🔲 ⚓️ 🆖 最新のOpenShiftアプリケーション、パート3：開発環境としてのOpenShiftおよびOpenShiftパイプライン 🎹 🛬 👲🏿

このブログの皆さん、こんにちは！これは、Red HatOpenShiftに最新のWebアプリケーションをデプロイする方法を紹介するシリーズの3番目の投稿です。

前の2つの投稿では、最新のWebアプリケーションをわずか数ステップでデプロイする方法と、新しいS2IイメージをNGINXなどの既製のHTTPサーバーイメージとともに使用して、本番デプロイメントにチェーンビルドを使用する方法について説明しました。

今日は、OpenShiftプラットフォームでアプリケーションの開発サーバーを実行し、それをローカルファイルシステムと同期する方法を示します。また、OpenShift Pipelinesとは何か、リンクされたアセンブリの代わりに使用する方法についても説明します。

開発環境としてのOpenShift

開発ワークフロー

最初の投稿で説明したように、最新のWebアプリケーションの一般的な開発ワークフローは、ローカルファイルの変更を監視する単なる「開発サーバー」です。それらが発生すると、アプリケーションのビルドが開始され、ブラウザに更新されます。

最新のフレームワークのほとんどでは、この「開発サーバー」は対応するコマンドラインツールに組み込まれています。

ローカルの例

まず、アプリケーションをローカルで実行する場合にこれがどのように機能するかを見てみましょう。以前の記事のReactアプリを例として取り上げましょう。ただし、同じワークフローの概念の多くが他のすべての最新のフレームワークに適用されます。

したがって、Reactの例で「開発サーバー」を起動するには、次のコマンドを発行します。

$ npm run start

次に、ターミナルウィンドウに次のようなものが表示されます。

そして、アプリケーションはデフォルトのブラウザで開きます。

ここで、ファイルに変更を加えると、アプリケーションはブラウザーで更新されます。

OK、ローカル開発ではすべてが明確ですが、OpenShiftで同じことを達成するにはどうすればよいですか？

OpenShift開発サーバー

覚えているかと思いますが、前回の投稿で、S2Iイメージのいわゆる実行フェーズを分析し、デフォルトでサーブモジュールがWebアプリケーションのサービスを担当していることを確認しました。

ただし、その例の実行スクリプトを詳しく見ると、$ NPM_RUN環境変数が含まれていることがわかります。これにより、独自のコマンドを実行できます。

たとえば、nodeshiftモジュールを使用してアプリケーションをデプロイできます。

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

注：上記の例は、一般的な考え方を説明するために省略されています。

ここでは、NPM_RUN環境変数をデプロイメントに追加しました。これは、OpenShiftポッド内でReact開発サーバーを起動するyarnstartコマンドを実行するようにランタイムに指示します。

実行中のポッドのログを見ると、次のようなものがあります。

もちろん、ローカルコードを、変更が監視されているがリモートサーバー上にあるコードと同期できるようになるまで、これはほとんど何も起こりません。

リモートコードとローカルコードの同期

幸い、nodeshiftは同期に簡単に役立ち、watchコマンドを使用して変更を追跡できます。

したがって、アプリケーションの開発サーバーをデプロイするコマンドを実行した後、次のコマンドを安全に使用できます。

$ npx nodeshift watch

その結果、少し前に作成した実行中のポッドに接続され、ローカルファイルとリモートクラスターの同期がアクティブになり、ローカルシステム上のファイルの変更が監視されます。

したがって、src / App.jsファイルを更新すると、システムはこれらの変更に反応し、それらをリモートクラスターにコピーして開発サーバーを起動します。これにより、ブラウザーでアプリケーションが更新されます。

完全を期すために、これらのコマンド全体がどのように見えるかを示しましょう。

$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000

$ npx nodeshift watch --strictSSL=false

watchコマンドは、oc rsyncコマンドを抽象化したものであり、ここでどのように機能するかについて詳しく知ることができます。

