kkamegawa's weblog

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

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 2018/1/24の更新

Visual Studio Team Services 2018/1/24のSprint 129のリリースノートの翻訳を行いました。オリジナルはこちらから見てください。

docs.microsoft.com

今回はSprint 128と129がまとめられていますが、意外と多くなくて助かりました。今回GitHub Enterpriseとの統合サポート、pull requestのフィルタリング、いくつかのタスクの廃止が予定されています。

特にRun functional testとかdeployment test agentは書かれているようにWinRMの構成がたいへん面倒で、特にパブリッククラウド上に構成する場合、httpのWinRMを構成するとか、httpsでもオレオレ証明書をどうにかするとか手間だったので、廃止されるのはほんとに助かります。

TeXの数式サポートも誰得と思いましたが、最近はDeep LearningはやりでMSの中でもこれ使っていろいろやっているからなんでしょうかね。

Wikiの印刷は希望していた機能の1つなので、うれしいです。仕様書をオフライン提供するときとかいいですね。

ではまた三週間後。

Translate to Japanese to VSTS release notes from h ...

Visual Studio 2017オフラインイメージから古いコンポーネントを削除するツールを公開しました

Visual Studio 2017はオフラインインストール用のイメージ作成ができます。

docs.microsoft.com

Visual Studio 2017もラピッドリリースになったようで、従来のService Packレベルの更新が数か月に一度程度公開されます。この辺は.NET Coreや昨今の流れのはやいオープンソース系のツールについていくには仕方のないことですね。

docs.microsoft.com

ところが困った点として、同じフォルダでオフラインイメージを構築していくと、古いバージョンのコンポーネントもたまっていきます。私の場合は最新版だけあればいいので、こんなツールを作ってみました。

github.com

Visual Studio 2017のオフラインイメージをダウンロードしたフォルダを指定して実行すると、最新のコンポーネントのフォルダを除いて削除します。

.NET Coreの練習用に作ってみました。Releaseは作っていないのですが、Visual Studio用のツールなので、Visual Studioは持っている(もしくは.NET Core SDKだけでビルドできる)ので、まぁいいでしょう。

誰得ツールですが、よかったら使ってみてください。

(追記) --cleanオプションでできたのか…前なかった気がするんだけどなぁ…と思ったら、15.3のインストーラーで追加されたのか。

VSTSでLinuxのVMにdockerイメージを展開する

はじめに

読者(え)の方からリクエストをいただいたので。LinuxのVMでDockerコンテナを運用しているけど、VSTSでうまいデプロイ方法が分からないというお便りをいただきました。

アドベントカレンダーでは時間がなかったのですが、時間が取れたので、Linuxの仮想マシンに対するRelease Managementの使用方法について紹介します。

Deployment Groupsそのものの作り方に関してはアドベントカレンダーを見てください。

kkamegawa.hatenablog.jp

docker-compose.ymlの変更

f:id:kkamegawa:20180107165309p:plain

Visual Studio 2017でDockerプロジェクトを作ると、docker-compose.ymlのversionが3になっています。Linux用のHosted Agentでは2になってないとエラーになりました。

気を付けてください。

ビルド定義の用意

今回は.NET Coreのプロジェクトですが、基本的には何も変わりません。

f:id:kkamegawa:20180107161927p:plain

Visual StudioのContinuous Delivery拡張機能を使うと、Docker compose Fileのところがminatchパターンを指定していないので、** の追加を忘れないでください。

marketplace.visualstudio.com

f:id:kkamegawa:20180107161920p:plain

f:id:kkamegawa:20180107161921p:plain

他は特にデフォルトのままですね。このままでかまいません。

Deployment Groupsを構成する

LinuxにDeployment Agentを構成します。Linux用のスクリプトが用意されるので、このまま使ってください。

f:id:kkamegawa:20180107161922p:plain

エージェントは事前に構成する必要があります。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ではありません。

f:id:kkamegawa:20180107161926p:plain

Dockerタスクを追加して、Run as imageを選択します。

f:id:kkamegawa:20180107161925p:plain

ここではAzure Docker Registryを選択していますが、もちろんDocker Hubでも構いません。

f:id:kkamegawa:20180107161923p:plain

どのグループにどのリリースが行われているかわかります。

f:id:kkamegawa:20180107161924p:plain

リリースの履歴も表示できます。