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'ı 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.
Ö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.
Ö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.
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.
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
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.
Hızlı bir şekilde Spring uygulaması geliştirmek için buraya gidin .
Ş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.
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.
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
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.
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.
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.
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.