Nowoczesne aplikacje na OpenShift, część 2: kompilacje łańcuchowe

Cześć wszystkim! To drugi post z naszej serii, w którym pokazujemy, jak wdrażać nowoczesne aplikacje internetowe na Red Hat OpenShift.

W poprzednim poście poruszyliśmy nieco możliwości nowego obrazu buildera S2I (source-to-image), który przeznaczony jest do budowania i wdrażania nowoczesnych aplikacji webowych na platformie OpenShift. Potem zainteresował nas temat szybkiego wdrażania aplikacji, a dzisiaj przyjrzymy się, jak wykorzystać obraz S2I jako „czysty” obraz buildera i połączyć go z powiązanymi złożeniami OpenShift.

Czysty obraz konstruktora

Jak wspomnieliśmy w części XNUMX, większość nowoczesnych aplikacji internetowych ma tak zwany etap kompilacji, podczas którego zazwyczaj wykonywane są takie operacje, jak transpilacja kodu, łączenie wielu plików i minifikacja. Pliki uzyskane w wyniku tych operacji - a jest to statyczny kod HTML, JavaScript i CSS - przechowywane są w folderze wyjściowym. Lokalizacja tego folderu zwykle zależy od używanych narzędzi do budowania, a w przypadku React będzie to folder ./build (powrócimy do tego bardziej szczegółowo poniżej).

Źródło do obrazu (S2I)

W tym poście nie poruszamy tematu „czym jest S2I i jak z niego korzystać” (więcej na ten temat możesz przeczytać tutaj), ale ważne jest, aby mieć jasność co do dwóch etapów tego procesu, aby zrozumieć, do czego służy obraz narzędzia Web App Builder.

Faza montażu

Faza montażu ma bardzo podobny charakter do tego, co dzieje się, gdy uruchamiasz kompilację Dockera i kończysz na nowym obrazie Dockera. Odpowiednio ten etap ma miejsce podczas rozpoczynania kompilacji na platformie OpenShift.

W przypadku obrazu Web App Builder jest on odpowiedzialny za zainstalowanie zależności aplikacji i uruchomienie kompilacji. złożyć skrypt. Domyślnie obraz konstruktora używa konstrukcji build build npm run, ale można to zastąpić za pomocą zmiennej środowiskowej NPM_BUILD.

Jak powiedzieliśmy wcześniej, lokalizacja gotowej, już zbudowanej aplikacji zależy od tego, jakich narzędzi użyjesz. Na przykład w przypadku React będzie to folder ./build, a dla aplikacji Angular będzie to folder nazwa_projektu/dist. Jak już pokazano w poprzednim poście, lokalizację katalogu wyjściowego, który jest domyślnie ustawiony na kompilację, można zastąpić zmienną środowiskową OUTPUT_DIR. Cóż, ponieważ lokalizacja folderu wyjściowego różni się w zależności od platformy, po prostu kopiujesz wygenerowane dane wyjściowe do standardowego folderu na obrazie, a mianowicie /opt/apt-root/output. Jest to ważne dla zrozumienia reszty tego artykułu, ale na razie przyjrzyjmy się szybko kolejnemu etapowi – fazie uruchamiania.

faza biegu

Ten etap ma miejsce, gdy na nowym obrazie utworzonym na etapie montażu wykonywane jest wywołanie docker run. To samo dzieje się podczas wdrażania na platformie OpenShift. Domyślny uruchom skrypt używa moduł obsługowy do obsługi zawartości statycznej znajdującej się w powyższym standardowym katalogu wyjściowym.

Ta metoda jest dobra do szybkiego wdrażania aplikacji, ale generalnie nie jest zalecana do udostępniania zawartości statycznej w ten sposób. Cóż, ponieważ w rzeczywistości udostępniamy tylko zawartość statyczną, nie potrzebujemy instalowanego Node.js w naszym obrazie – wystarczy serwer WWW.

Innymi słowy, podczas montażu potrzebujemy jednej rzeczy, podczas wykonywania potrzebujemy drugiej. W tej sytuacji z pomocą przychodzą kompilacje łańcuchowe.

Połączone kompilacje

O tym piszą konstrukcje łańcuchowe w dokumentacji OpenShift:

„Można połączyć ze sobą dwa zespoły, z których jeden generuje skompilowaną jednostkę, a drugi przechowuje tę jednostkę w osobnym obrazie używanym do uruchamiania tej jednostki”.

