🥇 OpenShift پر جدید ایپلی کیشنز، حصہ 2: زنجیروں والی تعمیرات

سب کو سلام! یہ ہماری سیریز کی دوسری پوسٹ ہے جس میں ہم دکھاتے ہیں کہ Red Hat OpenShift پر جدید ویب ایپلیکیشنز کو کیسے تعینات کیا جائے۔

پچھلی پوسٹ میں، ہم نے نئی S2I (ذریعہ سے تصویر) بلڈر امیج کی صلاحیتوں کو تھوڑا سا چھوا، جو OpenShift پلیٹ فارم پر جدید ویب ایپلیکیشنز کی تعمیر اور تعیناتی کے لیے ڈیزائن کیا گیا ہے۔ اس کے بعد ہم ایک ایپلیکیشن کو فوری طور پر تعینات کرنے کے موضوع میں دلچسپی رکھتے تھے، اور آج ہم دیکھیں گے کہ S2I امیج کو "خالص" بلڈر امیج کے طور پر کیسے استعمال کیا جائے اور اسے متعلقہ OpenShift اسمبلیوں کے ساتھ جوڑ دیا جائے۔

بلڈر کی صاف تصویر

جیسا کہ ہم نے حصہ XNUMX میں ذکر کیا ہے، زیادہ تر جدید ویب ایپلیکیشنز میں ایک نام نہاد تعمیراتی مرحلہ ہوتا ہے، جو عام طور پر کوڈ ٹرانسپلیشن، ایک سے زیادہ فائل کنکٹنیشن، اور منیفیکیشن جیسے کام انجام دیتا ہے۔ ان کارروائیوں کے نتیجے میں حاصل ہونے والی فائلیں - اور یہ جامد HTML، JavaScript اور CSS ہیں - آؤٹ پٹ فولڈر میں محفوظ ہیں۔ اس فولڈر کا مقام عام طور پر اس بات پر منحصر ہوتا ہے کہ کون سے تعمیراتی اوزار استعمال کیے جا رہے ہیں، اور React کے لیے یہ ./build فولڈر ہو گا (ہم ذیل میں مزید تفصیل سے اس پر واپس آئیں گے)۔

ماخذ سے تصویر (S2I)

اس پوسٹ میں ہم "S2I کیا ہے اور اس کا استعمال کیسے کریں" کے موضوع کو نہیں چھوتے ہیں (آپ اس کے بارے میں مزید پڑھ سکتے ہیں یہاں)، لیکن یہ سمجھنے کے لیے کہ ویب ایپ بلڈر کی تصویر کیا کرتی ہے اس عمل کے دو مراحل کے بارے میں واضح ہونا ضروری ہے۔

اسمبلی کا مرحلہ

اسمبلی کا مرحلہ فطرت میں بہت ملتا جلتا ہے جب آپ ڈوکر بلڈ چلاتے ہیں اور ایک نئی ڈوکر امیج کے ساتھ ختم ہوتے ہیں۔ اس کے مطابق، یہ مرحلہ اس وقت ہوتا ہے جب OpenShift پلیٹ فارم پر تعمیر شروع کرتے ہیں۔

ویب ایپ بلڈر امیج کی صورت میں، یہ آپ کی ایپلیکیشن کے انحصار کو انسٹال کرنے اور بلڈ کو چلانے کے لیے ذمہ دار ہے۔ سکرپٹ جمع. پہلے سے طے شدہ طور پر، بلڈر امیج npm run build construct کا استعمال کرتی ہے، لیکن اسے NPM_BUILD ماحولیاتی متغیر کے ذریعے اوور رائیڈ کیا جا سکتا ہے۔