これはReactの例ですが、他のフレームワークでもまったく同じ方法を使用できます。必要に応じてNPM_RUN環境変数を設定するだけです。

オープンシフトパイプライン

次に、OpenShift Pipelinesのようなツールと、それをチェーンビルドの代わりに使用する方法について説明します。

OpenShiftパイプラインとは

OpenShift Pipelinesは、Tektonを使用してパイプラインを編成するためのクラウドベースのCI / CD継続的統合および配信システムです。Tektonは、柔軟なオープンソースのKubernetesネイティブCI / CDフレームワークであり、基盤となるレイヤーから抽象化することにより、プラットフォーム（Kubernetes、サーバーレス、仮想マシンなど）全体の展開を自動化します。

この記事を理解するには、パイプラインに関するある程度の知識が必要です。そのため、最初に公式チュートリアルを読むことを強くお勧めします。

作業環境の設定

この記事の例を試すには、最初に実稼働環境を準備する必要があります。

OpenShift 4. CodeReady Containers (CRD), .
, , Pipeline Operator. , , .
Tekton CLI (tkn) .
create-react-app, , ( React).
() , npm install npm start.

アプリケーションリポジトリには、アプリケーションの展開に使用されるKubernetes / OpenShiftYAMLが配置されるk8sフォルダもあります。このリポジトリに作成するタスク、ClusterTasks、リソース、およびパイプラインがあります。

始めましょう

この例の最初のステップは、OpenShiftクラスターに新しいプロジェクトを作成することです。このプロジェクトをwebapp-pipelineと呼び、次のコマンドで作成しましょう。

$ oc new-project webapp-pipeline

さらに、プロジェクトのこの名前がコードに表示されるため、別の名前を付ける場合は、例のコードを適宜編集することを忘れないでください。この時点から、上から下に移動するのではなく、下から上に移動します。つまり、最初にコンベヤーのすべてのコンポーネントを作成し、次にそれ自体を作成します。

だから、まず第一に...

タスク

パイプライン内にアプリケーションをデプロイするのに役立ついくつかのタスクを作成しましょう。最初のタスク（apply_manifests_task）は、アプリケーションのk8sフォルダーにあるKubernetesリソース（サービス、デプロイメント、およびルート）にYAMLを適用する役割を果たします。2番目のタスク（update_deployment_task）は、既にデプロイされているイメージをパイプラインによって作成されたイメージに更新する役割を果たします。

まだはっきりしていなくても心配しないでください。実際、これらのタスクはユーティリティのようなものであり、後で詳しく説明します。今のところ、それらを作成しましょう：

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml

次に、tkn CLIコマンドを使用して、タスクが作成されていることを確認します。

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

注：これらは現在のプロジェクトのローカルタスクです。

クラスタータスク

クラスター化されたタスクは、基本的に単純なタスクと同じです。つまり、特定のタスクを開始するときに何らかの方法で組み合わされる、再利用可能なステップのコレクションです。違いは、クラスタータスクがクラスター内のどこでも利用できることです。パイプラインオペレータが追加されたときに自動的に作成されるクラスタタスクのリストを表示するには、もう一度tknCLIコマンドを使用します。

$ tkn clustertask ls

NAME                       AGE
buildah                    1 day ago
buildah-v0-10-0            1 day ago
jib-maven                  1 day ago
kn                         1 day ago
maven                      1 day ago
openshift-client           1 day ago
openshift-client-v0-10-0   1 day ago
s2i                        1 day ago
s2i-go                     1 day ago
s2i-go-v0-10-0             1 day ago
s2i-java-11                1 day ago
s2i-java-11-v0-10-0        1 day ago
s2i-java-8                 1 day ago
s2i-java-8-v0-10-0         1 day ago
s2i-nodejs                 1 day ago
s2i-nodejs-v0-10-0         1 day ago
s2i-perl                   1 day ago
s2i-perl-v0-10-0           1 day ago
s2i-php                    1 day ago
s2i-php-v0-10-0            1 day ago
s2i-python-3               1 day ago
s2i-python-3-v0-10-0       1 day ago
s2i-ruby                   1 day ago
s2i-ruby-v0-10-0           1 day ago
s2i-v0-10-0                1 day ago

