Docker "Aygıtta Yer Kalmadı" Hatası Nasıl Düzeltilir: Kapsamlı Rehber

"Aygıtta yer kalmadı" Docker hatası genellikle en kötü zamanda ortaya çıkar: dağıtımın ortasında, kritik bir build sırasında veya gerekli bir imajı çekerken. Bu hatayla birkaç kez karşılaştım ve şunu söyleyebilirim: Doğru teşhis olmadan dosya silmeye koşmak veri kaybına davetiye çıkarır.

Bu hatayı özellikle zorlayıcı kılan şey, nadiren tek bir nedene dayanmasıdır. Birikmiş Docker imajları, kontrolden çıkmış container log’ları, milyonlarca küçük dosyadan tükenmiş inode’lar ya da çalışan süreçlerin hâlâ açık tuttuğu silinmiş dosyaların tükettiği “hayalet” alanla uğraşıyor olabilirsiniz. Her senaryo farklı bir çözüm gerektirir.

Bu yüzden her zaman eylemden önce teşhisi vurgularım. Kök nedeni anlamak, hedefe yönelik çözümleri verimli biçimde uygulamanızı ve üretim ortamınızı aksatmanızı önler. Bu rehberde, bu can sıkıcı sorunu teşhis etme, çözme ve önleme konusunda sistematik bir yaklaşım sunacağım.

Docker’a yeniyseniz, uygulamalı Introduction to Docker kursumuzu almanızı öneririm; containerization’a başlamanız için gereken her şeyi kapsar.

Docker "Aygıtta Yer Kalmadı" Hatası Nedir?

Docker bu hatayı verdiğinde, sistem depolamanızla ilgili iki temel sorundan birini işaret eder:

• Fiziksel disk bloklarının tükenmesi
• Inode’ların tükenmesi

Bu nedenler arasındaki ayrımı anlamak, doğru çözümü uygulamak için kritik öneme sahiptir.

“Aygıtta yer kalmadı” hatasının temel nedenleri

İlk ve en basit neden fiziksel disk bloklarının tükenmesidir. Dosya sisteminizin veri yazacak gerçek depolama alanı kalmamıştır. Bu daha sezgisel bir senaryodur: Diskinizi Docker imajları, container’lar, log’lar veya diğer dosyalarla doldurmuşsunuzdur.

İkinci ve daha az bariz neden ise inode’ların tükenmesidir. GB’larca boş alan olsa bile, dosya sisteminiz inode’ları (dosya ve dizinleri izlemek için kullanılan metadata yapıları) tüketebilir. Her dosya ve dizin bir inode kullanır; bu nedenle milyonlarca küçük dosya oluşturan uygulamalar (PHP oturum dosyaları veya npm’in node_modules dizinleri gibi) disk alanı boş kalsa bile inode’ları bitirebilir.

overlay2 depolama sürücüsünü anlama

Docker genellikle Linux OverlayFS tabanlı overlay2 depolama sürücüsünü kullanır. OverlayFS, tek bir ana makinede birden çok dizini katmanlar ve bunları birleşik bir dosya sistemi olarak sunar. İmaj katmanları salt okunur alt dizinler olarak bağlanırken, her çalışan container ince bir yazılabilir üst katman ekler. Birleştirilmiş görünüm container’a tek bir dizin olarak sunulur.

overlay2 sürücüsü teorik olarak 128’e kadar alt OverlayFS katmanını yerel olarak destekler, ancak Docker’ın katman deposu pratikte imaj başına 125 temel katman sınırı uygular. Bu, docker build ve docker commit gibi işlemler için verimli imaj bileşimi ve daha iyi performans sağlar. 

overlay2 önceki depolama sürücülerine göre daha az inode tüketecek şekilde tasarlanmış olsa da, sürekli imaj derleyen, katman çeken veya container oluşturan Docker ortamları, özellikle imajlar veya uygulama katmanları çok sayıda küçük dosya içerdiğinde, zaman içinde hem disk blokları hem de inode’lar üzerinde ciddi baskı oluşturabilir.

Bu hatanın görünümü dağıtım ortamına göre değişir:

