警告
Azure Container Service (ACS) は非推奨です。 ACS に新しい機能は追加されません。 すべての API、ポータル エクスペリエンス、CLI コマンド、およびドキュメントは非推奨としてマークされます。
詳細については、Azure Container Service の廃止に関するお知らせを Azure.comでご覧ください。
次のいずれかの Azure Marketplace ソリューションをデプロイすることをお勧めします。
- Mesosphere DC/OS
クラウド用の最新のアプリケーションを開発する際の最大の課題の 1 つは、これらのアプリケーションを継続的に提供できることです。 この記事では、Docker Swarm、Azure Container Registry、Azure Pipelines 管理を使用して、Azure Container Service を使用して完全な継続的インテグレーションとデプロイ (CI/CD) パイプラインを実装する方法について説明します。
目的は、Azure DevOps Services を使用して、Docker Swarm クラスターでこのアプリケーションを継続的に配信することです。 次の図では、この継続的デリバリー パイプラインについて詳しく説明します。
手順の簡単な説明を次に示します。
- コードの変更はソース コード リポジトリにコミットされます (こちら、GitHub)
- GitHub が Azure DevOps Services でビルドをトリガーする
- Azure DevOps Services は最新バージョンのソースを取得し、アプリケーションを構成するすべてのイメージをビルドします
- Azure DevOps Services は、Azure Container Registry サービスを使用して作成された Docker レジストリに各イメージをプッシュします
- Azure DevOps Services によって新しいリリースがトリガーされる
- このリリースでは、Azure コンテナー サービス クラスター マスター ノードで SSH を使用していくつかのコマンドが実行されます
- クラスター上の Docker Swarm が最新バージョンのイメージをプルする
- 新しいバージョンのアプリケーションは、Docker Compose を使用してデプロイされます
前提条件
このチュートリアルを開始する前に、次のタスクを完了する必要があります。
- Azure Container Service で Swarm クラスターを作成する
- Azure Container Service で Swarm クラスターに接続する
- Azure コンテナー レジストリ を作成する
- Azure DevOps Services の組織とプロジェクトを作成
- GitHub リポジトリを GitHub アカウントにフォーク
注
Azure Container Service の Docker Swarm オーケストレーターは、従来のスタンドアロン Swarm を使用します。 現時点では、統合 Swarm モード (Docker 1.12 以降) は、Azure Container Service でサポートされているオーケストレーターではありません。 Azure に Swarm モード クラスターをデプロイする場合は、オープンソースの ACS エンジン、コミュニティが提供する クイックスタート テンプレート、または Azure Marketplaceの Docker ソリューションを使用します。
Docker がインストールされている Ubuntu (14.04 または 16.04) マシンも必要です。 このマシンは、Azure Pipelines プロセス中に Azure DevOps Services によって使用されます。 このマシンを作成する 1 つの方法は、Azure Marketplace で利用可能なイメージを使用することです。
手順 1: Azure DevOps Services 組織を構成する
このセクションでは、Azure DevOps Services 組織を構成します。
Azure DevOps Services Linux ビルド エージェントを構成する
Docker イメージを作成し、Azure DevOps Services ビルドから Azure コンテナー レジストリにこれらのイメージをプッシュするには、Linux エージェントを登録する必要があります。 次のインストール オプションがあります。
Linux にエージェントをデプロイする
Docker Integration Azure DevOps Services 拡張機能をインストールする
Microsoft では、Azure Pipelines プロセスで Docker を操作するための Azure DevOps Services 拡張機能を提供しています。 この拡張機能は、Azure DevOps Services Marketplaceで使用できます。 インストール をクリックして、この拡張機能を Azure DevOps Services 組織に追加します。
をインストールする
資格情報を使用して Azure DevOps Services 組織に接続するように求められます。
Azure DevOps Services と GitHub を接続する
Azure DevOps Services プロジェクトと GitHub アカウントの間の接続を設定します。
Azure DevOps Services プロジェクトで、ツール バーの 設定 アイコンをクリックし、Servicesを選択します。
Azure DevOps Services の
左側で、新しいサービス エンドポイント>GitHubをクリックします。
GitHub アカウントで動作するように Azure DevOps Services を承認するには、[ の承認] をクリックし、開いたウィンドウの手順に従います。
Azure DevOps Services - GitHub の承認
Azure DevOps Services を Azure コンテナー レジストリと Azure Container Service クラスターに接続する
CI/CD パイプラインに入る前の最後の手順は、Azure でコンテナー レジストリと Docker Swarm クラスターへの外部接続を構成することです。
Azure DevOps Services プロジェクトの Services 設定で、Docker Registry の種類サービス エンドポイントを追加します。
開いたポップアップで、Azure コンテナー レジストリの URL と資格情報を入力します。
Azure DevOps Services の
Docker Swarm クラスターの場合は、SSH 種類のエンドポイントを追加します。 次に、Swarm クラスターの SSH 接続情報を入力します。
Azure DevOps Services - SSH
すべての構成が完了しました。 次の手順では、アプリケーションをビルドして Docker Swarm クラスターにデプロイする CI/CD パイプラインを作成します。
手順 2: ビルド パイプラインを作成する
この手順では、Azure DevOps Services プロジェクトのビルド パイプラインを設定し、コンテナー イメージのビルド ワークフローを定義します
パイプラインの初期セットアップ
ビルド パイプラインを作成するには、Azure DevOps Services プロジェクトに接続し、ビルド & リリース クリックします。
[ビルド定義] セクション内で、[+ 新規] をクリックします。 空の テンプレートを選択します。
GitHub リポジトリ ソースを使用して新しいビルドを構成し、継続的インテグレーション 確認し、Linux エージェントを登録したエージェント キューを選択します。 [ 作成] をクリックしてビルド パイプラインを作成します。
Azure DevOps Services の
の作成ビルド定義 ページで、まず リポジトリ タブを開き、前提条件で作成した MyShop プロジェクトのフォークを使用するようにビルドを構成します。 デフォルト ブランチとして acs-docs を選択していることを確認します。
[トリガー] タブで、ビルドが各コミット後にトリガーされるように構成します。 継続的インテグレーション を選択し、バッチ変更を選択します。
Azure DevOps Services の
ビルド ワークフローを定義する
次の手順では、ビルド ワークフローを定義します。 MyShop アプリケーション用にビルドするコンテナー イメージは 5 つあります。 各イメージは、プロジェクト フォルダーにある Dockerfile を使用して構築されます。
- プロダクトAPI
- プロキシ
- RatingsApi
- レコメンデーションズAPI
- ショップフロント
イメージごとに 2 つの Docker ステップを追加する必要があります。1 つはイメージをビルドし、1 つは Azure コンテナー レジストリにイメージをプッシュします。
ビルド ワークフローにステップを追加するには、[+ ビルド ステップの追加] をクリックし、Docker 選択します。
Azure DevOps Services の
イメージごとに、
docker buildコマンドを使用する 1 つのステップを構成します。Azure DevOps Services
ビルド操作では、Azure コンテナー レジストリ、イメージのビルド アクション、および各イメージを定義する Dockerfile を選択します。 ビルド コンテキスト を Dockerfile ルート ディレクトリとして設定し、イメージ名を定義します。
前の画面に示すように、Azure コンテナー レジストリの URI でイメージ名を開始します。 (ビルド変数を使用して、この例のビルド識別子など、イメージのタグをパラメーター化することもできます)。
イメージごとに、
docker pushコマンドを使用する 2 番目の手順を構成します。
プッシュ操作の場合は、Azure コンテナー レジストリの [イメージのプッシュ] アクション 選択し、前の手順で作成した イメージ名 を入力します。
5 つのイメージごとにビルドとプッシュのステップを構成した後、ビルド ワークフローにさらに 2 つのステップを追加します。
a bash スクリプトを使用して、docker-compose.yml ファイル内の BuildNumber 出現箇所を現在のビルド ID に置き換えるコマンド ライン タスク。詳細については、次の画面を参照してください。
Azure DevOps Services の
b。 更新された Compose ファイルをビルド 成果物として削除して、リリースで使用できるようにするタスク。 詳細については、次の画面を参照してください。
Azure DevOps Services の
[保存] をクリックし、ビルド パイプラインに名前を付けます。
手順 3: リリース パイプラインを作成する
Azure DevOps Services を使用すると、環境間でリリースを管理できます。 継続的デプロイを有効にして、アプリケーションがさまざまな環境 (開発、テスト、実稼働前、運用前など) にスムーズにデプロイされるようにすることができます。 Azure Container Service Docker Swarm クラスターを表す新しい環境を作成できます。
Azure DevOps Services の 
へのリリース
初期リリースのセットアップ
リリース パイプラインを作成するには、[リリース >] をクリックします。
成果物ソースを構成するには、[成果物の ] をクリック>成果物ソースをリンクします。 ここでは、この新しいリリース パイプラインを、前の手順で定義したビルドにリンクします。 これにより、docker-compose.yml ファイルはリリース プロセスで使用できます。
Azure DevOps Services - リリース成果物
リリース トリガーを構成するには、トリガー をクリックし、継続的配置を選択します。 同じ成果物ソースにトリガーを設定します。 この設定により、ビルドが正常に完了するとすぐに新しいリリースが開始されます。
Azure DevOps Services の
リリース ワークフローを定義する
リリース ワークフローは、追加する 2 つのタスクで構成されます。
以前に構成した SSH 接続を使用して、Docker Swarm マスター ノード上の デプロイ フォルダーに、compose ファイルを安全にコピーするタスクを構成します。 詳細については、次の画面を参照してください。
Azure DevOps Services -
のリリースbash コマンドを実行してマスター ノードで
dockerコマンドとdocker-composeコマンドを実行するように 2 つ目のタスクを構成します。 詳細については、次の画面を参照してください。
マスターで実行されるコマンドは、Docker CLI と Docker-Compose CLI を使用して、次のタスクを実行します。
Azure コンテナー レジストリにログインします ([変数] タブで定義されている 3 つのビルド変数が使用されます)
Swarm エンドポイントを操作する DOCKER_HOST 変数を定義する (:2375)
以前のセキュア コピー タスクによって作成され、docker-compose.yml ファイルを含む展開 フォルダー に移動します。
docker-composeのコマンドを実行して、新しいイメージをプルし、サービスを停止し、サービスを削除し、コンテナを作成します。重要
前の画面に示されているように、Fail on STDERR チェックボックスを外したままにしておきます。 これは重要な設定です。なぜなら、
docker-composeがコンテナの停止や削除といった複数の診断メッセージを標準エラー出力に表示するためです。 このチェック ボックスをオンにした場合、Azure DevOps Services は、すべて問題ない場合でも、リリース中にエラーが発生したことを報告します。
この新しいリリース パイプラインを保存します。
注
このデプロイには、古いサービスを停止し、新しいサービスを実行しているため、いくつかのダウンタイムが含まれます。 ブルーグリーンのデプロイを行うことで、これを回避できます。
手順 4. CI/CD パイプラインをテストする
構成が完了したら、この新しい CI/CD パイプラインをテストします。 これをテストする最も簡単な方法は、ソース コードを更新し、変更を GitHub リポジトリにコミットすることです。 コードをプッシュしてから数秒後に、Azure DevOps Services で実行されている新しいビルドが表示されます。 正常に完了すると、新しいリリースがトリガーされ、新しいバージョンのアプリケーションが Azure Container Service クラスターにデプロイされます。
次のステップ
- Azure DevOps Services での CI/CD の詳細については、Azure Pipelines ドキュメント 記事 参照してください。