世界のやまさ

SEKAI NO YAMASA

トップ > Azure

デプロイに失敗した場合の再デプロイが便利になっていた

Azure

前回の記事中にチラッと書いたんですが、便利になったので改めて記事に書き起こしました。

blog.nnasaki.com

よくなんらかの原因でデプロイに失敗すると、アラートが表示されてこんな画面が出ます。

f:id:nnasaki:20170504221636p:plain

そのときのエラー画面の上の方に次の画面が表示され、そこに「再デプロイ」というボタンがあるので、ポチッと押します。

f:id:nnasaki:20170504221858p:plain

すると、カスタムデプロイという見慣れない画面に飛ばされますが、ここでエラーの原因となっていた情報を再度入れ直します。先のエラーだとリージョンがダメだったようなので、東南アジアにしてみました。VM Sizeも一応直しておきます。

f:id:nnasaki:20170504222717p:plain

スクロールを下にしていくと、Marketplace から購入したわけじゃないけど、とりあえずチェックを入れて購入を押します。

f:id:nnasaki:20170504222153p:plain

無事作成出来ました。

f:id:nnasaki:20170504223929p:plain

前は失敗すると、また一から作り直しだったんですが便利になりました。どうやら次のフィードバックを取り入れてくれたようです。

completed
How can the Azure portal be improved?
  • 19 votes
  • 4 comments

Be able to reconfigure a failed deployment and relaunch it

Sometimes, a deployment fails for different reasons: bad parametering, inappropriate context or runtime error (quite often in this stage of the portal and API). It would be very useful to be able to reopen the workflow from a deployment (the UI worlflow, if it was made via UI). Then it could be ...

feedback.azure.com

https://feedback.azure.com の意見は本当に開発者がよく見ているようなので、気に入らないところがあれば投稿するようにして、一致する意見があればVoteしてあげると良いと思います。

コンテナ管理はどれを選ぶべき？Azure Container Service で使用出来る Docker Swarm、Mesosphere DC/OS、 Kubernetes の3つを比較してみた。

Azure Azure Container Services kubernetes

f:id:nnasaki:20170508142056p:plain

Azure Container Service ではオーケストレーションを選択する自由が有り、 Docker Swarm、Mesosphere DC/OS、 Kubernetes のいずれかを選べます。

3つも選べることは良いことなのですが、初めて使うと正直どれを選べば良いか迷います。

結論：Kubernetes を選ぶべき

結論から先に言うと Kubernetes を選ぶべきだと思います。今回はあまり技術的な部分（アーキテクチャ、機能性、安定性、性能）は触れずに、自分が普段行っている比較でまとめてみました。

理由1：Githubで比べる

OSSのプロダクトでどれを選ぶべきか迷った場合は、GithubのPulseを参考にすると良いです。Docker Swarm、Mesosphere DC/OS、 Kubernetes のそれぞれ1ヶ月分を見ていきます。

Docker Swarm

f:id:nnasaki:20170508130001p:plain https://github.com/docker/swarm/pulse/monthly

  • Star数
    • 4470 かなりある。
  • PR数
    • 10 とかなり少ない
  • Issue数
    • Close より Open のほうが多く若干良くない兆候
  • Authors
  • 3人と少ない

Mesosphere DC/OS

DC/OSはボリュームが少なかったので、marathonで比較した。

f:id:nnasaki:20170508140106p:plain https://github.com/mesosphere/marathon/pulse/monthly

  • Star数
    • 3233 かなりある。
  • PR数
    • 12 とかなり少ない
  • Issue数
    • Close が多くて○
  • Authors
  • 15人でまぁまぁ多い

Kubernetes

