Docker konteynerlerinin 10 yılı

• 2013’teki ilk yayımlanışından bu yana geliştiricilerin uygulama derleme, dağıtım ve çalıştırma biçimini kökten değiştiren Docker’ın teknik evrim sürecini ele alan bir ACM makalesi; basit bir CLI’ın arkasında yatan onlarca yıllık sistem araştırmasını derliyor
• Linux namespace’lerini kullanarak sanal makine olmadan da süreç izolasyonu sağlaması, Docker’ın temel teknik dayanağıdır; 2001’den itibaren kademeli olarak eklenen 7 namespace türü birleştirilerek hafif konteynerler uygulanır
• macOS ve Windows desteği için kütüphane sanal makine monitörünü (HyperKit) masaüstü uygulamasının içine gömen tersine düşünülmüş bir mimari benimsendi; geleneksel hypervisor yaklaşımı yerine Linux kullanıcı süreci içinde çalıştırıldı
• Günümüzde ARM·RISC-V gibi heterojen donanımları ve yapay zeka iş yüklerini destekliyor; bulut, masaüstü ve edge genelinde standart geliştirme altyapısı haline geldi
• Yapay zeka iş yüklerinin yükselişiyle birlikte GPU bağımlılığı yönetimi yeni bir zorluk olarak öne çıktı; CDI (Container Device Interface) üzerinden GPU desteği ve TEE (Trusted Execution Environment) entegrasyonu gibi alanlarda Docker’ın evrimi sürüyor

---

Teknik kökenler

• 2000’lerin başında Linux dağıtımlarına çok sayıda bağımlılığı elle kurmak ve yazılımı doğrudan derleyip yapılandırmak yaygındı; 2010’da bulut bilişimin yükselmesiyle bu süreç daha da karmaşık hale geldi
• Docker, geliştiricinin uygulamayı ve tüm bağımlılıklarını dosya sistemi imajı ("konteyner") olarak paketlemesini sağlayarak, yalnızca Docker kurulu herhangi bir makinede çalıştırılmasını kolaylaştırdı
• Sanal makinelerden farklı olarak, tam bir işletim sistemi kurulumu olmadan birkaç komutla çalıştırılabilir

Tipik iş akışı

• Geliştirici bir Dockerfile yazarak shell sözdizimine dayalı adım adım derleme sürecini tanımlar
  • Python web sitesi örneği: FROM python:3 ile başlayıp bağımlılık kurulumu, kod kopyalama, port açma ve çalıştırma komutuna kadar her şeyi tek dosyada belirtir
• docker build ile konteyner imajı oluşturulur ve docker push ile Docker Hub’a gönderilir
• docker run -v data:/app/data -p 80:80 gibi komutlarla veri volume mount ve ağ portu açığa çıkarma ayarları verilerek çalıştırılır
• 2013’ten sonra CLI büyük ölçüde genişletilip backend baştan tasarlanmış olsa da, Dockerfile yazma → docker build → docker run şeklindeki temel iş akışı tutarlı biçimde korundu
• GitHub’da, herkese açık depoların kök dizininde yer alan 3,4 milyondan fazla Dockerfile bulundu

İç çalışma mantığı: Linux namespace’leri

• OS çekirdeği süreç belleğini izole etse de dosya sistemi, yapılandırma dosyaları, dinamik kütüphaneler gibi birçok sistem kaynağı paylaşılır
  • Aynı makinede çakışan dinamik kütüphane gereksinimlerine sahip birden çok uygulamayı kurmak oldukça zordur
  • Ağ portu çakışmaları gibi süreçler arası istenmeyen etkileşimler oluşabilir
• Her uygulamayı ayrı bir sanal makine (VM) içinde çalıştırmak bunu çözer, ancak yinelenen çekirdek, dosya sistemi, önbellek ve bridge ağlar nedeniyle çok ağırdır
  • Her guest OS bağımsız çalıştığı için storage ve bellekte yinelenen veriyi ayıklamak da zordur
