Azure Docker Integration

先日(7/30)と言っても、既に2ヶ月前。第28回 Tokyo Jazug Nightの資料をやっとSlideshareに上げた。Introduction of Azure Docker Integration

だいぶ空いてしまったので、更新情報を。先日、2020/9/24 に、docker compose をクラウド上で動かすための、docker cli 拡張SDKが公開された。アーキテクチャを見ると、ECS/ACI バックエンドとなっているのが、それぞれのコンテキストを提供している部分で、ECS, ACI 統合がどのようにされているのかがわかる。

Docker Open Sources Compose for Amazon ECS and Microsoft ACI

Stone

現時点で、この図のNode SDKCompose CLIの部分がオープンソース化されている。このアーキテクチャは最終的なものではなく、「後でCompose CLIを既存のCLIとマージする予定」ということだ。

どうやら、Compose CLIに、gRPCのAPIを追加して、複数の言語から、Docker CLIを使えるようにするつもりらしい。今は、Node SDKしかなく、APIはCompose CLIに付いてるが、これは暫定。将来的には、人気のある言語用にSDKを用意し、Compose CLIは、Docker CLIに統合、また、コンテキストのバックエンドは、ECS、ACIだけでは無く他のものもサポートする。ということらしい。なかなか興味深い

閑話休題

このBlog、2年ほど空いてしまったが、今回復活にあたり、static site generatorとして使ってるtinkererを docker 化しWSL2でビルドすることにした。tinkerer の Dockerfiletakekazuomi/tinkerer最近は、Windows Python環境が安定しないのと、Python 環境自体が壊れやすいので、venv を使うより、いっそのことWSL2+Docker の方が良いかなと思っている。

参考までに、Blogの方のDockerfile

FROM takekazuomi/tinkerer:1.7.2

WORKDIR /tmp

ENV DEBIAN_FRONTEND noninteractive

USER root

COPY requirements.txt ./

