世界のやまさ

SEKAI NO YAMASA

Azure Kubernetes Service (AKS) が GA しました

GA しました。これでプロダクション環境でも安心して使用出来ます。

azure.microsoft.com

AKS is now generally available in ten regions across three continents, and we expect to add ten more regions in the coming months!

ただし、東日本・西日本リージョンではまだ使えず、数ヶ月以内には使えるようになるかと思います。

f:id:nnasaki:20180615054931p:plain

Azure で Kubernetes を使ってみよう

この記事は Kubernetes2 Advent Calendar 2017 - Qiita の22日目です。

Microsoft Azure はコンテナをサポートしており、 Kubernetes を使う方法は主に3つあります。

  1. Azure Container Service (ACS)
  2. Azure Container Service Engine
  3. Azure Container Service (AKS)

2 の ACS Engine につきましては、ACS Engineを利用してAzure上にkubernetesをdeploy! | 技術的な何か。 にて記事が既にありますので、そちらをご参照ください。

今回は 3 の Azure Container Service (AKS) について説明します。

余談ですが、AKS の 「K」 は Container ではなく、 GCP や AWS と同様に Azure Kubernetes Service としてもらったほうが ACS と見分けが付きやすいのになぁと思ってます。

Azure Container Service (AKS) とは?

完全に Managed な Kubernetes のクラスターです。マスターは Microsoft によって管理され無料です。エージェントノードは VM の分だけ課金されます。クラスターのアップグレード、クラスターのスケールアウトなどがサポートされます。

ACS, ACS Engine, AKS どれを選べば良いの?

ACS との大きな違いは AKS はマスターの課金が無いことです。AKS は Managed で手間いらずな反面、カスタマイズに乏しいので VNET との統合などよりカスタマイズが必要であれば、ACS Engine を選択するべきだと思います。 Kubernetes を使うにあたって、 ACS を選択する理由は SLA が必要であればとリージョンぐらいで、積極的に選択する理由は無いと思っています。

まとめると次のとおりです。

  • ACS
    • SLA が欲しい
    • 日本リージョンで使いたい
  • ACS Engine
    • kubernetes のカスタマイズがしたい
  • AKS
    • プレビューを受け入れられる
    • リージョンは問わない
    • Kubernetes の管理はなるべく手間をかけたくない

また余談ですが、単純に Web アプリを Docker コンテナを動かしたいだけであれば、 Azure Container Instancesが便利です。また、production, staging, development などの複数環境でブルーグリーンデプロイをしたいのであれば、Web App for Containersが便利です。

kubernetes よりお手軽にコンテナを運用出来ますので、是非あわせてお試しください。

AKS の作り方

早速試してみましょう。今回は次のクイックスタートを行ってみます。

docs.microsoft.com

非常に簡単です。次のデモをご覧下さい。(Introducing AKS (managed Kubernetes) and Azure Container Registry improvements | Blog | Microsoft Azureより引用)

f:id:nnasaki:20171221125017g:plain

Azure Account を持っている人は次の Launch Cloud Shell のボタンを押すと、すぐに試すことが出来ます。

Launch Cloud Shell

アカウントをお持ちで無い方は、無料サインアップでアカウントを作成してください。AKS はすべて無料枠で試すことが可能です。

Cloud Shell にて次の3行を入力するだけで、kubernetesクラスターが立ち上がります。

az provider register -n Microsoft.ContainerService
az group create --name myResourceGroup --location eastus
az aks create --resource-group myResourceGroup --name myK8sCluster --node-count 1 --generate-ssh-keys

AKS の使い方

通常の kubernetes と変わりません。

Cloud Shell では kubectl が既に入っているので、 az aks get-credentials --resource-group myResourceGroup --name myK8sCluster をしてクレデンシャルを引っ張ってくれば、kubectl にて操作できるようになります。

例えば kubectl get nodes をすればノードの一覧が表示されます。

出力例:

NAME                       STATUS    ROLES     AGE       VERSION
aks-nodepool1-34892656-0   Ready     agent     1h        v1.7.7

アプリケーションの実行方法

通常の kubernetes と変わりません。yml を作成して、kubectl create すれば実行されます。サンプルで提供されている azure-vote.yml を Cloud Shell 上で作成します。 cat > azure-vote.yml などで以下をコピペして作って下さい。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      containers:
      - name: azure-vote-back
        image: redis
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      containers:
      - name: azure-vote-front
        image: microsoft/azure-vote-front:redis-v1
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

