kkamegawa's weblog

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

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がありますので、選んでみます。

f:id:kkamegawa:20171221000909p:plain

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

f:id:kkamegawa:20171221000910p:plain

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

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

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

f:id:kkamegawa:20171221000911p:plain

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

f:id:kkamegawa:20171221000912p:plain

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

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

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

f:id:kkamegawa:20171221000913p:plain

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

f:id:kkamegawa:20171221000914p:plain

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

f:id:kkamegawa:20171221000915p:plain

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

f:id:kkamegawa:20171221003044p:plain

実際これをリリースしてみると、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仮想マシンデプロイ時の注意点

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本ともども)フォローアップします…たぶん。

Visual Studio Team Services CI/CDアドベントカレンダー:データベースへのCI/CD(10日目)

はじめに

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

qiita.com

CI/CDといえば、プログラムが主ですが、データベースにデプロイするときはどうしているでしょうか。Visual Studio 2017 Enterpriseに付属するReadyRollを使ってCI/CDをやってみましょう。Re

なお、VS2017に付属するReadyRollはCoreエディションなので、一部機能のみですが、SQLに対するIntelliSenceとかは使えます。SSDTに内蔵されているものよりも高機能に見えます。

www.red-gate.com

Pro/Communityエディション向けには体験版が用意されています。

marketplace.visualstudio.com

ReadyRollはSQL Server(SQL Database)専用ですが、開発しているRedGate社はMySQLやOracle DBに対応した製品も販売しているようです。

www.red-gate.com

RedGate ReadyRollとEntity Frameworkの違い

データベースの管理ではないですが、移行をサポートしたものとしてすぐに思いつくのはEntity FrameworkのCode Firstとの違いです。以前も書いたのでこちらをみてください。

kkamegawa.hatenablog.jp

ただ、VSTSと組み合わせると結構便利なこともあります。ちょっと見てみましょう。

拡張機能の追加

marketplace.visualstudio.com

まず、対象のVSTSにReadyRoll拡張機能を追加します。この拡張機能そのものは無償です。ライセンスはあくまでもクライアントのみにかかるようです。追加すると、ReadyRollのビルドタスクが表示されます。

ビルド定義を作る

f:id:kkamegawa:20171210172604p:plain

ReadyRollには専用のビルド定義が用意されています。こちらを選びます。

f:id:kkamegawa:20171210154152p:plain

こんな感じのビルド定義が用意されています。当然ですが、ビルドエージェントにはHosted VS2017か、Visual Studio 2017 Enterpriseがインストールされているプライベートエージェントをプールを選んでください。

f:id:kkamegawa:20171210154148p:plain

ターゲットのSQL Server(Database)を選んで接続情報を指定します。余談ですが、パスワードはAzure Key Vaultを使うこともできます。

f:id:kkamegawa:20171210154147p:plain

Variable GroupにKey Vaultを指定します。

f:id:kkamegawa:20171210154146p:plain

Key Vaultに登録したVariable Groupを参照しておけば、ビルド定義内でKey Vaultに登録しているパスワードをビルド内変数として参照できます。

f:id:kkamegawa:20171210154149p:plain

Visual StudioのビルドタスクもReadyRollように調整されています。ビルドを実行してみましょう。

f:id:kkamegawa:20171210154150p:plain

VSTSにReadyRoll拡張機能をインストールすると、Database diff scriptとDatabase scriptという項目ができています。ReadyRollプロジェクトをビルドすると、ここに表示されます。このキャプチャを取った11/26時点ではWindows 10 Fall Creators UpdateのEdgeではここが表示されないようで、Chromeでキャプチャを取りました。

f:id:kkamegawa:20171210154151p:plain

データベースに対して実行したスクリプトも表示されます。

ReadyRollでリリース

ビルドができたら次はリリースです。

f:id:kkamegawa:20171210154153p:plain

リリースでの成果物(Artifact)にReadyRollのビルド定義を指定します。

f:id:kkamegawa:20171210154154p:plain

リリースのタスクにReadyRoll deploy Database Packageがあるので、選択します。

f:id:kkamegawa:20171210154155p:plain

ビルドパッケージにはReadyRollで生成されたPowerShellスクリプトを指定します。

f:id:kkamegawa:20171210190710p:plain

このように、リリースも正常に行われています。

Visual Studioでの注意事項

f:id:kkamegawa:20171210190748p:plain

Visual StudioでReadyRollのプロジェクトを作ったときデプロイ先によって、プロジェクトのこの設定を変更してください。

特にSQL DatabaseとSQL Serverでは使えるSQLに差があります。具体的にはuse命令がSQL Databaseでは使えないので、SQL ServerのままだとSQL Databaseへのデプロイに失敗します*1

まとめ

ReadyRollを使った基本的なデプロイまで紹介しました。もちろん一回のデプロイで終わるわけはなく、継続的にリリースするときにはいろいろ考慮することがありますが、もうちょっと使いこなしてみて紹介できればと思います。

*1:最初これに気づかなかった…

わんくま&プロ生合同勉強会でWindows コンテナーのことをしゃべってきました

わんくま&プロ生合同勉強会でWindowsコンテナーについて基本編を解説してきました。Windowsコンテナーは選択肢やインストールがまだ混乱しているというか、ちょっとわかりにくい状況になっていると思っているので、できるだけ整理したつもりです。

コンテナーを使われている方がほとんどいらっしゃらなかったので、ちょうどよかったのではないかなという感じです。今回CIはLinux環境で行いましたが、Windows環境でやる方法をちょっと探しておきます。