🥇 جديد ايپليڪيشنون OpenShift تي، حصو 2: زنجيرن سان ٺهيل عمارتون

هيلو سڀ! هي اسان جي سيريز جي ٻي پوسٽ آهي جنهن ۾ اسين ڏيکاريون ٿا ته جديد ويب ايپليڪيشنن کي ڪيئن لڳايو وڃي Red Hat OpenShift تي.

پوئين پوسٽ ۾، اسان نئين S2I (ذريعو کان تصوير) بلڊر جي تصوير جي صلاحيتن تي ٿورڙو ڇڪايو، جيڪو OpenShift پليٽ فارم تي جديد ويب ايپليڪيشنن جي تعمير ۽ ترتيب ڏيڻ لاء ٺهيل آهي. پوءِ اسان هڪ ايپليڪيشن کي جلدي ترتيب ڏيڻ جي موضوع ۾ دلچسپي وٺندا هئاسين، ۽ اڄ اسان ڏسنداسين ته ڪيئن استعمال ڪجي S2I تصوير کي ”خالص“ بلڊر تصوير جي طور تي ۽ ان کي ملائي OpenShift اسيمبلين سان.

صاف بلڊر جي تصوير

جيئن اسان حصو XNUMX ۾ ذڪر ڪيو آهي، اڪثر جديد ويب ايپليڪيشنن ۾ هڪ نام نهاد تعميراتي اسٽيج هوندو آهي، جيڪو عام طور تي ڪم سرانجام ڏيندو آهي جهڙوڪ ڪوڊ ٽرانسپيليشن، گھڻن فائلن جي ڪنٽينشن، ۽ minification. انهن عملن جي نتيجي ۾ حاصل ڪيل فائلون - ۽ هي جامد HTML، JavaScript ۽ CSS - آئوٽ پٽ فولڊر ۾ محفوظ ٿيل آهن. هن فولڊر جو مقام عام طور تي منحصر هوندو آهي ته ڪهڙا اوزار استعمال ڪيا پيا وڃن، ۽ رد عمل لاءِ اهو هوندو ./build فولڊر (اسان هن ڏانهن واپس اچون ٿا وڌيڪ تفصيل سان هيٺ).

ماخذ کان تصوير (S2I)

هن پوسٽ ۾ اسان موضوع تي هٿ نه ٿا رکون "S2I ڇا آهي ۽ ان کي ڪيئن استعمال ڪجي" (توهان هن بابت وڌيڪ پڙهي سگهو ٿا هتي)، پر اھو ضروري آھي ته ھن عمل جي ٻن مرحلن بابت واضح ھجي سمجھڻ لاءِ ته ھڪڙي ويب ايپ بلڊر تصوير ڇا ڪري ٿي.

اسيمبليء جو مرحلو

اسيمبليءَ جو مرحلو فطرت ۾ بلڪل ساڳيو آهي ته ڇا ٿيندو جڏهن توهان ڊاڪر بلڊ هلائيندا آهيو ۽ نئين ڊاڪر تصوير سان ختم ڪندا آهيو. انهي جي مطابق، هي اسٽيج تڏهن ٿئي ٿو جڏهن OpenShift پليٽ فارم تي تعمير شروع ڪيو وڃي.

ويب ايپ بلڊر جي تصوير جي صورت ۾، اهو توهان جي ايپليڪيشن جي انحصار کي نصب ڪرڻ ۽ تعمير کي هلائڻ جو ذميوار آهي. اسڪرپٽ گڏ ڪرڻ. ڊفالٽ طور، بلڊر تصوير استعمال ڪري ٿو npm رن تعمير تعمير، پر اهو NPM_BUILD ماحول جي متغير ذريعي ختم ڪري سگهجي ٿو.

جيئن اسان اڳ ۾ چيو آهي، مڪمل ٿيل، اڳ ۾ ئي ٺهيل ايپليڪيشن جو مقام انحصار ڪري ٿو ته توهان ڪهڙا اوزار استعمال ڪندا آهيو. مثال طور، React جي صورت ۾ هي هوندو ./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 پيٽرول تي ڌيان ڏيڻ جي قابل آهي. اسان جي مثال ۾ React ايپليڪيشن لاءِ، پريشان ٿيڻ جي ڪا به ڳالهه ناهي، ڇو ته React ڊفالٽ ويل کي آئوٽ پٽ فولڊر طور استعمال ڪري ٿو، پر 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'