作成後 kubectl create -f azure-vote.yml でアプリケーションを実行します。

アプリケーションを確認する

実行後サービス開始までには時間がかかります。 kubectl get service azure-vote-front --watch にて azure-vote-front サービスの EXTERNAL-IP が <pending> から IP アドレスに変わりましたらブラウザにてアクセス可能になります。

f:id:nnasaki:20171222001500p:plain

AKS を削除する

試し終わりましたら、次のコマンドですべてのリソースを削除できます。削除が終われば課金が止まります。

az group delete --name myResourceGroup --yes --no-wait

まとめ

Azure でも Kubernetes サポートに力を入れていることをご紹介いたしました。

開発体制もかなり強化しており、Kubernetes co-founder である brendandburns(@brendandburns)氏 が Microsoft に Join しています。Deis, Inc. | The Kubernetes Company を買収したりしています。

Kubernetes を使う際は是非 Azure も選択肢の1つとしてお選びください。

サーバーレスでお手軽 Storage お掃除

Microsoft Azure Advent Calendar 2017 16日目の記事です。

qiita.com

これはなに?

Logic Apps で Azure Blob Storage に保存されたファイルを定期的にお掃除します。

皆さんそろそろ年末の大掃除の季節ですよね?大掃除毎年大変ですよね?でも、お掃除は毎日やっていれば大掃除しなくて済みますよね?でも、面倒臭いですよね?

そうですよね。毎日やりましょう。それもお手軽簡単に。

今回のイメージは次の図のような感じです。例えば Linux から cron で定期的に Azure Blob Storage に保存されているファイル(ログとかDBバックアップとか)を、Logic Apps で毎晩30日より古いファイルを削除します。

f:id:nnasaki:20171214105954p:plain

Logic Apps についてはリンク先を見てください。簡単にいうとコーディング無しでサーバーレスで動きます。

azure.microsoft.com

なにが嬉しいの?

沢山あります。某牛丼風に言うとこんな感じです。

  • 安い
    • 1アクション ¥0.002856 円!
    • 1000 アクションで ¥2.8 円です
    • 毎日定期実行で年間数円レベルですよ
  • 早い
    • 実行速度はそんなに速くありませんが、生産性がめちゃめちゃ高いです。すぐ作れます。
    • 今まで何世代前削除というのをシェルでゴニョゴニョ書いてcronで回すという手間が省けます
  • うまい
    • SLAがついていますので安心して実行を任せられます
    • 実行したログも残りますのでエビデンスガー勢も押さえ込めます

ね?もう VM 立てて cron でバッチとかやる必要無いでしょ?

どうやるの?

Azure Storage にBackup をする

Linux から Azure Storage にバックアップを保存。今回の本題から外れるので省略します。 Azure CLI 2.0 などを使ってシェルを作成し、cron で回したりすれば出来ます。 Linux からの Backup は結局 cron 使うのかよっていうツッコミはとりあえず置いておきます。

Logic Apps を作成する

ポータルから Logic Apps を作成し、テンプレートのカテゴリで「スケジュール」を選択後、「Delete old Azure blobs」を選択

f:id:nnasaki:20171213150541p:plain

「このテンプレートを使用する」を選択

f:id:nnasaki:20171213151218p:plain

「作成」を選択

f:id:nnasaki:20171213151406p:plain

「接続名」に名前を入力し、「ストレージアカウント」を選択して、「作成」をクリック

f:id:nnasaki:20171213151529p:plain

「続行」をクリック

f:id:nnasaki:20171213151634p:plain

沢山出てきますが、ひとつひとつ設定していきます。

f:id:nnasaki:20171213152356p:plain

Recurrence

繰り返す頻度です。デフォルトで1日1回になっています。 これで良ければ変更する必要はありません。

f:id:nnasaki:20171213152006p:plain

Set expiration age variable

何日前のファイルを消すか設定します。デフォルトは30日前です。 これで良ければ変更する必要はありません。

f:id:nnasaki:20171213152420p:plain

List blobs

削除対象のフォルダーを指定します。必須です。

f:id:nnasaki:20171213152528p:plain

今回は backup-test を選択しました。

f:id:nnasaki:20171213152743p:plain

For each

