kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Visual Studio Team Services CI/CDアドベントカレンダー:仮想マシンへの継続的デプロイ(12日目)

はじめに

これはVisual Studio Team Servicesアドベントカレンダー12日目の記事です。

qiita.com

今日は昨日に引き続き、Azure仮想マシンへの継続的配信を紹介します。最初に…ちょっと失敗して、仮想マシンへの設定で忘れているものがありました。なので、失敗していますが、最終的には成功するはずです、たぶん。あとでUIテストを紹介するときにリカバリーしようと思っています。

仮想マシンでの事前準備

AzureにWindows仮想マシンを立てた人はわかると思いますが、ネットワークプロファイルがパブリックになっています。実はこのパブリックのままだとWinRMでの管理ができません。

Azureでドキュメントが提供されているので、こちらを見てください。

docs.microsoft.com

AzureのDevTest Labsであればこの辺も割と面倒見てくれるはず…です。TFS本ではこの辺をちゃんとドメインプロファイルにしているので、そちらでもカバーできればと思っています。

Azure仮想マシンデプロイ時の注意点

f:id:kkamegawa:20171212205452p:plain

Azure仮想マシンデプロイ時の拡張機能にTeam ServicesのDeployment groups用のエージェントを入れられるように見えるのですが、実はこれ成功したことありません(汗)。これを入れると、どうしてもVMのデプロイでエラーになります。VMそのものはできているのですが、エージェントが構成されていません。

製品グループにもフィードバックしたような感じではありますが、もう一度聞いてみます。

f:id:kkamegawa:20171212205459p:plain

VSTSのAzure File Copyタスクでストレージアカウントを指定するところがあるので、管理ディスク(Managed Storage)を使わないほうがいいかもしれません。WinRMを使うので、ストレージアカウントなくてもいいはずなんですが…停止しているときでもコピーできればいいのですが。

Deployment groupのエージェントフェーズを使う

f:id:kkamegawa:20171212203125p:plain

ReleaseでEnvironmentを作るとagent phaseというビルドエージェントと同じものを使っていました。Deployment groupに対してデプロイするにはdeployment group phaseを使います。

f:id:kkamegawa:20171212203124p:plain

追加するタスクはagent phaseと変わりありません。PowerShellのタスクやResource Groupの作成ができます…が、このResource Group内のVMの起動タスクを設定すると、現時点でなぜかエラーが出るようです。ちょっとフィードバックしておきます。

f:id:kkamegawa:20171212203123p:plain

Azureリソースグループ内のVMを起動する、というタスクです(が、私が試したときはエラーになりました…)。

f:id:kkamegawa:20171212203134p:plain

VMにファイルコピーします。ここでストレージアカウントを指定するため、VMには管理ディスクが使えないのではないか疑惑がありますが、ちょっと聞いてみます(こんなんばっかり…)。

Sourceはビルドで生成されたartifactのコピー元フォルダを指定します。

f:id:kkamegawa:20171212203126p:plain

こんな感じですね。フォルダを指定するので、コピー元のartifactの段階でちゃんとフォルダになっている必要があります。ビルド時msi形式で作っている場合、このタスクでコピーしてから、WinRMで実行するか、PowerShell DSCで構成するしかないでしょうか。

f:id:kkamegawa:20171212203130p:plain

VMへのコピーはこんな感じです。Adminのアカウント名とパスワードはVariablesに登録しています。ただ、Workgroup環境だとVMごとにアカウント名が変わるので、やはりAzure Active Directory Domain Servicesなどでドメイン管理しないといけないんでしょうか…。ID複数管理するのが苦にならなければいいけど。

f:id:kkamegawa:20171212203129p:plain

リリース実行

f:id:kkamegawa:20171212203131p:plain

Create Releaseでリリース実行します。

f:id:kkamegawa:20171212203133p:plain

対象のVMにコピーできれば完璧…だったのですが、WinRMの構成やるの忘れていたので、このようなエラーになりました(恥)。Azureに限りませんが、Windows VMへのデプロイを実施するときは以下のことを忘れないでください。

  • セキュリティグループで5986/tcpを通す
  • 仮想マシン内のパブリックネットワークプロファイルに対してwinrm qcを実施ておく(デフォルトではエラーになります)
  • Windows Advanced Firewallでパブリックプロファイルに対して5986/tcpを通す

さすがにパブリックプロファイルに対して5986/tcpを通すのは怖いと思います。AzureのIPアドレス変更に追従できるのであれば、VSTSのIPアドレスのみ通すようにネットワークセキュリティグループを構成すればいいでしょう。

f:id:kkamegawa:20171212203132p:plain

デプロイが終了すると、deployment groupのマシンに対して成功失敗が表示されます。

まとめ

閉まらない結果でした、後日ちゃんとした方法を(TFS2017/2018本ともども)フォローアップします…たぶん。