मैंने की कई प्रस्तुतियों में बहुत सारे उत्कृष्ट, उच्च-स्तरीय कार्य देखे हैं। हालाँकि, कुछ लोग इस बात पर विचार करते हैं कि हर दिन काम करते समय डेटाबेस को सामान्य स्टैंडबाय (डेव, स्टेज, प्रोड, आदि) पर कैसे अपडेट रखा जाए। यह आलेख नौसिखिए डेवलपर्स के लिए है। मैंने सीआई/सीडी प्रक्रिया में डेटाबेस माइग्रेशन सिस्टम शुरू करने के लिए एक सरल तकनीक का प्रदर्शन करने के लिए एक उदाहरण के रूप में स्प्रिंग का उपयोग किया। 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 पर बैश के माध्यम से स्थापित करने के लिए, यह उदाहरण मदद करता है कि आप Apple सिलिकॉन-आधारित सिस्टम के लिए रनर कैसे स्थापित कर सकते हैं (अन्य OS आप यहां पा सकते हैं): 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 अब हम बटन पर क्लिक करके यूआई के माध्यम से स्वयं रनर बना सकते हैं। 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 में डालना अच्छा अभ्यास है, जो डेव/प्रोड स्टैंड के बीच एप्लिकेशन को लचीले ढंग से अनुकूलित करने में मदद करेगा। हम अपने प्रोजेक्ट में कुबेरनेट्स का उपयोग करते हैं, और इन मापदंडों को विभिन्न योजनाओं के लिए पूर्व-कॉन्फ़िगर किए गए मान फ़ाइलों का उपयोग करके एप्लिकेशन का निर्माण करते समय टीमों द्वारा स्वयं सेट किया जाना चाहिए। 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 सभी संभावित कमांड में पाए जा सकते हैं। अब हमें केवल आवश्यकता है, जो हमें चेंजलॉग-मास्टर.xml फ़ाइल से वर्तमान संस्करण में अपडेट करने की अनुमति देता है। लिक्विबेस दस्तावेज़ update अगला चरण प्रोजेक्ट रूट पर a.gitlab-ci.yml फ़ाइल बनाना है जिसमें CI/CD प्रक्रिया को आगे बढ़ाने के निर्देश शामिल हैं। सबसे पहले, मैं फ़ाइल के लिए आकर्षित करना चाहूंगा, जो प्रोजेक्ट में सापेक्ष पथ पर पाया जा सकता है। कॉन्फ़िगरेशन को फुलाने से पहले, मैं इसका उपयोग करने का सुझाव देता हूं। यह भी माना जाता है कि आप जानते हैं कि YAML फ़ाइलों के साथ कैसे काम करना है। gitlab-ci.yml अंतर्निहित लिंकर पर ध्यान ci/lint चरण और कार्य 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 प्रक्रिया में एकीकृत किया जाए। मुझे आशा है कि यह मार्गदर्शिका इस मार्गदर्शिका को क्रियान्वित करने में आपकी सहायता करेगी।
