Fleet ve Fleetctl Kullanarak CoreOS Kümenizi Yönetme Rehberi

Fleet ve Fleetctl Kullanarak CoreOS Kümenizi Yönetme Rehberi

Giriş

Modern bulut tabanlı uygulamaların ve mikroservis mimarilerinin yükselişiyle birlikte, dağıtık sistemlerin yönetimi kritik bir hale gelmiştir. Bu bağlamda, CoreOS gibi hafif, kapsayıcı odaklı işletim sistemleri, küme yönetimini kolaylaştıran araçlarla birlikte öne çıkmıştır. CoreOS, temel olarak systemd, etcd ve Docker gibi bileşenler üzerine inşa edilmiş, otomatik güncellemeler ve güvenlik odaklı bir Linux dağıtımıdır. Ancak, bir CoreOS kümesindeki servisleri tüm düğümler arasında tutarlı ve ölçeklenebilir bir şekilde yönetmek için ek bir orkestrasyon katmanına ihtiyaç duyulur. İşte bu noktada Fleet ve onun komut satırı arayüzü olan fleetctl devreye girer.

Fleet, CoreOS’un ilk zamanlarında, dağıtık bir init sistemi olarak tasarlanmış, systemd unit dosyalarını bir küme genelinde çalıştırmanıza olanak tanıyan bir araçtı. Her ne kadar günümüzde Kubernetes gibi daha gelişmiş konteyner orkestrasyon platformları tarafından büyük ölçüde gölgede bırakılmış ve aktif geliştirilmesi durdurulmuş olsa da, Fleet’in çalışma prensiplerini ve CoreOS ekosistemindeki yerini anlamak, dağıtık sistem yönetimi ve konteyner orkestrasyonunun temel kavramlarını kavramak açısından hala değerli bir öğrenme deneyimi sunmaktadır. Bu makale, Fleet ve fleetctl’in CoreOS kümelerinde nasıl kullanıldığını, mimarisini, temel ve gelişmiş komutlarını, pratik örneklerini ve güncel durumu hakkında kapsamlı bir rehber sunmaktadır.

CoreOS, etcd ve systemd: Temeller

Fleet’in nasıl çalıştığını anlamak için CoreOS’un temel yapı taşlarını kavramak önemlidir. CoreOS, dağıtık sistemlerin ihtiyaçlarına özel olarak tasarlanmış bir işletim sistemidir ve etcd ile systemd gibi kilit teknolojileri bünyesinde barındırır.

CoreOS’un Mimarisi

CoreOS, “immutable infrastructure” (değişmez altyapı) felsefesiyle tasarlanmıştır. Bu, işletim sisteminin kendisinin değiştirilemez olduğu ve güncellemelerin atomik olarak tüm sistemin değiştirilmesiyle yapıldığı anlamına gelir. Uygulamalar ise Docker konteynerleri içinde çalıştırılır. Bu yaklaşım, sistem tutarlılığını ve güvenliğini artırırken, karmaşık bağımlılık sorunlarını da en aza indirir. CoreOS’un hafif yapısı ve konteyner odaklı yaklaşımı, onu dağıtık servisler için ideal bir platform haline getirir.

etcd: Dağıtık Yapılandırma Deposu

etcd, CoreOS’un kalbinde yer alan, dağıtık ve tutarlı bir anahtar-değer deposudur. Dağıtık sistemlerdeki yapılandırma verilerini, servis keşfi bilgilerini ve koordinasyon durumlarını güvenilir bir şekilde saklamak için kullanılır. etcd, Raft konsensüs algoritmasını kullanarak yüksek erişilebilirlik ve veri tutarlılığı sağlar. CoreOS kümelerindeki tüm düğümler, birbirleriyle ve diğer servislerle iletişim kurmak için etcd’yi kullanır. Fleet de servislerin durumunu ve yerleşim bilgilerini etcd üzerinde depolar ve bu sayede küme genelinde servislerin orkestrasyonunu mümkün kılar.

systemd: Servis Yöneticisi

systemd, Linux işletim sistemlerinde servisleri ve sistem kaynaklarını yönetmek için kullanılan bir init sistemidir. Birçok modern Linux dağıtımında varsayılan init sistemi olarak görev yapar. systemd, servisleri “unit” adı verilen yapılandırma dosyaları aracılığıyla tanımlar ve yönetir. Bu unit dosyaları, servislerin nasıl başlatılacağını, durdurulacağını, hangi bağımlılıklara sahip olduğunu ve hangi kaynakları kullanacağını belirler. CoreOS’ta her bir düğümde systemd çalışır ve yerel servisleri yönetir. Fleet ise bu yerel systemd’lerin üzerine inşa edilerek, unit dosyalarını bir küme genelinde dağıtık olarak yönetme yeteneği kazandırır.

