paint-brush
CI/CD adımınızda Basit Veritabanı Geçiş Komut Dosyalarıby@mindsky
6,573
6,573

CI/CD adımınızda Basit Veritabanı Geçiş Komut Dosyaları

DevOps Yazma Yarışması'na gönderilen birçok başvuruda çok sayıda olağanüstü, üst düzey çalışma gördüm. Ancak çok az kişi, her gün çalışırken veritabanını ortak yedeklerde (geliştirme, aşama, üretim vb.) nasıl güncel tutacağını düşünüyor. Bu makale acemi geliştiricilere yöneliktir. Bir veritabanı geçiş sistemini CI/CD sürecine dahil etmeye yönelik basit bir tekniği göstermek için Spring'i örnek olarak kullandım.
featured image - CI/CD adımınızda Basit Veritabanı Geçiş Komut Dosyaları
Aleksander Tyryshkin HackerNoon profile picture
0-item
1-item

DevOps Yazma Yarışması'na gönderilen birçok başvuruda çok sayıda olağanüstü, üst düzey çalışma gördüm. Ancak çok az kişi, her gün çalışırken veritabanını ortak yedeklerde (geliştirme, aşama, üretim vb.) nasıl güncel tutacağını düşünüyor. Bu makale acemi geliştiricilere yöneliktir. Bir veritabanı geçiş sistemini CI/CD sürecine dahil etmeye yönelik basit bir tekniği göstermek için Spring'i örnek olarak kullandım.

Bu dağıtım için Liquibase ve GitLab CI/CD araçlarına ihtiyacımız olacak. Şimdilik bir veritabanının çalışır durumda olduğunu varsayalım. PostgreSQL kullanacağım.

GitLab CI/CD'si

GitLab'ı zaten dağıttıysanız bu adımı tamamen atlayabilirsiniz.


Gitlab'ı dağıtmak için Docker yöntemini kullanacağız. $GITLAB_HOME değişkenini oluşturmamız gerektiğini unutmamak önemlidir.


 sudo docker run --detach \ --hostname gitlab.devopscontest.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ --shm-size 256m \ gitlab/gitlab-ee:16.4.1-ee.0


Bir sonraki adım koşucuları kurmak ve yapılandırmaktır.


Zaten uzun süredir devam eden bir projeniz varsa ve her şey uzun süredir ayarlanmışsa yeni bir koşucu oluşturmayı atlayabilirsiniz.


GitLab CI


Örnek olarak 16.4.1 sürümünü kullanarak bir koşucunun oluşturulmasını göstereceğim. 17.0'dan sonraki her şey RUNNER_AUTHENTICATION_TOKEN kullanılarak kayda gider, ancak yaklaşım mevcut yaklaşıma yakındır.


GitLab 17.0'dan önceki akış


GitLab 17.0'dan sonraki akış


Öncelikle runner kaynağını kurmanız gerekiyor. Dağıtılmış GitLab'ınıza bash aracılığıyla yüklemek için bu örnek, Apple Silicon tabanlı sistemler (diğer işletim sistemlerini burada bulabilirsiniz) için runner'ı nasıl kurabileceğinize yardımcı olur:


 # Download the binary for your system sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 # Give it permission to execute sudo chmod +x /usr/local/bin/gitlab-runner # Create a GitLab Runner user sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash # Install and run as a service sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start


Artık New project runner düğmesine tıklayarak kullanıcı arayüzü aracılığıyla koşucunun kendisini oluşturabiliriz.


Yeni koşucu oluştur


Her koşucunun bir platformu, mavi renkte görünen etiketleri ve diğer çalışma zamanı yapılandırmaları olabilir. Programdan komut çalıştırma olasılığını ayarlamamız gerektiğinde etiketler kullanışlı oluyor. Şimdilik diğer hiçbir şeyle ilgilenmiyoruz.


Koşucuyu oluşturduktan sonra


Create runner tıkladıktan sonra yapmanız gereken tek şey koşucunuzu kaydettirmek.


 # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU


Sıvı baz

Liquibase , veritabanı geçişlerini yönetmek için ücretsiz ve açık kaynaklı bir platformdur. Özet olarak Liquibase, değişiklik kümesi dosyalarını kullanarak toplama ve geri alma prosedürlerini tanımlamanıza olanak tanır. Komut dosyalarının kendisi geleneksel SQL komutlarının yanı sıra veritabanınıza göre uyarlanmış bir komut dosyasına dönüştürülecek veritabanından bağımsız değişiklik açıklamaları da olabilir. Desteklenen veritabanlarının listesine buradan ulaşabilirsiniz .


Size bir Spring uygulamasında geçiş gerçekleştirmenin bir yolunu göstereceğim. Bu, tüm değişiklik setlerinin yürütülmesini ayrı bir adım olarak kontrol edebilmeniz için gereklidir.

Proje

Hızlı bir şekilde Spring uygulaması geliştirmek için buraya gidin .


Bahar Başlatma


Şimdi hızlı bir şekilde application.yml. Etkin ve değişiklik günlüğü seçeneklerine özellikle dikkat edilmelidir. İlk seçenek Liquibase'i uygulama düzeyinde etkinleştirir ve devre dışı bırakır, ikincisi ise değişiklik günlüğünün yolunu belirler.


 server: port: 80 spring: datasource: username: ${DB_USERNAME} password: ${DB_PASSWORD} url: ${DB_HOST} liquibase: enabled: true change-log: classpath:db/changelog/db.changelog-master.xml


Değişkenlerle ne yapmalı?