جیسا کہ ہم نے پہلے کہا، پہلے سے تیار شدہ ایپلیکیشن کا مقام اس بات پر منحصر ہے کہ آپ کون سے ٹولز استعمال کرتے ہیں۔ مثال کے طور پر، React کی صورت میں یہ ./build فولڈر ہوگا، اور کونیی ایپلی کیشنز کے لیے یہ پروجیکٹ_نام/ڈسٹ فولڈر ہوگا۔ اور جیسا کہ پہلے ہی پچھلی پوسٹ میں دکھایا گیا ہے، آؤٹ پٹ ڈائرکٹری کا مقام، جو بطور ڈیفالٹ بنانے کے لیے سیٹ ہے، کو OUTPUT_DIR ماحولیاتی متغیر کے ذریعے اوور رائیڈ کیا جا سکتا ہے۔ ٹھیک ہے، چونکہ آؤٹ پٹ فولڈر کا مقام فریم ورک سے دوسرے فریم ورک میں مختلف ہوتا ہے، اس لیے آپ آسانی سے تیار کردہ آؤٹ پٹ کو امیج کے معیاری فولڈر میں کاپی کرتے ہیں، یعنی /opt/apt-root/output۔ اس مضمون کے بقیہ حصے کو سمجھنے کے لیے یہ ضروری ہے، لیکن ابھی کے لیے آئیے فوری طور پر اگلے مرحلے یعنی رن فیز کو دیکھتے ہیں۔

چلانے کے مرحلے

یہ مرحلہ اس وقت ہوتا ہے جب اسمبلی مرحلے کے دوران بنائی گئی نئی امیج پر کال ٹو ڈوکر رن کی جاتی ہے۔ OpenShift پلیٹ فارم پر تعینات کرتے وقت بھی ایسا ہی ہوتا ہے۔ طے شدہ سکرپٹ چلائیں استعمال کرتا ہے ماڈیول کی خدمت کریں مندرجہ بالا معیاری آؤٹ پٹ ڈائرکٹری میں موجود جامد مواد کو پیش کرنے کے لیے۔

یہ طریقہ ایپلی کیشنز کو تیزی سے تعینات کرنے کے لیے اچھا ہے، لیکن عام طور پر اس طرح جامد مواد پیش کرنے کی سفارش نہیں کی جاتی ہے۔ ٹھیک ہے، چونکہ حقیقت میں ہم صرف جامد مواد پیش کرتے ہیں، ہمیں اپنی تصویر کے اندر نصب Node.js کی ضرورت نہیں ہے - ایک ویب سرور کافی ہوگا۔

دوسرے لفظوں میں، جمع کرتے وقت ہمیں ایک چیز کی ضرورت ہوتی ہے، جب کہ عمل کرتے وقت ہمیں دوسری چیز کی ضرورت ہوتی ہے۔ اس صورت حال میں، زنجیروں کی تعمیر کام آتی ہے.

زنجیروں سے جڑی ہوئی تعمیرات

اس بارے میں وہ لکھتے ہیں۔ زنجیروں سے جڑی ہوئی تعمیرات OpenShift دستاویزات میں:

"دو اسمبلیوں کو آپس میں جوڑا جا سکتا ہے، جس میں سے ایک ایک مرتب شدہ ہستی تیار کرتی ہے اور دوسری اس ہستی کو ایک الگ تصویر میں میزبانی کرتی ہے جو اس ہستی کو چلانے کے لیے استعمال ہوتی ہے۔"

دوسرے الفاظ میں، ہم اپنی تعمیر کو چلانے کے لیے ویب ایپ بلڈر امیج کا استعمال کر سکتے ہیں، اور پھر اپنے مواد کو پیش کرنے کے لیے ویب سرور امیج، وہی NGINX استعمال کر سکتے ہیں۔

اس طرح، ہم ویب ایپ بلڈر امیج کو ایک "خالص" بلڈر کے طور پر استعمال کر سکتے ہیں اور ساتھ ہی ساتھ ایک چھوٹی رن ٹائم امیج بھی رکھ سکتے ہیں۔

اب اس کو ایک مخصوص مثال سے دیکھتے ہیں۔

تربیت کے لیے ہم استعمال کریں گے۔ سادہ ردعمل کی درخواست, 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 پیرامیٹر پر توجہ دینے کے قابل ہے۔ ہماری مثال میں 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'