• 1978 tarihli Unix v7’deki chroot() ayrı bir kök dosya sistemine izin veriyordu, ancak birden çok uygulamanın dosya sistemini birleştirmeyi desteklemiyordu
• Nix ve Guix, uygulama başına dizin yeniden paketleme + dinamik bağlama ile bunu çözer; ancak kapalı kaynak yazılımlara uygulanmaları zordur ve ağ portu çakışması sorununu çözemezler
• Docker, Linux namespace’lerini seçti: her süreç, dosya ve dizin gibi paylaşılan kaynaklara erişim biçimini ayrı ayrı kontrol edebilir
  • Örneğin, farklı namespace’lerdeki iki süreç /etc/passwd yolunu sırasıyla /alice/etc/passwd ve /bob/etc/passwd olarak farklı yorumlayabilir
  • Namespace’ler yalnızca kaynağı açarken uygulanır; sonrasında file descriptor’lar ek yük olmadan normal çekirdek kaynakları olarak çalışır
• Namespace’lerin eklenme geçmişi
  • 2001, Linux 2.5.2: mount namespace
  • 2006, Linux 2.6.19: IPC namespace
  • 2007, Linux 2.6.24: network stack namespace
  • Toplam 7 namespace türü desteklenir
• Plan 9’dan farklı olarak namespace’ler en baştan tasarlanmadı, kademeli olarak eklendiği için düşük seviyeli ve kullanımı zordu
• FreeBSD ve Solaris’teki benzer özellikler de yaygın kullanıma ulaşamadı
• 2013’te Docker’ın temel katkısı, VM’lerin ağır izolasyonu ile işletim sistemi temel öğelerinin kullanım kolaylığı arasında pratik bir denge noktası bulmasıydı

Docker’ın Linux konteyner çalıştırma yapısı

• Docker, host üzerinde çalışan sunucu daemon’u (dockerd) ile RESTful API üzerinden istek gönderen CLI istemcisinden oluşan istemci-sunucu yapısını kullanır
• 2015 civarında monolitik daemon ayrıştırılarak uzmanlaşmış bileşenlere dönüştürüldü
  • BuildKit: dosya sistemi imajı oluşturma
  • containerd: imajları çalışan konteyner örneklerine dönüştürme ve ağ ile storage kaynaklarını yönetme

Konteyner imajları

• docker build çağrıldığında, Dockerfile’daki yürütülebilir dosyaları ve verileri temsil eden katmanlı dosya sistemi imajı oluşturulur
  • En alt katman: Debian veya Alpine Linux gibi OS dağıtımı (ya da tar arşiviyle elle oluşturulmuş temel)
  • Sonraki katmanlar: Dockerfile’daki her komutun çalıştırılmasıyla oluşan dosya sistemi farkları
• İçerik adreslemeli storage sisteminde saklanır: anahtar olarak dosya sistemi imajının hash’i kullanılır
  • Verimli tekilleştirme, değişmezlik garantisi ve hash üzerinden kurcalama doğrulaması sağlar
• 2016’da Open Container Initiative (OCI) imaj formatını standartlaştırdı; çok sayıda bağımsız uygulama mevcut
• Linux dosya sistemleri overlayfs, btrfs, ZFS kullanılarak copy-on-write katmanları verimli biçimde snapshot’lanıp klonlanır
• stargz storage snapshotter ile imajlar için lazy-pulling desteği sağlanır

Konteyner örnekleri

• docker run çağrıldığında, OCI imajından namespace’lerle izole edilmiş bir süreç ("konteyner") oluşturmak için sistem kaynakları tahsis edilir
• containerd, her konteyner için gereken namespace’leri dinamik olarak ayarlarken şunları yapar:
  • Kaynak izolasyonu ve I/O hız sınırlaması için süreç cgroups (control groups) tanımlama
  • Konteyner içindeki yerel ağ portlarını host arayüzündeki dışa açık portlara yeniden eşleme
  • Kalıcı uygulama durumu için host dosya sistemindeki değiştirilebilir storage volume’larını bağlama
  • PID namespace ile konteynerin süreç ağacını izole etme
  • user namespace ile konteyner içindeki yerel UID’leri host’taki farklı UID’lere eşleme (ör. konteyner içindeki UID 1000 → host’ta UID 12345 veya 23456)
