Modern bilgi teknolojileri (BT) ekosistemleri, ge\u00e7mi\u015fe k\u0131yasla katbekat daha karma\u015f\u0131k, dinamik ve \u00f6l\u00e7eklenebilir yap\u0131lardan olu\u015fmaktad\u0131r. Bulut bili\u015fim teknolojilerinin hayat\u0131m\u0131za girmesi, mikrohizmet mimarilerinin yayg\u0131nla\u015fmas\u0131 ve s\u00fcrekli entegrasyon\/s\u00fcrekli teslimat (CI\/CD) s\u00fcre\u00e7lerinin standart hale gelmesiyle birlikte, y\u00f6netilmesi gereken sunucu, a\u011f cihaz\u0131, veri taban\u0131 ve uygulama say\u0131s\u0131 \u00fcstel bir \u015fekilde artm\u0131\u015ft\u0131r. Bu devasa ekosistemde, her bir bile\u015fenin do\u011fru parametrelerle, g\u00fcvenli ve tutarl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak manuel y\u00f6ntemlerle imkans\u0131z hale gelmi\u015ftir. \u0130\u015fte bu noktada, sistemlerin ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca tutarl\u0131l\u0131\u011f\u0131n\u0131, g\u00fcvenilirli\u011fini ve performans\u0131n\u0131 korumay\u0131 ama\u00e7layan disipline “Konfig\u00fcrasyon Y\u00f6netimi” (Configuration Management – CM) ad\u0131 verilmektedir.<\/p>\n
Konfig\u00fcrasyon y\u00f6netimi, sadece yaz\u0131l\u0131m d\u00fcnyas\u0131na \u00f6zg\u00fc bir kavram de\u011fildir. K\u00f6keni askeri standartlara, havac\u0131l\u0131k ve sistem m\u00fchendisli\u011fine dayanan bu disiplin; bir \u00fcr\u00fcn\u00fcn veya sistemin gereksinimleri, tasar\u0131m\u0131 ve operasyonel bilgileri aras\u0131ndaki tutarl\u0131l\u0131\u011f\u0131 kurma ve s\u00fcrd\u00fcrme s\u00fcrecidir. BT d\u00fcnyas\u0131nda ise konfig\u00fcrasyon y\u00f6netimi; sunucular\u0131n i\u015fletim sistemi ayarlar\u0131ndan, a\u011f cihazlar\u0131n\u0131n port yap\u0131land\u0131rmalar\u0131na, uygulamalar\u0131n ortam de\u011fi\u015fkenlerinden (environment variables) g\u00fcvenlik yamalar\u0131n\u0131n takibine kadar geni\u015f bir yelpazeyi kapsar.<\/p>\n
Bu makalede, konfig\u00fcrasyon y\u00f6netiminin ne oldu\u011funu, neden kritik bir \u00f6neme sahip oldu\u011funu, temel bile\u015fenlerini, s\u00fcre\u00e7lerini, modern d\u00fcnyada nas\u0131l uyguland\u0131\u011f\u0131n\u0131 ve en pop\u00fcler konfig\u00fcrasyon y\u00f6netimi ara\u00e7lar\u0131n\u0131 derinlemesine inceleyece\u011fiz.<\/p>\n
Konfig\u00fcrasyon y\u00f6netimi, bir BT altyap\u0131s\u0131ndaki t\u00fcm donan\u0131m, yaz\u0131l\u0131m ve a\u011f bile\u015fenlerinin mevcut durumunu tan\u0131mlayan, bu durumlar\u0131 kay\u0131t alt\u0131na alan, de\u011fi\u015fiklikleri sistematik olarak y\u00f6neten ve sistemler aras\u0131ndaki tutarl\u0131l\u0131\u011f\u0131 garanti eden m\u00fchendislik s\u00fcrecidir. Temel amac\u0131; “bilinmeyen” veya “belgelenmemi\u015f” durumlar\u0131 ortadan kald\u0131rarak, sistemlerin her an tahmin edilebilir ve tekrarlanabilir bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamakt\u0131r.<\/p>\n
Konfig\u00fcrasyon y\u00f6netiminin \u00f6nemini anlamak i\u00e7in, bu s\u00fcrecin uygulanmad\u0131\u011f\u0131 senaryolarda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck problemlerden biri olan “Konfig\u00fcrasyon Sapmas\u0131” (Configuration Drift) kavram\u0131na bakmak gerekir. Bir sistem y\u00f6neticisinin acil bir sorunu \u00e7\u00f6zmek i\u00e7in canl\u0131 ortamdaki (production) bir sunucuya manuel olarak ba\u011flan\u0131p bir konfig\u00fcrasyon dosyas\u0131n\u0131 de\u011fi\u015ftirdi\u011fini d\u00fc\u015f\u00fcnelim. Bu de\u011fi\u015fiklik belgelenmez veya merkezi bir sisteme i\u015flenmezse, o sunucu art\u0131k di\u011fer sunuculardan farkl\u0131 bir yap\u0131ya sahip olur. Zamanla bu t\u00fcr manuel m\u00fcdahaleler biriktik\u00e7e, sunucular benzersiz ve y\u00f6netilemez hale gelir. Literat\u00fcrde buna “Kar Tanesi Sunucu” (Snowflake Server) denir. Kar tanesi sunucular, sistemlerin g\u00fcncellenmesini, yedeklenmesini ve felaket an\u0131nda yeniden aya\u011fa kald\u0131r\u0131lmas\u0131n\u0131 son derece zorla\u015ft\u0131r\u0131r. Konfig\u00fcrasyon y\u00f6netimi, t\u00fcm sunucular\u0131 “Anka Ku\u015fu Sunucu” (Phoenix Server) haline getirerek, gerekti\u011finde saniyeler i\u00e7inde s\u0131f\u0131rdan ve ayn\u0131 ayarlarla yeniden olu\u015fturulabilmelerine olanak tan\u0131r.<\/p>\n
Konfig\u00fcrasyon y\u00f6netiminin sa\u011flad\u0131\u011f\u0131 temel avantajlar \u015funlard\u0131r:<\/p>\n
Ba\u015far\u0131l\u0131 bir konfig\u00fcrasyon y\u00f6netimi mimarisi kurabilmek i\u00e7in bu disiplinin temelini olu\u015fturan yap\u0131 ta\u015flar\u0131n\u0131 iyi anlamak gerekir. Bu bile\u015fenler, sistemlerin durumunu izlemek ve y\u00f6netmek i\u00e7in ortak bir dil ve altyap\u0131 sunar.<\/p>\n
Konfig\u00fcrasyon y\u00f6netimi kapsam\u0131nda kontrol alt\u0131nda tutulmas\u0131, izlenmesi ve y\u00f6netilmesi gereken her t\u00fcrl\u00fc ba\u011f\u0131ms\u0131z varl\u0131\u011fa “Konfig\u00fcrasyon Kalemi” (CI) denir. Bir CI; fiziksel bir sunucu, bir sanal makine, bir a\u011f anahtar\u0131 (switch), bir yaz\u0131l\u0131m lisans\u0131, bir veri taban\u0131 tablosu, hatta bir SSL sertifikas\u0131 veya kaynak kod deposu olabilir. Her CI’n\u0131n kendine \u00f6zg\u00fc nitelikleri (s\u00fcr\u00fcm, konum, sahip, durum vb.) ve di\u011fer CI’lar ile olan ili\u015fkileri tan\u0131mlan\u0131r.<\/p>\n
Konfig\u00fcrasyon Y\u00f6netimi Veritaban\u0131 (Configuration Management Database – CMDB), t\u00fcm konfig\u00fcrasyon kalemlerinin (CI) ve bu kalemler aras\u0131ndaki ili\u015fkilerin tutuldu\u011fu merkezi depodur. CMDB, altyap\u0131n\u0131n “tek do\u011fruluk kayna\u011f\u0131” (Single Source of Truth – SSOT) olarak i\u015flev g\u00f6r\u00fcr. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131n hangi uygulama sunucusunda \u00e7al\u0131\u015ft\u0131\u011f\u0131, bu sunucunun hangi fiziksel sunucu \u00fczerinde bar\u0131nd\u0131r\u0131ld\u0131\u011f\u0131 ve hangi veri taban\u0131na ba\u011fland\u0131\u011f\u0131 bilgisi CMDB \u00fczerinde ili\u015fkilendirilmi\u015f durumdad\u0131r. Bu sayede, bir bile\u015fende yap\u0131lacak de\u011fi\u015fikli\u011fin di\u011fer bile\u015fenleri nas\u0131l etkileyece\u011fi (etki analizi) \u00f6nceden g\u00f6r\u00fclebilir.<\/p>\n
Temel \u00e7izgi (baseline), bir sistemin belirli bir andaki onaylanm\u0131\u015f, test edilmi\u015f ve kararl\u0131 kabul edilmi\u015f konfig\u00fcrasyon durumudur. Sistemlerin gelecekteki performans\u0131n\u0131 ve durumunu kar\u015f\u0131la\u015ft\u0131rmak i\u00e7in bir referans noktas\u0131 g\u00f6revi g\u00f6r\u00fcr. \u00d6rne\u011fin, yeni bir yaz\u0131l\u0131m s\u00fcr\u00fcm\u00fc canl\u0131ya al\u0131nmadan \u00f6nce mevcut sistemin bir konfig\u00fcrasyon baseline’\u0131 al\u0131n\u0131r. E\u011fer yeni s\u00fcr\u00fcmde beklenmedik bir hata olu\u015fursa, sistem h\u0131zl\u0131ca bu baseline durumuna geri \u00e7ekilir (rollback).<\/p>\n
Konfig\u00fcrasyon y\u00f6netimi sadece ara\u00e7lardan ibaret de\u011fildir; ayn\u0131 zamanda disiplinli bir s\u00fcre\u00e7 y\u00f6netimidir. Geleneksel olarak (\u00f6rne\u011fin ITIL \u00e7er\u00e7evesinde) konfig\u00fcrasyon y\u00f6netimi be\u015f temel a\u015famadan olu\u015fur:<\/p>\n
Bu a\u015famada, konfig\u00fcrasyon y\u00f6netiminin kapsam\u0131, hedefleri, rolleri ve sorumluluklar\u0131 belirlenir. Hangi varl\u0131klar\u0131n konfig\u00fcrasyon kalemi (CI) olarak kabul edilece\u011fi, bu kalemlerin hangi detay d\u00fczeyinde (granularity) takip edilece\u011fi ve CMDB’nin nas\u0131l g\u00fcncellenece\u011fi planlan\u0131r. Ayr\u0131ca kullan\u0131lacak ara\u00e7lar ve standartlar bu a\u015famada se\u00e7ilir.<\/p>\n
Belirlenen kapsam dahilindeki t\u00fcm CI’lar benzersiz bir \u015fekilde etiketlenir ve tan\u0131mlan\u0131r. Her bir CI’n\u0131n \u00f6zellikleri, s\u00fcr\u00fcmleri, teknik \u00f6zellikleri ve di\u011fer CI’lar ile olan ili\u015fkileri sisteme kaydedilir. Bu a\u015fama, altyap\u0131n\u0131n mevcut durumunun tam bir r\u00f6ntgeninin \u00e7ekilmesini sa\u011flar.<\/p>\n
Konfig\u00fcrasyon y\u00f6netiminin en kritik a\u015famalar\u0131ndan biridir. Yetkisiz, plans\u0131z ve test edilmemi\u015f de\u011fi\u015fikliklerin sisteme dahil edilmesini engeller. Herhangi bir konfig\u00fcrasyon de\u011fi\u015fikli\u011fi talebi (RFC – Request for Change) bir onay mekanizmas\u0131ndan ge\u00e7er, test ortamlar\u0131nda do\u011frulan\u0131r ve ancak ondan sonra kontroll\u00fc bir \u015fekilde canl\u0131 ortama uygulan\u0131r.<\/p>\n
Bir konfig\u00fcrasyon kaleminin ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca ge\u00e7irdi\u011fi t\u00fcm a\u015famalar\u0131n (\u00f6rne\u011fin: “Sipari\u015f Edildi”, “Test A\u015famas\u0131nda”, “Aktif”, “Kullan\u0131m D\u0131\u015f\u0131”) ve yap\u0131lan de\u011fi\u015fikliklerin ge\u00e7mi\u015finin (audit trail) izlenmesi s\u00fcrecidir. Bu sayede bir hata olu\u015ftu\u011funda, sistemin ge\u00e7mi\u015fte hangi a\u015famalardan ge\u00e7ti\u011fi geriye d\u00f6n\u00fck olarak analiz edilebilir.<\/p>\n
CMDB’de kay\u0131tl\u0131 olan konfig\u00fcrasyon bilgileri ile ger\u00e7ek d\u00fcnyadaki (fiziksel veya bulut ortam\u0131ndaki) durumun uyu\u015fup uyu\u015fmad\u0131\u011f\u0131n\u0131n periyodik olarak kontrol edilmesidir. Otomatik tarama ara\u00e7lar\u0131 kullan\u0131larak, kay\u0131t d\u0131\u015f\u0131 bir sunucu eklenip eklenmedi\u011fi veya bir sunucunun ayarlar\u0131n\u0131n manuel olarak de\u011fi\u015ftirilip de\u011fi\u015ftirilmedi\u011fi denetlenir ve raporlan\u0131r.<\/p>\n
Geleneksel BT operasyonlar\u0131nda konfig\u00fcrasyon y\u00f6netimi, sistem y\u00f6neticilerinin el kitap\u00e7\u0131klar\u0131na (runbooks) bakarak manuel ad\u0131mlarla sistemleri yap\u0131land\u0131rmas\u0131 anlam\u0131na geliyordu. Ancak bulut bili\u015fimin y\u00fckseli\u015fiyle birlikte bu yakla\u015f\u0131m tamamen de\u011fi\u015fti ve yerini “Altyap\u0131 Kod Olarak” (Infrastructure as Code – IaC) yakla\u015f\u0131m\u0131na b\u0131rakt\u0131.<\/p>\n
IaC, sunucular\u0131n, a\u011flar\u0131n, depolama birimlerinin ve di\u011fer altyap\u0131 elemanlar\u0131n\u0131n manuel i\u015flemler yerine makine taraf\u0131ndan okunabilir tan\u0131m dosyalar\u0131 (kod) arac\u0131l\u0131\u011f\u0131yla y\u00f6netilmesi ve haz\u0131rlanmas\u0131 s\u00fcrecidir. Bu yakla\u015f\u0131m, yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerindeki en iyi pratiklerin (s\u00fcr\u00fcm kontrol sistemleri, test otomasyonu, kod incelemesi) altyap\u0131 y\u00f6netimine de uygulanmas\u0131n\u0131 sa\u011flam\u0131\u015ft\u0131r.<\/p>\n
Modern d\u00fcnyada konfig\u00fcrasyon y\u00f6netimi ara\u00e7lar\u0131, IaC felsefesinin en \u00f6nemli uygulay\u0131c\u0131lar\u0131d\u0131r. Bu ba\u011flamda iki temel yakla\u015f\u0131m ve iki farkl\u0131 \u00e7al\u0131\u015fma modeli \u00f6ne \u00e7\u0131kmaktad\u0131r:<\/p>\n
Piyasada farkl\u0131 ihtiya\u00e7lara ve mimarilere hitap eden bir\u00e7ok konfig\u00fcrasyon y\u00f6netimi arac\u0131 bulunmaktad\u0131r. Bunlardan en yayg\u0131n kullan\u0131lan d\u00f6rt tanesi \u015funlard\u0131r:<\/p>\n
Red Hat taraf\u0131ndan geli\u015ftirilen Ansible, g\u00fcn\u00fcm\u00fczde en pop\u00fcler konfig\u00fcrasyon y\u00f6netimi ara\u00e7lar\u0131ndan biridir. En b\u00fcy\u00fck avantaj\u0131 “Agentless” yani hedef sunucularda herhangi bir ajan yaz\u0131l\u0131m\u0131na ihtiya\u00e7 duymamas\u0131d\u0131r. Ba\u011flant\u0131lar\u0131 SSH (Linux) veya WinRM (Windows) \u00fczerinden ger\u00e7ekle\u015ftirir. Konfig\u00fcrasyon tan\u0131mlar\u0131, okunmas\u0131 ve yaz\u0131lmas\u0131 son derece kolay olan YAML format\u0131ndaki “Playbook” dosyalar\u0131nda yap\u0131l\u0131r. Bildirimsel bir yap\u0131ya sahiptir ve \u00f6\u011frenme e\u011frisi olduk\u00e7a d\u00fc\u015f\u00fckt\u00fcr.<\/p>\n
Sekt\u00f6r\u00fcn en eski ve en olgun ara\u00e7lar\u0131ndan biri olan Puppet, genellikle b\u00fcy\u00fck \u00f6l\u00e7ekli kurumsal altyap\u0131larda tercih edilir. Ajan tabanl\u0131 (agent-based) ve \u00e7ekme (pull) modeliyle \u00e7al\u0131\u015f\u0131r. Puppet, sistem durumunu tan\u0131mlamak i\u00e7in kendine \u00f6zg\u00fc bir bildirimsel dil (Declarative DSL) kullan\u0131r. Sistemlerin s\u00fcrekli olarak istenen durumda kalmas\u0131n\u0131 sa\u011flama (state enforcement) konusunda son derece agresif ve ba\u015far\u0131l\u0131d\u0131r; sistemde yap\u0131lan manuel bir de\u011fi\u015fikli\u011fi an\u0131nda alg\u0131lay\u0131p eski haline getirebilir.<\/p>\n
Chef, altyap\u0131y\u0131 tamamen kod olarak ele alan ve sistem y\u00f6neticilerinden ziyade yaz\u0131l\u0131m geli\u015ftiricilere hitap eden bir ara\u00e7t\u0131r. Konfig\u00fcrasyonlar, Ruby dili kullan\u0131larak “Recipe” (Tarif) ve “Cookbook” (Yemek Kitab\u0131) ad\u0131 verilen yap\u0131larda tan\u0131mlan\u0131r. Emirsel (imperative) bir yakla\u015f\u0131ma daha yak\u0131nd\u0131r, bu da karma\u015f\u0131k mant\u0131ksal s\u00fcre\u00e7lerin ve d\u00f6ng\u00fclerin altyap\u0131 kodunda kolayca yaz\u0131labilmesini sa\u011flar. Ajan tabanl\u0131 \u00e7al\u0131\u015f\u0131r.<\/p>\n
SaltStack, \u00f6zellikle h\u0131z ve \u00e7ok b\u00fcy\u00fck \u00f6l\u00e7ekli altyap\u0131lar\u0131n y\u00f6netimi konusunda \u00f6ne \u00e7\u0131kan Python tabanl\u0131 bir ara\u00e7t\u0131r. Hedef sunuculardaki ajanlar (minions) ile merkezi sunucu (master) aras\u0131ndaki ileti\u015fimi s\u0131radan HTTP yerine son derece h\u0131zl\u0131 olan ZeroMQ protokol\u00fc \u00fczerinden ger\u00e7ekle\u015ftirir. Hem itme hem de \u00e7ekme modellerini destekler. Konfig\u00fcrasyonlar YAML veya Python ile yaz\u0131labilir. Olay g\u00fcd\u00fcml\u00fc (event-driven) otomasyon yetene\u011fi sayesinde, sistemde olu\u015fan bir hataya an\u0131nda otomatik tepki verebilir.<\/p>\n
Konfig\u00fcrasyon y\u00f6netimi ara\u00e7lar\u0131n\u0131 kullanmak tek ba\u015f\u0131na ba\u015far\u0131y\u0131 garanti etmez. Bu ara\u00e7lar\u0131n do\u011fru metodolojilerle desteklenmesi gerekir. \u0130\u015fte sekt\u00f6rde kabul g\u00f6rm\u00fc\u015f en iyi pratiklerden baz\u0131lar\u0131:<\/p>\n
Konfig\u00fcrasyon y\u00f6netimi, g\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen ve b\u00fcy\u00fcyen BT d\u00fcnyas\u0131nda bir l\u00fcks de\u011fil, operasyonel s\u00fcreklilik ve g\u00fcvenlik i\u00e7in ka\u00e7\u0131n\u0131lmaz bir zorunluluktur. Manuel s\u00fcre\u00e7lerin getirdi\u011fi riskleri ortadan kald\u0131rarak, altyap\u0131lar\u0131n tutarl\u0131, g\u00fcvenli, \u00f6l\u00e7eklenebilir ve izlenebilir olmas\u0131n\u0131 sa\u011flar.<\/p>\n
Ansible, Puppet, Chef veya SaltStack gibi modern ara\u00e7lar sayesinde altyap\u0131 y\u00f6netimi, yaz\u0131l\u0131m geli\u015ftirme disipliniyle birle\u015ferek DevOps k\u00fclt\u00fcr\u00fcn\u00fcn en \u00f6nemli s\u00fctunlar\u0131ndan biri olan “Altyap\u0131 Kod Olarak (IaC)” yakla\u015f\u0131m\u0131n\u0131 do\u011furmu\u015ftur. Do\u011fru ara\u00e7 se\u00e7imi, iyi tan\u0131mlanm\u0131\u015f s\u00fcre\u00e7ler ve en iyi pratiklerin uygulanmas\u0131yla, organizasyonlar hata oranlar\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcrken, yeni \u00f6zellikleri canl\u0131ya alma h\u0131zlar\u0131n\u0131 (time-to-market) radikal bir \u015fekilde art\u0131rabilirler.<\/p>\n