次に、2つのクラスタータスクを作成しましょう。1つ目は、S2Iイメージを生成し、それを内部OpenShiftレジストリに送信します。2つ目は、コンテンツとして既にアセンブルしたアプリケーションを使用して、NGINXベースのイメージを構築することです。

画像を作成して送信する

最初のタスクを作成するときは、リンクされたアセンブリに関する前の記事ですでに行ったことを繰り返します。 S2Iイメージ（ubi8-s2i-web-app）を使用してアプリケーションを「ビルド」し、最終的にイメージが内部OpenShiftレジストリに保存されたことを思い出してください。ここで、WebアプリケーションのこのS2Iイメージを使用して、アプリケーションのDockerFileを作成し、Buildahを使用して実際のビルドを実行し、結果のイメージを内部OpenShiftレジストリにプッシュします。これは、OpenShiftをデプロイするときに行うこととまったく同じです。 NodeShiftを使用するアプリケーション。

どうやってこれをすべて知ったのですか？公式Node.jsの公式バージョンから、それをコピーして自分たちで完成させました。

そこで、s2i-web-appクラスタータスクを作成します。

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

これについては詳しく説明しませんが、OUTPUT_DIRパラメーターについて詳しく説明します。

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

デフォルトでは、このパラメーターはビルドに設定されています。ビルドは、Reactが収集したコンテンツを配置する場所です。他のフレームワークは異なるパスを使用します。たとえば、Emberはdistを使用します。最初のクラスタータスクの出力は、収集したHTML、JavaScript、およびCSSを含む画像になります。

NGINXに基づいてイメージを構築する

2番目のクラスタータスクについては、既に収集したアプリケーションのコンテンツを使用して、NGINXに基づいてイメージを収集する必要があります。基本的に、これは前のセクションでチェーンビルドについて説明した部分です。

これを行うには、上記と同じ方法で、クラスタータスクwebapp-build-runtimeを作成します。

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

これらのクラスタータスクのコードを見ると、使用しているGitリポジトリー、または作成したイメージの名前が指定されていないことがわかります。Gitに転送するもの、または最終的な画像を表示する特定の画像のみを指定します。これが、他のアプリケーションで作業するときにこれらのクラスタータスクを再利用できる理由です。

そしてここで私たちは優雅に次のポイントに移ります...

リソース

したがって、先ほど述べたように、クラスタータスクは可能な限り一般的なものにする必要があるため、入力（Gitリポジトリ）と出力（最終イメージ）で使用されるリソースを作成する必要があります。必要な最初のリソースは、アプリケーションが存在するGitです。次のようなものです。

# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: web-application-repo
spec:
  type: git
  params:
    - name: url
      value: https://github.com/nodeshift-starters/react-pipeline-example
    - name: revision
      value: master

ここで、PipelineResourceのタイプはgitです。paramsセクションのurlキーは、特定のリポジトリを指し、マスターブランチを設定します（これはオプションですが、完全を期すために記述します）。

次に、s2i-web-appタスクの結果が保存されるイメージのリソースを作成する必要があります。これは次のように実行されます。

# This resource is the result of running "npm run build",  the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: built-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest

ここで、PipelineResourceはimageタイプであり、urlパラメーター値は内部のOpenShift Image Registry、特にwebapp-pipeline名前空間内のレジストリを指します。別の名前名を使用している場合は、このパラメーターを変更することを忘れないでください。

そして最後に、必要な最後のリソースもイメージタイプであり、これが最終的なNGINXイメージになり、展開中に使用されます。

# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: runtime-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest

繰り返しになりますが、このリソースは、webapp-pipeline名前名の内部OpenShiftレジストリにイメージを格納していることに注意してください。

これらすべてのリソースを一度に作成するには、createコマンドを使用します。

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

リソースが次のように作成されていることを確認できます。

$ tkn resource ls

パイプラインパイプライン

必要なコンポーネントがすべて揃ったので、それらからパイプラインを組み立て、次のコマンドで作成します。

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

ただし、このコマンドを実行する前に、これらのコンポーネントを見てみましょう。最初は名前です：

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

次に、仕様セクションに、前に作成したリソースの表示が表示されます。

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

次に、パイプラインが完了するタスクを作成します。まず、彼は私たちがすでに作成したs2i-web-appタスクを実行する必要があります。

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

このタスクは、入力（gir-resource）および出力（built-web-application-image resource）パラメーターを取ります。また、自己署名証明書を使用しているため、TLSを検証しないように、特別なパラメーターを渡します。

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

次のタスクはほとんど同じですが、ここでのみ、すでに作成されているwebapp-build-runtimeクラスタータスクが呼び出されます。

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

前のタスクと同様に、リソースを渡しますが、これはbuilt-web-application-image（前のタスクの出力）になりました。そして出力として、再び画像を設定します。このタスクは前のタスクの後に実行する必要があるため、runAfterフィールドを追加します。

resources:
        inputs:
          - name: image
            resource: built-web-application-image
        outputs:
          - name: image
            resource: runtime-web-application-image
        params:
        - name: TLSVERIFY
          value: "false"
      runAfter:
        - build-web-application

次の2つのタスクは、Webアプリケーションのk8sディレクトリにあるサービス、ルート、およびデプロイメントにYAMLファイルを適用し、新しいイメージを作成するときにこのデプロイメントを更新する役割を果たします。記事の冒頭で、これら2つのクラスタータスクを設定しました。

コンベヤーの実行

したがって、パイプラインのすべての部分が作成され、次のコマンドで開始します。

$ tkn pipeline start build-and-deploy-react

この段階では、コマンドラインがインタラクティブに使用され、各リクエストに応じて適切なリソースを選択する必要があります。gitリソースの場合はweb-application-repoを選択し、最初のイメージのリソースの場合はbuilt-web-application-imageを選択し、最後に2番目の画像リソース–runtime-web-application-image：

? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr

次に、次のコマンドを使用してパイプラインのステータスを確認しましょう。

$ tkn pipeline logs -f

パイプラインが開始され、アプリケーションがデプロイされたら、次のコマンドを使用して公開ルートを要求します。

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

見やすくするために、図に示すように、パイプラインセクションのWebコンソールの開発者モードでパイプラインを表示できます。1.1。

図1。実行中のパイプラインの概要。

図2に示すように、実行中のパイプラインをクリックすると、追加情報が表示されます。

図：2.パイプラインに関する詳細情報。

詳細を確認すると、図3に示すように、実行中のアプリケーションがトポロジビューに表示されます。

図3.実行中のポッド。

図4に示すように、アイコンの右上隅にある円をクリックすると、アプリケーションが開きます。

図：4.Reactアプリケーションを起動しました。

結論

そこで、OpenShiftでアプリケーションの開発サーバーを実行し、ローカルファイルシステムと同期する方法を示しました。また、OpenShiftPipelinesを使用してチェーンビルドテンプレートを模倣する方法についても説明しました。この記事のすべてのサンプルコードは、ここにあります。

追加リソース（EN）

今後のウェビナーの発表

Red Hat OpenShift Container PlatformとKubernetesのネイティブエクスペリエンスに関する一連の金曜日のウェビナーを開始します。

最新のOpenShiftアプリケーション、パート3：開発環境としてのOpenShiftおよびOpenShiftパイプライン