Docker Build Bağlamı: Docker İmajları İçin Kapsamlı Bir Rehber

Docker imajları oluştururken karşılaşılan en temel ama çoğu zaman göz ardı edilen konulardan biri, Docker build bağlamıdır. Peki, bu kavram tam olarak ne anlama geliyor ve Dockerfile’ınızla birlikte projelerinizin performansını, güvenliğini ve taşınabilirliğini nasıl doğrudan etkiliyor? Bu rehberde, Docker build bağlamının derinliklerine inecek, etkili yönetim stratejilerini keşfedecek ve gerçek dünya senaryolarıyla uygulamalı optimizasyon tekniklerini öğreneceksiniz. Başlangıç seviyesinden ileri düzeye kadar her okuyucunun faydalanabileceği bu kapsamlı kılavuzla, Docker imajlarınızı bir üst seviyeye taşıyın.

Bir aşçı, lezzetli bir yemek yapmak için elinin altındaki tüm malzemelere ihtiyaç duyar. Docker dünyasında da imaj oluşturma süreci benzer bir prensiple işler: Docker Daemon, imajı inşa etmek için ihtiyaç duyduğu tüm dosyalara ve dizinlere erişebilmelidir. İşte “Docker build bağlamı” tam da bu noktada devreye girer. Bağlam, docker build komutunu çalıştırdığınız dizin (veya belirttiğiniz bir dizin) ile bu dizin altındaki tüm alt dizin ve dosyaların tamamını ifade eder. Başka bir deyişle, Docker Daemon’ına gönderilen ve imaj oluşturma sürecinde kullanılabilecek olan dosya ve dizin kümesidir.

Bu kavramın önemi birkaç temel noktada yatar. İlk olarak, performansı doğrudan etkiler. Eğer build bağlamınız gereksiz yere büyükse, yani imajınızda kullanmayacağınız binlerce dosya veya gigabaytlarca veri içeriyorsa, Docker Daemon’a gönderilen veri miktarı artar. Bu durum, özellikle uzak bir Docker Daemon kullanıldığında (örneğin, bir CI/CD sistemi veya buluttaki bir sunucu), build süresini önemli ölçüde uzatır. Çünkü tüm bu gereksiz verinin ağ üzerinden transfer edilmesi gerekir.

İkinci olarak, güvenlik açısından kritik bir rol oynar. Projenizin kaynak kodları arasında hassas veriler (API anahtarları, parolalar, kişisel veri içeren dosyalar vb.) bulunabilir. Eğer bu dosyalar bilmeden build bağlamına dahil edilirse ve Dockerfile’ınızda bu dosyaları imaj içine kopyalayan bir komut varsa, bu hassas veriler nihai Docker imajınıza sızabilir. Ortaya çıkan imaj, başkaları tarafından incelendiğinde veya kullanıldığında ciddi güvenlik riskleri oluşturabilir. Bu nedenle, build bağlamını dikkatli bir şekilde yönetmek, uygulamalarınızın ve verilerinizin güvenliği için olmazsa olmazdır.

Son olarak, imajın yeniden üretilebilirliği ve taşınabilirliği açısından da bağlamın önemi büyüktür. Dockerfile’ınızda COPY . . gibi genel komutlar kullandığınızda, bağlamınızda bulunan her şey imaja kopyalanır. Bu, farklı geliştirme ortamlarında veya farklı build makinelerinde bağlamın içeriği değişirse, aynı Dockerfile ile aynı imajı elde etme garantisini zayıflatabilir. Bağlamın net ve minimal olması, tutarlı ve öngörülebilir imajlar oluşturmanıza yardımcı olur. Dolayısıyla, bir Docker imajının sağlam temeller üzerinde yükselmesi için build bağlamının doğru bir şekilde anlaşılması ve yönetilmesi şarttır.

Docker Build Bağlamını Nasıl Etkili Yönetiriz? Temel Uygulamalar

