OpenShift वरील आधुनिक ऍप्लिकेशन्स, भाग 2: चेन बिल्ड्स

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

मागील पोस्टमध्ये, आम्ही नवीन S2I (स्रोत-टू-इमेज) बिल्डर इमेजच्या क्षमतांना किंचित स्पर्श केला, जे OpenShift प्लॅटफॉर्मवर आधुनिक वेब अनुप्रयोग तयार करण्यासाठी आणि तैनात करण्यासाठी डिझाइन केलेले आहे. मग आम्हाला एखादे ऍप्लिकेशन त्वरीत उपयोजित करण्याच्या विषयात रस होता आणि आज आम्ही S2I प्रतिमा “शुद्ध” बिल्डर इमेज म्हणून कशी वापरायची आणि ती संबंधित OpenShift असेंब्लीसह कशी जोडायची ते पाहू.

स्वच्छ बिल्डरची प्रतिमा

आम्ही भाग XNUMX मध्ये नमूद केल्याप्रमाणे, बहुतेक आधुनिक वेब ऍप्लिकेशन्समध्ये तथाकथित बिल्ड स्टेज असते, जे सामान्यत: कोड ट्रान्सपिलेशन, मल्टिपल फाईल एकत्रीकरण आणि मिनिफिकेशन यासारखे ऑपरेशन करते. या ऑपरेशन्सच्या परिणामी प्राप्त झालेल्या फायली - आणि हे स्थिर HTML, JavaScript आणि CSS - आउटपुट फोल्डरमध्ये संग्रहित केले जातात. या फोल्डरचे स्थान सहसा कोणती बिल्ड टूल्स वापरली जात आहेत यावर अवलंबून असते आणि प्रतिक्रियासाठी हे ./build फोल्डर असेल (आम्ही खाली अधिक तपशीलाने यावर परत येऊ).

सोर्स-टू-इमेज (S2I)

या पोस्टमध्ये आम्ही "S2I म्हणजे काय आणि ते कसे वापरावे" या विषयाला स्पर्श करत नाही (आपण याबद्दल अधिक वाचू शकता येथे), परंतु वेब अॅप बिल्डर प्रतिमा काय करते हे समजून घेण्यासाठी या प्रक्रियेतील दोन चरणांबद्दल स्पष्ट असणे महत्त्वाचे आहे.

विधानसभा टप्पा

जेव्हा तुम्ही डॉकर बिल्ड चालवता आणि नवीन डॉकर प्रतिमेसह समाप्त करता तेव्हा असेंब्लीचा टप्पा निसर्गात अगदी सारखाच असतो. त्यानुसार, OpenShift प्लॅटफॉर्मवर बिल्ड सुरू करताना हा टप्पा येतो.

वेब अॅप बिल्डर इमेजच्या बाबतीत, तुमच्या अॅप्लिकेशनचे अवलंबन स्थापित करण्यासाठी आणि बिल्ड चालवण्यासाठी ते जबाबदार आहे. स्क्रिप्ट एकत्र करा. डीफॉल्टनुसार, बिल्डर इमेज एनपीएम रन बिल्ड कंस्ट्रक्ट वापरते, परंतु हे NPM_BUILD पर्यावरण व्हेरिएबलद्वारे ओव्हरराइड केले जाऊ शकते.

आम्ही आधी म्हटल्याप्रमाणे, तयार केलेल्या, आधीच तयार केलेल्या अनुप्रयोगाचे स्थान आपण कोणती साधने वापरता यावर अवलंबून असते. उदाहरणार्थ, React च्या बाबतीत हे ./build फोल्डर असेल आणि अँगुलर ऍप्लिकेशन्ससाठी ते प्रोजेक्ट_नेम/डिस्ट फोल्डर असेल. आणि, आधीच्या पोस्टमध्ये दाखवल्याप्रमाणे, आउटपुट डिरेक्ट्रीचे स्थान, जे डीफॉल्टनुसार तयार केले जाते, ते 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 पॅरामीटरकडे लक्ष देणे योग्य आहे. आमच्या उदाहरणातील React ऍप्लिकेशनसाठी, काळजी करण्यासारखे काहीही नाही, कारण React आउटपुट फोल्डर म्हणून डिफॉल्ट मूल्य वापरते, परंतु Angular किंवा इतर कशाच्या बाबतीत, हे पॅरामीटर आवश्यकतेनुसार बदलणे आवश्यक आहे.

आता इमेजस्ट्रीम्स विभागात एक नजर टाकूया.

- 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, वेब-अॅप-बिल्डर-रनटाइम इमेज आणि आमचा सोर्स कोड एकत्र करणारी असेंबली पायरीचा परिणाम असेल. म्हणूनच आम्ही या प्रतिमेच्या नावात "-बिल्डर" जोडले आहे.

दुसरी प्रतिमा - 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 ची ओळ सांगते की या बिल्डचा परिणाम त्याच react-web-app-builder इमेजमध्ये ठेवला जाईल जी आम्ही इमेजस्ट्रीम्स विभागात थोड्या आधी पाहिली होती.

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