実際の削除処理です。先ほど選択したフォルダ内のファイルを1つずつ最終更新日時を見て、 Set expiration age variable で設定した日数より古ければ削除します。特にここも変更する必要はありません。

f:id:nnasaki:20171213152615p:plain

最後に保存して完了です。

Logic Apps を実行する

実行は1日に1回されますが、すぐに確認したい場合は「概要」の「トリガーの実行」をクリックします。

f:id:nnasaki:20171213153741p:plain

起動に成功すればこのように実行の履歴に「成功」と表示されます。

f:id:nnasaki:20171213153850p:plain

さらに、履歴をクリックすると、「実行の履歴」を表示します。

f:id:nnasaki:20171213154007p:plain

さらに、各項目をクリックすると実行結果も表示してくれるのでデバッグも楽ですね。

f:id:nnasaki:20171213154121p:plain

ファイルを確認すると本日(執筆時点の12/13)のファイルがあるときに実行したしたので、まだ消されていませんでした。

f:id:nnasaki:20171213154455p:plain

まとめ

Logic Apps 便利で簡単で良いですね!


【オマケ】本当に動いているかテストする

ここから下は本当に動作しているか不安な人向けの記述です。手っ取り早く試したい人には不要なので読まなくて良いです。オマケのほうが本編より長いので。

さきほどは31日前のファイルが実際に削除するかは確認出来ませんでした。というのも、Azure Blob Storage の最終更新日(last-modified)を参照しているのですが、このプロパティはユーザーが手動で変更出来ないためです。

そこで、今回はストレージに meta-data を手動で付与して、強制的に31日前にして動作確認することにしました。

流れとしてはこんな感じです。先の Logic Apps に追加分を【追加】としています。

  • 【追加】Storage の meta-data に date を設定する
  • 【追加】Storage の SAS トークンを取得
  • ファイルの一覧を取得
  • 一覧をループ
    • 【追加】ファイルの meta-data から日付を取得
    • 【追加】ファイルの meta-data で比較して削除する

順番に見ていきましょう

【追加】Storage の meta-data に date を設定する

動作確認なので portal にて設定してしまいましょう。 BLOBのメタデータの編集は次の図のようにクリックしていきます。

f:id:nnasaki:20171214123530p:plain

キーに date を追加し、値に 2017-12-13T06:01:56+00:00 を入れて保存。

f:id:nnasaki:20171214123559p:plain

削除したいファイルのほうはとりあえず11/1にしてみましょう。 同じようにキーに date を追加し、値に 2017-11-01T06:01:56+00:00 を入れて保存。

【追加】Storage の SAS トークンを取得

上記で設定した meta-data ですが、Logic Apps の Storage Connector から取得する方法がありません。 そこで、後述の「【追加】ファイルの meta-data から日付を取得」にて Storage の REST API を使用して取得します。この Storage の REST API の呼び出しは認証が必要でして、認証には Storage の SAS トークン(認証トークンのようなもの)取得が別途必要です。若干込み入った処理になりますので、今回は次の Azure Functions をデプロイして使います。

github.com

上記を Azure Functions に展開して、Logic Apps から REST API を呼び出すアクションを加えます。アクションの追加は「+」のボタンを押すことで追加できます。次のような設定になりました。

f:id:nnasaki:20171214124402p:plain

ファイルの一覧を取得

ここは変更ありません。

一覧をループ

【追加】ファイルの meta-data から日付を取得

For each の最初に次のような感じで追加します。

f:id:nnasaki:20171214125004p:plain

URI の部分は手動で設定が必要です。Logic Apps 上部のコードビューをクリックしてコードで編集します。

f:id:nnasaki:20171214143714p:plain

アクション名に「Get metadata」と付けていたので、「Get_metadata」で検索します。(スペースがアンダースコアに変わっているのに注意してください)

uriの部分に https://[ストレージアカウント名].blob.core.windows.net/[ストレージコンテナ名]/@{items('For_each')?['DisplayName']}?comp=metadata&@{body('Get_storage_SAS_token')?['token']} と入れてください。 @{body('Get_storage_SAS_token')?['token']} が Azure Functions を呼び出したアクションの Response Body 中の JSON token の部分となります。

f:id:nnasaki:20171214143921p:plain

【追加】ファイルの meta-data で比較して削除する

先ほどのコードビューにてループの Condition の expression を先ほど取得した meta-data の date を使用するように変更します。

