OpenShift मा आधुनिक अनुप्रयोगहरू, भाग 2: चेन बिल्डहरू

नमस्ते सबै! यो हाम्रो शृङ्खलाको दोस्रो पोष्ट हो जसमा हामीले Red Hat OpenShift मा आधुनिक वेब अनुप्रयोगहरू कसरी डिप्लोय गर्ने भनेर देखाउँछौं।

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

सफा बिल्डर छवि

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

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

यस पोष्टमा हामी "S2I के हो र यसलाई कसरी प्रयोग गर्ने" शीर्षकमा छुँदैनौं (तपाईं यसको बारेमा थप पढ्न सक्नुहुन्छ। यहाँ), तर वेब एप निर्माणकर्ता छविले के गर्छ भनेर बुझ्नको लागि यस प्रक्रियाका दुई चरणहरूबारे स्पष्ट हुनु महत्त्वपूर्ण छ।

विधानसभा चरण

असेंबली चरण प्रकृतिमा धेरै मिल्दोजुल्दो छ जब तपाइँ डकर बिल्ड चलाउनुहुन्छ र नयाँ डकर छविको साथ समाप्त हुन्छ। तदनुसार, यो चरण OpenShift प्लेटफर्ममा निर्माण सुरु गर्दा हुन्छ।

वेब एप निर्माणकर्ता छविको मामलामा, यो तपाईंको अनुप्रयोगको निर्भरताहरू स्थापना गर्न र निर्माण चलाउन जिम्मेवार छ। लिपि जम्मा गर्नुहोस्। पूर्वनिर्धारित रूपमा, निर्माणकर्ता छविले npm रन निर्माण निर्माण प्रयोग गर्दछ, तर यसलाई NPM_BUILD वातावरण चर मार्फत ओभरराइड गर्न सकिन्छ।

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

रन चरण

यो चरण तब हुन्छ जब डकर रन कल गर्न को लागी विधानसभा चरण को समयमा सिर्जना गरिएको नयाँ छवि मा बनाइन्छ। OpenShift प्लेटफर्ममा डिप्लोइ गर्दा त्यस्तै हुन्छ। पूर्वनिर्धारित लिपि चलाउनुहोस् उपयोगहरु सेवा मोड्युल माथिको मानक आउटपुट डाइरेक्टरीमा अवस्थित स्थिर सामग्री सेवा गर्न।

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

अर्को शब्दमा, संयोजन गर्दा हामीलाई एउटा चीज चाहिन्छ, कार्यान्वयन गर्दा हामीलाई अर्को चाहिन्छ। यस अवस्थामा, जंजीर निर्माणहरू काममा आउँछन्।

जंजीर बनाउँछ

यिनै विषयमा लेख्छन् जंजीर निर्माणहरू OpenShift कागजातमा:

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

अर्को शब्दमा, हामी हाम्रो निर्माण चलाउनको लागि वेब एप बिल्डर छवि प्रयोग गर्न सक्छौं, र त्यसपछि हाम्रो सामग्री सेवा गर्न वेब सर्भर छवि, उही NGINX प्रयोग गर्न सक्छौं।

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

अब यसलाई विशेष उदाहरणको साथ हेरौं।

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

यसले हामीलाई सबै कुरा मिलाउन मद्दत गर्नेछ OpenShift टेम्प्लेट फाइल.

यस फाइललाई थप विवरणमा हेरौं, र प्यारामिटरहरू खण्डसँग सुरु गरौं।

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 प्यारामिटरमा ध्यान दिन लायक छ। हाम्रो उदाहरणमा प्रतिक्रिया एप्लिकेसनको लागि, चिन्ता लिनु पर्ने कुनै कुरा छैन, किनकि प्रतिक्रियाले पूर्वनिर्धारित मानलाई आउटपुट फोल्डरको रूपमा प्रयोग गर्दछ, तर Angular वा अन्य चीजको मामलामा, यो प्यारामिटर आवश्यक रूपमा परिवर्तन गर्न आवश्यक हुनेछ।

अब 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 मा ट्याग गरिएको छ। डकर हब.

चौथो NGINX छवि (संस्करण 1.12) पछिल्लो ट्यागको साथ हो डकर हब.

अब पहिलो दुई तस्बिर हेरौं। तिनीहरू दुवै सुरुमा खाली छन् र निर्माण चरणको समयमा मात्र सिर्जना गरिन्छ। पहिलो छवि, react-web-app-builder, वेब-एप-बिल्डर-रनटाइम छवि र हाम्रो स्रोत कोडलाई संयोजन गर्ने एसेम्बली चरणको परिणाम हुनेछ। त्यसकारण हामीले यो छविको नाममा "-builder" थप्यौं।

दोस्रो छवि - react-web-app-runtime - nginx-image-runtime र react-web-app-builder छविबाट केही फाइलहरू संयोजनको परिणाम हुनेछ। यो छवि पनि डिप्लोइमेन्टको समयमा प्रयोग गरिनेछ र वेब सर्भर र स्थिर HTML, JavaScript, हाम्रो अनुप्रयोगको CSS मात्र समावेश हुनेछ।

भ्रमित? अब निर्माण कन्फिगरेसनहरू हेरौं र यो अलि स्पष्ट हुनेछ।

हाम्रो टेम्प्लेटमा दुईवटा निर्माण कन्फिगरेसनहरू छन्। यहाँ पहिलो छ, र यो राम्रो मानक छ:

  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 को साथ लाइनले भन्छ कि यस निर्माणको नतिजा उही प्रतिक्रिया-वेब-एप-बिल्डर छविमा राखिनेछ जुन हामीले ImageStreams सेक्सनमा अलि पहिले देख्यौं।

