🥇ओपनशिफ्ट पर आधुनिक अनुप्रयोग, भाग 2: जंजीर निर्मित

नमस्ते! यह हमारी श्रृंखला की दूसरी पोस्ट है जिसमें हम दिखाते हैं कि Red Hat OpenShift पर आधुनिक वेब एप्लिकेशन कैसे तैनात करें।

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

स्वच्छ बिल्डर छवि

जैसा कि हमने भाग XNUMX में उल्लेख किया है, अधिकांश आधुनिक वेब अनुप्रयोगों में एक तथाकथित बिल्ड चरण होता है, जो आम तौर पर कोड ट्रांसपिलेशन, मल्टीपल फ़ाइल कॉन्सटेनेशन और मिनिमिफिकेशन जैसे ऑपरेशन करता है। इन परिचालनों के परिणामस्वरूप प्राप्त फ़ाइलें - और ये स्थिर HTML, जावास्क्रिप्ट और सीएसएस हैं - आउटपुट फ़ोल्डर में संग्रहीत की जाती हैं। इस फ़ोल्डर का स्थान आमतौर पर इस बात पर निर्भर करता है कि कौन से बिल्ड टूल का उपयोग किया जा रहा है, और रिएक्ट के लिए यह ./build फ़ोल्डर होगा (हम इस पर नीचे अधिक विस्तार से वापस आएंगे)।

स्रोत-से-छवि (S2I)

इस पोस्ट में हम "S2I क्या है और इसका उपयोग कैसे करें" विषय पर बात नहीं कर रहे हैं (आप इसके बारे में अधिक पढ़ सकते हैं यहां), लेकिन वेब ऐप बिल्डर छवि क्या करती है, यह समझने के लिए इस प्रक्रिया के दो चरणों के बारे में स्पष्ट होना महत्वपूर्ण है।

विधानसभा चरण

असेंबली चरण प्रकृति में बहुत समान है जब आप डॉकर बिल्ड चलाते हैं और एक नई डॉकर छवि के साथ समाप्त होते हैं। तदनुसार, यह चरण ओपनशिफ्ट प्लेटफॉर्म पर निर्माण शुरू करते समय होता है।

वेब ऐप बिल्डर छवि के मामले में, यह आपके एप्लिकेशन की निर्भरता स्थापित करने और बिल्ड चलाने के लिए ज़िम्मेदार है। स्क्रिप्ट इकट्ठा करें. डिफ़ॉल्ट रूप से, बिल्डर छवि npm रन बिल्ड निर्माण का उपयोग करती है, लेकिन इसे NPM_BUILD पर्यावरण चर के माध्यम से ओवरराइड किया जा सकता है।

जैसा कि हमने पहले कहा, तैयार, पहले से निर्मित एप्लिकेशन का स्थान इस बात पर निर्भर करता है कि आप कौन से टूल का उपयोग करते हैं। उदाहरण के लिए, रिएक्ट के मामले में यह ./build फ़ोल्डर होगा, और Angular अनुप्रयोगों के लिए यह project_name/dist फ़ोल्डर होगा। और, जैसा कि पिछली पोस्ट में दिखाया गया है, आउटपुट निर्देशिका का स्थान, जो डिफ़ॉल्ट रूप से निर्माण के लिए सेट है, को OUTPUT_DIR पर्यावरण चर के माध्यम से ओवरराइड किया जा सकता है। खैर, चूंकि आउटपुट फ़ोल्डर का स्थान फ्रेमवर्क से फ्रेमवर्क में भिन्न होता है, आप बस जेनरेट किए गए आउटपुट को छवि में मानक फ़ोल्डर में कॉपी करते हैं, अर्थात् /opt/apt-root/output। इस लेख के बाकी हिस्सों को समझने के लिए यह महत्वपूर्ण है, लेकिन अभी आइए अगले चरण - रन चरण पर नज़र डालें।

चरण चलाएँ

यह चरण तब होता है जब असेंबली चरण के दौरान बनाई गई नई छवि पर डॉकर रन के लिए कॉल की जाती है। ओपनशिफ्ट प्लेटफ़ॉर्म पर तैनात करते समय भी ऐसा ही होता है। गलती करना स्क्रिप्ट चलाएँ का उपयोग करता है सर्व मॉड्यूल उपरोक्त मानक आउटपुट निर्देशिका में स्थित स्थिर सामग्री परोसने के लिए।

