VSサブスクリプションとVSTSアカウントをAzure AD認証で動かす場合の注意事項

これは2018/2/1時点の情報です。

たぶん日本マイクロソフトさんから翻訳が出るんじゃないかなあと期待しているのですが、重要な注意事項なので簡単に翻訳＆解説してみます。オリジナルも必ず読んでください。

VS Subscriptions and linking your VSTS account to AzureAD – Microsoft DevOps Blog

前提

Visual StudioサブスクリプションはMSアカウントに紐づけるのが基本です。そして、AzureやVSTSのサブスクリプションもMSアカウントで使っている人が多いと思います。個人もしくは小規模団体であればこれでもいいでしょう。

しかし、大きな組織ではそうはいきません。会社で買ったVSサブスクリプションは会社のAzure ADに紐づけておきたいという話はよくあります。VSサブスクリプションを自分のMSアカウントに紐づけたまま、VSTSをAzure ADにくっつける場合の認証のパターンによってはちょっと厄介なことになります。

そのことを書いたのがMSから公開された前述のブログです。

MSアカウントをoutlook.com等に使っていて、VSサブスクリプションをAzure AD(exsample.com)に紐づけたい場合

VSTSかAzureを組織のAzure ADに紐づけていて、VSサブスクリプションが個人のMSアカウントなどの異なる認証にある場合、VSサブスクリプションを"Alternate Account"でAzure ADに紐づけてください。

関連付けされると、どちらもOKになります。

exsample.comにサブスクリプションが関連付けられているけど、このドメインのVSTSがAzure ADで運用されていない。サインインはoutlook.comなどのMSアカウント

このシナリオではMSアカウント作成時にロックダウンされてしまいます。現在解決方法はなく、MS側が頑張って修正しています。今後、MSアカウントの"Alternate account"でAzure ADのVSTSにサインインできるようにするつもりです。

サブスクリプションの管理者はAzure ADのメールアドレスに関連付けます。

サブスクリプションが exsample.com に関連付けられているけど、組織のAzure ADは別のメールアドレス(exsample.jpなど)で、サブスクリプションと一致していない

二番目のシナリオとよく似ていますが、こちらもサポートされていません。VSサブスクリプション側にフィードバックをもらっていて、Azure ADの外部認証で何とかできるように計画中。管理者が期待するメールアドレスに割り当てるのが一番いい解決方法になります。

最後に

この辺のドメインと認証の運用は過渡期ということもあり、非常にややこしいです。私もいろいろ便利そうなので、Azure ADベースでVSTSを運用したいのです。

しかし、サブスクリプションががんじがらめ＆失敗するとどうにもならないということもあり、気軽に試せないです…。必要であれば、MSのサポートに問い合わせてみてください。

注意点として、会社のAzure ADはVSサブスクリプションに対して関知しないといわれたら一番目のシナリオの解決が非常に困ることになるので、この辺の制度を認識してもらうところからでしょうかね。Azure AD関係の知識がないと理解してもらうのが難しいところです。

Visual Studio Team Services CI/CDアドベントカレンダー：CI/CDまとめ(25日目)

はじめに

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

qiita.com

なんとか完走できました。というか、これは最後のポエム的なエントリーです。

VSTSとCI/CDについて

VSTSのCI機能は早くからありましたが、CDに関しては、少し後からという感じでしたね。もともとRelease Managementという買収した製品があり、それをTFSに組み込み、さらにはVSTSに持っていくというところから始まったので、最初のリリース機能はおまけみたいなものでした。

だんだんと改良を続けてきて今に至るわけですが、まだまだもっとこうなればいいなーと思うところはあるものの、当初からしたら随分良くなったと思います。

Webへの傾倒

最近のVisual Studio Team Services/Team Foundation Server/Visual Studioのリリースを見ていると、Webへ舵を切っているように見えます。実際、Test ManagerやFeedback Clientはサポートこそされているものの、Visual Studio 2017標準ではインストールされません。

MSの昨今の方針を示すように、クライアントもクロスプラットフォームのために.NETオブジェクトモデルから、REST APIを押しています。もちろん、.NET Coreでもいいのでしょうけど、あのオブジェクトモデルを.NET Coreに移行させるとなると、既存のライブラリ群からの移行が大変そうです。

Python製のVSTS-cliも出てきたし、Web拡張機能を使うにもRESTの方が都合がいいでしょう。これはこれで正しいように思います。

github.com

今後はモバイル用のビューの不足ですね。Work itemなど一部はサポートを始めましたが、まだまだ不足しています。かと言って、そう簡単に作れそうもない気もしますし、必要かと言われれば…うーん。

エージェントについて

CIに使うビルドサーバーを管理したくない、というのはその通りだと思いますが、反面外に出せないライブラリやコンパイラーを使うために独自のエージェントを立てる道が用意されているのはハイブリッドを得意とする、MSらしいなと思います。

ただ、ちょいちょい？と思うことはあります。昨日までは1分で終わるようなソリューションのビルドにある日突然7−8分かかったりとか。今回だいぶビルド無償枠を使ったのですが、この不思議なポーズ(?)現象のおかげで、無為に使われてしまいました。

後、これは致し方ないのですが、スプリント単位でVSのエージェントが更新されるものの、15.5がリリースされるちょっと前に15.4にしました！というのはもうちょっとなんとかならないものかと。

VSのビルドツール類がコンテナーになって、VS Hosted AgentがWindows Server 2016ベースになれば解消するのでしょうか。

