AWS CodeBuild’de Docker yap\u0131lar\u0131n\u0131z yava\u015f m\u0131 ilerliyor? Bu makale, ECR’\u0131 uzak \u00f6nbellek olarak kullanarak build s\u00fcrelerinizi %25 veya daha fazla nas\u0131l h\u0131zland\u0131rabilece\u011finizi ad\u0131m ad\u0131m anlat\u0131yor. Verimlili\u011fi art\u0131r\u0131n!<\/p>\n
G\u00fcn\u00fcm\u00fcz yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde, Continuous Integration\/Continuous Delivery (CI\/CD) pipeline’lar\u0131, h\u0131z ve verimlilik a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir. \u00d6zellikle konteynerize edilmi\u015f uygulamalar\u0131n pop\u00fclaritesi artt\u0131k\u00e7a, Docker imajlar\u0131n\u0131n h\u0131zl\u0131 bir \u015fekilde olu\u015fturulmas\u0131 ve g\u00fcncellenmesi, geli\u015ftirme ekipleri i\u00e7in birincil \u00f6ncelik haline gelmi\u015ftir. Ancak, \u00e7o\u011fu zaman AWS CodeBuild gibi CI\/CD servislerinde Docker imajlar\u0131 olu\u015fturulurken kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck sorunlardan biri, build s\u00fcrelerinin uzamas\u0131d\u0131r. Her yeni kod de\u011fi\u015fikli\u011finde t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n ba\u015ftan indirilmesi ve Docker katmanlar\u0131n\u0131n yeniden olu\u015fturulmas\u0131, de\u011ferli zaman kayb\u0131na ve operasyonel maliyetlerin artmas\u0131na neden olabilir.<\/p>\n
Peki, bu sorunu nas\u0131l a\u015fabiliriz? AWS Elastic Container Registry (ECR) gibi bir konteyner kay\u0131t defterini uzak bir \u00f6nbellek olarak kullanarak, Docker build s\u00fcre\u00e7lerinizi \u00f6nemli \u00f6l\u00e7\u00fcde h\u0131zland\u0131rman\u0131z m\u00fcmk\u00fcn. Bu teknik sayesinde, CodeBuild ortam\u0131 her seferinde t\u00fcm Docker katmanlar\u0131n\u0131 s\u0131f\u0131rdan olu\u015fturmak yerine, daha \u00f6nce ECR’a y\u00fcklenmi\u015f olan katmanlar\u0131 yeniden kullanabilir. Bu y\u00f6ntem, \u00f6zellikle b\u00fcy\u00fck ba\u011f\u0131ml\u0131l\u0131k setlerine sahip veya s\u0131k s\u0131k g\u00fcncellenen projelerde %25 veya daha fazla h\u0131zlanma sa\u011flayarak geli\u015ftirme d\u00f6ng\u00fclerinizi k\u0131salt\u0131r ve ekiplerinizin daha verimli \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r. Gelin, bu etkili stratejiyi ad\u0131m ad\u0131m inceleyelim ve CodeBuild Docker build’lerinizi nas\u0131l turbo \u015farj edece\u011finizi ke\u015ffedelim.<\/p>\n
Bir\u00e7ok geli\u015ftirici, AWS CodeBuild’de Docker imajlar\u0131 olu\u015ftururken build s\u00fcrelerinin beklenenden daha uzun s\u00fcrd\u00fc\u011f\u00fcn\u00fc fark eder. Bu durumun temel nedenlerini anlamak, \u00e7\u00f6z\u00fcm yollar\u0131 geli\u015ftirmek i\u00e7in ilk ad\u0131md\u0131r. \u00d6ncelikle, Docker’\u0131n katmanl\u0131 (layered) mimarisi bu s\u00fcre\u00e7te b\u00fcy\u00fck rol oynar. Her bir Bu temiz ba\u015flang\u0131\u00e7, CodeBuild’in g\u00fcvenli\u011fi ve izolasyonu a\u00e7\u0131s\u0131ndan harika olsa da, performans a\u00e7\u0131s\u0131ndan bir darbo\u011faz yarat\u0131r. Her build i\u015flemi, Dockerfile’daki t\u00fcm ad\u0131mlar\u0131, ba\u011f\u0131ml\u0131l\u0131k indirmeleri ve derleme s\u00fcre\u00e7lerini ba\u015ftan sona yeniden y\u00fcr\u00fctmek zorunda kal\u0131r. \u00d6rne\u011fin, bir Node.js uygulamas\u0131nda Uzman \u0130pucu: Docker’\u0131n katmanl\u0131 yap\u0131s\u0131, \u00f6nbellekleme i\u00e7in anahtar bir mekanizmad\u0131r. De\u011fi\u015fmeyen katmanlar yeniden kullan\u0131larak build s\u00fcresi \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131labilir. Bu nedenle, Dockerfile’\u0131n\u0131z\u0131 tasarlarken daha az s\u0131kl\u0131kta de\u011fi\u015fen ad\u0131mlar\u0131 (\u00f6rne\u011fin ba\u011f\u0131ml\u0131l\u0131k kurulumu) daha yukar\u0131ya, daha s\u0131k de\u011fi\u015fen ad\u0131mlar\u0131 (\u00f6rne\u011fin uygulama kodu kopyalama) daha a\u015fa\u011f\u0131ya yerle\u015ftirmek ak\u0131ll\u0131ca olacakt\u0131r.<\/p>\n<\/div>\n CodeBuild’in yerel \u00f6nbellekleme se\u00e7enekleri (\u00f6rne\u011fin S3 \u00f6nbelleklemesi), dosya sistemi d\u00fczeyinde \u00e7al\u0131\u015f\u0131r ve genellikle Docker katmanlar\u0131n\u0131n \u00f6nbelleklenmesi i\u00e7in yeterince optimize de\u011fildir. S3’e s\u0131k\u0131\u015ft\u0131r\u0131lm\u0131\u015f dosyalar g\u00f6ndermek ve oradan \u00e7ekmek de ek bir overhead yarat\u0131r. Bu y\u00fczden, Docker’\u0131n kendi \u00f6nbellekleme mekanizmalar\u0131ndan tam olarak faydalanmak i\u00e7in daha geli\u015fmi\u015f bir stratejiye ihtiyac\u0131m\u0131z var: Uzak Docker kay\u0131t defterlerini \u00f6nbellek olarak kullanmak. ECR, bu senaryo i\u00e7in ideal bir \u00e7\u00f6z\u00fcmd\u00fcr, \u00e7\u00fcnk\u00fc Docker imajlar\u0131n\u0131 ve onlar\u0131n alt\u0131ndaki katmanlar\u0131 depolamak \u00fczere tasarlanm\u0131\u015ft\u0131r. Bu sayede, CodeBuild bir \u00f6nceki ba\u015far\u0131l\u0131 build’den kalan katmanlar\u0131 ECR’dan \u00e7ekerek, sadece de\u011fi\u015fen katmanlar\u0131 yeniden olu\u015fturabilir. Bu y\u00f6ntem, her build i\u00e7in %25’ten \u00e7ok daha fazla h\u0131zlanma potansiyeli sunar, \u00f6zellikle ba\u011f\u0131ml\u0131l\u0131k katmanlar\u0131n\u0131n \u00e7o\u011fu zaman sabit kald\u0131\u011f\u0131 durumlarda.<\/p>\n AWS ECR’\u0131 (Elastic Container Registry) uzak bir Docker \u00f6nbelle\u011fi olarak kullanma fikri, Docker’\u0131n kendi yerle\u015fik \u00f6nbellekleme mekanizmas\u0131n\u0131, bulut ortam\u0131na ta\u015f\u0131ma prensibine dayan\u0131r. Bu stratejinin merkezinde Temel olarak, Docker imajlar\u0131 bir dizi salt okunur katmandan olu\u015fur. Her katman, Dockerfile’daki bir komuta kar\u015f\u0131l\u0131k gelir. \u00d6rne\u011fin, bir Uzman \u0130pucu: Bir sonraki CodeBuild \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, Bu stratejinin etkinli\u011fi, Dockerfile’\u0131n\u0131z\u0131n tasar\u0131m\u0131na da ba\u011fl\u0131d\u0131r. S\u0131k de\u011fi\u015fen kodlar\u0131 (\u00f6rne\u011fin uygulama kaynak kodunu) Dockerfile’\u0131n alt katmanlar\u0131na yerle\u015ftirmek, daha az de\u011fi\u015fen ba\u011f\u0131ml\u0131l\u0131klar\u0131 (\u00f6rne\u011fin temel i\u015fletim sistemi, paket y\u00f6neticisi kurulumlar\u0131) ise \u00fcst katmanlara yerle\u015ftirmek, \u00f6nbellek isabet oran\u0131n\u0131 art\u0131r\u0131r. B\u00f6ylece, k\u00fc\u00e7\u00fck bir kod de\u011fi\u015fikli\u011fi yapt\u0131\u011f\u0131n\u0131zda, Docker sadece en alttaki katmanlar\u0131 yeniden in\u015fa ederken, yukar\u0131daki a\u011f\u0131r ba\u011f\u0131ml\u0131l\u0131k katmanlar\u0131n\u0131 ECR’dan \u00e7ekti\u011fi \u00f6nceki imajdan kullanmaya devam edebilir. Sonu\u00e7 olarak, bu y\u00f6ntem, her CodeBuild \u00e7al\u0131\u015fmas\u0131nda sanal makinenin diskine veya S3’e ba\u011fl\u0131 kalmadan, tamamen bulut tabanl\u0131, merkezi ve s\u00fcrekli g\u00fcncel bir Docker katman \u00f6nbelleklemesi sa\u011flar.<\/p>\n AWS CodeBuild ve ECR’\u0131 entegre ederek Docker build s\u00fcrelerinizi h\u0131zland\u0131rmak i\u00e7in belirli ad\u0131mlar\u0131 takip etmeniz gerekir. Bu s\u00fcre\u00e7, hem AWS kaynaklar\u0131n\u0131n yap\u0131land\u0131r\u0131lmas\u0131n\u0131 hem de \u0130lk olarak, Docker imajlar\u0131n\u0131z\u0131 depolayaca\u011f\u0131n\u0131z bir Amazon ECR deposuna ihtiyac\u0131n\u0131z var. Bu depo, ayn\u0131 zamanda uzak \u00f6nbelle\u011finiz olarak da i\u015flev g\u00f6recektir.<\/p>\n AWS Y\u00f6netim Konsolu \u00fczerinden:<\/p>\n AWS CLI \u00fczerinden:<\/p>\n <\/code><\/p>\n Bu komut, Mevcut veya yeni bir CodeBuild projenizin ECR ile etkile\u015fime ge\u00e7ebilmesi i\u00e7in baz\u0131 yap\u0131land\u0131rmalara ihtiyac\u0131 vard\u0131r:<\/p>\n Genellikle \u015eimdi en kritik k\u0131sma geliyoruz: <\/code><\/p>\n Yukar\u0131daki Bu ad\u0131mlar\u0131 uygulayarak, CodeBuild Docker build'lerinizin %25 veya daha fazla h\u0131zland\u0131\u011f\u0131n\u0131 g\u00f6receksiniz. \u00d6zellikle ba\u011f\u0131ml\u0131l\u0131k katmanlar\u0131n\u0131n s\u0131k de\u011fi\u015fmedi\u011fi senaryolarda bu kazan\u00e7 \u00e7ok daha y\u00fcksek olabilir.<\/p>\n Bir web uygulamas\u0131 projesi \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131z\u0131 hayal edin. Bu, bir Node.js tabanl\u0131 API backend'i ve React tabanl\u0131 bir frontend'i i\u00e7eren tipik bir mikroservis mimarisi olabilir. Her iki uygulama da kendi Docker imajlar\u0131na sahiptir ve AWS CodePipeline \u00fczerinden CodeBuild kullan\u0131larak derlenip ECR'a g\u00f6nderilir. Uygulaman\u0131z b\u00fcy\u00fcd\u00fck\u00e7e, ba\u011f\u0131ml\u0131l\u0131k say\u0131s\u0131 artt\u0131k\u00e7a ve ekipteki geli\u015ftiriciler s\u0131k s\u0131k kod g\u00f6nderdik\u00e7e, CodeBuild'deki Docker derleme s\u00fcreleri sinir bozucu derecede uzamaya ba\u015flar. Diyelim ki, her bir imaj\u0131n derlenmesi ba\u015flang\u0131\u00e7ta 8-10 dakika s\u00fcr\u00fcyordu.<\/p>\n Mevcut Durum (\u00d6nbelleksiz):<\/b><\/p>\n Her commit sonras\u0131, CodeBuild yeni bir ortam ba\u015flat\u0131r. Her bir Dockerfile i\u00e7in:<\/p>\n Bu s\u00fcre\u00e7, backend ve frontend i\u00e7in ayr\u0131 ayr\u0131 tekrarland\u0131\u011f\u0131nda, her deploy pipeline'\u0131 i\u00e7in toplamda 16-20 dakika gibi bir s\u00fcre harcar. Bu, g\u00fcn i\u00e7inde birka\u00e7 commit yap\u0131ld\u0131\u011f\u0131nda saatlere denk gelebilir ve geli\u015ftiricilerin geri bildirim d\u00f6ng\u00fcs\u00fcn\u00fc uzat\u0131r.<\/p>\n ECR ile Uzak \u00d6nbellekleme Uygulamas\u0131:<\/b><\/p>\n Yukar\u0131da anlat\u0131lan ad\u0131mlar\u0131 izleyerek, hem backend hem de frontend Dockerfile'lar\u0131m\u0131z i\u00e7in <\/code><\/p>\n Ve buna uygun olarak g\u00fcncellenmi\u015f <\/code><\/p>\n Sonu\u00e7lar ve Metrikler:<\/b><\/p>\n Bu entegrasyonu uygulad\u0131ktan sonra, build s\u00fcrelerini tekrar \u00f6l\u00e7t\u00fc\u011f\u00fcm\u00fczde \u015funlar\u0131 g\u00f6zlemleriz:<\/p>\n Uzman \u0130pucu: Dockerfile'\u0131n\u0131zda Bu vaka analizi, ECR'\u0131 uzak \u00f6nbellek olarak kullanman\u0131n, CodeBuild'deki Docker derleme s\u00fcreleri \u00fczerinde ne kadar \u00f6nemli bir etki yaratabilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Geli\u015ftiriciler, daha h\u0131zl\u0131 geri bildirim d\u00f6ng\u00fcleri sayesinde daha verimli \u00e7al\u0131\u015fabilir, CI\/CD pipeline'lar\u0131 daha h\u0131zl\u0131 tamamlan\u0131r ve genel olarak geli\u015ftirme s\u00fcreci \u00e7ok daha ak\u0131c\u0131 hale gelir. Bu optimizasyon, \u00f6zellikle b\u00fcy\u00fck ekiplerde ve s\u0131k entegrasyon yap\u0131lan projelerde operasyonel maliyetleri de d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n ECR'\u0131 uzak \u00f6nbellek olarak kullanmak, Docker build'lerinizi h\u0131zland\u0131rmak i\u00e7in harika bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r. Ancak, bu tekni\u011fi daha da geli\u015ftirmek ve build s\u00fcre\u00e7lerinizi optimize etmek i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve p\u00fcf noktalar\u0131 mevcuttur:<\/p>\n Docker'\u0131n yeni nesil build motoru olan BuildKit, performans\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131ran ve daha geli\u015fmi\u015f \u00f6nbellekleme yetenekleri sunan bir dizi \u00f6zellik ile birlikte gelir. CodeBuild'de BuildKit'i etkinle\u015ftirmek genellikle sadece bir ortam de\u011fi\u015fkeni ayarlamak kadar basittir:<\/p>\n <\/code><\/p>\n BuildKit'in avantajlar\u0131 \u015funlard\u0131r:<\/p>\n \u00c7ok a\u015famal\u0131 Dockerfile'lar, final imaj\u0131n\u0131z\u0131n boyutunu k\u00fc\u00e7\u00fcltmenin ve build s\u00fcrelerini optimize etmenin harika bir yoludur. Bu y\u00f6ntemle, uygulaman\u0131z\u0131 derlemek veya ba\u011f\u0131ml\u0131l\u0131klar\u0131 indirmek i\u00e7in bir \"builder\" a\u015famas\u0131 kullanabilir, ard\u0131ndan sadece gerekli \u00e7al\u0131\u015fma zaman\u0131 dosyalar\u0131n\u0131 son, hafif bir imaja kopyalayabilirsiniz. Bu, final imaj\u0131n\u0131zdaki katman say\u0131s\u0131n\u0131 azalt\u0131r ve her build'de daha az veri transferi anlam\u0131na gelir.<\/p>\n <\/code><\/p>\n Bu yakla\u015f\u0131mla, Farkl\u0131 branch'ler veya farkl\u0131 t\u00fcrdeki build'ler (\u00f6rn. test, geli\u015ftirme, \u00fcretim) i\u00e7in farkl\u0131 \u00f6nbellek stratejileri d\u00fc\u015f\u00fcnebilirsiniz. \u00d6rne\u011fin:<\/p>\n Bazen bilin\u00e7li olarak \u00f6nbelle\u011fi temizlemek isteyebilirsiniz (\u00f6rn. temel imaj g\u00fcncellemesi sonras\u0131 veya ba\u011f\u0131ml\u0131l\u0131k sorunlar\u0131n\u0131 gidermek i\u00e7in). Bunun i\u00e7in Her build sonras\u0131 CodeBuild'in CloudWatch'a g\u00f6nderdi\u011fi metrikleri (\u00f6rn. Bu ileri d\u00fczey teknikleri birle\u015ftirerek, AWS CodeBuild Docker build'lerinizin sadece %25 de\u011fil, %50'ye varan veya daha fazla h\u0131zlanmas\u0131n\u0131 sa\u011flayabilir, geli\u015ftirme d\u00f6ng\u00fclerinizi \u00f6nemli \u00f6l\u00e7\u00fcde iyile\u015ftirebilirsiniz.<\/p>\n Bu teknik makalede Docker build h\u0131zland\u0131rma \u00fczerine odaklanm\u0131\u015f olsak da, i\u00e7eri\u011fin okuyuculara en iyi \u015fekilde ula\u015fmas\u0131 i\u00e7in mobil uyumlu ve performansl\u0131 bir HTML sunumu kritik \u00f6neme sahiptir. Kullan\u0131c\u0131lar makaleyi farkl\u0131 cihazlardan (masa\u00fcst\u00fc, tablet, mobil) okuyabilir ve k\u00f6t\u00fc bir kullan\u0131c\u0131 deneyimi, de\u011ferli i\u00e7eri\u011fin bile g\u00f6z ard\u0131 edilmesine yol a\u00e7abilir.<\/p>\n Mobil uyumlu HTML tasarlarken dikkat etmemiz gereken temel prensipler \u015funlard\u0131r:<\/p>\n <\/code> <\/code><\/li>\n <\/code><\/li>\n Web Performans\u0131 \u0130pu\u00e7lar\u0131:<\/b><\/p>\n Mobil uyumluluk kadar, web sayfas\u0131n\u0131n h\u0131zl\u0131 y\u00fcklenmesi de \u00f6nemlidir:<\/p>\n Bu prensiplere ba\u011fl\u0131 kalarak, makalemizin i\u00e7eri\u011fi gibi teknik bilgilerin, okuyuculara kesintisiz ve keyifli bir deneyimle ula\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flayabiliriz. Mobil uyumluluk ve performans, g\u00fcn\u00fcm\u00fcz internet kullan\u0131c\u0131lar\u0131 i\u00e7in bir l\u00fcks de\u011fil, bir gerekliliktir.<\/p>\n Bu makale boyunca, AWS CodeBuild'deki Docker derleme s\u00fcrelerinin neden uzad\u0131\u011f\u0131n\u0131, ECR'\u0131 uzak bir \u00f6nbellek olarak kullanarak bu sorunu nas\u0131l a\u015fabilece\u011fimizi ve bu entegrasyonun ad\u0131m ad\u0131m nas\u0131l yap\u0131land\u0131r\u0131laca\u011f\u0131n\u0131 detayl\u0131ca inceledik. G\u00f6rd\u00fck ki, \u00d6zellikle Docker'\u0131n katmanl\u0131 mimarisinden faydalanarak, de\u011fi\u015fmeyen ba\u011f\u0131ml\u0131l\u0131k katmanlar\u0131n\u0131 her seferinde yeniden indirmek ve olu\u015fturmak yerine ECR'dan \u00e7ekmek, zaman ve kaynak tasarrufu sa\u011flar. BuildKit kullan\u0131m\u0131, \u00e7ok a\u015famal\u0131 Dockerfile'lar, Bu teknikleri uygulayarak, sadece CodeBuild maliyetlerinizi d\u00fc\u015f\u00fcrmekle kalmayacak, ayn\u0131 zamanda geli\u015ftirici deneyimini de \u00f6nemli \u00f6l\u00e7\u00fcde iyile\u015ftireceksiniz. Uzun build s\u00fcrelerinin neden oldu\u011fu bekleme s\u00fcreleri azalacak, ekipleriniz daha h\u0131zl\u0131 iterasyon yapabilecek ve daha az kesintiyle \u00e7al\u0131\u015fabilecektir. Gelecekte, Docker build s\u00fcre\u00e7lerinizi daha da optimize etmek i\u00e7in BuildKit'in geli\u015fmi\u015f \u00f6nbellekleme \u00f6zelliklerini daha derinlemesine ke\u015ffetmeyi ve farkl\u0131 build profiliniz i\u00e7in \u00f6zel \u00f6nbellekleme stratejileri olu\u015fturmay\u0131 d\u00fc\u015f\u00fcnebilirsiniz. Ayr\u0131ca, CloudWatch metriklerini d\u00fczenli olarak izlemek, yap\u0131lan optimizasyonlar\u0131n s\u00fcrd\u00fcr\u00fclebilirli\u011fini ve etkinli\u011fini garanti alt\u0131na alacakt\u0131r.<\/p>\n ECR \u00f6nbelleklemesi, asl\u0131nda ECR'da Docker imaj\u0131 depolama maliyetidir. AWS, depolanan her GB ba\u015f\u0131na ayl\u0131k bir \u00fccret al\u0131r ve veri transferi i\u00e7in de \u00fccretlendirme yapabilir. Ancak, genellikle build s\u00fcrelerinden ve geli\u015ftirici verimlili\u011finden elde edilen kazan\u00e7, depolama maliyetinden \u00e7ok daha fazlad\u0131r. Maliyeti d\u00fc\u015f\u00fcrmek i\u00e7in ECR ya\u015fam d\u00f6ng\u00fcs\u00fc politikalar\u0131 kullanarak eski veya kullan\u0131lmayan imajlar\u0131 otomatik olarak temizleyebilirsiniz.<\/p>\n Evet, genellikle her benzersiz Docker imaj\u0131 i\u00e7in (\u00f6rne\u011fin, bir mikroservisin backend'i, frontend'i veya bir yard\u0131mc\u0131 servis) ayr\u0131 bir ECR deposu kullanmak en iyi uygulamad\u0131r. Bu, imajlar\u0131n y\u00f6netimini kolayla\u015ft\u0131r\u0131r, izinleri daha iyi ay\u0131rman\u0131za olanak tan\u0131r ve \u00f6nbellekleme stratejilerinin daha temiz kalmas\u0131n\u0131 sa\u011flar. Ancak, \u00e7ok say\u0131da k\u00fc\u00e7\u00fck yard\u0131mc\u0131 imaj\u0131n\u0131z varsa, bunlar\u0131 tek bir depoda farkl\u0131 etiketlerle y\u00f6netmek de bir se\u00e7enek olabilir.<\/p>\n CodeBuild'in ECR'dan imaj \u00e7ekip g\u00f6nderebilmesi i\u00e7in IAM hizmet rol\u00fcne en az\u0131ndan a\u015fa\u011f\u0131daki izinler gereklidir: \u00d6nbelle\u011fi manuel olarak temizlemek i\u00e7in, BuildKit, Docker'\u0131n yeni nesil build motorudur ve bir\u00e7ok \u00f6nemli avantaj sunar. Paralel build yetene\u011fi ile ba\u011f\u0131ms\u0131z Dockerfile ad\u0131mlar\u0131n\u0131 ayn\u0131 anda y\u00fcr\u00fctebilir, b\u00f6ylece toplam build s\u00fcresini k\u0131salt\u0131r. Daha ak\u0131ll\u0131 ve ince taneli \u00f6nbellekleme mekanizmalar\u0131na sahiptir, sadece katmanlar\u0131 de\u011fil, komutlar\u0131n \u00e7\u0131kt\u0131s\u0131n\u0131 da \u00f6nbelle\u011fe alabilir. Ayr\u0131ca, daha az disk alan\u0131 kullan\u0131r ve harici \u00f6nbellek kaynaklar\u0131n\u0131 daha esnek bir \u015fekilde kullanma imkan\u0131 sunar, bu da genel build performans\u0131n\u0131 ve verimlili\u011fi \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r.<\/p>\n","protected":false},"excerpt":{"rendered":"AWS CodeBuild’de Docker yap\u0131lar\u0131n\u0131z yava\u015f m\u0131 ilerliyor? Bu makale, ECR’\u0131 uzak \u00f6nbellek olarak kullanarak build s\u00fcrelerinizi %25 veya…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1407],"tags":[],"class_list":{"0":"post-32345","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-docker","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nRUN<\/code>, COPY<\/code> veya ADD<\/code> komutu Dockerfile’\u0131n\u0131zda yeni bir katman olu\u015fturur. Bu katmanlar \u00f6nbelle\u011fe al\u0131nabilir ve de\u011fi\u015fiklik yap\u0131lmad\u0131\u011f\u0131 s\u00fcrece yeniden kullan\u0131labilir. Ancak CodeBuild gibi CI\/CD ortamlar\u0131nda, varsay\u0131lan olarak her build oturumu temiz bir ortamda ba\u015flar. Bu, daha \u00f6nce olu\u015fturulmu\u015f olan hi\u00e7bir Docker katman\u0131n\u0131n yerel olarak mevcut olmad\u0131\u011f\u0131 anlam\u0131na gelir.<\/p>\nnpm install<\/code> komutu her seferinde t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131 internetten yeniden indirecek, bu da hem zaman hem de a\u011f bant geni\u015fli\u011fi t\u00fcketimine yol a\u00e7acakt\u0131r. Benzer \u015fekilde, b\u00fcy\u00fck bir Python projesinde pip install -r requirements.txt<\/code> veya bir Java projesinde Maven\/Gradle build’leri de ayn\u0131 sorunu yarat\u0131r. Bu durum, \u00f6zellikle s\u0131k commit yap\u0131lan projelerde veya birden fazla mikroservisi olan geni\u015f sistemlerde birikerek ciddi bir maliyet ve zaman israf\u0131na d\u00f6n\u00fc\u015febilir.<\/p>\nECR Uzak \u00d6nbellek Olarak Nas\u0131l \u00c7al\u0131\u015f\u0131r? Temel Kavramlar Nelerdir?<\/h2>\n
docker build --cache-from<\/code> komutu yer al\u0131r. Bu komut, Docker daemon’\u0131na, imaj\u0131 olu\u015ftururken belirli bir imaj\u0131 \u00f6nbellek kayna\u011f\u0131 olarak kullanmas\u0131n\u0131 s\u00f6yler. Yani, yeni bir imaj in\u015fa edilirken, Dockerfile’daki ad\u0131mlar\u0131n \u00e7\u0131kt\u0131s\u0131n\u0131 mevcut bir imaj\u0131n katmanlar\u0131yla kar\u015f\u0131la\u015ft\u0131r\u0131r ve e\u011fer bir katman de\u011fi\u015fmemi\u015fse, bu katman\u0131 yeniden olu\u015fturmak yerine var olan\u0131 kullan\u0131r.<\/p>\nFROM<\/code> komutu temel bir katman getirir, RUN apt-get update<\/code> ba\u015fka bir katman ekler, COPY . \/app<\/code> bir ba\u015fkas\u0131n\u0131 ekler. Bu katmanlar benzersiz bir hash ile tan\u0131mlan\u0131r. E\u011fer bir komut veya onun ba\u011f\u0131ml\u0131l\u0131klar\u0131 (\u00f6rne\u011fin kopyalanan dosyalar) de\u011fi\u015fmezse, Docker o katman\u0131 yeniden olu\u015fturmak yerine \u00f6nbellekten \u00e7ekebilir. \u0130\u015fte bu noktada ECR devreye giriyor. CodeBuild, her ba\u015far\u0131l\u0131 build sonras\u0131 olu\u015fan Docker imaj\u0131n\u0131 ECR’a g\u00f6nderdi\u011finde, bu imaj\u0131n t\u00fcm katmanlar\u0131 da ECR’da saklanm\u0131\u015f olur.<\/p>\n--cache-from<\/code> komutu birden fazla imaj\u0131 referans g\u00f6sterebilir. E\u011fer uygulaman\u0131z\u0131n farkl\u0131 s\u00fcr\u00fcmleri i\u00e7in ayr\u0131 ECR etiketleri kullan\u0131yorsan\u0131z, en g\u00fcncel iki veya \u00fc\u00e7 imaj\u0131 \u00f6nbellek kayna\u011f\u0131 olarak belirtmek, \u00f6nbellek isabet oran\u0131n\u0131 art\u0131rabilir.<\/p>\n<\/div>\npre_build<\/code> a\u015famas\u0131nda, \u00f6nceki ba\u015far\u0131l\u0131 build’in imaj\u0131n\u0131 ECR’dan \u00e7ekeriz. Bu \u00e7ekilen imaj daha sonra docker build --cache-from your_ecr_repo\/your_image:latest<\/code> komutuyla yeni build s\u00fcrecine \u00f6nbellek kayna\u011f\u0131 olarak sa\u011flan\u0131r. Docker daemon’\u0131, Dockerfile’daki her ad\u0131m\u0131 incelerken, \u00f6ncelikle bu \u00e7ekilmi\u015f imaj\u0131n katmanlar\u0131n\u0131 kontrol eder. E\u011fer bir katman ayn\u0131ysa (yani Dockerfile’daki ilgili ad\u0131m ve ba\u011flamdaki dosyalar de\u011fi\u015fmemi\u015fse), Docker o katman\u0131 ECR’dan zaten \u00e7ekilmi\u015f olan imajdan alarak yeniden derleme i\u015flemini atlar. Bu, \u00f6zellikle FROM<\/code>, RUN apt-get update && apt-get install -y ...<\/code> gibi pahal\u0131 ba\u011f\u0131ml\u0131l\u0131k kurulumu ad\u0131mlar\u0131 i\u00e7in b\u00fcy\u00fck bir zaman tasarrufu sa\u011flar.<\/p>\nAd\u0131m Ad\u0131m Kurulum: CodeBuild ve ECR Entegrasyonu<\/h2>\n
buildspec.yml<\/code> dosyan\u0131zda uygun komutlar\u0131 kullanmay\u0131 i\u00e7erir.<\/p>\nAd\u0131m 1: ECR Deposu Olu\u015fturma<\/h3>\n
\n
my-app-image<\/code>).<\/li>\n\naws ecr create-repository \\\n --repository-name my-app-image \\\n --image-tag-mutability MUTABLE \\\n --image-scanning-configuration scanOnPush=true\n<\/pre>\nmy-app-image<\/code> ad\u0131nda bir ECR deposu olu\u015fturur. MUTABLE<\/code> etiket mutability'si, latest<\/code> gibi etiketlerin \u00fczerine yaz\u0131lmas\u0131na izin verir ki bu \u00f6nbellekleme senaryomuz i\u00e7in idealdir.<\/p>\nAd\u0131m 2: CodeBuild Projenizi Yap\u0131land\u0131rma<\/h3>\n
\n
\n
ecr:GetAuthorizationToken<\/code><\/li>\necr:BatchCheckLayerAvailability<\/code><\/li>\necr:GetDownloadUrlForLayer<\/code><\/li>\necr:BatchGetImage<\/code><\/li>\necr:InitiateLayerUpload<\/code><\/li>\necr:UploadLayerPart<\/code><\/li>\necr:CompleteLayerUpload<\/code><\/li>\necr:PutImage<\/code><\/li>\n<\/ul>\nAmazonEC2ContainerRegistryPowerUser<\/code> veya AmazonEC2ContainerRegistryFullAccess<\/code> politikalar\u0131n\u0131 eklemek yeterli olacakt\u0131r, ancak en iyi uygulama ilkesiyle en az ayr\u0131cal\u0131k prensibine g\u00f6re \u00f6zel bir politika olu\u015fturman\u0131z \u00f6nerilir.<\/li>\naws\/codebuild\/standard:5.0<\/code> veya \u00fcst\u00fc). Ayr\u0131ca, \"Privileged\" (Ayr\u0131cal\u0131kl\u0131) modu etkinle\u015ftirmeniz gerekir, \u00e7\u00fcnk\u00fc Docker daemon'\u0131 bu modda \u00e7al\u0131\u015f\u0131r.<\/li>\nAd\u0131m 3:
buildspec.yml<\/code> Dosyan\u0131z\u0131 Optimize Etme<\/h3>\nbuildspec.yml<\/code> dosyan\u0131z\u0131, ECR'\u0131 uzak \u00f6nbellek olarak kullanacak \u015fekilde d\u00fczenlemek. A\u015fa\u011f\u0131daki \u00f6rnek, temel bir Node.js uygulamas\u0131n\u0131 varsayarak haz\u0131rlanm\u0131\u015ft\u0131r.<\/p>\n\nversion: 0.2\n\nphases:\n pre_build:\n commands:\n - echo \"Docker login i\u015flemi ba\u015flat\u0131l\u0131yor...\"\n - AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)\n - ECR_REPO_NAME=\"my-app-image\" # ECR depo ad\u0131n\u0131z\u0131 buraya yaz\u0131n\n - ECR_URI=\"${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com\/${ECR_REPO_NAME}\"\n - $(aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com)\n - echo \"ECR'dan \u00f6nceki imaj \u00e7ekiliyor (e\u011fer varsa) ve \u00f6nbellek olarak kullan\u0131lacak...\"\n - docker pull $ECR_URI:latest || true # \u00d6nceki imaj\u0131 \u00e7ek, yoksa hata vermesin\n\n build:\n commands:\n - echo \"Docker imaj\u0131 in\u015fa ediliyor, ECR'dan \u00f6nbellek kullan\u0131larak...\"\n - docker build --cache-from $ECR_URI:latest -t $ECR_URI:latest .\n - echo \"Build tamamland\u0131.\"\n\n post_build:\n commands:\n - echo \"Yeni Docker imaj\u0131 ECR'a g\u00f6nderiliyor...\"\n - docker push $ECR_URI:latest\n - echo \"\u0130maj ECR'a ba\u015far\u0131yla g\u00f6nderildi.\"\n<\/pre>\nbuildspec.yml<\/code> dosyas\u0131n\u0131 inceleyelim:<\/p>\n\n
pre_build<\/code>:<\/b>\n\n
aws ecr get-login-password<\/code> komutu ile yap\u0131l\u0131r.<\/li>\ndocker pull $ECR_URI:latest || true<\/code> komutu ile ECR'daki en son imaj\u0131 \u00e7ekmeye \u00e7al\u0131\u015f\u0131yoruz. || true<\/code> k\u0131sm\u0131, e\u011fer ECR'da hen\u00fcz bir imaj yoksa komutun ba\u015far\u0131s\u0131z olmas\u0131n\u0131 engeller ve build'in devam etmesini sa\u011flar. Bu \u00e7ekilen imaj, bir sonraki a\u015famada \u00f6nbellek olarak kullan\u0131lacakt\u0131r.<\/li>\n<\/ul>\n<\/li>\nbuild<\/code>:<\/b>\n\n
docker build --cache-from $ECR_URI:latest -t $ECR_URI:latest .<\/code> komutu burada sihirbazl\u0131\u011f\u0131 yap\u0131yor. --cache-from<\/code> bayra\u011f\u0131, Docker'a ECR'dan \u00e7ekti\u011fimiz imaj\u0131 ($ECR_URI:latest<\/code>) \u00f6nbellek olarak kullanmas\u0131n\u0131 s\u00f6yler. Docker, bu imaj\u0131n katmanlar\u0131n\u0131 kontrol ederek, de\u011fi\u015fmeyen ad\u0131mlar\u0131 yeniden in\u015fa etmek yerine mevcut katmanlar\u0131 kullan\u0131r.<\/li>\n<\/ul>\n<\/li>\npost_build<\/code>:<\/b>\n\n
$ECR_URI:latest<\/code>) ECR'a geri g\u00f6nderiyoruz. Bu, bir sonraki build i\u00e7in yeni bir \u00f6nbellek imaj\u0131 sa\u011flar.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nGer\u00e7ek D\u00fcnya Senaryosu: Bir Web Uygulamas\u0131n\u0131n Derlenme S\u00fcrecini \u0130yile\u015ftirme<\/h2>\n
\n
FROM node:18-alpine<\/code> gibi temel imaj\u0131 indirir.<\/li>\nCOPY package.json .<\/code> ve RUN npm install<\/code> komutlar\u0131 ile t\u00fcm Node.js ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 ba\u015ftan indirir ve kurar (bu genellikle en uzun ad\u0131md\u0131r, 5-7 dakika s\u00fcrebilir).<\/li>\nbuildspec.yml<\/code> dosyalar\u0131n\u0131 ECR'\u0131 \u00f6nbellek olarak kullanacak \u015fekilde g\u00fcncelliyoruz. \u0130\u015fte basitle\u015ftirilmi\u015f bir \u00f6rnek Dockerfile yap\u0131s\u0131:<\/p>\n\n# Backend API Dockerfile\nFROM node:18-alpine\n\nWORKDIR \/app\n\n# \u00d6nce ba\u011f\u0131ml\u0131l\u0131klar\u0131 kopyala ve kur (daha az de\u011fi\u015fen katman)\nCOPY package.json package-lock.json .\/\nRUN npm install --production\n\n# Sonra uygulama kodunu kopyala (daha s\u0131k de\u011fi\u015fen katman)\nCOPY . .\n\nCMD [\"node\", \"src\/index.js\"]\n<\/pre>\nbuildspec.yml<\/code> (yukar\u0131daki Ad\u0131m 3'teki genel yap\u0131y\u0131 kullan\u0131yoruz, sadece ECR_REPO_NAME de\u011fi\u015fiyor):<\/p>\n\n# Backend buildspec.yml (k\u0131salt\u0131lm\u0131\u015f)\n# ... pre_build faz\u0131 ECR login ve pull komutlar\u0131yla ...\n build:\n commands:\n - docker build --cache-from ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com\/my-backend-app:latest \\\n -t ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com\/my-backend-app:latest .\n# ... post_build faz\u0131 ECR push komutlar\u0131yla ...\n<\/pre>\n\n
package.json<\/code> (veya di\u011fer ba\u011f\u0131ml\u0131l\u0131k dosyalar\u0131) de\u011fi\u015fmemi\u015fse, npm install<\/code> ad\u0131m\u0131 tamamen \u00f6nbellekten \u00e7ekilir. Bu durumda, build s\u00fcresi 2-3 dakikaya kadar d\u00fc\u015fer<\/b>. Bu, orijinal s\u00fcrenin %60-75 oran\u0131nda bir azalmaya tekab\u00fcl eder!<\/li>\npackage.json<\/code> dosyas\u0131nda bir de\u011fi\u015fiklik yap\u0131l\u0131rsa (yeni bir ba\u011f\u0131ml\u0131l\u0131k ekleme gibi), npm install<\/code> katman\u0131 yeniden olu\u015fturulur. Ancak yine de, FROM<\/code> komutunun getirdi\u011fi temel katmanlar ve di\u011fer de\u011fi\u015fmeyen katmanlar \u00f6nbellekten al\u0131naca\u011f\u0131 i\u00e7in, build s\u00fcresi %10-20 daha k\u0131sa olabilir (\u00f6rn. 6-7 dakika).<\/li>\n<\/ul>\nnpm install<\/code> gibi maliyetli ad\u0131mlardan \u00f6nce sadece package.json<\/code> ve package-lock.json<\/code> dosyalar\u0131n\u0131 kopyalamak, bu katman\u0131 daha izole ve daha az de\u011fi\u015fir hale getirir. Uygulama kodundaki de\u011fi\u015fiklikler bu katman\u0131 ge\u00e7ersiz k\u0131lmaz.<\/p>\n<\/div>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve P\u00fcf Noktalar\u0131<\/h2>\n
BuildKit Kullan\u0131m\u0131 ile Daha H\u0131zl\u0131 ve Geli\u015fmi\u015f \u00d6nbellekleme<\/h3>\n
\nversion: 0.2\n\nenv:\n variables:\n DOCKER_BUILDKIT: 1 # BuildKit'i etkinle\u015ftirir\n\nphases:\n # ... (di\u011fer fazlar) ...\n build:\n commands:\n # BuildKit ile docker build komutu\n - docker build --cache-from $ECR_URI:latest -t $ECR_URI:latest .\n<\/pre>\n\n
--cache-to<\/code> ve --cache-from<\/code> se\u00e7enekleriyle daha esnek \u00f6nbellekleme stratejileri olu\u015fturman\u0131za olanak tan\u0131r.<\/li>\n<\/ul>\n\u00c7ok A\u015famal\u0131 Dockerfile'lar (Multi-Stage Builds)<\/h3>\n
\n# A\u015eAMA 1: Uygulamay\u0131 derle\nFROM node:18-alpine AS builder\n\nWORKDIR \/app\nCOPY package.json package-lock.json .\/\nRUN npm install\n\nCOPY . .\nRUN npm run build # React uygulamas\u0131n\u0131 derle\n\n# A\u015eAMA 2: Hafif \u00e7al\u0131\u015fma zaman\u0131 imaj\u0131\nFROM node:18-alpine\n\nWORKDIR \/app\nCOPY --from=builder \/app\/build .\/build # Sadece derlenmi\u015f \u00e7\u0131kt\u0131lar\u0131 kopyala\nCOPY --from=builder \/app\/node_modules .\/node_modules\nCOPY package.json .\n\nCMD [\"npm\", \"start\"]\n<\/pre>\nbuilder<\/code> a\u015famas\u0131ndaki a\u011f\u0131r ba\u011f\u0131ml\u0131l\u0131k indirme ve derleme s\u00fcre\u00e7leri, e\u011fer kod de\u011fi\u015fmediyse \u00f6nbellekten al\u0131nabilir ve nihai imaj\u0131n\u0131zda sadece gerekli dosyalar bulunur.<\/p>\n.dockerignore<\/code> Dosyas\u0131 Kullan\u0131m\u0131<\/h3>\n.dockerignore<\/code> dosyas\u0131, Docker build ba\u011flam\u0131na gereksiz dosyalar\u0131n (\u00f6rn. .git<\/code> klas\u00f6r\u00fc, node_modules<\/code> dizini, yerel geli\u015ftirme yap\u0131land\u0131rma dosyalar\u0131) dahil edilmesini engeller. Bu, build ba\u011flam\u0131n\u0131n boyutunu k\u00fc\u00e7\u00fclterek, Docker daemon'\u0131na g\u00f6nderilen veri miktar\u0131n\u0131 azalt\u0131r ve dolay\u0131s\u0131yla build s\u00fcresini h\u0131zland\u0131r\u0131r. Ayr\u0131ca, ba\u011flamdaki dosya say\u0131s\u0131 ne kadar az olursa, Docker katman \u00f6nbelleklemesi i\u00e7in de\u011fi\u015fiklikleri kontrol ederken o kadar h\u0131zl\u0131 \u00e7al\u0131\u015f\u0131r.<\/p>\n\u00d6nbellekleme Stratejileri ve \u0130maj Etiketleme<\/h3>\n
\n
develop<\/code>, main<\/code>) ayr\u0131 bir etiket kullanmak, branch'ler aras\u0131 kar\u0131\u015f\u0131kl\u0131\u011f\u0131 \u00f6nler ve her branch'in kendi kararl\u0131 \u00f6nbelle\u011fini s\u00fcrd\u00fcrmesine yard\u0131mc\u0131 olur. ${ECR_URI}:latest-${CODEBUILD_WEBHOOK_HEAD_REF}<\/code> gibi dinamik etiketler kullanabilirsiniz.<\/li>\nManuel \u00d6nbellek Invalidasyonu ve Temizli\u011fi<\/h3>\n
docker build --no-cache ...<\/code> bayra\u011f\u0131n\u0131 kullanabilirsiniz. Ayr\u0131ca, ECR'daki eski veya kullan\u0131lmayan imajlar\u0131 belirli aral\u0131klarla temizlemek, depolama maliyetlerini d\u00fc\u015f\u00fcrmeye yard\u0131mc\u0131 olur. ECR ya\u015fam d\u00f6ng\u00fcs\u00fc politikalar\u0131 (Lifecycle Policies) bu konuda otomasyon sa\u011flar.<\/p>\nCloudWatch Metrikleri ile \u0130zleme<\/h3>\n
Duration<\/code>) d\u00fczenli olarak izlemek, yapt\u0131\u011f\u0131n\u0131z optimizasyonlar\u0131n etkisini g\u00f6rmenizi sa\u011flar. Ortalama build s\u00fcrelerindeki azalmalar\u0131 g\u00f6zlemleyerek stratejilerinizin ba\u015far\u0131s\u0131n\u0131 \u00f6l\u00e7ebilirsiniz. Anormal y\u00fckseli\u015fler, \u00f6nbellek isabet oranlar\u0131nda bir sorun oldu\u011funu veya bir performans darbo\u011faz\u0131 olu\u015ftu\u011funu g\u00f6sterebilir.<\/p>\nMobil Uyumlu HTML ve Performans \u0130pu\u00e7lar\u0131 (Makalenin Sunumu \u0130\u00e7in)<\/h2>\n
\n
<\/code> b\u00f6l\u00fcm\u00fcnde bir viewport meta etiketi bulunmal\u0131d\u0131r. Bu, taray\u0131c\u0131lara sayfan\u0131n cihaz\u0131n geni\u015fli\u011fine g\u00f6re \u00f6l\u00e7eklenmesini s\u00f6yler.\n\n\n <\/pre>\n
\n Bu etiket, mobil cihazlarda metinlerin okunabilirli\u011fini ve \u00f6\u011felerin d\u00fczg\u00fcn hizalanmas\u0131n\u0131 sa\u011flar.<\/li>\nmax-width: 100%; height: auto;<\/code> gibi CSS kurallar\u0131 kullanarak g\u00f6r\u00fcnt\u00fclerin kapsay\u0131c\u0131lar\u0131na s\u0131\u011fmas\u0131n\u0131 sa\u011flay\u0131n.\n\nimg {\n max-width: 100%;\n height: auto;\n display: block; \/* Gereksiz bo\u015fluklar\u0131 engeller *\/\n}\n <\/pre>\n\n\/* Genel stil *\/\nbody {\n font-size: 16px;\n line-height: 1.6;\n}\n\n\/* K\u00fc\u00e7\u00fck ekranlar i\u00e7in (\u00f6rne\u011fin 768px alt\u0131) *\/\n@media (max-width: 768px) {\n body {\n font-size: 14px;\n }\n h2 {\n font-size: 1.8em;\n }\n .info-box {\n margin: 10px;\n padding: 15px;\n }\n}\n <\/pre>\nem<\/code>, rem<\/code> veya vw<\/code> (viewport width) birimlerini kullanarak yaz\u0131 tipi boyutlar\u0131n\u0131n ekran boyutuna g\u00f6re otomatik olarak ayarlanmas\u0131n\u0131 sa\u011flayabilirsiniz.<\/li>\n\n
async<\/code> veya defer<\/code> nitelikleriyle asenkron olarak y\u00fckleyerek render-blocking'i \u00f6nleyin.<\/li>\nSonu\u00e7 ve Gelecek Ad\u0131mlar<\/h2>\n
docker build --cache-from<\/code> komutunu ECR ile birle\u015ftirerek ve buildspec.yml<\/code> dosyas\u0131n\u0131 ak\u0131ll\u0131ca yap\u0131land\u0131rarak, build s\u00fcrelerinde %25 veya daha fazla kayda de\u011fer iyile\u015fmeler elde etmek m\u00fcmk\u00fcnd\u00fcr. Ger\u00e7ek d\u00fcnya senaryolar\u0131, bu optimizasyonun geli\u015ftirici \u00fcretkenli\u011fi ve CI\/CD pipeline'lar\u0131n\u0131n genel verimlili\u011fi \u00fczerindeki olumlu etkisini a\u00e7\u0131k\u00e7a ortaya koymu\u015ftur.<\/p>\n.dockerignore<\/code> dosyas\u0131 ve ak\u0131ll\u0131 etiketleme stratejileri gibi ileri d\u00fczey ipu\u00e7lar\u0131 ise bu kazan\u0131mlar\u0131 daha da art\u0131rman\u0131n yollar\u0131n\u0131 sunmaktad\u0131r. Unutulmamal\u0131d\u0131r ki, s\u00fcrekli entegrasyon ve da\u011f\u0131t\u0131m\u0131n amac\u0131, h\u0131zl\u0131 ve g\u00fcvenilir geri bildirim d\u00f6ng\u00fcleri sa\u011flamakt\u0131r. Daha h\u0131zl\u0131 Docker build'leri, bu amaca ula\u015fmada kritik bir rol oynar.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
1. ECR \u00f6nbelleklemesi ne kadar maliyetlidir?<\/h4>\n
2. Her Docker imaj\u0131 i\u00e7in ayr\u0131 bir ECR deposu mu kullanmal\u0131y\u0131m?<\/h4>\n
3.
buildspec.yml<\/code> dosyas\u0131nda hangi IAM izinleri gerekiyor?<\/h4>\necr:GetAuthorizationToken<\/code>, ecr:BatchCheckLayerAvailability<\/code>, ecr:GetDownloadUrlForLayer<\/code>, ecr:BatchGetImage<\/code> (pull i\u00e7in) ve ecr:InitiateLayerUpload<\/code>, ecr:UploadLayerPart<\/code>, ecr:CompleteLayerUpload<\/code>, ecr:PutImage<\/code> (push i\u00e7in). Genellikle AmazonEC2ContainerRegistryPowerUser<\/code> veya AmazonEC2ContainerRegistryFullAccess<\/code> y\u00f6netilen politikalar\u0131 bu izinleri kapsar, ancak g\u00fcvenlik a\u00e7\u0131s\u0131ndan \u00f6zel bir politika olu\u015fturman\u0131z \u00f6nerilir.<\/p>\n4. \u00d6nbellek temizli\u011fi nas\u0131l yap\u0131l\u0131r?<\/h4>\n
docker build<\/code> komutuna --no-cache<\/code> bayra\u011f\u0131n\u0131 ekleyebilirsiniz. Bu, Docker'\u0131n t\u00fcm katmanlar\u0131 s\u0131f\u0131rdan olu\u015fturmas\u0131n\u0131 sa\u011flar. ECR'daki eski imajlar\u0131 temizlemek i\u00e7in ise, AWS ECR ya\u015fam d\u00f6ng\u00fcs\u00fc politikalar\u0131n\u0131 kullanarak belirli bir ya\u015fa veya etiket say\u0131s\u0131na ula\u015fan imajlar\u0131n otomatik olarak silinmesini sa\u011flayabilirsiniz.<\/p>\n5. BuildKit kullanmak neden \u00f6nemlidir?<\/h4>\n