• Namespace yapılandırmasının az miktarda ek yükü vardır, ancak tam bir Linux VM başlatmaktan çok daha düşüktür ve çoğu durumda 1 saniyenin altındadır
• Linux çekirdeği, sonlanan konteynerleri normal süreçlerde olduğu gibi garbage collection ile temizler

Linux’un ötesi: macOS ve Windows desteği

• İstemci-sunucu mimarisi sayesinde CLI, güvenli ağ bağlantısı üzerinden uzak Docker örneklerine komut gönderebilir
• 2015’te Docker, Linux geliştirmede yaygın biçimde benimsenmişti; ancak macOS/Windows geliştiricilerinin Linux konteynerlerini çalıştıramaması önemli bir kullanılabilirlik engeli yarattı
  • Geliştiricilerin çoğu temel geliştirme ortamı olarak macOS/Windows kullanırken, Docker dosya sistemi imajları yalnızca Linux çekirdeğinde çalışabiliyordu
  • Public cloud’ın yükselişiyle birlikte dağıtım ortamı olarak Linux tercih edildi

Docker for Mac uygulamasının oluşturulması

• Temel kısıt: Linux sürümü Docker’a alışkın geliştiriciler için ek yapılandırma olmadan çalışmalı ve aynı Docker imajlarını çalıştırabilmeliydi
• Mevcut yaklaşımı (Linux’u masaüstü işletim sisteminin yanında ayrı çalıştırmayı) tersine çevirerek, hipervizörü macOS/Windows kullanıcı alanı uygulamasının içine gömdüler ve Linux’u onun içinde çalıştırdılar
  • Unikernel araştırmalarından ilham alındı: OS bileşenlerinin daha büyük uygulamaların içine esnek biçimde gömülebileceğini gösterdi
• HyperKit: Intel CPU’nun donanımsal sanallaştırma uzantılarını kullanarak normal bir kullanıcı sürecinde Linux çekirdeğini çalıştıran bir kütüphane VMM
  • Gömülü Linux çekirdeği Docker daemon’unu çalıştırır; bu daemon da konteynerleri yönetir ve normal Docker sunucu uç noktası gibi davranır
  • Tüm Linux yönetim ayrıntıları masaüstü uygulamasının içinde gizlenir → masaüstündeki docker build ve docker run, gömülü Linux örneğine iletilir ve “sadece çalışır”
• Bu yaklaşım, Podman gibi diğer konteyner sistemleri tarafından da benimsendi ve macOS/Windows üzerinde konteyner çalıştırmanın standart yöntemi haline geldi

LinuxKit: gömülü özel Linux dağıtımı

• Bağımsız çalışmak yerine başka uygulamaların bir bileşeni olarak gömülmek üzere tasarlanmış özel bir Linux dağıtımı
• Uygulama açılış süresini en aza indirmek için Docker konteynerlerini çalıştırmak adına gerekli en az bileşeni içeren özel bir kullanıcı alanı oluşturdu
• Her bir bileşeni konteyner içinde çalıştırarak, önyüklemede kullanılan kök namespace içinde hiçbir şey çalıştırmıyor
• Docker konteynerlerinin kullandığı aynı copy-on-write dosya sistemi ve ağ namespace’lerinden yararlanıyor
• LinuxKit + HyperKit birleşimiyle Linux süreçleri, yerel macOS süreçleriyle neredeyse aynı hızda başlatılabiliyor
• 2016’da Docker for Mac ve Windows uygulamaları olarak yayımlandı

Ağ sorunları ve SLIRP çözümü