ٽين ۽ چوٿين تصويرن تي هڪ نظر وٺو. اهي ٻئي بيان ڪيا ويا آهن Docker تصويرون، ۽ توهان واضح طور تي ڏسي سگهو ٿا ته اهي ڪٿان اچن ٿا.

ٽئين تصوير ويب ايپ بلڊر آهي ۽ اها 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، جاوا اسڪرپٽ، اسان جي ايپليڪيشن جي 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 سان ليڪ چوي ٿو ته هن تعمير جو نتيجو ساڳيو ريڪٽ-ويب-ايپ-بلڊر تصوير ۾ رکيو ويندو جيڪو اسان ٿورو اڳ ڏٺو هو تصوير اسٽريمز سيڪشن ۾.

2 ليبل ٿيل لائن توهان کي ٻڌائي ٿي ته ڪوڊ ڪٿان حاصل ڪجي. اسان جي صورت ۾، هي هڪ گٽ مخزن آهي، ۽ مقام، ريف ۽ حوالو فولڊر مقرر ڪيا ويا آهن انهن پيٽرولن پاران جيڪي اسان اڳ ۾ ئي مٿي ڏٺو آهي.

3 ليبل ٿيل ليڪ اھو آھي جيڪو اسان اڳ ۾ ئي پيٽرول سيڪشن ۾ ڏٺو آھي. اهو شامل ڪري ٿو OUTPUT_DIR ماحولياتي متغير، جيڪو اسان جي مثال ۾ تعمير ڪيو ويو آهي.
ليبل ٿيل 4 ليبل چوي ٿو ويب-ايپ-بلڊر-رن ٽائم تصوير کي استعمال ڪرڻ لاءِ، جيڪو اسان اڳ ۾ ئي ڏٺو آهي ImageStream سيڪشن ۾.

لائين ليبل ٿيل 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

تنهن ڪري ٻئي تعمير جي جوڙجڪ react-web-app-runtime آهي، ۽ اهو شروع ٿئي ٿو خوبصورت معياري.

ليبل ٿيل 1 ليبل ڪا نئين شيء ناهي - اهو صرف چوي ٿو ته تعمير جو نتيجو رد عمل-ويب-ايپ-رن ٽائم تصوير ۾ رکيل آهي.

ليبل ٿيل 2 ليبل، جيئن پوئين ترتيب ۾، اشارو ڪري ٿو ته ذريعو ڪوڊ ڪٿان حاصل ڪجي. پر نوٽ ڪريو ته هتي اسان اهو چئي رهيا آهيون ته اهو تصوير مان ورتو ويو آهي. ان کان علاوه، تصوير مان جيڪا اسان صرف ٺاھيو آھي - react-web-app-builder کان (ليبل ٿيل 3 ۾ اشارو ڪيو ويو). اهي فائلون جن کي اسان استعمال ڪرڻ چاهيون ٿا اهي تصوير جي اندر آهن ۽ انهن جي جاءِ اتي مقرر ٿيل آهي 4 ليبل تي، اسان جي صورت ۾ اهو آهي /opt/app-root/output/. جيڪڏھن توھان کي ياد آھي، اھو اھو آھي جتي فائلون ٺاھيون ويون آھن جيڪي اسان جي ايپليڪيشن جي تعمير جي نتيجن تي ٻڌل آھن.

ليبل 5 سان اصطلاح ۾ بيان ڪيل منزل فولڊر صرف موجوده ڊاريڪٽري آهي (اهو سڀ ڪجهه آهي، ياد رکو، ڪنهن جادوگر شيءِ جي اندر هلندڙ آهي جنهن کي OpenShift سڏيو ويندو آهي، ۽ توهان جي مقامي ڪمپيوٽر تي نه).