• Yerel Linux sistemlerinde /var/lib/docker’ı destekleyen dosya sistemini etkiler. 

• Windows veya macOS için Docker Desktop’ta, kısıt Docker’ın sanal makine disk imajının (ör. .raw veya .vhdx dosyası) içinde bulunur ve depolamayı geri kazanma veya yeniden boyutlandırma sırasında ek hususlar doğurur.

Adım 1: Kök Nedeni Teşhis Edin

Herhangi bir şeyi kaldırmadan önce her zaman kapsamlı bir teşhisle başlarım. Birkaç dakikalık bu yatırım, saatlerce sürecek sorun gidermeyi önleyebilir ve kazara veri kaybını engelleyebilir.

Sistem düzeyinde kapasiteyi kontrol edin

Ana makinenizin disk kullanımını df -H ile inceleyerek başlayın (df, disk free anlamına gelir):

df -HAltyapı:

WSL’de boş disk kontrolü

Bu komut, disk kullanımını insan tarafından okunabilir biçimde gösterir. %100’e yakın kapasitedeki dosya sistemlerini arayın. 

Yerel Linux kurulumlarında, /var/lib/docker’ın bulunduğu bölüme özellikle dikkat edin. Bu genellikle kök bölümünüz (/) veya Docker’a ayrılmış bir bölümdür. 

Docker Desktop’ta (Windows/Mac) belirli /var/lib/docker başvuruları yerine, Docker’ın bir sanal makine içinde çalıştığı için Docker VM verilerini tutan ana dosya sistemi bağlamasını (genellikle /dev/sdf veya benzeri) arayın.

Ardından, df -i kullanarak inode tükenmesini kontrol edin:

df -iAltyapı:

Inode tükenmesi kontrolü

Herhangi bir dosya sisteminde %100 inode kullanımı (IUse%) görürseniz, sorunu buldunuz demektir. Bu senaryo, Docker’ın birçok küçük dosyaya sahip container’ları tekrar tekrar oluşturup yok ettiği build sunucuları ve CI/CD ortamlarında şaşırtıcı derecede yaygındır.

Docker’a özgü kullanımı analiz edin

Artık sorunun disk alanı mı yoksa inode’lar mı olduğunu belirlediğimize göre, daha derine inip Docker’ın kaynak tüketimini inceleyelim. docker system df komutu, tüm Docker kurulumlarında evrensel olarak çalışan üst düzey bir özet sağlar:

docker system dfAltyapı:

Bu çıktı, alan kullanımını dört kategoriye ayırır: İmajlar, container’lar, yerel volumelar ve build önbelleği.

RECLAIMABLE sütunu özellikle değerlidir. Çalışan container’ları etkilemeden ne kadar alanı geri kazanabileceğinizi gösterir. Bu iki metrik arasındaki farkı anlamak kilittir: “active” alan, hâlihazırda çalışan container’lar tarafından kullanılan alandır; “reclaimable” alan ise güvenle boşaltılabilir.

Daha ayrıntılı bilgi için detay bayrağını ekleyin:

docker system df -vAltyapı:

Docker kullanım analizi

Bu ayrıntılı çıktı, her bir imajı, container’ı ve volume’u ayrı ayrı boyutlarıyla listeler; alanı en çok tüketenleri tespit etmenize yardımcı olacak ayrımı sunar. Her bölümde şunlara bakın:

• İmajlar: Her imajın boyutunu ve şu anda kullanımda olup olmadığını gösterir. Kullanılmayan veya farklı tag’lerle yinelenen büyük imajları arayın. “Unused” olarak işaretlenen imajlar, çalışan container’ları etkilemeden güvenle kaldırılabilir.

• Container’lar: Her container için yazılabilir katman boyutunu gösterir. Durdurulmuş bir container burada önemli bir SIZE gösteriyorsa, dosya sistemine veri yazmıştır. CREATED sütunu, unutulmuş olabilecek eski container’ları belirlemenize yardımcı olur.

• Volumelar: Volume boyutlarını ve kullanım durumlarını listeler. Kullanımda olmadığı işaretlenen volumelar, kaldırma için uygun adaylardır; ancak temizlemeden önce önemli veri içermediklerinden emin olun.