Fleet Nedir ve Neden İhtiyaç Duyulur?

CoreOS’un temel bileşenleri olan etcd ve systemd, tek bir düğüm üzerindeki servis yönetiminde oldukça etkilidir. Ancak, birden fazla CoreOS düğümünden oluşan bir kümede, servislerin dağıtık olarak yönetilmesi, yük dengelemesi ve yüksek erişilebilirlik gibi zorluklar ortaya çıkar. İşte Fleet bu zorlukları aşmak için tasarlanmıştır.

Fleet’in Tanımı

Fleet, CoreOS kümeleri için tasarlanmış, dağıtık bir systemd olarak tanımlanabilir. Temel amacı, systemd unit dosyalarını alıp bunları bir CoreOS kümesindeki uygun düğümlere dağıtmak ve yönetmektir. Bir servisi bir düğümde başlatmak yerine, Fleet ile bir servisi küme genelinde başlatma talimatı verirsiniz ve Fleet, etcd’yi kullanarak bu servisi hangi düğümde çalıştıracağına karar verir ve o düğümdeki yerel systemd’yi kullanarak servisi başlatır. Bu sayede, geliştiriciler ve sistem yöneticileri, servislerini tek bir mantıksal birim olarak düşünebilir ve kümenin karmaşıklığıyla doğrudan uğraşmak zorunda kalmazlar.

Dağıtık Servis Yönetimi Zorlukları

Büyük ölçekli dağıtık sistemlerde servis yönetimi, çeşitli zorlukları beraberinde getirir:
* Servis Yerleşimi: Hangi servisin hangi sunucuda çalışacağı nasıl belirlenir? Kaynak kullanımı, performans ve güvenlik gereksinimleri nasıl dikkate alınır?
* Yüksek Erişilebilirlik: Bir sunucu arızalandığında, o sunucudaki servisler otomatik olarak başka bir sunucuya nasıl taşınır veya yeniden başlatılır?
* Ölçeklenebilirlik: Servislere olan talep arttığında, yeni örnekler otomatik olarak nasıl başlatılır ve küme genelinde nasıl dağıtılır?
* Yapılandırma Yönetimi: Servislerin yapılandırma bilgileri (portlar, IP adresleri, bağımlılıklar) küme genelinde nasıl tutarlı bir şekilde yönetilir ve güncellenir?
* Servis Keşfi: Bir servis, diğer servislerin nerede çalıştığını nasıl öğrenir ve onlarla nasıl iletişim kurar?

Fleet’in Sağladığı Çözümler

Fleet, bu zorluklara aşağıdaki gibi çözümler sunar:
* Küresel Servis Görünümü: Tüm küme genelindeki çalışan servislerin ve düğümlerin merkezi bir görünümünü sağlar.
* Servis Yerleşim Kısıtlamaları: Gelişmiş unit dosyası seçenekleri aracılığıyla, servislerin belirli özelliklere sahip düğümlerde (örneğin, belirli bir donanım etiketine sahip düğümler) çalışmasını sağlayabilir veya belirli servislerin aynı düğümde çalışmasını engelleyebilirsiniz.
* Otomatik Yeniden Planlama: Bir düğüm arızalandığında, Fleet o düğümdeki başarısız olan servisleri otomatik olarak kümedeki başka uygun bir düğüme taşıyarak yüksek erişilebilirlik sağlamaya çalışır.
* Basitleştirilmiş Dağıtım: Geliştiricilerin, servislerini dağıtmak için tek tek düğümlerle uğraşmak yerine, fleetctl aracılığıyla küme genelinde tek bir komutla dağıtım yapmasını sağlar.

Fleet Mimarisi ve Çalışma Prensibi

Fleet, etcd’yi temel alarak, CoreOS kümesindeki tüm düğümler arasında servislerin orkestrasyonunu sağlar. Mimarisini ve nasıl çalıştığını anlamak, Fleet’i etkin bir şekilde kullanmak için hayati öneme sahiptir.

Bileşenler

Fleet mimarisi temel olarak üç ana bileşenden oluşur:
* fleetd Agent: Her CoreOS düğümünde çalışan bir Fleet ajanıdır. Bu ajan, etcd’yi izler, etcd’deki servis durumu değişikliklerini algılar ve yerel systemd ile etkileşime girerek servisleri başlatır, durdurur veya yeniden başlatır. Ayrıca, düğümün kendi durumunu (örneğin, mevcut kaynakları, meta verileri) etcd’ye yazar.
* etcd: Daha önce bahsedildiği gibi, etcd Fleet’in omurgasıdır. Tüm servis unit dosyaları, servislerin mevcut durumları, beklenen durumları, düğüm meta verileri ve Fleet’in dahili durum bilgileri etcd’de saklanır. Fleetd ajanları ve fleetctl istemcisi etcd üzerinden iletişim kurar.
* fleetctl İstemci: Kullanıcıların Fleet kümesiyle etkileşim kurmasını sağlayan komut satırı arayüzüdür. fleetctl, etcd’ye doğrudan veya bir fleetd ajanı aracılığıyla bağlanarak servisleri gönderme, başlatma, durdurma, silme ve küme durumunu sorgulama gibi işlemleri gerçekleştirir.

