🥇برنامه های مدرن در OpenShift، قسمت 2: ساخت های زنجیره ای

سلام به همه! این دومین پست از سری ما است که در آن نحوه استقرار برنامه های وب مدرن در Red Hat OpenShift را نشان می دهیم.

در پست قبلی کمی به قابلیت های تصویر ساز جدید S2I (منبع به تصویر) پرداختیم که برای ساخت و استقرار برنامه های کاربردی وب مدرن در پلتفرم OpenShift طراحی شده است. سپس ما به موضوع استقرار سریع یک برنامه علاقه مند شدیم و امروز به نحوه استفاده از یک تصویر S2I به عنوان یک تصویر سازنده خالص و ترکیب آن با مجموعه های OpenShift مرتبط نگاه خواهیم کرد.

تصویر سازنده تمیز

همانطور که در قسمت XNUMX اشاره کردیم، اکثر برنامه های کاربردی وب مدرن به اصطلاح مرحله ساخت دارند که معمولاً عملیات هایی مانند انتقال کد، الحاق چند فایل و کوچک سازی را انجام می دهد. فایل های به دست آمده در نتیجه این عملیات - و این HTML ایستا، جاوا اسکریپت و CSS است - در پوشه خروجی ذخیره می شوند. محل این پوشه معمولاً بستگی به ابزارهای ساخت مورد استفاده دارد، و برای React این پوشه ./build خواهد بود (در ادامه با جزئیات بیشتر به این موضوع باز خواهیم گشت).

منبع به تصویر (S2I)

در این پست ما به موضوع "S2I چیست و نحوه استفاده از آن" نمی پردازیم (شما می توانید در این مورد بیشتر بخوانید اینجا)، اما برای درک اینکه یک تصویر Web App Builder چه کاری انجام می دهد، واضح بودن دو مرحله در این فرآیند بسیار مهم است.

مرحله مونتاژ

فاز مونتاژ از نظر ماهیت بسیار شبیه به اتفاقاتی است که وقتی Docker build را اجرا می کنید و در نهایت با یک تصویر Docker جدید مواجه می شوید. بر این اساس، این مرحله هنگام شروع یک ساخت بر روی پلت فرم OpenShift رخ می دهد.

در مورد یک تصویر Web App Builder، مسئول نصب وابستگی های برنامه شما و اجرای ساخت است. مونتاژ اسکریپت. به طور پیش فرض، تصویر سازنده از ساختار ساخت npm run استفاده می کند، اما می توان آن را از طریق متغیر محیطی NPM_BUILD لغو کرد.

همانطور که قبلاً گفتیم، مکان برنامه تکمیل شده و از قبل ساخته شده به ابزارهایی که استفاده می کنید بستگی دارد. به عنوان مثال، در مورد React این پوشه ./build خواهد بود و برای برنامه های Angular پوشه project_name/dist خواهد بود. و همانطور که قبلا در پست قبلی نشان داده شد، مکان دایرکتوری خروجی که به طور پیش فرض برای ساخت تنظیم شده است، می تواند از طریق متغیر محیطی OUTPUT_DIR لغو شود. خوب، از آنجایی که مکان پوشه خروجی در چارچوبی به فریمورک دیگر متفاوت است، شما به سادگی خروجی تولید شده را در پوشه استاندارد تصویر، یعنی /opt/apt-root/output کپی کنید. این برای درک بقیه این مقاله مهم است، اما در حال حاضر اجازه دهید به سرعت به مرحله بعدی - مرحله اجرا نگاه کنیم.

فاز اجرا

این مرحله زمانی اتفاق می‌افتد که یک فراخوانی برای اجرای docker بر روی تصویر جدید ایجاد شده در مرحله اسمبلی ایجاد می‌شود. هنگام استقرار در پلتفرم OpenShift نیز همین اتفاق می افتد. پیش فرض اجرای اسکریپت استفاده می کند ماژول خدمت برای ارائه محتوای ثابت واقع در فهرست خروجی استاندارد بالا.

این روش برای استقرار سریع برنامه ها خوب است، اما به طور کلی ارائه محتوای ثابت به این روش توصیه نمی شود. خوب، از آنجایی که در واقعیت ما فقط محتوای ثابت را ارائه می دهیم، نیازی به نصب Node.js در داخل تصویر نداریم - یک وب سرور کافی است.

به عبارت دیگر، هنگام مونتاژ به یک چیز نیاز داریم، در هنگام اجرا به چیز دیگری نیاز داریم. در این شرایط، ساخت های زنجیر شده به کارتان می آیند.

سازه های زنجیر شده

این چیزی است که آنها در مورد آن می نویسند ساخت های زنجیر شده در اسناد OpenShift:

دو اسمبلی را می‌توان به هم متصل کرد، که یکی یک موجودیت کامپایل‌شده را ایجاد می‌کند و دیگری میزبان آن موجودیت در یک تصویر جداگانه است که برای اجرای آن موجودیت استفاده می‌شود.

به عبارت دیگر، می‌توانیم از تصویر Web App Builder برای اجرای ساختمان استفاده کنیم و سپس از تصویر وب سرور، همان NGINX، برای ارائه محتوای خود استفاده کنیم.

بنابراین، می‌توانیم از تصویر Web App Builder به عنوان یک سازنده خالص استفاده کنیم و در عین حال یک تصویر زمان اجرا کوچک داشته باشیم.

حال بیایید با یک مثال خاص به این موضوع نگاه کنیم.

برای آموزش استفاده خواهیم کرد برنامه ساده React، با استفاده از ابزار خط فرمان 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 تعریف شده‌اند و به وضوح می‌توانید ببینید که از کجا آمده‌اند.

تصویر سوم 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 استاتیک، جاوا اسکریپت، 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 است و مکان، ref و پوشه زمینه با پارامترهایی که قبلاً در بالا دیدیم تعیین می شوند.

خط با برچسب 3 همان چیزی است که قبلاً در بخش پارامترها دیدیم. متغیر محیطی OUTPUT_DIR را اضافه می کند که در مثال ما build است.
خطی با برچسب 4 می گوید که از تصویر web-app-builder-runtime استفاده کنید که قبلاً در بخش ImageStream دیده بودیم.

خط با برچسب 5 می گوید که ما می خواهیم از یک ساخت افزایشی استفاده کنیم اگر تصویر S2I از آن پشتیبانی می کند و تصویر Web App Builder از آن پشتیبانی می کند. در اولین راه اندازی، پس از اتمام مرحله اسمبلی، تصویر پوشه 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 چیز جدیدی نیست - به سادگی می گوید که نتیجه ساخت در تصویر 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-builder تغییر می‌کند، این بیلد را فعال می‌کند.

در غیر این صورت، این الگو شامل پیکربندی استقرار بسیار استاندارد، و همچنین مواردی است که به سرویس‌ها و مسیرها مربوط می‌شوند، اما ما به این جزئیات زیاد نمی‌پردازیم. لطفاً توجه داشته باشید که تصویری که مستقر خواهد شد، تصویر react-web-app-runtime است.

استقرار برنامه

بنابراین اکنون که به الگو نگاه کردیم، بیایید ببینیم که چگونه از آن برای استقرار یک برنامه استفاده کنیم.

ما می توانیم از ابزار OpenShift Client به نام 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 App است هدایت می‌شویم:

مکمل 1

برای عاشقان انگولار هم داریم نرم افزار مثال.

الگوی اینجا به جز متغیر OUTPUT_DIR یکسان است.

مکمل 2

در این مقاله از NGINX به عنوان یک وب سرور استفاده کردیم، اما جایگزین کردن آن با آپاچی بسیار آسان است، فقط قالب موجود در فایل را تغییر دهید. تصویر NGINX بر تصویر آپاچی.

نتیجه

در قسمت اول این مجموعه، نحوه استقرار سریع برنامه های وب مدرن بر روی پلت فرم OpenShift را نشان دادیم. امروز به این موضوع پرداختیم که یک تصویر برنامه وب چه کاری انجام می دهد و چگونه می توان آن را با یک وب سرور خالص مانند NGINX با استفاده از ساختارهای زنجیره ای ترکیب کرد تا یک برنامه کاربردی آماده برای تولید ایجاد کرد. در مقاله بعدی و پایانی این مجموعه، نحوه اجرای سرور توسعه برای برنامه خود در OpenShift و اطمینان از همگام سازی فایل های محلی و راه دور را نشان خواهیم داد.

مطالب این سری مقالات

قسمت 1: نحوه استقرار برنامه های کاربردی وب مدرن تنها در چند مرحله;
قسمت 2: نحوه استفاده از یک تصویر S2I جدید با یک تصویر سرور HTTP موجود، مانند NGINX، با استفاده از مجموعه‌های OpenShift مرتبط برای استقرار تولید.
قسمت 3: نحوه اجرای سرور توسعه برای برنامه خود در پلتفرم OpenShift و همگام سازی آن با سیستم فایل محلی.

منابع اضافی

کتاب الکترونیکی رایگان در حال استقرار در OpenShift.
اطلاعات در مورد OpenShift و Kubernetes.

منبع: www.habr.com

برنامه های مدرن در OpenShift، قسمت 2: ساخت های زنجیره ای