Innymi słowy, możemy użyć obrazu narzędzia Web App Builder do uruchomienia naszej kompilacji, a następnie użyć obrazu serwera WWW, tego samego NGINX, do obsługi naszej zawartości.

Dzięki temu możemy używać obrazu Web App Builder jako „czystego” kreatora, a jednocześnie mieć mały obraz wykonawczy.

Teraz spójrzmy na to na konkretnym przykładzie.

Do treningu będziemy używać prosta aplikacja React, utworzony przy użyciu narzędzia wiersza poleceń create-react-app.

Pomoże nam to wszystko poskładać w całość Plik szablonu OpenShift.

Przyjrzyjmy się temu plikowi bardziej szczegółowo i zacznijmy od sekcji parametrów.

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

Wszystko tutaj jest dość jasne, warto jednak zwrócić uwagę na parametr OUTPUT_DIR. W przypadku aplikacji React z naszego przykładu nie ma się czym martwić, ponieważ React używa domyślnej wartości jako folderu wyjściowego, ale w przypadku Angulara lub innego parametru ten będzie musiał zostać zmieniony w razie potrzeby.

Przyjrzyjmy się teraz sekcji 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'

Spójrz na trzeci i czwarty obraz. Obydwa są zdefiniowane jako obrazy Dockera i można wyraźnie zobaczyć, skąd pochodzą.

Trzeci obraz to narzędzie do tworzenia aplikacji internetowych i pochodzi z aplikacji Nodeshift/ubi8-s2i-web-app oznaczonej 10.x na Centrum Dockera.

Czwarty to obraz NGINX (wersja 1.12) z najnowszym tagiem Centrum Dockera.

Przyjrzyjmy się teraz dwóm pierwszym obrazom. Obydwa są puste na początku i powstają dopiero w fazie budowy. Pierwszy obraz, reagujący-web-app-builder, będzie wynikiem etapu montażu, który połączy obraz środowiska uruchomieniowego web-app-builder-builder i nasz kod źródłowy. Dlatego dodaliśmy „-builder” do nazwy tego obrazu.

Drugi obraz - reagują-web-app-runtime - będzie wynikiem połączenia nginx-image-runtime i niektórych plików z obrazu Reaguj-web-app-builder. Ten obraz będzie również używany podczas wdrażania i będzie zawierał tylko serwer WWW oraz statyczny kod HTML, JavaScript i CSS naszej aplikacji.

Zdezorientowany? Przyjrzyjmy się teraz konfiguracjom kompilacji, a stanie się to trochę jaśniejsze.

Nasz szablon ma dwie konfiguracje kompilacji. Oto pierwszy z nich, dość standardowy:

  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

Jak widać, linia z etykietą 1 mówi, że wynik tej kompilacji zostanie umieszczony w tym samym obrazie narzędzia do tworzenia aplikacji internetowych reagujących, który widzieliśmy nieco wcześniej w sekcji ImageStreams.

Linia oznaczona numerem 2 informuje, skąd pobrać kod. W naszym przypadku jest to repozytorium git, a lokalizację, folder referencyjny i kontekstowy określają parametry, które widzieliśmy powyżej.

Linię oznaczoną numerem 3 widzieliśmy już w sekcji parametrów. Dodaje zmienną środowiskową OUTPUT_DIR, którą w naszym przykładzie jest build.
Linia oznaczona liczbą 4 mówi, aby użyć obrazu środowiska wykonawczego aplikacji internetowej, który widzieliśmy już w sekcji ImageStream.

Linia oznaczona numerem 5 mówi, że chcemy użyć kompilacji przyrostowej, jeśli obraz S2I ją obsługuje i obsługuje to obraz narzędzia Web App Builder. Przy pierwszym uruchomieniu, po zakończeniu etapu montażu, obraz zapisze folder node_modules do pliku archiwum. Następnie przy kolejnych uruchomieniach obraz po prostu rozpakuje ten folder, aby skrócić czas kompilacji.

I na koniec, linia oznaczona numerem 6 to tylko kilka wyzwalaczy, dzięki którym kompilacja będzie uruchamiana automatycznie, bez ręcznej interwencji, gdy coś się zmieni.

Ogólnie rzecz biorąc, jest to dość standardowa konfiguracja kompilacji.

Przyjrzyjmy się teraz drugiej konfiguracji kompilacji. Jest bardzo podobny do pierwszego, ale jest jedna istotna różnica.

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

Zatem druga konfiguracja kompilacji to środowisko wykonawcze aplikacji internetowej reagującej i zaczyna się całkiem standardowo.