RUN apt-get -y update \
&& apt-get -y clean \
&& rm -rf /var/lib/apt/lists/* \
&& pip3 install pip -U \
&& pip install -r requirements.txt \
&& python -m pip install https://github.com/takekazuomi/sphinx-gist-embed/archive/master.tar.gz

USER tinker

WORKDIR /blog

CMD ["tinker", "-h"]

Bookmarks

複数Subscriptionへのデプロイ

この記事はMicrosoft Azure Advent Calendar 2017の2日目の記事です。

ちょっと便利な、ARM template の小技を紹介します。

以前から1つのテンプレートを使って、複数のリソースグループへデプロイすることができましたが[1]。さらに、Microsoft.Resources/deploymentsAPI Version: 2017-05-10から、別のサブスクリプションへもデプロイできるようになりました。[2]

リソースを異なるサブスクリプションにデプロイするには、別のリソースグループへデプロイする時と同じように、nested template(Microsoft.Resources/deployments) を使います。 deployments リソースにsubscriptionId プロパティが追加され、そこに指定したサブスクリプションにnested templateで定義したリソースが展開されるってわけです、簡単ですね。

IMG_3105

ちょっとやってみましょう、下にテンプレートの抜粋を見て下さい。[3]テンプレートは、別のリソースグループへデプロイする時とほぼ同じで、8行目のsubscriptionId のところが違うぐらいなのがわかります。

これで上手くデプロイできるか確認しましょう。 local subscription (083c462a-7c24-4a16-8bfe-876cb0ab434b) を選択した状態でデプロイします。そうするとストレージアカウント(東日本)が作成され、同時に remote subscription (ff05d8ad-12ee-4c68-97bb-78baefa1c01a) にもストレージアカウント(西日本)も作成されます。

実行には事前に、リソースグループが必要です。サブスクリプションを切替ながら、リソースグループを両側に用意します。

$ Select-AzureRmSubscription -SubscriptionId 083c462a-7c24-4a16-8bfe-876cb0ab434b
$ New-AzureRmResourceGroup -Name LocalRG -Location japaneast

$ Select-AzureRmSubscription -SubscriptionId ff05d8ad-12ee-4c68-97bb-78baefa1c01a
$ New-AzureRmResourceGroup -Name RemoteRG -Location japanwest

これでリソースグループが出来たので、local subscription を選択し直して、前記のテンプレートをデプロイします。

$ Select-AzureRmSubscription -SubscriptionId 083c462a-7c24-4a16-8bfe-876cb0ab434b
$ New-AzureRmResourceGroupDeployment -TemplateFile .\deploystorage.json `
       -StorageAccountName kyrtlocal01 `
       -ResourceGroupName LocalRG `
       -RemoteResourceGroup RemoteRG `
       -RemoteSubscriptionId ff05d8ad-12ee-4c68-97bb-78baefa1c01a `
       -RemoteStorageAccountName kyrtremote01

思った通りに出来ているか確認しましょう。

$ Select-AzureRmSubscription -SubscriptionId 083c462a-7c24-4a16-8bfe-876cb0ab434b
$ Get-AzureRmStorageAccount -ResourceGroupName RemoteRG | fl ResourceGroupName,Id, Location

ResourceGroupName : localrg
Id                : /subscriptions/08.../resourceGroups/localrg/providers/Microsoft.Storage/storageAccounts/kyrtlocal01
Location          : japaneast


$ Select-AzureRmSubscription -SubscriptionId ff05d8ad-12ee-4c68-97bb-78baefa1c01a
$ Get-AzureRmStorageAccount -ResourceGroupName RemoteRG | fl ResourceGroupName,Id, Location

ResourceGroupName : remoterg
Id                : /subscriptions/ff.../resourceGroups/remoterg/providers/Microsoft.Storage/storageAccounts/kyrtremote01
Location          : japanwest

ストレージアカウントが2つ作成され、それぞれ別のサブスクリプションに東日本と西日本に配置されているのが確認できました。複数サブスクリプションへの配置が必要なケースはあまり無い気もしますが、なかなか面白いですね。

注意

テンプレートの、38行目で、location を西日本を直接指定しています。 ここを、location": "[resourceGroup().location]としたら、locationが東日本になってしまいました。resourceGroup()は、親のdeploymentsリソースを指すようです。ちょっと混乱しますが、「まあ納得できる範囲かな」という気はします。

最後に

今回の元ネタは、@rjmaxの、Demos for Ignite US 2017 session BRK3167[4]です。このレポジトリだけで無く彼のレポジトリはARM template を使う人には必見の情報満載です、素晴らしい。特に、rjmax/ArmExamplesはお勧めですよ、ここのテンプレートは短くて見やすいのも良い感じです。

2017 Microsoft MVP Award を受賞しました

2017年7月期、Microsoft Azure のカテゴリで、Microsoft MVP Award を受賞しました。

今年は、Cosmos DBの年ですね、楽しみな年になりそうです。

これからも、よろしくお願いいたします。

Stone

Azure に OAuth 2.0 Device Flow でログインする

この前az loginでログイン出来なくなった時に、azure cli 2.0 のコードを見ていたら、Azureのドキュメントには出てこない(見慣れない)使い方をしてたので確認も兼ねて生REST、OAuth 2.0 Device Flow[1]でAzrueにloginして Beare Tokenを取得するコンソールプログラムazlogin[2]を書いてみた。

curry

使い方

azloginを実行すると、azure cli 2.0 と同じように、デバイスコードと入力用のURLが表示される。この画面のメッセージがazure cli 2.0と一文一句違わず同じなのは、AIPが返して来るメッセージをそのまま表示してるからだ。

ログインに成功すると、アカウントに紐づいたテナントを全部取得して、テナントのアクセストークンを取得し、それを使ってサブスクリプションの情報を取得。結果をJSONで出力する。

$ .\azlogin
To sign in, use a web browser to open the page https://aka.ms/devicelogin and enter the code G9HFZ4NCY to authenticate.
....
[
   {
     "tenantId": "xxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxxxxx",
     "subscriptionId": "xxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxxxxx",
     "subscriptionName": "Developer Program Benefit",
     "bearer": "********************************************a"
   },
   {
     "tenantId": "xxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxxxxx",
     "subscriptionId": "xxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxxxxx",
     "subscriptionName": "foo",
     "bearer": "********************************************a"
   },
   {
     "tenantId": "xxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxxxxx",
     "subscriptionId": "xxxxxxxx-xxxx-xxxxxxxxx-xxxxxxxxxxxx",
     "subscriptionName": "kinmugi",
     "bearer": "********************************************a"
   }
]

このJSONから、Bearer token を取得し変数に保存するして置き、APIの呼び出しをしてみよう。

まずは、jp (JMESPath) の式を用意する。短いのでコマンドラインにそのまま書きたいところだが、Windowsだとエスケープ関係が難しすぎる(cmd.exeや、powershellでは)ので、諦めてファイルに書く。

この例だと、subscriptionName が ‘kinmugi’のサブスクリプションのBearer tokenを取り出している。Windowsだと素直にPowerShellで書いたほうが楽な気がする。最近、JMESPath が気に入っているので、あえてjpを使う。

ここでは、本物のcurlを使って、リソースグループの一覧を取得している。PowerShellだとcurlでaliasが切ってあるが使えないので、本物を入れてalias を切った方が良い。

$ cat filter.jp
[?subscriptionName == 'kinmugi'].bearer|[0]

$ $bearer = (.\azlogin | jp -u -e filter.jp)

$ curl -H  "Authorization: Bearer $bearer" "https://management.azure.com/subscriptions/xxxxxxxx-.../resourcegroups?api-version=2017-05-10"

Bearer tokenさえ手に入れれば、こんな感じでサクッと管理APIが呼べる。

最後に

Azureのドキュメントだとごちゃごちゃしてて良くわからないが、認証は基本普通のOAuth 2.0 なのでそれほど難しくない。このあたりで困ったら、OAuth2.0 のドキュメント(Googleのとか 、翻訳もある[3])を読むと良い。Azure固有の問題は、松崎さんのブログ[4]がお勧めだ。

今回は、生RESTだけで構築したが、認証だけならそれほど難しいことはない。本格的にAzureを触ろうと思うとモデルが欲しくなり。触っていくと大量のモデルが出てくるので自前で作るのはとてもメンドクサイ。その場合はAzureSDKを使うと既にモデルが用意去れているので便利だ。

参考

[1]Using OAuth 2.0 to Access Google APIs,OAuth 2.0 for TV and Limited-Input Device Applications,
[2]Azure Login OAuth 2.0 Device Flow Console Program.
[3]OAuth 2.0 Flow: DevicesYouTube Data APIのドキュメントだが、翻訳されている。
[4]Login UI が出せない Client の OAuth フロー (Azure AD)この記事より松崎さんのブログを読んだほうが良いだろう。

下記のコードも参考になる