تیسری اور چوتھی تصویر پر ایک نظر ڈالیں۔ ان دونوں کو ڈوکر امیجز کے طور پر بیان کیا گیا ہے، اور آپ واضح طور پر دیکھ سکتے ہیں کہ وہ کہاں سے آتی ہیں۔

تیسری تصویر web-app-builder کی ہے اور یہ nodeshift/ubi8-s2i-web-app ٹیگ کردہ 10.x سے آتی ہے۔ ڈاکر ہب.

چوتھی ایک NGINX تصویر (ورژن 1.12) ہے جس پر تازہ ترین ٹیگ ہے۔ ڈاکر ہب.

اب آئیے پہلی دو تصاویر کو دیکھتے ہیں۔ وہ دونوں شروع میں خالی ہوتے ہیں اور صرف تعمیراتی مرحلے کے دوران بنائے جاتے ہیں۔ پہلی تصویر، react-web-app-builder، ایک اسمبلی مرحلے کا نتیجہ ہو گی جو web-app-builder-runtime امیج اور ہمارے سورس کوڈ کو یکجا کرے گی۔ اسی لیے ہم نے اس تصویر کے نام میں "-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 امیج اس کو سپورٹ کرتی ہے تو ہم انکریمنٹل بلڈ استعمال کرنا چاہتے ہیں، اور ویب ایپ بلڈر امیج کرتا ہے۔ پہلی لانچ میں، اسمبلی کا مرحلہ مکمل ہونے کے بعد، تصویر 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 کا لیبل لگا ہوا لائن کوئی نئی بات نہیں ہے - یہ صرف یہ کہتا ہے کہ تعمیر کا نتیجہ react-web-app-runtime امیج میں ڈال دیا جاتا ہے۔

2 کا لیبل لگا ہوا لائن، جیسا کہ پچھلی ترتیب میں، اشارہ کرتی ہے کہ سورس کوڈ کہاں سے حاصل کرنا ہے۔ لیکن غور کریں کہ یہاں ہم کہہ رہے ہیں کہ یہ تصویر سے لیا گیا ہے۔ مزید برآں، اس تصویر سے جو ہم نے ابھی بنائی ہے - react-web-app-builder سے (3 لیبل والی لائن میں اشارہ کیا گیا ہے)۔ ہم جن فائلوں کو استعمال کرنا چاہتے ہیں وہ تصویر کے اندر ہیں اور ان کا مقام 4 لیبل والی لائن میں سیٹ ہے، ہمارے معاملے میں یہ /opt/app-root/output/ ہے۔ اگر آپ کو یاد ہے تو، یہ وہ جگہ ہے جہاں ہماری ایپلیکیشن بنانے کے نتائج پر مبنی فائلیں محفوظ کی جاتی ہیں۔

لیبل 5 کے ساتھ اصطلاح میں مخصوص کردہ منزل کا فولڈر صرف موجودہ ڈائریکٹری ہے (یہ سب کچھ ہے، یاد رکھیں، کسی جادوئی چیز کے اندر چل رہا ہے جسے OpenShift کہتے ہیں، اور آپ کے مقامی کمپیوٹر پر نہیں)۔

حکمت عملی سیکشن - جس پر 6 کا لیبل لگا ہوا ہے - بھی پہلی تعمیر کی ترتیب سے ملتا جلتا ہے۔ صرف اس بار ہم nginx-image-runtime استعمال کرنے جا رہے ہیں، جسے ہم نے ImageStream سیکشن میں پہلے ہی دیکھا ہے۔

آخر میں، 7 کا لیبل لگا ہوا لائن محرکات کا ایک حصہ ہے جو ہر بار ری ایکٹ-ویب-ایپ بلڈر کی تصویر کو تبدیل کرنے پر اس تعمیر کو چالو کرے گا۔