• Gömülü Linux konteynerlerinden macOS/Windows’a ağ bağlantısı beklenmedik şekilde zor bir problemdi
• Geleneksel Ethernet köprüleme yaklaşımı karmaşık ağ yönetimi gerektiriyordu ve kurumsal masaüstlerindeki güvenlik duvarı/virüs denetleyicileri bunu potansiyel kötü amaçlı trafik olarak algıladığı için beta kullanıcılarından binlerce hata raporu geldi
• SLIRP çözümü: İlk kez 1990’ların ortasında Palm Pilot PDA’ları internete bağlamak için kullanılan bir araç
  • Konteynerin TCP el sıkışması sırasında Ethernet çerçeveleri paylaşımlı bellek üzerinden virtio protokolü ile host’a gönderilir
  • MirageOS’un unikernel kütüphaneleri kullanılarak Linux ağ istekleri macOS/Windows yerel socket çağrılarına dönüştürülür
  • OCaml ile yazılmış kullanıcı alanı TCP/IP yığını vpnkit, bunu host işletim sisteminde alır ve macOS connect() sistem çağrısını yapar
  • VPN politikaları açısından çıkan trafik, ayrı bir makineden değil Docker uygulamasından gelmiş olarak görülür
• 2016 beta testlerinde vpnkit dağıtıldıktan sonra kurumsal kullanıcı hata raporları %99’dan fazla azaldı
• SLIRP yaklaşımı daha sonra sunucusuz bulut alanında da benimsendi; eski çevirmeli ağ teknikleri yeni konteyner yönetimi sorunlarını çözmekte kullanıldı

Gelen ağ trafiğinin işlenmesi

• Linux konteyneri bir portu dinlediğinde, CLI’de açıkça istenmedikçe otomatik olarak internete açılmaz (ör. docker run -p 80:80 nginx)
• İdeal kullanıcı deneyimi: konteyner portlarının doğrudan masaüstü IP’sinde görünmesi ve tarayıcıdan http://localhost:8080 ile erişilebilmesi
  • VMware Fusion gibi eski masaüstü sanallaştırma araçları localhost yerine geçici bir ara IP gösteriyordu
• LinuxKit çekirdeğine özel bir eBPF programı yüklenir → masaüstü host’a karşılık gelen bir dinleme socket’i oluşturmayı tetikler → port yönlendirici etkinleşir
• Sonuç: Mac’te Linux konteyneri çalıştırıldığında anında localhost üzerinden erişim mümkün olur; geliştirici deneyimi yerel Linux makineyle aynı hale gelir

Depolama

• Geliştiricilerin kodu yerelde düzenlerken konteyner içinde kodu ve testleri çalıştırabilmesi gerekir
• Linux’ta docker run -v /host:/container ile bind mount üzerinden canlı dosya erişimi sağlanır
• macOS ve Windows farklı çekirdeklere sahip olduğu için bind mount çalışmaz
  • Docker, KVM hipervizöründen türeyen virtio-fs paylaşımlı bellek protokolünü kullanarak dosya sistemi işlemlerini host’a iletir (FUSE istek biçiminde)
  • Host bu istekleri alır ve karşılık gelen open, read, write sistem çağrılarını yapar
• Geliştiricinin kodu ve verisi host dosya sisteminde kalır; böylece Apple Time Capsule veya Spotlight gibi yedekleme ve arama araçları bunlara erişebilir

Windows Services for Linux (WSL)

• 2017’de Microsoft WSL’yi yayımladı: Windows üzerinde Linux uygulamalarını doğrudan çalıştırma
  • İlk sürüm, sanallaştırma yerine Linux ikililerinin sistem çağrılarını Windows sistem çağrılarına dinamik olarak çeviren bir library OS yaklaşımıydı
  • Birçok uygulamada başarılı oldu, ancak Docker konteynerlerini çalıştırmak için desteklenen sistem çağrıları yetersizdi
• 2018’de WSL2 yayımlandı: Docker for Mac’e benzer şekilde arka planda tam bir Linux VM çalıştıran biçimde yeniden tasarlandı
  • WSL2 Docker, daemon’u ve kullanıcı konteynerlerini LinuxKit WSL dağıtımı içinde çalıştırır
  • Docker API’sini ve ağ port yönlendirmesini Windows’un kendisi ile diğer Linux dağıtımları arasında işler
