最新のOpenShiftアプリ、パート2：チェーンビルド

こんにちは！これはシリーズの2番目の投稿であり、Red HatOpenShiftに最新のWebアプリケーションをデプロイする方法を紹介します。







前回の投稿では、OpenShiftプラットフォームで最新のWebアプリケーションを構築および展開するように設計された、新しいS2I（ソースからイメージ）ビルダーイメージの機能について少し触れました。次に、アプリケーションの迅速な展開のトピックに関心がありましたが、今日は、S2Iイメージを「クリーンな」ビルダーイメージとして使用し、関連するOpenShiftアセンブリと組み合わせる方法を見ていきます。

きれいなビルダー画像

最初の部分で述べたように、ほとんどの最新のWebアプリケーションには、いわゆるビルドステージがあり、通常、コードの変換、複数のファイルの連結、ミニファイなどの操作を実行します。結果のファイル（静的HTML、JavaScript、およびCSS）が出力フォルダーに追加されます。このフォルダの場所は通常、使用されているビルドツールによって異なり、Reactの場合、これは./buildフォルダになります（これについては、以下で詳しく説明します）。

ソースからイメージ（S2I）

この投稿では、S2Iとは何か、およびその使用方法についてはまったく説明していません（詳細については、こちらを参照してください）が、Web App Builderイメージの機能を理解するには、このプロセスの2つの段階について明確にすることが重要です。

組み立て段階

組み立て手順は、本質的に、docker buildを実行して、新しいDockerイメージを作成したときに発生する手順と非常によく似ています。したがって、この段階は、OpenShiftプラットフォームでビルドを開始するときに発生します。



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



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

実行フェーズ

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



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



つまり、組み立て中に1つ、実行中にもう1つ必要です。ここで、チェーンビルドが役立ちます。

連鎖ビルド

OpenShiftのドキュメントにチェーンビルド について書かれている内容は次のとおりです。

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

つまり、Web App Builderイメージを使用してビルドを実行し、次にWebサーバーイメージNGINXを使用してコンテンツを提供できます。



したがって、Web App Builderイメージを純粋なビルダーとして使用しても、実行時イメージは小さくなります。



それでは、具体的な例でこれを見てみましょう。



このチュートリアルでは、create-react-appコマンドラインツールで構築された単純なReactアプリケーションを使用します。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'

3番目と4番目の画像を見てください。どちらもDockerイメージとして定義されており、どこから来たのかがはっきりとわかります。



3番目の画像はweb-app-builderで、Dockerハブに10.xタグが付いたnodeshift / ubi8-s2i-web-appから取得されます。



4つ目は、Dockerハブに最新のタグが付いたNGINXイメージ（バージョン1.12）です。



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



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



混乱していますか？次に、ビルド構成を見てみましょう。少し明確になります。



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

  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リポジトリであり、場所、ref、およびコンテキストフォルダは、上記ですでに見たパラメータによって定義されます。



3というラベルの付いた行は、パラメータセクションにすでに表示されています。この例でビルドされているOUTPUT_DIR環境変数を追加します。

4というラベルの付いた行は、ImageStreamセクションですでに見たweb-app-builder-runtimeイメージを使用することを示しています。



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



そして最後に、6というラベルの付いた行は、何かが変更されたときに手動の介入なしでビルドが自動的に開始されるように、ほんの数個のトリガーです。



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



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

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

したがって、2番目のビルド構成は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

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



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



これらのコマンドを実行すると、2つのアセンブリがあることがわかります。







概要画面に戻ると、ポッドが起動します。







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

付録1

Angular愛好家のために、サンプルアプリもあります。



テンプレートは、OUTPUT_DIR変数を除いて、ここでも同じです。

付録2

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

結論

このシリーズの最初のパートでは、OpenShiftプラットフォームに最新のWebアプリケーションをすばやくデプロイする方法を紹介しました。今日は、Webアプリイメージを作成するものと、チェーンビルドを使用してNGINXなどの純粋なWebサーバーと組み合わせて、より本番環境に対応したアプリビルドを作成する方法について説明しました。このシリーズの次の最後の記事では、OpenShiftでアプリケーションの開発サーバーを実行し、ローカルファイルとリモートファイルの同期を維持する方法を示します。

この記事シリーズの内容

• パート1：わずか数ステップで最新のWebアプリケーションを展開する方法;
• パート2：関連するOpenShiftアセンブリを使用して本番デプロイメントを編成し、既存のHTTPサーバーイメージ（NGINXなど）とともに新しいS2Iイメージを使用する方法。
• 3: OpenShift .

• Deploying to OpenShift.
• OpenShift Kubernetes.