• Build önbelleği: Çoğunlukla en büyük tüketici ve sıklıkla gözden kaçar. Bunlar, Docker’ın sonraki build’leri hızlandırmak için tuttuğu docker build işlemlerinden kalan ara katmanlardır.

İşletim sistemi özel komutları

Daha derin dosya sistemi içgörüsü isteyen yerel Linux kullanıcıları, hangi alt dizinlerin (overlay2, containers, volumes) en çok alan tükettiğini doğrudan göstermek için alt dizinleri isteğe bağlı olarak inceleyebilir:

sudo du -h --max-depth=1 /var/lib/docker | sort -hAltyapı:

Bununla birlikte, Docker Desktop kullanıcıları için /var/lib/docker Docker’ın gizli sanal makinesi içinde bulunur ve doğrudan erişilebilir değildir. İyi haber şu ki, docker system df -v platformdan bağımsız olarak ihtiyacınız olan tüm eyleme dönüştürülebilir bilgileri sağlar ve en güvenilir teşhis yaklaşımıdır.

Adım 2: Docker Prune ile Sistemi Temizleyin 

Alan tüketiminin nerede olduğunu belirledikten sonra, Docker’ın yerleşik temizleme komutlarını kullanarak onu güvenle geri kazanabilirim. Bu işlemler, yalnızca kullanılmayan kaynakları kaldıracak şekilde tasarlanmıştır; çalışan servisleri bozma riskini en aza indirir.

Sarkan (dangling) kaynakları temizleyin

Docker “dangling” ve “unused” kaynakları ayırt eder. Sarkan bir imaj, tag’i olmayan ve hiçbir container referansı bulunmayan imajdır. Genellikle başarısız olan veya yerini bir başkasına bırakan bir build’in ara katmanıdır. Bunları kaldırmak her zaman güvenlidir.

Temel prune komutuyla başlayın:

docker system pruneAltyapı:

Bu komut tüm kullanılmayan container’ları, ağları ve sarkan imajları kaldırır. Etiketli imajlara veya volumelara açıkça belirtilmedikçe dokunmaz. Docker işlem öncesi onay isteyecektir.

Daha agresif olmak ve tüm kullanılmayan imajları (yalnızca sarkanları değil) kaldırmak için --all bayrağını ekleyin:

docker system prune --allAltyapı:

Docker system prune

Bu komut, şu anda hiçbir container ile ilişkili olmayan imajları kaldırır. Dikkatli olun: Sonraki dağıtımlar kaldırılan imajları yeniden çekmek zorunda kalacaktır.

Temizlemeye volumeları (kalıcı veri içerirler) dahil etmek isterseniz --volumes bayrağını ekleyin:

docker system prune --all --volumesAltyapı:

Uyarı: Bu, kullanılmayan volumelardaki verileri kalıcı olarak siler. Bu bayrağı kullanmadan önce volumeların önemli veri içermediğini mutlaka doğrulayın.

Build önbelleğini yönetin

İşler burada ilginçleşiyor. Docker build işlemlerinden gelen ara katmanları depolayan build önbelleği çoğu zaman en büyük alan tüketicisidir; ancak docker system prune bunu sonraki build performansını korumak için kasıtlı olarak hariç tutar.

Özellikle build önbelleğini hedeflemek için:

docker builder pruneAltyapı:

Seçici olmak ve yakın tarihli önbellek katmanlarını korumak isterseniz zaman tabanlı filtreler kullanın:

docker builder prune --filter "until=24h"Altyapı:

Bu, yalnızca 24 saatten eski önbellek katmanlarını kaldırır ve yakın çalışmalarınızın kalmasını sağlar.

Volumeları güvenle temizleyin

Volumelar, kalıcı veri (veritabanları, yüklenen dosyalar, uygulama durumu gibi) içerdiğinden ekstra dikkat gerektirir. Yanlış volume’u kaldırmak kalıcı veri kaybı demektir.

Önce sarkan volumeları (herhangi bir container’a bağlı olmayanlar) tespit edin:

docker volume ls -f dangling=trueAltyapı:

Bu listeyi dikkatle inceleyin. Bu volumelara ihtiyaç olmadığından eminseniz, temizleyin:

docker volume pruneAltyapı:

Docker devam etmeden önce onay isteyecektir. Şüpheye düştüğünüzde, temizlemeden önce volumeları yedekleyin.

Adım 3: Docker Log Dosyası Tükenmesini Yönetin

Container log’ları fark ettirmeden muazzam miktarda disk alanı tüketebilir; bazen container başına 50 GB’ı aşabilir.

Şişmiş log dosyalarını belirleyin

Docker’ın varsayılan json-file logging sürücüsü tüm container stdout ve stderr çıktısını JSON dosyalarına yakalar. Bir azami boyut ayarı olmadan (varsayılan -1, sınırsız), bu dosyalar sınırsız büyür.

Tüm ortamlarda container boyutlarını kontrol edin:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"Altyapı:

Belirli bir container’ın log dosyası boyutunu kontrol etmek için:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)Altyapı:

Yalnızca yerel Linux için, en büyük log dosyalarını doğrudan bulun:

sudo find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} + | sort -h | tail -10Altyapı:

docker logs yavaşlarsa veya container’lar başlatılamazsa, aşırı büyük log’lar muhtemel nedendir. Bunu çözmek için log’ları kısaltabilirsiniz.

Log’ları güvenle kısaltın

Log’ları kısaltmak alanı geri kazandırır. Ancak container’lar çalışırken rm ile log dosyalarını asla silmeyin. Docker daemon bu log’lara açık dosya tanıtıcıları tutar ve onları silmek, daemon yeniden başlatılana kadar alan tüketmeye devam eden “silinmiş ama açık” dosyalar oluşturur.

Güvenli yaklaşım, log’ları sıfıra kısaltmaktır:

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container-name>)Altyapı:

Bu, dosya tanıtıcılarını bozmadan alanı anında serbest bırakır. Container aynı dosyaya log yazmaya devam eder.

Adım 4: İleri Düzey Sorun Giderme ve Gizli Sorunlar

Standart temizleme başarısız olduğunda, şu daha nadir ancak aynı derecede etkili sorunlardan biriyle uğraşıyor olabilirsiniz:

• Inode tükenmesi: Boş disk alanı olmasına rağmen dosya metadata yapılarının bitmesi

• Silinmiş ama açık dosyalar: Süreçlerin, silinmiş dosyalara açık dosya tanıtıcıları tutması ve “hayalet” alan kullanımı oluşturması

• Docker Desktop sanal disk şişmesi: VM içinde veri sildikten sonra ana .raw veya .vhdx dosyası küçülmez

Bu senaryoların her birini sistematik olarak ele alalım.

Inode tükenmesini çözün

Bu durum, PHP oturumları, npm node_modules veya inode’ları korkutucu hızda tüketen build artıkları gibi uygulamaların milyonlarca küçük dosya oluşturmasından kaynaklanabilir.

Önce inode tükenmesini doğrulayın:

df -iAltyapı:

Docker komutlarını kullanarak (tüm ortamlar):

docker ps -a | wc -l             # Container sayısını kontrol edin
docker images | wc -l         # İmaj sayısını kontrol edin
docker image prune -a      # Inode’ları boşaltmak için kullanılmayan imajları kaldırınAltyapı:

Linux kurulumları için inode yoğun dizinleri belirleyin:

for dir in /var/lib/docker/*/; do
    echo "$dir: $(sudo find $dir -type f 2>/dev/null | wc -l) files"
doneAltyapı:

docker rmi ile kullanılmayan imajları kaldırmak da inode’ları boşaltır. Uygulama düzeyindeki sorunlar için, container içinde temizlik uygulayın veya geçici dosyalar için volume mount’ları kullanın.

Silinmiş ama açık dosyaları yönetin (yalnızca Linux)

Bir dosya, bir süreç tarafından hâlâ açıkken silindiğinde, dosya sistemi süreç dosya tanıtıcısını kapatana kadar alanı serbest bırakmaz (“hayalet” alan kullanımı).

Linux kullanıcıları, açık dosyalar listesinde “deleted” girdilerini arayarak bunun olup olmadığını doğrulayabilir.

Önce bu dosyaları tespit edin:

sudo lsof | grep deleted Altyapı:

Silinmiş Docker dosyaları

Ardından, alanı serbest bırakmak için ilgili süreci (PID’yi lsof çıktısından kullanarak) veya Docker’ı yeniden başlatın. Bunu yaptıktan sonra komutu yeniden çalıştırırsanız, dosyalar artık görünmeyecektir; bu da düzgün şekilde kaldırıldıkları anlamına gelir.

Şimdi yalnızca Docker Desktop’a özgü olan son ileri düzey sorun giderme stratejisini inceleyelim: sanal disklerin yönetimi.

Docker Desktop sanal disklerini yönetme

Docker Desktop, verileri dinamik olarak büyüyen ancak siz VM içinde veri sildiğinizde otomatik olarak küçülmeyen bir sanal disk dosyasında (Mac’te .raw, Windows’ta .vhdx) saklar. İmajları ve container’ları temizler, VM içindeki boş alanın arttığını görürsünüz; ancak ana makine diskiniz dolu kalır.

Bunu yönetmek için en güvenli yaklaşım, verileri kaybetmeden diski sıkıştırmak üzere fstrim kullanmaktır:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /Altyapı:

Bu komut, Docker Desktop VM’in dosya sistemini kırpar ve kullanılmayan blokları ana sisteminize geri verir. İmajlarınız, container’larınız ve volumelarınız aynen kalır.

Alternatif olarak, tamamen sıfırdan başlamak isterseniz (bu tüm verileri siler), Docker Desktop Settings → Troubleshoot → Reset to factory defaults seçeneğini kullanın. 

Uyarı: Bu yıkıcı bir işlemdir ve tüm imajları, container’ları, volumeları ve ayarları kaldırır. Yalnızca diğer her şey başarısız olursa son çare olarak kullanılmalıdır.

Fabrika ayarlarına sıfırla

Adım 5: Docker “Aygıtta Yer Kalmadı” Hatasını Önleyin

Artık acil krizi çözdüğümüze göre, tekrarı önlemek için yapısal değişiklikler uygulayalım. Bu yapılandırmalar planlama gerektirir ancak sistem kararlılığına büyük katkı sağlar.

Docker kök dizinini taşıyın (yalnızca Linux)

Docker Desktop kullanıcıları veri kökü konumunu kolayca değiştiremez. Bunun yerine şunları yapabilirsiniz:

• Disk alanını artırın: Adım 4’te açıklanan sanal disk sıkıştırma yöntemlerini kullanın

• WSL2 arka ucu için: Docker Desktop Settings → Resources bölümünde gösterildiği gibi bir .wslconfig dosyasıyla sınırları yönetin

Bununla birlikte, Linux’taysanız ve kök bölümünüz kısıtlıysa ama daha büyük bir bölüm mevcutsa (belki ayrılmış bir veri diski), Docker’ın veri dizinini taşımak kalıcı bir çözümdür.

Önce Docker’ı durdurun:

sudo systemctl stop dockerAltyapı:

/etc/docker/daemon.json dosyasını düzenleyerek yeni konumu belirtin:

{
  "data-root": "/mnt/docker-data"
}Altyapı:

Mevcut verileri taşıyarak imajlarınızı ve container’larınızı koruyun:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/Altyapı:

Son olarak Docker’ı yeniden başlatın:

sudo systemctl start dockerAltyapı:

Docker artık tüm verileri yeni konumda saklar. Yeni dizin yolunu doğrulamak için docker info | grep "Docker Root Dir" ile kontrol edin.

Genel log döndürmeyi yapılandırın

Log döndürme, uyguladığım en etkili önleme stratejisidir. Varsayılan olarak Docker’ın json-file sürücüsünde max-size: -1 (sınırsız) bulunur; bu da üretimde yaşanacak bir felaketin habercisidir.

Yerel Linux kurulumları için, küresel sınırları zorlamak üzere /etc/docker/daemon.json dosyasını düzenleyin:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Altyapı:

Dosyayı düzenledikten sonra Docker’ı yeniden başlatın.

Docker Desktop kullanıcıları için /etc/docker/daemon.json’ı doğrudan düzenlemezsiniz. Bunun yerine:

1. Docker Desktop’ı açın
2. Settings → Docker Engine’e gidin
3. Daemon yapılandırmasının bulunduğu bir JSON düzenleyici göreceksiniz
4. Mevcut JSON’a log döndürme ayarlarını ekleyin:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Altyapı:

Son olarak Apply & Restart’a tıklayın.

Bu örnek yapılandırma, her container’ı 10 MB’lık üç log dosyasıyla sınırlar (container başına toplam 30 MB).

Kritik not: Bu ayarlar yalnızca yeni oluşturulan container’lara uygulanır. Mevcut container’lar özgün log yapılandırmalarını korur. Yeni sınırları uygulamak için container’ları yeniden oluşturmalısınız.

Daha iyi sıkıştırma ve performans için local logging sürücüsünü de düşünebilirsiniz:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}Altyapı:

Ayrıca, docker-compose.yml içinde hizmet başına log ayarlarını geçersiz kılabilirsiniz:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"Altyapı:

Bakımı otomatikleştirin

Bir diğer iyi uygulama da bazı süreçleri otomatikleştirmektir. Sıklıkla söylendiği gibi, önleme kriz yönetiminden daha iyidir. Bu nedenle, bakım pencerelerinde çalışan bir cron göreviyle temizlemeyi otomatikleştirmenizi öneririm:

# Create a cleanup script
sudo cat > /usr/local/bin/docker-cleanup.sh << 'EOF'
#!/bin/bash
docker system prune -f
docker builder prune -f --filter "until=168h"
EOF

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# Add to crontab to run weekly on Sundays at 2 AM
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -Altyapı:

Bu betik, her pazar günü saat 02:00’de durdurulmuş container’ları ve kullanılmayan verileri otomatik olarak kaldıran planlı bir görev oluşturur. Ayrıca disk kullanımının süresiz büyümesini önlemek için bir haftadan (168 saat) eski build önbellek katmanlarını güvenle temizler.

Buna ek olarak, imaj boyutlarını en aza indirmek için çok aşamalı build’lerle Dockerfile’larınızı optimize edin. Çok aşamalı build’ler, bir aşamada derleme ve oluşturma (tüm ağır geliştirme araçlarıyla) yapmanıza ve ardından yalnızca nihai çıktıları temiz, minimal bir üretim aşamasına kopyalamanıza olanak tanır. 

Bu, nihai imajınızdan build bağımlılıklarını, kaynak kodunu ve ara dosyaları çıkararak boyutu ve saldırı yüzeyini önemli ölçüde azaltır.

# Build stage
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]Altyapı:

Bu desen, build araçlarını ve kaynak kodunu hariç tutarak üretim imaj boyutunu azaltır.

Sonuç

"Aygıtta yer kalmadı" hatasını düzeltmek öngörülebilir bir kalıbı izler: Önce teşhis ederek disk blokları mı yoksa inode’larla mı uğraştığınızı anlayın, ardından verileri kaybetmeden alanı geri kazanmak için güvenle temizleyin ve son olarak tekrarı önlemek için yapılandırmayı optimize edin.

Docker ortamlarını yıllarca yönetirken öğrendiğim, en etkili önleme stratejisinin log döndürme olduğudur. Basit bir daemon.json yapılandırması, alan tükenmesi olaylarının çoğunu önleyebilir.

Şimdi daemon.json yapılandırmanızı denetlemenizi öneririm. Logging sürücünüz için max-size ve max-file ayarları yoksa, bunları hemen ekleyin. Bir sonraki alan krizinden kaçındığınızda gelecekteki kendiniz size teşekkür edecektir.

Bir Docker uzmanı olmaya hazır mısınız? O hâlde bir sonraki adım, şiddetle önerdiğim Docker ve Kubernetes ile Containerization ve Virtualization beceri yoluna kaydolmaktır.