Wiersz oznaczony numerem 1 nie jest niczym nowym — po prostu mówi, że wynik kompilacji jest umieszczany w obrazie środowiska wykonawczego aplikacji reagującej.

Linia oznaczona numerem 2, podobnie jak w poprzedniej konfiguracji, wskazuje, skąd można pobrać kod źródłowy. Ale zauważ, że tutaj mówimy, że jest to wzięte z obrazu. Co więcej, z obrazu, który właśnie stworzyliśmy - z narzędzia reagującego-web-app-builder (wskazanego w linii oznaczonej 3). Pliki, których chcemy użyć, znajdują się wewnątrz obrazu, a ich lokalizacja jest ustawiona w linii oznaczonej numerem 4, w naszym przypadku jest to /opt/app-root/output/. Jeśli pamiętasz, to tutaj przechowywane są pliki wygenerowane na podstawie wyników budowy naszej aplikacji.

Folder docelowy określony w terminie z etykietą 5 to po prostu katalog bieżący (pamiętaj, że to wszystko działa w jakiejś magicznej rzeczy zwanej OpenShift, a nie na twoim komputerze lokalnym).

Sekcja strategii – linia oznaczona numerem 6 – jest również podobna do konfiguracji z pierwszej kompilacji. Tylko tym razem użyjemy środowiska nginx-image-runtime, które widzieliśmy już w sekcji ImageStream.

Na koniec linia oznaczona numerem 7 to sekcja wyzwalaczy, które aktywują tę kompilację za każdym razem, gdy zmieni się obraz narzędzia Reaguj-web-app-builder.

W przeciwnym razie ten szablon zawiera dość standardową konfigurację wdrożenia, a także elementy związane z usługami i trasami, ale nie będziemy wdawać się w zbyt wiele szczegółów. Należy pamiętać, że obraz, który zostanie wdrożony, to obraz środowiska uruchomieniowego aplikacji internetowej reagującej.

Wdrożenie aplikacji

Skoro już przyjrzeliśmy się szablonowi, zobaczmy, jak go użyć do wdrożenia aplikacji.

Do wdrożenia naszego szablonu możemy użyć narzędzia klienckiego OpenShift o nazwie 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

Pierwsze polecenie na powyższym zrzucie ekranu to celowo inżynieryjny sposób na znalezienie szablonu./openshiftio/application.yaml.

Drugie polecenie po prostu tworzy nową aplikację w oparciu o ten szablon.

Gdy te polecenia zadziałają, zobaczymy, że mamy dwa złożenia:

Wracając do ekranu Przegląd, zobaczymy uruchomiony zasobnik:

Kliknij link, a zostaniemy przeniesieni do naszej aplikacji, która jest domyślną stroną aplikacji React:

Dodatek 1

Dla miłośników Angulara też mamy przykładowa aplikacja.

Schemat tutaj jest taki sam, z wyjątkiem zmiennej OUTPUT_DIR.

Dodatek 2

W tym artykule użyliśmy NGINX jako serwera WWW, ale dość łatwo jest go zastąpić Apache, wystarczy zmienić szablon w pliku obraz NGINX na Obraz Apacza.

wniosek

W pierwszej części tego cyklu pokazaliśmy jak szybko wdrożyć nowoczesne aplikacje webowe na platformie OpenShift. Dzisiaj przyjrzeliśmy się, co robi obraz aplikacji internetowej i jak można go połączyć z czystym serwerem internetowym, takim jak NGINX, używając kompilacji łańcuchowych, aby stworzyć wersję aplikacji bardziej gotową do produkcji. W kolejnym i ostatnim artykule z tej serii pokażemy, jak uruchomić serwer deweloperski dla Twojej aplikacji na OpenShift i zapewnić synchronizację plików lokalnych i zdalnych.

Treść tej serii artykułów

• Część 1: jak wdrożyć nowoczesne aplikacje internetowe w zaledwie kilku krokach;
• Część 2: Jak używać nowego obrazu S2I z istniejącym obrazem serwera HTTP, takim jak NGINX, przy użyciu powiązanych zestawów OpenShift do wdrożenia produkcyjnego;
• Część 3: jak uruchomić serwer deweloperski dla swojej aplikacji na platformie OpenShift i zsynchronizować go z lokalnym systemem plików.

Dodatkowe zasoby

• Darmowy e-book Wdrażanie w OpenShift.
• Informacje o OpenShift i Kubernetes.

Źródło: www.habr.com