بصورت دیگر، اس ٹیمپلیٹ میں بہت معیاری تعیناتی ترتیب ہے، ساتھ ہی وہ چیزیں جو خدمات اور راستوں سے متعلق ہیں، لیکن ہم اس کی زیادہ تفصیل میں نہیں جائیں گے۔ براہ کرم نوٹ کریں کہ جو تصویر لگائی جائے گی وہ react-web-app-رن ٹائم امیج ہے۔

درخواست کی تعیناتی

تو اب جب کہ ہم نے ٹیمپلیٹ کو دیکھا ہے، آئیے دیکھتے ہیں کہ اسے ایپلیکیشن کی تعیناتی کے لیے کیسے استعمال کیا جائے۔

ہم اپنے ٹیمپلیٹ کو تعینات کرنے کے لیے اوپن شفٹ کلائنٹ ٹول کا استعمال کر سکتے ہیں جسے 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۔

دوسری کمانڈ صرف اس ٹیمپلیٹ کی بنیاد پر ایک نئی ایپلیکیشن بناتی ہے۔

ان احکامات کے کام کرنے کے بعد، ہم دیکھیں گے کہ ہمارے پاس دو اسمبلیاں ہیں:

اور جائزہ اسکرین پر واپس آتے ہوئے، ہم لانچ شدہ پوڈ دیکھیں گے:

لنک پر کلک کریں اور ہمیں ہماری ایپ پر لے جایا جائے گا، جو ڈیفالٹ React ایپ کا صفحہ ہے:

ضمیمہ 1

کونیی محبت کرنے والوں کے لیے ہمارے پاس بھی ہے۔ مثال کی درخواست.

یہاں پیٹرن ایک ہی ہے، سوائے OUTPUT_DIR متغیر کے۔

ضمیمہ 2

اس مضمون میں ہم نے NGINX کو بطور ویب سرور استعمال کیا ہے، لیکن اسے اپاچی سے تبدیل کرنا کافی آسان ہے، بس فائل میں موجود ٹیمپلیٹ کو تبدیل کریں۔ NGINX تصویر پر اپاچی تصویر.

حاصل يہ ہوا

اس سیریز کے پہلے حصے میں، ہم نے دکھایا کہ جدید ویب ایپلیکیشنز کو اوپن شفٹ پلیٹ فارم پر تیزی سے کیسے تعینات کیا جائے۔ آج ہم نے دیکھا کہ ایک ویب ایپ امیج کیا کرتی ہے اور اسے کس طرح NGINX جیسے خالص ویب سرور کے ساتھ جوڑا جا سکتا ہے تاکہ زیادہ پروڈکشن کے لیے تیار ایپلی کیشن کی تعمیر کی جا سکے۔ اس سیریز کے اگلے اور آخری مضمون میں، ہم دکھائیں گے کہ اوپن شفٹ پر آپ کی ایپلیکیشن کے لیے ڈویلپمنٹ سرور کیسے چلایا جائے اور مقامی اور ریموٹ فائلوں کی ہم آہنگی کو یقینی بنایا جائے۔

مضامین کے اس سلسلے کے مشمولات

1 حصہ: جدید ویب ایپلیکیشنز کو صرف چند مراحل میں کیسے تعینات کیا جائے۔;
حصہ 2: موجودہ HTTP سرور امیج کے ساتھ نئی S2I امیج کا استعمال کیسے کریں، جیسے کہ NGINX، پروڈکشن کی تعیناتی کے لیے متعلقہ OpenShift اسمبلیوں کا استعمال کرتے ہوئے؛
حصہ 3: اوپن شفٹ پلیٹ فارم پر اپنی ایپلیکیشن کے لیے ڈویلپمنٹ سرور کیسے چلائیں اور اسے مقامی فائل سسٹم کے ساتھ ہم آہنگ کریں۔

ые ы

مفت ای بک OpenShift میں تعیناتی.
کے بارے میں معلومات اوپن شفٹ اور کبرنیٹس.

ماخذ: www.habr.com

OpenShift پر جدید ایپلی کیشنز، حصہ 2: زنجیروں والی تعمیرات