• Docker konteynerlerinin platformlar arası evrimini mümkün kılan temel mimari: geleneksel olarak “yalnızca çekirdeğe ait kod” kabul edilen parçaları kullanıcı alanı kütüphaneleri olarak yeniden kullanıp diğer uygulamalara gömen library OS yaklaşımı
• Bu mimarinin başarısı, görünmez ama her yerde olmasıyla kanıtlanır: milyonlarca geliştirici her gün hangi işletim sisteminde çalıştığını dert etmeden Docker kullanıyor

Yeni geliştirici iş akışı: çoklu CPU mimarisi

• Docker’ın ilk dönemlerinde bulut iş yüklerinin çoğu Intel mimarisi tabanlıydı
• 2018’de Amazon Graviton ARM işlemcileri, 2020’de Apple M1 ARM CPU’sunun çıkmasıyla durum değişti
  • İş yüklerini ARM üzerinde çalıştırmak maliyet tasarrufu ve daha yüksek performans sağlayabiliyor
• Aynı Docker imajı içinde Intel, ARM, POWER ve RISC-V gibi çoklu CPU mimarilerini desteklemek gerekti
• Sunucu tarafında OCI imaj formatı çoklu mimari manifestoları (multiarch manifests) ile genişletildi
• Tek bir host üzerinde çoklu CPU mimarileri için imaj oluşturmak amacıyla Linux’un binfmt_misc özelliği kullanıldı
  • QEMU üzerinden ARM ve Intel ikilileri arasında şeffaf dönüşüm sağlandı
  • Ek yük çoğunlukla yalnızca build aşamasında oluşur; ortaya çıkan çoklu mimari imajlar ise herhangi bir host’ta yerel olarak çalışır
• Apple, Rosetta ile CPU komut seti dönüşümü için donanım ve yazılım desteği sundu → bu, Docker mimarisine kolayca entegre edildi
• Bugün Intel ve ARM konteynerlerini yan yana çalıştırmak yaygın bir geliştirici iş akışı

Gizli yönetimi için güvenilir yürütme ortamları (TEE)

• Konteyner ortamlarında parola veya API anahtarı gibi gizli bilgilerinin (secrets) yönetimi her zaman zorlu bir konu oldu
  • Dosya sistemi imajına gömmeden dinamik olarak enjekte edilmesi gerekir
• Docker, socket forwarding desteği sunarak yerel alan soketlerinin konteynere mount edilmesini mümkün kılar
  • Docker for Mac/Windows durumunda soket forwarding Linux VM’ye kadar uzanır
  • ssh-agent gibi anahtar yönetim sistemleri, anahtarları doğrudan açığa çıkarmadan konteyner içinde kullanılabilir
• Socket forwarding temel bir koruma seviyesi sağlasa da, büyüyen yazılım tedarik zincirindeki kötü amaçlı yazılımlara karşı daha fazla savunma katmanı gerekir
• Hypervisor koruması, konteyner runtime içine doğrudan uygulanarak konteynerler arası koruma seviyesi artırılıyor
• Güvenilir yürütme ortamı (TEE): modern CPU’ların donanım özellikleriyle, host OS üzerinde bile gizli verileri koruyabilen "confidential VM"ler oluşturulabiliyor
  • Uygulama, kernel ve hypervisor sınırlarını aşacak şekilde veri erişimine kısıtlama uygulanabilir
  • Ancak TEE yapılandırma ve kullanımı, OS sanallaştırmasına benzer bir yönetim karmaşıklığı taşır
• Confidential Containers çalışma grubu, TEE içinde çalışan ve Docker ile yönetilen uygulamalar geliştiriyor
  • Docker CLI, masaüstündeki yerel TEE’den host üzerinden uzak bulut TEE ortamına kadar şifrelenmiş mesaj forwarding yapıyor
  • Geliştiriciler sahaya gitmeden hassas bulut ortamlarında kimlik doğrulaması yapabiliyor, kimlik bilgileri ise masaüstü enclave’inde güvenle saklanıyor

AI iş yükleri için GPGPU desteği