Nasıl Çalışır?

Fleet’in çalışma prensibi oldukça basittir ancak dağıtık sistemlerin karmaşıklığını gizler:
1. Unit Gönderimi: Bir kullanıcı fleetctl submit my-service.service komutunu çalıştırdığında, fleetctl bu unit dosyasını etcd’ye yazar. Unit dosyası etcd’de “bekleyen” (pending) bir durumla işaretlenir.
2. Planlama: fleetd ajanları, etcd’deki değişiklikleri sürekli olarak izler. Yeni bir unit dosyası etcd’ye yazıldığında, bir fleetd ajanı (veya içindeki bir planlayıcı bileşeni), bu unit dosyasını hangi düğümde çalıştırması gerektiğine karar verir. Bu karar, unit dosyasındaki X-Fleet direktifleri (yerleşim kısıtlamaları) ve düğümlerin mevcut durumu (kaynaklar, meta veriler) dikkate alınarak verilir.
3. Başlatma: Karar verilen düğümdeki fleetd ajanı, etcd’den ilgili unit dosyasını alır ve yerel systemd’yi kullanarak servisi başlatır (systemctl start my-service.service).
4. Durum Güncellemesi: Servis başlatıldıktan sonra, fleetd ajanı servisin durumunu (çalışıyor, durdu, başarısız oldu vb.) etcd’ye geri yazar. Bu durum, fleetctl list-units gibi komutlarla sorgulanabilir.
5. Hata Durumunda Yeniden Planlama: Eğer bir düğüm arızalanırsa veya bir servis beklenmedik bir şekilde durursa, etcd’deki durum bilgisi güncellenir. fleetd ajanları bu değişikliği algılar ve arızalı servisi kümedeki başka uygun bir düğüme otomatik olarak yeniden planlamaya çalışır. Bu, Fleet’in temel yüksek erişilebilirlik özelliklerinden biridir.

Fleetctl Kullanımı: Temel Komutlar ve İşlemler

fleetctl, Fleet kümesiyle etkileşim kurmak için kullanılan ana komut satırı aracıdır. Bu bölümde fleetctl‘in kurulumu, küme bağlantısı ve temel servis yönetimi komutları ele alınacaktır.

Kurulum ve Bağlantı

CoreOS işletim sistemlerinde fleetctl genellikle önceden yüklü olarak gelir. Eğer yüklü değilse, CoreOS dokümantasyonundan veya Fleet GitHub sayfasından indirilebilir. fleetctl‘in küme ile iletişim kurabilmesi için etcd’ye erişmesi gerekir. Bu genellikle iki yolla yapılır:
* SSH Tünelleme (Önerilen): En güvenli ve yaygın yöntemdir. fleetctl, kümedeki bir CoreOS düğümüne SSH tüneli kurarak etcd’ye erişir.

export FLEETCTL_TUNNEL=coreos-node-ip:22
    fleetctl list-machines

Bu komut, coreos-node-ip adresindeki CoreOS düğümüne SSH üzerinden bağlanır ve etcd’ye erişmek için bir tünel oluşturur.
* Doğrudan etcd Uç Noktası: Daha az güvenli olmakla birlikte, etcd uç noktalarının doğrudan erişilebilir olduğu durumlarda kullanılabilir.

export FLEETCTL_ENDPOINT=http://etcd-cluster-ip:2379
    fleetctl list-machines

Bu yöntem, etcd’nin herkese açık olması durumunda güvenlik riskleri taşır ve genellikle üretim ortamlarında önerilmez.

Küme Durumunu Görüntüleme

Kümenin genel durumunu ve çalışan servisleri görüntülemek için aşağıdaki komutlar kullanılır:
* fleetctl list-machines: Kümedeki tüm CoreOS düğümlerini listeler. Her düğümün ID’si, IP adresi, durum bilgisi ve varsa meta verileri gösterilir.

fleetctl list-machines

Çıktı örneği:

MACHINE         IP              METADATA        STATE
    4a1b2c3d...     192.168.1.101   role=web        up
    5b2c3d4e...     192.168.1.102   role=db         up

