サポートコンソール開発者トライアルの開始お問い合わせ

2.3.5.2. 繰り返し可能なプロモーションプロセス

パイプラインの異なるステージング環境での初回のセットアップ後に、プロモーションパイプラインを使用したアプリケーションの反復を検証する繰り返し可能な手順のセットを開始できます。これらの基本的な手順は、ソース環境のイメージまたは API オブジェクトが変更されるたびに実行されます。

更新後のイメージの移動→更新後の API オブジェクトの移動→環境固有のカスタマイズの適用

  1. 通常、最初の手順ではアプリケーションに関連するイメージの更新をパイプラインの次のステージにプロモートします。前述のように、ステージング環境間で OpenShift Container Platform レジストリーが共有されるかどうかが、イメージをプロモートする上での主要な差別化要因となります。

    1. レジストリーが共有されている場合、単に oc tag を使用します。 

      $ oc tag <project_for_stage_N>/<imagestream_name_for_stage_N>:<tag_for_stage_N> <project_for_stage_N+1>/<imagestream_name_for_stage_N+1>:<tag_for_stage_N+1>

    2. レジストリーが共有されていない場合、ソースおよび宛先の両方のレジストリーにログインする際、各プロモーションパイプラインレジストリーに対してアクセストークンを使用でき、アプリケーションイメージのプル、タグ付け、およびプッシュを随時実行できます。

      1. ソース環境レジストリーにログインします。 

        $ docker login -u <username> -e <any_email_address> -p <token_value> <src_env_registry_ip>:<port>

      2. アプリケーションのイメージをプルします。 

        $ docker pull <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag>

      3. アプリケーションのイメージを宛先レジストリーの場所にタグ付けし、宛先ステージング環境と一致するように namespace、名前、タグを随時更新します。 

        $ docker tag <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag> <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>

      4. 宛先ステージング環境レジストリーにログインします。 

        $ docker login -u <username> -e <any_email_address> -p <token_value> <dest_env_registry_ip>:<port>

      5. イメージを宛先にプッシュします。 

        $ docker push <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
        ヒント

        外部レジストリーからイメージの新バージョンを自動的にインポートするために、oc tag コマンドで --scheduled オプションを使用できます。これを使用する場合、ImageStreamTag が参照するイメージは、イメージをホストするレジストリーから定期的にプルされます。

  2. 次に、アプリケーションの変化によってアプリケーションを構成する API オブジェクトの根本的な変更や API オブジェクトセットへの追加と削除が必要となるケースがあります。アプリケーションの API オブジェクトにこのような変化が生じると、OpenShift Container Platform CLI はあるステージング環境から次の環境へと変更を移行するための広範囲のオプションを提供します。

    1. プロモーションパイプラインの初回セットアップ時と同じ方法で開始します。 

      $ oc login <source_environment>
$ oc project <source_project>
$ oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml
$ oc login <target_environment>
$ oc <target_project>

    2. 単に新しい環境でリソースを作成するのではなく、それらを更新します。これを実行するための方法がいくつかあります。

      1. より保守的なアプローチとして、oc apply を使用し、ターゲット環境内の各 API オブジェクトに新しい変更をマージできます。これを実行することにより、--dry-run=true オプションを実行し、オブジェクトを実際に変更する前に結果として得られるオブジェクトを確認することができます。 

        $ oc apply -f export.yaml --dry-run=true

        問題がなければ、apply コマンドを実際に実行します。 

        $ oc apply -f export.yaml

        apply コマンドはより複雑なシナリオで役立つ追加の引数をオプションで取ります。詳細については oc apply --help を参照してください。

      2. または、よりシンプルで積極的なアプローチとして、oc replace を使用できます。この更新および置換についてはドライランは利用できません。最も基本的な形式として、以下を実行できます。 

        $ oc replace -f export.yaml

        apply と同様に、replace はより高度な動作については他の引数をオプションで取ります。詳細は、oc replace --help を参照してください。

  3. 直前の手順では、導入された新しい API オブジェクトは自動的に処理されますが、API オブジェクトがソースの環境から削除された場合には、 oc delete を使用してこれらをターゲットの環境から手動で削除する必要があります。

  4. ステージング環境ごとに必要な値が異なる可能性があるため、API オブジェクトで引用された環境変数を調整する必要がある場合があります。この場合は oc set env を使用します。 

    $ oc set env <api_object_type>/<api_object_ID> <env_var_name>=<env_var_value>
  5. 最後に、oc rollout コマンドまたは、上記の「デプロイメント」のセクションで説明した他のメカニズムを使用して、更新したアプリケーションの新規デプロイメントをトリガーします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.