यह विधि अनुप्रयोगों को शीघ्रता से तैनात करने के लिए अच्छी है, लेकिन आम तौर पर इस तरह से स्थिर सामग्री परोसने की अनुशंसा नहीं की जाती है। खैर, चूँकि वास्तव में हम केवल स्थिर सामग्री परोसते हैं, हमें अपनी छवि के अंदर Node.js स्थापित करने की आवश्यकता नहीं है - एक वेब सर्वर पर्याप्त होगा।

दूसरे शब्दों में, संयोजन करते समय हमें एक चीज़ की आवश्यकता होती है, निष्पादित करते समय हमें दूसरी चीज़ की आवश्यकता होती है। इस स्थिति में, जंजीरदार निर्माण काम में आते हैं।

जंजीरदार निर्माण

वे इसी बारे में लिखते हैं जंजीरदार निर्माण ओपनशिफ्ट दस्तावेज़ में:

"दो असेंबली को एक साथ जोड़ा जा सकता है, जिसमें एक संकलित इकाई उत्पन्न करता है और दूसरा उस इकाई को एक अलग छवि में होस्ट करता है जिसका उपयोग उस इकाई को चलाने के लिए किया जाता है।"

दूसरे शब्दों में, हम अपने निर्माण को चलाने के लिए वेब ऐप बिल्डर छवि का उपयोग कर सकते हैं, और फिर अपनी सामग्री की सेवा के लिए वेब सर्वर छवि, उसी एनजीआईएनएक्स का उपयोग कर सकते हैं।

इस प्रकार, हम वेब ऐप बिल्डर छवि को "शुद्ध" बिल्डर के रूप में उपयोग कर सकते हैं और साथ ही एक छोटी रनटाइम छवि भी प्राप्त कर सकते हैं।

अब इसे एक विशिष्ट उदाहरण से देखते हैं।

प्रशिक्षण के लिए हम उपयोग करेंगे सरल प्रतिक्रिया आवेदन, create-react-app कमांड लाइन टूल का उपयोग करके बनाया गया।

इससे हमें सब कुछ एक साथ रखने में मदद मिलेगी ओपनशिफ्ट टेम्प्लेट फ़ाइल.

आइए इस फ़ाइल को अधिक विस्तार से देखें, और पैरामीटर अनुभाग से शुरू करें।

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: The source URL for the application
    displayName: Source URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: The branch name for the application
    displayName: Source Branch
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: The location within the source repo of the application
    displayName: Source Directory
    value: .
    required: true
  - name: OUTPUT_DIR
    description: The location of the compiled static files from your web apps builder
    displayName: Output Directory
    value: build
    required: false

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

आइए अब ImageStreams अनुभाग पर एक नज़र डालें।

- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-builder  // 1 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-runtime  // 2 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: web-app-builder-runtime // 3
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: nginx-image-runtime // 4
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: 'centos/nginx-112-centos7:latest'

तीसरी और चौथी छवि पर एक नज़र डालें। उन दोनों को डॉकर छवियों के रूप में परिभाषित किया गया है, और आप स्पष्ट रूप से देख सकते हैं कि वे कहाँ से आए हैं।

तीसरी छवि वेब-ऐप-बिल्डर है और यह nodeshift/ubi8-s2i-web-app से आती है जिसे 10.x पर टैग किया गया है डॉकटर हब.

चौथी नवीनतम टैग के साथ एक एनजीआईएनएक्स छवि (संस्करण 1.12) है डॉकटर हब.

अब आइए पहली दो छवियों को देखें। वे दोनों शुरुआत में खाली हैं और केवल निर्माण चरण के दौरान बनाए गए हैं। पहली छवि, प्रतिक्रिया-वेब-ऐप-बिल्डर, एक असेंबली चरण का परिणाम होगी जो वेब-ऐप-बिल्डर-रनटाइम छवि और हमारे स्रोत कोड को संयोजित करेगी। इसीलिए हमने इस छवि के नाम में "-बिल्डर" जोड़ा है।

दूसरी छवि - प्रतिक्रिया-वेब-ऐप-रनटाइम - nginx-image-runtime और प्रतिक्रिया-वेब-ऐप-बिल्डर छवि से कुछ फ़ाइलों के संयोजन का परिणाम होगी। इस छवि का उपयोग परिनियोजन के दौरान भी किया जाएगा और इसमें केवल हमारे एप्लिकेशन का वेब सर्वर और स्थिर HTML, जावास्क्रिप्ट, सीएसएस शामिल होगा।

अस्पष्ट? आइए अब बिल्ड कॉन्फ़िगरेशन पर एक नज़र डालें और यह थोड़ा स्पष्ट हो जाएगा।

हमारे टेम्पलेट में दो बिल्ड कॉन्फ़िगरेशन हैं। यहाँ पहला है, और यह काफी मानक है:

  apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-builder
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-builder:latest // 1
    source:   // 2 
      git:
        uri: ${SOURCE_REPOSITORY_URL}
        ref: ${SOURCE_REPOSITORY_REF}
      contextDir: ${SOURCE_REPOSITORY_DIR}
      type: Git
    strategy:
      sourceStrategy:
        env:
          - name: OUTPUT_DIR // 3 
            value: ${OUTPUT_DIR}
        from:
          kind: ImageStreamTag
          name: web-app-builder-runtime:latest // 4
        incremental: true // 5
      type: Source
    triggers: // 6
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - imageChange: {}
      type: ImageChange

जैसा कि आप देख सकते हैं, लेबल 1 वाली पंक्ति कहती है कि इस बिल्ड का परिणाम उसी प्रतिक्रिया-वेब-ऐप-बिल्डर छवि में रखा जाएगा जिसे हमने इमेजस्ट्रीम अनुभाग में कुछ समय पहले देखा था।

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

3 लेबल वाली लाइन वही है जो हम पैरामीटर अनुभाग में पहले ही देख चुके हैं। यह OUTPUT_DIR पर्यावरण चर जोड़ता है, जो हमारे उदाहरण में बिल्ड है।
4 लेबल वाली लाइन वेब-ऐप-बिल्डर-रनटाइम छवि का उपयोग करने के लिए कहती है, जिसे हम पहले ही इमेजस्ट्रीम अनुभाग में देख चुके हैं।

5 लेबल वाली लाइन कहती है कि हम एक वृद्धिशील बिल्ड का उपयोग करना चाहते हैं यदि S2I छवि इसका समर्थन करती है, और वेब ऐप बिल्डर छवि इसका समर्थन करती है। पहले लॉन्च पर, असेंबली चरण पूरा करने के बाद, छवि नोड_मॉड्यूल फ़ोल्डर को एक संग्रह फ़ाइल में सहेजेगी। फिर, बाद के रन पर, छवि निर्माण समय को कम करने के लिए इस फ़ोल्डर को आसानी से अनज़िप कर देगी।

और अंत में, 6 लेबल वाली लाइन कुछ बदलाव होने पर, मैन्युअल हस्तक्षेप के बिना, बिल्ड को स्वचालित रूप से चलाने के लिए बस कुछ ट्रिगर है।

कुल मिलाकर यह एक काफी मानक बिल्ड कॉन्फ़िगरेशन है।

अब आइए दूसरे बिल्ड कॉन्फ़िगरेशन पर एक नज़र डालें। यह पहले वाले के समान ही है, लेकिन एक महत्वपूर्ण अंतर है।

apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-runtime
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-runtime:latest // 1
    source: // 2
      type: Image
      images:                              
        - from:
            kind: ImageStreamTag
            name: react-web-app-builder:latest // 3
          paths:
            - sourcePath: /opt/app-root/output/.  // 4
              destinationDir: .  // 5
             
    strategy: // 6
      sourceStrategy:
        from:
          kind: ImageStreamTag
          name: nginx-image-runtime:latest
        incremental: true
      type: Source
    triggers:
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - type: ImageChange
      imageChange: {}
    - type: ImageChange
      imageChange:
        from:
          kind: ImageStreamTag
          name: react-web-app-builder:latest // 7

तो दूसरा बिल्ड कॉन्फ़िगरेशन प्रतिक्रिया-वेब-ऐप-रनटाइम है, और यह काफी मानक रूप से शुरू होता है।

1 लेबल वाली लाइन कोई नई बात नहीं है - यह बस इतना कहती है कि बिल्ड परिणाम प्रतिक्रिया-वेब-ऐप-रनटाइम छवि में डाल दिया गया है।