• AI iş yüklerinin yükselişi, tamamen yeni bir zorluğu da beraberinde getirdi: makine öğrenimi iş yüklerinin çoğu GPU üzerinde çalışıyor
• Temel sorun şu: GPU iş yükleri tam olarak eşleşen kernel GPU sürücüsü ve kullanıcı alanı kütüphaneleri gerektiriyor, ancak çok sayıda konteyner tek bir paylaşımlı kernel üzerinde çalışıyor
  • İki uygulama aynı kernel GPU sürücüsünün farklı sürümlerini isterse, Docker’ın başta çözmeye çalıştığı temel çakışma yeniden ortaya çıkıyor
• Mart 2023’ten beri Docker, CDI(Container Device Interface) desteği sunuyor
  • Konteyner başlatılırken dosya sistemi imajını özelleştiriyor
  • GPU aygıt dosyalarını ve GPU’ya özel dinamik kütüphaneleri bind mount ile ekleyip ld.so önbelleğini yeniden oluşturuyor
• CDI, belirli GPU sınıfları ve üreticileri arasında imaj taşınabilirliğini garanti etse de, farklı OS’ler ve donanım markaları arasında tam anlamıyla sorunsuz değil
  • CDI’nin eklediği dinamik kütüphaneler farklı API’ler tanımladığından, konteynerlerin geleneksel arayüzü olan kararlı Linux sistem çağrısı ABIsine benzer bir yapı yok
  • Nvidia GPU için geliştirilen bir uygulamanın Apple M serisi CPU’da çalıştırılmasının zor olmasının nedeni, GPU sanallaştırma desteğinin farklı donanımlar arasında vektör komutlarını dönüştürecek kadar olgunlaşmamış olması
• Konteyner topluluğu ve GPU üreticileriyle birlikte, GPU ile ilgili bağımlılıkları yönetmenin daha esnek ve güvenli yolları geliştiriliyor
• Taşınabilir arayüz girişiminin ortak bir uzlaşıya ulaşması umuluyor

Sonuç

• Docker, 2013’te geliştiricilerin uygulama oluşturmasını, paylaşmasını ve çalıştırmasını kolaylaştırma hedefiyle yola çıktı
• Bugün standart bulut ve masaüstü geliştirme iş akışlarına derinlemesine entegre durumda; dünya genelinde milyonlarca geliştirici tarafından her gün kullanılıyor ve aylık milyarlarca isteği işliyor
• Birbiriyle çalışabilirlik için standartlar oluşturan aktif ve çeşitli bir açık kaynak topluluğunu sürdürmek, değişmeyen hedeflerden biri oldu
  • CNCF(Cloud Native Computing Foundation) birçok temel bileşenin yöneticisi olarak görev yapıyor
  • Open Container Initiative(Linux Foundation bünyesinde) ise imaj formatının yöneticisi
• Günümüzde bu öğelerin birçok uygulaması aktif olarak kullanılıyor; dağıtımlar bulut, masaüstü ve otomotiv, mobil, uzay aracı gibi edge ortamlarda artıyor
• 2025 itibarıyla tipik geliştirici iş akışı; sürekli test ve dağıtım, IDE dil sunucuları ve agentic coding yoluyla AI desteğini bir araya getiriyor
• Docker açısından bakıldığında temel "build and run" iş akışı 10 yıl öncesine çok benziyor, ancak farklı ortamlardaki sürtünmeyi azaltan sistem desteği büyük ölçüde güçlendirildi
• Amaç, Docker’ı geliştiricilerin kodu daha hızlı dağıtmasına yardımcı olan görünmez bir eşlikçi haline getirmek ve modern AI kodlama iş akışlarına uygun şekilde ölçeklenebilir tasarlamak

[GN⁺]

Hacker News görüşleri

• Docker ilk çıktığında, bir tane daha "devrim" söyleminden bıkmış durumdaydım
  Yarım yamalak NoSQL, koşulsuz mikroservisler ve her fonksiyon çağrısını RPC'ye çeviren akımdan nefret ediyordum
  Ama bugün sadeliği sayesinde sık sık kullanıyorum
  Yine de başkalarının container'ları hâlâ cehennem gibi. Ben en azından basit tutmaya çalışıyorum ama bazıları o kadar çok şey dolduruyor ki, sanki kendileri de dağıtım sürecini bilmiyormuş gibi geliyor
  Artık LLM'ler sayesinde geliştiricinin kendisinin bile bakmadığı kodların ortalığa saçıldığı bir çağdayız gibi görünüyor

  • Her sabahın köründe DevOps ekibinin container sorunlarını çözmek için bitmek bilmeyen Zoom çağrıları yaptığını görmek, gerçekte neler olduğunu kimsenin bilmediğine beni iyice ikna etti

• Sayısız deneme oldu ama sonunda Dockerfile'ın ayakta kalmasının nedeni esnekliği
  Mevcut işletim tarzındaki gibi dosya kopyalayıp komut çalıştırma yapısına aşina olunması da etkiliydi
  Kaba saba görünüyor olabilir ama bu basit esneklik muhtemelen ileride de ana akım olarak kalacak

  • Dil bağımsız bir build aracı olmadığı için sonuçta dil bazlı paket yöneticilerini çağıran rastgele komutlar çalıştırıyoruz
    Herkes Nix ya da Bazel kullansaydı, belki docker build alay konusu olurdu
  • Yeniden üretilebilir build'leri engelleyen bir bariyer var
    Farklı build'lerde hash'ler değişirse güvenilemez hâle geliyor; bu yüzden dosya değiştirme zamanı gibi unsurlar hash'e dahil oldukça tam tutarlılık zor
  • Docker registry gibi merkezi bir depo olmaması, alternatif çözümlerin darboğazı
    Ben şahsen mkosi'yi seviyorum ama herkes boş bir OS şablonundan başlamak istemiyor
  • Nix, Docker container'ları oluşturmakta mükemmel
  • Registry ile bağın biraz daha güçlü olmasını isterdim
    Çoğu durumda public registry'den pull edip private registry'ye push yapılıyor; bu yüzden yerel image'lar neredeyse hiç kullanılmıyor
    Biraz verimsiz ama değiştirecek kadar da rahatsız edici görünmüyor

• Docker'ın ilk kez 2013'te PyCon US Santa Clara'da tanıtıldığını hatırlıyorum
  O dönemki YouTube sunum videosuna bakınca bunun tarihî bir an olduğu görülüyor
  Makalenin yayımlanma tarihiyle gerçek sunum zamanı farklı olduğundan bir karışıklık olmuş gibi ama kabaca 13 yıl önceydi

  • Başlık sadece "zamanda geriye gitmek" anlamında seçilmiş
    “Twelve years of Docker containers” yerine “A decade of Docker” daha doğal geldi
  • Aslında doğru tarih 2014
    HN'deki ilk tanıtım yazısını hatırlıyorum
    O sırada LXC ya da Vagrant gibi alternatiflerden bıkmıştım; Docker gerçekten kurtarıcı gibi bir şeydi

• Docker'ın 1990'lardan kalma SLIRP adlı bir dial-up aracını yeniden kullanarak güvenlik duvarını aşmış olması ilginç

  • Podman da bir zamanlar slirp4netns kullanıyordu ama son dönemde Pasta'ya geçti
  • SLIRP, Palm Pilot için değil; SLIP/PPP kullanamayan shell account kullanıcılarının internet bağlantısını taklit edebilmesi için yapılmış bir yardımcı programdı
    Gelen bağlantıları desteklemiyordu ama NAT'in öncülü sayılabilecek bir fikirdi
  • Palm Pilot için olan bir aracı güvenlik duvarını aşmak için kullanmak çılgınca bir fikir, ama en iyi altyapı hack'leri genelde böyle bir çaresizlikten doğuyor
  • SLIRP, 'rootless' network namespace'ler içindi; yani root yetkisi olmadan container'ı host ağına bağlama yöntemi