Docker build bağlamını etkili bir şekilde yönetmek, genellikle docker build komutunun nasıl kullanıldığı ve Dockerfile’ın içeriğiyle yakından ilişkilidir. Komut satırında docker build çalıştırdığınızda, genellikle sonuna bir yol veya . (nokta) eklersiniz. Bu nokta, mevcut dizinin build bağlamı olarak kullanılacağını belirtir. Yani, Docker Daemon’a gönderilecek olan tüm dosya ve dizinler, bu noktadan itibaren taranır.

COPY ve ADD gibi Dockerfile komutları, build bağlamından dosya veya dizinleri alıp imajın dosya sistemine kopyalamak için kullanılır. Örneğin, COPY ./src /app/src komutu, build bağlamındaki src dizinini alıp imaj içindeki /app/src dizinine yerleştirir. Eğer ./src dizini build bağlamında yoksa, Docker bu komutu çalıştırırken hata verir. Bu nedenle, Dockerfile’ınızdaki her COPY veya ADD komutunun kaynak yolunun build bağlamında gerçekten var olduğundan emin olmalısınız.

İşte basit bir Node.js uygulamasını Dockerize etmek için bir örnek. Proje yapısı şöyle olsun:

• my-node-app/
  • Dockerfile
  • package.json
  • package-lock.json
  • app.js
  • node_modules/ (Bu dizini imaja dahil etmek istemeyiz)

Bu senaryoda, my-node-app dizininde docker build . komutunu çalıştırdığımızda, bu dizin ve altındaki her şey build bağlamına dahil edilir. Ancak biz node_modules klasörünü imaja kopyalamak istemeyiz, çünkü npm install komutuyla zaten imaj içinde bağımlılıkları yeniden kuracağız. Bu, hem imaj boyutunu gereksiz yere artırır hem de build süresini uzatır.

İlk olarak, basit bir Dockerfile örneği:

# Dockerfile
FROM node:16-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
    

Bu Dockerfile, önce package.json dosyalarını kopyalar, sonra bağımlılıkları yükler ve son olarak kalan tüm proje dosyalarını (COPY . . ile) kopyalar. Ancak bu son komut, node_modules dizinini de (eğer varsa) kopyalamaya çalışacaktır. İşte bu noktada .dockerignore dosyasının gücünden faydalanırız.

Build işlemini tetiklemek için aşağıdaki komutu kullanabiliriz:

# Terminal
docker build -t my-node-app .
    

Bu komut, mevcut dizindeki her şeyi (gizli dosyalar dahil) Docker Daemon'a gönderir. Daha verimli bir build süreci ve daha küçük imajlar için bu bağlamı kontrol altında tutmak elzemdir. Bir sonraki bölümde .dockerignore dosyasının bu süreçteki rolünü inceleyeceğiz.

.dockerignore Dosyası: Gereksiz Dosyaları Bağlamdan Nasıl Dışlarız?

Docker build bağlamını optimize etmenin en güçlü yollarından biri, .dockerignore dosyasını kullanmaktır. Bu dosya, tıpkı .gitignore dosyası gibi çalışır, ancak amacı farklıdır: Docker Daemon'a gönderilecek olan dosya ve dizinler arasından hangilerinin hariç tutulacağını Docker'a bildirir. Bu sayede, gereksiz verilerin ağ üzerinden transfer edilmesi ve Docker imajına kopyalanması engellenir, bu da build sürelerini kısaltır ve nihai imaj boyutunu küçültür.

.dockerignore dosyasının çalışma prensibi oldukça basittir. Build işlemi başlamadan önce, Docker Client belirtilen bağlam dizinini tarar ve bu dosyadaki kurallara uyan her şeyi bağlamdan çıkarır. Ardından kalan dosyaları sıkıştırılmış bir tar arşivi olarak Docker Daemon'a gönderir. Bu, özellikle büyük projelere sahip geliştiriciler için hayat kurtarıcı bir özelliktir. Örneğin, Node.js projelerinde node_modules dizini, Python projelerinde __pycache__ veya sanal ortam dizinleri (venv), Java projelerinde target dizinleri genellikle binlerce dosya içerir ve onlarca hatta yüzlerce megabayt yer kaplayabilir. Bu dosyaları bağlamdan dışlamak, hem ağ trafiğini azaltır hem de Docker Daemon'ın bu dosyaları işlemek zorunda kalmamasını sağlar.

