OpenShift-də müasir tətbiqlər, 2-ci hissə: zəncirlənmiş quruluşlar

Hamıya salam! Bu, Red Hat OpenShift-də müasir veb proqramlarını necə yerləşdirməyi göstərdiyimiz seriyamızdakı ikinci yazıdır.

Əvvəlki yazıda biz OpenShift platformasında müasir veb proqramların qurulması və yerləşdirilməsi üçün nəzərdə tutulmuş yeni S2I (mənbədən-şəklə) qurucu təsvirinin imkanlarına bir qədər toxunduq. Sonra bir tətbiqin tez yerləşdirilməsi mövzusu ilə maraqlandıq və bu gün biz S2I görüntüsünü "təmiz" qurucu şəkli kimi necə istifadə edəcəyimizə baxacağıq və onu əlaqəli OpenShift montajları ilə birləşdirəcəyik.

Təmiz inşaatçı şəkli

XNUMX-ci hissədə qeyd etdiyimiz kimi, müasir veb proqramların əksəriyyəti adətən kodun köçürülməsi, çoxsaylı faylların birləşdirilməsi və kiçildilməsi kimi əməliyyatları yerinə yetirən qurma mərhələsinə malikdir. Bu əməliyyatlar nəticəsində əldə edilən fayllar - və bu, statik HTML, JavaScript və CSS - çıxış qovluğunda saxlanılır. Bu qovluğun yeri adətən hansı qurma alətlərindən istifadə olunduğundan asılıdır və React üçün bu ./build qovluğu olacaq (buna aşağıda daha ətraflı qayıdacayıq).

Mənbədən Şəkilə (S2I)

Bu yazıda biz “S2I nədir və ondan necə istifadə etmək olar” mövzusuna toxunmuruq (bu barədə daha çox oxuya bilərsiniz) burada), lakin Veb Tətbiq Qurucusu şəklinin nə etdiyini başa düşmək üçün bu prosesdəki iki addımı aydınlaşdırmaq vacibdir.

Montaj mərhələsi

Montaj mərhələsi təbiətcə docker build-i işə saldıqda baş verənlərə çox oxşardır və yeni Docker təsviri ilə nəticələnir. Müvafiq olaraq, bu mərhələ OpenShift platformasında qurmağa başladıqda baş verir.

Veb Tətbiq Qurucusu təsviri vəziyyətində, o, tətbiqinizin asılılıqlarını quraşdırmaq və quruluşu işə salmaq üçün məsuliyyət daşıyır. skript yığın. Defolt olaraq, qurucu şəkli npm run qurma konstruksiyasından istifadə edir, lakin bu NPM_BUILD mühit dəyişəni vasitəsilə ləğv edilə bilər.

Daha əvvəl dediyimiz kimi, hazır, artıq qurulmuş tətbiqin yeri hansı vasitələrdən istifadə etdiyinizdən asılıdır. Məsələn, React vəziyyətində bu ./build qovluğu, Angular proqramlar üçün isə layihə_adı/dist qovluğu olacaq. Əvvəlki yazıda artıq göstərildiyi kimi, standart olaraq qurulmaq üçün təyin edilmiş çıxış qovluğunun yeri OUTPUT_DIR mühit dəyişəni vasitəsilə ləğv edilə bilər. Yaxşı, çıxış qovluğunun yeri çərçivədən çərçivəyə fərqli olduğundan, siz sadəcə olaraq yaradılan çıxışı şəkildəki standart qovluğa, yəni /opt/apt-root/output-a köçürürsünüz. Bu, bu məqalənin qalan hissəsini başa düşmək üçün vacibdir, lakin indi tez növbəti mərhələyə - qaçış mərhələsinə baxaq.

qaçış mərhələsi

Bu mərhələ montaj mərhələsində yaradılmış yeni təsvirdə docker run çağırışı edildiyi zaman baş verir. Eyni şey OpenShift platformasında yerləşdirərkən baş verir. Defolt skripti işlədin istifadə edir xidmət modulu yuxarıdakı standart çıxış kataloqunda yerləşən statik məzmuna xidmət etmək.

Bu üsul tətbiqləri tez yerləşdirmək üçün yaxşıdır, lakin ümumiyyətlə statik məzmunu bu şəkildə təqdim etmək tövsiyə edilmir. Əslində biz yalnız statik məzmuna xidmət etdiyimiz üçün şəklimizdə Node.js quraşdırmaq lazım deyil - veb server kifayət edəcək.

Başqa sözlə, montaj edərkən bir şeyə ehtiyacımız var, icra edərkən başqa bir şey lazımdır. Bu vəziyyətdə, zəncirlənmiş quruluşlar faydalıdır.

Zəncirlənmiş quruluşlar

Bu barədə yazırlar zəncirlənmiş tikililər OpenShift sənədlərində:

"İki məclis bir-biri ilə əlaqələndirilə bilər, biri tərtib edilmiş obyekt yaradır, digəri isə həmin obyekti idarə etmək üçün istifadə olunan ayrı bir görüntüdə yerləşdirir."

Başqa sözlə, biz quruluşumuzu işə salmaq üçün Veb Tətbiq Qurucusu görüntüsündən istifadə edə bilərik və sonra məzmunumuza xidmət etmək üçün veb server şəklini, eyni NGINX-dən istifadə edə bilərik.

Beləliklə, biz Web App Builder şəklini "təmiz" qurucu kimi istifadə edə bilərik və eyni zamanda kiçik bir iş vaxtı təsvirinə sahib ola bilərik.

İndi buna konkret misalla baxaq.

Təlim üçün istifadə edəcəyik sadə React tətbiqi, create-react-app komanda xətti alətindən istifadə edərək yaradılmışdır.

Bu, bizə hər şeyi bir araya gətirməyə kömək edəcək OpenShift şablon faylı.

Bu faylı daha ətraflı nəzərdən keçirək və parametrlər bölməsindən başlayaq.

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

Burada hər şey olduqca aydındır, lakin OUTPUT_DIR parametrinə diqqət yetirməyə dəyər. Nümunəmizdəki React tətbiqi üçün narahat olmaq üçün heç bir şey yoxdur, çünki React çıxış qovluğu kimi standart dəyəri istifadə edir, lakin Angular və ya başqa bir şey vəziyyətində bu parametr lazım olduqda dəyişdirilməlidir.

İndi isə ImageStreams bölməsinə nəzər salaq.

- 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'

Üçüncü və dördüncü şəkillərə nəzər salın. Onların hər ikisi Docker şəkilləri kimi müəyyən edilir və siz onların haradan gəldiyini aydın görə bilərsiniz.

Üçüncü şəkil web-app-builder-dir və o, 8.x etiketli nodeshift/ubi2-s10i-web-app-dan gəlir. Docker mərkəzi.

Dördüncüsü, ən son etiketi olan NGINX şəklidir (versiya 1.12). Docker mərkəzi.

İndi ilk iki şəkilə baxaq. Onların hər ikisi başlanğıcda boşdur və yalnız tikinti mərhələsində yaradılır. İlk şəkil, react-web-app-builder, web-app-builder-iş vaxtı şəklini və mənbə kodumuzu birləşdirəcək montaj addımının nəticəsi olacaq. Ona görə də bu şəklin adına “-builder” əlavə etdik.

İkinci şəkil - react-web-app-runtime - nginx-image-runtime və react-web-app-builder təsvirindən bəzi faylların birləşməsinin nəticəsi olacaq. Bu şəkil həmçinin yerləşdirmə zamanı istifadə olunacaq və yalnız tətbiqimizin veb serverini və statik HTML, JavaScript, CSS-ni ehtiva edəcək.

Qarışıq? İndi qurma konfiqurasiyalarına nəzər salaq və bir az daha aydın olacaq.

Şablonumuzun iki quruluş konfiqurasiyası var. Budur birincisi və olduqca standartdır:

  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

Gördüyünüz kimi, 1 etiketli sətirdə deyilir ki, bu quruluşun nəticəsi ImageStreams bölməsində bir az əvvəl gördüyümüz eyni reaksiya-veb-app-builder şəklinə yerləşdiriləcək.

2 etiketli sətir kodu haradan əldə edəcəyinizi bildirir. Bizim vəziyyətimizdə bu, git deposudur və yer, ref və kontekst qovluğu yuxarıda gördüyümüz parametrlərlə müəyyən edilir.

3 etiketli xətt artıq parametrlər bölməsində gördüyümüz şeydir. O, bizim nümunəmizdə qurulan OUTPUT_DIR mühit dəyişənini əlavə edir.
4 etiketli xətt artıq ImageStream bölməsində gördüyümüz web-app-builder-runtime təsvirindən istifadə etməyi nəzərdə tutur.

5 etiketli sətir S2I şəkli və Veb Tətbiq Qurucusu şəklini dəstəklədiyi təqdirdə artımlı quruluşdan istifadə etmək istədiyimizi söyləyir. İlk işə salınmada, montaj mərhələsi başa çatdıqdan sonra, şəkil node_modules qovluğunu arxiv faylında saxlayacaq. Sonra, sonrakı dövrlərdə, şəkil qurmaq vaxtını azaltmaq üçün sadəcə bu qovluğu açacaq.

Və nəhayət, 6 ilə işarələnmiş xətt nəyisə dəyişəndə ​​əl müdaxiləsi olmadan quraşdırmanın avtomatik işləməsini təmin edən bir neçə tetikleyicidir.

Ümumiyyətlə, bu olduqca standart bir quruluş konfiqurasiyasıdır.

İndi ikinci qurma konfiqurasiyasına nəzər salaq. Birincisinə çox bənzəyir, lakin bir mühüm fərq var.

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

