GitLab CI’daki Uygulamanızı Google Kubernetes Engine (GKE) ile Dağıtmak

Google Cloud Platform, Google Kubernetes Engine(GKE) adı verilen konteyner yapısına sahip bir uygulama yönetimine sahiptir. GKE, konteynerize edilmiş uygulamalar için canlı ortama hazır ve yönetimini kendisinin yaptığı bir servis sunar. Böylelikle uygulamalarınızı Kubernetes cluster’ları (kümeleri) içerisinde kurmanız ve çalıştırmanız mümkün hale gelir.

Bu blog yazısında, Google Cloud GKE cluster’ının dağıtımını ve yapılandırılmasını otomatikleştirmek için Gitlab CI Runner kullanan bir Gitlab CI/CD pipeline oluşturacağız.

Her GitLab CI/CD pipeline’ın yönetimine olanak tanıyan .gitlab-ci.yml adlı bir YAML dosyasına ihtiyacı vardır. Bunun için örnek bir kod depomuz (repo) var, bu yüzden açıklaması daha kolay olacak. Bu projenin içinde basit bir Node.js uygulaması var. Pipeline, yapılan her değişiklik için otomatik olarak bir konteyner oluşturur ve bunu .gitlab-ci.yml dosyası aracılığıyla GKE’ye dağıtır. Biraz daha detaylı inceleyelim:

GitLab CI dosyası, job’un davranışını tanımlayan parametrelere sahiptir. En üste bakarsak, “stages” adında üç adımlı bir parametremiz var. Her adımın Gitlab Runners üzerinde çalışan farklı bir job’u var. Varsayılan olarak, CI job’ları paylaşımlı Gitlab Runners üzerinde çalışır, ancak kendi özel ortamınızdan da bir runner yükleyebilir ve kaydedebilirsiniz. Daha fazla bilgiyi burada bulabilirsiniz.

docker build adındaki ilk adımda, runner yeni bir docker imajı oluşturmak için Docker Engine’i kullanır ve bu imajı registry’e ilerletir. Bu imaj, 3000 numaralı bağlantı noktasında bir HTTP sunucusu başlatır ve bu sunucu da her isteğe You're on, HOSTNAME cevabı döner. HOSTNAME burada sunucunun gerçek ana bilgisayar (host) adıdır. Yine, bu basit bir HTTP sunucusudur ve tek ihtiyacı olan bir Docker Engine’dir. Bu sunucunun dış dünyadan erişilebilir olmasını istiyorsak uygun ağ ve ağ yönetimine ihtiyacımız var, bu da bizi ikinci adıma götürüyor.

gcloud deployadındaki ikinci adımda, runner üzerinde Google Cloud komut satırı aracını kullanır ve bir Google Cloud hesabını güvenli şekilde doğrular. Burada SERVICE_ACCOUNT değişkenini kullanır ve bu, runner aracılığıyla ortamlara uygulanan bir ortam değişkenini tutar. Ortam değişkenleri, yalnızca korumalı branch veya tag’lere maruz bırakılarak korunabilir. Ek olarak, job log’larda gizlenmeleri için maskelenebilirler. Bu hesap bilgileriyle, runner, .gitlab-ci.yml dosyasında belirtilen spesifikasyonlarda bir Kubernetes cluster oluşturur. Son olarak, aynı runner bu sefer Kubernetes komut satırı aracını kullanır ve daha sonra açıklayacağım simple-app.yaml dosyasında belirtilen pod’ları dağıtır.

gcloud destroy son adımdır. Bu adımı ekliyorum çünkü kod deposunu (repo) sadece test amaçlı oluşturuyorum ve bu yüzden işim bittiğinde dağıtımı otomatik olarak yok etmek istiyorum. when: manual parametresi sayesinde, bu adım sadece elle tetiklenebiliyor.

Bunu yapmak için projenizin CI/CD > Pipelines bölümüne gidebilirsiniz. Ardından Manual Job butonuna tıklayınca, job’lar yapılandırdığınız şekilde yürütülür.

Şimdi tekrar simple-app.yaml dosyasına gidebiliriz. Kubernetes, tüm aspect’lere bir nesne olarak davranır ve bu nesneler bir RESTful kaynak tarafından temsil edilir. Bu nesne bilgilerini Kubernetes’e bir YAML dosyası aracılığıyla sağlayabilirsiniz. Birlikte inceleyelim:

Bu YAML dosyasının 2 bölümü var. Kubernetes, bu bölümleri kind adı verilen bir parametre ile ayırır. Yani burada kind‘ın 2 türü var, ilki kind: Deployment, diğeri kind: Service. Her iki bölümde de, Kubernetes nesneleri için gerekli bilgileri saklayan ApiVersion, Kind, Metadata ve Spec parametreleri bulunmalıdır.

Bu dağıtım, aslında birinci adımda oluşturulan konteyner imajını alır, ardından bu imajı 3 ayrı nod’a kopyalar (ReplicaSet’in replicas: 3 dosyasından talep ettiği şey budur) ve bunları 3000 numaralı bağlantı noktasında (containerPort: 3000) gösterir. Bu üç pod, aralarındaki trafik yükünü dengeleyen bir LoadBalancer servisi ile dış dünyaya sunulacak ve servis olarak Google Cloud load balancer kullanacaktır. GKE, simple-app.yaml dosyasındaki servis bölümü ile, bir load balancer servisi oluşturur ve pod’un 3000 bağlantı noktasını dış dünyadan 80 bağlantı noktasına yeniden yönlendirir.

Bu konuda anlatılabilecek çok fazla şey var. Elimden geldiğince basit ve yeni başlayanların anlayabileceği seviyede tutmaya çalıştım. Umarım faydalı olmuştur.