2 लेबल गरिएको रेखाले तपाईंलाई कोड कहाँबाट प्राप्त गर्ने भनेर बताउँछ। हाम्रो अवस्थामा, यो एक git भण्डार हो, र स्थान, रेफ र सन्दर्भ फोल्डर हामीले पहिले नै माथि देखेका प्यारामिटरहरू द्वारा निर्धारण गरिन्छ।

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

Line लेबल गरिएको 5 भन्छ कि यदि S2I छविले यसलाई समर्थन गर्दछ भने हामी वृद्धिशील निर्माण प्रयोग गर्न चाहन्छौं, र वेब एप बिल्डर छविले गर्छ। पहिलो प्रक्षेपणमा, विधानसभा चरण पूरा भएपछि, छविले node_modules फोल्डरलाई अभिलेख फाइलमा बचत गर्नेछ। त्यसपछि, पछिको रनहरूमा, छविले निर्माण समय कम गर्न यो फोल्डरलाई अनजिप गर्नेछ।

र अन्तमा, 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 को साथ शब्दमा निर्दिष्ट गरिएको गन्तव्य फोल्डर केवल हालको डाइरेक्टरी हो (यो सबै हो, याद गर्नुहोस्, केहि जादुई चीज भित्र चलिरहेको छ जुन OpenShift भनिन्छ, र तपाईंको स्थानीय कम्प्युटरमा होइन)।

रणनीति खण्ड - रेखा लेबल 6 - पनि पहिलो निर्माण कन्फिगरेसन जस्तै छ। केवल यस पटक हामी nginx-image-runtime प्रयोग गर्न जाँदैछौं, जुन हामीले पहिले नै ImageStream सेक्सनमा देख्यौं।

अन्तमा, 7 लेबल गरिएको रेखा ट्रिगरहरूको खण्ड हो जसले प्रत्येक पटक प्रतिक्रिया-वेब-एप-बिल्डर छवि परिवर्तन गर्दा यो निर्माण सक्रिय गर्दछ।

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

आवेदन परिनियोजन

त्यसोभए अब हामीले टेम्प्लेट हेरेका छौं, यसलाई कसरी प्रयोग गर्ने एप्लिकेसन प्रयोग गर्ने हेरौं।

हामी हाम्रो टेम्प्लेट डिप्लोय गर्नको लागि oc भनिने OpenShift क्लाइन्ट उपकरण प्रयोग गर्न सक्छौं:

$ 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।

दोस्रो आदेशले यस टेम्प्लेटमा आधारित नयाँ अनुप्रयोग सिर्जना गर्दछ।

यी आदेशहरूले काम गरेपछि, हामी देख्नेछौं कि हामीसँग दुईवटा सम्मेलनहरू छन्:

र सिंहावलोकन स्क्रिनमा फर्केर, हामी सुरु गरिएको पोड देख्नेछौं:

लिङ्क क्लिक गर्नुहोस् र हामीलाई हाम्रो एपमा लगिनेछ, जुन पूर्वनिर्धारित प्रतिक्रिया एप पृष्ठ हो:

पूरक २०२०

Angular प्रेमीहरूको लागि हामीसँग पनि छ उदाहरण आवेदन.

यहाँ ढाँचा उस्तै छ, OUTPUT_DIR चर बाहेक।

पूरक २०२०

यस लेखमा हामीले NGINX लाई वेब सर्भरको रूपमा प्रयोग गर्यौं, तर यसलाई Apache सँग बदल्न सजिलो छ, फाइलमा टेम्प्लेट परिवर्तन गर्नुहोस्। NGINX छवि मा Apache छवि.

निष्कर्षमा

यस शृङ्खलाको पहिलो भागमा, हामीले OpenShift प्लेटफर्ममा आधुनिक वेब अनुप्रयोगहरू कसरी द्रुत रूपमा डिप्लोय गर्ने भनेर देखायौं। आज हामीले वेब एप छविले के गर्छ र यसलाई थप उत्पादन-तयार एप्लिकेसन निर्माण सिर्जना गर्न चेन बिल्डहरू प्रयोग गरेर NGINX जस्ता शुद्ध वेब सर्भरसँग कसरी जोड्न सकिन्छ भनेर हेर्यौं। यस शृङ्खलाको अर्को र अन्तिम लेखमा, हामी कसरी OpenShift मा तपाईंको अनुप्रयोगको लागि विकास सर्भर चलाउने र स्थानीय र रिमोट फाइलहरूको सिङ्क्रोनाइजेसन सुनिश्चित गर्ने देखाउनेछौं।

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

• भाग 1: केवल केहि चरणहरूमा आधुनिक वेब अनुप्रयोगहरू कसरी तैनात गर्ने;
• भाग २: कसरी नयाँ S2I छवि प्रयोग गर्ने विद्यमान HTTP सर्भर छविको साथ, जस्तै NGINX, उत्पादन परिनियोजनको लागि सम्बन्धित OpenShift सभाहरू प्रयोग गरेर;
• भाग 3: OpenShift प्लेटफर्ममा तपाइँको अनुप्रयोगको लागि विकास सर्भर कसरी चलाउने र यसलाई स्थानीय फाइल प्रणालीसँग सिङ्क्रोनाइज गर्ने।

अतिरिक्त स्रोतहरू

• नि: शुल्क ई-पुस्तक OpenShift मा तैनात गर्दै.
• मा जानकारी OpenShift र Kubernetes.

स्रोत: www.habr.com