.dockerignore dosyası, güvenlik açısından da kritik bir rol oynar. Geliştirme ortamınızda bulunan .env dosyaları, yerel konfigürasyon dosyaları, veritabanı yedeği gibi hassas bilgileri içeren dosyalar yanlışlıkla Docker imajına sızabilir. Bu tür dosyaları .dockerignore listesine eklemek, potansiyel güvenlik açıklarını önler.

İşte yukarıdaki Node.js uygulaması için tipik bir .dockerignore dosyası örneği:

# .dockerignore
node_modules
npm-debug.log
.git
.env
Dockerfile
.vscode/
temp/
    

Bu örnekte:

• node_modules: Bağımlılıklar imaj içinde yeniden kurulacağı için dışlanır.
• npm-debug.log: Hata ayıklama günlükleri, imaj için gereksizdir.
• .git: Git versiyon kontrol sistemi dosyaları, imaj içinde olmamalıdır.
• .env: Ortam değişkenleri içeren hassas dosya, imaja sızmamalıdır.
• Dockerfile: Zaten Docker Daemon tarafından okunur, imaja kopyalanmasına gerek yoktur.
• .vscode/: Geliştirme ortamı konfigürasyonları.
• temp/: Geçici dosyaların bulunduğu bir dizin.

Bu şekilde, yalnızca uygulamanın çalışması için gerçekten gerekli olan dosyalar build bağlamına dahil edilmiş olur. Bu dosyanın doğru kullanımı, Docker imajı oluşturma sürecinizin verimliliğini ve güvenliğini önemli ölçüde artırır. Bu optimizasyon, özellikle büyük ölçekli ve çok sayıda bağımlılığı olan projelerde belirgin bir fark yaratır.

Gerçek Dünya Senaryolarında Docker Build Bağlamı Optimizasyonu: Bir Vaka Analizi

Büyük ve karmaşık projelerle çalışırken, Docker build bağlamını optimize etmek bir zorunluluk haline gelir. Monorepolar (tek bir depoda birden fazla projenin bulunduğu yapılar) veya legacy projeler, genellikle gereksiz yere büyük build bağlamlarına yol açar. Gelin, frontend ve backend uygulamalarının aynı Git deposunda bulunduğu bir monorepo senaryosunu ele alalım. Proje yapımız şöyle olsun:

my-monorepo/
├── frontend/
│   ├── src/
│   ├── public/
│   ├── package.json
│   └── ...
├── backend/
│   ├── src/
│   ├── requirements.txt
│   └── ...
├── .dockerignore
└── Dockerfile.multistage
    

Bu yapıda, hem frontend hem de backend için Docker imajları oluşturmamız gerekiyor. Eğer my-monorepo dizininde docker build . komutunu kullanıp tek bir Dockerfile yazarsak, tüm monorepo dizini build bağlamına dahil edilecek ve bu da muazzam bir veri transferine neden olacaktır. Oysa frontend imajı sadece frontend dizinine, backend imajı ise sadece backend dizinine ihtiyaç duyar. Bu durumda, çok aşamalı build (multi-stage build) ve spesifik COPY komutları devreye girer.

Aşağıdaki Dockerfile.multistage örneği, bu senaryoda bağlam optimizasyonunu nasıl gerçekleştirebileceğimizi gösteriyor:

# Dockerfile.multistage

# 1. Frontend Uygulamasını Oluşturma Aşaması
FROM node:16-alpine as frontend-builder
WORKDIR /app/frontend
# Sadece frontend'in package.json dosyalarını kopyala
COPY ./frontend/package*.json ./
RUN npm install
# Sadece frontend dizinindeki diğer dosyaları kopyala
COPY ./frontend .
RUN npm run build

# 2. Backend Uygulamasını Oluşturma Aşaması (Örnek Python)
FROM python:3.9-slim-buster as backend-builder
WORKDIR /app/backend
# Sadece backend'in requirements.txt dosyasını kopyala
COPY ./backend/requirements.txt ./
RUN pip install -r requirements.txt
# Sadece backend dizinindeki diğer dosyaları kopyala
COPY ./backend .

