🥇OpenShift 上の最新アプリケーション、パート 3: 開発環境としての OpenShift と OpenShift Pipelines

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

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

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

開発環境としての OpenShift

開発ワークフロー

で述べたように最初の投稿、最新の Web アプリケーションの典型的な開発プロセスは、ローカルファイルへの変更を追跡するある種の「開発サーバー」にすぎません。これらが発生すると、アプリケーションのビルドがトリガーされ、ブラウザーに更新されます。

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

地元の例

まず、アプリケーションをローカルで実行するときにこれがどのように機能するかを見てみましょう。アプリケーションを例に挙げてみましょう反応するただし、ほぼ同じワークフロー概念が他のすべての最新フレームワークに適用されます。
したがって、React の例で「開発サーバー」を起動するには、次のコマンドを入力します。

$ npm run start

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

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

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

ローカルモードでの開発についてはすべて明らかですが、OpenShift で同じことを実現するにはどうすればよいでしょうか?

OpenShift 上の開発サーバー

覚えていれば、前の投稿S2I イメージのいわゆる実行フェーズを調べたところ、デフォルトでは、serv モジュールが Web アプリケーションのサービスを担当していることがわかりました。

しかし、よく見てみるとスクリプトを実行するこの例では、コマンドを実行できるようにする $NPM_RUN 環境変数が含まれています。

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

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

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

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

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

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

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

幸いなことに、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 パイプライン

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

OpenShift パイプラインとは

OpenShift Pipelines は、Tekton を使用してパイプラインを編成するために設計されたクラウドネイティブ CI/CD 継続的統合および配信システムです。 Tekton は、柔軟なオープンソースの Kubernetes ネイティブ CI/CD フレームワークで、基礎となるレイヤーから抽象化することで、さまざまなプラットフォーム (Kubernetes、サーバーレス、仮想マシンなど) でのデプロイメントを自動化できます。

この記事を理解するには、パイプラインに関するある程度の知識が必要となるため、最初に読むことを強くお勧めします。公式教科書.

作業環境をセットアップする

この記事の例を試してみるには、まず作業環境を準備する必要があります。

OpenShift 4 クラスターをインストールして構成します。この例では、これに CodeReady Containers (CRD) を使用しています。インストール手順については、こちらを参照してください。ここで.
クラスターの準備ができたら、それに Pipeline Operator をインストールする必要があります。心配しないでください、それは簡単です、インストール手順ここで.
ダウンロードテクトン CLI (tkn) ここで.
create-react-app コマンドラインツールを実行して、デプロイするアプリケーションを作成します (これは単純なアプリケーションです) 反応する).
(オプション) リポジトリのクローンを作成し、npm install してから npm start を使用してサンプルアプリケーションをローカルで実行します。

アプリケーションリポジトリには、アプリケーションのデプロイに使用される Kubernetes/OpenShift YAML が含まれる k8s フォルダーもあります。この中で作成するタスク、クラスタータスク、リソース、パイプラインがあります。リポジトリ.

降ります

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

$ oc new-project webapp-pipeline

このプロジェクト名は後でコードに表示されるため、別の名前を付けることにした場合は、それに応じてサンプルコードを編集することを忘れないでください。この時点から、トップダウンではなくボトムアップで作業を開始します。つまり、最初にコンベヤのすべてのコンポーネントを作成し、次にコンベヤ自体を作成します。

それで、まずは...

タスク

パイプライン内でアプリケーションをデプロイするのに役立ついくつかのタスクを作成しましょう。最初のタスク apply_manifests_task は、アプリケーションの k8s フォルダーにある Kubernetes リソース (サービス、デプロイメント、およびルート) の YAML を適用する役割を果たします。 XNUMX 番目のタスク - 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

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

クラスタータスク

クラスタータスクは基本的に単純なタスクと同じです。つまり、特定のタスクを実行するときに何らかの方法で結合される再利用可能なステップのコレクションです。違いは、クラスタータスクはクラスター内のどこでも利用できることです。 Pipeline Operator の追加時に自動的に作成されるクラスタータスクのリストを表示するには、tkn CLI コマンドを再度使用します。

$ 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 つのクラスタータスクを作成しましょう。 XNUMX つ目は SXNUMXI イメージを生成し、内部 OpenShift レジストリに送信します。 XNUMX つ目は、すでに構築したアプリケーションをコンテンツとして使用して、NGINX に基づいてイメージを構築することです。

画像を作成して送信する

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

どうやってこのようなことを知ったのでしょうか? から公式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

デフォルトでは、このパラメータは build と等しく、React がアセンブルされたコンテンツを配置する場所です。他のフレームワークは別のパスを使用します。たとえば、Ember では dist です。最初のクラスタータスクの出力は、収集した HTML、JavaScript、CSS を含む画像になります。

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

XNUMX 番目のクラスタータスクに関しては、既に構築したアプリケーションのコンテンツを使用して、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 キーは特定のリポジトリを指し、master ブランチを指定します (これはオプションですが、完全を期すためにこれを記述します)。

ここで、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 イメージレジストリー、特に 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

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

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 リソース) パラメーターと出力 (built-web-application-image リソース) パラメーターを受け取ります。また、自己署名証明書を使用しているため、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

前のタスクと同様にリソースを渡しますが、今回は build-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

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

コンベアの起動

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

$ tkn pipeline start build-and-deploy-react

この段階では、コマンドラインは対話的に使用され、各リクエストに応じて適切なリソースを選択する必要があります。git リソースの場合は web-application-repo を選択し、最初のイメージリソースの場合は build-web-application を選択します。 -image、そして最後に XNUMX 番目のイメージリソース –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。実行中のパイプラインのレビュー。

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

米。 2. パイプラインに関する追加情報。

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

図 3. 起動されたポッド。

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

米。 4. React アプリケーションを実行します。

まとめ

以上、OpenShift 上でアプリケーションの開発サーバーを実行し、ローカルファイルシステムと同期する方法を説明しました。また、OpenShift Pipelines を使用してチェーンビルドテンプレートをシミュレートする方法についても検討しました。この記事のサンプルコードはすべて見つかります。ここで.

追加リソース (英語)

今後のウェビナーのお知らせ

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

出所： habr.com

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

開発環境としての OpenShift

開発ワークフロー

地元の例

OpenShift 上の開発サーバー

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

Openshift パイプライン

OpenShift パイプラインとは

作業環境をセットアップする

降ります

タスク

クラスタータスク

画像を作成して送信する

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

リソース

コンベヤパイプライン

コンベアの起動

まとめ

追加リソース (英語)

今後のウェビナーのお知らせ

コメントを追加します返信をキャンセル

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

開発環境としての OpenShift

開発ワークフロー

地元の例

OpenShift 上の開発サーバー

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

Openshift パイプライン

OpenShift パイプラインとは

作業環境をセットアップする

降ります

タスク

クラスタータスク

画像を作成して送信する

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

リソース

コンベヤパイプライン

コンベアの起動

まとめ

追加リソース (英語)

今後のウェビナーのお知らせ

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル