{"id":34033,"date":"2025-11-10T07:01:56","date_gmt":"2025-11-10T04:01:56","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/web-uygulamam\/"},"modified":"2025-11-10T07:01:56","modified_gmt":"2025-11-10T04:01:56","slug":"web-uygulamam","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/web-uygulamam\/","title":{"rendered":"Web Uygulamam"},"content":{"rendered":"

<\/p>\n

Kubernetes’te ConfigMap’leri Dinamik Olarak G\u00fcncelleme Rehberi<\/h1>\n

\n Modern bulut tabanl\u0131 uygulamalar\u0131n karma\u015f\u0131kl\u0131\u011f\u0131 artt\u0131k\u00e7a, yap\u0131land\u0131rma y\u00f6netiminin \u00f6nemi de katlanarak artmaktad\u0131r. \u00d6zellikle Kubernetes gibi kapsay\u0131c\u0131 orkestrasyon platformlar\u0131nda, uygulamalar\u0131n \u00e7al\u0131\u015fma zaman\u0131 ayarlar\u0131n\u0131, veritaban\u0131 ba\u011flant\u0131 bilgilerini veya API anahtarlar\u0131n\u0131 verimli ve hatas\u0131z bir \u015fekilde y\u00f6netmek kritik bir ihtiya\u00e7t\u0131r. Bu makalede, Kubernetes’teki ConfigMap kaynaklar\u0131n\u0131 bir volume olarak nas\u0131l ba\u011flayaca\u011f\u0131m\u0131z\u0131 ve bu yap\u0131land\u0131rma verilerini uygulamalar\u0131m\u0131z\u0131n \u00e7al\u0131\u015fma d\u00fczenini bozmadan, kesintisiz bir \u015fekilde nas\u0131l dinamik olarak g\u00fcncelleyebilece\u011fimizi ayr\u0131nt\u0131l\u0131 bir \u015fekilde inceleyece\u011fiz. Bu rehber, ister s\u0131f\u0131rdan ba\u015flayan bir DevOps m\u00fchendisi olun ister deneyimli bir Kubernetes kullan\u0131c\u0131s\u0131, her seviyeden okuyucuya hitap edecek \u015fekilde tasarlanm\u0131\u015ft\u0131r.\n<\/p>\n

\n G\u00fcn\u00fcm\u00fcz mikroservis mimarilerinde, her bir servisin kendine \u00f6zg\u00fc yap\u0131land\u0131rma ihtiya\u00e7lar\u0131 bulunur. Geli\u015ftirme, test, haz\u0131rl\u0131k ve \u00fcretim ortamlar\u0131 aras\u0131nda bu yap\u0131land\u0131rmalar s\u0131kl\u0131kla de\u011fi\u015fiklik g\u00f6sterir. Geleneksel yakla\u015f\u0131mlarda, bir yap\u0131land\u0131rma de\u011fi\u015fikli\u011fi genellikle uygulaman\u0131n yeniden da\u011f\u0131t\u0131lmas\u0131n\u0131 veya en az\u0131ndan kapsay\u0131c\u0131n\u0131n yeniden ba\u015flat\u0131lmas\u0131n\u0131 gerektirirdi. Bu durum, \u00f6zellikle yo\u011fun trafik alan veya y\u00fcksek eri\u015filebilirlik gerektiren uygulamalar i\u00e7in kabul edilemez kesintilere yol a\u00e7abilirdi. Dinamik yap\u0131land\u0131rma y\u00f6netimi ise, uygulamalar\u0131n canl\u0131yken yap\u0131land\u0131rmalar\u0131n\u0131 g\u00fcncellemesine olanak tan\u0131r, bu da kesinti s\u00fcresini minimize eder ve operasyonel verimlili\u011fi art\u0131r\u0131r. Bu esneklik, CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) s\u00fcre\u00e7lerinin etkinli\u011fini de maksimize eder, \u00e7\u00fcnk\u00fc art\u0131k her k\u00fc\u00e7\u00fck yap\u0131land\u0131rma de\u011fi\u015fikli\u011fi i\u00e7in uzun da\u011f\u0131t\u0131m boru hatlar\u0131n\u0131 ba\u015ftan sona \u00e7al\u0131\u015ft\u0131rmaya gerek kalmaz.\n<\/p>\n

\n Bir e-ticaret uygulaman\u0131z oldu\u011funu ve anl\u0131k olarak bir kampanyan\u0131n ba\u015flang\u0131\u00e7 veya biti\u015f tarihini, \u00f6deme entegrasyonu i\u00e7in yeni bir API anahtar\u0131n\u0131 veya bir arka u\u00e7 servisin adresini g\u00fcncellemeniz gerekti\u011fini d\u00fc\u015f\u00fcnelim. E\u011fer bu t\u00fcr de\u011fi\u015fiklikler i\u00e7in t\u00fcm uygulamay\u0131 yeniden ba\u015flatman\u0131z gerekseydi, kullan\u0131c\u0131lar\u0131n\u0131z ciddi kesintiler ya\u015fayabilir veya performans d\u00fc\u015f\u00fc\u015fleriyle kar\u015f\u0131la\u015fabilirdi. Dinamik yap\u0131land\u0131rma ile, bu t\u00fcr g\u00fcncellemeler arka planda sessizce ger\u00e7ekle\u015fir ve uygulama ak\u0131\u015f\u0131 hi\u00e7 bozulmaz. Bu sadece m\u00fc\u015fteri deneyimini iyile\u015ftirmekle kalmaz, ayn\u0131 zamanda geli\u015ftirici ekiplerin daha h\u0131zl\u0131 yineleme yapmas\u0131na ve yeni \u00f6zellik veya d\u00fczeltmeleri daha \u00e7evik bir \u015fekilde sunmas\u0131na olanak tan\u0131r. Ayr\u0131ca, hata ay\u0131klama s\u00fcre\u00e7lerinde de b\u00fcy\u00fck kolayl\u0131k sa\u011flar; bir yap\u0131land\u0131rma hatas\u0131 durumunda, h\u0131zl\u0131 bir d\u00fczeltme ile uygulama ak\u0131\u015f\u0131n\u0131 tekrar normale d\u00f6nd\u00fcrmek \u00e7ok daha pratik hale gelir.\n<\/p>\n

\n Kubernetes ekosistemi i\u00e7inde ConfigMap’ler, bu dinamik yap\u0131land\u0131rma ihtiya\u00e7lar\u0131n\u0131 kar\u015f\u0131lamak i\u00e7in temel bir bile\u015fen olarak \u00f6ne \u00e7\u0131kar. Uygulama kodundan ba\u011f\u0131ms\u0131z olarak yap\u0131land\u0131rma verilerini depolama yetenekleri sayesinde, kapsay\u0131c\u0131 imajlar\u0131n\u0131 daha genel ve yeniden kullan\u0131labilir hale getirirler. Bu da DevOps prensiplerinin temelini olu\u015fturan ayr\u0131m prensibine m\u00fckemmel bir \u015fekilde uyar: “yap\u0131land\u0131rmay\u0131 koddan ay\u0131r.” Bu ayr\u0131m, g\u00fcvenlik, s\u00fcr\u00fcm kontrol\u00fc ve \u00f6l\u00e7eklenebilirlik a\u00e7\u0131s\u0131ndan da \u00f6nemli avantajlar sunar. \u00d6rne\u011fin, hassas olmayan yap\u0131land\u0131rma verilerini Git depolar\u0131nda g\u00fcvenle saklayabilir ve s\u00fcr\u00fcmleyebiliriz, b\u00f6ylece ge\u00e7mi\u015f de\u011fi\u015fiklikleri takip etmek ve gerekti\u011finde geri almak \u00e7ok daha kolay hale gelir. Kubernetes’in sa\u011flad\u0131\u011f\u0131 bu g\u00fc\u00e7l\u00fc yap\u0131land\u0131rma y\u00f6netimi yetenekleri, modern, dayan\u0131kl\u0131 ve \u00f6l\u00e7eklenebilir uygulamalar in\u015fa etmenin anahtarlar\u0131ndan biridir.\n<\/p>\n

ConfigMap Nedir ve Neden Kubernetes Uygulamalar\u0131nda Hayati Bir Rol Oynar?<\/h2>\n

\n ConfigMap, Kubernetes’te yap\u0131land\u0131rma verilerini anahtar-de\u011fer \u00e7iftleri olarak depolayan bir API nesnesidir. Bu veriler, bir kapsay\u0131c\u0131 imaj\u0131ndan ba\u011f\u0131ms\u0131zd\u0131r ve bir pod’a \u00e7e\u015fitli yollarla enjekte edilebilir: ortam de\u011fi\u015fkenleri olarak, komut sat\u0131r\u0131 arg\u00fcmanlar\u0131 olarak veya en \u00e7ok tercih edilen y\u00f6ntemlerden biri olan volume olarak mount edilerek. ConfigMap’ler, veritaban\u0131 ba\u011flant\u0131 dizeleri, log seviyeleri, d\u0131\u015f servis adresleri gibi hassas olmayan yap\u0131land\u0131rma bilgilerini y\u00f6netmek i\u00e7in idealdir. Hassas veriler i\u00e7inse Kubernetes’in Secret kaynaklar\u0131 kullan\u0131l\u0131r; bu, veri t\u00fcr\u00fcne g\u00f6re do\u011fru arac\u0131 se\u00e7menin \u00f6nemini vurgular. ConfigMap’lerin temel amac\u0131, uygulama kodunu ve yap\u0131land\u0131rmay\u0131 birbirinden ay\u0131rmakt\u0131r, b\u00f6ylece uygulama imajlar\u0131n\u0131 de\u011fi\u015ftirmeden farkl\u0131 ortamlar i\u00e7in yeniden kullan\u0131labilir hale getiririz.\n<\/p>\n

\n ConfigMap’lerin sa\u011flad\u0131\u011f\u0131 bu ayr\u0131m, bir\u00e7ok operasyonel avantaj\u0131 beraberinde getirir. Birincisi, geli\u015ftirme ve operasyon ekipleri aras\u0131nda daha net bir sorumluluk ayr\u0131m\u0131 sa\u011flar. \u0130kincisi, ayn\u0131 uygulama imaj\u0131n\u0131 farkl\u0131 yap\u0131land\u0131rmalarla birden \u00e7ok ortamda kullanma yetene\u011fi sunar. \u00d6rne\u011fin, ayn\u0131 web sunucusu imaj\u0131 geli\u015ftirme ortam\u0131nda debug modunda \u00e7al\u0131\u015f\u0131rken, \u00fcretim ortam\u0131nda optimize edilmi\u015f ve g\u00fcvenli modda \u00e7al\u0131\u015fabilir, t\u00fcm bunlar sadece farkl\u0131 bir ConfigMap ile sa\u011flan\u0131r. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, yap\u0131land\u0131rma g\u00fcncellemelerini \u00e7ok daha h\u0131zl\u0131 ve g\u00fcvenli hale getirir. Bir yap\u0131land\u0131rma dosyas\u0131ndaki k\u00fc\u00e7\u00fck bir de\u011fi\u015fiklik bile, e\u011fer do\u011frudan uygulama imaj\u0131n\u0131n i\u00e7ine g\u00f6m\u00fclm\u00fc\u015f olsayd\u0131, imaj\u0131n yeniden olu\u015fturulmas\u0131n\u0131, test edilmesini ve da\u011f\u0131t\u0131lmas\u0131n\u0131 gerektirirdi ki bu da zaman al\u0131c\u0131 ve hata potansiyeli y\u00fcksek bir s\u00fcre\u00e7tir. ConfigMap’ler sayesinde bu de\u011fi\u015fiklikler an\u0131nda cluster i\u00e7inde uygulanabilir.\n<\/p>\n

