{"id":33500,"date":"2025-11-03T17:01:41","date_gmt":"2025-11-03T14:01:41","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/docker-build-baglami-docker-imajlari-icin-kapsamli-bir-rehber\/"},"modified":"2025-11-03T17:01:41","modified_gmt":"2025-11-03T14:01:41","slug":"docker-build-baglami-docker-imajlari-icin-kapsamli-bir-rehber","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/docker-build-baglami-docker-imajlari-icin-kapsamli-bir-rehber\/","title":{"rendered":"Docker Build Ba\u011flam\u0131: Docker \u0130majlar\u0131 \u0130\u00e7in Kapsaml\u0131 Bir Rehber"},"content":{"rendered":"

<\/p>\n

Docker imajlar\u0131 olu\u015ftururken kar\u015f\u0131la\u015f\u0131lan en temel ama \u00e7o\u011fu zaman g\u00f6z ard\u0131 edilen konulardan biri, Docker build ba\u011flam\u0131d\u0131r. Peki, bu kavram tam olarak ne anlama geliyor ve Dockerfile’\u0131n\u0131zla birlikte projelerinizin performans\u0131n\u0131, g\u00fcvenli\u011fini ve ta\u015f\u0131nabilirli\u011fini nas\u0131l do\u011frudan etkiliyor? Bu rehberde, Docker build ba\u011flam\u0131n\u0131n derinliklerine inecek, etkili y\u00f6netim stratejilerini ke\u015ffedecek ve ger\u00e7ek d\u00fcnya senaryolar\u0131yla uygulamal\u0131 optimizasyon tekniklerini \u00f6\u011freneceksiniz. Ba\u015flang\u0131\u00e7 seviyesinden ileri d\u00fczeye kadar her okuyucunun faydalanabilece\u011fi bu kapsaml\u0131 k\u0131lavuzla, Docker imajlar\u0131n\u0131z\u0131 bir \u00fcst seviyeye ta\u015f\u0131y\u0131n.<\/p>\n

Bir a\u015f\u00e7\u0131, lezzetli bir yemek yapmak i\u00e7in elinin alt\u0131ndaki t\u00fcm malzemelere ihtiya\u00e7 duyar. Docker d\u00fcnyas\u0131nda da imaj olu\u015fturma s\u00fcreci benzer bir prensiple i\u015fler: Docker Daemon, imaj\u0131 in\u015fa etmek i\u00e7in ihtiya\u00e7 duydu\u011fu t\u00fcm dosyalara ve dizinlere eri\u015febilmelidir. \u0130\u015fte “Docker build ba\u011flam\u0131” tam da bu noktada devreye girer. Ba\u011flam, docker build<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131z dizin (veya belirtti\u011finiz bir dizin) ile bu dizin alt\u0131ndaki t\u00fcm alt dizin ve dosyalar\u0131n tamam\u0131n\u0131 ifade eder. Ba\u015fka bir deyi\u015fle, Docker Daemon’\u0131na g\u00f6nderilen ve imaj olu\u015fturma s\u00fcrecinde kullan\u0131labilecek olan dosya ve dizin k\u00fcmesidir.<\/p>\n

Bu kavram\u0131n \u00f6nemi birka\u00e7 temel noktada yatar. \u0130lk olarak, performans\u0131 do\u011frudan etkiler. E\u011fer build ba\u011flam\u0131n\u0131z gereksiz yere b\u00fcy\u00fckse, yani imaj\u0131n\u0131zda kullanmayaca\u011f\u0131n\u0131z binlerce dosya veya gigabaytlarca veri i\u00e7eriyorsa, Docker Daemon’a g\u00f6nderilen veri miktar\u0131 artar. Bu durum, \u00f6zellikle uzak bir Docker Daemon kullan\u0131ld\u0131\u011f\u0131nda (\u00f6rne\u011fin, bir CI\/CD sistemi veya buluttaki bir sunucu), build s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde uzat\u0131r. \u00c7\u00fcnk\u00fc t\u00fcm bu gereksiz verinin a\u011f \u00fczerinden transfer edilmesi gerekir.<\/p>\n

\u0130kinci olarak, g\u00fcvenlik a\u00e7\u0131s\u0131ndan kritik bir rol oynar. Projenizin kaynak kodlar\u0131 aras\u0131nda hassas veriler (API anahtarlar\u0131, parolalar, ki\u015fisel veri i\u00e7eren dosyalar vb.) bulunabilir. E\u011fer bu dosyalar bilmeden build ba\u011flam\u0131na dahil edilirse ve Dockerfile’\u0131n\u0131zda bu dosyalar\u0131 imaj i\u00e7ine kopyalayan bir komut varsa, bu hassas veriler nihai Docker imaj\u0131n\u0131za s\u0131zabilir. Ortaya \u00e7\u0131kan imaj, ba\u015fkalar\u0131 taraf\u0131ndan incelendi\u011finde veya kullan\u0131ld\u0131\u011f\u0131nda ciddi g\u00fcvenlik riskleri olu\u015fturabilir. Bu nedenle, build ba\u011flam\u0131n\u0131 dikkatli bir \u015fekilde y\u00f6netmek, uygulamalar\u0131n\u0131z\u0131n ve verilerinizin g\u00fcvenli\u011fi i\u00e7in olmazsa olmazd\u0131r.<\/p>\n

Son olarak, imaj\u0131n yeniden \u00fcretilebilirli\u011fi ve ta\u015f\u0131nabilirli\u011fi a\u00e7\u0131s\u0131ndan da ba\u011flam\u0131n \u00f6nemi b\u00fcy\u00fckt\u00fcr. Dockerfile’\u0131n\u0131zda COPY . .<\/code> gibi genel komutlar kulland\u0131\u011f\u0131n\u0131zda, ba\u011flam\u0131n\u0131zda bulunan her \u015fey imaja kopyalan\u0131r. Bu, farkl\u0131 geli\u015ftirme ortamlar\u0131nda veya farkl\u0131 build makinelerinde ba\u011flam\u0131n i\u00e7eri\u011fi de\u011fi\u015firse, ayn\u0131 Dockerfile ile ayn\u0131 imaj\u0131 elde etme garantisini zay\u0131flatabilir. Ba\u011flam\u0131n net ve minimal olmas\u0131, tutarl\u0131 ve \u00f6ng\u00f6r\u00fclebilir imajlar olu\u015fturman\u0131za yard\u0131mc\u0131 olur. Dolay\u0131s\u0131yla, bir Docker imaj\u0131n\u0131n sa\u011flam temeller \u00fczerinde y\u00fckselmesi i\u00e7in build ba\u011flam\u0131n\u0131n do\u011fru bir \u015fekilde anla\u015f\u0131lmas\u0131 ve y\u00f6netilmesi \u015fartt\u0131r.<\/p>\n

Docker Build Ba\u011flam\u0131n\u0131 Nas\u0131l Etkili Y\u00f6netiriz? Temel Uygulamalar<\/h2>\n

Docker build ba\u011flam\u0131n\u0131 etkili bir \u015fekilde y\u00f6netmek, genellikle docker build<\/code> komutunun nas\u0131l kullan\u0131ld\u0131\u011f\u0131 ve Dockerfile’\u0131n i\u00e7eri\u011fiyle yak\u0131ndan ili\u015fkilidir. Komut sat\u0131r\u0131nda docker build<\/code> \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, genellikle sonuna bir yol veya .<\/code> (nokta) eklersiniz. Bu nokta, mevcut dizinin build ba\u011flam\u0131 olarak kullan\u0131laca\u011f\u0131n\u0131 belirtir. Yani, Docker Daemon’a g\u00f6nderilecek olan t\u00fcm dosya ve dizinler, bu noktadan itibaren taran\u0131r.<\/p>\n

COPY<\/code> ve ADD<\/code> gibi Dockerfile komutlar\u0131, build ba\u011flam\u0131ndan dosya veya dizinleri al\u0131p imaj\u0131n dosya sistemine kopyalamak i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, COPY .\/src \/app\/src<\/code> komutu, build ba\u011flam\u0131ndaki src<\/code> dizinini al\u0131p imaj i\u00e7indeki \/app\/src<\/code> dizinine yerle\u015ftirir. E\u011fer .\/src<\/code> dizini build ba\u011flam\u0131nda yoksa, Docker bu komutu \u00e7al\u0131\u015ft\u0131r\u0131rken hata verir. Bu nedenle, Dockerfile’\u0131n\u0131zdaki her COPY<\/code> veya ADD<\/code> komutunun kaynak yolunun build ba\u011flam\u0131nda ger\u00e7ekten var oldu\u011fundan emin olmal\u0131s\u0131n\u0131z.<\/p>\n

\u0130\u015fte basit bir Node.js uygulamas\u0131n\u0131 Dockerize etmek i\u00e7in bir \u00f6rnek. Proje yap\u0131s\u0131 \u015f\u00f6yle olsun:<\/p>\n

    \n
  • my-node-app\/<\/code>\n
      \n
    • Dockerfile<\/code><\/li>\n
    • package.json<\/code><\/li>\n
    • package-lock.json<\/code><\/li>\n
    • app.js<\/code><\/li>\n
    • node_modules\/<\/code> (Bu dizini imaja dahil etmek istemeyiz)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

      Bu senaryoda, my-node-app<\/code> dizininde docker build .<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131m\u0131zda, bu dizin ve alt\u0131ndaki her \u015fey build ba\u011flam\u0131na dahil edilir. Ancak biz node_modules<\/code> klas\u00f6r\u00fcn\u00fc imaja kopyalamak istemeyiz, \u00e7\u00fcnk\u00fc npm install<\/code> komutuyla zaten imaj i\u00e7inde ba\u011f\u0131ml\u0131l\u0131klar\u0131 yeniden kuraca\u011f\u0131z. Bu, hem imaj boyutunu gereksiz yere art\u0131r\u0131r hem de build s\u00fcresini uzat\u0131r.<\/p>\n

      \u0130lk olarak, basit bir Dockerfile<\/code> \u00f6rne\u011fi:<\/p>\n

      \n# Dockerfile\nFROM node:16-alpine\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm install\nCOPY . .\nEXPOSE 3000\nCMD [\"npm\", \"start\"]\n    <\/pre>\n
      <\/code><\/p>\n
      Bu Dockerfile, \u00f6nce package.json<\/code> dosyalar\u0131n\u0131 kopyalar, sonra ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fckler ve son olarak kalan t\u00fcm proje dosyalar\u0131n\u0131 (COPY . .<\/code> ile) kopyalar. Ancak bu son komut, node_modules<\/code> dizinini de (e\u011fer varsa) kopyalamaya \u00e7al\u0131\u015facakt\u0131r. \u0130\u015fte bu noktada .dockerignore<\/code> dosyas\u0131n\u0131n g\u00fcc\u00fcnden faydalan\u0131r\u0131z.<\/p>\n
      Build i\u015flemini tetiklemek i\u00e7in a\u015fa\u011f\u0131daki komutu kullanabiliriz:<\/p>\n
      \n# Terminal\ndocker build -t my-node-app .\n    <\/pre>\n
      <\/code><\/p>\n
      Bu komut, mevcut dizindeki her \u015feyi (gizli dosyalar dahil) Docker Daemon'a g\u00f6nderir. Daha verimli bir build s\u00fcreci ve daha k\u00fc\u00e7\u00fck imajlar i\u00e7in bu ba\u011flam\u0131 kontrol alt\u0131nda tutmak elzemdir. Bir sonraki b\u00f6l\u00fcmde .dockerignore<\/code> dosyas\u0131n\u0131n bu s\u00fcre\u00e7teki rol\u00fcn\u00fc inceleyece\u011fiz.<\/p>\n
      .dockerignore Dosyas\u0131: Gereksiz Dosyalar\u0131 Ba\u011flamdan Nas\u0131l D\u0131\u015flar\u0131z?<\/h2>\n
      Docker build ba\u011flam\u0131n\u0131 optimize etmenin en g\u00fc\u00e7l\u00fc yollar\u0131ndan biri, .dockerignore<\/code> dosyas\u0131n\u0131 kullanmakt\u0131r. Bu dosya, t\u0131pk\u0131 .gitignore<\/code> dosyas\u0131 gibi \u00e7al\u0131\u015f\u0131r, ancak amac\u0131 farkl\u0131d\u0131r: Docker Daemon'a g\u00f6nderilecek olan dosya ve dizinler aras\u0131ndan hangilerinin hari\u00e7 tutulaca\u011f\u0131n\u0131 Docker'a bildirir. Bu sayede, gereksiz verilerin a\u011f \u00fczerinden transfer edilmesi ve Docker imaj\u0131na kopyalanmas\u0131 engellenir, bu da build s\u00fcrelerini k\u0131salt\u0131r ve nihai imaj boyutunu k\u00fc\u00e7\u00fclt\u00fcr.<\/p>\n
      .dockerignore<\/code> dosyas\u0131n\u0131n \u00e7al\u0131\u015fma prensibi olduk\u00e7a basittir. Build i\u015flemi ba\u015flamadan \u00f6nce, Docker Client belirtilen ba\u011flam dizinini tarar ve bu dosyadaki kurallara uyan her \u015feyi ba\u011flamdan \u00e7\u0131kar\u0131r. Ard\u0131ndan kalan dosyalar\u0131 s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f bir tar ar\u015fivi olarak Docker Daemon'a g\u00f6nderir. Bu, \u00f6zellikle b\u00fcy\u00fck projelere sahip geli\u015ftiriciler i\u00e7in hayat kurtar\u0131c\u0131 bir \u00f6zelliktir. \u00d6rne\u011fin, Node.js projelerinde node_modules<\/code> dizini, Python projelerinde __pycache__<\/code> veya sanal ortam dizinleri (venv<\/code>), Java projelerinde target<\/code> dizinleri genellikle binlerce dosya i\u00e7erir ve onlarca hatta y\u00fczlerce megabayt yer kaplayabilir. Bu dosyalar\u0131 ba\u011flamdan d\u0131\u015flamak, hem a\u011f trafi\u011fini azalt\u0131r hem de Docker Daemon'\u0131n bu dosyalar\u0131 i\u015flemek zorunda kalmamas\u0131n\u0131 sa\u011flar.<\/p>\n
      .dockerignore<\/code> dosyas\u0131, g\u00fcvenlik a\u00e7\u0131s\u0131ndan da kritik bir rol oynar. Geli\u015ftirme ortam\u0131n\u0131zda bulunan .env<\/code> dosyalar\u0131, yerel konfig\u00fcrasyon dosyalar\u0131, veritaban\u0131 yede\u011fi gibi hassas bilgileri i\u00e7eren dosyalar yanl\u0131\u015fl\u0131kla Docker imaj\u0131na s\u0131zabilir. Bu t\u00fcr dosyalar\u0131 .dockerignore<\/code> listesine eklemek, potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 \u00f6nler.<\/p>\n
      \u0130\u015fte yukar\u0131daki Node.js uygulamas\u0131 i\u00e7in tipik bir .dockerignore<\/code> dosyas\u0131 \u00f6rne\u011fi:<\/p>\n
      \n# .dockerignore\nnode_modules\nnpm-debug.log\n.git\n.env\nDockerfile\n.vscode\/\ntemp\/\n    <\/pre>\n
      <\/code><\/p>\n
      Bu \u00f6rnekte:<\/p>\n
        \n
      • node_modules<\/code>: Ba\u011f\u0131ml\u0131l\u0131klar imaj i\u00e7inde yeniden kurulaca\u011f\u0131 i\u00e7in d\u0131\u015flan\u0131r.<\/li>\n
      • npm-debug.log<\/code>: Hata ay\u0131klama g\u00fcnl\u00fckleri, imaj i\u00e7in gereksizdir.<\/li>\n
      • .git<\/code>: Git versiyon kontrol sistemi dosyalar\u0131, imaj i\u00e7inde olmamal\u0131d\u0131r.<\/li>\n
      • .env<\/code>: Ortam de\u011fi\u015fkenleri i\u00e7eren hassas dosya, imaja s\u0131zmamal\u0131d\u0131r.<\/li>\n
      • Dockerfile<\/code>: Zaten Docker Daemon taraf\u0131ndan okunur, imaja kopyalanmas\u0131na gerek yoktur.<\/li>\n
      • .vscode\/<\/code>: Geli\u015ftirme ortam\u0131 konfig\u00fcrasyonlar\u0131.<\/li>\n
      • temp\/<\/code>: Ge\u00e7ici dosyalar\u0131n bulundu\u011fu bir dizin.<\/li>\n<\/ul>\n
        Bu \u015fekilde, yaln\u0131zca uygulaman\u0131n \u00e7al\u0131\u015fmas\u0131 i\u00e7in ger\u00e7ekten gerekli olan dosyalar build ba\u011flam\u0131na dahil edilmi\u015f olur. Bu dosyan\u0131n do\u011fru kullan\u0131m\u0131, Docker imaj\u0131 olu\u015fturma s\u00fcrecinizin verimlili\u011fini ve g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Bu optimizasyon, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve \u00e7ok say\u0131da ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 olan projelerde belirgin bir fark yarat\u0131r.<\/p>\n
        Ger\u00e7ek D\u00fcnya Senaryolar\u0131nda Docker Build Ba\u011flam\u0131 Optimizasyonu: Bir Vaka Analizi<\/h2>\n
        B\u00fcy\u00fck ve karma\u015f\u0131k projelerle \u00e7al\u0131\u015f\u0131rken, Docker build ba\u011flam\u0131n\u0131 optimize etmek bir zorunluluk haline gelir. Monorepolar (tek bir depoda birden fazla projenin bulundu\u011fu yap\u0131lar) veya legacy projeler, genellikle gereksiz yere b\u00fcy\u00fck build ba\u011flamlar\u0131na yol a\u00e7ar. Gelin, frontend ve backend uygulamalar\u0131n\u0131n ayn\u0131 Git deposunda bulundu\u011fu bir monorepo senaryosunu ele alal\u0131m. Proje yap\u0131m\u0131z \u015f\u00f6yle olsun:<\/p>\n
        \nmy-monorepo\/\n\u251c\u2500\u2500 frontend\/\n\u2502   \u251c\u2500\u2500 src\/\n\u2502   \u251c\u2500\u2500 public\/\n\u2502   \u251c\u2500\u2500 package.json\n\u2502   \u2514\u2500\u2500 ...\n\u251c\u2500\u2500 backend\/\n\u2502   \u251c\u2500\u2500 src\/\n\u2502   \u251c\u2500\u2500 requirements.txt\n\u2502   \u2514\u2500\u2500 ...\n\u251c\u2500\u2500 .dockerignore\n\u2514\u2500\u2500 Dockerfile.multistage\n    <\/pre>\n
        <\/code><\/p>\n
        Bu yap\u0131da, hem frontend hem de backend i\u00e7in Docker imajlar\u0131 olu\u015fturmam\u0131z gerekiyor. E\u011fer my-monorepo<\/code> dizininde docker build .<\/code> komutunu kullan\u0131p tek bir Dockerfile yazarsak, t\u00fcm monorepo dizini build ba\u011flam\u0131na dahil edilecek ve bu da muazzam bir veri transferine neden olacakt\u0131r. Oysa frontend imaj\u0131 sadece frontend<\/code> dizinine, backend imaj\u0131 ise sadece backend<\/code> dizinine ihtiya\u00e7 duyar. Bu durumda, \u00e7ok a\u015famal\u0131 build (multi-stage build) ve spesifik COPY<\/code> komutlar\u0131 devreye girer.<\/p>\n
        A\u015fa\u011f\u0131daki Dockerfile.multistage<\/code> \u00f6rne\u011fi, bu senaryoda ba\u011flam optimizasyonunu nas\u0131l ger\u00e7ekle\u015ftirebilece\u011fimizi g\u00f6steriyor:<\/p>\n
        \n# Dockerfile.multistage\n\n# 1. Frontend Uygulamas\u0131n\u0131 Olu\u015fturma A\u015famas\u0131\nFROM node:16-alpine as frontend-builder\nWORKDIR \/app\/frontend\n# Sadece frontend'in package.json dosyalar\u0131n\u0131 kopyala\nCOPY .\/frontend\/package*.json .\/\nRUN npm install\n# Sadece frontend dizinindeki di\u011fer dosyalar\u0131 kopyala\nCOPY .\/frontend .\nRUN npm run build\n\n# 2. Backend Uygulamas\u0131n\u0131 Olu\u015fturma A\u015famas\u0131 (\u00d6rnek Python)\nFROM python:3.9-slim-buster as backend-builder\nWORKDIR \/app\/backend\n# Sadece backend'in requirements.txt dosyas\u0131n\u0131 kopyala\nCOPY .\/backend\/requirements.txt .\/\nRUN pip install -r requirements.txt\n# Sadece backend dizinindeki di\u011fer dosyalar\u0131 kopyala\nCOPY .\/backend .\n\n# 3. Nihai \u00dcretim \u0130maj\u0131 A\u015famas\u0131 (\u00d6rnek Nginx ile sunum)\nFROM nginx:stable-alpine\n# Frontend'in build edilmi\u015f \u00e7\u0131kt\u0131lar\u0131n\u0131 kopyala\nCOPY --from=frontend-builder \/app\/frontend\/build \/usr\/share\/nginx\/html\n# Backend uygulamas\u0131n\u0131 kopyala\nCOPY --from=backend-builder \/app\/backend \/var\/www\/backend\nEXPOSE 80\nCMD [\"nginx\", \"-g\", \"daemon off;\"]\n    <\/pre>\n
        <\/code><\/p>\n
        Bu Dockerfile<\/code>, tek bir docker build .<\/code> komutu ile t\u00fcm monoreponun ba\u011flam olarak g\u00f6nderilmesini gerektirir, ancak kritik fark, COPY<\/code> komutlar\u0131n\u0131n sadece ilgili alt dizinleri hedeflemesidir (.\/frontend\/package*.json<\/code> yerine .\/frontend\/package*.json<\/code> gibi). Bu sayede, her a\u015famada yaln\u0131zca o a\u015faman\u0131n ihtiya\u00e7 duydu\u011fu dosyalar kopyalan\u0131r ve gereksiz dosyalar\u0131n ara katmanlara dahil edilmesi engellenir.<\/p>\n
        \u00d6zellikle COPY .\/frontend .<\/code> gibi komutlar yerine, COPY .\/frontend\/src .\/src<\/code> \u015feklinde daha spesifik yollar kullanarak da build ba\u011flam\u0131n\u0131 g\u00f6nderdikten sonra kopyalanan dosyalar\u0131n miktar\u0131n\u0131 azaltabiliriz. Ancak .dockerignore<\/code>, daha en ba\u015fta Docker Daemon'a g\u00f6nderilen veri miktar\u0131n\u0131 kontrol etti\u011fi i\u00e7in daha \u00f6nceliklidir. Bu \u00e7ok a\u015famal\u0131 build stratejisi, nihai imaj\u0131n boyutunu k\u00fc\u00e7\u00fclt\u00fcrken ayn\u0131 zamanda farkl\u0131 bile\u015fenlerin ba\u011f\u0131ms\u0131z olarak in\u015fa edilmesini sa\u011flar, b\u00f6ylece build s\u00fcre\u00e7leri daha h\u0131zl\u0131 ve verimli hale gelir. Unutulmamal\u0131d\u0131r ki, .dockerignore<\/code> dosyas\u0131 her zaman en \u00fcst seviyede, yani my-monorepo\/<\/code> dizininde olmal\u0131 ve t\u00fcm projeyi kapsayan genel kurallar\u0131 i\u00e7ermelidir.<\/p>\n
        Build Ba\u011flam\u0131 ve Performans \u0130li\u015fkisi: Nas\u0131l Daha H\u0131zl\u0131 Docker \u0130majlar\u0131 Olu\u015ftururuz?<\/h2>\n
        Docker imaj olu\u015fturma s\u00fcreci, karma\u015f\u0131k bir dans gibidir ve bu dans\u0131n ritmi, build ba\u011flam\u0131n\u0131n boyutuna ve i\u00e7eri\u011fine g\u00f6re de\u011fi\u015fir. H\u0131zl\u0131 ve verimli bir build s\u00fcreci i\u00e7in build ba\u011flam\u0131n\u0131 optimize etmek, adeta gizli bir silaht\u0131r. Performans, genellikle iki ana fakt\u00f6r \u00fczerinden etkilenir: a\u011f transferi ve Docker Daemon'\u0131n disk \u00fczerindeki i\u015flem y\u00fck\u00fc.<\/p>\n
        \u0130lk olarak, a\u011f transferi. docker build<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, Docker Client belirtilen build ba\u011flam\u0131n\u0131 (.dockerignore<\/code> kurallar\u0131 uyguland\u0131ktan sonra) s\u0131k\u0131\u015ft\u0131r\u0131r ve Docker Daemon'a g\u00f6nderir. E\u011fer ba\u011flam\u0131n\u0131zda gigabaytlarca veri varsa, bu veri transferi build s\u00fcrecinin en yava\u015f ad\u0131m\u0131 olabilir. \u00d6zellikle uzak bir sunucuda \u00e7al\u0131\u015fan bir Docker Daemon ile \u00e7al\u0131\u015f\u0131yorsan\u0131z (\u00f6rne\u011fin, bulut tabanl\u0131 CI\/CD servisleri), bu gecikme daha da belirginle\u015fir. Bu y\u00fczden, .dockerignore<\/code> dosyas\u0131n\u0131 titizlikle kullanarak gereksiz dosyalar\u0131 en ba\u015ftan elemek, a\u011f y\u00fck\u00fcn\u00fc minimize etmenin anahtar\u0131d\u0131r.<\/p>\n
        \u0130kinci olarak, Docker Daemon'\u0131n disk \u00fczerindeki i\u015flem y\u00fck\u00fc ve katmanlama (layering) mekanizmas\u0131. Docker imajlar\u0131 katmanlar halinde in\u015fa edilir. Dockerfile'daki her bir komut (FROM<\/code>, RUN<\/code>, COPY<\/code> vb.) genellikle yeni bir katman olu\u015fturur. Docker, bir katman de\u011fi\u015fmedi\u011fi s\u00fcrece onu yeniden in\u015fa etmek yerine \u00f6nbellekten (cache) kullan\u0131r. Bu \u00f6nbellekleme mekanizmas\u0131, build s\u00fcrelerini dramatik \u015fekilde k\u0131saltabilir. Ancak, COPY . .<\/code> gibi bir komutla ba\u011flam\u0131n tamam\u0131n\u0131 kopyalad\u0131\u011f\u0131n\u0131zda ve bu ba\u011flamdaki tek bir dosya bile de\u011fi\u015fse, Docker o katmandan sonraki t\u00fcm katmanlar\u0131 yeniden in\u015fa etmek zorunda kal\u0131r. Bu da \u00f6nbellekleme faydas\u0131n\u0131 ortadan kald\u0131r\u0131r.<\/p>\n
        Peki, daha h\u0131zl\u0131 imajlar olu\u015fturmak i\u00e7in ne yapmal\u0131y\u0131z?<\/p>\n
          \n
        1. Minimal .dockerignore<\/code>:<\/strong> Yukar\u0131da da belirtti\u011fimiz gibi, build ba\u011flam\u0131na sadece ger\u00e7ekten gerekli olan dosyalar\u0131 dahil edin. B\u00fcy\u00fck ba\u011f\u0131ml\u0131l\u0131k dizinlerini (node_modules<\/code>, venv<\/code>, target<\/code>), ge\u00e7ici dosyalar\u0131, versiyon kontrol sistemlerine ait dizinleri (.git<\/code>) ve hassas verileri mutlaka d\u0131\u015flay\u0131n.<\/li>\n
        2. COPY<\/code> Komutlar\u0131n\u0131n Stratejik S\u0131ralanmas\u0131:<\/strong> En az de\u011fi\u015fen dosyalar\u0131 (\u00f6rne\u011fin, package.json<\/code>, requirements.txt<\/code> gibi ba\u011f\u0131ml\u0131l\u0131k tan\u0131mlama dosyalar\u0131) Dockerfile'\u0131n \u00fcst k\u0131s\u0131mlar\u0131na, yani de\u011fi\u015fme olas\u0131l\u0131\u011f\u0131 en d\u00fc\u015f\u00fck olan komutlardan hemen sonraya yerle\u015ftirin. B\u00f6ylece, bu dosyalar de\u011fi\u015fmedik\u00e7e, ba\u011f\u0131ml\u0131l\u0131k kurulumu gibi zaman al\u0131c\u0131 RUN<\/code> komutlar\u0131 \u00f6nbellekten kullan\u0131l\u0131r.<\/li>\n
        3. Belirli Dosya ve Dizinleri Kopyalama:<\/strong> M\u00fcmk\u00fcnse, COPY . .<\/code> yerine COPY .\/src \/app\/src<\/code> veya COPY .\/configs \/etc\/app\/configs<\/code> gibi daha spesifik kopyalama komutlar\u0131 kullan\u0131n. Bu, belirli bir dizindeki de\u011fi\u015fikliklerin yaln\u0131zca o dizinle ilgili katman\u0131 ge\u00e7ersiz k\u0131lmas\u0131n\u0131 sa\u011flar, t\u00fcm uygulama katmanlar\u0131n\u0131 de\u011fil.<\/li>\n
        4. \u00c7ok A\u015famal\u0131 Build (Multi-Stage Builds):<\/strong> Gereksiz build ara\u00e7lar\u0131n\u0131 ve ara dosyalar\u0131 nihai imajdan ay\u0131rmak i\u00e7in \u00e7ok a\u015famal\u0131 build'leri kullan\u0131n. Bu, hem imaj boyutunu k\u00fc\u00e7\u00fclt\u00fcr hem de build ba\u011flam\u0131n\u0131n daha mod\u00fcler y\u00f6netilmesine olanak tan\u0131r.<\/li>\n<\/ol>\n
          \n
          Uzman \u0130pucu:<\/strong> Build performans\u0131n\u0131 \u00f6l\u00e7mek i\u00e7in docker build --no-cache ...<\/code> ve ard\u0131ndan normal docker build ...<\/code> komutlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131r\u0131n. Aradaki fark, \u00f6nbellekleme stratejinizin ne kadar etkili oldu\u011funu g\u00f6sterir. Ayr\u0131ca, docker history <\/code> komutu ile katman boyutlar\u0131n\u0131 inceleyebilir ve hangi katmanlar\u0131n gereksiz yer kaplad\u0131\u011f\u0131n\u0131 tespit edebilirsiniz.<\/p>\n<\/blockquote>\n
          Bu stratejileri uygulayarak, Docker build s\u00fcre\u00e7lerinizi \u00f6nemli \u00f6l\u00e7\u00fcde h\u0131zland\u0131rabilir ve daha verimli imajlar elde edebilirsiniz. Unutmay\u0131n, iyi y\u00f6netilmi\u015f bir build ba\u011flam\u0131, sadece h\u0131zl\u0131 build s\u00fcreleri de\u011fil, ayn\u0131 zamanda daha k\u00fc\u00e7\u00fck ve g\u00fcvenli imajlar anlam\u0131na da gelir.<\/p>\n
          Build Ba\u011flam\u0131 G\u00fcvenli\u011fi: Hassas Verileri \u0130majlara S\u0131zd\u0131rmamak \u0130\u00e7in Neler Yapmal\u0131y\u0131z?<\/h2>\n
          Docker imaj g\u00fcvenli\u011fi, modern uygulama geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinin vazge\u00e7ilmez bir par\u00e7as\u0131d\u0131r. Build ba\u011flam\u0131n\u0131n do\u011fru y\u00f6netilmemesi, hassas verilerin yanl\u0131\u015fl\u0131kla nihai imajlara s\u0131zmas\u0131na neden olabilir, bu da ciddi g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7ar. API anahtarlar\u0131, veritaban\u0131 parolalar\u0131, \u00f6zel sertifikalar veya di\u011fer ki\u015fisel tan\u0131mlay\u0131c\u0131 bilgiler gibi kritik verilerin imaj i\u00e7ine g\u00f6m\u00fclmesi, uygulaman\u0131z\u0131n ve kullan\u0131c\u0131lar\u0131n\u0131z\u0131n g\u00fcvenli\u011fini tehlikeye atar.<\/p>\n
          Bu t\u00fcr s\u0131z\u0131nt\u0131lar\u0131 \u00f6nlemek i\u00e7in uygulanabilecek temel stratejiler bulunmaktad\u0131r:<\/p>\n
            \n
          1. .dockerignore<\/code> Dosyas\u0131n\u0131n Kapsaml\u0131 Kullan\u0131m\u0131:<\/strong> Bu, hassas dosyalar\u0131 build ba\u011flam\u0131ndan d\u0131\u015flaman\u0131n ilk ve en \u00f6nemli ad\u0131m\u0131d\u0131r. .env<\/code> dosyalar\u0131, yerel konfig\u00fcrasyon dosyalar\u0131, SSH anahtarlar\u0131 (e\u011fer yanl\u0131\u015fl\u0131kla proje dizinindeyse), veritaban\u0131 yedekleri ve di\u011fer gizli bilgileri i\u00e7eren t\u00fcm dosyalar\u0131 .dockerignore<\/code> listesine eklemelisiniz. Bu, bu dosyalar\u0131n Docker Daemon'a bile g\u00f6nderilmemesini sa\u011flar.<\/li>\n
          2. \u00c7ok A\u015famal\u0131 Build'lerin G\u00fcvenlik Faydalar\u0131:<\/strong> \u00c7ok a\u015famal\u0131 build'ler, sadece imaj boyutunu k\u00fc\u00e7\u00fcltmekle kalmaz, ayn\u0131 zamanda g\u00fcvenlik a\u00e7\u0131s\u0131ndan da \u00f6nemli avantajlar sunar. \u0130lk a\u015famalarda (build a\u015famas\u0131) hassas verileri kullanarak derleme veya test yapabilir, ancak bu verileri son, \u00fcretim a\u015famas\u0131 imaj\u0131na kopyalamayarak nihai imaj\u0131n temiz kalmas\u0131n\u0131 sa\u011flayabilirsiniz. \u00d6rne\u011fin, API anahtarlar\u0131n\u0131 bir build arg\u00fcman\u0131 olarak kullan\u0131p, sadece build s\u0131ras\u0131nda eri\u015filmesini sa\u011flayabilir, ancak final imaj\u0131na g\u00f6mmeyebilirsiniz.<\/li>\n
          3. Build Arg\u00fcmanlar\u0131 (--build-arg<\/code>) ve Ortam De\u011fi\u015fkenleri:<\/strong> Hassas bilgiler i\u00e7in --build-arg<\/code> komutunu kullanarak ortam de\u011fi\u015fkenlerini Dockerfile'a aktarabilirsiniz. Ancak, bu arg\u00fcmanlar Docker imaj\u0131n\u0131n ge\u00e7mi\u015finde (docker history<\/code>) g\u00f6r\u00fcn\u00fcr olabilece\u011finden, kritik hassasiyetteki veriler i\u00e7in dikkatli kullan\u0131lmal\u0131d\u0131r. Daha g\u00fcvenli bir yakla\u015f\u0131m, bu de\u011ferleri Dockerfile<\/code> i\u00e7erisinde ARG<\/code> ile tan\u0131mlay\u0131p, ENV<\/code> ile kal\u0131c\u0131 hale getirmemektir. Bunun yerine, uygulama \u00e7al\u0131\u015fma zaman\u0131nda (runtime) ortam de\u011fi\u015fkenleri olarak verilmelidir.<\/li>\n
          4. Docker BuildKit Secrets:<\/strong> Modern Docker s\u00fcr\u00fcmleri, BuildKit ad\u0131 verilen yeni bir imaj olu\u015fturma motoruyla birlikte gelir. BuildKit, hassas verileri (secrets) daha g\u00fcvenli bir \u015fekilde y\u00f6netmek i\u00e7in yerle\u015fik destek sunar. --secret<\/code> bayra\u011f\u0131n\u0131 kullanarak, dosyalar\u0131 veya ortam de\u011fi\u015fkenlerini Docker Daemon'a g\u00f6ndermeden, sadece build a\u015famas\u0131nda Dockerfile'\u0131n\u0131zda eri\u015filebilir hale getirebilirsiniz. Bu veriler imajda kal\u0131c\u0131 olmaz ve docker history<\/code>'de g\u00f6r\u00fcnmez.<\/li>\n<\/ol>\n
            BuildKit ile secret kullan\u0131m\u0131 i\u00e7in \u00f6rnek bir komut:<\/p>\n
            \n# BuildKit'i etkinle\u015ftirin ve secret kullanarak imaj\u0131 olu\u015fturun\nDOCKER_BUILDKIT=1 docker build --secret id=mysecret,src=.\/.env . -t myapp\n    <\/pre>\n
            <\/code><\/p>\n
            Ve ilgili Dockerfile par\u00e7as\u0131:<\/p>\n
            \n# Dockerfile\n# BuildKit ile secret kullanmak i\u00e7in syntax tan\u0131m\u0131\n# syntax=docker\/dockerfile:1.4\n\nFROM alpine\nWORKDIR \/app\n# 'mysecret' ad\u0131ndaki secret'\u0131 \/run\/secrets\/mysecret dosyas\u0131na ba\u011fla\nRUN --mount=type=secret,id=mysecret,dst=\/run\/secrets\/mysecret \\\n    cat \/run\/secrets\/mysecret > \/tmp\/secret_output.txt\n\n# UYARI: Bu \u00f6rnek s\u0131rr\u0131 bir dosyaya yazar. Ger\u00e7ek uygulamalarda do\u011frudan kullan\u0131n\n# ve nihai imaja dahil etmeyin.\n# Sadece demo ama\u00e7l\u0131d\u0131r. Nihai imajda bu dosya olmamal\u0131d\u0131r.\n    <\/pre>\n
            <\/code><\/p>\n
            Bu, secret'\u0131n sadece build a\u015famas\u0131nda eri\u015filebilir olmas\u0131n\u0131 ve nihai imaja dahil edilmemesini sa\u011flar. BuildKit kullanmak, \u00f6zellikle hassas verilerle \u00e7al\u0131\u015f\u0131rken en g\u00fcvenli yakla\u015f\u0131mlardan biridir.<\/p>\n
            Son olarak, hi\u00e7bir hassas verinin do\u011frudan Dockerfile i\u00e7ine hard-code edilmemesi gerekti\u011fini unutmay\u0131n. Bu t\u00fcr bilgiler her zaman \u00e7al\u0131\u015fma zaman\u0131nda (runtime) ortam de\u011fi\u015fkenleri, Kubernetes Secrets veya Docker Swarm Secrets gibi g\u00fcvenli y\u00f6ntemlerle uygulamaya enjekte edilmelidir. Build ba\u011flam\u0131 g\u00fcvenli\u011fini ciddiye almak, uygulaman\u0131z\u0131n genel g\u00fcvenlik duru\u015funu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirecektir.<\/p>\n
            S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
            Docker build ba\u011flam\u0131n\u0131 anlamak, daha verimli, g\u00fcvenli ve performansl\u0131 imajlar olu\u015fturman\u0131n temelidir. Bu makalede ele ald\u0131\u011f\u0131m\u0131z konular, ba\u011flam\u0131n ne oldu\u011fu, neden \u00f6nemli oldu\u011fu, .dockerignore<\/code> kullan\u0131m\u0131, \u00e7ok a\u015famal\u0131 build'lerle optimizasyon ve g\u00fcvenlik stratejileri \u00fczerine odakland\u0131. Do\u011fru yakla\u015f\u0131mlarla, Docker imaj olu\u015fturma s\u00fcre\u00e7lerinizi \u00e7ok daha sa\u011flam hale getirebilirsiniz. \u015eimdi, konuyu peki\u015ftirmek i\u00e7in s\u0131k\u00e7a sorulan baz\u0131 sorulara g\u00f6z atal\u0131m.<\/p>\n
              \n
            1. \n
              Build ba\u011flam\u0131 ve \u00e7al\u0131\u015fma dizini (WORKDIR<\/code>) aras\u0131ndaki fark nedir?<\/h3>\n
              Build ba\u011flam\u0131, docker build<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda Docker Daemon'a g\u00f6nderilen, ana bilgisayar\u0131n\u0131zdaki (host machine) t\u00fcm dosya ve dizin k\u00fcmesidir. Yani, Docker'\u0131n imaj\u0131 in\u015fa etmek i\u00e7in eri\u015febilece\u011fi t\u00fcm kaynaklar\u0131 temsil eder. \u00c7al\u0131\u015fma dizini (WORKDIR<\/code>) ise, Dockerfile<\/code> i\u00e7inde WORKDIR \/app<\/code> gibi bir komutla belirlenen, imaj\u0131n dosya sistemi i\u00e7indeki bir dizindir. RUN<\/code>, CMD<\/code>, ENTRYPOINT<\/code>, COPY<\/code> ve ADD<\/code> gibi komutlar, WORKDIR<\/code> i\u00e7inde g\u00f6receli yollar\u0131 kullanarak i\u015flem yapar. K\u0131sacas\u0131, ba\u011flam kaynaklar\u0131 host'tan Daemon'a g\u00f6nderirken, WORKDIR<\/code> bu kaynaklar\u0131n imaj i\u00e7inde nereye kopyalanaca\u011f\u0131n\u0131 veya hangi dizinde i\u015flem yap\u0131laca\u011f\u0131n\u0131 belirtir.<\/p>\n<\/li>\n
            2. \n
              .dockerignore<\/code> dosyas\u0131 yoksa ne olur?<\/h3>\n
              E\u011fer bir .dockerignore<\/code> dosyas\u0131 yoksa, docker build .<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, mevcut dizindeki t\u00fcm dosyalar ve alt dizinler (.git<\/code> gibi baz\u0131 \u00f6zel durumlar d\u0131\u015f\u0131nda) build ba\u011flam\u0131na dahil edilir ve Docker Daemon'a g\u00f6nderilir. Bu durum, genellikle gereksiz yere b\u00fcy\u00fck veri transferine ve daha yava\u015f build s\u00fcrelerine yol a\u00e7ar. Ayr\u0131ca, projenizde bulunan hassas dosyalar\u0131n veya b\u00fcy\u00fck ba\u011f\u0131ml\u0131l\u0131k klas\u00f6rlerinin (node_modules<\/code>, venv<\/code> vb.) imaj\u0131n\u0131za s\u0131zma riskini art\u0131r\u0131r, bu da imaj boyutunu \u015fi\u015firir ve g\u00fcvenlik a\u00e7\u0131klar\u0131na neden olabilir.<\/p>\n<\/li>\n
            3. \n
              Uzak bir URL'den build ba\u011flam\u0131 alabilir miyim?<\/h3>\n
              Evet, Docker, build ba\u011flam\u0131n\u0131 uzak bir Git deposundan da alabilir. Bunun i\u00e7in docker build <\/code> komutunu kullanman\u0131z yeterlidir. \u00d6rne\u011fin, docker build https:\/\/github.com\/docker\/rootfs.git#container:docker<\/code>. Bu durumda, Docker belirtilen Git deposunu klonlar ve klonlanan deponun k\u00f6k dizinini build ba\u011flam\u0131 olarak kullan\u0131r. E\u011fer Git deposunda bir .dockerignore<\/code> dosyas\u0131 varsa, bu kurallar da uygulan\u0131r. Bu \u00f6zellik, \u00f6zellikle CI\/CD senaryolar\u0131nda veya payla\u015f\u0131lan Dockerfile'lar\u0131 kullan\u0131rken olduk\u00e7a faydal\u0131d\u0131r.<\/p>\n<\/li>\n
            4. \n
              Docker build ba\u011flam\u0131nda performans d\u00fc\u015f\u00fc\u015f\u00fcn\u00fc nas\u0131l tespit ederim?<\/h3>\n
              Performans d\u00fc\u015f\u00fc\u015f\u00fcn\u00fc tespit etmek i\u00e7in birka\u00e7 y\u00f6ntem vard\u0131r:<\/p>\n
                \n
              • Build S\u00fcresi Analizi:<\/strong> docker build<\/code> komutunun \u00e7\u0131kt\u0131s\u0131n\u0131 dikkatle inceleyin. Her ad\u0131m\u0131n ne kadar s\u00fcrd\u00fc\u011f\u00fcn\u00fc g\u00f6zlemleyin. \u00d6zellikle \"Sending build context to Docker daemon\" ad\u0131m\u0131n\u0131n uzun s\u00fcrmesi, b\u00fcy\u00fck bir ba\u011flam\u0131n\u0131z oldu\u011funu g\u00f6sterir.<\/li>\n
              • docker history<\/code>:<\/strong> Olu\u015fturdu\u011funuz imaj\u0131n katmanlar\u0131n\u0131 docker history <\/code> komutuyla inceleyin. B\u00fcy\u00fck boyutlu katmanlar, genellikle gereksiz dosyalar\u0131n kopyaland\u0131\u011f\u0131n\u0131 veya verimli bir \u00f6nbellekleme stratejisinin olmad\u0131\u011f\u0131n\u0131 i\u015faret eder.<\/li>\n
              • --progress=plain<\/code>:<\/strong> Docker BuildKit ile DOCKER_BUILDKIT=1 docker build --progress=plain .<\/code> komutunu kullanarak build ad\u0131mlar\u0131n\u0131n daha detayl\u0131 bir \u00e7\u0131kt\u0131s\u0131n\u0131 alabilir, hangi ad\u0131m\u0131n ne kadar s\u00fcrd\u00fc\u011f\u00fcn\u00fc ve hangi katmanlar\u0131n \u00f6nbellekten kullan\u0131ld\u0131\u011f\u0131n\u0131 daha net g\u00f6rebilirsiniz.<\/li>\n
              • du -sh .<\/code>:<\/strong> Build ba\u011flam\u0131n\u0131 g\u00f6ndermeden \u00f6nce dizininizin boyutunu kontrol edin. .dockerignore<\/code> uyguland\u0131ktan sonraki ger\u00e7ek boyutu anlamak i\u00e7in temporer bir dizine kopyalay\u0131p .dockerignore<\/code>'u uygulay\u0131p \u00f6yle kontrol edebilirsiniz.<\/li>\n<\/ul>\n<\/li>\n
              • \n
                Bir web sayfas\u0131n\u0131 mobil uyumlu hale getirmek i\u00e7in temel bir media query \u00f6rne\u011fi verir misiniz?<\/h3>\n
                Elbette. Docker build ba\u011flam\u0131yla do\u011frudan ilgili olmasa da, web geli\u015ftirmenin \u00f6nemli bir par\u00e7as\u0131 olan mobil uyumlulu\u011fu g\u00f6stermek i\u00e7in temel bir CSS media query \u00f6rne\u011fi a\u015fa\u011f\u0131dad\u0131r. Bu \u00f6rnek, belirli bir ekran geni\u015fli\u011finin alt\u0131nda bir div'in rengini ve metin boyutunu nas\u0131l de\u011fi\u015ftirebilece\u011finizi g\u00f6sterir:<\/p>\n
                \n