paint-brush
आपके सीआई/सीडी चरण पर सरल डेटाबेस माइग्रेशन स्क्रिप्टद्वारा@mindsky
6,693 रीडिंग
6,693 रीडिंग

आपके सीआई/सीडी चरण पर सरल डेटाबेस माइग्रेशन स्क्रिप्ट

द्वारा Aleksandr Tyryshkin6m2023/10/16
Read on Terminal Reader

बहुत लंबा; पढ़ने के लिए

मैंने DevOps लेखन प्रतियोगिता की कई प्रस्तुतियों में बहुत सारे उत्कृष्ट, उच्च-स्तरीय कार्य देखे हैं। हालाँकि, कुछ लोग इस बात पर विचार करते हैं कि हर दिन काम करते समय डेटाबेस को सामान्य स्टैंडबाय (डेवलपमेंट, स्टेज, प्रोडक्ट आदि) पर कैसे अपडेट रखा जाए। यह आलेख नौसिखिए डेवलपर्स के लिए है। मैंने सीआई/सीडी प्रक्रिया में डेटाबेस माइग्रेशन सिस्टम शुरू करने के लिए एक सरल तकनीक का प्रदर्शन करने के लिए एक उदाहरण के रूप में स्प्रिंग का उपयोग किया।
featured image - आपके सीआई/सीडी चरण पर सरल डेटाबेस माइग्रेशन स्क्रिप्ट
Aleksandr Tyryshkin HackerNoon profile picture
0-item
1-item

मैंने DevOps लेखन प्रतियोगिता की कई प्रस्तुतियों में बहुत सारे उत्कृष्ट, उच्च-स्तरीय कार्य देखे हैं। हालाँकि, कुछ लोग इस बात पर विचार करते हैं कि हर दिन काम करते समय डेटाबेस को सामान्य स्टैंडबाय (डेव, स्टेज, प्रोड, आदि) पर कैसे अपडेट रखा जाए। यह आलेख नौसिखिए डेवलपर्स के लिए है। मैंने सीआई/सीडी प्रक्रिया में डेटाबेस माइग्रेशन सिस्टम शुरू करने के लिए एक सरल तकनीक का प्रदर्शन करने के लिए एक उदाहरण के रूप में स्प्रिंग का उपयोग किया।

इस परिनियोजन के लिए हमें लिक्विबेस और गिटलैब सीआई/सीडी टूल की आवश्यकता होगी। फिलहाल मान लें कि डेटाबेस चालू है और चल रहा है। मैं PostgreSQL का उपयोग करूँगा।

गिटलैब सीआई/सीडी

यदि आपके पास पहले से ही GitLab तैनात है, तो आप इस चरण को पूरी तरह से छोड़ सकते हैं।


Gitlab को तैनात करने के लिए, हम Docker पद्धति का उपयोग करेंगे। यह ध्यान रखना महत्वपूर्ण है कि हमें $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


अगला कदम रनर्स को स्थापित और कॉन्फ़िगर करना है।


यदि आपके पास पहले से ही एक लंबे समय से चल रहा प्रोजेक्ट है और सब कुछ लंबे समय से सेट किया गया है, तो आप एक नया रनर बनाना छोड़ सकते हैं।


गिटलैब सीआई


मैं एक उदाहरण के रूप में संस्करण 16.4.1 का उपयोग करके एक धावक का निर्माण दिखाऊंगा। 17.0 के बाद कुछ भी RUNNER_AUTHENTICATION_TOKEN उपयोग करके पंजीकरण के लिए जाता है, लेकिन दृष्टिकोण वर्तमान के करीब है।


GitLab 17.0 से पहले प्रवाहित करें


GitLab 17.0 के बाद प्रवाह


सबसे पहले, आपको रनर स्रोत स्थापित करना होगा। इसे अपने तैनात GitLab पर बैश के माध्यम से स्थापित करने के लिए, यह उदाहरण मदद करता है कि आप Apple सिलिकॉन-आधारित सिस्टम के लिए रनर कैसे स्थापित कर सकते हैं (अन्य OS आप यहां पा सकते हैं):


 # 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


अब हम New project runner बटन पर क्लिक करके यूआई के माध्यम से स्वयं रनर बना सकते हैं।


नया धावक बनाएं


प्रत्येक धावक के पास एक प्लेटफ़ॉर्म, नीले रंग में दिखाई देने वाले टैग और अन्य रनटाइम कॉन्फ़िगरेशन हो सकते हैं। जब हमें प्रोग्राम से कमांड चलाने की संभावना निर्धारित करने की आवश्यकता होती है, तो टैग काम में आते हैं। फ़िलहाल, हमें बाकी सभी चीज़ों में कोई दिलचस्पी नहीं है।


धावक बनाने के बाद


Create runner पर क्लिक करने के बाद, केवल अपने रनर को पंजीकृत करना बाकी है।


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


लिक्विबेस

लिक्विबेस डेटाबेस माइग्रेशन के प्रबंधन के लिए एक स्वतंत्र और ओपन-सोर्स प्लेटफॉर्म है। संक्षेप में, लिक्विबेस आपको चेंजसेट फ़ाइलों का उपयोग करके रोलअप और रोलबैक प्रक्रियाओं का वर्णन करने की अनुमति देता है। स्क्रिप्ट स्वयं पारंपरिक SQL कमांड के साथ-साथ संशोधनों के डेटाबेस-स्वतंत्र विवरण भी हो सकते हैं जिन्हें आपके डेटाबेस के अनुरूप स्क्रिप्ट में बदल दिया जाएगा। समर्थित डेटाबेस की सूची यहां उपलब्ध है


मैं आपको स्प्रिंग एप्लिकेशन में माइग्रेशन करने का एक तरीका दिखाऊंगा। यह आवश्यक है ताकि आप एक अलग चरण के रूप में सभी परिवर्तन सेटों के निष्पादन को नियंत्रित कर सकें।

परियोजना

स्प्रिंग एप्लिकेशन को शीघ्रता से विकसित करने के लिए, यहां जाएं


स्प्रिंग इनिशियलाइज़र


आइए अब जल्दी से 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


वेरिएबल्स के साथ क्या करें?

उन्हें GitLab में डालना अच्छा अभ्यास है, जो डेव/प्रोड स्टैंड के बीच एप्लिकेशन को लचीले ढंग से अनुकूलित करने में मदद करेगा।


GitLab में वेरिएबल


हम अपने प्रोजेक्ट में कुबेरनेट्स का उपयोग करते हैं, और इन मापदंडों को विभिन्न योजनाओं के लिए पूर्व-कॉन्फ़िगर किए गए मान फ़ाइलों का उपयोग करके एप्लिकेशन का निर्माण करते समय टीमों द्वारा स्वयं सेट किया जाना चाहिए।



 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"



आइए अनुकूलन पर वापस जाएं। मेरी राय में, पूरी तरह से आत्मनिर्भर ऐप्स बनाना जो तुरंत तैनाती के लिए तैयार हों, एक स्मार्ट अभ्यास है। सीआई/सीडी में एक अलग चरण बनाने के लिए, आइए एक माइग्रेट फ़ाइल बनाएं। हम अलग-अलग टीमों के लिए अलग-अलग टूल का उपयोग कर सकते हैं, और हम इस फ़ाइल के साथ माइग्रेशन सिस्टम तक ही सीमित नहीं हैं।


 #!/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



सभी संभावित कमांड लिक्विबेस दस्तावेज़ में पाए जा सकते हैं। अब हमें केवल update आवश्यकता है, जो हमें चेंजलॉग-मास्टर.xml फ़ाइल से वर्तमान संस्करण में अपडेट करने की अनुमति देता है।

अगला चरण प्रोजेक्ट रूट पर a.gitlab-ci.yml फ़ाइल बनाना है जिसमें CI/CD प्रक्रिया को आगे बढ़ाने के निर्देश शामिल हैं।


सबसे पहले, मैं gitlab-ci.yml फ़ाइल के लिए अंतर्निहित लिंकर पर ध्यान आकर्षित करना चाहूंगा, जो प्रोजेक्ट में सापेक्ष पथ ci/lint पर पाया जा सकता है। कॉन्फ़िगरेशन को फुलाने से पहले, मैं इसका उपयोग करने का सुझाव देता हूं। यह भी माना जाता है कि आप जानते हैं कि YAML फ़ाइलों के साथ कैसे काम करना है।

चरण और कार्य

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

migration टैग हमारे पहले से जेनरेट किए गए रनर को इस कार्य पर प्रतिक्रिया करने और script अनुभाग में स्क्रिप्ट चलाने का निर्देश देता है। stage स्ट्रिंग उस चरण की पहचान करती है जिससे यह कार्य संबंधित है। यदि आवश्यक हो, तो एक ही धावक एक साथ कई परियोजनाओं पर काम कर सकता है। पर्यावरण ब्लॉक पर्यावरण को संदर्भित करता है। यह एक प्रकार का डैशबोर्ड है जहां आप अपने स्टैंड (डेवलपमेंट, प्री-प्रोड, प्रोड इत्यादि) की स्थिति देख सकते हैं और मैन्युअल तैनाती जैसी कार्रवाई कर सकते हैं। इसके अतिरिक्त, पर्यावरण-बाध्य चर को कॉन्फ़िगर किया जा सकता है; हालाँकि, मुझे इस प्रीमियम सुविधा का परीक्षण करने का मौका नहीं मिला है।


त्रुटियों वाले उपायों की अस्वीकृति

सेटिंग्स मर्ज अनुरोध


यदि परिनियोजन प्रक्रिया में कुछ गलत हो जाता है तो आप संबंधित विलय को रोक सकते हैं। विशेष रूप से, यह तब सहायक होता है जब परीक्षणों को एक स्वतंत्र चरण के रूप में सीआई/सीडी में एकीकृत किया जाता है। हालाँकि हमारे उदाहरण में लिक्विबेस के परीक्षण नहीं हैं, उदाहरण के लिए, यदि गलत फ़ाइल पथ दर्ज किए जाते हैं तो यह ख़राब हो सकता है।


यदि सीआई/सीडी को कॉन्फ़िगर करने के बाद चेकबॉक्स पर टिक नहीं किया गया है तो सभी विलयों की अनुमति नहीं दी जाएगी।


अंतिम स्पर्श

परियोजना


आइए एक माइग्रेशन फ़ाइल बनाएं और इसे सक्षम करें। ऐसा करने के लिए हमें इनपुट बिंदु के रूप में changelog-master.xml फ़ाइल बनाने की आवश्यकता है।


अधिक लचीले प्रबंधन के लिए एकाधिक चेंजलॉग.एक्सएमएल रखना अच्छा अभ्यास है। आप उनसे चेंजलॉग पदानुक्रम बना सकते हैं। हालाँकि, हमारे उदाहरण में हम एक सरल तरीके का उपयोग करेंगे।


 <?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>


दिनांक और समय का उपयोग करके माइग्रेशन को नाम देना एक अच्छा अभ्यास है। जब एक बड़ी विकास टीम एक ही समय में काम कर रही हो तो इससे माइग्रेशन की छँटाई में बाधा उत्पन्न होने से बचा जा सकेगा।


 --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;


आप माइग्रेशन का वर्णन करने के लिए विभिन्न XML, YAML, या JSON प्रारूपों का उपयोग कर सकते हैं, लेकिन मेरी पसंद के अनुसार SQL पढ़ने में सबसे आसान है।


पाइपलाइन


हम अमल करने की कोशिश करते हैं और सब कुछ सफल होता है।' हमारे डेटाबेस की जाँच करें और डेटाबेसचेंजलॉग में प्रविष्टि देखें।



डेटाबेस में पंक्ति


निष्कर्ष

इस लेख में, हमने चर्चा की कि GitLab को स्वयं कैसे तैनात किया जाए, रनर्स को कैसे डाउनलोड और कॉन्फ़िगर किया जाए, और, सबसे महत्वपूर्ण बात, डेटाबेस माइग्रेशन सिस्टम को अपनी CI/CD प्रक्रिया में एकीकृत किया जाए। मुझे आशा है कि यह मार्गदर्शिका इस मार्गदर्शिका को क्रियान्वित करने में आपकी सहायता करेगी।