حڪمت عملي سيڪشن - ليبل ٿيل 6 - پڻ پهرين تعمير جي ترتيب سان ملندڙ جلندڙ آهي. صرف هن وقت اسان استعمال ڪرڻ وارا آهيون nginx-image-runtime، جيڪو اسان اڳ ۾ ئي ڏٺو آهي تصويري اسٽريم سيڪشن ۾.

آخرڪار، 7 ليبل ٿيل لائن ٽرگرن جو ھڪڙو حصو آھي جيڪو چالو ڪندو ھن تعمير کي ھر دفعي رد عمل-ويب-ايپ-بلڊر تصوير تبديل ڪندو.

ٻي صورت ۾، هي ٽيمپليٽ خوبصورت معياري ترتيب واري ترتيب تي مشتمل آهي، انهي سان گڏ شيون جيڪي خدمتن ۽ رستن سان لاڳاپيل آهن، پر اسان ان جي تمام گهڻي تفصيل ۾ نه وينداسين. مهرباني ڪري نوٽ ڪريو ته اها تصوير جيڪا ترتيب ڏني ويندي اها آهي react-web-app-runtime تصوير.

ايپليڪيشن لڳائڻ

سو هاڻي ته اسان ٽيمپليٽ کي ڏٺو آهي، اچو ته ڏسون ته ان کي ڪيئن استعمال ڪجي ايپليڪيشن کي ترتيب ڏيڻ لاءِ.

اسان استعمال ڪري سگھون ٿا OpenShift ڪلائنٽ ٽول 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

Angular عاشق لاء اسان وٽ پڻ آهي مثال جي درخواست.

هتي جو نمونو ساڳيو آهي، سواءِ OUTPUT_DIR متغير جي.

اضافي 2

هن آرٽيڪل ۾ اسان NGINX کي ويب سرور طور استعمال ڪيو، پر ان کي اپاچي سان تبديل ڪرڻ بلڪل آسان آهي، صرف فائل ۾ ٽيمپليٽ تبديل ڪريو. NGINX تصوير تي Apache تصوير.

ٿڪل

هن سيريز جي پهرين حصي ۾، اسان ڏيکاريو ته ڪيئن جلدي جديد ويب ايپليڪيشنن کي ترتيب ڏيو OpenShift پليٽ فارم تي. اڄ اسان ڏٺو ته هڪ ويب ايپ تصوير ڇا ڪري ٿي ۽ ڪيئن ان کي هڪ خالص ويب سرور سان گڏ ڪري سگهجي ٿو جهڙوڪ NGINX وڌيڪ پيداوار لاءِ تيار ٿيل ايپليڪيشن ٺاهڻ لاءِ زنجير ٺاهي استعمال ڪندي. هن سلسلي جي ايندڙ ۽ آخري مضمون ۾، اسين ڏيکارينداسين ته ڪيئن هلائجي ڊولپمينٽ سرور توهان جي ايپليڪيشن لاءِ OpenShift ۽ مقامي ۽ ريموٽ فائلن جي هم وقت سازي کي يقيني بڻائي.

مضمونن جي هن سلسلي جو مواد

حصو 1: صرف چند قدمن ۾ جديد ويب ايپليڪيشنن کي ڪيئن ترتيب ڏيڻ;
حصو 2: نئين S2I تصوير کي موجوده HTTP سرور جي تصوير سان ڪيئن استعمال ڪجي، جهڙوڪ NGINX، پيداوار جي ترتيب لاءِ لاڳاپيل OpenShift اسيمبليون استعمال ڪندي؛
حصو 3: OpenShift پليٽ فارم تي توهان جي ايپليڪيشن لاء ڊولپمينٽ سرور ڪيئن هلائڻ ۽ ان کي مقامي فائل سسٽم سان هم وقت سازي ڪرڻ.

اضافي وسيلا

مفت اي بک OpenShift تي ترتيب ڏيڻ.
تي معلومات OpenShift ۽ Kubernetes.

جو ذريعو: www.habr.com

OpenShift تي جديد ايپليڪيشنون، حصو 2: زنجير ٺهيل