Beləliklə, ikinci qurma konfiqurasiyası react-web-app-runtime-dır və olduqca standart olaraq başlayır.

1 etiketli xətt yeni bir şey deyil - sadəcə olaraq, qurulma nəticəsinin react-web-app-runtime şəklinə daxil edildiyini söyləyir.

Əvvəlki konfiqurasiyada olduğu kimi 2 etiketli sətir mənbə kodunu haradan əldə etmək lazım olduğunu göstərir. Amma diqqət yetirin ki, burada biz onun təsvirdən götürüldüyünü deyirik. Üstəlik, indicə yaratdığımız təsvirdən - react-web-app-builder-dən (3 ilə işarələnmiş sətirdə göstərilmişdir). İstifadə etmək istədiyimiz fayllar şəklin içərisindədir və onların yeri 4 etiketli sətirdə göstərilib, bizim vəziyyətimizdə bu /opt/app-root/output/-dir. Xatırlayırsınızsa, tətbiqimizin qurulmasının nəticələrinə əsasən yaradılan fayllar burada saxlanılır.

5 etiketli termində göstərilən təyinat qovluğu sadəcə cari qovluqdur (hamısı, unutmayın ki, yerli kompüterinizdə deyil, OpenShift adlı sehrli şeyin içərisində işləyir).

Strategiya bölməsi – 6 ilə işarələnmiş xətt – ilk qurma konfiqurasiyasına bənzəyir. Yalnız bu dəfə artıq ImageStream bölməsində gördüyümüz nginx-image-runtime-dan istifadə edəcəyik.

Nəhayət, 7 etiketli sətir hər dəfə reaksiya veb-proqram qurucusu şəkli dəyişdikdə bu quruluşu aktivləşdirəcək tetikleyiciler bölməsidir.

Əks halda, bu şablonda kifayət qədər standart yerləşdirmə konfiqurasiyası, həmçinin xidmətlər və marşrutlarla əlaqəli şeylər var, lakin biz bu qədər təfərrüata girməyəcəyik. Nəzərə alın ki, yerləşdiriləcək şəkil react-web-app-runtime şəklidir.

Tətbiqin Yerləşdirilməsi

İndi şablonu nəzərdən keçirdikdən sonra tətbiqi yerləşdirmək üçün ondan necə istifadə edəcəyimizi görək.

Şablonumuzu yerləşdirmək üçün oc adlı OpenShift müştəri alətindən istifadə edə bilərik:

$ 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

Yuxarıdakı ekran görüntüsündəki ilk əmr şablon tapmaq üçün qəsdən mühəndislik üsuludur./openshiftio/application.yaml.

İkinci komanda sadəcə olaraq bu şablon əsasında yeni proqram yaradır.

Bu əmrlər işlədikdən sonra iki məclisimizin olduğunu görəcəyik:

Və Baxış ekranına qayıdaraq, işə salınmış podu görəcəyik:

Linkə klikləyin və biz defolt React Tətbiq səhifəsi olan tətbiqimizə aparılacağıq:

Əlavə 1

Angular sevənlər üçün bizdə də var nümunə tətbiqi.

OUTPUT_DIR dəyişəni istisna olmaqla, burada nümunə eynidir.

Əlavə 2

Bu yazıda biz NGINX-dən veb server kimi istifadə etdik, lakin onu Apache ilə əvəz etmək olduqca asandır, sadəcə olaraq fayldakı şablonu dəyişdirin. NGINX şəkli haqqında Apache şəkli.

Nəticə

Bu seriyanın birinci hissəsində biz OpenShift platformasında müasir veb proqramları necə tez yerləşdirməyi göstərdik. Bu gün biz Veb Tətbiq şəklinin nə etdiyini və daha çox istehsala hazır proqram quruluşu yaratmaq üçün zəncirlənmiş quruluşlardan istifadə edərək NGINX kimi təmiz veb serverlə necə birləşdirilə biləcəyinə baxdıq. Bu seriyanın növbəti və son məqaləsində biz OpenShift-də tətbiqiniz üçün inkişaf serverini necə idarə edəcəyinizi və yerli və uzaq faylların sinxronizasiyasını necə təmin edəcəyinizi göstərəcəyik.

Bu məqalələr seriyasının məzmunu

• Part 1: müasir veb proqramlarını bir neçə addımda necə yerləşdirmək olar;
• Hissə 2: İstehsalın yerləşdirilməsi üçün əlaqəli OpenShift birləşmələrindən istifadə edərək, NGINX kimi mövcud HTTP server təsviri ilə yeni S2I təsvirindən necə istifadə etmək olar;
• 3-cü hissə: OpenShift platformasında tətbiqiniz üçün inkişaf serverini necə işə salmaq və onu yerli fayl sistemi ilə sinxronlaşdırmaq.

Əlavə Resurslar

• Pulsuz e-kitab OpenShift-ə yerləşdirilir.
• haqqında məlumat OpenShift və Kubernetes.

Mənbə: www.habr.com