f:id:nnasaki:20170508125935p:plain https://github.com/kubernetes/kubernetes/pulse/monthly

  • Star数
    • 22956 他より一桁多い。
  • PR数
    • 886 他より一桁多い。
  • Issue数
    • Close は多いが新規もかなりある。Issueも溜まっており、品質は問題があるかもしれないが、それだけ叩かれているということでもある。
  • Authors
  • 172人 他より一桁多い。
  • 特定の人物に偏りが無く、OSSの存続性が高いといえる

OSSは止まってしまわないことが重要だと考えていますので、とにかく勢いがある Kubernetes に軍配が上がると思います。

理由２：Googleトレンドで比べる

f:id:nnasaki:20170508140801p:plain https://trends.google.co.jp/trends/explore?q=Docker%20Swarm,Mesosphere,Kubernetes

過去5年間でみると、Docker Swarm は微増。Mesosphere は横ばい。Kubernetesは急激に伸びていることがわかります。

国別でみるとアメリカでは Mesosphere が強いようです。 f:id:nnasaki:20170508141600p:plain

理由３：エンタープライズ対応があるか比べる

OSSを利用するだけでは無くエンタープライズのような大規模向けの場合、サポートが必要となることが多いです。有償サポートがあるかどうかで比較します。

  • Docker Swarm
    • Docker Enterprise がある
  • Mesosphere DC/OS
    • Mesosphere Enterprise が用意されている
  • Kubernetes
    • Redhat 社の openshift をはじめとしたパートナー企業のサポートがある

どれを選んでもサポートはありますので問題なさそうです。

理由４：事例で見る

どんなに優れていても実際に使えなければどうしようもありません。どんな事例があるかも重要なポイントになります。今回は Kubernetes しかあげませんが、ポケモンGOが動いている*1ってだけでかなり強い理由になるでしょう。

まとめ

Kubernetes が良いのではないかという最初の結論の通りです。今後技術的検証を進めるにつれて、印象は変わるかもしれませんが、今のところ Kubernetes を使用していきます。

追記：2017/5/11

Build 2017 で Service Fabric でもコンテナサポートが発表されました。

f:id:nnasaki:20170511121236p:plain

Microsoft Azure ではコンテナ管理は複数の選択肢があります。適材適所で選ぶ方法などはまた後日。

*1:正確にはGoogle Cloud上のGKEですが

Azure Container Service のエージェントを50にするとどうなるか？

Azure Azure Container Services kubernetes

Azure Container Service を使用して kubernetes のノードを50にしてみました。

f:id:nnasaki:20170508121911p:plain

VM数は53個

ノード50個にマスター3個で計53個になりました。圧巻です。リソースグループではネットワークインターフェンスなどがあるので計120個と表示されました。

f:id:nnasaki:20170508122051p:plain

CLIで仮想マシンをカウントするとキッチリ53個でした。

f:id:nnasaki:20170508122116p:plain

ストレージアカウントは４つ

ノード3つにマスター1つになりました。

f:id:nnasaki:20170508122324p:plain

このように各ストレージアカウントに分散してOSディスク用のblobが作られます。

f:id:nnasaki:20170508122443p:plain

ノード20個ごとに1ストレージアカウントが作られました。

TIPS:ストレージアカウントの制限について

ストレージアカウントごとにIOPSなどの制限があるので注意が必要です。

docs.microsoft.com

なお、管理ディスク(Managed Disk)を使用すればストレージアカウントの制限は無くなります。

ノード変更操作中のコンテナの動作について

50ノードとか課金が怖いので1時間もしないうちに5ノードに戻しましたチキンです。

ノード数の変更中もまったく問題ありません。ダッシュボードもデプロイ済みのアプリケーションも問題なく繋がりました。

まとめ

Azure Container Service のエージェント数の変更はまったく問題がありませんでしたが、ストレージアカウントの制限は気になるので 管理ディスク(Managed Disk) の対応が早くされると良いなと思います。 ACS-Engine の Issue や kubenetes の issue を見ると、kubenetes の 管理ディスク(Managed Disk) 対応はもう少し先になりそうです。

github.com

github.com