OpenShift 上の最新アプリケーション、パート 2: チェーンされたビルド

こんにちは、みんな！ これは、Red Hat OpenShift に最新の Web アプリケーションをデプロイする方法を説明するシリーズの XNUMX 番目の投稿です。

前回の投稿では、OpenShift プラットフォーム上で最新の Web アプリケーションを構築およびデプロイするために設計された、新しい S2I (source-to-image) ビルダー イメージの機能について少し触れました。 次に、アプリケーションを迅速にデプロイするというトピックに興味を持ちました。今日は、S2I イメージを「純粋な」ビルダー イメージとして使用し、それを関連する OpenShift アセンブリと組み合わせる方法を見ていきます。

クリーンなビルダーイメージ

第 XNUMX 回で述べたように、最新の Web アプリケーションのほとんどにはいわゆるビルド ステージがあり、通常はコードのトランスパイル、複数のファイルの連結、縮小などの操作を実行します。 これらの操作の結果として取得されたファイル (これは静的 HTML、JavaScript、および CSS) は出力フォルダーに保存されます。 通常、このフォルダーの場所は、使用されているビルド ツールによって異なります。React の場合、これは ./build フォルダーになります (これについては、後で詳しく説明します)。

ソースからイメージへ (S2I)

この投稿では、「S2I とは何か、そしてその使用方法」というトピックには触れません (これについて詳しくは、こちらをご覧ください) ここで) ですが、Web App Builder イメージの機能を理解するには、このプロセスの XNUMX つのステップを明確にすることが重要です。

組み立て段階

アセンブリフェーズは、docker build を実行して新しい Docker イメージが作成されるときに起こることと本質的によく似ています。 したがって、この段階は、OpenShift プラットフォームでビルドを開始するときに発生します。

Web App Builder イメージの場合、アプリケーションの依存関係をインストールし、ビルドを実行します。 アセンブルスクリプト。 デフォルトでは、ビルダー イメージは npm run ビルド構造を使用しますが、これは NPM_BUILD 環境変数を通じてオーバーライドできます。

前に述べたように、完成した、すでに構築されたアプリケーションの場所は、使用するツールによって異なります。 たとえば、React の場合、これは ./build フォルダーになり、Angular アプリケーションの場合は project_name/dist フォルダーになります。 また、前の投稿ですでに示したように、デフォルトでビルドするように設定されている出力ディレクトリの場所は、OUTPUT_DIR 環境変数を使用してオーバーライドできます。 出力フォルダーの場所はフレームワークごとに異なるため、生成された出力をイメージ内の標準フォルダー (/opt/apt-root/output) にコピーするだけです。 これはこの記事の残りの部分を理解するために重要ですが、ここでは次の段階である実行フェーズを簡単に見てみましょう。

実行フェーズ

この段階は、アセンブリ段階で作成された新しいイメージに対して docker run への呼び出しが行われたときに発生します。 OpenShift プラットフォームにデプロイする場合も同じことが起こります。 デフォルト スクリプトを実行する 使用する サーブモジュール 上記の標準出力ディレクトリにある静的コンテンツを提供します。

この方法はアプリケーションを迅速に展開する場合に適していますが、静的コンテンツをこの方法で提供することは一般的に推奨されません。 実際には静的なコンテンツのみを提供するため、イメージ内に Node.js をインストールする必要はありません。Web サーバーで十分です。

言い換えれば、組み立てるときに必要なものは XNUMX つあり、実行するときには別のものが必要になるということです。 このような状況では、チェーン ビルドが役に立ちます。

連鎖ビルド

これが彼らが書いていることです 連鎖ビルド OpenShift ドキュメントでは次のようになります。

「XNUMX つのアセンブリをリンクできます。XNUMX つはコンパイル済みエンティティを生成し、もう XNUMX つはそのエンティティを実行するために使用される別のイメージでそのエンティティをホストします。」