तर दुसरे बिल्ड कॉन्फिगरेशन म्हणजे react-web-app-runtime, आणि ते अगदी मानक सुरू होते.

1 लेबल केलेली ओळ काही नवीन नाही - ती फक्त असे म्हणते की बिल्ड परिणाम प्रतिक्रिया-वेब-अॅप-रनटाइम इमेजमध्ये ठेवला जातो.

मागील कॉन्फिगरेशन प्रमाणे 2 लेबल केलेली ओळ, स्त्रोत कोड कोठून मिळवायचा हे सूचित करते. पण लक्षात घ्या की इथे आम्ही म्हणत आहोत की ते प्रतिमेवरून घेतले आहे. शिवाय, आम्ही नुकत्याच तयार केलेल्या प्रतिमेतून - react-web-app-builder कडून (लेबल केलेल्या 3 मध्ये सूचित केलेले). आम्‍हाला वापरण्‍याच्‍या फाईल्‍स इमेजमध्‍ये आहेत आणि त्‍यांचे स्‍थान 4 लेबलच्‍या ओळीत सेट केले आहे, आमच्या बाबतीत ते /opt/app-root/output/ आहे. तुम्हाला आठवत असेल तर, आमचा अर्ज तयार करण्याच्या परिणामांवर आधारित व्युत्पन्न केलेल्या फाइल्स इथेच संग्रहित केल्या जातात.

लेबल 5 सह टर्ममध्ये निर्दिष्ट केलेले गंतव्य फोल्डर फक्त वर्तमान निर्देशिका आहे (हे सर्व आहे, लक्षात ठेवा, ओपनशिफ्ट नावाच्या जादुई गोष्टीमध्ये चालत आहे, आणि तुमच्या स्थानिक संगणकावर नाही).

स्ट्रॅटेजी विभाग – 6 लेबल असलेली लाइन – देखील पहिल्या बिल्ड कॉन्फिगरेशन प्रमाणेच आहे. फक्त यावेळी आम्ही nginx-image-runtime वापरणार आहोत, जे आम्ही इमेजस्ट्रीम विभागात आधीच पाहिले आहे.

शेवटी, 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.

दुसरी कमांड या टेम्प्लेटवर आधारित एक नवीन ऍप्लिकेशन तयार करते.

या आज्ञा कार्य केल्यानंतर, आम्ही पाहू की आमच्याकडे दोन असेंब्ली आहेत:

आणि विहंगावलोकन स्क्रीनवर परत आल्यावर, आम्ही लॉन्च केलेला पॉड पाहू:

दुव्यावर क्लिक करा आणि आम्हाला आमच्या अॅपवर नेले जाईल, जे डीफॉल्ट प्रतिक्रिया अॅप पृष्ठ आहे:

पुरवणी 1

कोनीय प्रेमींसाठी आमच्याकडे देखील आहे उदाहरण अर्ज.

OUTPUT_DIR व्हेरिएबल वगळता येथे नमुना समान आहे.

पुरवणी 2

या लेखात आम्ही NGINX वेब सर्व्हर म्हणून वापरले, परंतु ते Apache सह बदलणे खूप सोपे आहे, फक्त फाइलमधील टेम्पलेट बदला NGINX प्रतिमा वर अपाचे प्रतिमा.

निष्कर्ष

या मालिकेच्या पहिल्या भागात, आम्ही ओपनशिफ्ट प्लॅटफॉर्मवर आधुनिक वेब ऍप्लिकेशन्स त्वरीत कसे तैनात करायचे ते दाखवले. आज आम्ही वेब अॅप प्रतिमा काय करते आणि अधिक उत्पादन-तयार अॅप्लिकेशन बिल्ड तयार करण्यासाठी साखळीबद्ध बिल्ड वापरून NGINX सारख्या शुद्ध वेब सर्व्हरसह ते कसे एकत्र केले जाऊ शकते ते पाहिले. या मालिकेतील पुढील आणि शेवटच्या लेखात, आम्ही OpenShift वर तुमच्या ऍप्लिकेशनसाठी डेव्हलपमेंट सर्व्हर कसा चालवायचा आणि स्थानिक आणि रिमोट फाइल्सचे सिंक्रोनाइझेशन कसे सुनिश्चित करायचे ते दाखवू.

लेखांच्या या मालिकेतील सामग्री

• भाग 1: आधुनिक वेब ऍप्लिकेशन्स फक्त काही चरणांमध्ये कसे उपयोजित करायचे;
• भाग २: विद्यमान HTTP सर्व्हर प्रतिमेसह नवीन S2I प्रतिमा कशी वापरायची, जसे की NGINX, उत्पादन उपयोजनासाठी संबंधित OpenShift असेंब्ली वापरून;
• भाग 3: OpenShift प्लॅटफॉर्मवर तुमच्या ऍप्लिकेशनसाठी डेव्हलपमेंट सर्व्हर कसा चालवायचा आणि तो स्थानिक फाइल सिस्टमसह सिंक्रोनाइझ कसा करायचा.

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

• मोफत ई-पुस्तक OpenShift वर तैनात करत आहे.
• वर माहिती OpenShift आणि Kubernetes.

स्त्रोत: www.habr.com