Nested Virtualizationをサポートするクラウドについて

Nested Virtualizationってサポートされているよな？とサポートしたクラウドサービスについてまとめてみました。最近のOS(私が認識しているのはWindowsだけですが)はOSの機能として仮想化を使ってカーネル部分や秘密情報を保護することがあるし、例えばクラウドの開発環境で各種エミュレーターやWSL2が動けば便利です。

VMなので、各社それほど劇的に変わるとは思えないですが、一応2021/3/16時点の情報です。

Google

cloud.google.com

Linuxをデプロイした場合に限り、Nested Virtualizationをサポートします。Windowsのデプロイではサポートされません。

IBM

cloud.ibm.com

VPCのGen2でなおかつ、自分で有効化すれば使えるようですね。あと、ライブマイグレーションは使えないとのことです。

Alibaba

topic.alibabacloud.com

自分で有効化すれば使えるそうです。ドキュメントではKVMに準じるそうです。

AWS

aws.amazon.com

ベアメタルインスタンス以外では使えないようです。この点結構会社の人から相談を受けて「ベアメタルじゃないと使えないですね」と言って泣かれることが多いAWSです。

Oracle

blogs.oracle.com

docs.oracle.com

Oracle Linux 7.x以降であればサポートされているそうです。それ以外の環境はKVMのサポート状況に準じると。

Azure

docs.microsoft.com

DやEであればv3もしくはv4とついたインスタンスでサポートされます。aシリーズ（AMDプロセッサー）に関してはWindowsの場合Windows 10 20H2(ビルド19636以降)じゃないとNested Virtualizationサポートされないはずです。

techcommunity.microsoft.com

まとめ

意外とNested Virtualizationサポートしていますね。設定が必要なクラウドサービス多いけど、みんなが使うものじゃないから仕方ないですかね。

Azure DevOps 2021/3/3の更新

Azure DevOps Sprint 183のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

Twitterでも書きましたが、マイニングに不正利用されてその管理にマンパワーが取られすぎてしまったためにオープンソース向けAzure Pipelinesの無料並列ビルドの提供をやめることにしたそうです。一律中止ではなく、使っている人はメールを送れば引き続き使えるようになるそうです。GitHub Actions側にはこの制限はないということなので、監視は基本的にActionsに注力することにしたのでしょうか。

あと、PATの管理を行うためのAPIがプライベートプレビューで提供されるそうです。PATをPATを動的に生成したいみたいなシナリオがある方は連絡してみてください。

以前も書いた通り、プロジェクトに入っている人以外のメンバーの検索、タグ付けができなくなるそうです。これは非常に嬉しい改善ですね。今までこれをやるためにはorganizationを分割するしかなかったので、例えば組織内で一つのAzure DevOpsに集中させることが難しかったのです。こちらでも書いています。

kkamegawa.hatenablog.jp

これで特にインナーソースで使う場合、管理者すくなりますね。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…

Azure DevOps 2021/2/4の更新

Azure DevOps Sprint 182リリースノートの翻訳を行いました。オリジナルはこちらからみてください。

docs.microsoft.com

.NET Core 3.0がEOLになって半年経ったので、Hosted Agentから消えるそうです。Windowsにはもともと入っていなかったので、Linux/macOSのみが対象だそうです。組み込みされなくなっただけなので、.NET Core Install Taskを使えば継続して使えます。ちょっとだけ時間がかかるようになりますね。

今までorganization単位でユーザーの検索ができていた仕様が改善されて、Projectスコープになります。この仕様で困ることがあるといえば、別プロジェクトへforkした場合、お互いのプロジェクトにユーザーを登録しないといけなくなりますが、forkはお互い干渉しないというものになるので、まぁいいのかな。

あとはDelivery Plansの上限が15になったり、Chart Widgetのgroup byがGAになったりということですね。今週も小幅で翻訳楽でした。

ではまた三週間後。

ranslate to Japanese to Azure DevOps release note…

Azure DevOpsのプロジェクトに所属しないユーザーが検索されなくなります

Sprint 182が公開されました。翻訳は別途公開しますが、今までセキュリティ上の都合でorganizationを分割せざるを得なかった問題が解消されているので、紹介します。

今までのAzure DevOpsではorganizationに含まれるユーザーは全て検索対象になっていました。これで何が困るかといえば、AというプロジェクトとBというプロジェクトで利害関係の異なっているとまでは言わないですが、社外のゲストユーザーを入れていた場合です。

偶然メールアドレスのローカルパートや氏名で一致した場合、みられちゃ困る他社のメンバーまで見えてしまうことになります。今までこういう時はorganizationを分割せざるを得なかったのですが、複数organizationがあると自分の作業も分割されてしまうし、何よりセキュリティレベルに異なったものを設定してしまうことになります。

Azure Artifactsも異なるOrganizationで課金が多重にかかるのも地味に辛いですね。そこでSprint 182ではProject-Scoped Usersという組み込みセキュリティグループが作られました。OrganizationのPermissionsにあります。

ここに入っている人は既定で自分のグループ以外のユーザーが検索、タグ付けなどで出て来なくなります。とはいえ、何かしないといけないわけではなくて、Project-Scoped UsersにはProject Collection Valid Usersグループが入っています。そして、チームプロジェクト毎にProject Valid Usersというグループが作られています。

各プロジェクトにアクセスする場合、Project Valid Usersに追加されるはずなので、実は特に何をしなくても、プロジェクトガイのメンバーがサジェストされることがなくなるはずです。

社内開発でAzure DevOpsを使おうとする場合、無関係のパートナーさんが出てきては困るということもあったと思うので、これでより便利になりますね。

よって、今後organizationを分割する場合というのはこのくらいでしょうか。

• 将来的にorganizationの所有者が変わる（発注を発注を受けて仕事する）場合
• 開発者から地理的に近い場所に設置したい場合
• そもそも接続するAzure ADが違う場合
• セキュリティレベルが異なる場合(OrganizationのPolicy設定）