つまり、Web App Builder イメージを使用してビルドを実行し、Web サーバー イメージ (同じ 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'

XNUMX枚目とXNUMX枚目の画像をご覧ください。 これらはどちらも Docker イメージとして定義されており、どこから来たのかが明確にわかります。

8 番目のイメージは web-app-builder で、2.x でタグ付けされたnodeshift/ubi10-sXNUMXi-web-app から取得されます。 Dockerハブ.

1.12 番目は、最新のタグが付けられた NGINX イメージ (バージョン XNUMX) です。 Dockerハブ.

それでは最初の XNUMX つの画像を見てみましょう。 これらは両方とも開始時には空であり、ビルドフェーズ中にのみ作成されます。 最初のイメージ、react-web-app-builder は、web-app-builder-runtime イメージとソース コードを結合するアセンブリ ステップの結果です。 このため、このイメージの名前に「-builder」を追加しました。

XNUMX 番目のイメージ (react-web-app-runtime) は、nginx-image-runtime と、react-web-app-builder イメージのいくつかのファイルを組み合わせた結果になります。 このイメージは展開時にも使用され、アプリケーションの Web サーバーと静的 HTML、JavaScript、CSS のみが含まれます。

混乱した？ 次に、ビルド構成を見てみましょう。これにより、もう少し明確になります。

私たちのテンプレートには XNUMX つのビルド構成があります。 これが最初のもので、非常に標準的なものです。

  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 の行は、このビルドの結果が、ImageStreams セクションで少し前に見たものと同じreact-web-app-builder イメージに配置されることを示しています。

2 というラベルの付いた行は、コードの取得元を示します。 この場合、これは git リポジトリであり、場所、参照、およびコンテキスト フォルダーは、上ですでに説明したパラメーターによって決定されます。

3 というラベルの付いた行は、パラメーター セクションですでに見たものです。 OUTPUT_DIR 環境変数 (この例では build) が追加されます。
4 というラベルの付いた行は、ImageStream セクションですでに見た web-app-builder-runtime イメージを使用することを示しています。

5 というラベルの行は、S2I イメージがインクリメンタル ビルドをサポートしており、Web App Builder イメージがインクリメンタル ビルドをサポートしている場合にインクリメンタル ビルドを使用することを示しています。 最初の起動時、アセンブリ段階が完了した後、イメージは、node_modules フォルダーをアーカイブ ファイルに保存します。 その後の実行では、イメージはビルド時間を短縮するためにこのフォルダーを単純に解凍します。

最後に、6 というラベルの付いた行は、何かが変更されたときに手動介入なしで自動的にビルドを実行するためのいくつかのトリガーです。

全体的に、これはかなり標準的なビルド構成です。

次に、XNUMX 番目のビルド構成を見てみましょう。 最初のものとよく似ていますが、重要な違いが XNUMX つあります。

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

したがって、XNUMX 番目のビルド構成は、react-web-app-runtime であり、非常に標準的なものから始まります。

1 というラベルの付いた行は新しいものではありません。単に、ビルド結果が React-web-app-runtime イメージに入れられることを示しています。

前の構成と同様に、2 というラベルの付いた行は、ソース コードの入手先を示します。 ただし、ここでは画像から取得したと言っていることに注意してください。 さらに、作成したばかりのイメージ、react-web-app-builder (3 番の行に示されています) からのものです。 使用したいファイルはイメージ内にあり、その場所は 4 というラベルの付いた行で設定されています。この場合は /opt/app-root/output/ です。 覚えていると思いますが、ここにはアプリケーションの構築結果に基づいて生成されたファイルが保存されます。

ラベル 5 の用語で指定されている宛先フォルダーは、単に現在のディレクトリです (これはすべて、ローカル コンピューター上ではなく、OpenShift と呼ばれる魔法の内部で実行されているということを覚えておいてください)。

戦略セクション (6 というラベルが付いた行) も、最初のビルド構成と似ています。 今回のみ、ImageStream セクションですでに見た nginx-image-runtime を使用します。

最後に、7 というラベルの付いた行は、react-web-app-builder イメージが変更されるたびにこのビルドをアクティブ化するトリガーのセクションです。

それ以外の場合、このテンプレートには非常に標準的なデプロイメント構成と、サービスとルートに関連するものが含まれていますが、これについてはあまり詳しく説明しません。 デプロイされるイメージは、react-web-app-runtime イメージであることに注意してください。

アプリケーションの導入

テンプレートを確認したので、それを使用してアプリケーションをデプロイする方法を見てみましょう。

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

上のスクリーンショットの最初のコマンドは、template./openshiftio/application.yaml を見つけるための意図的なエンジニアリング方法です。

XNUMX 番目のコマンドは、このテンプレートに基づいて新しいアプリケーションを作成するだけです。

これらのコマンドが機能すると、XNUMX つのアセンブリがあることがわかります。

そして、概要画面に戻ると、起動されたポッドが表示されます。

リンクをクリックすると、デフォルトの React App ページであるアプリに移動します。

サプリメント1

Angular 愛好家のために、次のものも用意しています。 アプリケーション例.

ここのパターンは、OUTPUT_DIR 変数を除いて同じです。

サプリメント2

この記事では Web サーバーとして NGINX を使用しましたが、Apache に置き換えるのは非常に簡単で、ファイル内のテンプレートを変更するだけです。 NGINX イメージ на Apache イメージ.

まとめ

このシリーズの最初の部分では、最新の Web アプリケーションを OpenShift プラットフォームに迅速にデプロイする方法を説明しました。 今日は、Web アプリ イメージの役割と、チェーン ビルドを使用して、Web アプリ イメージを NGINX のような純粋な Web サーバーと組み合わせて、より本番環境に対応したアプリケーション ビルドを作成する方法について説明しました。 このシリーズの次の最終記事では、OpenShift 上でアプリケーションの開発サーバーを実行し、ローカル ファイルとリモート ファイルの同期を確保する方法を説明します。

このシリーズの記事の内容

• パート1： わずか数ステップで最新の Web アプリケーションをデプロイする方法;
• パート 2: 本番デプロイメントに関連する OpenShift アセンブリを使用して、NGINX などの既存の HTTP サーバー イメージで新しい S2I イメージを使用する方法。
• パート 3: OpenShift プラットフォーム上でアプリケーションの開発サーバーを実行し、ローカル ファイル システムと同期する方法。

追加リソース

• 無料の電子書籍 OpenShift へのデプロイ.
• 情報 OpenShift と Kubernetes.

出所： habr.com