Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Başlangıç problemi şudur: localde çalışan uygulama CI veya staging'de farklı runtime, dependency ya da build girdileriyle ayrışabilir. Karar sorusu da şudur: uygulamayı mevcut host runtime'ında mı bırakmalı, yoksa image ile container sınırında mı çalıştırmalıyız?
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
- Mevcut host runtime'ı başlangıç maliyetini düşürür; ortam drift'ini ekip takip eder.
- Image + container ortak bir build artefact'ı taşımayı kolaylaştırır; image, registry, güvenlik ve runtime bakımı gerekir.
- Compose ile local çoklu servis akışı tanımlanabilir; Compose her production orchestration veya ölçekleme ihtiyacını tek başına çözmez.
Bu seçenekler bağlama göre birlikte de kullanılabilir. Örneğin Compose localde, başka bir platform production'da kullanılabilir.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-007'de junior'ın localde çalışan uygulaması CI image build adımında başarısızdır. Log, Dockerfile'ın istediği dependency manifest'inin build context içinde bulunmadığını gösterir. Image üretilmediği için Staging job'ı başlamaz.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Junior “Docker bozuk” demek yerine commit, Dockerfile, context, .dockerignore, lock file ve CI çalışma dizinini karşılaştırır. Sonra image identity, runtime health/log ve hedef ortam koşullarını kontrol eder. Image build'inin başarılı olması, Staging veya Production davranışının doğrulandığı anlamına gelmez.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Containerization, image, container, Dockerfile, build context, registry, repository, tag, digest, Compose ve OCI terimlerini birbirinden ayırır.
- Açıkla: Image'ın artefact, container'ın çalışan örnek olduğunu; Docker'ın yaklaşımın kendisi değil araç bağlamı olduğunu anlatır.
- Uygula: CI image build hatasında commit, Dockerfile, context, ignore kapsamı, image kimliği, runtime sinyali ve hedef ortamı kanıtla karşılaştırır.
- Karar ver:
Karar → Kanıt → Sınırüçlüsü olmadan production'a çıkış kararı verilmez. - Şimdilik bilmesi gerekmeyen: Kubernetes cluster işletmek, container runtime yazmak veya kurum çapında image policy'si kurmak.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Bir uygulamanın “çalıştığı makine” yalnızca source code'dan oluşmaz. Runtime, işletim sistemi kütüphaneleri, dependency sürümleri, environment ayarları, architecture ve başlatma command'i sonucu etkileyebilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Bu girdileri açık bir build tanımına ve taşınabilir bir image'a bağlamak, local, CI, staging ve production arasındaki bazı varsayım farklarını azaltmaya yardım eder.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler build girdilerini tanımlı hâle getirmek ve aynı artefact'ı farklı ortamlarda incelemek için container yaklaşımını kullanabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Dockerfile image build adımlarını, build context builder'ın erişebildiği dosyaları, registry image saklama ve paylaşımını görünür kılar. Compose birden fazla service, network ve volume ile local uygulama modelini tanımlayabilir. OCI ise image, runtime ve distribution için vendor bağımsız standart sınırları gösterir.
Bunlar her ekibin zorunlu araçları değildir. Registry'de bir image bulunması, onun production'da çalıştığını veya güvenli olduğunu kanıtlamaz.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Image tanımı ve dependency'lerin açık olması tekrar üretilebilirliği kolaylaştırabilir. Bunun karşılığında image build süresi, registry depolama, cache, güvenlik güncellemesi, network, volume, secret ve gözlemlenebilirlik yönetimi gelir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Dockerfile ile build context aynı şey değildir. Tag okunabilir bir release adıdır ve değişebilir. Digest belirli image içeriğini sabitlemeye yardım eder; ancak güvenlik güncellemelerini otomatik takip etme kararını ekip yine vermelidir.
Container, VM'nin yalnızca daha hızlı adı değildir. İzolasyon ve kaynak sınırı host, runtime ve çalışma yapılandırmasıyla birlikte değerlendirilir. Bu yüzden aynı image kullanmak bazı build farklarını azaltır; network, storage, secret, architecture veya external service farklarını otomatik çözmez.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Docker, Containerization'ın kendisidir.” Eksik; Docker yaygın bir araç ve platform bağlamıdır, kavram daha geniştir.
- “Image ile container aynı şeydir.” Yanlış; image paketlenmiş artefact, container ise onun belirli çalışma örneğidir.
- “Container bir VM'dir.” Yanlış; izolasyon ve kaynak sınırları farklıdır; runtime ve host koşulları ayrıca incelenmelidir.
- “Localde image build olduysa Staging sağlıklıdır.” Yanlış; deployment, configuration, network, secret, dependency service ve runtime davranışı henüz doğrulanmamış olabilir.
- “Aynı tag her zaman aynı image'dır.” Güvenilmez; tag yeniden işaretlenebilir, immutable digest ise belirli image içeriğini ayırmak için kullanılır.
- “Compose Production için evrensel deployment standardıdır.” Yanlış; Compose bir uygulama modelidir ve kullanılan ortamın sınırları ayrıca belirlenir.
- “Registry'de image varsa deployment tamamdır.” Yanlış; registry saklama ve paylaşma yüzeyidir, hedef çalışma ortamı değildir.
- “Dockerfile image'ın kendisidir.” Yanlış; Dockerfile build talimatıdır, image onun sonucundaki artefact'tır.
- “Image build geçtiyse container sağlıklıdır.” Yanlış; runtime status, health, log, network, storage, secret ve dış servis kanıtları ayrıca incelenir.
Gerilim ve çözüm1. bölüm