下図の expression の部分を @less(ticks(outputs('Get_metadata')['headers']?['x-ms-meta-date']), ticks(addDays(utcnow(), variables('ExpirationAgeInDays')))) と書き換えます。

meta-data は REST API の Response Header に x-ms-meta- と付いてくるので注意してください。

f:id:nnasaki:20171214144603p:plain

この辺の書き方はちょっと慣れが必要ですが、ある程度 MS 系で XML をいじったことがある人は、なんとなく雰囲気で理解できるかと思います。文法など詳しいドキュメントはこちらにあります。

docs.microsoft.com

実行結果

1日も待っていられないのでまた、トリガーで実行してみます。今回2個のファイルを入れました。早速実行結果を見てみましょう。

1個目は条件を満たしていないのでスキップされました。

f:id:nnasaki:20171214150244p:plain

2個目は For each の「次へ」をクリックすると確認できます。先ほどと違って削除されました。

f:id:nnasaki:20171214150415p:plain

【オマケ】まとめ

動作テストついでに Logic Apps の組み方をちょっと説明してみました。こんな感じでチャチャっと組めます。足りない機能は Azure Functions を使ったり、アクションを追加すれば解決出来ます。料金も格安ですので、皆さん是非使ってくださいね!

尚、Logic Apps は日本語のユーザーグループ LogicFlow-ja があります。ご興味のある方は参加してください。

「Microsoft Azure開発者ガイド(第2版)」と「Azureアプリケーションアーキテクチャガイド」が公開されました

「さとうなおきの「週刊アジュール」 ― 第13回」を見ていたところ、「Microsoft Azure開発者ガイド(第2版)」と「Azureアプリケーションアーキテクチャガイド」が公開されていることを思い出しました。

ascii.jp

どちらもこれから Azure を始める人にも既に Azure を使っている人にも役立つと思いますので、是非目を通しておくことをオススメします。

「Microsoft Azure開発者ガイド(第2版)」

開発者とついていますので難しく感じますが、インフラやはじめての人にもお勧めでです。

Azure の各サービスの概要がまとまっていて、どんなことが出来るかというのが理解しやすく感じました。中々こういった資料って無いので貴重に感じました。

azure.microsoft.com

「Azureアプリケーションアーキテクチャガイド」

こちらは高度な内容が含まれていますが、実際にアプリケーションを設計する際のヒントが沢山あります。Azure を使い始めていたり、他のクラウドから乗り換える人にもお勧めです。Azure だけでは無くクラウドネイティブアプリケーションを作る際の設計のヒントにもなるかと思います。

docs.microsoft.com

Azure Container Instances が出た!

f:id:nnasaki:20170727021747p:plain

azure.microsoft.com

でました。コマンド一発でDockerコンテナがAzure上で動きます。nginxを動かすにはこうですっ!(aci_grpリソースグループがある前提)

az container create -g aci_grp --name nginx --image library/nginx --ip-address public

ブラウザでアクセスすると確かに表示される。

f:id:nnasaki:20170727015730p:plain

あれ、これっていきなりGAなの?って思ったら違う。

Container Instances are available today in public preview for Linux containers. Windows container support will be available in the coming weeks.

Linux コンテナは Public Preview。Windows コンテナはもうすぐサポートというけど動くという噂

Kubenetes の Node としても動きます。

github.com

Registering into the Kubernetes data plane as a Node with unlimited capacity

アンリミテッド!なんか強そう。

あくまでNodeとして動くので、Kubenetesのクラスタ自体はあらかじめ Azure Container Service などで作っておく必要があります。試して失敗した人の画像はこちら。