* fleetctl list-units: Küme genelinde Fleet tarafından yönetilen tüm unit dosyalarını listeler. Hangi unit’in hangi makinede çalıştığını, durumunu ve istenen durumunu gösterir.

fleetctl list-units

Çıktı örneği:

UNIT            MACHINE         ACTIVE          SUB
    my-app.service  4a1b2c3d.../192.168.1.101  active          running
    nginx.service   5b2c3d4e.../192.168.1.102  active          running

* fleetctl status : Belirli bir unit’in detaylı durumunu, loglarını ve systemd çıktısını gösterir.

fleetctl status my-app.service

* fleetctl journal : Belirli bir unit’in systemd journal loglarını görüntüler. Bu, servislerdeki sorunları gidermek için çok kullanışlıdır.

fleetctl journal my-app.service

Unit Dosyaları Oluşturma

Fleet, standart systemd unit dosyalarını kullanır. Ancak, dağıtık davranışını kontrol etmek için [X-Fleet] bölümünde özel direktifler de ekleyebilirsiniz. Bir örnek Nginx servis unit dosyası:

# nginx.service
[Unit]
Description=Nginx Web Server
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill nginx
ExecStartPre=-/usr/bin/docker rm nginx
ExecStartPre=/usr/bin/docker pull nginx:latest
ExecStart=/usr/bin/docker run --name nginx -p 80:80 nginx:latest
ExecStop=/usr/bin/docker stop nginx
ExecStopPost=/usr/bin/docker rm nginx

[Install]
WantedBy=multi-user.target

[X-Fleet]
Bu servisin küme genelinde tek bir örnek olarak çalışmasını sağlar
X-Fleet-Global=true # Eğer her düğümde çalışmasını isteseydik
Conflicts=nginx.service # Aynı isimde başka bir nginx servisiyle çakışmasını engeller

Yukarıdaki örnekte:
* [Unit] bölümü, servisin tanımını ve bağımlılıklarını içerir. After=docker.service ve Requires=docker.service Docker’ın çalışır durumda olmasını sağlar.
* [Service] bölümü, servisin nasıl başlatılacağını (ExecStart), durdurulacağını (ExecStop) ve ön/son adımları (ExecStartPre, ExecStopPost) tanımlar. Docker konteynerlerini yönetmek için Docker komutları kullanılır.
* [Install] bölümü, servisin systemd tarafından nasıl etkinleştirileceğini belirtir.
* [X-Fleet] bölümü, Fleet’e özel talimatlar içerir. Conflicts=nginx.service direktifi, kümede yalnızca bir tane nginx.service örneğinin çalışmasını garanti eder.

Unitleri Yükleme ve Başlatma

Unit dosyalarını oluşturduktan sonra, bunları Fleet kümesine göndermeniz ve başlatmanız gerekir:
1. Unit Dosyasını Gönderme (Submit): Unit dosyasını etcd’ye kaydeder, ancak henüz başlatmaz.

fleetctl submit nginx.service

2. Unit’i Başlatma (Start): Etcd’ye kaydedilmiş unit’i kümede başlatma talimatını verir. Fleet, uygun bir düğüm bulup servisi orada çalıştırır.

fleetctl start nginx.service

Bu iki adımı tek bir komutla da yapabilirsiniz: fleetctl load nginx.service (yükler ve başlatır) veya fleetctl start nginx.service (eğer zaten submit edilmişse).
3. Durumu Kontrol Etme: Servisin başarıyla başlatılıp başlatılmadığını kontrol edin.

fleetctl list-units
    fleetctl status nginx.service

Unitleri Durdurma ve Kaldırma

Bir servisi durdurmak veya kümeden tamamen kaldırmak için aşağıdaki komutları kullanın:
* Unit’i Durdurma (Stop): Servisi çalıştıran düğümdeki yerel systemd’ye durdurma sinyali gönderir. Unit dosyası etcd’de kalır.

fleetctl stop nginx.service

* Unit’i Kaldırma (Destroy): Servisi durdurur ve unit dosyasını etcd’den tamamen siler.

fleetctl destroy nginx.service

Unitlerin Güncellenmesi

Bir unit dosyasını güncelledikten sonra, değişiklikleri kümede uygulamak için servisi yeniden göndermeniz ve başlatmanız gerekir:
1. Mevcut Servisi Durdur ve Kaldır:

fleetctl stop my-app.service
    fleetctl destroy my-app.service

2. Güncellenmiş Unit Dosyasını Gönder ve Başlat:

fleetctl submit my-app.service
    fleetctl start my-app.service