# 3. Nihai Üretim İmajı Aşaması (Örnek Nginx ile sunum)
FROM nginx:stable-alpine
# Frontend'in build edilmiş çıktılarını kopyala
COPY --from=frontend-builder /app/frontend/build /usr/share/nginx/html
# Backend uygulamasını kopyala
COPY --from=backend-builder /app/backend /var/www/backend
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
    

Bu Dockerfile, tek bir docker build . komutu ile tüm monoreponun bağlam olarak gönderilmesini gerektirir, ancak kritik fark, COPY komutlarının sadece ilgili alt dizinleri hedeflemesidir (./frontend/package*.json yerine ./frontend/package*.json gibi). Bu sayede, her aşamada yalnızca o aşamanın ihtiyaç duyduğu dosyalar kopyalanır ve gereksiz dosyaların ara katmanlara dahil edilmesi engellenir.

Özellikle COPY ./frontend . gibi komutlar yerine, COPY ./frontend/src ./src şeklinde daha spesifik yollar kullanarak da build bağlamını gönderdikten sonra kopyalanan dosyaların miktarını azaltabiliriz. Ancak .dockerignore, daha en başta Docker Daemon'a gönderilen veri miktarını kontrol ettiği için daha önceliklidir. Bu çok aşamalı build stratejisi, nihai imajın boyutunu küçültürken aynı zamanda farklı bileşenlerin bağımsız olarak inşa edilmesini sağlar, böylece build süreçleri daha hızlı ve verimli hale gelir. Unutulmamalıdır ki, .dockerignore dosyası her zaman en üst seviyede, yani my-monorepo/ dizininde olmalı ve tüm projeyi kapsayan genel kuralları içermelidir.

Build Bağlamı ve Performans İlişkisi: Nasıl Daha Hızlı Docker İmajları Oluştururuz?

Docker imaj oluşturma süreci, karmaşık bir dans gibidir ve bu dansın ritmi, build bağlamının boyutuna ve içeriğine göre değişir. Hızlı ve verimli bir build süreci için build bağlamını optimize etmek, adeta gizli bir silahtır. Performans, genellikle iki ana faktör üzerinden etkilenir: ağ transferi ve Docker Daemon'ın disk üzerindeki işlem yükü.

İlk olarak, ağ transferi. docker build komutunu çalıştırdığınızda, Docker Client belirtilen build bağlamını (.dockerignore kuralları uygulandıktan sonra) sıkıştırır ve Docker Daemon'a gönderir. Eğer bağlamınızda gigabaytlarca veri varsa, bu veri transferi build sürecinin en yavaş adımı olabilir. Özellikle uzak bir sunucuda çalışan bir Docker Daemon ile çalışıyorsanız (örneğin, bulut tabanlı CI/CD servisleri), bu gecikme daha da belirginleşir. Bu yüzden, .dockerignore dosyasını titizlikle kullanarak gereksiz dosyaları en baştan elemek, ağ yükünü minimize etmenin anahtarıdır.

İkinci olarak, Docker Daemon'ın disk üzerindeki işlem yükü ve katmanlama (layering) mekanizması. Docker imajları katmanlar halinde inşa edilir. Dockerfile'daki her bir komut (FROM, RUN, COPY vb.) genellikle yeni bir katman oluşturur. Docker, bir katman değişmediği sürece onu yeniden inşa etmek yerine önbellekten (cache) kullanır. Bu önbellekleme mekanizması, build sürelerini dramatik şekilde kısaltabilir. Ancak, COPY . . gibi bir komutla bağlamın tamamını kopyaladığınızda ve bu bağlamdaki tek bir dosya bile değişse, Docker o katmandan sonraki tüm katmanları yeniden inşa etmek zorunda kalır. Bu da önbellekleme faydasını ortadan kaldırır.

Peki, daha hızlı imajlar oluşturmak için ne yapmalıyız?

