Gantek
GitLab 101

GitLab 101

GitLab DevOps Platformu, en temelinde Git version kontrol aracını kullanan bir Kaynak Kod Yönetim (Source Code Management-SCM) aracıdır. Bu uygulama; rakiplerinden farklı olarak yıllardır sürekli entegrasyon (Continous Integration-CI), sürekli dağıtım (Continous Delivery -CD), güvenlik, wiki, sorun takibi (issue tracking) ve planlama gibi farklı özelliklerini geliştirmekte, GitOps ve ML (Machine Learning) “pipeline”lar gibi yenilikçi özellikleri de kendine hızlıca entegre etmektedir.

GitLab, 2011 yılında açık kaynak kodlu proje olarak geliştirilmeye başlanmıştır. Başlangıçta uygulamanın çoğunluğu Ruby ile yazılmış, sonrasında da Go dili ile geliştirmeler eklenmiştir. Yazılım geliştirme ekiplerinin iş birliği içerisinde çalışmasını sağlamak amacıyla başlayıp, daha hızlı, verimli ve güvenli yazılım teslimi yapan uçtan uca bir DevOps platformu haline dönüşmüştür. DevOps süreçleri için büyük kolaylık ve avantaj sağlayan bir platform olarak her yıl popülerliğini daha da artırmaktadır. DevOps yazılım döngüsünde bulunan tüm aşamaları kendi üzerinde barındırması iş yükünü büyük ölçüde hafifletmektedir.


Kuruluşlardaki her ekip, GitLab kullanarak DevOps yaşam döngüsü boyunca şeffaf, tutarlı ve izlenebilir şekilde projelerin yönetimini sağlayabilmektedir. Yazılımın planlanması, “build” ve “deploy” edilmesi hızlı ve güvenli bir şekilde yapılabilmektedir.

Yukarıdaki görselde GitLab’in sağladığı hizmetler detaylı olarak ifade edilmiştir. Buradan da görüldüğü gibi, projenin planlanmasından başlayıp son aşamasına kadar geçen bu süreçte, farklı araçlar (tools) ile yapılabilen işlemleri, örneğin güvenlik, depolama, izleme gibi görevleri, çok kolay bir şekilde projelere entegre edebilmeyi sağlamaktadır. Bu yeteneğini özellikle vurgulamak gerekir. Çünkü yazılım geliştiriciler olarak pek çok “tool”ları birbiriyle entegre olarak çalıştırmak efor isteyen bir iş olarak karşımıza çıkmaktadır. Gerek konfigürasyonlarının yapılması, gerekse çalışmaya başladıktan sonra çıkan çeşitli hataları için aksiyon alabilmek çok zahmetli olabilmektedir. GitLab, bu yönden baktığımız zaman bizlere büyük avantajlar sağlamaktadır. Bu konfigürasyon işlemleri kullanıcı arayüzünden kolaylıkla yapılabileceği gibi, CI/CD işlemlerinin beyni olarak nitelendirilebilen “gitlab-ci.yml” dosyası üzerinden de aktif hale getirilebilmektedir.

GitLab, CI/CD süreçlerinin “As Code” olarak tuttuğu ve yıllardır bunu geliştirdiği için yönetilebilen araçların en iyilerinden biri olduğunu söyleyebiliriz. Yapılan bu işlemler için GitLab’in aslında iki önemli bileşeni bulunmaktadır. Bileşenlerin işlevlerinin daha iyi anlaşılması için bir örnek vererek anlatmak gerekirse; “.gitlab-ci.yml” beyin, “Gitlab-Runner” ise insan vücudu gibi düşünülebilir. Burada anlatılmak istenen; “gitlab-ci.yaml” dosyasında “pipeline”ın ne gibi görevler yerine getireceğinin ayarlanması, “GitLab Runner”da ise bu ayarlamalara göre bir “pipeline” oluşturulup yürütülebilmesidir diyebiliriz. Özetle, Gitlab CI/CD’yi kullanmak için öncelikle “pipeline”i tanımlayan biri “.gitlab-ci.yml” isimli bir YAML dosyası yazmalı, “Gitlab Runner” kurup konfigüre ettikten sonra da bu “pipeline”ı çalıştırmalıdır.

 

“Gitlab Runner” Nedir?

“Gitlab Runner”, Go diliyle yazılmış olup “.gitlab-ci.yml”da belirtilen “job”ların yürütülmesini ve çıktılarının geri GitLab sunucusuna gönderilmesini sağlayan açık kaynak kodlu bir projedir. Gitlab sunucusu ile iletişime geçmek içi GitLab API’sini kullanır. “GitLab Runner” istenilen bir platform üzerine kurulabilmektedir (Linux, Windows, MacOS, Docker). “Gitlab Runner” farklı dillerde yazılan yazılımların testlerini yapabilmektedir. Örnek vermek gerekirse, .NET, Java, Pyhton, PHP ve diğer dilleri söyleyebiliriz.

“Gitlab Runner”, farklı şekillerde konfigüre edilebilmektedir. Projelerin çalışma şekilleri veya yoğunluğuna bağlı olarak bunların ayarlanması yazılım geliştirme süreci için fayda sağlamaktadır. “Shared Runner” katagorisindeki “runner”lara Gitlab’da bulunan bütün gruplar ve projeler erişebilmektedir. “Spesific Runner”lar kullanıcın ayarlamasına göre istenilen bir proje üzerinde yetkilendirilebilir. ”Group Runner” kategorisindekilere ise aynı grubun altındaki bütün alt gruplar ve projeler tarafından erişim sağlanabilir.

“.gitlab-ci.ymlNedir?

“.gitlab-ci.yml”nin, oluşturulmak istenen “pipeline” için konfigürasyonların yapıldığı dosya olduğunu daha önce de belirtmiştik. Bu YAML dosyasında aşağıdakiler tanımlanabilmektedir:

  • Çalıştırılmakistenenkomutlar.
  • Dahil edilmek istenen başka konfigürasyon dosyaları ve şablonları.
  • Bağımlılıklarveönbellekler (Dependencies & Caches).
  • Projenin deploy edileceğikonum.
  • Komutlarınotomatikveyamanuelolarakçalıştırılmasınınayarlanması.

Bunun gibi örnekler çoğaltılabilir.

GitLab’i daha iyi anlamak için temel bileşenlerine bakalım:

Varsayılan olarak “pipeline”da üç tane aşama (stage) olmalıdır: “build”, “test” ve “deploy”. “Stage”, bir “job”un ne zaman ve nasıl yürütülmesi gerektiğini tanımlamaktadır. Her “stage”de bir veya birden fazla “job” bulunabilir. “Pipeline”da yapılması istenilen görevler “job”lar ile tanımlanır. Her “stage”deki “job”lar paralel olarak yürütülmektedir ve bir aşamadaki tüm işler başarılı olursa sıradaki “stage”e geçilir. Eğer bir aşamadaki bir iş başarısız olursa bir sonraki “stage”e geçilmez. Özetle, komutlar “job”ların içinde gruplanırlar, “job”lar ise “pipeline”ların daha küçük bir parçası olarak çalışırlar. Tanımlanan birbirinden bağımsız “job”lar ise “stage” altında istenilen sırada çalıştırılacak şekilde gruplandırılabilir. “Job”ları, projeye ve yapılmak istenen testlere göre sıralamak önemli bir unsurdur. “.gitlab-ci.yml” dosyası “repository”e eklendiği zaman, GitLab bunu tespit eder ve “Gitlab Runner” üzerinde daha önce tanımlanan “job”lar çalışmaya başlar. Aşağıda basit bir örnek verilmiştir ve yapılan işlemler açıklanmaktadır:

İlk olarak “build stage”inde bulunan “build-code-job” ismindeki “job” çalışır. “Job”, çıktı olarak “Ruby’nin versiyonunu verir ve “rake” komutu ile projeyi “build” eder. Eğer bu “stage” başarılı bir şekilde tamamlanırsa, “test-code-job” ismindeki “job”lar paralel olarak çalışmaya başlar ve belirtilen dosyaları test eder.

 

KAYNAKLAR:

Güncel Blog Yazıları

2023'te Dijital Yatırımlarımızda Öne Çıkacak Konular
Turbonomic 101
Açık Kaynak Yazılım Lisans Türleri
INSTANA 101
Podman
GitLab 101
CI/CD Nedir?
GitLab’ın AI Yeteneği ve DevSecOps Platformundaki Rolü
Redis‘te En Sık Yapılan Hatalar
Bulut Teknolojisi Nedir?
Veritas ile Veri Yönetiminde Yenilikçi Yaklaşımlar
API Gateway'ler: Dijital Dönüşümde Verimliliği ve Güvenliği Artırmanın Yolu
Red Hat Ansible Lightspeed ve IBM Watsonx Code Assistant: BT Otomasyonunda Devrim
PostgreSQL’in Tarihçesi
PostgreSQL Mimarisi
Istio Service Mesh
Mikroservislerin Gelecegi
Elasticsearch Machine Learning
Gelişmiş Arama Deneyimi: Elasticsearch Relevance Engine ve Büyük Dil Modelleri ile Yapay Zeka Destekli Arama Çözümleri
Kubernetes - Cka Sınavı  Genel Başlıklar
Kubernetes Mimarisi
Openshift Updates
Dell OpenManage Enterprise ile Tek Yerden Çoklu Sistem Yönetimi
Dolandırıcılık Yönetim Sisteminin Önemi ve Bu Kapsamda Kullanılan ROC-Fraud Management System
Partner Settlements’ın Önemi ve Bu Kapsamda Kullanılan ROC-Partner Settlement System
Gelir Güvence Sisteminin Önemi ve Bu Kapsamda Kullanılan ROC-Revenue Assurance System
Windows Admin Center – Kolaylaştırılmış, Modern Uzaktan Sunucu Yönetim Aracı
Oracle ASR Manager ile Oracle Donanım Arızalarında Otomatik Çağrı  Açılması
Veri Tabanı Nedir? Veri Tabanı Güvenliğini Nasıl Sağlarız?
DevOps Nedir? DevOps Neden Önemlidir?
PostgreSQL’de TOAST (The Oversized-Attribute Storage Technique) Kavramı
MVCC (Multi Version Concurrency Control) nedir? PostgreSQL’in MVCC implementasyonu nasıldır?