Sıfır kesinti süreli güncellemeler için, servisin birden fazla örneğini çalıştırıp, yeni sürümü ayrı bir isimle başlatıp, eski sürümü durdurmadan önce yeni sürümün hazır olmasını beklemek gibi daha gelişmiş stratejiler gerekebilir. Fleet, bu tür karmaşık senaryoları doğrudan desteklemese de, temel mekanizmaları sağlayarak bu tür stratejilerin uygulanmasına olanak tanır.

Gelişmiş Fleet Kullanımı ve Stratejiler

Fleet, sadece servisleri başlatıp durdurmaktan daha fazlasını yapabilir. Gelişmiş özellikleri sayesinde, servis yerleşimini kontrol edebilir, bağımlılıkları yönetebilir ve daha dayanıklı uygulamalar oluşturabilirsiniz.

Unit Bağlantıları ve Bağımlılıklar

Systemd unit dosyalarında olduğu gibi, Fleet unit dosyalarında da servisler arası bağımlılıkları tanımlayabilirsiniz. Bu, bir servisin başka bir servis başlatılmadan önce çalışmamasını veya başka bir servisle birlikte başlatılmasını sağlamak için önemlidir.
* Requires=: Bu unit’in başlaması için belirtilen unit’in başarılı bir şekilde başlaması gerektiğini belirtir. Eğer bağımlı unit başarısız olursa, bu unit de başlatılamaz.
* After=: Bu unit’in, belirtilen unit başladıktan sonra başlatılması gerektiğini belirtir. Bağımlı unit’in başarısız olması bu unit’in başlamasını engellemez, sadece sırasını belirler.
* BindsTo=: Requires gibidir, ancak bağımlı unit durdurulduğunda bu unit’in de durdurulmasını sağlar.

Örnek: Bir veritabanı servisi başlatılmadan önce bir uygulamanın başlamamasını sağlamak:

# my-app.service
[Unit]
Description=My Web Application
After=docker.service my-db.service
Requires=docker.service my-db.service
...

Bu, my-app.service‘in başlaması için docker.service ve my-db.service‘in aktif olması gerektiğini belirtir.

Servis Yerleşim Kısıtlamaları

Fleet’in en güçlü özelliklerinden biri, servislerin kümedeki belirli düğümlere yerleştirilmesi için kısıtlamalar tanımlayabilme yeteneğidir. Bu, [X-Fleet] bölümündeki özel direktiflerle yapılır.
* X-Fleet-MachineMetadata==: Düğümlere meta veri etiketleri atayabilir ve servislerin yalnızca bu etiketlere sahip düğümlerde çalışmasını sağlayabilirsiniz. Örneğin, “role=web” etiketli düğümlerde web sunucularını çalıştırmak için:

# web-server.service
    [X-Fleet]
    MachineMetadata=role=web

Düğüme meta veri eklemek için: fleetctl start --metadata role=web (bu komut fleetctl‘in eski sürümlerinde çalışıyordu, yeni sürümler için fleetctl set-machine-metadata kullanmak veya cloud-config ile düğüm başlatırken belirtmek daha yaygındır).
* X-Fleet-Conflicts=: Bu direktif, belirtilen unit’in bu unit ile aynı düğümde çalışmasını engeller. Yüksek erişilebilirlik için aynı servisin birden fazla örneğini farklı düğümlere dağıtmak istediğinizde kullanışlıdır.

# my-app@.service (template unit)
    [X-Fleet]
    Conflicts=my-app@*.service

Bu, my-app@1.service ve my-app@2.service gibi farklı örneklerin aynı düğümde çalışmamasını sağlar.
X-Fleet-Global=true: Bu direktif, servisin kümedeki her* düğümde otomatik olarak başlatılmasını sağlar. Örneğin, bir log toplama ajanı veya bir izleme aracı gibi servisler için idealdir.

# fluentd.service
    [X-Fleet]
    Global=true

Yüksek Erişilebilirlik ve Ölçeklenebilirlik

Fleet, temel yüksek erişilebilirlik ve ölçeklenebilirlik mekanizmalarını sunar:
* Birden Fazla Örnek Çalıştırma: Bir servisin birden fazla örneğini (örneğin, my-app@1.service, my-app@2.service) başlatarak yükü dağıtabilir ve bir örnek başarısız olduğunda diğerlerinin çalışmaya devam etmesini sağlayabilirsiniz. Conflicts direktifi ile bu örneklerin farklı düğümlere dağıtılmasını garanti edebilirsiniz.
* Otomatik Yeniden Planlama: Bir düğüm arızalandığında veya bir servis durduğunda, Fleet otomatik olarak başarısız olan unit’i başka uygun bir düğüme taşımaya çalışır. Bu, temel bir kendini iyileştirme mekanizmasıdır.

Dağıtık Uygulama Kalıpları

