Modern bulut tabanl\u0131 uygulamalar\u0131n ve mikroservis mimarilerinin y\u00fckseli\u015fiyle birlikte, da\u011f\u0131t\u0131k sistemlerin y\u00f6netimi kritik bir hale gelmi\u015ftir. Bu ba\u011flamda, CoreOS gibi hafif, kapsay\u0131c\u0131 odakl\u0131 i\u015fletim sistemleri, k\u00fcme y\u00f6netimini kolayla\u015ft\u0131ran ara\u00e7larla birlikte \u00f6ne \u00e7\u0131km\u0131\u015ft\u0131r. CoreOS, temel olarak systemd, etcd ve Docker gibi bile\u015fenler \u00fczerine in\u015fa edilmi\u015f, otomatik g\u00fcncellemeler ve g\u00fcvenlik odakl\u0131 bir Linux da\u011f\u0131t\u0131m\u0131d\u0131r. Ancak, bir CoreOS k\u00fcmesindeki servisleri t\u00fcm d\u00fc\u011f\u00fcmler aras\u0131nda tutarl\u0131 ve \u00f6l\u00e7eklenebilir bir \u015fekilde y\u00f6netmek i\u00e7in ek bir orkestrasyon katman\u0131na ihtiya\u00e7 duyulur. \u0130\u015fte bu noktada Fleet ve onun komut sat\u0131r\u0131 aray\u00fcz\u00fc olan fleetctl devreye girer.<\/p>\n
Fleet, CoreOS’un ilk zamanlar\u0131nda, da\u011f\u0131t\u0131k bir init sistemi olarak tasarlanm\u0131\u015f, systemd unit dosyalar\u0131n\u0131 bir k\u00fcme genelinde \u00e7al\u0131\u015ft\u0131rman\u0131za olanak tan\u0131yan bir ara\u00e7t\u0131. Her ne kadar g\u00fcn\u00fcm\u00fczde Kubernetes gibi daha geli\u015fmi\u015f konteyner orkestrasyon platformlar\u0131 taraf\u0131ndan b\u00fcy\u00fck \u00f6l\u00e7\u00fcde g\u00f6lgede b\u0131rak\u0131lm\u0131\u015f ve aktif geli\u015ftirilmesi durdurulmu\u015f olsa da, Fleet’in \u00e7al\u0131\u015fma prensiplerini ve CoreOS ekosistemindeki yerini anlamak, da\u011f\u0131t\u0131k sistem y\u00f6netimi ve konteyner orkestrasyonunun temel kavramlar\u0131n\u0131 kavramak a\u00e7\u0131s\u0131ndan hala de\u011ferli bir \u00f6\u011frenme deneyimi sunmaktad\u0131r. Bu makale, Fleet ve fleetctl’in CoreOS k\u00fcmelerinde nas\u0131l kullan\u0131ld\u0131\u011f\u0131n\u0131, mimarisini, temel ve geli\u015fmi\u015f komutlar\u0131n\u0131, pratik \u00f6rneklerini ve g\u00fcncel durumu hakk\u0131nda kapsaml\u0131 bir rehber sunmaktad\u0131r.<\/p>\n
Fleet’in nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak i\u00e7in CoreOS’un temel yap\u0131 ta\u015flar\u0131n\u0131 kavramak \u00f6nemlidir. CoreOS, da\u011f\u0131t\u0131k sistemlerin ihtiya\u00e7lar\u0131na \u00f6zel olarak tasarlanm\u0131\u015f bir i\u015fletim sistemidir ve etcd ile systemd gibi kilit teknolojileri b\u00fcnyesinde bar\u0131nd\u0131r\u0131r.<\/p>\n
CoreOS, “immutable infrastructure” (de\u011fi\u015fmez altyap\u0131) felsefesiyle tasarlanm\u0131\u015ft\u0131r. Bu, i\u015fletim sisteminin kendisinin de\u011fi\u015ftirilemez oldu\u011fu ve g\u00fcncellemelerin atomik olarak t\u00fcm sistemin de\u011fi\u015ftirilmesiyle yap\u0131ld\u0131\u011f\u0131 anlam\u0131na gelir. Uygulamalar ise Docker konteynerleri i\u00e7inde \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Bu yakla\u015f\u0131m, sistem tutarl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenli\u011fini art\u0131r\u0131rken, karma\u015f\u0131k ba\u011f\u0131ml\u0131l\u0131k sorunlar\u0131n\u0131 da en aza indirir. CoreOS’un hafif yap\u0131s\u0131 ve konteyner odakl\u0131 yakla\u015f\u0131m\u0131, onu da\u011f\u0131t\u0131k servisler i\u00e7in ideal bir platform haline getirir.<\/p>\n
etcd, CoreOS’un kalbinde yer alan, da\u011f\u0131t\u0131k ve tutarl\u0131 bir anahtar-de\u011fer deposudur. Da\u011f\u0131t\u0131k sistemlerdeki yap\u0131land\u0131rma verilerini, servis ke\u015ffi bilgilerini ve koordinasyon durumlar\u0131n\u0131 g\u00fcvenilir bir \u015fekilde saklamak i\u00e7in kullan\u0131l\u0131r. etcd, Raft konsens\u00fcs algoritmas\u0131n\u0131 kullanarak y\u00fcksek eri\u015filebilirlik ve veri tutarl\u0131l\u0131\u011f\u0131 sa\u011flar. CoreOS k\u00fcmelerindeki t\u00fcm d\u00fc\u011f\u00fcmler, birbirleriyle ve di\u011fer servislerle ileti\u015fim kurmak i\u00e7in etcd’yi kullan\u0131r. Fleet de servislerin durumunu ve yerle\u015fim bilgilerini etcd \u00fczerinde depolar ve bu sayede k\u00fcme genelinde servislerin orkestrasyonunu m\u00fcmk\u00fcn k\u0131lar.<\/p>\n
systemd, Linux i\u015fletim sistemlerinde servisleri ve sistem kaynaklar\u0131n\u0131 y\u00f6netmek i\u00e7in kullan\u0131lan bir init sistemidir. Bir\u00e7ok modern Linux da\u011f\u0131t\u0131m\u0131nda varsay\u0131lan init sistemi olarak g\u00f6rev yapar. systemd, servisleri “unit” ad\u0131 verilen yap\u0131land\u0131rma dosyalar\u0131 arac\u0131l\u0131\u011f\u0131yla tan\u0131mlar ve y\u00f6netir. Bu unit dosyalar\u0131, servislerin nas\u0131l ba\u015flat\u0131laca\u011f\u0131n\u0131, durdurulaca\u011f\u0131n\u0131, hangi ba\u011f\u0131ml\u0131l\u0131klara sahip oldu\u011funu ve hangi kaynaklar\u0131 kullanaca\u011f\u0131n\u0131 belirler. CoreOS’ta her bir d\u00fc\u011f\u00fcmde systemd \u00e7al\u0131\u015f\u0131r ve yerel servisleri y\u00f6netir. Fleet ise bu yerel systemd’lerin \u00fczerine in\u015fa edilerek, unit dosyalar\u0131n\u0131 bir k\u00fcme genelinde da\u011f\u0131t\u0131k olarak y\u00f6netme yetene\u011fi kazand\u0131r\u0131r.<\/p>\n
CoreOS’un temel bile\u015fenleri olan etcd ve systemd, tek bir d\u00fc\u011f\u00fcm \u00fczerindeki servis y\u00f6netiminde olduk\u00e7a etkilidir. Ancak, birden fazla CoreOS d\u00fc\u011f\u00fcm\u00fcnden olu\u015fan bir k\u00fcmede, servislerin da\u011f\u0131t\u0131k olarak y\u00f6netilmesi, y\u00fck dengelemesi ve y\u00fcksek eri\u015filebilirlik gibi zorluklar ortaya \u00e7\u0131kar. \u0130\u015fte Fleet bu zorluklar\u0131 a\u015fmak i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n
Fleet, CoreOS k\u00fcmeleri i\u00e7in tasarlanm\u0131\u015f, da\u011f\u0131t\u0131k bir systemd olarak tan\u0131mlanabilir. Temel amac\u0131, systemd unit dosyalar\u0131n\u0131 al\u0131p bunlar\u0131 bir CoreOS k\u00fcmesindeki uygun d\u00fc\u011f\u00fcmlere da\u011f\u0131tmak ve y\u00f6netmektir. Bir servisi bir d\u00fc\u011f\u00fcmde ba\u015flatmak yerine, Fleet ile bir servisi k\u00fcme genelinde ba\u015flatma talimat\u0131 verirsiniz ve Fleet, etcd’yi kullanarak bu servisi hangi d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015ft\u0131raca\u011f\u0131na karar verir ve o d\u00fc\u011f\u00fcmdeki yerel systemd’yi kullanarak servisi ba\u015flat\u0131r. Bu sayede, geli\u015ftiriciler ve sistem y\u00f6neticileri, servislerini tek bir mant\u0131ksal birim olarak d\u00fc\u015f\u00fcnebilir ve k\u00fcmenin karma\u015f\u0131kl\u0131\u011f\u0131yla do\u011frudan u\u011fra\u015fmak zorunda kalmazlar.<\/p>\n
B\u00fcy\u00fck \u00f6l\u00e7ekli da\u011f\u0131t\u0131k sistemlerde servis y\u00f6netimi, \u00e7e\u015fitli zorluklar\u0131 beraberinde getirir: Fleet, bu zorluklara a\u015fa\u011f\u0131daki gibi \u00e7\u00f6z\u00fcmler sunar: Fleet, etcd’yi temel alarak, CoreOS k\u00fcmesindeki t\u00fcm d\u00fc\u011f\u00fcmler aras\u0131nda servislerin orkestrasyonunu sa\u011flar. Mimarisini ve nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak, Fleet’i etkin bir \u015fekilde kullanmak i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n Fleet mimarisi temel olarak \u00fc\u00e7 ana bile\u015fenden olu\u015fur: Fleet’in \u00e7al\u0131\u015fma prensibi olduk\u00e7a basittir ancak da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 gizler: CoreOS i\u015fletim sistemlerinde Bu komut, Bu y\u00f6ntem, etcd’nin herkese a\u00e7\u0131k olmas\u0131 durumunda g\u00fcvenlik riskleri ta\u015f\u0131r ve genellikle \u00fcretim ortamlar\u0131nda \u00f6nerilmez.<\/p>\n K\u00fcmenin genel durumunu ve \u00e7al\u0131\u015fan servisleri g\u00f6r\u00fcnt\u00fclemek i\u00e7in a\u015fa\u011f\u0131daki komutlar kullan\u0131l\u0131r: \u00c7\u0131kt\u0131 \u00f6rne\u011fi:<\/p>\n * \u00c7\u0131kt\u0131 \u00f6rne\u011fi:<\/p>\n * * Fleet, standart systemd unit dosyalar\u0131n\u0131 kullan\u0131r. Ancak, da\u011f\u0131t\u0131k davran\u0131\u015f\u0131n\u0131 kontrol etmek i\u00e7in Yukar\u0131daki \u00f6rnekte: Unit dosyalar\u0131n\u0131 olu\u015fturduktan sonra, bunlar\u0131 Fleet k\u00fcmesine g\u00f6ndermeniz ve ba\u015flatman\u0131z gerekir: 2. Unit’i Ba\u015flatma (Start):<\/strong> Etcd’ye kaydedilmi\u015f unit’i k\u00fcmede ba\u015flatma talimat\u0131n\u0131 verir. Fleet, uygun bir d\u00fc\u011f\u00fcm bulup servisi orada \u00e7al\u0131\u015ft\u0131r\u0131r.<\/p>\n Bu iki ad\u0131m\u0131 tek bir komutla da yapabilirsiniz: Bir servisi durdurmak veya k\u00fcmeden tamamen kald\u0131rmak i\u00e7in a\u015fa\u011f\u0131daki komutlar\u0131 kullan\u0131n: * Unit’i Kald\u0131rma (Destroy):<\/strong> Servisi durdurur ve unit dosyas\u0131n\u0131 etcd’den tamamen siler.<\/p>\n Bir unit dosyas\u0131n\u0131 g\u00fcncelledikten sonra, de\u011fi\u015fiklikleri k\u00fcmede uygulamak i\u00e7in servisi yeniden g\u00f6ndermeniz ve ba\u015flatman\u0131z gerekir: 2. G\u00fcncellenmi\u015f Unit Dosyas\u0131n\u0131 G\u00f6nder ve Ba\u015flat:<\/strong><\/p>\n S\u0131f\u0131r kesinti s\u00fcreli g\u00fcncellemeler i\u00e7in, servisin birden fazla \u00f6rne\u011fini \u00e7al\u0131\u015ft\u0131r\u0131p, yeni s\u00fcr\u00fcm\u00fc ayr\u0131 bir isimle ba\u015flat\u0131p, eski s\u00fcr\u00fcm\u00fc durdurmadan \u00f6nce yeni s\u00fcr\u00fcm\u00fcn haz\u0131r olmas\u0131n\u0131 beklemek gibi daha geli\u015fmi\u015f stratejiler gerekebilir. Fleet, bu t\u00fcr karma\u015f\u0131k senaryolar\u0131 do\u011frudan desteklemese de, temel mekanizmalar\u0131 sa\u011flayarak bu t\u00fcr stratejilerin uygulanmas\u0131na olanak tan\u0131r.<\/p>\n Fleet, sadece servisleri ba\u015flat\u0131p durdurmaktan daha fazlas\u0131n\u0131 yapabilir. Geli\u015fmi\u015f \u00f6zellikleri sayesinde, servis yerle\u015fimini kontrol edebilir, ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netebilir ve daha dayan\u0131kl\u0131 uygulamalar olu\u015fturabilirsiniz.<\/p>\n Systemd unit dosyalar\u0131nda oldu\u011fu gibi, Fleet unit dosyalar\u0131nda da servisler aras\u0131 ba\u011f\u0131ml\u0131l\u0131klar\u0131 tan\u0131mlayabilirsiniz. Bu, bir servisin ba\u015fka bir servis ba\u015flat\u0131lmadan \u00f6nce \u00e7al\u0131\u015fmamas\u0131n\u0131 veya ba\u015fka bir servisle birlikte ba\u015flat\u0131lmas\u0131n\u0131 sa\u011flamak i\u00e7in \u00f6nemlidir. \u00d6rnek: Bir veritaban\u0131 servisi ba\u015flat\u0131lmadan \u00f6nce bir uygulaman\u0131n ba\u015flamamas\u0131n\u0131 sa\u011flamak:<\/p>\n Bu, Fleet’in en g\u00fc\u00e7l\u00fc \u00f6zelliklerinden biri, servislerin k\u00fcmedeki belirli d\u00fc\u011f\u00fcmlere yerle\u015ftirilmesi i\u00e7in k\u0131s\u0131tlamalar tan\u0131mlayabilme yetene\u011fidir. Bu, D\u00fc\u011f\u00fcme meta veri eklemek i\u00e7in: Bu, Fleet, temel y\u00fcksek eri\u015filebilirlik ve \u00f6l\u00e7eklenebilirlik mekanizmalar\u0131n\u0131 sunar: Fleet, CoreOS ekosisteminde \u00e7e\u015fitli da\u011f\u0131t\u0131k uygulama kal\u0131plar\u0131n\u0131 desteklemek i\u00e7in kullan\u0131labilir: Fleet, CoreOS’un ilk zamanlar\u0131nda konteyner orkestrasyonunda \u00f6nemli bir rol oynam\u0131\u015f olsa da, zamanla Kubernetes, Docker Swarm ve Mesos gibi daha kapsaml\u0131 ve \u00f6zellikli platformlar ortaya \u00e7\u0131km\u0131\u015ft\u0131r. Fleet, \u00f6zellikle CoreOS’un “distributed systemd” felsefesine uygun, daha hafif ve basit orkestrasyon ihtiya\u00e7lar\u0131 i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu nedenle, karma\u015f\u0131k mikroservis mimarileri veya \u00e7ok b\u00fcy\u00fck \u00f6l\u00e7ekli da\u011f\u0131t\u0131mlar i\u00e7in Kubernetes gibi ara\u00e7lar daha uygunken, daha k\u00fc\u00e7\u00fck veya \u00f6zel CoreOS k\u00fcmeleri i\u00e7in Fleet hala anla\u015f\u0131lmas\u0131 gereken bir ara\u00e7t\u0131r.<\/p>\n \u015eimdiye kadar \u00f6\u011frendiklerimizi peki\u015ftirmek i\u00e7in, Fleet ve fleetctl kullanarak basit bir web uygulamas\u0131n\u0131 CoreOS k\u00fcmesine nas\u0131l da\u011f\u0131tabilece\u011fimize dair pratik bir \u00f6rnek inceleyelim.<\/p>\n Bir CoreOS k\u00fcmemiz var ve bu k\u00fcmeye a\u015fa\u011f\u0131daki servisleri da\u011f\u0131tmak istiyoruz: Her iki servis de Docker konteynerleri olarak \u00e7al\u0131\u015facak. Nginx’in 80 portundan d\u0131\u015far\u0131ya a\u00e7\u0131k olmas\u0131n\u0131 ve Flask uygulamas\u0131n\u0131n ise Nginx’in proxy yapabilece\u011fi dahili bir portta \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayaca\u011f\u0131z.<\/p>\n Bu unit dosyas\u0131, Nginx konteynerini Basit bir Flask uygulamas\u0131 i\u00e7in bir Dockerfile:<\/p>\n Bu Dockerfile ve \u015eimdi Flask uygulamas\u0131 i\u00e7in unit dosyas\u0131:<\/p>\n Bu unit dosyas\u0131, Flask uygulamas\u0131n\u0131 1. Unit Dosyalar\u0131n\u0131 Olu\u015fturun:<\/strong> 3. Durumlar\u0131 Kontrol Edin:<\/strong><\/p>\n Bu \u00f6rnek, Fleet’in nas\u0131l temel bir Docker tabanl\u0131 uygulamay\u0131 CoreOS k\u00fcmesinde da\u011f\u0131tmak i\u00e7in kullan\u0131labilece\u011fini g\u00f6stermektedir. Daha karma\u015f\u0131k senaryolarda, Nginx’i bir reverse proxy olarak yap\u0131land\u0131r\u0131p Flask uygulamas\u0131na y\u00f6nlendirmek, servis ke\u015ffi ara\u00e7lar\u0131n\u0131 kullanmak ve daha fazla \u00f6l\u00e7eklenebilirlik sa\u011flamak i\u00e7in unit \u015fablonlar\u0131n\u0131 ( Fleet ve CoreOS k\u00fcmelerini y\u00f6netirken g\u00fcvenlik ve en iyi uygulamalar \u00f6nemlidir.<\/p>\n * SSH T\u00fcnelleme Kullan\u0131n:<\/strong> * Ayr\u0131cal\u0131kl\u0131 Konteynerlerden Ka\u00e7\u0131n\u0131n:<\/strong> M\u00fcmk\u00fcn oldu\u011funca * Log Y\u00f6netimi:<\/strong> Servislerinizin loglar\u0131n\u0131 d\u00fczenli olarak kontrol edin ( Fleet, CoreOS ekosisteminde \u00f6nemli bir rol oynam\u0131\u015f olsa da, konteyner orkestrasyon d\u00fcnyas\u0131 h\u0131zla geli\u015fmi\u015ftir ve Fleet’in konumu de\u011fi\u015fmi\u015ftir.<\/p>\n CoreOS’un Red Hat taraf\u0131ndan sat\u0131n al\u0131nmas\u0131 ve ard\u0131ndan Red Hat OpenShift ve Kubernetes’e odaklan\u0131lmas\u0131yla birlikte, Fleet’in aktif geli\u015ftirilmesi durdurulmu\u015ftur. Red Hat, CoreOS’un gelece\u011fini Kubernetes tabanl\u0131 OpenShift Container Platform’a entegre etmi\u015ftir. Bu nedenle, Fleet art\u0131k aktif olarak geli\u015ftirilmeyen ve “deprecated” (kullan\u0131mdan kald\u0131r\u0131lm\u0131\u015f) bir ara\u00e7t\u0131r.<\/strong><\/p>\n Bu bilgi, Fleet’i \u00f6\u011frenen veya mevcut bir Fleet kurulumunu y\u00f6neten herkes i\u00e7in kritik \u00f6neme sahiptir. Yeni projeler i\u00e7in Fleet kullanmak yerine, modern konteyner orkestrasyon ara\u00e7lar\u0131na y\u00f6nelmek \u015fiddetle tavsiye edilir. Ancak, eski CoreOS kurulumlar\u0131n\u0131 anlamak veya da\u011f\u0131t\u0131k sistemlerin temel prensiplerini \u00f6\u011frenmek amac\u0131yla Fleet’i bilmek hala de\u011ferlidir.<\/p>\n G\u00fcn\u00fcm\u00fczde, Fleet’in yerini alan veya ondan \u00e7ok daha kapsaml\u0131 \u00f6zellikler sunan bir\u00e7ok konteyner orkestrasyon platformu bulunmaktad\u0131r: Bu modern alternatifler, Fleet’in sundu\u011fu temel orkestrasyon yeteneklerinin \u00e7ok \u00f6tesine ge\u00e7erek, daha karma\u015f\u0131k, \u00f6l\u00e7eklenebilir ve dayan\u0131kl\u0131 da\u011f\u0131t\u0131k uygulamalar\u0131n y\u00f6netimi i\u00e7in gerekli ara\u00e7lar\u0131 sunar.<\/p>\n Fleet ve fleetctl, CoreOS’un ilk zamanlar\u0131nda, da\u011f\u0131t\u0131k systemd unit y\u00f6netimi i\u00e7in yenilik\u00e7i ve g\u00fc\u00e7l\u00fc bir \u00e7\u00f6z\u00fcm sunmu\u015ftur. CoreOS’un etcd ve systemd gibi temel bile\u015fenlerini kullanarak, geli\u015ftiricilerin ve sistem y\u00f6neticilerinin Docker konteynerlerini bir k\u00fcme genelinde tutarl\u0131 ve g\u00fcvenilir bir \u015fekilde da\u011f\u0131tmas\u0131na ve y\u00f6netmesine olanak tan\u0131m\u0131\u015ft\u0131r. Servis yerle\u015fim k\u0131s\u0131tlamalar\u0131, otomatik yeniden planlama ve unit ba\u011f\u0131ml\u0131l\u0131klar\u0131 gibi \u00f6zellikleri sayesinde, Fleet, da\u011f\u0131t\u0131k servis y\u00f6netiminin temel zorluklar\u0131na etkili \u00e7\u00f6z\u00fcmler getirmi\u015ftir.<\/p>\n Ancak, teknoloji d\u00fcnyas\u0131n\u0131n h\u0131zl\u0131 evrimiyle birlikte, Kubernetes gibi daha geli\u015fmi\u015f ve kapsaml\u0131 konteyner orkestrasyon platformlar\u0131 Fleet’in yerini alm\u0131\u015ft\u0131r. Fleet’in aktif geli\u015ftirilmesinin durdurulmu\u015f olmas\u0131 ve “deprecated” olarak kabul edilmesi, yeni projeler i\u00e7in alternatif \u00e7\u00f6z\u00fcmlere y\u00f6nelmenin gereklili\u011fini ortaya koymaktad\u0131r.<\/p>\n Yine de, Fleet’in \u00e7al\u0131\u015fma prensiplerini ve CoreOS ekosistemindeki rol\u00fcn\u00fc anlamak, da\u011f\u0131t\u0131k sistem mimarileri, servis orkestrasyonu ve konteyner y\u00f6netimi alan\u0131ndaki temel kavramlar\u0131 \u00f6\u011frenmek i\u00e7in hala de\u011ferli bir kaynakt\u0131r. Bu makale, Fleet ve fleetctl’in nas\u0131l kullan\u0131laca\u011f\u0131na dair kapsaml\u0131 bir rehber sunarak, bu eski ama \u00f6nemli teknolojinin anla\u015f\u0131lmas\u0131na katk\u0131da bulunmay\u0131 ama\u00e7lam\u0131\u015ft\u0131r. Modern konteyner orkestrasyonuna ge\u00e7i\u015f yaparken, Fleet’in sundu\u011fu dersler ve CoreOS’un felsefesi, daha iyi ve daha dayan\u0131kl\u0131 da\u011f\u0131t\u0131k sistemler tasarlamak i\u00e7in bir temel olu\u015fturabilir.
\n* Servis Yerle\u015fimi:<\/strong> Hangi servisin hangi sunucuda \u00e7al\u0131\u015faca\u011f\u0131 nas\u0131l belirlenir? Kaynak kullan\u0131m\u0131, performans ve g\u00fcvenlik gereksinimleri nas\u0131l dikkate al\u0131n\u0131r?
\n* Y\u00fcksek Eri\u015filebilirlik:<\/strong> Bir sunucu ar\u0131zaland\u0131\u011f\u0131nda, o sunucudaki servisler otomatik olarak ba\u015fka bir sunucuya nas\u0131l ta\u015f\u0131n\u0131r veya yeniden ba\u015flat\u0131l\u0131r?
\n* \u00d6l\u00e7eklenebilirlik:<\/strong> Servislere olan talep artt\u0131\u011f\u0131nda, yeni \u00f6rnekler otomatik olarak nas\u0131l ba\u015flat\u0131l\u0131r ve k\u00fcme genelinde nas\u0131l da\u011f\u0131t\u0131l\u0131r?
\n* Yap\u0131land\u0131rma Y\u00f6netimi:<\/strong> Servislerin yap\u0131land\u0131rma bilgileri (portlar, IP adresleri, ba\u011f\u0131ml\u0131l\u0131klar) k\u00fcme genelinde nas\u0131l tutarl\u0131 bir \u015fekilde y\u00f6netilir ve g\u00fcncellenir?
\n* Servis Ke\u015ffi:<\/strong> Bir servis, di\u011fer servislerin nerede \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 nas\u0131l \u00f6\u011frenir ve onlarla nas\u0131l ileti\u015fim kurar?<\/p>\nFleet’in Sa\u011flad\u0131\u011f\u0131 \u00c7\u00f6z\u00fcmler<\/h3>\n
\n* K\u00fcresel Servis G\u00f6r\u00fcn\u00fcm\u00fc:<\/strong> T\u00fcm k\u00fcme genelindeki \u00e7al\u0131\u015fan servislerin ve d\u00fc\u011f\u00fcmlerin merkezi bir g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc sa\u011flar.
\n* Servis Yerle\u015fim K\u0131s\u0131tlamalar\u0131:<\/strong> Geli\u015fmi\u015f unit dosyas\u0131 se\u00e7enekleri arac\u0131l\u0131\u011f\u0131yla, servislerin belirli \u00f6zelliklere sahip d\u00fc\u011f\u00fcmlerde (\u00f6rne\u011fin, belirli bir donan\u0131m etiketine sahip d\u00fc\u011f\u00fcmler) \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayabilir veya belirli servislerin ayn\u0131 d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015fmas\u0131n\u0131 engelleyebilirsiniz.
\n* Otomatik Yeniden Planlama:<\/strong> Bir d\u00fc\u011f\u00fcm ar\u0131zaland\u0131\u011f\u0131nda, Fleet o d\u00fc\u011f\u00fcmdeki ba\u015far\u0131s\u0131z olan servisleri otomatik olarak k\u00fcmedeki ba\u015fka uygun bir d\u00fc\u011f\u00fcme ta\u015f\u0131yarak y\u00fcksek eri\u015filebilirlik sa\u011flamaya \u00e7al\u0131\u015f\u0131r.
\n* Basitle\u015ftirilmi\u015f Da\u011f\u0131t\u0131m:<\/strong> Geli\u015ftiricilerin, servislerini da\u011f\u0131tmak i\u00e7in tek tek d\u00fc\u011f\u00fcmlerle u\u011fra\u015fmak yerine, fleetctl arac\u0131l\u0131\u011f\u0131yla k\u00fcme genelinde tek bir komutla da\u011f\u0131t\u0131m yapmas\u0131n\u0131 sa\u011flar.<\/p>\nFleet Mimarisi ve \u00c7al\u0131\u015fma Prensibi<\/h2>\n
Bile\u015fenler<\/h3>\n
\n* fleetd<\/code> Agent:<\/strong> Her CoreOS d\u00fc\u011f\u00fcm\u00fcnde \u00e7al\u0131\u015fan bir Fleet ajan\u0131d\u0131r. Bu ajan, etcd’yi izler, etcd’deki servis durumu de\u011fi\u015fikliklerini alg\u0131lar ve yerel systemd ile etkile\u015fime girerek servisleri ba\u015flat\u0131r, durdurur veya yeniden ba\u015flat\u0131r. Ayr\u0131ca, d\u00fc\u011f\u00fcm\u00fcn kendi durumunu (\u00f6rne\u011fin, mevcut kaynaklar\u0131, meta verileri) etcd’ye yazar.
\n* etcd:<\/strong> Daha \u00f6nce bahsedildi\u011fi gibi, etcd Fleet’in omurgas\u0131d\u0131r. T\u00fcm servis unit dosyalar\u0131, servislerin mevcut durumlar\u0131, beklenen durumlar\u0131, d\u00fc\u011f\u00fcm meta verileri ve Fleet’in dahili durum bilgileri etcd’de saklan\u0131r. Fleetd ajanlar\u0131 ve fleetctl istemcisi etcd \u00fczerinden ileti\u015fim kurar.
\n* fleetctl<\/code> \u0130stemci:<\/strong> Kullan\u0131c\u0131lar\u0131n Fleet k\u00fcmesiyle etkile\u015fim kurmas\u0131n\u0131 sa\u011flayan komut sat\u0131r\u0131 aray\u00fcz\u00fcd\u00fcr. fleetctl<\/code>, etcd’ye do\u011frudan veya bir fleetd<\/code> ajan\u0131 arac\u0131l\u0131\u011f\u0131yla ba\u011flanarak servisleri g\u00f6nderme, ba\u015flatma, durdurma, silme ve k\u00fcme durumunu sorgulama gibi i\u015flemleri ger\u00e7ekle\u015ftirir.<\/p>\nNas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
\n1. Unit G\u00f6nderimi:<\/strong> Bir kullan\u0131c\u0131 fleetctl submit my-service.service<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131nda, fleetctl<\/code> bu unit dosyas\u0131n\u0131 etcd’ye yazar. Unit dosyas\u0131 etcd’de “bekleyen” (pending) bir durumla i\u015faretlenir.
\n2. Planlama:<\/strong> fleetd<\/code> ajanlar\u0131, etcd’deki de\u011fi\u015fiklikleri s\u00fcrekli olarak izler. Yeni bir unit dosyas\u0131 etcd’ye yaz\u0131ld\u0131\u011f\u0131nda, bir fleetd<\/code> ajan\u0131 (veya i\u00e7indeki bir planlay\u0131c\u0131 bile\u015feni), bu unit dosyas\u0131n\u0131 hangi d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015ft\u0131rmas\u0131 gerekti\u011fine karar verir. Bu karar, unit dosyas\u0131ndaki X-Fleet<\/code> direktifleri (yerle\u015fim k\u0131s\u0131tlamalar\u0131) ve d\u00fc\u011f\u00fcmlerin mevcut durumu (kaynaklar, meta veriler) dikkate al\u0131narak verilir.
\n3. Ba\u015flatma:<\/strong> Karar verilen d\u00fc\u011f\u00fcmdeki fleetd<\/code> ajan\u0131, etcd’den ilgili unit dosyas\u0131n\u0131 al\u0131r ve yerel systemd’yi kullanarak servisi ba\u015flat\u0131r (systemctl start my-service.service<\/code>).
\n4. Durum G\u00fcncellemesi:<\/strong> Servis ba\u015flat\u0131ld\u0131ktan sonra, fleetd<\/code> ajan\u0131 servisin durumunu (\u00e7al\u0131\u015f\u0131yor, durdu, ba\u015far\u0131s\u0131z oldu vb.) etcd’ye geri yazar. Bu durum, fleetctl list-units<\/code> gibi komutlarla sorgulanabilir.
\n5. Hata Durumunda Yeniden Planlama:<\/strong> E\u011fer bir d\u00fc\u011f\u00fcm ar\u0131zalan\u0131rsa veya bir servis beklenmedik bir \u015fekilde durursa, etcd’deki durum bilgisi g\u00fcncellenir. fleetd<\/code> ajanlar\u0131 bu de\u011fi\u015fikli\u011fi alg\u0131lar ve ar\u0131zal\u0131 servisi k\u00fcmedeki ba\u015fka uygun bir d\u00fc\u011f\u00fcme otomatik olarak yeniden planlamaya \u00e7al\u0131\u015f\u0131r. Bu, Fleet’in temel y\u00fcksek eri\u015filebilirlik \u00f6zelliklerinden biridir.<\/p>\nFleetctl Kullan\u0131m\u0131: Temel Komutlar ve \u0130\u015flemler<\/h2>\n
fleetctl<\/code>, Fleet k\u00fcmesiyle etkile\u015fim kurmak i\u00e7in kullan\u0131lan ana komut sat\u0131r\u0131 arac\u0131d\u0131r. Bu b\u00f6l\u00fcmde fleetctl<\/code>‘in kurulumu, k\u00fcme ba\u011flant\u0131s\u0131 ve temel servis y\u00f6netimi komutlar\u0131 ele al\u0131nacakt\u0131r.<\/p>\nKurulum ve Ba\u011flant\u0131<\/h3>\n
fleetctl<\/code> genellikle \u00f6nceden y\u00fckl\u00fc olarak gelir. E\u011fer y\u00fckl\u00fc de\u011filse, CoreOS dok\u00fcmantasyonundan veya Fleet GitHub sayfas\u0131ndan indirilebilir. fleetctl<\/code>‘in k\u00fcme ile ileti\u015fim kurabilmesi i\u00e7in etcd’ye eri\u015fmesi gerekir. Bu genellikle iki yolla yap\u0131l\u0131r:
\n* SSH T\u00fcnelleme (\u00d6nerilen):<\/strong> En g\u00fcvenli ve yayg\u0131n y\u00f6ntemdir. fleetctl<\/code>, k\u00fcmedeki bir CoreOS d\u00fc\u011f\u00fcm\u00fcne SSH t\u00fcneli kurarak etcd’ye eri\u015fir.<\/p>\nexport FLEETCTL_TUNNEL=coreos-node-ip:22\n fleetctl list-machines<\/code><\/pre>\ncoreos-node-ip<\/code> adresindeki CoreOS d\u00fc\u011f\u00fcm\u00fcne SSH \u00fczerinden ba\u011flan\u0131r ve etcd’ye eri\u015fmek i\u00e7in bir t\u00fcnel olu\u015fturur.
\n* Do\u011frudan etcd U\u00e7 Noktas\u0131:<\/strong> Daha az g\u00fcvenli olmakla birlikte, etcd u\u00e7 noktalar\u0131n\u0131n do\u011frudan eri\u015filebilir oldu\u011fu durumlarda kullan\u0131labilir.<\/p>\nexport FLEETCTL_ENDPOINT=http:\/\/etcd-cluster-ip:2379\n fleetctl list-machines<\/code><\/pre>\nK\u00fcme Durumunu G\u00f6r\u00fcnt\u00fcleme<\/h3>\n
\n* fleetctl list-machines<\/code>:<\/strong> K\u00fcmedeki t\u00fcm CoreOS d\u00fc\u011f\u00fcmlerini listeler. Her d\u00fc\u011f\u00fcm\u00fcn ID’si, IP adresi, durum bilgisi ve varsa meta verileri g\u00f6sterilir.<\/p>\nfleetctl list-machines<\/code><\/pre>\nMACHINE IP METADATA STATE\n 4a1b2c3d... 192.168.1.101 role=web up\n 5b2c3d4e... 192.168.1.102 role=db up<\/code><\/pre>\nfleetctl list-units<\/code>:<\/strong> K\u00fcme genelinde Fleet taraf\u0131ndan y\u00f6netilen t\u00fcm unit dosyalar\u0131n\u0131 listeler. Hangi unit’in hangi makinede \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, durumunu ve istenen durumunu g\u00f6sterir.<\/p>\nfleetctl list-units<\/code><\/pre>\nUNIT MACHINE ACTIVE SUB\n my-app.service 4a1b2c3d...\/192.168.1.101 active running\n nginx.service 5b2c3d4e...\/192.168.1.102 active running<\/code><\/pre>\nfleetctl status fleetctl status my-app.service<\/code><\/pre>\nfleetctl journal fleetctl journal my-app.service<\/code><\/pre>\nUnit Dosyalar\u0131 Olu\u015fturma<\/h3>\n
[X-Fleet]<\/code> b\u00f6l\u00fcm\u00fcnde \u00f6zel direktifler de ekleyebilirsiniz. Bir \u00f6rnek Nginx servis unit dosyas\u0131:<\/p>\n# nginx.service\n[Unit]\nDescription=Nginx Web Server\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nTimeoutStartSec=0\nExecStartPre=-\/usr\/bin\/docker kill nginx\nExecStartPre=-\/usr\/bin\/docker rm nginx\nExecStartPre=\/usr\/bin\/docker pull nginx:latest\nExecStart=\/usr\/bin\/docker run --name nginx -p 80:80 nginx:latest\nExecStop=\/usr\/bin\/docker stop nginx\nExecStopPost=\/usr\/bin\/docker rm nginx\n\n[Install]\nWantedBy=multi-user.target\n\n[X-Fleet]\nBu servisin k\u00fcme genelinde tek bir \u00f6rnek olarak \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar<\/h2>\n
X-Fleet-Global=true # E\u011fer her d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015fmas\u0131n\u0131 isteseydik<\/h2>\nConflicts=nginx.service # Ayn\u0131 isimde ba\u015fka bir nginx servisiyle \u00e7ak\u0131\u015fmas\u0131n\u0131 engeller<\/code><\/pre>\n
\n* [Unit]<\/code> b\u00f6l\u00fcm\u00fc, servisin tan\u0131m\u0131n\u0131 ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 i\u00e7erir. After=docker.service<\/code> ve Requires=docker.service<\/code> Docker’\u0131n \u00e7al\u0131\u015f\u0131r durumda olmas\u0131n\u0131 sa\u011flar.
\n* [Service]<\/code> b\u00f6l\u00fcm\u00fc, servisin nas\u0131l ba\u015flat\u0131laca\u011f\u0131n\u0131 (ExecStart<\/code>), durdurulaca\u011f\u0131n\u0131 (ExecStop<\/code>) ve \u00f6n\/son ad\u0131mlar\u0131 (ExecStartPre<\/code>, ExecStopPost<\/code>) tan\u0131mlar. Docker konteynerlerini y\u00f6netmek i\u00e7in Docker komutlar\u0131 kullan\u0131l\u0131r.
\n* [Install]<\/code> b\u00f6l\u00fcm\u00fc, servisin systemd taraf\u0131ndan nas\u0131l etkinle\u015ftirilece\u011fini belirtir.
\n* [X-Fleet]<\/code> b\u00f6l\u00fcm\u00fc, Fleet’e \u00f6zel talimatlar i\u00e7erir. Conflicts=nginx.service<\/code> direktifi, k\u00fcmede yaln\u0131zca bir tane nginx.service<\/code> \u00f6rne\u011finin \u00e7al\u0131\u015fmas\u0131n\u0131 garanti eder.<\/p>\nUnitleri Y\u00fckleme ve Ba\u015flatma<\/h3>\n
\n1. Unit Dosyas\u0131n\u0131 G\u00f6nderme (Submit):<\/strong> Unit dosyas\u0131n\u0131 etcd’ye kaydeder, ancak hen\u00fcz ba\u015flatmaz.<\/p>\nfleetctl submit nginx.service<\/code><\/pre>\nfleetctl start nginx.service<\/code><\/pre>\nfleetctl load nginx.service<\/code> (y\u00fckler ve ba\u015flat\u0131r) veya fleetctl start nginx.service<\/code> (e\u011fer zaten submit edilmi\u015fse).
\n3. Durumu Kontrol Etme:<\/strong> Servisin ba\u015far\u0131yla ba\u015flat\u0131l\u0131p ba\u015flat\u0131lmad\u0131\u011f\u0131n\u0131 kontrol edin.<\/p>\nfleetctl list-units\n fleetctl status nginx.service<\/code><\/pre>\nUnitleri Durdurma ve Kald\u0131rma<\/h3>\n
\n* Unit’i Durdurma (Stop):<\/strong> Servisi \u00e7al\u0131\u015ft\u0131ran d\u00fc\u011f\u00fcmdeki yerel systemd’ye durdurma sinyali g\u00f6nderir. Unit dosyas\u0131 etcd’de kal\u0131r.<\/p>\nfleetctl stop nginx.service<\/code><\/pre>\nfleetctl destroy nginx.service<\/code><\/pre>\nUnitlerin G\u00fcncellenmesi<\/h3>\n
\n1. Mevcut Servisi Durdur ve Kald\u0131r:<\/strong><\/p>\nfleetctl stop my-app.service\n fleetctl destroy my-app.service<\/code><\/pre>\nfleetctl submit my-app.service\n fleetctl start my-app.service<\/code><\/pre>\nGeli\u015fmi\u015f Fleet Kullan\u0131m\u0131 ve Stratejiler<\/h2>\n
Unit Ba\u011flant\u0131lar\u0131 ve Ba\u011f\u0131ml\u0131l\u0131klar<\/h3>\n
\n* Requires=<\/code>:<\/strong> Bu unit’in ba\u015flamas\u0131 i\u00e7in belirtilen unit’in ba\u015far\u0131l\u0131 bir \u015fekilde ba\u015flamas\u0131 gerekti\u011fini belirtir. E\u011fer ba\u011f\u0131ml\u0131 unit ba\u015far\u0131s\u0131z olursa, bu unit de ba\u015flat\u0131lamaz.
\n* After=<\/code>:<\/strong> Bu unit’in, belirtilen unit ba\u015flad\u0131ktan sonra ba\u015flat\u0131lmas\u0131 gerekti\u011fini belirtir. Ba\u011f\u0131ml\u0131 unit’in ba\u015far\u0131s\u0131z olmas\u0131 bu unit’in ba\u015flamas\u0131n\u0131 engellemez, sadece s\u0131ras\u0131n\u0131 belirler.
\n* BindsTo=<\/code>:<\/strong> Requires<\/code> gibidir, ancak ba\u011f\u0131ml\u0131 unit durduruldu\u011funda bu unit’in de durdurulmas\u0131n\u0131 sa\u011flar.<\/p>\n# my-app.service\n[Unit]\nDescription=My Web Application\nAfter=docker.service my-db.service\nRequires=docker.service my-db.service\n...<\/code><\/pre>\nmy-app.service<\/code>‘in ba\u015flamas\u0131 i\u00e7in docker.service<\/code> ve my-db.service<\/code>‘in aktif olmas\u0131 gerekti\u011fini belirtir.<\/p>\nServis Yerle\u015fim K\u0131s\u0131tlamalar\u0131<\/h3>\n
[X-Fleet]<\/code> b\u00f6l\u00fcm\u00fcndeki \u00f6zel direktiflerle yap\u0131l\u0131r.
\n* X-Fleet-MachineMetadata=# web-server.service\n [X-Fleet]\n MachineMetadata=role=web<\/code><\/pre>\nfleetctl start --metadata role=web<\/code> (bu komut fleetctl<\/code>‘in eski s\u00fcr\u00fcmlerinde \u00e7al\u0131\u015f\u0131yordu, yeni s\u00fcr\u00fcmler i\u00e7in fleetctl set-machine-metadata<\/code> kullanmak veya cloud-config<\/code> ile d\u00fc\u011f\u00fcm ba\u015flat\u0131rken belirtmek daha yayg\u0131nd\u0131r).
\n* X-Fleet-Conflicts=# my-app@.service (template unit)\n [X-Fleet]\n Conflicts=my-app@*.service<\/code><\/pre>\nmy-app@1.service<\/code> ve my-app@2.service<\/code> gibi farkl\u0131 \u00f6rneklerin ayn\u0131 d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015fmamas\u0131n\u0131 sa\u011flar.
\n X-Fleet-Global=true<\/code>:<\/strong> Bu direktif, servisin k\u00fcmedeki <\/em>her* d\u00fc\u011f\u00fcmde otomatik olarak ba\u015flat\u0131lmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir log toplama ajan\u0131 veya bir izleme arac\u0131 gibi servisler i\u00e7in idealdir.<\/p>\n# fluentd.service\n [X-Fleet]\n Global=true<\/code><\/pre>\nY\u00fcksek Eri\u015filebilirlik ve \u00d6l\u00e7eklenebilirlik<\/h3>\n
\n* Birden Fazla \u00d6rnek \u00c7al\u0131\u015ft\u0131rma:<\/strong> Bir servisin birden fazla \u00f6rne\u011fini (\u00f6rne\u011fin, my-app@1.service<\/code>, my-app@2.service<\/code>) ba\u015flatarak y\u00fck\u00fc da\u011f\u0131tabilir ve bir \u00f6rnek ba\u015far\u0131s\u0131z oldu\u011funda di\u011ferlerinin \u00e7al\u0131\u015fmaya devam etmesini sa\u011flayabilirsiniz. Conflicts<\/code> direktifi ile bu \u00f6rneklerin farkl\u0131 d\u00fc\u011f\u00fcmlere da\u011f\u0131t\u0131lmas\u0131n\u0131 garanti edebilirsiniz.
\n* Otomatik Yeniden Planlama:<\/strong> Bir d\u00fc\u011f\u00fcm ar\u0131zaland\u0131\u011f\u0131nda veya bir servis durdu\u011funda, Fleet otomatik olarak ba\u015far\u0131s\u0131z olan unit’i ba\u015fka uygun bir d\u00fc\u011f\u00fcme ta\u015f\u0131maya \u00e7al\u0131\u015f\u0131r. Bu, temel bir kendini iyile\u015ftirme mekanizmas\u0131d\u0131r.<\/p>\nDa\u011f\u0131t\u0131k Uygulama Kal\u0131plar\u0131<\/h3>\n
\n* Sidekick Pattern:<\/strong> Bir ana uygulaman\u0131n yan\u0131nda \u00e7al\u0131\u015fan yard\u0131mc\u0131 servisler (sidekick’ler) i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131n yan\u0131nda bir registrator<\/code> konteyneri \u00e7al\u0131\u015ft\u0131rarak servis ke\u015ffini otomatikle\u015ftirebilirsiniz. registrator<\/code>, Docker konteynerlerini izler ve yeni konteynerleri etcd’ye kaydeder.
\n* Servis Ke\u015ffi:<\/strong> Fleet’in kendisi do\u011frudan bir servis ke\u015fif sistemi de\u011fildir, ancak etcd’yi kullanarak servis ke\u015ffi yapmay\u0131 kolayla\u015ft\u0131r\u0131r. registrator<\/code> gibi ara\u00e7lar, \u00e7al\u0131\u015fan konteynerlerin IP adreslerini ve portlar\u0131n\u0131 etcd’ye kaydedebilir ve confd<\/code> gibi ara\u00e7lar bu bilgiyi kullanarak yap\u0131land\u0131rma dosyalar\u0131n\u0131 (\u00f6rne\u011fin, Nginx proxy yap\u0131land\u0131rmas\u0131) dinamik olarak g\u00fcncelleyebilir.<\/p>\nFleet ve Di\u011fer Ara\u00e7lar<\/h3>\n
Pratik Bir \u00d6rnek: Basit Bir Web Uygulamas\u0131 Da\u011f\u0131t\u0131m\u0131<\/h2>\n
Senaryo Tan\u0131m\u0131<\/h3>\n
\n* Nginx Web Sunucusu:<\/strong> Gelen istekleri dinleyecek ve statik i\u00e7erik sunacak veya di\u011fer servislere proxy yapacak.
\n* Python Flask Uygulamas\u0131:<\/strong> Basit bir dinamik web uygulamas\u0131 (\u00f6rne\u011fin, “Hello, CoreOS!” mesaj\u0131n\u0131 d\u00f6nd\u00fcren bir Flask uygulamas\u0131).<\/p>\nNginx Unit Dosyas\u0131 (nginx.service)<\/h3>\n
# \/etc\/systemd\/system\/nginx.service\n[Unit]\nDescription=Nginx Web Server\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nTimeoutStartSec=0\nExecStartPre=-\/usr\/bin\/docker kill nginx-proxy\nExecStartPre=-\/usr\/bin\/docker rm nginx-proxy\nExecStartPre=\/usr\/bin\/docker pull nginx:latest\nExecStart=\/usr\/bin\/docker run --name nginx-proxy -p 80:80 -d nginx:latest\nExecStop=\/usr\/bin\/docker stop nginx-proxy\nExecStopPost=\/usr\/bin\/docker rm nginx-proxy\nRestart=on-failure\nRestartSec=10\n\n[Install]\nWantedBy=multi-user.target\n\n[X-Fleet]\nNginx'in k\u00fcmede tek bir yerde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayal\u0131m<\/h2>\nConflicts=nginx.service<\/code><\/pre>\n
nginx-proxy<\/code> ad\u0131yla ba\u015flat\u0131r ve host’un 80 portunu konteynerin 80 portuna e\u015fler. Conflicts=nginx.service<\/code> ile k\u00fcmede sadece bir Nginx \u00f6rne\u011finin \u00e7al\u0131\u015fmas\u0131n\u0131 garanti ederiz.<\/p>\nFlask Uygulamas\u0131 Unit Dosyas\u0131 (flask-app.service)<\/h3>\n
# Dockerfile\nFROM python:3.9-slim-buster\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install -r requirements.txt\nCOPY app.py .\nEXPOSE 5000\nCMD [\"python\", \"app.py\"]<\/code><\/pre>\napp.py<\/code> i\u00e7eri\u011fi:<\/p>\n# app.py\nfrom flask import Flask\napp = Flask(__name__)\n\n@app.route('\/')\ndef hello():\n return \"Hello from Flask on CoreOS!\"\n\nif __name__ == '__main__':\n app.run(host='0.0.0.0', port=5000)<\/code><\/pre>\napp.py<\/code> ile bir Docker imaj\u0131 olu\u015fturup bir Docker kay\u0131t defterine (\u00f6rne\u011fin Docker Hub) g\u00f6ndermeniz gerekir. \u00d6rne\u011fin, yourusername\/flask-app:latest<\/code>.<\/p>\n# \/etc\/systemd\/system\/flask-app.service\n[Unit]\nDescription=Flask Web Application\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nTimeoutStartSec=0\nExecStartPre=-\/usr\/bin\/docker kill flask-web-app\nExecStartPre=-\/usr\/bin\/docker rm flask-web-app\nExecStartPre=\/usr\/bin\/docker pull yourusername\/flask-app:latest\nExecStart=\/usr\/bin\/docker run --name flask-web-app -p 5000:5000 -d yourusername\/flask-app:latest\nExecStop=\/usr\/bin\/docker stop flask-web-app\nExecStopPost=\/usr\/bin\/docker rm flask-web-app\nRestart=on-failure\nRestartSec=10\n\n[Install]\nWantedBy=multi-user.target\n\n[X-Fleet]\nFlask uygulamas\u0131n\u0131n da k\u00fcmede tek bir yerde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayal\u0131m<\/h2>\nConflicts=flask-app.service<\/code><\/pre>\n
flask-web-app<\/code> ad\u0131yla ba\u015flat\u0131r ve host’un 5000 portunu konteynerin 5000 portuna e\u015fler.<\/p>\nDa\u011f\u0131t\u0131m Ad\u0131mlar\u0131<\/h3>\n
nginx.service<\/code> ve flask-app.service<\/code> dosyalar\u0131n\u0131 yerel makinenizde olu\u015fturun.
\n2. Unitleri G\u00f6nderin ve Ba\u015flat\u0131n:<\/strong><\/p>\nfleetctl submit nginx.service\n fleetctl start nginx.service\n\n fleetctl submit flask-app.service\n fleetctl start flask-app.service<\/code><\/pre>\nfleetctl list-units\n fleetctl status nginx.service\n fleetctl status flask-app.service<\/code><\/pre>\nlist-units<\/code> \u00e7\u0131kt\u0131s\u0131nda, her iki servisin de active<\/code> ve running<\/code> durumda oldu\u011funu ve farkl\u0131 veya ayn\u0131 d\u00fc\u011f\u00fcmlerde (e\u011fer Conflicts<\/code> k\u0131s\u0131tlamas\u0131 farkl\u0131 bir d\u00fc\u011f\u00fcme yerle\u015fimi zorlam\u0131yorsa) \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6rmelisiniz.
\n4. Uygulamay\u0131 Test Edin:<\/strong>
\n Nginx’in \u00e7al\u0131\u015ft\u0131\u011f\u0131 d\u00fc\u011f\u00fcm\u00fcn IP adresini (fleetctl list-machines<\/code> \u00e7\u0131kt\u0131s\u0131ndan al\u0131n) kullanarak taray\u0131c\u0131n\u0131zdan bu IP adresine gidin. Nginx’in varsay\u0131lan kar\u015f\u0131lama sayfas\u0131n\u0131 veya yap\u0131land\u0131rd\u0131\u011f\u0131n\u0131z statik i\u00e7eri\u011fi g\u00f6rmelisiniz.
\n Flask uygulamas\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 d\u00fc\u011f\u00fcm\u00fcn IP adresini ve 5000 portunu kullanarak (\u00f6rn: http:\/\/flask-app-ip:5000<\/code>) Flask uygulaman\u0131za eri\u015fin. “Hello from Flask on CoreOS!” mesaj\u0131n\u0131 g\u00f6rmelisiniz.<\/p>\nmy-app@.service<\/code>) kullanmak gibi ad\u0131mlar eklenebilir.<\/p>\nG\u00fcvenlik ve En \u0130yi Uygulamalar<\/h2>\n
fleetctl Eri\u015fimi G\u00fcvenli\u011fi<\/h3>\n
FLEETCTL_TUNNEL<\/code> kullanarak SSH t\u00fcneli \u00fczerinden etcd’ye ba\u011flanmak, etcd u\u00e7 noktas\u0131n\u0131 internete a\u00e7\u0131k b\u0131rakmaktan \u00e7ok daha g\u00fcvenlidir. SSH anahtarlar\u0131n\u0131z\u0131n g\u00fcvenli\u011fini sa\u011flay\u0131n.
\n* etcd Eri\u015fimi K\u0131s\u0131tlamalar\u0131:<\/strong> etcd k\u00fcmenizin d\u0131\u015far\u0131dan eri\u015fime kapal\u0131 oldu\u011fundan ve yaln\u0131zca g\u00fcvenilir istemcilerin eri\u015febildi\u011finden emin olun. TLS\/SSL kullanarak etcd ileti\u015fimini \u015fifreleyin ve istemci kimlik do\u011frulamas\u0131n\u0131 etkinle\u015ftirin.
\n* Eri\u015fim Kontrol\u00fc:<\/strong> fleetctl<\/code> komutlar\u0131na eri\u015fimi, yetkili kullan\u0131c\u0131larla s\u0131n\u0131rlay\u0131n.<\/p>\nUnit Dosyalar\u0131 G\u00fcvenli\u011fi<\/h3>\n
privileged<\/code> Docker konteynerlerinden ka\u00e7\u0131n\u0131n. Bir konteynere gereksiz ayr\u0131cal\u0131klar vermek, g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7abilir.
\n* S\u0131n\u0131rl\u0131 Kaynak Kullan\u0131m\u0131:<\/strong> Unit dosyalar\u0131nda Docker’\u0131n --memory<\/code>, --cpu-shares<\/code> gibi se\u00e7eneklerini kullanarak konteynerlerin kaynak kullan\u0131m\u0131n\u0131 s\u0131n\u0131rlay\u0131n. Bu, bir konteynerin t\u00fcm d\u00fc\u011f\u00fcm kaynaklar\u0131n\u0131 t\u00fcketmesini \u00f6nler.
\n* En Az Yetki Prensibi:<\/strong> Konteynerler i\u00e7inde \u00e7al\u0131\u015fan uygulamalar\u0131n yaln\u0131zca ihtiya\u00e7 duyduklar\u0131 izinlere sahip oldu\u011fundan emin olun.
\n* G\u00fcvenilir \u0130majlar Kullan\u0131n:<\/strong> Docker imajlar\u0131n\u0131 g\u00fcvenilir kaynaklardan (\u00f6rne\u011fin, Docker Hub’daki resmi imajlar veya kendi g\u00fcvenli kay\u0131t defterinizdeki imajlar) \u00e7ekin.<\/p>\nBak\u0131m ve \u0130zleme<\/h3>\n
fleetctl journal
\n* Metrik Toplama:<\/strong> K\u00fcme d\u00fc\u011f\u00fcmlerinin ve \u00e7al\u0131\u015fan servislerin performans metriklerini (CPU, bellek, disk, a\u011f kullan\u0131m\u0131) izleyin. Prometheus, Grafana gibi ara\u00e7lar bu konuda yard\u0131mc\u0131 olabilir.
\n* Otomatik G\u00fcncellemeler:<\/strong> CoreOS’un otomatik g\u00fcncelleme mekanizmas\u0131ndan faydalan\u0131n. Ancak, g\u00fcncellemelerin uygulaman\u0131z \u00fczerindeki etkilerini test etmek i\u00e7in bir haz\u0131rl\u0131k ortam\u0131 kullan\u0131n.<\/p>\nFleet’in Gelece\u011fi ve Alternatifler<\/h2>\n
Fleet’in Durumu<\/h3>\n
Modern Alternatifler<\/h3>\n
\n* Kubernetes:<\/strong> A\u00e7\u0131k ara en pop\u00fcler ve kapsaml\u0131 konteyner orkestrasyon platformudur. Da\u011f\u0131t\u0131k sistemlerin t\u00fcm y\u00f6nlerini (servis ke\u015ffi, y\u00fck dengeleme, otomatik \u00f6l\u00e7ekleme, depolama y\u00f6netimi, yap\u0131land\u0131rma y\u00f6netimi vb.) y\u00f6netmek i\u00e7in zengin bir API ve ekosistem sunar. CoreOS da art\u0131k Kubernetes’e odaklanm\u0131\u015ft\u0131r.
\n* Docker Swarm:<\/strong> Docker’\u0131n kendi yerle\u015fik orkestrasyon arac\u0131d\u0131r. Kubernetes’e g\u00f6re daha basit bir yap\u0131ya sahiptir ve Docker Compose ile iyi entegre olur. Daha k\u00fc\u00e7\u00fck \u00f6l\u00e7ekli da\u011f\u0131t\u0131mlar i\u00e7in iyi bir se\u00e7enek olabilir.
\n* Nomad:<\/strong> HashiCorp taraf\u0131ndan geli\u015ftirilen, genel ama\u00e7l\u0131 bir i\u015f zamanlay\u0131c\u0131s\u0131d\u0131r. Konteynerlerin yan\u0131 s\u0131ra, sanal makineleri ve di\u011fer i\u015f y\u00fcklerini de orkestra edebilir. Esnekli\u011fi ve basitli\u011fi ile \u00f6ne \u00e7\u0131kar.<\/p>\nSonu\u00e7<\/h2>\n
\n<\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Fleet ve Fleetctl Kullanarak CoreOS K\u00fcmenizi Y\u00f6netme Rehberi\nGiri\u015f\nModern bulut tabanl\u0131 uygulamalar\u0131n ve mikroservis mimarilerinin y\u00fckseli\u015fiy","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":[1],"tags":[],"class_list":{"0":"post-37854","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n