1. Minimal .dockerignore: Yukarıda da belirttiğimiz gibi, build bağlamına sadece gerçekten gerekli olan dosyaları dahil edin. Büyük bağımlılık dizinlerini (node_modules, venv, target), geçici dosyaları, versiyon kontrol sistemlerine ait dizinleri (.git) ve hassas verileri mutlaka dışlayın.
2. COPY Komutlarının Stratejik Sıralanması: En az değişen dosyaları (örneğin, package.json, requirements.txt gibi bağımlılık tanımlama dosyaları) Dockerfile'ın üst kısımlarına, yani değişme olasılığı en düşük olan komutlardan hemen sonraya yerleştirin. Böylece, bu dosyalar değişmedikçe, bağımlılık kurulumu gibi zaman alıcı RUN komutları önbellekten kullanılır.
3. Belirli Dosya ve Dizinleri Kopyalama: Mümkünse, COPY . . yerine COPY ./src /app/src veya COPY ./configs /etc/app/configs gibi daha spesifik kopyalama komutları kullanın. Bu, belirli bir dizindeki değişikliklerin yalnızca o dizinle ilgili katmanı geçersiz kılmasını sağlar, tüm uygulama katmanlarını değil.
4. Çok Aşamalı Build (Multi-Stage Builds): Gereksiz build araçlarını ve ara dosyaları nihai imajdan ayırmak için çok aşamalı build'leri kullanın. Bu, hem imaj boyutunu küçültür hem de build bağlamının daha modüler yönetilmesine olanak tanır.

Uzman İpucu: Build performansını ölçmek için docker build --no-cache ... ve ardından normal docker build ... komutlarını çalıştırın. Aradaki fark, önbellekleme stratejinizin ne kadar etkili olduğunu gösterir. Ayrıca, docker history komutu ile katman boyutlarını inceleyebilir ve hangi katmanların gereksiz yer kapladığını tespit edebilirsiniz.

Bu stratejileri uygulayarak, Docker build süreçlerinizi önemli ölçüde hızlandırabilir ve daha verimli imajlar elde edebilirsiniz. Unutmayın, iyi yönetilmiş bir build bağlamı, sadece hızlı build süreleri değil, aynı zamanda daha küçük ve güvenli imajlar anlamına da gelir.

Build Bağlamı Güvenliği: Hassas Verileri İmajlara Sızdırmamak İçin Neler Yapmalıyız?

Docker imaj güvenliği, modern uygulama geliştirme ve dağıtım süreçlerinin vazgeçilmez bir parçasıdır. Build bağlamının doğru yönetilmemesi, hassas verilerin yanlışlıkla nihai imajlara sızmasına neden olabilir, bu da ciddi güvenlik açıklarına yol açar. API anahtarları, veritabanı parolaları, özel sertifikalar veya diğer kişisel tanımlayıcı bilgiler gibi kritik verilerin imaj içine gömülmesi, uygulamanızın ve kullanıcılarınızın güvenliğini tehlikeye atar.

Bu tür sızıntıları önlemek için uygulanabilecek temel stratejiler bulunmaktadır:

1. .dockerignore Dosyasının Kapsamlı Kullanımı: Bu, hassas dosyaları build bağlamından dışlamanın ilk ve en önemli adımıdır. .env dosyaları, yerel konfigürasyon dosyaları, SSH anahtarları (eğer yanlışlıkla proje dizinindeyse), veritabanı yedekleri ve diğer gizli bilgileri içeren tüm dosyaları .dockerignore listesine eklemelisiniz. Bu, bu dosyaların Docker Daemon'a bile gönderilmemesini sağlar.
2. Çok Aşamalı Build'lerin Güvenlik Faydaları: Çok aşamalı build'ler, sadece imaj boyutunu küçültmekle kalmaz, aynı zamanda güvenlik açısından da önemli avantajlar sunar. İlk aşamalarda (build aşaması) hassas verileri kullanarak derleme veya test yapabilir, ancak bu verileri son, üretim aşaması imajına kopyalamayarak nihai imajın temiz kalmasını sağlayabilirsiniz. Örneğin, API anahtarlarını bir build argümanı olarak kullanıp, sadece build sırasında erişilmesini sağlayabilir, ancak final imajına gömmeyebilirsiniz.
3. Build Argümanları (--build-arg) ve Ortam Değişkenleri: Hassas bilgiler için --build-arg komutunu kullanarak ortam değişkenlerini Dockerfile'a aktarabilirsiniz. Ancak, bu argümanlar Docker imajının geçmişinde (docker history) görünür olabileceğinden, kritik hassasiyetteki veriler için dikkatli kullanılmalıdır. Daha güvenli bir yaklaşım, bu değerleri Dockerfile içerisinde ARG ile tanımlayıp, ENV ile kalıcı hale getirmemektir. Bunun yerine, uygulama çalışma zamanında (runtime) ortam değişkenleri olarak verilmelidir.
4. Docker BuildKit Secrets: Modern Docker sürümleri, BuildKit adı verilen yeni bir imaj oluşturma motoruyla birlikte gelir. BuildKit, hassas verileri (secrets) daha güvenli bir şekilde yönetmek için yerleşik destek sunar. --secret bayrağını kullanarak, dosyaları veya ortam değişkenlerini Docker Daemon'a göndermeden, sadece build aşamasında Dockerfile'ınızda erişilebilir hale getirebilirsiniz. Bu veriler imajda kalıcı olmaz ve docker history'de görünmez.

BuildKit ile secret kullanımı için örnek bir komut:

# BuildKit'i etkinleştirin ve secret kullanarak imajı oluşturun
DOCKER_BUILDKIT=1 docker build --secret id=mysecret,src=./.env . -t myapp
    

Ve ilgili Dockerfile parçası:

# Dockerfile
# BuildKit ile secret kullanmak için syntax tanımı
# syntax=docker/dockerfile:1.4

FROM alpine
WORKDIR /app
# 'mysecret' adındaki secret'ı /run/secrets/mysecret dosyasına bağla
RUN --mount=type=secret,id=mysecret,dst=/run/secrets/mysecret \
    cat /run/secrets/mysecret > /tmp/secret_output.txt

# UYARI: Bu örnek sırrı bir dosyaya yazar. Gerçek uygulamalarda doğrudan kullanın
# ve nihai imaja dahil etmeyin.
# Sadece demo amaçlıdır. Nihai imajda bu dosya olmamalıdır.
    

Bu, secret'ın sadece build aşamasında erişilebilir olmasını ve nihai imaja dahil edilmemesini sağlar. BuildKit kullanmak, özellikle hassas verilerle çalışırken en güvenli yaklaşımlardan biridir.

Son olarak, hiçbir hassas verinin doğrudan Dockerfile içine hard-code edilmemesi gerektiğini unutmayın. Bu tür bilgiler her zaman çalışma zamanında (runtime) ortam değişkenleri, Kubernetes Secrets veya Docker Swarm Secrets gibi güvenli yöntemlerle uygulamaya enjekte edilmelidir. Build bağlamı güvenliğini ciddiye almak, uygulamanızın genel güvenlik duruşunu önemli ölçüde güçlendirecektir.

Sıkça Sorulan Sorular (SSS)

Docker build bağlamını anlamak, daha verimli, güvenli ve performanslı imajlar oluşturmanın temelidir. Bu makalede ele aldığımız konular, bağlamın ne olduğu, neden önemli olduğu, .dockerignore kullanımı, çok aşamalı build'lerle optimizasyon ve güvenlik stratejileri üzerine odaklandı. Doğru yaklaşımlarla, Docker imaj oluşturma süreçlerinizi çok daha sağlam hale getirebilirsiniz. Şimdi, konuyu pekiştirmek için sıkça sorulan bazı sorulara göz atalım.

1. Build bağlamı ve çalışma dizini (WORKDIR) arasındaki fark nedir?

   Build bağlamı, docker build komutunu çalıştırdığınızda Docker Daemon'a gönderilen, ana bilgisayarınızdaki (host machine) tüm dosya ve dizin kümesidir. Yani, Docker'ın imajı inşa etmek için erişebileceği tüm kaynakları temsil eder. Çalışma dizini (WORKDIR) ise, Dockerfile içinde WORKDIR /app gibi bir komutla belirlenen, imajın dosya sistemi içindeki bir dizindir. RUN, CMD, ENTRYPOINT, COPY ve ADD gibi komutlar, WORKDIR içinde göreceli yolları kullanarak işlem yapar. Kısacası, bağlam kaynakları host'tan Daemon'a gönderirken, WORKDIR bu kaynakların imaj içinde nereye kopyalanacağını veya hangi dizinde işlem yapılacağını belirtir.

