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. DevOps Yazma Yarışması'na 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. değişkenini oluşturmamız gerektiğini unutmamak önemlidir. $GITLAB_HOME 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. kullanılarak kayda gider, ancak yaklaşım mevcut yaklaşıma yakındır. 17.0'dan sonraki her şey RUNNER_AUTHENTICATION_TOKEN Ö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: https://docs.gitlab.com/runner/install/?embedable=true # 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 düğmesine tıklayarak kullanıcı arayüzü aracılığıyla koşucunun kendisini oluşturabiliriz. New project runner 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. tıkladıktan sonra yapmanız gereken tek şey koşucunuzu kaydettirmek. Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU Sıvı baz , 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. . Liquibase 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 Şimdi hızlı bir şekilde 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. application.yml. 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ı bulabilirsiniz. Artık sadece ihtiyacımız var, bu da changelog-master.xml dosyasından güncel sürüme güncelleme yapmamızı sağlıyor. Liquibase belgelerinde update 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 göreceli yolunda bulunabilen dosyası için ç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. ci/lint gitlab-ci.yml yerleşik bağlayıcıya dikkat 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 etiketi, daha önce oluşturduğumuz runnerımıza bu göreve tepki vermesi ve bölümündeki scriptleri çalıştırması talimatını verir. 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 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ı. migration script stage çevreyi 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. Son dokunuşlar Bir geçiş dosyası oluşturalım ve etkinleştirelim. Bunu yapmak için dosyasını giriş noktası olarak oluşturmamız gerekiyor. changelog-master.xml 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. Çö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.
