Gitlab-Runner Executors Nedir?

Gitlab-Runner Executors Nedir?

Eğer gitlab-runner ile ilgili öğrenmeye yeni başladıysanız öncelikle https://kubernetesturkey.com/gitlab-runner-nedir-nasil-kurulur makalemizi okumanızı tavsiye ederim.

Normalde makalelerin bir süre sonra güncellenmesi gerekiyor hepimizin bildiği gibi ama bu başka. Gitlab artık executors destek listesini kilitledi. Herhalde bu makale meslek hayatımda güncelleme istemeyen yagane ürün olarak kalıcak 🙂

Nedir? yazımda konuştuğumuz gibi runnerlar sunucumuza register olduktan sonra işlemleri üzerine alıp pipeline'ı bir bir takip ederek çalıştırıyorlar. Peki, build için jdk, push için docker, test için go gereksinimleri olan bir runner gerektiğinde, veya bir projem jdk8 bir projem 9 gereksimi varsa, linux alternatives kullanıcak kadar linux bilgim veya sabrım yoksa napıcam?

Executors Tipleri

  • SSH
  • Shell
  • Parallels
  • VirtualBox
  • Docker
  • Docker Machine (auto-scaling)
  • Kubernetes
  • Custom
Kısa kısa;

SSH

Doğruyu söylemek gerekirse sadece varlığından haberim var bana çok da güven vermiyor. Sebebi de Gitlab'in kendi açıklamalarında bunun en az desteklenen tip olduğu ve tavsiye edilmediğidir. Mantık basit adı gibi, GitLab Runner'ın harici bir sunucuya bağlanmasını sağlar ve yapıları orada çalıştırır.  Eğer bunu kullanmak isterseniz daha fazla araştırmanızı tavsiye ederim ama gitlab-runner zaten light, kurun geçin .

SHELL

Shell, yapılandırılması en basit executordur. Derlemeleriniz için gerekli tüm bağımlılıkların, Runner'ın kurulu olduğu makineye manuel olarak yüklenmesi gerekir. Misal docker build&push için docker, java için maven.

Bu yazının başında anlattığım birden fazla jdk versiyonu, gibi bağımlılıkları bu tip ile tek sunucu ile karşılayamayabilirsiniz.

Fakat eğer build ve push gibi adımların gereksinimlerini docker file içerisinde halledebiliyorsanız ( bununla ilgili de bir yazı yazıp burayı güncelleyeceğim ) vm üzerine docker  yükleyip işi bitirebilirsiniz.

DOCKER/DOCKER MACHINE/KUBERNETES

Shell'de çözemediğimiz bağımlılık problemlerini ki bunları sadece jdk, maven vs gibi düşünmeyin test adımı için gerekli olan mysql, redis vb gibi servisleri de içinde barındırabilecek bir yapıyı hayal edin ve okumaya devam edin bu hayal gerçek 🙂

Gitlab-runner registration aşamasında, executer tipini docker verip daha sonrasında default image vererek kolaylıkla oluşturabilirsiniz.

En başta sizden eğer pipelineda belirtilmemisse kullanacağı default image'ı soracaktır. Misal ubuntu dediniz, ama pipeline çalışırken size redis lazım, .gitlab-ci.yml'da image: redis:latest demeniz yeterli.

Çok övdük, tabiki bir bokluk var. 🙂 Bu executor tipinde docker build ve push komutlarını çalıştırmak gerçekten başta işkence. 2 tam günüm gitti. docker-dind kullanmak da yetmiyor.

.gitlab-ci.yml'ınıza eklemeniz;

....
variables:
  DOCKER_DRIVER: overlay2
  # See https://github.com/docker-library/docker/pull/166
  DOCKER_TLS_CERTDIR: ""
  DOCKER_HOST: tcp://docker:2375
...

Daha sonrasında ise eğer docker executor kullanıyorsanız /etc/gitlab-runner/config.tml içerisinden privileged true demeniz gerekiyor.

Kubernetes executor için, helm values.yaml'ında privileged: değerini true'ya çekmeniz gerekiyor. Bunları yapmazsanız hata alırsınız.

Neyse konumuza dönelim, docker machine ise docker'ın auto-scalingli hali.

Kubernetes executor, 3'ü bir arada nescafe, derlemeleriniz için mevcut bir Kubernetes clusterını kullanmanıza olanak tanır. Executor, Kubernetes cluster API'sini çağırıp ve her GitLab CI işi için yeni bir pod oluşturacaktır. Her yeni bir job yeni bir pod yeni bir docker ve işin güzel tarafı sofrayı yine kuran kaldırdıpı için arkada çöp de bırakmaması.

Kubernetes executor, gitlab managed k8siniz var ise UI dahi oluşturabiliniyor.

CUSTOM

Burda ortalık baya karışıyor. Gerçekten ileri seviye bir konu büyük ihtimallede işinize yaramayacaktır ama ben yine de küçük bir bahsedeyim;

Podman ve Libvirt gibi gitlab'in desteklemediği ortamlarınız var ise, bazı betikler yazarak/ekleyerek kendi executorınızı oluşturmanız ve bu desteklenmeyen ortamlarda koşmanızı sağlar.

Parallels ve VirtualBox

İkisi de aynı şekilde çalışıyorlar ama açıkcası benim de pek ilgimi çekmedi. Windows kurulumu da burdan yapılıyor. https://docs.gitlab.com/runner/executors/virtualbox.html

Sonuç

Eğer ki küçük ölçekli bir yapınız varsa, single-node gitlab koşuyorsanız, sizin için shell en kolayı olucaktır.

Biraz daha büyük bir yapınız ve geniş yelpazede bir tech stackiniz var ise, k8s üzerinde koşmanız size çok avantaj sağlayacaktır.

Shell ve ssh'ın yapılarından ötürü ( vm üzerinde çalışıyorlar sonuçta aynı bash aynı sh ) her build için temiz bir ortamınız olmayacaktır, docker ve k8s ise build adımlarında biraz yorduğu tecrübe ile sabit 🙂

Burda best practise executor, sizin ihtiyaçlarınıza en uygun olandır.

Yorum Yapın