प्रेरणा और परिचय
बिल्ड पूर्वावलोकन कुछ भी नया या अभिनव नहीं है। हरोकू उनके पास वर्षों से था। हालाँकि, यदि आप Google क्लाउड प्लेटफ़ॉर्म पर निर्माण कर रहे हैं, तो चीज़ें थोड़ी अधिक कठिन हैं। Google क्लाउड बिल्ड का उपयोग क्लाउड फ़ंक्शंस, क्लाउड रन, कुबेरनेट्स, ऐप इंजन आदि में परिनियोजन के लिए किया जा सकता है। यह वह है जो पूर्वावलोकन को थोड़ा जटिल बनाता है, क्योंकि क्लाउड बिल्ड को यह नहीं पता होता है कि आप अपने एप्लिकेशन या सेवा को कहाँ परिनियोजित कर रहे हैं। उनके पास रिपॉजिटरी को जोड़ने और GitHub में बिल्ड स्थिति दिखाने के लिए एक GitHub ऐप है, लेकिन बस इतना ही। हेरोकू, वर्सेल या फ्लाई जैसे उत्पादों से कोई पूर्वावलोकन, टिप्पणी या कोई "सामान्य" सामान नहीं है।
क्लाउड बिल्ड से गिटहब पुल अनुरोध पर एक सरल HTTP अनुरोध के साथ टिप्पणी पोस्ट करने का एक "आसान" तरीका है। लेकिन जब आप GitHub Deployments API का उपयोग कर सकते हैं तो यह कितना आसान है।
इस एपीआई के साथ, आप वातावरण बना सकते हैं, प्रति पर्यावरण अलग-अलग चर रख सकते हैं और पुल अनुरोध पर सीधे निर्माण और परिनियोजन स्थिति दिखा सकते हैं। और एक बार आपके सीडी प्लेटफॉर्म पर परिनियोजन हो जाने के बाद, आप URL को परिनियोजन स्थिति में जोड़ सकते हैं। इस लेख में हम यही करने जा रहे हैं।
गिटहब परिनियोजन स्थिति
दोबारा, HTTP अनुरोधों के साथ सीधे Deployments API का उपयोग करके ऐसा करने का एक और तरीका है। हालांकि यह कभी-कभी मुश्किल हो सकता है और आपको GitHub के साथ प्रमाणित करने के लिए एक व्यक्तिगत एक्सेस टोकन को परिभाषित करने की आवश्यकता होगी। इसके बजाय, हमने एक छोटी Node.js सेवा को एक साथ रखने का फैसला किया, जो ऐप टोकन बनाने और डिप्लॉयमेंट एपीआई के साथ इंटरैक्ट करने के लिए GitHub ऐप्स का उपयोग करती है। यह परिनियोजन प्रक्रिया पर थोड़ा बेहतर नियंत्रण की अनुमति देता है।
अस्वीकरण
यह आलेख विशेष रूप से Google क्लाउड प्लेटफ़ॉर्म और गिटहब के लिए लिखा गया है। Google क्लाउड प्लेटफ़ॉर्म, Google क्लाउड बिल्ड और IAM अनुमतियों की बुनियादी समझ मान ली गई है।
आपके पास Google क्लाउड प्लेटफ़ॉर्म प्रोजेक्ट स्थापित होना चाहिए।
गिटहब नियोक्ता (नोड.जेएस और डॉकर)
GitHub Deployer एक छोटी Node.js सेवा है जो GitHub ऐप के साथ अधिकृत है और GitHub Deployments API के साथ इंटरैक्ट करती है। आदेश पूर्वनिर्धारित होते हैं और कुछ सूचनाओं को डॉकर छवि में निर्मित करने की आवश्यकता होती है, अन्यथा क्लाउड बिल्ड में रनटाइम कॉन्फ़िगरेशन बहुत जटिल हो जाएगा।
डॉकर छवि तैयार निर्मित नहीं है; आपको इसे स्वयं बनाना होगा और इसे अपनी रजिस्ट्री में धकेलना होगा। सबसे अच्छी जगह Google आर्टिफैक्ट रजिस्ट्री है जहां आपके एप्लिकेशन के लिए छवियों को भी संग्रहीत किया जाता है (कंटेनर रजिस्ट्री को हटा दिया गया है):
यदि पहले से नहीं किया गया है, तो एक आर्टिफैक्ट रजिस्ट्री रिपॉजिटरी बनाएं
एक GitHub ऐप बनाएं और इसे अपने संगठन में इंस्टॉल करें
आवश्यक अनुमतियाँ: 'पुल_अनुरोध', 'तैनाती', 'मेटाडेटा'
ऐप आईडी (ऐप सेटिंग स्क्रीन से), और ऐप इंस्टॉलेशन आईडी कॉपी करें ("कॉन्फ़िगर करें" पर क्लिक करने के बाद आपको यूआरएल में इंस्टॉलेशन आईडी मिल जाएगी। पता नहीं और कहां मिल सकती है)
एक निजी कुंजी बनाएं और डाउनलोड करें और इसे बेस 64 में बदलें (
base64 -i your.private-key.pem)
डॉकर छवि बनाएँ
क्लाउड बिल्ड amd64 पर चलता है, इसलिए हमें x86 प्लेटफॉर्म के लिए छवि बनाने के लिए buildx आवश्यकता है:
docker buildx build --platform linux/amd64 . -t us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer \
--build-arg GH_APP_ID=[GITHUB_APP_ID] \
--build-arg GH_APP_PRIVATE_KEY=[GITHUB_PRIVATE_KEY_BASE_64] \
--build-arg GH_APP_INSTALLATION_ID=[GITHUB_INSTALLATION_ID] \
--build-arg GH_OWNER=[GITHUB_ORG]
छवि को अपनी रजिस्ट्री में पुश करें:
docker push us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer
स्थानीय रूप से डॉकर छवि चलाएँ
docker run -it -e REPO_NAME=test -e REF=main -e ENVIRONMENT=test us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer:latest create
आवश्यक पर्यावरण चर:
-
REPO_NAME: रिपॉजिटरी का नाम आवश्यक है (उदाहरण के लिएgh-deployer) -
REF: तैनात करने के लिए शाखा, टैग या SHA की आवश्यकता होती है (उदाहरण के लिएmain) -
ENVIRONMENT: परिनियोजित करने के लिए पर्यावरण की आवश्यकता होती है (उदाहरणpreview) -
TRANSIENT_ENVIRONMENT: वैकल्पिक/झूठा अगरtrueपर सेट किया जाता है, तो परिनियोजन एक निश्चित समय के बाद हटा दिया जाएगा -
DESCRIPTION: वैकल्पिक परिनियोजन का विवरण
निम्नलिखित आदेश पहले तर्क के रूप में उपलब्ध हैं:
-
create- एक नया परिनियोजन बनाएँ -
pending- निर्माण लंबित है -
in_progress- निर्माण प्रगति पर है -
queued- निर्माण कतारबद्ध है -
success- तैनाती सफल रही -
error- कुछ गलत हो गया -
failure- परिनियोजन विफल रहा
क्लाउड बिल्ड के साथ विकल्प वर्तमान में थोड़े सीमित हैं। कोई pending स्थिति नहीं है क्योंकि प्रारंभिक परिनियोजन बनाने के लिए क्लाउड बिल्ड को प्रारंभ करने की आवश्यकता है। queued कोई मतलब नहीं है, इसलिए हमारे अपने सेटअप में, हम निम्नलिखित का उपयोग कर रहे हैं:
-
gh-deployer/createएक कमिट के लिए क्षणिक परिनियोजन बनाने के लिए -
pgh-deployer/ending - परिनियोजन के लिए डॉकर छवि बनाने के लिए कनिको बिल्ड चलाएँ
-
gh-deployer/in_progressनिर्माण पूरा होने के बाद और छवि तैनात होने से पहले - छवि तैनात होने के बाद
gh-deployer/success
फिर से, क्लाउड बिल्ड के साथ हम नहीं जानते कि परिनियोजन कहाँ होने जा रहा है, इसलिए परिनियोजन URL को success चरण में पास करने के दो तरीके हैं:
- निर्माण चरण में, URL को
/workspace/deployer_environment_urlमें लिखें -
successके बाद डॉकर छवि के लिए दूसरा तर्क पास करें
हम अपने परिनियोजन के लिए क्लाउड रन का उपयोग करते हैं, इसलिए किसी दिए गए पुल अनुरोध संख्या के लिए परिनियोजन URL को पुनः प्राप्त करने के लिए बिल्ड चरण यहां दिया गया है:
- नाम: gcr.io/google.com/cloudsdktool/cloud-sdk
env: - PR_NUMBER=$_PR_NUMBER script: >- gcloud run services list --project [project] --filter preview-$PR_NUMBER --format "value(status.address.url)" > /workspace/deployer_environment_urlक्लाउड बिल्ड कॉन्फ़िगरेशन / टेराफॉर्म
cloudbuild.yaml
यहाँ cloudbuild.yaml कॉन्फ़िगरेशन फ़ाइल का उपयोग करके एक पूर्ण उदाहरण दिया गया है। हम तैनाती लक्ष्य के रूप में निर्माण और क्लाउड रन के लिए कनिको का उपयोग करते हैं।
यदि आप टेराफॉर्म के साथ काम करते हैं, तो टेराफॉर्म फाइल भी उपलब्ध है: प्रीव्यू.टीएफ
गिटहब क्रियाएँ
परिनियोजन API का उपयोग करके, आप GitHub क्रियाएँ को deployment_status पर ट्रिगर कर सकते हैं। इससे प्रत्येक प्रीव्यू बिल्ड पर गुणवत्ता आश्वासन जांच, एंड-टू-एंड टेस्ट आदि चलाना आसान हो जाता है। यहां प्रत्येक पूर्वावलोकन पर Playwright चलाने के लिए एक उदाहरण दिया गया है, जिसमें environment_url का उपयोग किया गया है जो success स्थिति के लिए पारित किया गया है:
नाटककार-क्यूए:
if: ${{ github.event.deployment\_status.state == 'success' }} timeout-minutes: 60 runs-on: ubuntu\-latest steps: \- uses: actions/[\[email protected\]](/cdn-cgi/l/email-protection) \- uses: actions/setup\-[\[email protected\]](/cdn-cgi/l/email-protection) with: node-version: 20 cache: 'npm' \- run: npm ci \- name: Install Playwright Browsers run: npm exec playwright install \-\-with\-deps \-y \- name: Run Playwright tests run: pnpm exec playwright test env: BASE\_URL: ${{github.event.deployment\_status.environment\_url}} \- uses: actions/upload\-[\[email protected\]](/cdn-cgi/l/email-protection) if: always() with: name: playwright\-report path: playwright\-report/ retention-days: 30अनुकूलन
- मूल छवि
gcr.io/google.com/cloudsdktool/cloud-sdkअपेक्षाकृत बड़ी है। बिल्ड को गति देने के लिए आप क्लाउड रन घटकों के साथ अपनी स्वयं की छोटी gcloud छवि बना सकते हैं।
निष्कर्ष
गिटहब परिनियोजन स्थिति हो गई
गिटहब पुल अनुरोधों पर टिप्पणियां पहली बार में आसान होती हैं, लेकिन जब आपके पास प्रति पुल अनुरोध में एकाधिक तैनाती होती है, बिल्ड विफल हो जाती है आदि। वे बहुत अधिक लचीलापन प्रदान नहीं करते हैं और बनाए रखने/अपडेट करने में कठिन होते हैं। GitHub Deployments API किसी भी तृतीय पक्ष CI/CD सिस्टम से परिनियोजन बनाने और प्रबंधित करने का एक शानदार तरीका प्रदान करता है। GitHub Deployer के साथ हमने तैनाती एपीआई के साथ बातचीत को सुव्यवस्थित करने की कोशिश की और कुछ साइड इफेक्ट्स या नुकसान का ख्याल रखा जो कि केवल HTTP एपीआई के साथ हल करना असंभव है।
GitHub डिप्लॉयमेंट API का उपयोग करने का एक अन्य लाभ यह है कि आप GitHub क्रियाओं के लिए deployment_status ट्रिगर का उपयोग कर सकते हैं और सीधे ईवेंट पेलोड के साथ environment_url प्राप्त कर सकते हैं।
आप GitHub रिपॉजिटरी पर थोड़ा और विस्तृत इंस्टालेशन / बिल्ड निर्देश और सभी कोड पा सकते हैं
यदि आपका कोई प्रश्न या टिप्पणी है , तो कृपया ब्लूस्काई/ ट्विटर पर संपर्क करें या गिटहब पर चर्चा में शामिल हों ।