• Docker'ı kullanmak istedim ama her denediğimde ihtiyaç duyduğum bir özellik eksikti
  Muhtemelen pek yaygın olmayan bir teknoloji stack'i kullandığım içindi

• "Benim bilgisayarımda çalışıyor" sözünü endüstri standardına dönüştürmesi, Docker'ın büyüklüğü
  Artık o bilgisayarın kendisini production'a "gönderdiğimiz" bir dönemdeyiz

  • Ortak yazarlardan biri olarak, Docker'dan önce Xen ile uğraşıyordum; Docker gerçekten BT kültürünün kendisini değiştiren bir olaydı
    Eskiden dağıtım devasa bir prosedürdü ama artık dosya sistemini doğrudan deploy edebiliyoruz
    Bugünkü coding agent devrimi de bana benzer bir kültürel dönüşüm gibi geliyor
  • Docker'ın özü, build'i tekrarlanabilir bir süreç olarak yakalayabilmemizi sağlamasıydı
    Ortamı 10 satırlık bir script ile yeniden üretebiliyorsan, “makineyi deploy etmek” o kadar da kötü değil
  • Docker bir tür aşırı statik linkleme
    Neden böyle bir yaklaşımın bu kadar çekici olduğunu kendimize sormamız gerekiyor
  • Görünüşe göre "laptop'ta çalışıyor" artık "laptop'ı container yapıp pipeline'a koyalım" hâline geldi
    Soyutlamanın hep kazanmasının sebebi, temel problemi düzeltmenin fazla zor olması
  • Berbat container'ların, düzgün bir paketleme sistemi yerine Dockerfile ile servis yönetimi yapmaya çalıştığını görmek yorucu

• Networking konusunda çok bilgim yok ama Mac'te container'ların ayrı bir IP adresi almasını istiyorum
  Port mapping olmadan container_ip:80 üzerinden erişmek istiyorum
  Linux'ta bu mümkündü ama Mac'te bir VM üzerinden geçmek gerektiği için karmaşık
  WireGuard tabanlı yöntemi denedim ama her Docker güncellemesinde bozuluyor
  Resmî olarak desteklenen bir yöntem olsa keşke

  • Bir Docker mühendisi olarak, Tailscale Extension'ı denemeni öneririm
    Tailscale Docker Extension ayarları otomatik olarak hallediyor
    Port mapping'den kaçınma nedenin dinamik portlarsa, --net=host seçeneğini ve Host Networking ayarını açmanı öneririm
  • Mac'im yok ama açık kaynaklı alternatif olarak Colima projesini tavsiye ederim

• 2013, Docker, Guix ve NixOS'un aynı anda ortaya çıktığı paketleme açısından bereketli bir yıldı
  İlgili makaleyi yazarken bunu fark ettim
  Sonrasında bu kadar çok iyi projenin aynı yıl içinde birlikte çıktığı başka bir dönem oldu mu diye merak ediyorum

  • hg ve git birkaç hafta arayla çıktı, fossil da hemen ardından geldi
  • Dürüst olmak gerekirse, gerçekten kitleselleşmeyi başaran tek şeyin Docker olduğunu düşünüyorum
    Guix ve Nix hâlâ küçük bir kullanıcı kitlesiyle sınırlı

• ML ve AI her yere girdikçe image boyutları katlanarak büyüyor
  Sadece torch bile birkaç GB tutuyor
  Eski 30MB image'ları özlüyorum

  • TensorFlow'un iki kez kurulduğu image'lar bile gördüm
    Katmanlar arasında dosya paylaşımı olmadığı için israf çok büyük
    Bu yüzden dosya düzeyinde dedupe destekleyen alternatif bir registry geliştiriyorum
  • Ben, ISO tabanlı değişmez Alpine Linux üzerinde birkaç Ruby ve PHP container'ı çalıştırıyorum; toplamı yaklaşık 750MB

• Docker'ın kurumsal güvenlik yazılımlarını kandırmak için VPN gibi kılığına girmiş olması gerçekten çok ilginçti
  Teknik tarih açısından da eğlenceli bir örnek