🥇 په OpenShift کې عصري غوښتنلیکونه، 2 برخه: زنځیر شوي جوړونه

سلام و ټولو ته! دا زموږ په لړۍ کې دوهم پوسټ دی چې پکې موږ ښیې چې څنګه په Red Hat OpenShift کې عصري ویب غوښتنلیکونه ځای په ځای کړو.

په تیرو پوسټ کې ، موږ د نوي S2I (سرچینې څخه عکس) جوړونکي عکس ظرفیتونو ته لږ څه تماس نیولی ، کوم چې د OpenShift پلیټ فارم کې د عصري ویب غوښتنلیکونو جوړولو او پلي کولو لپاره ډیزاین شوی. بیا موږ د غوښتنلیک ګړندي ځای په ځای کولو موضوع سره علاقه درلوده ، او نن به موږ وګورو چې څنګه د S2I عکس د "خالص" جوړونکي عکس په توګه وکاروو او دا د اړوند OpenShift مجلسونو سره یوځای کړو.

د جوړونکي پاک انځور

لکه څنګه چې موږ په XNUMX برخه کې یادونه وکړه، ډیری عصري ویب غوښتنلیکونه د جوړیدو مرحله لري، کوم چې معمولا عملیات ترسره کوي لکه د کوډ لیږد، د څو فایلونو یوځای کول، او ماینیفیکیشن. د دې عملیاتو په پایله کې ترلاسه شوي فایلونه - او دا جامد 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 پیرامیټر ته د پاملرنې ارزښت لري. زموږ په مثال کې د عکس العمل غوښتنلیک لپاره ، د اندیښنې لپاره هیڅ شی شتون نلري ، ځکه چې عکس العمل ډیفالټ ارزښت د محصول فولډر په توګه کاروي ، مګر د زاویه یا بل څه په حالت کې ، دا پیرامیټر به د اړتیا سره سم بدل شي.

اوس راځئ چې د 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'

دریم او څلورم عکسونه وګورئ. دوی دواړه د ډاکر عکسونو په توګه تعریف شوي ، او تاسو کولی شئ په روښانه ډول وګورئ چې دوی له کوم ځای څخه راځي.

دریم عکس د ویب ایپ جوړونکی دی او دا د نوډشیفټ/ubi8-s2i-web-app څخه راځي چې د 10.x په نښه شوي د ډاکر مرکز.

څلورم د NGINX عکس دی (نسخه 1.12) د وروستي ټګ سره د ډاکر مرکز.

اوس راځئ چې لومړی دوه عکسونه وګورو. دوی دواړه په پیل کې خالي دي او یوازې د جوړیدو مرحلې په جریان کې رامینځته شوي. لومړی عکس، react-web-app-builder، به د یو مجلس مرحلې پایله وي چې د ویب-app-builder-runtime انځور او زموږ د سرچینې کوډ سره یوځای کوي. له همدې امله موږ د دې عکس نوم ته "-بلډر" اضافه کړ.

دوهم عکس - 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 عکس کې ځای په ځای شي چې موږ یو څه دمخه د ImageStreams برخه کې ولیدل.

2 لیبل شوی کرښه تاسو ته وایی چې کوډ له کوم ځای څخه ترلاسه کړئ. زموږ په قضیه کې ، دا د git ذخیره ده ، او موقعیت ، ریف او د شرایطو فولډر د پیرامیټونو لخوا ټاکل کیږي چې موږ دمخه پورته لیدلي.

د 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 لیبل شوی کرښه هیڅ نوی نده - دا په ساده ډول وايي چې د جوړونې پایله د عکس العمل-web-app-runtime عکس کې اچول کیږي.

د 2 لیبل شوی کرښه، لکه څنګه چې په تیر ترتیب کې، په ګوته کوي چې د سرچینې کوډ له کوم ځای څخه ترلاسه کړئ. مګر پام وکړئ چې دلته موږ وایو چې دا د عکس څخه اخیستل شوی. برسېره پردې، د عکس څخه چې موږ یې جوړ کړی - د react-web-app-builder څخه (په لیبل شوي 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.

دوهم کمانډ په ساده ډول د دې ټیمپلیټ پراساس یو نوی غوښتنلیک رامینځته کوي.

د دې حکمونو د کار کولو وروسته، موږ به وګورو چې موږ دوه مجلسونه لرو:

او د عمومي لید سکرین ته راستنیدل ، موږ به پیل شوی پوډ وګورو:

په لینک کلیک وکړئ او موږ به زموږ اپلیکیشن ته یوسو، کوم چې د ډیفالټ عکس العمل ایپ پاڼه ده:

ضمیمه 1

د زاویه مینه والو لپاره موږ هم لرو د مثال غوښتنلیک.

دلته نمونه یو شان ده، پرته له OUTPUT_DIR متغیر.

ضمیمه 2

پدې مقاله کې موږ NGINX د ویب سرور په توګه کارولی ، مګر دا د اپاچي سره بدلول خورا اسانه دي ، یوازې په فایل کې ټیمپلیټ بدل کړئ د NGINX انځور په د اپاچي انځور.

پایلې

د دې لړۍ په لومړۍ برخه کې، موږ وښودله چې څنګه د OpenShift پلیټ فارم کې عصري ویب غوښتنلیکونه په چټکۍ سره ځای په ځای کړي. نن ورځ موږ وګورو چې د ویب اپلیکیشن عکس څه کوي او دا څنګه د خالص ویب سرور سره لکه NGINX سره یوځای کیدی شي د زنځیر جوړونو په کارولو سره د تولید لپاره چمتو غوښتنلیک رامینځته کولو لپاره. د دې لړۍ په راتلونکې او وروستۍ مقاله کې، موږ به وښیو چې څنګه په OpenShift کې ستاسو د غوښتنلیک لپاره پرمختیایي سرور چلول او د ځایی او لرې پرتو فایلونو همغږي کول یقیني کول.

د مقالو د دې لړۍ منځپانګه

لومړۍ برخه: په څو مرحلو کې د عصري ویب غوښتنلیکونو ځای پرځای کولو څرنګوالی;
برخه 2: د موجوده HTTP سرور عکس سره د نوي S2I عکس کارولو څرنګوالی ، لکه NGINX ، د تولید پلي کولو لپاره د تړلو OpenShift مجلسونو په کارولو سره؛
دریمه برخه: د OpenShift پلیټ فارم کې ستاسو د غوښتنلیک لپاره د پراختیا سرور چلولو څرنګوالی او د محلي فایل سیسټم سره همغږي کول.

اضافي سرچینې

وړیا ای کتاب په OpenShift کې ځای پرځای کول.
په اړه معلومات OpenShift او Kubernetes.

سرچینه: www.habr.com

په OpenShift کې عصري غوښتنلیکونه، 2 برخه: زنځیر شوي جوړونه