2. .dockerignore dosyası yoksa ne olur?

   Eğer bir .dockerignore dosyası yoksa, docker build . komutunu çalıştırdığınızda, mevcut dizindeki tüm dosyalar ve alt dizinler (.git gibi bazı özel durumlar dışında) build bağlamına dahil edilir ve Docker Daemon'a gönderilir. Bu durum, genellikle gereksiz yere büyük veri transferine ve daha yavaş build sürelerine yol açar. Ayrıca, projenizde bulunan hassas dosyaların veya büyük bağımlılık klasörlerinin (node_modules, venv vb.) imajınıza sızma riskini artırır, bu da imaj boyutunu şişirir ve güvenlik açıklarına neden olabilir.

3. Uzak bir URL'den build bağlamı alabilir miyim?

   Evet, Docker, build bağlamını uzak bir Git deposundan da alabilir. Bunun için docker build komutunu kullanmanız yeterlidir. Örneğin, docker build https://github.com/docker/rootfs.git#container:docker. Bu durumda, Docker belirtilen Git deposunu klonlar ve klonlanan deponun kök dizinini build bağlamı olarak kullanır. Eğer Git deposunda bir .dockerignore dosyası varsa, bu kurallar da uygulanır. Bu özellik, özellikle CI/CD senaryolarında veya paylaşılan Dockerfile'ları kullanırken oldukça faydalıdır.

4. Docker build bağlamında performans düşüşünü nasıl tespit ederim?

   Performans düşüşünü tespit etmek için birkaç yöntem vardır:

   • Build Süresi Analizi: docker build komutunun çıktısını dikkatle inceleyin. Her adımın ne kadar sürdüğünü gözlemleyin. Özellikle "Sending build context to Docker daemon" adımının uzun sürmesi, büyük bir bağlamınız olduğunu gösterir.
   • docker history: Oluşturduğunuz imajın katmanlarını docker history komutuyla inceleyin. Büyük boyutlu katmanlar, genellikle gereksiz dosyaların kopyalandığını veya verimli bir önbellekleme stratejisinin olmadığını işaret eder.
   • --progress=plain: Docker BuildKit ile DOCKER_BUILDKIT=1 docker build --progress=plain . komutunu kullanarak build adımlarının daha detaylı bir çıktısını alabilir, hangi adımın ne kadar sürdüğünü ve hangi katmanların önbellekten kullanıldığını daha net görebilirsiniz.
   • du -sh .: Build bağlamını göndermeden önce dizininizin boyutunu kontrol edin. .dockerignore uygulandıktan sonraki gerçek boyutu anlamak için temporer bir dizine kopyalayıp .dockerignore'u uygulayıp öyle kontrol edebilirsiniz.

5. Bir web sayfasını mobil uyumlu hale getirmek için temel bir media query örneği verir misiniz?

   Elbette. Docker build bağlamıyla doğrudan ilgili olmasa da, web geliştirmenin önemli bir parçası olan mobil uyumluluğu göstermek için temel bir CSS media query örneği aşağıdadır. Bu örnek, belirli bir ekran genişliğinin altında bir div'in rengini ve metin boyutunu nasıl değiştirebileceğinizi gösterir:

   
   
   
   
     
   Bu kutu, ekran genişliğine göre rengini ve boyutunu değiştirir.
   
               

   Bu örnekte, tarayıcı penceresinin genişliği 768 pikselin altına düştüğünde .responsive-box sınıfına sahip div'in arka plan rengi, metin rengi ve boyutu değişir. 480 pikselin altında ise daha da küçülür. Bu teknik, içeriğinizin farklı cihazlarda en iyi şekilde görünmesini sağlar.