Fleet, CoreOS ekosisteminde çeşitli dağıtık uygulama kalıplarını desteklemek için kullanılabilir:
* Sidekick Pattern: Bir ana uygulamanın yanında çalışan yardımcı servisler (sidekick’ler) için kullanılır. Örneğin, bir web uygulamasının yanında bir registrator konteyneri çalıştırarak servis keşfini otomatikleştirebilirsiniz. registrator, Docker konteynerlerini izler ve yeni konteynerleri etcd’ye kaydeder.
* Servis Keşfi: Fleet’in kendisi doğrudan bir servis keşif sistemi değildir, ancak etcd’yi kullanarak servis keşfi yapmayı kolaylaştırır. registrator gibi araçlar, çalışan konteynerlerin IP adreslerini ve portlarını etcd’ye kaydedebilir ve confd gibi araçlar bu bilgiyi kullanarak yapılandırma dosyalarını (örneğin, Nginx proxy yapılandırması) dinamik olarak güncelleyebilir.

Fleet ve Diğer Araçlar

Fleet, CoreOS’un ilk zamanlarında konteyner orkestrasyonunda önemli bir rol oynamış olsa da, zamanla Kubernetes, Docker Swarm ve Mesos gibi daha kapsamlı ve özellikli platformlar ortaya çıkmıştır. Fleet, özellikle CoreOS’un “distributed systemd” felsefesine uygun, daha hafif ve basit orkestrasyon ihtiyaçları için tasarlanmıştır. Bu nedenle, karmaşık mikroservis mimarileri veya çok büyük ölçekli dağıtımlar için Kubernetes gibi araçlar daha uygunken, daha küçük veya özel CoreOS kümeleri için Fleet hala anlaşılması gereken bir araçtır.

Pratik Bir Örnek: Basit Bir Web Uygulaması Dağıtımı

Şimdiye kadar öğrendiklerimizi pekiştirmek için, Fleet ve fleetctl kullanarak basit bir web uygulamasını CoreOS kümesine nasıl dağıtabileceğimize dair pratik bir örnek inceleyelim.

Senaryo Tanımı

Bir CoreOS kümemiz var ve bu kümeye aşağıdaki servisleri dağıtmak istiyoruz:
* Nginx Web Sunucusu: Gelen istekleri dinleyecek ve statik içerik sunacak veya diğer servislere proxy yapacak.
* Python Flask Uygulaması: Basit bir dinamik web uygulaması (örneğin, “Hello, CoreOS!” mesajını döndüren bir Flask uygulaması).

Her iki servis de Docker konteynerleri olarak çalışacak. Nginx’in 80 portundan dışarıya açık olmasını ve Flask uygulamasının ise Nginx’in proxy yapabileceği dahili bir portta çalışmasını sağlayacağız.

Nginx Unit Dosyası (nginx.service)

# /etc/systemd/system/nginx.service
[Unit]
Description=Nginx Web Server
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill nginx-proxy
ExecStartPre=-/usr/bin/docker rm nginx-proxy
ExecStartPre=/usr/bin/docker pull nginx:latest
ExecStart=/usr/bin/docker run --name nginx-proxy -p 80:80 -d nginx:latest
ExecStop=/usr/bin/docker stop nginx-proxy
ExecStopPost=/usr/bin/docker rm nginx-proxy
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

[X-Fleet]
Nginx'in kümede tek bir yerde çalışmasını sağlayalım
Conflicts=nginx.service

Bu unit dosyası, Nginx konteynerini nginx-proxy adıyla başlatır ve host’un 80 portunu konteynerin 80 portuna eşler. Conflicts=nginx.service ile kümede sadece bir Nginx örneğinin çalışmasını garanti ederiz.

Flask Uygulaması Unit Dosyası (flask-app.service)

Basit bir Flask uygulaması için bir Dockerfile:

# Dockerfile
FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

app.py içeriği:

# app.py
from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello from Flask on CoreOS!"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Bu Dockerfile ve app.py ile bir Docker imajı oluşturup bir Docker kayıt defterine (örneğin Docker Hub) göndermeniz gerekir. Örneğin, yourusername/flask-app:latest.

Şimdi Flask uygulaması için unit dosyası:

# /etc/systemd/system/flask-app.service
[Unit]
Description=Flask Web Application
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill flask-web-app
ExecStartPre=-/usr/bin/docker rm flask-web-app
ExecStartPre=/usr/bin/docker pull yourusername/flask-app:latest
ExecStart=/usr/bin/docker run --name flask-web-app -p 5000:5000 -d yourusername/flask-app:latest
ExecStop=/usr/bin/docker stop flask-web-app
ExecStopPost=/usr/bin/docker rm flask-web-app
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

