Tekil bir sanal makinede Docker konteynerlerini y\u00f6netmekten, Go ile kendi hibrit orkestrat\u00f6r\u00fcn\u00fcz\u00fc in\u015fa ederek \u00e7ok d\u00fc\u011f\u00fcml\u00fc, y\u00fcksek eri\u015fimli bir k\u00fcmeye ge\u00e7i\u015fin yolculu\u011funu ke\u015ffedin. Bu makale, temel prensiplerden ileri seviye uygulamalara kadar ad\u0131m ad\u0131m rehberlik sunuyor.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen dijital d\u00fcnyas\u0131nda, yaz\u0131l\u0131m uygulamalar\u0131n\u0131 h\u0131zl\u0131, g\u00fcvenilir ve \u00f6l\u00e7eklenebilir bir \u015fekilde da\u011f\u0131tmak kritik bir ihtiya\u00e7 haline gelmi\u015ftir. Bu ihtiyac\u0131 kar\u015f\u0131lamada konteyner teknolojileri, \u00f6zellikle Docker, devrim niteli\u011finde bir kolayl\u0131k sa\u011flam\u0131\u015ft\u0131r. Bir uygulamay\u0131 ve t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 izole edilmi\u015f bir ortamda paketleyerek, “benim makinemde \u00e7al\u0131\u015f\u0131yor” sorununu ortadan kald\u0131ran konteynerler, geli\u015ftirme ve operasyon (DevOps) s\u00fcre\u00e7lerini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde h\u0131zland\u0131rm\u0131\u015ft\u0131r. Ancak, tek bir konteyneri y\u00f6netmek nispeten kolay olsa da, y\u00fczlerce, hatta binlerce konteynerden olu\u015fan karma\u015f\u0131k bir mikroservis mimarisini y\u00f6netmek, izlemek ve \u00f6l\u00e7eklemek manuel olarak imkans\u0131za yak\u0131n bir g\u00f6revdir.<\/p>\n
\u0130\u015fte tam bu noktada “orkestrasyon” kavram\u0131 devreye girer. Konteyner orkestrasyonu, konteynerle\u015ftirilmi\u015f i\u015f y\u00fcklerinin da\u011f\u0131t\u0131m\u0131n\u0131, y\u00f6netimini, \u00f6l\u00e7eklenmesini ve a\u011f ileti\u015fimini otomatikle\u015ftiren bir s\u00fcre\u00e7tir. Sekt\u00f6rde Kubernetes, Docker Swarm gibi g\u00fc\u00e7l\u00fc ve yayg\u0131n orkestrasyon ara\u00e7lar\u0131 bulunsa da, bazen \u00f6zel ihtiya\u00e7lar, \u00f6\u011frenme arzusu veya mevcut altyap\u0131larla daha s\u0131k\u0131 entegrasyon gereksinimleri, kendi orkestrat\u00f6r\u00fcm\u00fcz\u00fc in\u015fa etme fikrini cazip hale getirebilir. Bu makalede, Go (Golang) programlama dilinin sundu\u011fu performans, e\u015fzamanl\u0131l\u0131k (concurrency) yetenekleri ve sistem programlama i\u00e7in uygunlu\u011fu sayesinde, Docker konteynerlerini y\u00f6neten bir hibrit orkestrat\u00f6r\u00fcn nas\u0131l geli\u015ftirilebilece\u011fini ad\u0131m ad\u0131m inceleyece\u011fiz. Go, \u00f6zellikle a\u011f tabanl\u0131 uygulamalar ve da\u011f\u0131t\u0131k sistemler i\u00e7in bi\u00e7ilmi\u015f kaftan olup, Docker API ile do\u011fal bir uyum i\u00e7indedir. Bu yolculukta, tek bir sanal makine (VM) \u00fczerindeki basit bir konteyner y\u00f6neticisinden, birden fazla sunucuyu kapsayan, hata toleransl\u0131 ve \u00f6l\u00e7eklenebilir bir \u00e7ok d\u00fc\u011f\u00fcml\u00fc (multi-node) k\u00fcmeye nas\u0131l ula\u015faca\u011f\u0131m\u0131z\u0131 ke\u015ffedece\u011fiz. Amac\u0131m\u0131z, sadece teknik detaylar\u0131 \u00f6\u011frenmek de\u011fil, ayn\u0131 zamanda da\u011f\u0131t\u0131k sistemlerin temel prensiplerini ve konteyner orkestrasyonunun derinliklerini pratik bir yakla\u015f\u0131mla anlamakt\u0131r.<\/p>\n
Kendi konteyner orkestrat\u00f6r\u00fcm\u00fcz\u00fc geli\u015ftirme yolculu\u011fumuza, en basit haliyle, tek bir sanal makine \u00fczerinde \u00e7al\u0131\u015fan temel bir sistemle ba\u015flamak en mant\u0131kl\u0131 yakla\u015f\u0131md\u0131r. Bu a\u015famada, Go programlama dilini kullanarak Docker Engine API (Uygulama Programlama Aray\u00fcz\u00fc) ile nas\u0131l etkile\u015fim kurabilece\u011fimizi ve temel konteyner i\u015flemlerini (ba\u015flatma, durdurma, listeleme) nas\u0131l ger\u00e7ekle\u015ftirece\u011fimizi \u00f6\u011frenece\u011fiz. Docker, arka planda \u00e7al\u0131\u015fan bir daemon (servis) arac\u0131l\u0131\u011f\u0131yla konteynerleri y\u00f6netir ve bu daemon’a HTTP \u00fczerinden eri\u015filebilen bir RESTful API sunar. Go i\u00e7in geli\u015ftirilmi\u015f \u00d6ncelikle, bir Go projesi olu\u015fturup gerekli Docker istemci k\u00fct\u00fcphanesini projemize dahil etmemiz gerekir. A\u015fa\u011f\u0131daki kod blo\u011fu, basit bir Go program\u0131n\u0131n Docker istemcisini nas\u0131l ba\u015flataca\u011f\u0131n\u0131 ve \u00e7al\u0131\u015fan t\u00fcm konteynerleri listeleyece\u011fini g\u00f6stermektedir. Bu, orkestrat\u00f6r\u00fcm\u00fcz\u00fcn temel g\u00f6zlem yetene\u011fini olu\u015fturur:<\/p>\n Bu kod par\u00e7as\u0131, Go’nun Docker API ile ne kadar kolay entegre olabildi\u011fini g\u00f6steriyor. \u015eimdi, tekil bir VM \u00fczerinde konteynerleri ba\u015flatma ve durdurma gibi i\u015flemleri de ekleyerek orkestrat\u00f6r\u00fcm\u00fcz\u00fcn ilk temel i\u015flevselli\u011fini in\u015fa edebiliriz. \u00d6rne\u011fin, bir Nginx konteynerini ba\u015flatmak i\u00e7in \u00c7ok d\u00fc\u011f\u00fcml\u00fc bir mimariye ge\u00e7i\u015f, beraberinde da\u011f\u0131t\u0131k sistemlerin temel zorluklar\u0131n\u0131 getirir. Art\u0131k sadece tek bir sunucu \u00fczerinde \u00e7al\u0131\u015fan bir Docker daemon ile de\u011fil, birden fazla sunucuda \u00e7al\u0131\u015fan Docker daemon’lar\u0131 ve bunlar\u0131n birbirleriyle nas\u0131l koordine olaca\u011f\u0131yla ilgilenmemiz gerekmektedir. Bu zorluklar aras\u0131nda d\u00fc\u011f\u00fcm ke\u015ffi (node discovery), d\u00fc\u011f\u00fcmler aras\u0131 g\u00fcvenli ileti\u015fim, da\u011f\u0131t\u0131k durum y\u00f6netimi (distributed state management) ve i\u015f y\u00fcklerinin d\u00fc\u011f\u00fcmler aras\u0131nda adil ve verimli bir \u015fekilde da\u011f\u0131t\u0131lmas\u0131 (scheduling) gibi konular yer al\u0131r. Kendi orkestrat\u00f6r\u00fcm\u00fcz\u00fc geli\u015ftirirken, bu da\u011f\u0131t\u0131k sistem prensiplerini g\u00f6z \u00f6n\u00fcnde bulundurarak mimarimizi tasarlamam\u0131z gerekecektir. Tekil bir VM’deki basit y\u00f6netimden, karma\u015f\u0131k bir k\u00fcme y\u00f6netimine ge\u00e7i\u015f, orkestrat\u00f6r\u00fcm\u00fcz\u00fcn temel tasar\u0131m\u0131n\u0131 ve yeteneklerini k\u00f6kten de\u011fi\u015ftirecektir.<\/p>\n \u00c7ok d\u00fc\u011f\u00fcml\u00fc bir Docker k\u00fcmesini y\u00f6netmek i\u00e7in “hibrit” bir yakla\u015f\u0131m benimsemek, esneklik ve kontrol a\u00e7\u0131s\u0131ndan \u00f6nemli avantajlar sunar. Bu yakla\u015f\u0131mda, genellikle iki ana bile\u015fenimiz olur: merkezi bir orkestrat\u00f6r (controller) ve k\u00fcmedeki her bir i\u015f\u00e7i d\u00fc\u011f\u00fcm\u00fcnde (worker node) \u00e7al\u0131\u015fan hafif Go tabanl\u0131 ajanlar. Bu mimari, merkezi bir beyin taraf\u0131ndan al\u0131nan kararlar\u0131n, yerel ajanlar arac\u0131l\u0131\u011f\u0131yla her d\u00fc\u011f\u00fcmde uygulanmas\u0131n\u0131 sa\u011flar. Go’nun e\u015fzamanl\u0131l\u0131k (concurrency) ve a\u011f yetenekleri, hem merkezi orkestrat\u00f6r\u00fc hem de ajanlar\u0131 geli\u015ftirmek i\u00e7in ideal bir zemin sunar.<\/p>\n Merkezi orkestrat\u00f6r, k\u00fcmenin genel durumunu y\u00f6neten, kullan\u0131c\u0131 isteklerini alan (\u00f6rne\u011fin, “\u015fu uygulamadan 3 kopya \u00e7al\u0131\u015ft\u0131r”), uygun d\u00fc\u011f\u00fcmleri se\u00e7en (scheduling) ve bu kararlar\u0131 ilgili ajanlara ileten ana bile\u015fendir. Ajanlar ise, kendi \u00e7al\u0131\u015ft\u0131klar\u0131 d\u00fc\u011f\u00fcmdeki Docker Engine ile do\u011frudan etkile\u015fime girerek merkezi orkestrat\u00f6rden gelen komutlar\u0131 yerine getirirler. \u00d6rne\u011fin, bir konteyneri ba\u015flat\u0131r, durdurur, sa\u011fl\u0131k durumunu izler ve bu bilgileri merkezi orkestrat\u00f6re geri rapor ederler. Bu sayede, merkezi orkestrat\u00f6r k\u00fcmenin ger\u00e7ek zamanl\u0131 durumuna dair s\u00fcrekli g\u00fcncel bilgiye sahip olur ve olas\u0131 sorunlara kar\u015f\u0131 h\u0131zl\u0131ca aksiyon alabilir.<\/p>\n D\u00fc\u011f\u00fcmler aras\u0131 ileti\u015fim i\u00e7in gRPC (Google Remote Procedure Call) veya HTTP\/REST gibi protokoller kullan\u0131labilir. Go’nun standart k\u00fct\u00fcphanesi HTTP sunucular\u0131 ve istemcileri olu\u015fturmak i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lar sunarken, gRPC daha y\u00fcksek performans ve yap\u0131land\u0131r\u0131lm\u0131\u015f ileti\u015fim (Protocol Buffers ile) sa\u011flar. A\u015fa\u011f\u0131da, basit bir Go ajan\u0131n\u0131n temel yap\u0131s\u0131n\u0131 ve merkezi orkestrat\u00f6r\u00fcn bu ajana bir komut g\u00f6nderme mant\u0131\u011f\u0131n\u0131 g\u00f6steren yal\u0131n bir \u00f6rnek bulunmaktad\u0131r. Bu \u00f6rnek, bir ajan\u0131n belirli bir porttan komutlar\u0131 dinlemesini ve ald\u0131\u011f\u0131 komuta g\u00f6re Docker API ile etkile\u015fime ge\u00e7mesini sim\u00fcle eder:<\/p>\n Yukar\u0131daki ajan kodu, Bir Docker orkestrat\u00f6r\u00fcn\u00fcn ger\u00e7ek g\u00fcc\u00fc, sadece konteynerleri ba\u015flat\u0131p durdurmakla s\u0131n\u0131rl\u0131 de\u011fildir; ayn\u0131 zamanda sistemin de\u011fi\u015fen ko\u015fullara (d\u00fc\u011f\u00fcm ar\u0131zalar\u0131, konteyner \u00e7\u00f6k\u00fc\u015fleri) kar\u015f\u0131 ne kadar sa\u011flam ve esnek tepki verebildi\u011fiyle \u00f6l\u00e7\u00fcl\u00fcr. Bu, \u00f6zellikle “durum y\u00f6netimi” (state management), “hata tolerans\u0131” (fault tolerance) ve “otomatik iyile\u015fme” (self-healing) kavramlar\u0131n\u0131n devreye girdi\u011fi noktad\u0131r. Orkestrat\u00f6r\u00fcm\u00fcz\u00fcn, k\u00fcmenin “arzu edilen durumunu” (desired state) s\u00fcrekli olarak “mevcut durumu” (actual state) ile kar\u015f\u0131la\u015ft\u0131rmas\u0131 ve herhangi bir sapmada d\u00fczeltici eylemler almas\u0131 gerekir.<\/p>\n Arzu edilen durumu kal\u0131c\u0131 olarak saklamak i\u00e7in da\u011f\u0131t\u0131k bir anahtar-de\u011fer deposu (distributed key-value store) kullanmak kritik \u00f6neme sahiptir. Etcd veya Consul gibi sistemler, bu t\u00fcr bir g\u00f6reve m\u00fckemmel \u015fekilde uygundur. Bu depolar, merkezi orkestrat\u00f6r\u00fcn ve ajanlar\u0131n k\u00fcme yap\u0131land\u0131rmas\u0131n\u0131, hangi uygulaman\u0131n ka\u00e7 kopyas\u0131n\u0131n hangi d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015fmas\u0131 gerekti\u011fini ve di\u011fer \u00f6nemli meta verileri g\u00fcvenilir bir \u015fekilde saklamas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, orkestrat\u00f6r, bir uygulaman\u0131n 3 kopyas\u0131n\u0131n \u00e7al\u0131\u015fmas\u0131 gerekti\u011fini Etcd’ye kaydeder. Bir ajan\u0131n veya konteynerin \u00e7\u00f6kmesi durumunda, orkestrat\u00f6r bu durumu Etcd’deki arzu edilen durumla kar\u015f\u0131la\u015ft\u0131r\u0131r ve eksik konteynerleri yeniden ba\u015flatma veya ba\u015fka bir sa\u011fl\u0131kl\u0131 d\u00fc\u011f\u00fcme ta\u015f\u0131ma karar\u0131 al\u0131r.<\/p>\n Hata tolerans\u0131 ve otomatik iyile\u015fme mekanizmalar\u0131, orkestrat\u00f6r\u00fcn proaktif olmas\u0131n\u0131 gerektirir. Konteynerler i\u00e7in sa\u011fl\u0131k kontrolleri (health checks) tan\u0131mlamak bu s\u00fcrecin temelidir. Her konteynerin belirli aral\u0131klarla bir HTTP u\u00e7 noktas\u0131na veya bir komuta yan\u0131t verip vermedi\u011fi kontrol edilebilir. E\u011fer bir konteyner sa\u011fl\u0131k kontrol\u00fcn\u00fc ge\u00e7emezse, orkestrat\u00f6r onu “sa\u011fl\u0131ks\u0131z” (unhealthy) olarak i\u015faretler ve yeniden ba\u015flatma veya farkl\u0131 bir d\u00fc\u011f\u00fcmde yeniden zamanlama gibi eylemler tetikler. Benzer \u015fekilde, d\u00fc\u011f\u00fcmler i\u00e7in de sa\u011fl\u0131k kontrolleri uygulanmal\u0131d\u0131r. Bir d\u00fc\u011f\u00fcm\u00fcn \u00e7evrimd\u0131\u015f\u0131 kalmas\u0131 durumunda, o d\u00fc\u011f\u00fcmdeki t\u00fcm konteynerlerin di\u011fer sa\u011fl\u0131kl\u0131 d\u00fc\u011f\u00fcmlere ta\u015f\u0131nmas\u0131 gerekir. Bu s\u00fcre\u00e7, karma\u015f\u0131k gibi g\u00f6r\u00fcnse de, iyi tasarlanm\u0131\u015f bir durum makinesi ve olay tabanl\u0131 bir mimari ile y\u00f6netilebilir.<\/p>\n Merkezi orkestrat\u00f6r\u00fcn kendisinin de y\u00fcksek eri\u015filebilirli\u011fe sahip olmas\u0131 \u00f6nemlidir. E\u011fer merkezi orkestrat\u00f6r tek bir hata noktas\u0131 (single point of failure) ise, t\u00fcm k\u00fcme y\u00f6netimi durma noktas\u0131na gelir. Bu riski azaltmak i\u00e7in, birden fazla orkestrat\u00f6r \u00f6rne\u011fi \u00e7al\u0131\u015ft\u0131r\u0131labilir ve bunlar aras\u0131nda bir lider se\u00e7imi (leader election) mekanizmas\u0131 kullan\u0131labilir. Raft veya Paxos gibi konsens\u00fcs algoritmalar\u0131, da\u011f\u0131t\u0131k sistemlerde lider se\u00e7imi ve veri tutarl\u0131l\u0131\u011f\u0131 sa\u011flamak i\u00e7in kullan\u0131l\u0131r. Etcd veya Consul gibi ara\u00e7lar genellikle bu lider se\u00e7imi yeteneklerini de b\u00fcnyesinde bar\u0131nd\u0131r\u0131r, bu da kendi algoritmam\u0131z\u0131 yazma y\u00fck\u00fcn\u00fc azalt\u0131r. \u00d6zetle, sa\u011flam bir orkestrat\u00f6r, sadece konteynerleri da\u011f\u0131tmakla kalmaz, ayn\u0131 zamanda sistemin s\u00fcrekli \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131n\u0131 sa\u011flamak i\u00e7in proaktif olarak hatalar\u0131 izler, d\u00fczeltir ve kendini iyile\u015ftirir. Bu \u00f6zellikler, orkestrat\u00f6r\u00fcm\u00fcz\u00fc ger\u00e7ek d\u00fcnya \u00fcretim ortamlar\u0131 i\u00e7in g\u00fcvenilir bir \u00e7\u00f6z\u00fcm haline getirir.<\/p>\n \u015eimdiye kadar \u00f6\u011frendi\u011fimiz temel ve ileri d\u00fczey kavramlar\u0131, somut bir ger\u00e7ek d\u00fcnya senaryosu \u00fczerinde uygulayarak orkestrat\u00f6r\u00fcm\u00fcz\u00fcn yeteneklerini daha iyi anlayal\u0131m. Tipik bir mikroservis uygulamas\u0131, genellikle bir web \u00f6n y\u00fcz\u00fc (frontend), bir veya daha fazla arka u\u00e7 API servisi (backend) ve bir veritaban\u0131 gibi farkl\u0131 bile\u015fenlerden olu\u015fur. Bu bile\u015fenlerin her biri kendi konteynerinde \u00e7al\u0131\u015f\u0131r ve ba\u011f\u0131ms\u0131z olarak \u00f6l\u00e7eklenebilir. Kendi Go tabanl\u0131 hibrit orkestrat\u00f6r\u00fcm\u00fczle bu t\u00fcr bir uygulamay\u0131 nas\u0131l da\u011f\u0131tabilir ve y\u00f6netebiliriz?<\/p>\n Senaryomuzda, basit bir e-ticaret uygulamas\u0131n\u0131 ele alal\u0131m: bir Orkestrat\u00f6r\u00fcm\u00fcz\u00fcn ad\u0131mlar\u0131 \u015fu \u015fekilde olabilir:<\/p>\n Bu senaryo, orkestrat\u00f6r\u00fcm\u00fcz\u00fcn sadece teknik bir ara\u00e7 olmaktan \u00f6te, ger\u00e7ek bir uygulama ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc y\u00f6netebilen kapsaml\u0131 bir platforma d\u00f6n\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc g\u00f6stermektedir. Konteyner sa\u011fl\u0131k kontrolleri, d\u00fc\u011f\u00fcm ar\u0131zalar\u0131nda otomatik iyile\u015fme ve durum y\u00f6netimi prensipleri de bu senaryonun her ad\u0131m\u0131nda aktif olarak devreye girerek uygulaman\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 garanti eder.<\/p>\n Go programlama diliyle hibrit bir Docker orkestrat\u00f6r\u00fc in\u015fa etme yolculu\u011fumuzun sonuna geldik. Tek bir sanal makinede basit bir konteyner y\u00f6neticisi tasla\u011f\u0131ndan ba\u015flayarak, \u00e7ok d\u00fc\u011f\u00fcml\u00fc bir k\u00fcmede \u00f6l\u00e7eklenebilir, hata toleransl\u0131 ve otomatik iyile\u015fen bir sistemi nas\u0131l geli\u015ftirebilece\u011fimizi ad\u0131m ad\u0131m inceledik. Bu s\u00fcre\u00e7te, Docker Engine API’nin g\u00fcc\u00fcn\u00fc, Go’nun e\u015fzamanl\u0131l\u0131k yeteneklerini, da\u011f\u0131t\u0131k sistemlerin temel zorluklar\u0131n\u0131, durum y\u00f6netiminin \u00f6nemini ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda bir mikroservis uygulamas\u0131n\u0131n nas\u0131l orkestra edilece\u011fini \u00f6\u011frendik.<\/p>\n Kendi orkestrat\u00f6r\u00fcn\u00fcz\u00fc geli\u015ftirmenin de\u011feri, sadece teknik bilgi birikimi kazanmakla s\u0131n\u0131rl\u0131 de\u011fildir. Bu s\u00fcre\u00e7, mevcut orkestrasyon ara\u00e7lar\u0131n\u0131n (Kubernetes, Docker Swarm) i\u00e7 i\u015fleyi\u015fini derinlemesine anlaman\u0131za, \u00f6zel ihtiya\u00e7lar\u0131n\u0131za g\u00f6re esnek \u00e7\u00f6z\u00fcmler \u00fcretmenize ve altyap\u0131 y\u00f6netiminde tam kontrol sa\u011flaman\u0131za olanak tan\u0131r. Her ne kadar Kubernetes gibi olgun \u00e7\u00f6z\u00fcmlerin sundu\u011fu geni\u015f ekosistem ve topluluk deste\u011fi inkar edilemez olsa da, baz\u0131 ni\u015f kullan\u0131m durumlar\u0131, \u00f6\u011frenme ama\u00e7l\u0131 projeler veya \u00e7ok hafif, \u00f6zelle\u015ftirilmi\u015f bir ayak izi gerektiren ortamlar i\u00e7in kendi orkestrat\u00f6r\u00fcn\u00fcz\u00fc in\u015fa etmek mant\u0131kl\u0131 bir se\u00e7im olabilir.<\/p>\n Geli\u015ftirdi\u011fimiz bu orkestrat\u00f6r\u00fc daha da ileriye ta\u015f\u0131mak i\u00e7in baz\u0131 ipu\u00e7lar\u0131 ve gelecek vizyonlar\u0131 sunabiliriz:<\/p>\n Bu yolculuk, sadece bir yaz\u0131l\u0131m projesi de\u011fil, ayn\u0131 zamanda da\u011f\u0131t\u0131k sistemler mimarisine dair derin bir \u00f6\u011frenme deneyimidir. Kendi orkestrat\u00f6r\u00fcn\u00fcz\u00fc geli\u015ftirirken kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131z her zorluk, sizi daha iyi bir m\u00fchendis yapacak ve modern altyap\u0131lar\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131na dair paha bi\u00e7ilmez i\u00e7g\u00f6r\u00fcler sunacakt\u0131r. Gelecekte, bu t\u00fcr \u00f6zel orkestrat\u00f6rler, kenar bili\u015fim (edge computing) veya \u00f6zel donan\u0131m entegrasyonlar\u0131 gibi ni\u015f alanlarda \u00f6nemli bir rol oynayabilir.<\/p>\n Kubernetes, geni\u015f bir ekosisteme ve g\u00fc\u00e7l\u00fc \u00f6zelliklere sahip end\u00fcstri standard\u0131 bir \u00e7\u00f6z\u00fcmd\u00fcr. Ancak, kendi orkestrat\u00f6r\u00fcn\u00fcz\u00fc geli\u015ftirmek, da\u011f\u0131t\u0131k sistemler hakk\u0131nda derinlemesine bilgi edinmenizi, \u00f6zel ihtiya\u00e7lar\u0131n\u0131za g\u00f6re esnek \u00e7\u00f6z\u00fcmler olu\u015fturman\u0131z\u0131 ve kaynak t\u00fcketimi a\u00e7\u0131s\u0131ndan daha hafif bir sistem kurman\u0131z\u0131 sa\u011flayabilir. \u00d6\u011frenme, \u00f6zelle\u015ftirme veya belirli ni\u015f senaryolar i\u00e7in de\u011ferlidir.<\/p>\n<\/li>\n Go, e\u015fzamanl\u0131l\u0131k (goroutine’ler ve kanallar), y\u00fcksek performans, g\u00fc\u00e7l\u00fc a\u011f yetenekleri ve statik derleme gibi \u00f6zellikleriyle sistem programlama ve da\u011f\u0131t\u0131k sistemler i\u00e7in m\u00fckemmel bir dildir. Docker Engine API ile kolayca entegre olabilir ve k\u00fc\u00e7\u00fck, verimli ikili dosyalar (binary) \u00fcretir, bu da onu orkestrat\u00f6r bile\u015fenleri i\u00e7in ideal k\u0131lar.<\/p>\n<\/li>\n “Hibrit” terimi bu ba\u011flamda, merkezi bir kontrol mekanizmas\u0131 ile k\u00fcmedeki her d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015fan yerel ajanlar\u0131n birle\u015fimini ifade eder. Merkezi orkestrat\u00f6r genel kararlar\u0131 al\u0131r ve g\u00f6revleri da\u011f\u0131t\u0131rken, ajanlar yerel Docker daemon ile do\u011frudan etkile\u015fime girerek bu g\u00f6revleri yerine getirir. Bu, hem merkezi kontrol hem de d\u00fc\u011f\u00fcm d\u00fczeyinde esneklik sa\u011flar.<\/p>\n<\/li>\n Kesinlikle zorunlu olmasa da, da\u011f\u0131t\u0131k bir orkestrat\u00f6rde arzu edilen durumu g\u00fcvenilir bir \u015fekilde saklamak ve d\u00fc\u011f\u00fcmler aras\u0131nda tutarl\u0131l\u0131\u011f\u0131 sa\u011flamak i\u00e7in Etcd veya Consul gibi da\u011f\u0131t\u0131k anahtar-de\u011fer depolar\u0131 \u015fiddetle tavsiye edilir. Bu ara\u00e7lar, lider se\u00e7imi, servis ke\u015ffi ve konfig\u00fcrasyon y\u00f6netimi gibi ek yetenekler de sunar.<\/p>\n<\/li>\n<\/ul>\n #Go #Docker #Orkestrasyon #Da\u011f\u0131t\u0131kSistemler #KonteynerY\u00f6netimi #Yaz\u0131l\u0131mMimarisi #DevOps #Teknoloji<\/p>\ndocker\/docker\/client<\/code> k\u00fct\u00fcphanesi, bu API ile kolayca ileti\u015fim kurmam\u0131z\u0131 sa\u011flar.<\/p>\n\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"github.com\/docker\/docker\/api\/types\"\n\t\"github.com\/docker\/docker\/client\"\n)\n\nfunc main() {\n\tctx := context.Background()\n\tcli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tcontainers, err := cli.ContainerList(ctx, types.ContainerListOptions{})\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tfmt.Println(\"\u00c7al\u0131\u015fan Konteynerler:\")\n\tfor _, container := range containers {\n\t\tfmt.Printf(\"ID: %s, \u0130simler: %v, Resim: %s\\n\", container.ID[:10], container.Names, container.Image)\n\t}\n}\n <\/code><\/pre>\n<\/p><\/div>\ncli.ContainerCreate<\/code> ve cli.ContainerStart<\/code> fonksiyonlar\u0131n\u0131 kullanabiliriz. Ancak, ger\u00e7ek d\u00fcnya senaryolar\u0131nda tek bir sunucu \u00fczerindeki konteyner y\u00f6netimi yeterli de\u011fildir. Uygulamalar\u0131m\u0131z\u0131n y\u00fcksek eri\u015filebilirlik (high availability) sa\u011flamas\u0131, artan y\u00fcke kar\u015f\u0131 \u00f6l\u00e7eklenebilir olmas\u0131 ve sunucu ar\u0131zalar\u0131na dayan\u0131kl\u0131 olmas\u0131 gerekir. Bu ihtiya\u00e7lar bizi “\u00e7ok d\u00fc\u011f\u00fcml\u00fc” (multi-node) mimariye y\u00f6nlendirir.<\/p>\nHibrit Yakla\u015f\u0131m: Go Ajanlar\u0131 ve Merkezi Orkestrat\u00f6r\u00fcn Mimari Dans\u0131 Nas\u0131l \u0130\u015fler?<\/h3>\n
\n\/\/ Basit Go Ajan\u0131 (worker.go)\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"log\"\n\t\"net\/http\"\n\t\"github.com\/docker\/docker\/api\/types\/container\"\n\t\"github.com\/docker\/docker\/client\"\n)\n\nfunc main() {\n\thttp.HandleFunc(\"\/start-container\", func(w http.ResponseWriter, r *http.Request) {\n\t\timageName := r.URL.Query().Get(\"image\")\n\t\tif imageName == \"\" {\n\t\t\thttp.Error(w, \"Resim ad\u0131 belirtilmeli\", http.StatusBadRequest)\n\t\t\treturn\n\t\t}\n\n\t\tctx := context.Background()\n\t\tcli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())\n\t\tif err != nil {\n\t\t\tlog.Printf(\"Docker istemcisi olu\u015fturulamad\u0131: %v\", err)\n\t\t\thttp.Error(w, \"\u0130\u00e7 sunucu hatas\u0131\", http.StatusInternalServerError)\n\t\t\treturn\n\t\t}\n\n\t\tresp, err := cli.ContainerCreate(ctx, &container.Config{\n\t\t\tImage: imageName,\n\t\t}, nil, nil, nil, \"\")\n\t\tif err != nil {\n\t\t\tlog.Printf(\"Konteyner olu\u015fturulamad\u0131: %v\", err)\n\t\t\thttp.Error(w, fmt.Sprintf(\"Konteyner olu\u015fturma hatas\u0131: %v\", err), http.StatusInternalServerError)\n\t\t\treturn\n\t\t}\n\n\t\tif err := cli.ContainerStart(ctx, resp.ID, types.ContainerStartOptions{}); err != nil {\n\t\t\tlog.Printf(\"Konteyner ba\u015flat\u0131lamad\u0131: %v\", err)\n\t\t\thttp.Error(w, fmt.Sprintf(\"Konteyner ba\u015flatma hatas\u0131: %v\", err), http.StatusInternalServerError)\n\t\t\treturn\n\t\t}\n\n\t\tfmt.Fprintf(w, \"Konteyner %s ba\u015far\u0131yla ba\u015flat\u0131ld\u0131 (ID: %s)\\n\", imageName, resp.ID[:10])\n\t})\n\n\tlog.Println(\"Ajan dinlemede: :8080\")\n\tlog.Fatal(http.ListenAndServe(\":8080\", nil))\n}\n <\/code><\/pre>\n<\/p><\/div>\n\/start-container<\/code> URL’sine gelen bir HTTP iste\u011fini dinler ve belirtilen resim ad\u0131yla bir Docker konteyneri ba\u015flat\u0131r. Merkezi orkestrat\u00f6r ise, bu ajana bir HTTP iste\u011fi g\u00f6ndererek bir konteyner ba\u015flatma komutunu iletebilir. Bu basit model, daha karma\u015f\u0131k i\u015flevsellikler (durum raporlama, kaynak izleme, hata i\u015fleme) eklenerek geni\u015fletilebilir. \u00d6rne\u011fin, orkestrat\u00f6r, k\u00fcmedeki her ajan\u0131n kaynak kullan\u0131m\u0131n\u0131 (CPU, bellek) d\u00fczenli olarak sorgulayabilir ve bu bilgilere dayanarak daha ak\u0131ll\u0131 zamanlama (scheduling) kararlar\u0131 alabilir. Bu hibrit mimari, hem merkezi kontrol\u00fcn avantajlar\u0131n\u0131 hem de d\u00fc\u011f\u00fcm d\u00fczeyinde esnekli\u011fi bir araya getirerek, kendi \u00f6zel ihtiya\u00e7lar\u0131m\u0131za g\u00f6re \u00f6l\u00e7eklenebilir ve y\u00f6netilebilir bir orkestrasyon \u00e7\u00f6z\u00fcm\u00fc sunar.<\/p>\nSa\u011flaml\u0131k ve Esneklik: Durum Y\u00f6netimi, Hata Tolerans\u0131 ve Otomatik \u0130yile\u015fme Nas\u0131l Sa\u011flan\u0131r?<\/h3>\n
Ger\u00e7ek D\u00fcnya Senaryosu: \u00d6l\u00e7eklenebilir Bir Mikroservis Uygulamas\u0131n\u0131n Orkestrasyonu Nas\u0131l Yap\u0131l\u0131r?<\/h3>\n
web-ui<\/code> (\u00f6rne\u011fin, Nginx \u00fczerinde \u00e7al\u0131\u015fan bir React uygulamas\u0131), bir api-service<\/code> (\u00f6rne\u011fin, Go veya Node.js ile yaz\u0131lm\u0131\u015f bir REST API) ve bir product-db<\/code> (\u00f6rne\u011fin, PostgreSQL). Orkestrat\u00f6r\u00fcm\u00fcz\u00fcn bu \u00fc\u00e7 servisi k\u00fcme \u00fczerinde da\u011f\u0131tmas\u0131, birbirleriyle ileti\u015fim kurmalar\u0131n\u0131 sa\u011flamas\u0131 ve gerekti\u011finde \u00f6l\u00e7eklendirmesi gerekiyor. Da\u011f\u0131t\u0131m stratejisi olarak, web-ui<\/code> ve api-service<\/code>‘in y\u00fcksek eri\u015filebilirlik i\u00e7in birden fazla d\u00fc\u011f\u00fcmde (en az 2-3 kopya) \u00e7al\u0131\u015fmas\u0131n\u0131 isterken, product-db<\/code>‘nin veri tutarl\u0131l\u0131\u011f\u0131 ve performans nedeniyle belirli bir d\u00fc\u011f\u00fcmde veya \u00f6zel bir depolama birimiyle \u00e7al\u0131\u015fmas\u0131n\u0131 tercih edebiliriz.<\/p>\n\n
web-ui<\/code> i\u00e7in 3 kopya isteniyorsa, orkestrat\u00f6r k\u00fcmedeki en az y\u00fckl\u00fc veya belirli etiketlere sahip 3 d\u00fc\u011f\u00fcm\u00fc se\u00e7er. Veritaban\u0131 i\u00e7in ise, kal\u0131c\u0131 depolama (persistent storage) ba\u011fl\u0131 olan veya belirli bir donan\u0131ma sahip d\u00fc\u011f\u00fcmler tercih edilebilir.<\/li>\napi-service<\/code>, product-db<\/code>‘ye product-db:5432<\/code> adresi \u00fczerinden eri\u015febilir. K\u00fcme i\u00e7inde konteynerler aras\u0131 ileti\u015fimi sa\u011flamak i\u00e7in Docker’\u0131n overlay a\u011flar\u0131 veya Go ile geli\u015ftirilmi\u015f \u00f6zel bir a\u011f katman\u0131 kullan\u0131labilir. Orkestrat\u00f6r, d\u0131\u015f d\u00fcnyaya a\u00e7\u0131lacak servisler i\u00e7in port e\u015flemeleri ve y\u00fck dengeleyici (load balancer) yap\u0131land\u0131rmalar\u0131n\u0131 da y\u00f6netebilir.<\/li>\nweb-ui<\/code> veya api-service<\/code> i\u00e7in ek kopya ba\u015flatma komutlar\u0131 alabilir. Bu komutlar do\u011frultusunda, orkestrat\u00f6r yeni d\u00fc\u011f\u00fcmler se\u00e7er ve ilgili servislerin yeni kopyalar\u0131n\u0131 da\u011f\u0131t\u0131r. Talep azald\u0131\u011f\u0131nda ise gereksiz kopyalar\u0131 durdurarak kaynaklar\u0131 serbest b\u0131rak\u0131r.<\/li>\n<\/ol>\nSonu\u00e7: Kendi Orkestrat\u00f6r\u00fcn\u00fcz\u00fc Geli\u015ftirmenin De\u011feri, \u0130leri \u0130pu\u00e7lar\u0131 ve Gelecek Vizyonu<\/h3>\n
\n
S\u0131k\u00e7a Sorulan Sorular<\/h4>\n
\n