はじめに
読者(え)の方からリクエストをいただいたので。LinuxのVMでDockerコンテナを運用しているけど、VSTSでうまいデプロイ方法が分からないというお便りをいただきました。
アドベントカレンダーでは時間がなかったのですが、時間が取れたので、Linuxの仮想マシンに対するRelease Managementの使用方法について紹介します。
Deployment Groupsそのものの作り方に関してはアドベントカレンダーを見てください。
docker-compose.ymlの変更
Visual Studio 2017でDockerプロジェクトを作ると、docker-compose.ymlのversionが3になっています。Linux用のHosted Agentでは2になってないとエラーになりました。
気を付けてください。
ビルド定義の用意
今回は.NET Coreのプロジェクトですが、基本的には何も変わりません。
Visual StudioのContinuous Delivery拡張機能を使うと、Docker compose Fileのところがminatchパターンを指定していないので、** の追加を忘れないでください。
他は特にデフォルトのままですね。このままでかまいません。
Deployment Groupsを構成する
LinuxにDeployment Agentを構成します。Linux用のスクリプトが用意されるので、このまま使ってください。
エージェントは事前に構成する必要があります。AzureのVM展開でもできるはずなのですが、Windowsの場合、私は成功したことがないので、今後研究してみます。
VSTSのエージェントはビルドエージェントと同じバイナリを使うのですが、セットアップのスクリプト(パラメータ)が異なります。
VSTSのエージェントはDockerイメージも用意されていますが、基本的にDockerではなく、通常の展開をお勧めします。理由はVSTSのDeployment Groupからエージェントの更新ができるためです。Docker版を使うと、VSTSからの更新ができません。別途Dockerイメージを更新する手段を自分で構築する必要があります。
(追記)
もしも、オンプレミスのLinuxに展開する場合、GitHubのRelease(実態はAWS S3です)へのアクセスができるかどうか確認してください。VSTSのエージェントはGitHubのReleaseからダウンロードされるので、AWS S3がアクセス禁止になっているとVSTSからの更新ができません。
Releaseのダウンロード先をカスタムドメイン指定できるはずなので、そういうフィードバックはしているのですが、やはりUservoiceに作らないといけないかな…。
Release定義を作る
Release定義はAdd deployment phaseを選択してください。Agent phaseではありません。
Dockerタスクを追加して、Run as imageを選択します。
ここではAzure Docker Registryを選択していますが、もちろんDocker Hubでも構いません。
どのグループにどのリリースが行われているかわかります。
リリースの履歴も表示できます。