Bunları GitLab'a koymak iyi bir uygulamadır; bu, geliştirme/prod standları arasında uygulamanın esnek bir şekilde özelleştirilmesine yardımcı olacaktır.


GitLab'daki değişkenler


Projemizde Kubernetes kullanıyoruz ve bu parametrelerin, çeşitli şemalar için önceden yapılandırılmış değer dosyalarını kullanarak uygulamayı oluştururken ekiplerin kendileri tarafından ayarlanması gerekiyor.



 env: - name: SPRING_PROFILES_ACTIVE value: "dev" - name: DB_HOST value: "jdbc:postgresql://127.0.0.1:5436/your_db" - name: DB_USERNAME value: "user" - name: DB_PASSWORD value: "pass"



Özelleştirmeye geri dönelim. Hemen kullanıma hazır, tamamen kendi kendine yeten uygulamalar oluşturmak bence akıllıca bir uygulamadır. CI/CD'de ayrı bir aşama oluşturmak için bir geçiş dosyası oluşturalım. Farklı ekipler için farklı araçlar kullanabiliyoruz ve bu dosyayla geçiş sistemiyle sınırlı kalmıyoruz.


 #!/bin/sh cd /opt/app /opt/app/liquibase \ --changeLogFile=./db/changelog/changelog-master.xml \ --url="$DB_HOST" \ --username="$DB_USERNAME" \ --password="$DB_PASSWORD" \ --logLevel=info \ --headless=true \ update



Mümkün olan tüm komutları Liquibase belgelerinde bulabilirsiniz. Artık sadece update ihtiyacımız var, bu da changelog-master.xml dosyasından güncel sürüme güncelleme yapmamızı sağlıyor.

Bir sonraki adım, proje kökünde CI/CD sürecine nasıl devam edileceğine ilişkin talimatları içeren bir.gitlab-ci.yml dosyası oluşturmaktır.


İlk olarak, projede ci/lint göreceli yolunda bulunabilen gitlab-ci.yml dosyası için yerleşik bağlayıcıya dikkat çekmek istiyorum. Yapılandırmayı kabartmadan önce kullanmanızı öneririm. Ayrıca YAML dosyalarıyla nasıl çalışılacağını bildiğiniz varsayılmaktadır.

Aşamalar ve işler

 stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev

migration etiketi, daha önce oluşturduğumuz runnerımıza bu göreve tepki vermesi ve script bölümündeki scriptleri çalıştırması talimatını verir. stage dizesi bu işin ait olduğu aşamayı tanımlar. Gerektiğinde aynı koşucu aynı anda birden fazla proje üzerinde çalışabilir. Çevre bloğu çevreyi ifade eder. Bu, standlarınızın durumunu (geliştirme, ön üretim, üretim vb.) görüntüleyebileceğiniz ve manuel dağıtımlar gibi eylemler gerçekleştirebileceğiniz bir tür kontrol panelidir. Ek olarak ortama bağlı değişkenler de yapılandırılabilir; ancak bu premium özelliği test etme şansım olmadı.


Hatalı önlemlerin reddedilmesi

Ayarlar birleştirme istekleri


Dağıtım prosedüründe bir sorun olması durumunda ilgili birleştirmeyi durdurabilirsiniz. Özellikle testler CI/CD'ye bağımsız bir aşama olarak entegre edilirse bu yararlı olur. Örneğimizde Liquibase'in testleri olmasa da örneğin yanlış dosya yolları girilirse arızalanabilir.


CI/CD yapılandırıldıktan sonra onay kutusu işaretlenmezse tüm birleştirmelere izin verilmeyecektir.


Son dokunuşlar

Proje


Bir geçiş dosyası oluşturalım ve etkinleştirelim. Bunu yapmak için changelog-master.xml dosyasını giriş noktası olarak oluşturmamız gerekiyor.


Daha esnek bir yönetim için birden fazla changelog.xml dosyasına sahip olmak iyi bir uygulamadır. Onlardan bir değişiklik günlüğü hiyerarşisi oluşturabilirsiniz. Ancak örneğimizde daha basit bir yol kullanacağız.


 <?xml version="1.1" encoding="UTF-8" standalone="no"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:pro="http://www.liquibase.org/xml/ns/pro" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/pro http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd"> <include file="db/changelog/changeset-202310151300-create-table.sql"/> </databaseChangeLog>


Geçişleri tarih ve saat kullanarak adlandırmak iyi bir uygulamadır. Bu, büyük bir geliştirme ekibi aynı anda çalışırken geçiş sıralamasının bozulmasını önleyecektir.


 --liquibase formatted sql --changeset a.tyryshkin:create-table create table if not exists table ( id bigserial primary key, name varchar(255) ); create sequence if not exists table_id_seq;


Geçişleri tanımlamak için farklı XML, YAML veya JSON formatlarını kullanabilirsiniz, ancak SQL benim zevkime göre okunması en kolay formattır.


Boru hattı


Yürütmeye çalışıyoruz ve her şey başarılı oluyor. Veritabanımızı kontrol edin ve veritabanı değişikliği günlüğündeki girişi görün.



Veritabanındaki satır


Çözüm

Bu makalede GitLab'ı kendiniz nasıl dağıtacağınızı, çalıştırıcıları nasıl indirip yapılandıracağınızı ve en önemlisi bir veritabanı geçiş sistemini CI/CD sürecinize nasıl entegre edeceğinizi tartıştık. Bu kılavuzun, bu kılavuzu eyleme geçirmenize yardımcı olacağını umuyorum.