ビルド/リリース時のキャッシュ

NuGetパッケージのリストアやDockerコンテナーのpullでもうちょっとキャッシュされないかなぁとは思います。パッケージリストアで1-2分、docker pull も結構早いのですが(特にazure container registry使うと)、他のCIサービスがキャッシュしているように見えるので、この辺の改善もされるといいなとは思います。

Azureいらないようで、実はいる

同じ会社のサービスだから当然と言えば当然なのですが、Azureと一緒に使うとより便利です。パッと思いつく限りで。

• Application Insights, Monitorなどを使ったリリースゲート
• Key Vaultを使った機密性の高いデータの格納
• Azure AD(AAD)を認証に使うとAADのグループがそのままチームになる
• DevTest Labsと連携してテストエージェントの展開

まだ試せていないですが、VSTSをAzure ADで認証して、クライアントはAzure AD, Azure AD Domain Servicesを使っていると、WinRMのpublicプロファイル問題も解消できるんでしょうかね。

App CenterとVSTSとの住み分け

これどうなるんでしょうね。当面、別々に運用するようですが、当然連携するところもあります。ただ、ビルドするのは間違いなく、App Centerのビルド定義の方が楽ですね。

TestとCI/CD

今回ほとんど紹介できませんでしたが、CI/CD 時にSeleniumなどで自動化テストを行うと言ったことも可能です。

あとは本番前のいわゆるシステムテスト(負荷テストなど)もできますね。機能的にはほとんど変わってないはずなので、昨年のカレンダーを見ていただいてもいいと思います。

今回できなかったところ

ネタとしてはあったんですが、私の検証不足や執筆ペースの都合で諦めたものも結構あります。

• AWS との連係(拡張機能を入れるだけですが)
• もっと他にいろんなパターンのデプロイ
  • LogicApp / Functions
  • Hadoopなど
  • AWS(Lambda/S3/EC2)
  • Cognitive系
  • データベース上級編
  • 大規模並列デプロイ
  • JavaやJavaScript, PHP, Pythonなどの他プラットフォーム
• Docker(これはちょっとハマり中)
• VSTSビルドタスクを作ってみる
• Release Gateの他のパターン
• モバイル開発(Xamarin, Swift, Kotlinなどバックエンドを含めて)

TFS本と並行してできればと思っています。

終わりに

今年もカレンダーなんとか完走できました！読んでくれて、ちょっとでもVSTSに興味を持ってもらえれば嬉しいです。

来年は他に書く人がいそうだったらやりましょう。

Visual Studio Team Services CI/CDアドベントカレンダー：継続的モニタリングを設定する(20日目)

はじめに

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

qiita.com

継続的インテグレーション、継続的デプロイ(デリバリー)はよく聞いたことがあると思います。最近VSTSの開発で継続的モニタリングという言葉もでてきました。VSTSのリリーステンプレートにも入っています。

どんなものかちょっと見てみましょう(CI/CDじゃなかったのかという突っ込みは…)。

リリース定義の作り方

リリース定義にAzure App Service Deployment with Continuous Monitoringがありますので、選んでみます。

二つEnvironmentがありますが、すでに一度作ったものに追加する形でキャプチャ撮ったので、スルーしてください。

モニタリングのテンプレートから作った場合、以下の三つのタスクが定義されています。

• Enable Continuous Monitoring
• Configure Application Insights..
• Azure App Service Deploy

これを見てわかると思いますが、「App ServiceにデプロイするついでにApplication Insightsを定義してやるよ」ということをリリース定義でやってくれるものです。Enable Continuous Monitoringは要はApplication Insights拡張機能を指定したWeb Appsに設定してくれるというものです。

次のConfigure Application Insightsタスクで、Application Insightsの監視ルールが設定できます。実はこのタスクで作った場合、既定の設定が選択されているので、その設定をそのまま使っても構いません。

• Availability が99%を下回った場合
• リクエスト失敗が5回より大きい
• サーバーの応答時間が5秒より大きい場合
• サーバーの例外が5回を上回った場合

ここでサブスクリプションの所有者、コントリビューター、読み取り権限のある人、その他指定した人にこのアラート条件を満たしたときにメールを送信する設定もできます(Subscription owners.. にチェック)。

これ以外の警告条件を指定したい場合もあります。Alert rulesの横をクリックして、条件設定をします。

警告名、メトリクス、条件、閾値を指定します。余り警告が来てもあれなので、許容できる範囲を合意しておきましょう。

メトリクスにはWebサーバーで大体要求されるような項目が入っていると思います。

App Serviceのデプロイには特に問題はありませんね。

実際これをリリースしてみると、Application Insightsの警告ルールに設定されています。

まとめ

Application Insightsにはメトリクスをとる機能と、ログを出力する機能があります。今まではどちらもVisual Studioのウィザードで設定することが多かったと思いますが、モニタリングに関してはCDのタスクで設定できるようになりました。

メトリクスルールもCDで構成できるので、これを仮に複数のリージョンに展開するとなったときでも既存のリリース定義から複製すればいいだけなので、Azureポータルでぽちぽち手作業するのにくらべて、間違いが起きなくなります。

また、リリースに含まれるので、アラートルールを変更する場合でもリリース定義を変えることにより、記録として残るので、とても便利だと思います。

使ってみてください。

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仮想マシンデプロイ時の注意点

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

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

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

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

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

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

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

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

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

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

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

リリース実行

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

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

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

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

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

まとめ

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