\n Volume olarak mount edilen ConfigMap’ler, uygulamalar\u0131n yap\u0131land\u0131rma dosyalar\u0131na eri\u015fimi i\u00e7in en esnek ve g\u00fc\u00e7l\u00fc y\u00f6ntemlerden birini sunar. Bu yakla\u015f\u0131mla, ConfigMap i\u00e7indeki veriler, pod’un dosya sisteminde belirli bir dizine d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. Uygulama, sanki yerel bir dosya sistemi dosyas\u0131n\u0131 okuyormu\u015f gibi bu yap\u0131land\u0131rma verilerine eri\u015febilir. Bu, \u00f6zellikle geleneksel uygulamalar\u0131n veya \u00fc\u00e7\u00fcnc\u00fc taraf yaz\u0131l\u0131mlar\u0131n beklentilerini kar\u015f\u0131lamak i\u00e7in \u00f6nemlidir; \u00e7o\u011fu uygulama, yap\u0131land\u0131rma bilgilerini ortam de\u011fi\u015fkenleri yerine dosyalardan okumaya al\u0131\u015fk\u0131nd\u0131r. Bu y\u00f6ntem ayr\u0131ca, ConfigMap g\u00fcncellemelerinin pod’lar taraf\u0131ndan otomatik olarak alg\u0131lanmas\u0131n\u0131 ve yeni yap\u0131land\u0131rman\u0131n uygulanmas\u0131n\u0131 sa\u011flar, ki bu da makalemizin ana odak noktas\u0131d\u0131r. Kubernetes’in bu \u00f6zelli\u011fi, DevOps ekiplerine \u00f6nemli bir esneklik ve operasyonel kolayl\u0131k sa\u011flar, b\u00f6ylece uygulamalar her zaman en g\u00fcncel ayarlarla \u00e7al\u0131\u015fabilir ve kesinti s\u00fcreleri minimuma iner.\n<\/p>\n

\n Uzman \u0130pucu: ConfigMap’leri versiyon kontrol sisteminizde (Git gibi) y\u00f6netmek, yap\u0131land\u0131rma de\u011fi\u015fikliklerinin izlenebilirli\u011fini art\u0131r\u0131r ve geri alma i\u015flemlerini kolayla\u015ft\u0131r\u0131r. Helm gibi paket y\u00f6neticileri bu s\u00fcreci daha da otomatikle\u015ftirmenize yard\u0131mc\u0131 olabilir.\n<\/div>\n

ConfigMap’i Volume Olarak Mount Etmek: \u0130lk Ad\u0131mlar Nelerdir ve Nas\u0131l Uygulan\u0131r?<\/h2>\n

\n ConfigMap’leri bir pod’a volume olarak ba\u011flamak, uygulamalar\u0131n yap\u0131land\u0131rma dosyalar\u0131na do\u011frudan eri\u015fmesini sa\u011flaman\u0131n en yayg\u0131n ve etkili yoludur. Bu y\u00f6ntemle, ConfigMap i\u00e7eri\u011fi bir dosya sistemine yans\u0131t\u0131l\u0131r ve uygulama bu dosyalardan okuma yapabilir. \u0130lk olarak, bir ConfigMap olu\u015ftural\u0131m. Bu \u00f6rnekte, basit bir web uygulamas\u0131n\u0131n yap\u0131land\u0131rmas\u0131n\u0131 taklit eden bir dosya olu\u015fturaca\u011f\u0131z.\n<\/p>\n

\n \u00d6ncelikle, yap\u0131land\u0131rma verimizi i\u00e7eren bir ConfigMap olu\u015ftural\u0131m. Bu ConfigMap, bir veya daha fazla anahtar-de\u011fer \u00e7ifti i\u00e7erebilir. Her bir anahtar, daha sonra pod’un i\u00e7ine bir dosya olarak yans\u0131t\u0131lacakt\u0131r.\n<\/p>\n

\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: my-app-config\ndata:\n  appsettings.properties: |\n    api.url=http:\/\/api.example.com\/v1\n    log.level=INFO\n    feature.flag.beta=false\n  nginx.conf: |\n    server {\n      listen 80;\n      location \/ {\n        root \/usr\/share\/nginx\/html;\n        index index.html index.htm;\n      }\n    }\n<\/pre>\n
<\/code><\/p>\n
\n    Bu YAML tan\u0131m\u0131n\u0131 configmap.yaml<\/code> olarak kaydedip a\u015fa\u011f\u0131daki komutla Kubernetes k\u00fcmenize uygulayabilirsiniz:\n<\/p>\n
\nkubectl apply -f configmap.yaml\n<\/pre>\n
<\/code><\/p>\n
\n    ConfigMap'imiz art\u0131k haz\u0131r. \u015eimdi, bu ConfigMap'i bir pod'a volume olarak nas\u0131l ba\u011flayaca\u011f\u0131m\u0131za bakal\u0131m. Bir pod tan\u0131m\u0131nda, volumes<\/code> ve volumeMounts<\/code> alanlar\u0131n\u0131 kullanarak bu i\u015flemi ger\u00e7ekle\u015ftirece\u011fiz.\n<\/p>\n
\napiVersion: v1\nkind: Pod\nmetadata:\n  name: my-web-app\nspec:\n  containers:\n  - name: web-container\n    image: nginx:latest\n    ports:\n    - containerPort: 80\n    volumeMounts:\n    - name: config-volume\n      mountPath: \/etc\/config # ConfigMap i\u00e7eri\u011finin mount edilece\u011fi yol\n      readOnly: true\n  volumes:\n  - name: config-volume\n    configMap:\n      name: my-app-config # Ba\u011flanacak ConfigMap'in ad\u0131\n<\/pre>\n
<\/code><\/p>\n
\n    Yukar\u0131daki pod tan\u0131m\u0131n\u0131 pod.yaml<\/code> olarak kaydedip uygulad\u0131ktan sonra, my-web-app<\/code> pod'u olu\u015fturulacak ve i\u00e7indeki web-container<\/code> isimli Nginx kapsay\u0131c\u0131s\u0131 \/etc\/config<\/code> dizininde ConfigMap'imizdeki appsettings.properties<\/code> ve nginx.conf<\/code> dosyalar\u0131na sahip olacakt\u0131r. Bu dizine gidip dosyalar\u0131n i\u00e7eri\u011fini kontrol edebilirsiniz.\n<\/p>\n
\nkubectl apply -f pod.yaml\nkubectl exec -it my-web-app -- ls \/etc\/config\nkubectl exec -it my-web-app -- cat \/etc\/config\/appsettings.properties\n<\/pre>\n
<\/code><\/p>\n
\n    Bu ad\u0131mlarla, temel bir ConfigMap'i bir pod'a volume olarak ba\u015far\u0131yla ba\u011flam\u0131\u015f olursunuz. Ancak as\u0131l marifet, bu yap\u0131land\u0131rma dosyalar\u0131n\u0131 uygulamay\u0131 veya pod'u yeniden ba\u015flatmaya gerek kalmadan nas\u0131l dinamik olarak g\u00fcncelleyece\u011fimizdedir. Kubernetes'in sa\u011flad\u0131\u011f\u0131 bu dinamik g\u00fcncelleme mekanizmas\u0131, \u00f6zellikle kesintisiz operasyon gerektiren ortamlarda kritik bir avantaj sunar. Bir sonraki b\u00f6l\u00fcmde, bu dinamik g\u00fcncellemelerin perde arkas\u0131nda nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve uygulamalar\u0131n\u0131z\u0131n bundan nas\u0131l faydalanabilece\u011fini detayl\u0131ca inceleyece\u011fiz.\n<\/p>\n
ConfigMap G\u00fcncellemeleri Dinamik Olarak Nas\u0131l \u00c7al\u0131\u015f\u0131r ve Uygulamalar Nas\u0131l Haberdar Olur?<\/h2>\n
\n    Kubernetes'te bir ConfigMap'i bir volume olarak bir pod'a ba\u011flad\u0131\u011f\u0131n\u0131zda, Kubernetes asl\u0131nda bu ConfigMap'in i\u00e7eri\u011fini pod'un dosya sistemindeki belirli bir dizine senkronize eder. Bu senkronizasyon, atomik bir s\u00fcre\u00e7le ger\u00e7ekle\u015ftirilir. Yani, ConfigMap'te bir de\u011fi\u015fiklik yapt\u0131\u011f\u0131n\u0131zda, Kubernetes bu de\u011fi\u015fikli\u011fi hemen mevcut dosyan\u0131n \u00fczerine yazmak yerine, \u00f6nce yeni bir ge\u00e7ici dizin olu\u015fturur, yeni ConfigMap i\u00e7eri\u011fini bu ge\u00e7ici dizine yazar ve ard\u0131ndan pod i\u00e7indeki mevcut dizini atomik olarak bu yeni ge\u00e7ici dizine ba\u011flar (symlink g\u00fcncellenir). Bu atomik g\u00fcncelleme, uygulaman\u0131n yar\u0131da kalm\u0131\u015f veya bozuk bir yap\u0131land\u0131rma dosyas\u0131 okumas\u0131n\u0131 engeller.\n<\/p>\n
\n    Peki, uygulamalar bu de\u011fi\u015fikliklerden nas\u0131l haberdar olur? Kubernetes, ConfigMap'i mount etti\u011fi dizini varsay\u0131lan olarak yakla\u015f\u0131k 60 saniyede bir kontrol eder (kubelet'in varsay\u0131lan sync-period<\/code> ayar\u0131na ba\u011fl\u0131 olarak bu s\u00fcre de\u011fi\u015febilir). E\u011fer ConfigMap'te bir de\u011fi\u015fiklik alg\u0131lan\u0131rsa, yukar\u0131da bahsedilen atomik g\u00fcncelleme mekanizmas\u0131 devreye girer. Uygulaman\u0131z\u0131n bu yeni yap\u0131land\u0131rmay\u0131 kullanabilmesi i\u00e7in genellikle iki ana y\u00f6ntemden biri izlenir:\n<\/p>\n
    \n
  1. Uygulaman\u0131n Dosya Sistemini \u0130zlemesi (File System Watcher):<\/strong> Modern uygulamalar veya k\u00fct\u00fcphaneler, mount edilen dizindeki dosya de\u011fi\u015fikliklerini alg\u0131lamak i\u00e7in dosya sistemi izleyicilerini (\u00f6rne\u011fin, Linux'ta inotify veya Java'da WatchService) kullanabilir. Bu sayede, ConfigMap g\u00fcncellendi\u011finde, uygulama otomatik olarak yeni yap\u0131land\u0131rmay\u0131 y\u00fckleyebilir ve kendisini yeniden yap\u0131land\u0131rabilir. Bu y\u00f6ntem, uygulaman\u0131n kesintisiz \u00e7al\u0131\u015fmaya devam etmesini sa\u011flar.<\/li>\n
  2. Pod'un Yeniden Ba\u015flat\u0131lmas\u0131 (Rolling Update):<\/strong> E\u011fer uygulaman\u0131z dosya sistemi de\u011fi\u015fikliklerini otomatik olarak izleyemiyorsa veya yeniden yap\u0131land\u0131rma i\u015flemi karma\u015f\u0131ksa, ConfigMap'i g\u00fcncelledikten sonra ilgili pod'lar\u0131 yeniden ba\u015flatmak gerekebilir. Kubernetes, bir Deployment kulland\u0131\u011f\u0131n\u0131zda ve ConfigMap'i g\u00fcncelledi\u011finizde, Deployment'\u0131n pod \u015fablonu de\u011fi\u015fmedi\u011fi s\u00fcrece pod'lar\u0131 yeniden yaratma (rolling update) mekanizmas\u0131n\u0131 tetiklemez. Bu durumda, Deployment'\u0131 manuel olarak tetiklemek i\u00e7in bir de\u011fi\u015fiklik yapman\u0131z veya bir ara\u00e7 kullanman\u0131z gerekir. \u00d6rne\u011fin, Deployment'\u0131n pod \u015fablonuna bir annotasyon ekleyerek bu tetiklemeyi sa\u011flayabilirsiniz.<\/li>\n<\/ol>\n
    \n    \u0130kinci y\u00f6ntem i\u00e7in bir \u00f6rnek vermek gerekirse, genellikle Deployment'\u0131n spec.template.metadata.annotations<\/code> k\u0131sm\u0131na bir checksum<\/code> veya hash<\/code> eklenir. Bu checksum, ConfigMap'in i\u00e7eri\u011finin hash'i olabilir. ConfigMap g\u00fcncellendi\u011finde, bu checksum da g\u00fcncellenir, bu da Deployment'\u0131n pod \u015fablonunun de\u011fi\u015fti\u011fini alg\u0131lamas\u0131na ve yeni pod'lar\u0131 olu\u015fturarak eski pod'lar\u0131 sonland\u0131rmas\u0131na neden olur.\n<\/p>\n
    \napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: my-web-app-deployment\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: my-web-app\n  template:\n    metadata:\n      labels:\n        app: my-web-app\n      annotations:\n        checksum\/config: \"d41d8cd98f00b204e9800998ecf8427e\" # Bu hash ConfigMap'in i\u00e7eri\u011fine g\u00f6re g\u00fcncellenecek\n    spec:\n      containers:\n      - name: web-container\n        image: nginx:latest\n        ports:\n        - containerPort: 80\n        volumeMounts:\n        - name: config-volume\n          mountPath: \/etc\/config\n          readOnly: true\n      volumes:\n      - name: config-volume\n        configMap:\n          name: my-app-config\n<\/pre>\n
    <\/code><\/p>\n
    \n    Bu checksum\/config<\/code> annotasyonunu, CI\/CD pipeline'\u0131n\u0131zda ConfigMap'in i\u00e7eri\u011finin SHA256 veya MD5 hash'i ile dinamik olarak doldurabilirsiniz. B\u00f6ylece ConfigMap de\u011fi\u015fti\u011finde, Deployment da de\u011fi\u015fmi\u015f kabul edilir ve otomatik bir rolling update tetiklenir. Bu yakla\u015f\u0131m, uygulaman\u0131z\u0131n dosya sistemi de\u011fi\u015fikliklerini otomatik olarak alg\u0131layamad\u0131\u011f\u0131 durumlarda bile kesintisiz bir g\u00fcncelleme stratejisi sa\u011flar.\n<\/p>\n
    Uygulamal\u0131 Senaryo: Dinamik G\u00fcncellemeli Bir Web Uygulamas\u0131n\u0131 Nas\u0131l Yap\u0131land\u0131r\u0131r\u0131z?<\/h2>\n
    \n    \u015eimdi, \u00f6\u011frendiklerimizi bir araya getirerek ger\u00e7ek bir senaryo \u00fczerinden ilerleyelim. Basit bir Nginx web sunucusu \u00fczerinde ConfigMap ile dinamik olarak yap\u0131land\u0131r\u0131lan bir index.html<\/code> dosyas\u0131 oldu\u011funu varsayal\u0131m. Nginx, dosya sistemi de\u011fi\u015fikliklerini otomatik olarak alg\u0131lamaz ve yeniden y\u00fckleme gerektirir, ancak biz burada dosya g\u00fcncellemesini g\u00f6stermek i\u00e7in bu \u00f6rne\u011fi kullanaca\u011f\u0131z. Ger\u00e7ek d\u00fcnya uygulamalar\u0131nda, uygulaman\u0131z\u0131n kendisi dosya de\u011fi\u015fikliklerini izlemeli veya yukar\u0131da bahsedilen checksum y\u00f6ntemiyle pod'lar yeniden ba\u015flat\u0131lmal\u0131d\u0131r.\n<\/p>\n
    \n    Ad\u0131m 1: Ba\u015flang\u0131\u00e7 ConfigMap'ini Olu\u015fturma<\/strong>
    \n    \u0130lk olarak, web sayfam\u0131z\u0131n i\u00e7eri\u011fini tutacak bir ConfigMap olu\u015ftural\u0131m.\n<\/p>\n
    \n# initial-configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: my-web-page\ndata:\n  index.html: |\n    \n      
    Ho\u015f Geldiniz, G\u00fcncellendi!<\/h1>\n      
    Bu, ConfigMap'ten dinamik olarak gelen yeni<\/strong> sayfam\u0131zd\u0131r.<\/p>\n      
    S\u00fcr\u00fcm: v2.0 - Harika bir g\u00fcncelleme!<\/p>\n    <\/body>\n    <\/html>\n<\/pre>\n
    <\/code><\/p>\n
    <\/pre>\n
    <\/code>
    \nkubectl apply -f updated-configmap.yaml
    \n<\/code><\/p>\n
    \n    Ad\u0131m 5: G\u00fcncellemeyi G\u00f6zlemleme (ve Rolling Update Tetikleme)<\/strong>
    \n    Kubernetes, ConfigMap'i pod'lar\u0131n mount etti\u011fi dizine yakla\u015f\u0131k 60 saniye i\u00e7inde yans\u0131tacakt\u0131r. Ancak Nginx gibi uygulamalar, dosya sistemi de\u011fi\u015fikliklerini otomatik olarak alg\u0131lay\u0131p kendini yeniden y\u00fcklemez. Bu nedenle, Deployment'\u0131m\u0131z\u0131 ConfigMap de\u011fi\u015fikli\u011finden haberdar etmemiz ve bir rolling update tetiklememiz gerekiyor. Bunu, Deployment'\u0131n pod \u015fablonundaki checksum\/config<\/code> annotasyonunu g\u00fcncelleyerek yapabiliriz.\n<\/p>\n
    \n# ConfigMap i\u00e7eri\u011finin hash'ini hesaplay\u0131n (\u00f6rne\u011fin sha256sum ile)\nCONFIG_HASH=$(kubectl get configmap my-web-page -o jsonpath='{.data.index\\.html}' | sha256sum | awk '{print $1}')\n\n# Deployment'\u0131 g\u00fcncelleyin\nkubectl patch deployment web-app-deployment -p \"{\\\"spec\\\":{\\\"template\\\":{\\\"metadata\\\":{\\\"annotations\\\":{\\\"checksum\/config\\\":\\\"$CONFIG_HASH\\\"}}}}}\"\n<\/pre>\n
    <\/code><\/p>\n
    \n    Bu komut, Deployment'\u0131n checksum\/config<\/code> annotasyonunu yeni ConfigMap i\u00e7eri\u011finin hash'i ile g\u00fcncelleyecek ve bu da Deployment'\u0131n yeni pod'lar\u0131 olu\u015fturmas\u0131n\u0131 tetikleyecektir. Birka\u00e7 saniye i\u00e7inde, eski pod'lar sonland\u0131r\u0131l\u0131rken yeni pod'lar ba\u015flat\u0131lacak ve taray\u0131c\u0131n\u0131z\u0131 yeniledi\u011finizde \"S\u00fcr\u00fcm: v2.0\" olan g\u00fcncellenmi\u015f web sayfas\u0131n\u0131 g\u00f6receksiniz. Bu senaryo, ConfigMap'in hem veri sa\u011flama hem de dinamik g\u00fcncelleme yetene\u011fini ve rolling update stratejisi ile nas\u0131l birle\u015ftirilebilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir.\n<\/p>\n
    Geli\u015fmi\u015f Teknikler ve En \u0130yi Pratikler: Performans ve G\u00fcvenlik \u0130pu\u00e7lar\u0131<\/h2>\n
    \n    ConfigMap'leri volume olarak mount etmek ve dinamik olarak g\u00fcncellemek, Kubernetes'in g\u00fc\u00e7l\u00fc bir \u00f6zelli\u011fidir. Ancak bu \u00f6zelli\u011fin tam potansiyelini kullanmak ve olas\u0131 sorunlar\u0131 minimize etmek i\u00e7in baz\u0131 geli\u015fmi\u015f teknikler ve en iyi pratikler mevcuttur. Performans, g\u00fcvenlik ve y\u00f6netilebilirlik a\u00e7\u0131s\u0131ndan dikkat edilmesi gereken \u00f6nemli noktalar bulunmaktad\u0131r.\n<\/p>\n
      \n
    1. Atomic G\u00fcncelleme Mekanizmas\u0131n\u0131 Anlamak:<\/strong> Kubernetes ConfigMap'leri atomik olarak g\u00fcnceller. Bu, uygulama ConfigMap dosyalar\u0131n\u0131 okurken tutars\u0131z veya k\u0131smen yaz\u0131lm\u0131\u015f verilerle kar\u015f\u0131la\u015fmayaca\u011f\u0131 anlam\u0131na gelir. Ancak, uygulaman\u0131z\u0131n bu yeni dosyay\u0131 ne zaman ve nas\u0131l okuyaca\u011f\u0131n\u0131 iyi planlaman\u0131z gerekir. Baz\u0131 uygulamalar i\u00e7in dosya izleyici kullanmak idealdir, di\u011ferleri i\u00e7in ise rolling update zorunludur.<\/li>\n
    2. K\u00fc\u00e7\u00fck ve Odakl\u0131 ConfigMap'ler Kullanmak:<\/strong> Tek bir devasa ConfigMap yerine, farkl\u0131 servislerin veya mod\u00fcllerin ihtiya\u00e7 duydu\u011fu yap\u0131land\u0131rmalar\u0131 ayr\u0131, daha k\u00fc\u00e7\u00fck ConfigMap'lerde tutmak daha iyi bir yakla\u015f\u0131md\u0131r. Bu, y\u00f6netimi kolayla\u015ft\u0131r\u0131r, ba\u011f\u0131ml\u0131l\u0131klar\u0131 azalt\u0131r ve bir ConfigMap'teki bir de\u011fi\u015fikli\u011fin yaln\u0131zca ilgili pod'lar\u0131 etkilemesini sa\u011flar. Bu ayn\u0131 zamanda g\u00fcvenlik risklerini de azalt\u0131r.<\/li>\n
    3. subPath<\/code> Kullan\u0131m\u0131:<\/strong> E\u011fer bir ConfigMap'teki t\u00fcm dosyalar\u0131 de\u011fil, sadece belirli bir dosyay\u0131 mount etmek istiyorsan\u0131z, subPath<\/code> \u00f6zelli\u011fini kullanabilirsiniz. Bu, kapsay\u0131c\u0131n\u0131n ilgili dizininde sadece ihtiya\u00e7 duydu\u011fu dosyan\u0131n olmas\u0131n\u0131 sa\u011flar. Ancak subPath<\/code> ile mount edilen dosyalar dinamik g\u00fcncellemeleri otomatik olarak takip etmez; bu dosyalar g\u00fcncellenirse pod'un yeniden ba\u015flat\u0131lmas\u0131 gerekir.\n
      \n        volumeMounts:\n        - name: config-volume\n          mountPath: \/etc\/config\/appsettings.properties\n          subPath: appsettings.properties # Sadece bu dosyay\u0131 mount et\n        <\/pre>\n
      <\/code>\n    <\/li>\n
    4. G\u00fcvenlik Konular\u0131:<\/strong> ConfigMap'ler hassas veriler i\u00e7in tasarlanmam\u0131\u015ft\u0131r. API anahtarlar\u0131, veritaban\u0131 \u015fifreleri gibi hassas bilgiler i\u00e7in Kubernetes Secret'lar\u0131n\u0131 kullanmal\u0131s\u0131n\u0131z. ConfigMap'ler base64<\/code> ile kodlanmaz ve varsay\u0131lan olarak okunabilir durumdad\u0131r. Ayr\u0131ca, readOnly: true<\/code> bayra\u011f\u0131n\u0131 volumeMounts i\u00e7inde kullanmak, uygulaman\u0131z\u0131n yap\u0131land\u0131rma dosyalar\u0131n\u0131 yanl\u0131\u015fl\u0131kla de\u011fi\u015ftirmesini engeller.<\/li>\n
    5. S\u00fcr\u00fcm Kontrol\u00fc ve CI\/CD Entegrasyonu:<\/strong> ConfigMap YAML tan\u0131mlar\u0131n\u0131z\u0131 her zaman s\u00fcr\u00fcm kontrol sisteminizde (Git) tutun. Bu, de\u011fi\u015fikliklerin izlenebilirli\u011fini art\u0131r\u0131r ve \"Infrastructure as Code\" prensibini uygulaman\u0131z\u0131 sa\u011flar. CI\/CD pipeline'\u0131n\u0131zda ConfigMap g\u00fcncellemelerini ve pod'lar\u0131n rolling update'ini otomatikle\u015ftirmek, manuel hatalar\u0131 azalt\u0131r. Helm veya Kustomize gibi ara\u00e7lar bu s\u00fcre\u00e7leri daha verimli hale getirebilir.<\/li>\n
    6. Monitoring ve Alerting:<\/strong> Yap\u0131land\u0131rma g\u00fcncellemelerinin ne zaman yap\u0131ld\u0131\u011f\u0131n\u0131 ve uygulamalar \u00fczerindeki etkilerini izlemek i\u00e7in monitoring ve alerting sistemlerini entegre edin. Yanl\u0131\u015f bir yap\u0131land\u0131rma de\u011fi\u015fikli\u011fi uygulamada sorunlara yol a\u00e7arsa, h\u0131zl\u0131 bir \u015fekilde tespit edip m\u00fcdahale edebilmek \u00e7ok \u00f6nemlidir.<\/li>\n<\/ol>\n
      \n    Bu ileri d\u00fczey teknikler ve en iyi pratikler, Kubernetes'te ConfigMap y\u00f6netimini daha sa\u011flam, g\u00fcvenli ve verimli hale getirmenize yard\u0131mc\u0131 olacakt\u0131r. Dinamik yap\u0131land\u0131rma, modern bulut yerel uygulamalar i\u00e7in vazge\u00e7ilmez bir \u00f6zelliktir.\n<\/p>\n
      \n    Uzman \u0130pucu: Kapsay\u0131c\u0131 i\u00e7indeki uygulamalar\u0131n\u0131z\u0131n dosya sistemi de\u011fi\u015fikliklerini dinlemesini sa\u011flamak, s\u0131f\u0131r kesinti s\u00fcresiyle dinamik g\u00fcncellemeler i\u00e7in en etkili yoldur. Linux'ta inotify<\/code> API'si bunun i\u00e7in kullan\u0131labilir.\n<\/div>\n
      Mobil Uyumlu HTML ve CSS \u0130\u00e7in \u0130pu\u00e7lar\u0131: Neden Kubernetes Makalesinde Bundan Bahsediyoruz?<\/h2>\n
      \n    Her ne kadar bu makale a\u011f\u0131rl\u0131kl\u0131 olarak Kubernetes'teki ConfigMap'lerin dinamik g\u00fcncellenmesi \u00fczerine odaklansa da, modern web i\u00e7eri\u011fi olu\u015ftururken mobil uyumlulu\u011fun \u00f6nemi g\u00f6z ard\u0131 edilemez. Kullan\u0131c\u0131lar\u0131n b\u00fcy\u00fck bir \u00e7o\u011funlu\u011fu internete mobil cihazlar \u00fczerinden eri\u015fti\u011fi i\u00e7in, haz\u0131rlad\u0131\u011f\u0131m\u0131z her t\u00fcrl\u00fc HTML i\u00e7eri\u011finin (\u00f6rne\u011fin ConfigMap ile servis edilen bir web sayfas\u0131 gibi) farkl\u0131 ekran boyutlar\u0131na ve cihazlara sorunsuz bir \u015fekilde adapte olmas\u0131 kritik \u00f6neme sahiptir. Bu ba\u011flamda, teknik makalelerde veya herhangi bir web sayfas\u0131nda oldu\u011fu gibi, sundu\u011funuz i\u00e7eri\u011fin her platformda eri\u015filebilir ve okunakl\u0131 olmas\u0131, genel kullan\u0131c\u0131 deneyimini do\u011frudan etkiler. Bu b\u00f6l\u00fcm, teknik bir makalede bile mobil uyumlulu\u011fun neden vurgulanmas\u0131 gerekti\u011fini a\u00e7\u0131klayacak ve buna dair pratik bir HTML\/CSS \u00f6rne\u011fi sunacakt\u0131r.\n<\/p>\n
      \n    Mobil uyumluluk, sadece g\u00f6rsel bir estetik meselesi de\u011fildir; ayn\u0131 zamanda SEO (Arama Motoru Optimizasyonu) a\u00e7\u0131s\u0131ndan da temel bir gerekliliktir. Arama motorlar\u0131, mobil uyumlu siteleri s\u0131ralamada \u00f6nceliklendirir. E\u011fer i\u00e7eri\u011finiz mobil cihazlarda iyi g\u00f6r\u00fcnm\u00fcyorsa veya kullan\u0131lmas\u0131 zorsa, arama motorlar\u0131ndaki g\u00f6r\u00fcn\u00fcrl\u00fc\u011f\u00fcn\u00fcz d\u00fc\u015febilir ve potansiyel okuyucular\u0131n\u0131z\u0131 kaybedebilirsiniz. Kubernetes gibi teknik konular\u0131 ele alan makalelerde bile, i\u00e7eri\u011fin kolayca okunabilir, tablolar\u0131n d\u00fczenli ve kod bloklar\u0131n\u0131n kayd\u0131r\u0131labilir olmas\u0131 beklenir. Bu da, geli\u015ftiriciler ve operasyon ekipleri gibi teknik kitlelerin bile i\u00e7eri\u011fe daha rahat eri\u015febilmesini sa\u011flar. Responsive tasar\u0131m\u0131n temel prensipleri, bu hedefe ula\u015fmak i\u00e7in kullan\u0131l\u0131r.\n<\/p>\n
      \n    Responsive tasar\u0131m\u0131n kalbinde media query'ler yer al\u0131r. Media query'ler, ekran\u0131n geni\u015fli\u011fi, y\u00fcksekli\u011fi, cihaz\u0131n y\u00f6n\u00fc (yatay\/dikey) gibi \u00f6zelliklere ba\u011fl\u0131 olarak farkl\u0131 CSS stillerini uygulamam\u0131z\u0131 sa\u011flar. \u00d6rne\u011fin, k\u00fc\u00e7\u00fck ekranlar i\u00e7in yaz\u0131 boyutlar\u0131n\u0131 b\u00fcy\u00fctebilir, kolonlar\u0131 alt alta y\u0131\u011fabilir veya men\u00fcleri bir hamburger ikonunun arkas\u0131na gizleyebiliriz. B\u00fcy\u00fck ekranlar i\u00e7inse daha geni\u015f bir d\u00fczen kullanabilir ve daha fazla bilgiyi ayn\u0131 anda g\u00f6sterebiliriz. Bu esneklik, her kullan\u0131c\u0131n\u0131n cihaz\u0131na uygun en iyi deneyimi sunmam\u0131z\u0131 garantiler. A\u015fa\u011f\u0131da, temel bir mobil uyumlu HTML yap\u0131s\u0131n\u0131n ve buna e\u015flik eden CSS'in nas\u0131l g\u00f6r\u00fcnece\u011fine dair bir \u00f6rnek bulabilirsiniz:\n<\/p>\n
      \n