पिछले कॉन्फ़िगरेशन की तरह, 2 लेबल वाली लाइन इंगित करती है कि स्रोत कोड कहाँ से प्राप्त किया जाए। लेकिन ध्यान दें कि यहां हम यह कह रहे हैं कि यह तस्वीर से लिया गया है। इसके अलावा, उस छवि से जो हमने अभी बनाई है - प्रतिक्रिया-वेब-ऐप-बिल्डर से (3 लेबल वाली पंक्ति में दर्शाया गया है)। जिन फ़ाइलों का हम उपयोग करना चाहते हैं वे छवि के अंदर हैं और वहां उनका स्थान 4 लेबल वाली पंक्ति में सेट है, हमारे मामले में यह /opt/app-root/output/ है। यदि आपको याद हो, तो यह वह जगह है जहां हमारे एप्लिकेशन के निर्माण के परिणामों के आधार पर उत्पन्न फ़ाइलें संग्रहीत की जाती हैं।

लेबल 5 के साथ शब्द में निर्दिष्ट गंतव्य फ़ोल्डर केवल वर्तमान निर्देशिका है (यह सब, याद रखें, ओपनशिफ्ट नामक किसी जादुई चीज़ के अंदर चल रहा है, न कि आपके स्थानीय कंप्यूटर पर)।

रणनीति अनुभाग - 6 लेबल वाली पंक्ति - भी पहले बिल्ड कॉन्फ़िगरेशन के समान है। केवल इस बार हम nginx-image-runtime का उपयोग करने जा रहे हैं, जिसे हम पहले ही ImageStream अनुभाग में देख चुके हैं।

अंत में, 7 लेबल वाली लाइन ट्रिगर्स का एक अनुभाग है जो हर बार प्रतिक्रिया-वेब-ऐप-बिल्डर छवि में बदलाव होने पर इस बिल्ड को सक्रिय कर देगी।

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

अनुप्रयोग परिनियोजन

तो अब जब हमने टेम्पलेट देख लिया है, तो आइए देखें कि किसी एप्लिकेशन को तैनात करने के लिए इसका उपयोग कैसे करें।

हम अपने टेम्पलेट को तैनात करने के लिए oc नामक ओपनशिफ्ट क्लाइंट टूल का उपयोग कर सकते हैं:

$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f

$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app

ऊपर दिए गए स्क्रीनशॉट में पहला कमांड टेम्पलेट./openshiftio/application.yaml को खोजने का जानबूझकर इंजीनियरिंग तरीका है।

दूसरा कमांड बस इस टेम्पलेट के आधार पर एक नया एप्लिकेशन बनाता है।

इन आदेशों के काम करने के बाद, हम देखेंगे कि हमारे पास दो असेंबली हैं:

और अवलोकन स्क्रीन पर लौटते हुए, हम लॉन्च किए गए पॉड को देखेंगे:

लिंक पर क्लिक करें और हमें हमारे ऐप पर ले जाया जाएगा, जो कि डिफ़ॉल्ट रिएक्ट ऐप पेज है:

अनुपूरक 1

कोणीय प्रेमियों के लिए हमारे पास भी है उदाहरण आवेदन.

OUTPUT_DIR वेरिएबल को छोड़कर, यहां पैटर्न समान है।

अनुपूरक 2

इस लेख में हमने एनजीआईएनएक्स को एक वेब सर्वर के रूप में उपयोग किया है, लेकिन इसे अपाचे से बदलना काफी आसान है, बस फ़ाइल में टेम्पलेट बदलें एनजीआईएनएक्स छवि पर अपाचे छवि.

निष्कर्ष

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

लेखों की इस श्रृंखला की सामग्री

भाग 1: कुछ ही चरणों में आधुनिक वेब एप्लिकेशन कैसे तैनात करें;
भाग 2: उत्पादन परिनियोजन के लिए संबंधित ओपनशिफ्ट असेंबली का उपयोग करके मौजूदा HTTP सर्वर छवि, जैसे एनजीआईएनएक्स, के साथ एक नई एस2आई छवि का उपयोग कैसे करें;
भाग 3: ओपनशिफ्ट प्लेटफ़ॉर्म पर अपने एप्लिकेशन के लिए एक डेवलपमेंट सर्वर कैसे चलाएं और इसे स्थानीय फ़ाइल सिस्टम के साथ सिंक्रनाइज़ करें।

अतिरिक्त संसाधन

मुफ़्त ई-पुस्तक ओपनशिफ्ट पर तैनाती.
इस पर जानकारी ओपनशिफ्ट और कुबेरनेट्स.

स्रोत: www.habr.com

ओपनशिफ्ट पर आधुनिक अनुप्रयोग, भाग 2: जंजीर निर्मित