[X-Fleet]
Flask uygulamasının da kümede tek bir yerde çalışmasını sağlayalım
Conflicts=flask-app.service

Bu unit dosyası, Flask uygulamasını flask-web-app adıyla başlatır ve host’un 5000 portunu konteynerin 5000 portuna eşler.

Dağıtım Adımları

1. Unit Dosyalarını Oluşturun: nginx.service ve flask-app.service dosyalarını yerel makinenizde oluşturun.
2. Unitleri Gönderin ve Başlatın:

fleetctl submit nginx.service
    fleetctl start nginx.service

    fleetctl submit flask-app.service
    fleetctl start flask-app.service

3. Durumları Kontrol Edin:

fleetctl list-units
    fleetctl status nginx.service
    fleetctl status flask-app.service

list-units çıktısında, her iki servisin de active ve running durumda olduğunu ve farklı veya aynı düğümlerde (eğer Conflicts kısıtlaması farklı bir düğüme yerleşimi zorlamıyorsa) çalıştığını görmelisiniz.
4. Uygulamayı Test Edin:
Nginx’in çalıştığı düğümün IP adresini (fleetctl list-machines çıktısından alın) kullanarak tarayıcınızdan bu IP adresine gidin. Nginx’in varsayılan karşılama sayfasını veya yapılandırdığınız statik içeriği görmelisiniz.
Flask uygulamasının çalıştığı düğümün IP adresini ve 5000 portunu kullanarak (örn: http://flask-app-ip:5000) Flask uygulamanıza erişin. “Hello from Flask on CoreOS!” mesajını görmelisiniz.

Bu örnek, Fleet’in nasıl temel bir Docker tabanlı uygulamayı CoreOS kümesinde dağıtmak için kullanılabileceğini göstermektedir. Daha karmaşık senaryolarda, Nginx’i bir reverse proxy olarak yapılandırıp Flask uygulamasına yönlendirmek, servis keşfi araçlarını kullanmak ve daha fazla ölçeklenebilirlik sağlamak için unit şablonlarını (my-app@.service) kullanmak gibi adımlar eklenebilir.

Güvenlik ve En İyi Uygulamalar

Fleet ve CoreOS kümelerini yönetirken güvenlik ve en iyi uygulamalar önemlidir.

fleetctl Erişimi Güvenliği

* SSH Tünelleme Kullanın: FLEETCTL_TUNNEL kullanarak SSH tüneli üzerinden etcd’ye bağlanmak, etcd uç noktasını internete açık bırakmaktan çok daha güvenlidir. SSH anahtarlarınızın güvenliğini sağlayın.
* etcd Erişimi Kısıtlamaları: etcd kümenizin dışarıdan erişime kapalı olduğundan ve yalnızca güvenilir istemcilerin erişebildiğinden emin olun. TLS/SSL kullanarak etcd iletişimini şifreleyin ve istemci kimlik doğrulamasını etkinleştirin.
* Erişim Kontrolü: fleetctl komutlarına erişimi, yetkili kullanıcılarla sınırlayın.

Unit Dosyaları Güvenliği

* Ayrıcalıklı Konteynerlerden Kaçının: Mümkün olduğunca privileged Docker konteynerlerinden kaçının. Bir konteynere gereksiz ayrıcalıklar vermek, güvenlik açıklarına yol açabilir.
* Sınırlı Kaynak Kullanımı: Unit dosyalarında Docker’ın --memory, --cpu-shares gibi seçeneklerini kullanarak konteynerlerin kaynak kullanımını sınırlayın. Bu, bir konteynerin tüm düğüm kaynaklarını tüketmesini önler.
* En Az Yetki Prensibi: Konteynerler içinde çalışan uygulamaların yalnızca ihtiyaç duydukları izinlere sahip olduğundan emin olun.
* Güvenilir İmajlar Kullanın: Docker imajlarını güvenilir kaynaklardan (örneğin, Docker Hub’daki resmi imajlar veya kendi güvenli kayıt defterinizdeki imajlar) çekin.

Bakım ve İzleme

* Log Yönetimi: Servislerinizin loglarını düzenli olarak kontrol edin (fleetctl journal ). Merkezi bir log yönetim sistemi (örneğin, Fluentd, ELK Stack) kullanarak tüm küme loglarını tek bir yerden toplamak ve analiz etmek faydalıdır.
* Metrik Toplama: Küme düğümlerinin ve çalışan servislerin performans metriklerini (CPU, bellek, disk, ağ kullanımı) izleyin. Prometheus, Grafana gibi araçlar bu konuda yardımcı olabilir.
* Otomatik Güncellemeler: CoreOS’un otomatik güncelleme mekanizmasından faydalanın. Ancak, güncellemelerin uygulamanız üzerindeki etkilerini test etmek için bir hazırlık ortamı kullanın.

Fleet’in Geleceği ve Alternatifler

Fleet, CoreOS ekosisteminde önemli bir rol oynamış olsa da, konteyner orkestrasyon dünyası hızla gelişmiştir ve Fleet’in konumu değişmiştir.

Fleet’in Durumu

CoreOS’un Red Hat tarafından satın alınması ve ardından Red Hat OpenShift ve Kubernetes’e odaklanılmasıyla birlikte, Fleet’in aktif geliştirilmesi durdurulmuştur. Red Hat, CoreOS’un geleceğini Kubernetes tabanlı OpenShift Container Platform’a entegre etmiştir. Bu nedenle, Fleet artık aktif olarak geliştirilmeyen ve “deprecated” (kullanımdan kaldırılmış) bir araçtır.

Bu bilgi, Fleet’i öğrenen veya mevcut bir Fleet kurulumunu yöneten herkes için kritik öneme sahiptir. Yeni projeler için Fleet kullanmak yerine, modern konteyner orkestrasyon araçlarına yönelmek şiddetle tavsiye edilir. Ancak, eski CoreOS kurulumlarını anlamak veya dağıtık sistemlerin temel prensiplerini öğrenmek amacıyla Fleet’i bilmek hala değerlidir.

Modern Alternatifler

Günümüzde, Fleet’in yerini alan veya ondan çok daha kapsamlı özellikler sunan birçok konteyner orkestrasyon platformu bulunmaktadır:
* Kubernetes: Açık ara en popüler ve kapsamlı konteyner orkestrasyon platformudur. Dağıtık sistemlerin tüm yönlerini (servis keşfi, yük dengeleme, otomatik ölçekleme, depolama yönetimi, yapılandırma yönetimi vb.) yönetmek için zengin bir API ve ekosistem sunar. CoreOS da artık Kubernetes’e odaklanmıştır.
* Docker Swarm: Docker’ın kendi yerleşik orkestrasyon aracıdır. Kubernetes’e göre daha basit bir yapıya sahiptir ve Docker Compose ile iyi entegre olur. Daha küçük ölçekli dağıtımlar için iyi bir seçenek olabilir.
* Nomad: HashiCorp tarafından geliştirilen, genel amaçlı bir iş zamanlayıcısıdır. Konteynerlerin yanı sıra, sanal makineleri ve diğer iş yüklerini de orkestra edebilir. Esnekliği ve basitliği ile öne çıkar.

Bu modern alternatifler, Fleet’in sunduğu temel orkestrasyon yeteneklerinin çok ötesine geçerek, daha karmaşık, ölçeklenebilir ve dayanıklı dağıtık uygulamaların yönetimi için gerekli araçları sunar.

Sonuç

Fleet ve fleetctl, CoreOS’un ilk zamanlarında, dağıtık systemd unit yönetimi için yenilikçi ve güçlü bir çözüm sunmuştur. CoreOS’un etcd ve systemd gibi temel bileşenlerini kullanarak, geliştiricilerin ve sistem yöneticilerinin Docker konteynerlerini bir küme genelinde tutarlı ve güvenilir bir şekilde dağıtmasına ve yönetmesine olanak tanımıştır. Servis yerleşim kısıtlamaları, otomatik yeniden planlama ve unit bağımlılıkları gibi özellikleri sayesinde, Fleet, dağıtık servis yönetiminin temel zorluklarına etkili çözümler getirmiştir.

Ancak, teknoloji dünyasının hızlı evrimiyle birlikte, Kubernetes gibi daha gelişmiş ve kapsamlı konteyner orkestrasyon platformları Fleet’in yerini almıştır. Fleet’in aktif geliştirilmesinin durdurulmuş olması ve “deprecated” olarak kabul edilmesi, yeni projeler için alternatif çözümlere yönelmenin gerekliliğini ortaya koymaktadır.

Yine de, Fleet’in çalışma prensiplerini ve CoreOS ekosistemindeki rolünü anlamak, dağıtık sistem mimarileri, servis orkestrasyonu ve konteyner yönetimi alanındaki temel kavramları öğrenmek için hala değerli bir kaynaktır. Bu makale, Fleet ve fleetctl’in nasıl kullanılacağına dair kapsamlı bir rehber sunarak, bu eski ama önemli teknolojinin anlaşılmasına katkıda bulunmayı amaçlamıştır. Modern konteyner orkestrasyonuna geçiş yaparken, Fleet’in sunduğu dersler ve CoreOS’un felsefesi, daha iyi ve daha dayanıklı dağıtık sistemler tasarlamak için bir temel oluşturabilir.