← Radar

Konu: Altyapı2 dk okuma

Apple, Mac'e 'WSL' getirdi: Container Machines

Bu neden önemli?

Çoğu proje sonunda bir Linux sunucusunda çalışıyor ama geliştiriciler Mac kullanıyor. İkisi arasındaki farkları erken görmek, 'benim makinemde çalışıyordu' sorununu azaltıyor. Sanal makineler ve konteynerler arasındaki farkı anlamak için de iyi bir örnek.

Sorun: Mac’te yazıyorsun, Linux’ta çalışacak

Geliştiricilerin çoğu Mac kullanıyor. Ama yazdıkları kod sonunda genelde bir Linux sunucusunda çalışıyor. İki işletim sistemi birbirinden farklı davrandığı için, Mac’te sorunsuz çalışan bir şey sunucuda patlayabiliyor. Windows dünyasında bu sorunu WSL (Windows Subsystem for Linux) çözüyor: Windows’un içinde gerçek bir Linux çalıştırıyor. Apple’ın Container Machines özelliği de Mac için benzer bir şey yapıyor.

Ne sunuyor?

Container Machines, Mac’in içinde kalıcı, hafif bir Linux ortamı açıyor. Öne çıkan tarafı, iki sistemin ne kadar iç içe geçtiği:

  • Kullanıcı ve ev dizini paylaşımı. Mac’teki kullanıcı adın ve ev dizinin otomatik olarak Linux ortamına bağlanıyor. Yani projelerin ve ayar dosyaların ikisinde de var. Kopyalama adımı yok.
  • Mac’te düzenle, Linux’ta çalıştır. Editörünü Mac’te kullanmaya devam ediyorsun. Aynı dosyaları Linux ortamına geçip derleyip çalıştırıyorsun. Videodaki örnekte bir Bun uygulaması Mac’te yazılıp Linux ortamında tek satırla çalıştırılıyor.
  • Gerçek Linux servisleri. Ortam bir başlangıç sistemi (systemd) çalıştırabildiği için, uygulamanın yanında systemctl start postgresql diyerek gerçek bir veritabanını servis olarak açabiliyorsun.
  • Hedef başına bir ortam. Alpine, Ubuntu, Debian gibi farklı dağıtımları yan yana kurup uygulamanı hepsinde deneyebiliyorsun.

Konteyner mi, sanal makine mi?

Burada işin ilginç tarafı Apple’ın yaklaşımı. Geçen yıl çıkan container aracı, Docker’a alternatif. Ama Docker Desktop bütün konteynerleri tek büyük bir sanal makinede toplarken, Apple her konteynere kendi hafif sanal makinesini veriyor. Bunun güvenlik ve gizlilik avantajı var: Her konteyner tam bir sanal makine gibi yalıtılmış, sadece ona açtığın veriyi görüyor.

Container Machines ise bunun üstüne kurulu. Ama bir uygulamayı değil, bir Linux ortamını modelliyor. Yani sadece bir programı değil, tam bir dev makinesini çalıştırıyorsun. Konteyner ve sanal makine farkını kod izolasyonu yazımızda daha ayrıntılı anlattık.

Dikkat edilecekler

Video birkaç uyarı da sıralıyor:

  • Bellek geri verilmiyor. Ortam varsayılan olarak sistem belleğinin yarısını alıyor ve yeniden başlatana kadar bunu geri bırakmıyor. OrbStack gibi bazı araçlar kullanılmayan belleği macOS’e geri verebiliyor.
  • GPU ve USB geçişi yok. Şimdilik ekran kartını ya da USB cihazları ortama aktaramıyorsun.
  • Grafik uygulamaları zor. Linux’a özel arayüzlü programları çalıştırmak sorunsuz değil.
  • Güvenlik dengesi. Ev dizini paylaşımı varsayılan olarak okuma-yazma açık. Yani ortamda çalışan her şey SSH anahtarlarına ve bulut kimlik bilgilerine dokunabilir. Paylaşımı salt okunur yapabiliyor ya da tamamen kapatabiliyorsun, ama tek bir klasörü seçme imkânı yok.

RepoFlow’un karşılaştırmasına göre, çekirdek performansta Apple Containers, Docker Desktop ve OrbStack birbirine yakın. Videonun yapımcısının kişisel tercihi ise, kaynak yönetimi daha iyi olduğu için OrbStack’te kalmak. Yine de ücretsiz bir seçenek arayanlar için Apple containers, Docker Desktop’a iyi bir alternatif.

Düşün

  • Kodunu geliştirdiğin ortam ile çalışacağı ortam ne kadar farklıysa, sürprizler o kadar artar. Senin projende bu iki ortam ne kadar benziyor?
  • Kolaylık için ev dizinini bir Linux ortamına açmak sana ne kazandırır, ne kaybettirir?

Videoyu izle

Tıklayınca video YouTube'dan yüklenir; o ana kadar bu sayfa YouTube'a hiçbir istek göndermez.
Kaynaklar (3, İngilizce)

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.

Konu: Altyapı3 dkVideo: The Pragmatic Engineer

Kodu üretime güvenle göndermek: Canary, GitOps, geri alma yerine ileri sarma ve özellik bayrakları

Octopus Deploy'da baş mühendis olan Robert Erez, on yılı aşkın CI/CD deneyimini The Pragmatic Engineer'da anlattı. Bu sohbetten dört somut ders çıkıyor: Sürekli teslim ile sürekli dağıtım arasındaki farkı bilmek, GitOps'u Git'ten ibaret sanmamak, şema değişikliği varsa geri almak yerine ileri gitmek ve dağıtımı yayından ayırmak için özellik bayrağı kullanmak.