VMの管理なんてしたくないので、Kubenetesのクラスタ自体もACIベースで作ってくれると嬉しいんですけどねぇ。。。そのうちなってくれるかな?(チラッチラッ

Spring Boot を Azure Container Instances で動かす

https://hub.docker.com/r/nnasaki/spring-boot-sample/ にまっさらな Spring Boot アプリがあったので動かしてみました。port が 8080 なのでportの設定が必要です。もちろん Spring Boot で 80 の設定をしていれば必要ありません。

az container create -g aci_grp --name spring-boot-sample --image nnasaki/spring-boot-sample --ip-address public --port 8080

ブラウザで確認すると無事表示されました。

f:id:nnasaki:20170727020800p:plain

お値段

Pricing - Container Instances | Microsoft Azure

秒単位で課金です。24時間立ち上げる場合は普通のVMより若干高くなりそう。

起動時間はコンテナのイメージサイズにもよりますが、nginxなら数秒で立ち上がるので、オートスケールに使えそうな感じです。

まとめ

簡単。便利。

Docker 使う理由がまた1つ増えました。

サクッと作れるので、開発用とはもちろん、LTとかでもデモが映える感じ。

特に開発時にコンテナを使い捨てる Draft とはめっちゃ相性いいんじゃないですかね。

github.com

参考リンク

Azure Container Instancesbuchizo.wordpress.com

blog.shibayan.jp

Azure Managed Disk(管理ディスク) を節約して使う

blog.nnasaki.com

Azure Stack を Azure 上で構築したのは良かったですが、常時立ち上げているとお金がかかります。https://azure.microsoft.com/ja-jp/pricing/calculator/で見積もるとこんな感じです。

f:id:nnasaki:20170725155406p:plain

インスタンスサイズとかちょっと違うので正確ではありませんが、だいたい 18万/月ですね。

Manged Disk(管理ディスク) は使っても使わなくても同じ値段

VMについては300円/時間ぐらいなので、検証しているときだけ付けておけばなんとかなるのですが、ストレージが問題ですね。SSDを使ったPremium管理ディスクの場合、仮想マシンを停止していても課金がされます。なので約3.7万/月が固定費とかかってしまうことになるので、これは避けたい。

f:id:nnasaki:20170725155809p:plain

解決策:VMを止めている間はスタンダードに変更する

Manged Disk(管理ディスク) はVMを停止していれば、ポータルから簡単にスタンダードとプレミアムを変更できます。

f:id:nnasaki:20170725160218p:plain

ですが、今回ディスクが5本あるのでいちいちポータルでやるのは面倒くさい。そうするとコマンドラインでやろうかなと思います。思い出したらAzure Container Serviceを使ったときも同じようなことを書いていました。

blog.nnasaki.com

今はわざわざインストールしなくてもポータルから Azure Cloud Shell を使用すれば、すぐに実行出来ます。コマンドはこんな感じです。 -g azurestack は各自のリソースグループ名に変更してください。

az disk update --sku Standard_LRS --ids $(az disk list -g azurestack --query "[].id" -o tsv) --no-wait

f:id:nnasaki:20170725160920p:plain

節約効果は

5548円/月になりました。およそ1/7ぐらいでこれくらいならなんとかという感じです。

f:id:nnasaki:20170725161231p:plain

起動するときはPremiumに戻す

このままでも起動は出来るんですが、パフォーマンスが著しく落ちるので、SSDに戻します。VMを停止した状態で行ってください。

az disk update --sku Premium_LRS --ids $(az disk list -g azurestack --query "[].id" -o tsv) --no-wait

まとめ

VMの停止と起動の度にコマンド実行を忘れそうですので、Azure Automation で自動化するもよし、VMの操作もCLIでやるもよし。ご利用は計画的に。

AzureStack on Azure を作ってみた

azurestack.blog

Azure 上で Azure Stack を動かすという誰得な話ですが、ハードが必要なく必要な時だけ1時間数百円ほどで検証できます。まずはどんな感じか触ってみたいとかPoCとしてはコスト削減が出来るので、意外と良いかもしれません。

やってはいけないこと

  • コンピューター名を azurestack にする
    • インストールスクリプトでエラーになる。ポータルで VM を作成する際は azurestack 以外の名前にすること

注意点

  • インストールスクリプトを流している間に、リモートデスクトップセッションが切れて入り直す場合、ADを作成したあたりのタイミングから Administrator ではなく、 AzureStack\AzureStackAdmin で入らないと、セッションの復元が出来なくなる。さらに Administrator ではインストールスクリプトを流せなくなる。

所要時間

躓きながらやってたので、土日でなんとか出来た感じ。 慣れれば放置している時間が長いので、5時間ぐらいあれば出来そうな気はする。

前準備

  • 余裕のある Azure サブスクリプション
  • コア数制限解除
  • Windows Server 2016 E16s v3 (16 cores, 128 GB memory) 以上
    • あくまでMinimum。もう一つ上の E32s v3 (32 cores, 256 GB memori) 以上が推奨

手順

  • VM にリモートデスクトップする
  • 管理者ユーザーのyournameをadministratorに変更
Rename-LocalUser -Name yourname -NewName Administrator
  • ログオフ
  • Azureポータルで停止
  • AzureポータルでOSDiskを256GB、データディスクを256GB4本
  • Azureポータルで開始
  • ディスクマネージャーでCドライブを256に拡張
  • データディスクをGPTで初期化
  • タイムゾーンを東京にする
  • IE Enhanced Security Configuration を無効化
    • f:id:nnasaki:20170722100627p:plain
  • 次のスクリプトでHyper-Vなど必要な機能を有効化
Add-WindowsFeature Hyper-V, Failover-Clustering, Web-Server -IncludeManagementTools
Add-WindowsFeature RSAT-AD-PowerShell, RSAT-ADDS -IncludeAllSubFeature
Install-PackageProvider nuget –Verbose
  • 再起動
  • Azure Stack Development Kit をダウンロード https://azure.microsoft.com/en-us/overview/azure-stack/development-kit/
  • Azure Stack Development Kit を起動して、必要なファイルをダウンロード、解凍
    • f:id:nnasaki:20170722123006p:plain
  • CloudBuilder.vhdx をマウントして CloudDeployment , fwupdate , tools をCドライブ直下にコピーする。CloudBuilderはイジェクトする。
  • 次のスクリプトのyourdirectoryを自分のディレクトリに変更して実行
cd C:\CloudDeployment\Setup
.\InstallAzureStackPOC.ps1 -InfraAzureDirectoryTenantName yourdirectory.onmicrosoft.com -NATIPv4Subnet 172.16.0.0/24 -NATIPv4Address 172.16.0.2 -NATIPv4DefaultGateway 172.16.0.1 -Verbose
  • administrator パスワード入力
  • しばらくすると Azure のアカウントを入力
  • エラーが起こる
    • f:id:nnasaki:20170722140421p:plain
  • C:\CloudDeployment\Roles\PhysicalMachines\Tests\BareMetal.Tests.ps1 を 開いて $isVirtualizedDeployment-not を消す。3箇所ある
    • f:id:nnasaki:20170722140713p:plain
  • 下記コマンドを実行
.\InstallAzureStackPOC.ps1 -Rerun -Verbose
  • CredSSP エラーが起きる

    • f:id:nnasaki:20170723012640p:plain
  • 次のスクリプトを実行

Enable-WSManCredSSP -Role Server
Set-Item wsman:localhost\client\trustedhosts -Value *
Enable-WSManCredSSP -Role Client -DelegateComputer *
  • gpedit.msc を開いて、Local Computer Policy > Computer Configuration > Administrative Templates > System > Credential DelegationAllow Delegating Fresh Credentials with NTLM-only Server Authentication を有効にして、 WSMAN/* の value を追加する。

    • f:id:nnasaki:20170723013026p:plain
  • 再び下記コマンドを実行

.\InstallAzureStackPOC.ps1 -Rerun -Verbose
  • 数時間後エラー VERBOSE: 1> [IdentityProvider:Deployment] ERROR: An error occurred while trying to verify connection to the graph endpoint
    • f:id:nnasaki:20170723093415p:plain
    • IE でなにも見えない状態になっていた。NATが失敗してる?
    • 下記NATSwitchを追加する手順を行ったら、IEからも見られるようになった
New-VMSwitch -Name "NATSwitch" -SwitchType Internal -Verbose
$NIC=Get-NetAdapter|Out-GridView -PassThru
New-NetIPAddress -IPAddress 172.16.0.1 -PrefixLength 24 -InterfaceIndex $NIC.ifIndex
New-NetNat -Name "NATSwitch" -InternalIPInterfaceAddressPrefix "172.16.0.0/24" –Verbose

デプロイ完了

f:id:nnasaki:20170723163952p:plain

使い方

https://portal.local.azurestack.external/ にアクセス

キタ━(・∀・)━!!!!

f:id:nnasaki:20170723164429p:plain

まとめ

手順をまとめるとすんなりに見えますが、最初 azurestack という安易な名前にしたため、スクリプトが謎エラーでコケて作り直したり、スナップショットから復元したりと結構試行錯誤しました。

使い方についてはまた別途ご紹介したいと思います。

参考サイト

azurestack.blog

docs.microsoft.com

www.projectsr.net

Azure スキルのトレーニングを受けてみた

Azure Training Courses | Microsoft Learning というものがあり、試しに受講してみました。無料でどなたでも利用できます。

ページにはこんな感じで複数のコースが日本語で並んでいます。英語の物もあります。

f:id:nnasaki:20170620182229p:plain

今回は「Azure 基礎」と「AWS の専門家のための Microsoft Azure」を受けてみました。 理由は基礎周りの確認と、AWSの知識とAzureの知識を紐付けるためです。

若干日本語が怪しい部分もありますが、気にせず進めましょう。

f:id:nnasaki:20170620182512p:plain

Open edXというものが使われているらしく、インタラクティブに進みながら、動画やテキストで知識の確認が出来ます。

このように、章ごとに確認問題で理解度チェックが出来ます。

f:id:nnasaki:20170620182658p:plain

最終試験に合格すると証明書が発行されます。遠い昔、MCPに合格した時はビルゲイツのサインでしたが、今はサティア・ナデラなんですねー。感慨深い。

f:id:nnasaki:20170620182953p:plain

まとめ

良かった点

「Azure 基礎」ではあやふやだった知識が再度確認出来たと思います。

「AWS の専門家のための Microsoft Azure」ではAzureでのサービスはAWSだとこういうのかー。という感じで理解が深まりました。

実際の時間は空いた時間に気分転換も兼ねてやっていたのですが、おそらく8時間もかかっていないと思います。集中してやれば1日かからず出来るのではと思います。

受講するとき気をつけた方が良い点

「AWS の専門家のための Microsoft Azure」はこんな感じで機能比較表とかあり、わかりやすい感じでした。Direct Connectが直接接続と訳されていてちょっと訳しすぎな感じがありますが…

f:id:nnasaki:20170620183455p:plain f:id:nnasaki:20170620183542p:plain

Azure Functionsも選択肢では「関数」というように訳されており、ちょっと推測が必要になっていますので、お気を付け下さい。

JAWS-UG仙台で「Azure使いから見たAWSの良いところ」を発表しました

JAWS-UG 仙台勉強会 [6/23夜] にて「Azure使いから見たAWSの良いところ」を発表しました。

JAWS-UG 仙台の皆さん親切にしていただき、2度目か3度目の発表になります。幸いなことに興味を持っていただいた方が多く、資料公開後も沢山の反響をいただきました。

今回はAWSとAzureを比較してどちらが良い・悪いではなく、設計方針の違いについて説明したつもりです。スライド50枚に対して時間が15分で大分早口になってしまったので、若干誤解して伝わったかもしれません。

今度はJAZUG 東北でもJAWS-UGの方がお話したいとも伺っていますので、近々JAZUG 東北を開催します。具体的な日程と場所が決まり次第、本Blogでも告知いたしますので、皆さん楽しみにしていてください!

de:code 2017 のセッション資料・動画が公開されました

タイトルの通り、de:code 2017 のセッション資料・動画が公開されました。

前半は戸倉さんによるMobile Appsを活用し node.js を使用したデモと Cloud Shell のデモです。後半は私自身の体験を元に、VM から Azure Web Apps on Linux に移行するシナリオとメリットを解説しています。

スライド

動画

Azure Container Service における設計上の注意点

Azure Container Service(ACS) にて kubernetes を作成した場合、2017/5/29現在はストレージアカウントの制限を受けるため注意して下さい。

何故かというと Azure Container Service の Agent(Node) はストレージアカウントごとに10個VMを作ります。

f:id:nnasaki:20170527103838p:plain

ストレージアカウントには下図の通り、最大IOPSとスループットの制限があります。

f:id:nnasaki:20170527104220p:plain

下図のように片方のストレージアカウントのコンテナに負荷がかかると、上限に引っかかる場合があり、もう片方のストレージアカウントに余裕があっても負荷分散が出来ません。

f:id:nnasaki:20170527104236p:plain

これを解決するための手段はストレージアカウントを意識して自分でコンテナを再配置することが必要ですが、具体的にどのようにするかはちょっと分かっていないです。

ですが、悲観的になる必要は無くて、ストレージアカウントの制限については Managed Disk(管理ディスク)が使用できるようになれば解決すると思われます。

f:id:nnasaki:20170527110329p:plain

管理ディスクを使用する場合、今すぐできる解決策と将来に期待する2つの選択肢があると思いますので、ご紹介します。

今すぐできる解決策

ACS Engine という OSS プロジェクトを利用することで、Azure Manged Disk(管理ディスク)を使用して、KubernetesやMesosとDocker Swarmをデプロイすることが出来ます。

ACS Engine については Container Service についてよく寄せられる質問 を引用します。

Azure Container Service と ACS Engine の違いは何ですか。

Azure Container Service は SLA による保証が付いた Azure サービスで、Azure Portal の各種機能、Azure コマンドライン ツール、Azure API が付属しています。 Azure Container Service を使用すると、比較的少ない選択肢を選んで構成するだけで、標準のコンテナー オーケストレーション ツールを実行するクラスターを簡単に実装して管理できます。
ACS Engine はオープンソース プロジェクトで、パワー ユーザーがクラスター構成を各レベルでカスタマイズするのに適しています。 インフラとソフトウェアの両方の構成に変更を加えることができるため、ACS Engine には SLA が用意されていません。 サポートは、Microsoft の公式チャネルではなく、GitHub のオープンソース プロジェクトを通じて提供されます。

ただし、Kubernetes の場合 PersistentVolumeClaims(PVC, 永続ボリューム) には管理ディスクは現在非対応で、1.7でサポートされる予定だそうです。

github.com

将来に期待する

Virtual Machine Scale Sets(VMSS) が管理ディスク対応になってますので、Azure Container Service も VMSS 上で構築されているため(Kubernetesは現在そうなってないけど)将来的にはサポートされると考えています。

まとめ

Azure Container Service で管理ディスクが早くサポートされると良いなぁと思います。

de:code 2017で発表してきました

de:code (decode) 2017 | 日本マイクロソフトの開発者/アーキテクト/IT Pro 向けイベント - Microsoft Events &amp; Seminars

「OSS on Azure で構築するモバイル バックエンド」でテクニカル エバンジェリストの戸倉さんと一緒に発表しました。

数千人集まる大規模な有償イベントでは初の登壇でしたので、大変緊張しましたが貴重な経験をさせていただきました。

資料と録画は後日公開されますが、書ける範囲で簡単にまとめておきます。発表内容は前半Mobile Appsの部分は戸倉さんに対応していただき、私の発表は次の通りです。

  • 事例紹介 Linux と Java で構築
  • VirtualMachineだったので、辛いところもあった
  • 今から作るならWeb Apps On Linux
  • Docker は良いぞ
  • Azure Database for MySQL or PostgreSQL 出ましたね
  • どちらもまだプレビューだけど期待大ですね
  • Demo

DemoではOpenCVを扱い、画像をアップロードして顔認識をさせました。

f:id:nnasaki:20170526072756p:plain

Web Apps On Linuxのデプロイメントスロットを使用して、ちょっと改造したり

f:id:nnasaki:20170526073951p:plain

反省点

デモは本番で失敗してしまい、事前に録画しておいたムービーを流しました。失敗した理由はIPv6環境でlocalhostが通らなかったからです。

リハでは有線LANがドライバ不足で使えず、当日有線LANを使用したところIPv6が有線されてしまい localhost に接続できなかった模様です。

あとは声が出にくかったりなどなど、数えると切りが無く。

まとめ

スピーカーとして最終日の最後でしたので、自分の番が終わるまで落ち着きませんでした。セッションを何個か見ましたが頭に入ってこない感じ。

私の発表は導入部分について、なぜ導入するか?導入すると皆さんにどういうメリットがあるかという部分を中心に説明しましたので、技術的な機能紹介はポイントを絞り、あえて削りました。 Web Apps On Linuxについてはしばやん先生が既に資料も公開しておりますので、詳しくはそちらを参照していただくと良いです。

blog.shibayan.jp

Azure Database for MySQL/PostgreSQL についてはテクエバの久森さんが、 「Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介」というタイトルで発表されていますので、詳しくはそちらをご参照ください。

おまけ

Azure Thursday Japan (仮) #69 にも初出演させていただきました。de:code振り返りや最新Azureアップデートについて話しましたので、もし良かったら聞いて下さい。

www.youtube.com

【Build 2017】Azure Compute 新機能とロードマップ

f:id:nnasaki:20170514003947p:plain

Build 2017 の Corey Sanders のセッションを見ましたAzure Compute 新機能とロードマップが発表されました。Azure Computeは仮想マシンをはじめとしたカテゴリです。聞いててわくわくしますねー。スライドと動画は次のリンクから確認できます。

channel9.msdn.com

続きを読む