3大クラウドの大規模（オンライン）イベント状況
COVID-19 の影響もあり。。
今年の2月または3月頃から各種イベントのオンライン化が進んでおり、規模の大小問わず・・・・といった感じです。例年行われている大規模系イベントもこの流れで全セッションがオンライン化されています。私自身は昨年（リアルで） AWS / GCP のイベントに参加したのですが今年はオンライン化されるようです。というただの宣伝記事ですが。。
btsn.hatenablog.com
btsn.hatenablog.com
昨年リアル側で参加した感想としては会場の熱気を感じれるというところはメリットでどれだけそのパブリッククラウドが盛り上がっているのか、というのを知ることができます。そして、今年オンライン側で参加している感想としては熱気こそ感じ取りにくいものの、各セッションの入場制限なしに好きな時間に好きなセッションをゆっくり見れる、かつ場所を問わずというのがメリットです。それぞれにメリットがあると思います。
de:code 2020
既に開催済のイベントですが、6/30（火）までの開催期間がつい先日期間延長され、7/17（金）17:00 までになったそうです。既に全セッション公開済（段階的にセッションを公開していってた）のようなのでスタートが出遅れた方も今から一通り視聴可能だと思います！
btsn.hatenablog.com
Google Cloud Next ’20
GCP は 7/15（水） より開始で毎週、トピックが増えていく形を取るそうです。終了が 9/9（水） までとかなり長い感じです。
デジタル イベント Google Cloud Next ’20: OnAir のお知らせ: 7 月 14 日～9 月 8 日に開催 | Google Cloud Blog
AWS Summit Online
AWS は 9/8（火） より開始で 9/30（水） までの開催期間のようです。その中で初日 9/8（火） と 9/15（火） にはライブ配信アリのようです。Azure / GCP / AWS 全てに共通するのですが、「無料」というのが非常に有難いです！
AWS Summit Online | 2020年 9月 8日 (火) ～ 9月 30日 (水) オンラインで開催！
ということで
自分の好きなタイミングで好きなセッションを拝聴できる、ということで中々無い機会！是非！（今後はこのような形が主流になるのかもしれませんが。。）
Azure Shared Disks (Preview) に触れてみる【断念】
Azure Shared Disks ってなんぞや？
というところから。複数の仮想マシン（VM）からマネージドディスクを同時に接続できるという新機能です。オンプレミスに置き換えると SAN（Storage Area Network） でイメージすると分かりやすいです。Twitter 上でも話題になっていたので Web フォームからプレビュー版を申し込みました。
主な用途としてはクラスタ環境で動作しているアプリケーションになります。すぐにピンと来る例でいうと DB のフェールオーバーが必要なアプリケーション環境でしょうか。
折り返しのメールの From は MS で従事されている個人名のようでした、ちょっとビックリ。（勿論、英語で来ます。）
早速設定してみる
ここを参考に共有ディスクを有効にします。
Enable shared disks for Azure managed disks - Azure Windows Virtual Machines | Microsoft Docs
折り返しで来ていたメールには West Central US Region との記載があったので上記サイトを参考に「米国中西部」を指定してデプロイしました。無事デプロイが完了すると下記のようなイメージになります。
当たり前ではありますがデプロイしてすぐは何にもアタッチされていない状態です。
そこでまたドキュメントに戻って Azure PowerShell 部分を実行しようとしたのですが・・・・テスト用で利用している「Visual Studio Professional」のサブスクリプションは「米国中西部」に VM が作成できない関係で要件の1つである「ディスクを共有するすべての仮想マシンは、同じ近接配置グループに展開する必要があります。」を満たせません。（ちなみにポータルで VM を「米国中西部」に作成しようとすると下記のような感じになります）
解散！
Azure Arc (Preview) に触れてみる
先日の Microsoft Ignite にて
当ブログでも取り上げましたが、アメリカのオーランドで開催された Microsoft Ignite にて Azure Arc というサービスが紹介されていました。「コレなんぞや？」というところに関してはサービス紹介記事を別途あげているのでご覧下さいませ。
Azure Arc (Preview) を試してみる
現状はまだGAされておらず、Preview 状態です。ただ、試すことは出来るので概要を知るために下記サイトを参考にして。
クイック スタート - サーバー向け Azure Arc を使用してマシンを Azure に接続する - ポータル | Microsoft Docs
対象となるOSとして
・Windows Server 2012 R2 以降
・Ubuntu 16.04 および 18.04
が挙げられており、今回は前者の Windows Server 環境で試してみます。
まずは、https://aka.ms/hybridmachineportal にアクセス。未だこの時点では Azure Arc のターゲットとなるマシンは存在しない為、「追加」を押下します。
続いての画面に関しては「大規模に～～」というのが今回の趣旨ではなさそうなので「対話型スクリプトを使用したマシンの追加」を選択します。スクリプトの生成に関しては下記の形で作成しております。「地域」に関してはメタデータの格納場所になりますが、本日時点では「西ヨーロッパ」・「東南アジア」・「米国西部 2」の3カ所のみです。
その後の確認画面ではサブスクリプションの登録の為に「登録」を押下、その間にスクリプトを対象の Windows Server 側で PowerShell で実行しましょう。ちなみにファイルをダウンロードするのでカレントパスは適宜移動しておいて下さいませ。（スクリプトの3つ目に関しては自環境の情報が含まれるので意図的に隠しております。笑）
3つ目のスクリプト実行を行った際に URL と コードが表示されるので（別マシンのブラウザでもOKなので）URL 入力してコードも入力しましょう。
この通りに進行すると PowerShell（Windows Server 側）の画面では数十秒後にレスポンスが戻ってきます。
level=info msg="Successfully Onboarded Resource to Azure" VM Id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
完了し次第、Azure Arc のホーム画面に戻ると・・・・？
無事追加されていました！Azure の Portal 上に自マシンがあると変な感じですね。笑
今後の動向も含めてチェックしていこうと思います！
追記（Appendix）
2020/02/05
死活監視としてオフラインになるまで20分弱かかったような。ドキュメント上では「5分以内」との記述があったのですが環境のせいなのか。。
ターゲットに対するポリシー（準拠しているかどうか）の適用ができますが、下記のような画面になります。印象としては「オンプレ ＜ クラウド」寄りのポリシーが多い？感じです。
Microsoft Ignite 2019 振り返り
Microsoft Ignite とは？
アメリカのオーランドで 11/4～11/8 に行われたその名の通りマイクロソフト社が主催の開発者およびITプロフェッショナル向けの年次会議です。
また、当イベントをベースとし最も人気の高いコンテンツを選りすぐったツアーが全世界の30都市で Microsoft Ignite The Tour として開催されます。
Microsoft Ignite The Tour 2019-2020
私は 12/5・12/6 に開催される Tokyo の登録を行いました。Twitter 上で見つけた参加特典？のお話なのですがこんなのがあるそう、必見ですね！
Ignite と Ignite The Tour 参加者は、参加から6か月以内であれば、MS の認定試験を１つだけ無料になるみたい。https://t.co/6MELDGYhBJ
— こんごー (@kongou_ae) November 3, 2019
ちなみに、マイクロソフト社の社員の方や Microsoft MVP の方が多数 Twitter でつぶやいて下さっているのと良くまとまったブログもありますので私個人は挙げられた注目のサービスとまとまったブログのご紹介をするにとどめます。
今月の Jazug は2本目のセッションが現地へ行かれた方のセッションなので非常に楽しみにしています。（＋ 1本目のAKS のセッションも非常に興味アリ）
注目の数々！
Azure Arc
下記のお馴染みサイオスさんの記事が良くまとまっています。本日の記事で挙げるものは基本的にサイオスさんのものと被ってます。笑
ざっくり説明としてはマルチクラウド環境を統合管理（パッチ適用・自動アップデート）できるサービスです。まだ、プレビュー版でこれから随時機能拡張されていくのかと思われますが、先日発生した AWS の障害も踏まえて、今後マルチクラウドへの需要が高まっていくところを上手く見据えたサービスといえそうです。
Azure Synapse
このタイトルだけだと何のサービスかイマイチよく分からなかったのですが、SQL Data Warehouse を拡張したサービスのようです。
［速報］マイクロソフト、「Azure Synapse」発表。BigQuery対抗の大規模並列データ処理サービス。Ignite 2019 － Publickey
テラバイト・ペタバイト級のデータを扱う場合は今まで Google GCP の Big Query が最有力候補でしたがそれに対抗するサービスとして今回発表されました。今回のデモでは攻めたデモで Big Query で11分かかったものを Azure Synapse がたった9秒で検索してしまうという結果でした・・・・恐ろしい。クラウド専用としてアーキテクチャが構築されており、スケールアウトへの対応も万全なようです。（≒コスパも高い）
Power Virtual Agent
チャットボットがコーディングレスで作成できてしまうサービスなようです。今後、世の流れとしてはエンジニアでない職種の方も簡単に機能を構築できるような方向に変わっていきそうです。そんな中で発表された当機能。Azure Bot Service との切り分けは後ほど調べようと思いますが、コーディングレスという点から考えるとかなり簡易的なチャットボットが作成できる、という位置づけでしょうか。
Qiita の当記事は Ignite で当機能が発表されて割と間もないうちに書き上げられてました。とてもステキです！
Power Automate
前述のサイオスさんのブログでも「一番衝撃的」と書かれていましたが、私個人もこの発表が一番個人的でした。まさか、マイクロソフトが RPA に参入してくるとは、という印象で。WinActor や UiPath が有名どころですが Office 製品と親和性の高い（というか知り尽くしている。。）マイクロソフトの RPA となれば完全なる目玉の製品（機能）になるかと思います。
機能としては既存で存在する Microsoft Flow（さまざまなサービスを GUI で組み合わせてタスク自動化する） にユーザーインターフェース操作を自動化する（RPA）技術である「UI Flows」を追加したものです。Web ブラウザの操作記録に関しては「Selenium IDE」を利用するそう。
Power AutomateのUIフローを試してみました。 | 初心者備忘録
早速、機能を試されている方もいらっしゃるようです。
Visual Studio Online
もはや、Visual Studio もローカルではなくクラウド上で起動する時代になってしまったのか・・・・という感じですね。こちらも Power Automate に引き続き、衝撃的発表の内容のひとつです。
Visual Studio Online | サービス詳細 | Microsoft Azure
クラウド全般にいえることですが「利用したいときに利用したい分のリソースだけを利用する」という流れにあったサービスで Visual Studio Online もこれまた然りです。また、iPad のようなタブレットでも当サービスが利用できることを考えると「開発環境はもはや PC デバイスだけではない」という構図にもなります。そんな意味で衝撃的な発表内容でした。
Project Silica
サービス、という観点ではないのかもしれませんが個人的にそそられた発表で Project Silica という研究プロジェクトというものがありました。煮ても焼いても喪失しない石英ガラスデータ記録技術ということで利用目的としては「コールドデータ」（≒長期間のデータ保存）になりそうです。歴史を習っていて昔の書が発見されるのも凄いことなのですが、今後500年や1000年後にはこの石英ガラスが発見されて「昔の人はこんなことしてたのか」というのをデジタルデータのアーカイブで閲覧される、というのもまた凄いことですね。笑
何となくのまとめ
Big Query との比較が入った Azure Synapse や まさかの RPA 分野への参画となった Power Automate 等、満を持してのサービス発表が多かったような気がします。Azure は AWS よりは後発なのですが結果として AWS も 代表的なサービスである EC2 で マイクロソフトの Windows を利用しているわけで結果後追いでも巻き返せる算段はあるのかもしれません。RPA 分野も親和性の高い Office 製品を武器にすれば勢いは留まることを知らないことになりそうです。（持ち上げ過ぎ？）
とはいえ、Azure Arc のようなマルチクラウド環境を下支えするようなサービスも発表されたりと違った側面を見せ、今回の Ignite はとてもよいプロモーション活動になった気がします。
個人の課題として、来年は勿論本国で開催されるイベントへの参加は難しいわけですが、発表された内容をいち早く試してみるというレベルまでは持って行きたいところです。
その他のオススメのリンク
下記は最終日までを含め、要点要点をピックアップしてくださっており Ignite で何が発表されたんだろう？を知るにはとてもオススメです！
クラウドのデザインパターン
Kubernetes ネタは一休みして
先日のブログ記事として Kubernetes（AKS） を学ぶ旅として その11 までアップしましたが、コンテナオーケストレーションネタは少しお休みしてその他 Azure ネタに戻ろうと思います。
クラウドのデザインパターンとは？
私の場合、普段の実務でクラウドを扱うものが殆どない（あっても SaaS くらい）のでクラウド上でどのように設計すれば良いのかの導きがありません。ただ、今時は（Azure に限らず）各パブリッククラウドでやさしめのドキュメントを公開してくれています。Azure の場合は下記の通り。
AWS の場合は図説もあり非常に分かりやすいです。各実装に関しても表面部分ではありますが言及しており、当ドキュメントを拝読するだけでも簡易的な部分まではシステムが組めそうなくらいです。
ちなみに、GCP の場合は同じような検索キーワードでかけてもドキュメントらしいものは見当たりませんでした。この辺は Azure や AWS の方が充実していそうな。
クラウド設計パターンを拝読しての今後
どんなシステムを組んでいきたいかにもよりますが、基礎として知っておきたいものは下記の通りで。
https://portal.azure.com/#allservices より
コンピューティング
･･･ 過去記事でも挙げておりますがこれは押さえておきたい
･･･ これまた押さえておきたい基礎のキ
ネットワーキング
･･･ DNS機能により宛先サーバーの振り分けを行う
･･･ セキュリティで保護されたスケーラブルなエントリポイント
･･･ キャッシュできない動的コンテンツの動的サイトを高速化
WEB
･･･ 現状はプレビュー、マイクロソフトさんも力を入れている分野なので。
コンテナー
･･･ 折角学んだので継続して習得
データベース
･･･ これも以前、記事に挙げたものの深く知りたい。
分析
･･･ AI・機械学習関連ということで時代の流れに合わせて
AI + MACHINE LEARNING
･･･ 「Azure Databricks」と同じく
ID
･･･ Azure の ID 基盤として確実に押さえておきたいもの
DEVOPS
･･･ 「DevOps」は時代の流れに合わせて押さえておきたいキーワードなので
と、ザッと挙げてみたものの、これに限らず（各機能の）記事はアップしていく可能性があります。6月末頃にサブスクリプションを取得しまだ4ヶ月少々なので覚えることにキリはないですが地道に習得していきます！
Kubernetes（AKS）をやさしく学ぶ旅 その11
更にディープな Kubernetes を学ぶ旅へ（つづき）
その11 はざっくりとしたまとめになってしまいますが、残りの学んだ方がよい部分をピックアップ形式でお届けする形にします。ちなみに、長かった旅も今回でひとまず Closed とし、今後は知識を付加していく記事としてこの手の話題を上げていくようにします。
保守性
Kubernetes クラスターを運用する上で「バージョンアップ」がついて回ります。
・Kubernetes コンポーネントのバージョンアップ
・Kubernetes を動かすサーバーのバージョンアップ
機能の拡張は要／不要の判断が入るのですが、セキュリティの脆弱性他クリティカルな事項は基本「要」のみになるかと思います。ちなみに、Kubernetes でのバージョンの見方は下記の通りです。
（例）1.11.1 左：メジャー 真ん中：マイナー 右：パッチ
当記事を記載している 2019/10/31（木） 時点では 1.16.2 が最新です。
Pod が動作する Node を再起動する際に可能な限り影響する範囲をコントロールしたいです。Kubernetes には下記リンク先のような様々なしくみが提供されています。
また、Node の再起動を必要とする場合に再起動のコントロールをするしくみも提供さています。Kubernetes 自体がオープンソースですが、当しくみの Kured もオープンソースとして公開されています。マイクロソフトのドキュメントに Kured 関連記事が上がっていたので貼っておきます。
ちなみに、コンポーネントのアップグレードに関しても前述の Drain や Uncordon の仕組みを利用します。
リソース分離
こちらに関しては下記記事が非常にまとまっているのでオススメです。
実際に Kubernetes（クラスター） を運用していく上でトラブルを起こさないためにもセキュリティについては事前設計し考慮する必要がありそうです。
可観測性
そもそも、「可観測性」の定義とはなにかというところから。NTTソフトウェアイノベーションセンタの夏目様が Kubecon ＋ CloudNativeCon Europe 2019 に参加された際の記事に非常によくまとまっています。
可観測性（Observability）動向 - nttlabs - Medium
メトリック・ログ・トレースの3本を主体として「可観測性」が成り立ちます。個人利用もしているツールなのですがはてなさんが開発されている「mackerel」はサービス監視（外形監視）可能なツールとして紹介されています。
Azure 上でも「Azure Monitor」のようなメトリックとアラートのバックエンドサービス、更には可視化手段を提供してくれるサービスがあります。
コンテナー用 Azure Monitor の概要 | Microsoft Docs
リソース分離と同様ですが「絶対に必要」というわけではない（いや、必要か。笑）もののなかったことで後で痛い目を見ることがないようにしたいものです。
おまけ（1）
結果、今まで Kubernetes の記事として10近く上げてきたのですが結局、Kubernetes は使うべきなの使わないべきなの？という話題がついて回ると思います。これに関してマイクロソフトの寺田様がまとめてくださっている記事があるのでリンクを貼ります。
これに関連して Kubernetes のハンズオンイベントをときどき見かける（2days？）のですがどこかで参加したいなぁ・・・・。
おまけ（2）
プラスでハンズオンでも何度も実行している「kubectl」の手引きリンクを掲載致します。
Overview of kubectl - Kubernetes
おまけ（3）
こんなところをキャッチアップしていかないといけないところなのですが、Kubernetes に関わる記事として「Open Application Model」と「Dapr」があります。今月中旬頃に発表された記事ですが、今後のクラウド開発者の潮流がこの2サービスでどう変わっていくのかが楽しみなところです。自分自身も追随できるように日々是精進ですね！
おそらく、11/4～11/8にオーランドで開催される Microsoft Ignite でなにかしらの続報があるかも！？
追記（Appendix）
2019/11/04
Twitter でフォローしている方から Microsoft Learn に k8s のモジュールがあると聞き、早速やってみました。が、実は既にやっていました。復習の意味も兼ねてですが、短いモジュールながらも良くまとまっています。
Microsoft Azure を学ぶ上で役に立ちそうなリンク集
From Microsoft より
Microsoft Azure
言わずと知れた Microsoft Azure の公式ページです。まずはココから。
Azureの最新情報をキャッチ
日々更新される Azure の情報をキャッチする際に便利です。特に終了系の記事に関しては要チェックです。（終了系は寂しいですが。。）
分からないときはここを参照
Microsoft Azure のドキュメント | Microsoft Docs
Docs サイトです。最近は本当にドキュメントが充実しており助かります。各機能の簡易的なチュートリアルも掲載されていたりします。
Azureのサブスクリプション（課金）を気にせず気軽に学びたいなら
Microsoft Learn | Microsoft Docs
当ブログでも何度か取り上げている Microsoft Learn です。レベル上げの要素があり、RPG感覚で楽しめるので一度で二度おいしい感じです。最近はもくもく会も各地に少しずつ広がっています。
設計図を作成する際のアイコン集
リンク先のzipファイルをダウンロードし解凍すると利用用途によって分かれたフォルダ群が表示されます。かなり豊富です。
セミナー系
Webinar で学ぶ
JAZUG (Japan Azure User Group)
今年で丸9年を迎えた老舗？Azure コミュニティ。基本は月1でイベントが開催されており、東京地区はイベント開催から僅かな時間で登録が埋まってしまう程の超人気。
前述の Microsoft Learn のもくもく会に関するコミュニティです。一緒にもくもくするなら同志の方と進めるのが楽しいですよね！
おまけでTwitterアカウントも
Daiyu Hatakeyama (@dahatake) | Twitter
マイクロソフトの畠山様です。AI（Data Scientist） をメインとし、ソフトウェアのアーキテクチャ関連の Tweet もお届けくださってます。
Toru Makabe (@tmak_tw) | Twitter
マイクロソフトの真壁様です。インフラからアプリまで何でもござれの凄いお方です。海外の Tweet も含め Azure の最新情報を展開してくださるので勉強になります。
Shinya Yamaguchi (@izuru_yamarara) | Twitter
マイクロソフトの山口様です。Azure Active Directory 関連の Tweet （Qiita記事）がメインです。また、エンジニアの成長に関する Tweet もつぶやいてくださってます。
他、下記のリンクより Microsoft MVP (Azure) 受賞者一覧のページに飛べるので Twitter のリンクがある方はフォローしてみてはいかがでしょうか？（2019/10/30 42人）
他、何かあればまた追記していきます！
Kubernetes（AKS）をやさしく学ぶ旅 その10
更にディープな Kubernetes を学ぶ旅へ
その9 まではハンズオンを交えつつ記事にしていきましたが、以降はドキュメントサイトを参考にしつつアーキテクチャを学んでいく記事にします。幸いなことに昔に比べるとマイクロソフトのドキュメントは充実の一途を辿っており、基本はドキュメント先を見るだけでも十分学べると思います。笑
押さえた方がよい（と思う）アーキテクチャに関して
Reconciliation Loops
読了した本の共著の方でもあるマイクロソフトの真壁様の登壇資料（超良資料です！）でこのキーワードのことを詳しく解説されています。全画面で閲覧することをオススメします。
ネットワーク
読了した本で参考例として記載されていたのは kubenet と Azure SDN の話がメインでしたが、リンク先には CNI（Container Network Interface） のことも詳しく記載されています。大事なポイントとしては Kubernetes では Node 間だけでなく Pod 間の通信も視野に入れたネットワーク設計が必要になります。
可用性
「可用性」はこの業界にいるとよく聞くキーワードですが「システムが継続して稼働できる能力のこと」を指します。以前の記事にも記載している通りで Pod のレプリカ数を2以上に定義すれば複数の Node に Pod を分散できます。また Pod が動作している Node が NG になった際の挙動に関してもハンズオンしてみました。
視点を変えて、Kubernetes 本体（の可用性）を考えてみます。Kubernetes のコントロールを司るコンポーネント群は主に Master サーバー上に配置されます。（例：API Server / etcd / Controller Manager / Scheduler 等）
特に etcd はクリティカルな要素であり、それを冗長化するために Master サーバーを冗長化することが重要です。
ただし、注意点として前述の例で挙げた前2つは冗長化した環境においてアクティブ／アクティブですが後2つはアクティブ／スタンバイとなります。
後ろ2つは API Server 経由でウォッチされており、状態維持に努めるため、他とのオブジェクト操作に競合を起こさないようにアクティブ／スタンバイとしております。
Master と同様、Node の可用性も同じ構成のサーバーを増やすスケールアウトがベースのアプローチなようです。他は分散数等を考慮したりします。
拡張性
Kubernetes のアドオンとして開発されている Cluster Autoscaler が Node の水平自動スケール機能を担います。機能として「Pod に割り当て可能な空きリソースがどの Node を見てもない場合に、Node を追加する。」・「Node 追加後にクラスターのリソース利用率が下がったら Node を減らす。」を持っております。判断基準は「Pending の Pod」があるかです。詳しくは下記をご覧下さい。
柔軟な拡張性を活かすことで突発的なアクセス増に対応することが可能（ただし、スケールアウトには仮想マシン作成と Kubernetes のセットアップが必要なため、予めアクセス増が分かっている場合は自動ではなく手動で増やした方がよい。）になります。また、その7 で挙げた Pod の水平自動スケールである Horizontal Pod Scaler も自動スケールの重要なキーワードです。リンクは当記事中部にも掲載しておりますが下記に再掲します。記事の下部です。
なお、Node の水平自動スケールと Pod の水平自動スケールは共存可能です。
今回はここで終了です。
Kubernetes（AKS）をやさしく学ぶ旅 その9
デプロイ方法を知ったあとは ConfigMap
アプリケーションの Deployment を知ったあとは、デプロイの世界からは少し離れたものを学ぶようにします。
アプリケーション内で利用する設定情報や外部へのAPIキーは環境に依存するため、アプリケーションのコンテナイメージで管理せず別方法で管理することが望ましくなります。これを実現するための解として Kubernetes では「ConfigMap」という仕組みが準備されています。
ちなみに、ConfigMap を作成する方法としては3つの方法が存在します。
1 ➡ Kubernetes のマニフェストファイルを作成
2 ➡ アプリケーションの config ファイルをマウント
3 ➡ kubectl コマンドから作成
1の作成方法に関しては前述の blog 記事でも記載されております。2の作成方法に関しては「kubectl create configmap」を利用する方法です。
また、ConfigMap の値の参照方法としては
・環境変数渡し
・Volume としてマウント
があります。前者の場合はマニフェストファイルの [containers] - [env] フィールドを利用（[valueFrom] - [configMapKeyRef]）します。後者の場合もマニフェストファイルには記載しますが [containers] - [volumeMounts] （[volumes] - [configMap]）フィールドの設定で ConfigMap をコンテナーのどこにマウントするか具体的に指定します。
つづいて Secret !!
一般的なアプリケーションは他システムの呼び出しで使用するAPIキー、データベースへの接続のための ID / パスワード等、機密データを扱います。その管理の際には Secrets リソースを使います。ConfigMap との違いとしては ConfigMap が何も暗号化されていないのに対して Secrets は etcd の中で暗号化された状態で管理される、といった違いがあります。
ちなみに、作成する方法としては2つの方法が存在します
1 ➡ Kubernetes のマニフェストファイルを作成
2 ➡ 機密情報のファイルをマウント
また、ConfigMap の際と同様に値の参照方法としては
・環境変数渡し
・Volume としてマウント
があります。同じですね。前者の場合はこれまた ConfigMap と同様ですがマニフェストファイルの [containers] - [env] フィールドを利用（Secrets の場合は [valueFrom] - [secretKeyRef]）します。後者の場合もこれまたマニフェストファイルに記載しますが [containers] - [volumeMounts] （[volumes] - [secret]）フィールドの設定で Secret をコンテナーのどこにマウントするか具体的に指定します。
今回はハンズオンなしとなりますが、環境依存する部分に関しては ConfigMap や Secrets で設定を保持する、と覚えておきます！短いですがこんなところで。
Kubernetes（AKS）をやさしく学ぶ旅 その8
アプリケーションのデプロイの観点から
Kubernetes には流行りの CI / CD を実現する上で重要なデプロイの機能を備えています。今までにキーワードとしては出ていないですがデプロイを管理する「Deployment」が便利です。
アプリケーションのバージョンアップの考え方として、「より安全（テスト済）に、より迅速に。」が重要です。そんな中でデプロイする手法として代表的なものは以下のようなものです。
ローリングアップデート
アプリケーションのバージョンアップの際にまとめて一気に変更せず、稼働状態を保ちながら少しずつ順繰り更新する方法です。ちなみに、更新中は新旧のアプリケーションが混在するため、ローリングアップデートに対応した仕組みになっている必要があります。
ブルー／グリーンデプロイメント
バージョンが異なる新旧2つのアプリケーションを同時に動作させておき、ネットワークの設定を変更して対応する方法です。ブルー（旧）とグリーン（新）を切り替えることからそう呼ばれます。
ブルーを本番としてグリーン側で機能追加したものでテストし確認できた上で切り替えます。万が一、アプリケーションに障害があってもブルーに切り戻せることがメリットです。
その他キーワードとして一部利用者のみに新機能を開放して問題ないことを確認した上で残りを大規模展開することを「カナリアリリース」といいます。
Deployment とは？
その5 でスケジューリングの話をチラッとしましたが、Pod をどの Node に配置するかはこのスケジューリングで実現します。クラスター上の Pod はラベルによって管理されており、バージョンアップの際にそのアクセスする Pod を変える、という制御を管理するのが Deployment になります。
ちなみに、Pod や ReplicaSet は履歴の概念がないのでリリース後に変更のないアプリケーションを管理するのに適しています。Deployment の場合は履歴の概念があります。すなわち、、
➡ Pod のロールアウトやロールバックができる
➡ ロールアウトの方式を指定したり条件や速度を決められる
アプリケーションの世界では一般的に「作成したらそれで終わり！」というものが基本は少ないため、Deployment の積極利用が勧められます。
ここからハンズオン
Deployment 用のマニフェストファイルを準備し進める形となります。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#deployment-v1-apps
xxx > kubectl apply -f Deployment/nginx-deployment.yaml deployment.apps/nginx-deployment created xxx > kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 21s
Deployment の作成と共に自動的に ReplicaSet と Pod もできあがるようです。
xxx > kubectl get replicaset,pod NAME DESIRED CURRENT READY AGE replicaset.extensions/nginx-deployment-789d949f8b 3 3 3 3m21s NAME READY STATUS RESTARTS AGE pod/nginx-deployment-789d949f8b-cq9mv 1/1 Running 0 3m21s pod/nginx-deployment-789d949f8b-hq4pg 1/1 Running 0 3m21s pod/nginx-deployment-789d949f8b-xbpf7 1/1 Running 0 3m21s
Deployment 名を元に ReplicaSet と Pod の名称がつけられていることが分かります。
xxx > kubectl describe deploy nginx-deployment （略） OldReplicaSets:NewReplicaSet: nginx-deployment-789d949f8b (3/3 replicas created) （略）
この詳細を確認するコマンド実行結果を見ると上記2つで履歴をとっていることが分かります。次に一度 apply したファイルの中身 [spec] - [template] - [spec] - [containers] - [image] の行を変更します。
xxx > kubectl apply -f Deployment/nginx-deployment.yaml deployment.apps/nginx-deployment configured xxx > kubectl describe deploy nginx-deployment （略） OldReplicaSets: nginx-deployment-789d949f8b (1/1 replicas created) NewReplicaSet: nginx-deployment-69fdb6677 (3/3 replicas created) （略）
再度 apply した上で確認すると、変化の途中を捉えたものですが、「789～～」が「69f～～」になっています。
xxx > kubectl get replicaset --output=wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-deployment-69fdb6677 3 3 3 7m26s nginx nginx:1.15 app=nginx-pod,pod-template-hash=69fdb6677 nginx-deployment-789d949f8b 0 0 0 21m nginx nginx:1.14 app=nginx-pod,pod-template-hash=789d949f8b
Deployment の場合は内部で ReplicaSet の履歴を持っており、Label 確認コマンドを実行すると「pod-template-hash」というのを持っていることが分かります。ここでお馴染みの delete を発行します。
xxx > kubectl delete -f Deployment/nginx-deployment.yaml deployment.apps "nginx-deployment" deleted xxx > kubectl get pod,replicaset,deploy No resources found.
Deployment の削除と共に紐付いている ReplicaSet や Pod も削除されることが上記で分かります。
Deployment のしくみ
Kubernetes では大分類として2つのアップデート方式があります。
1つ目は「Recreate」方式で旧 Pod を全停止した上で新 Pod をその名の通り再作成する方法です。何となく勘の良い方はおわかりだと思うのですが、これではダウンタイムが発生します。すなわち、ダウンタイムが許される開発環境などで使用します。
2つ目は前述もしている「RollingUpdate」です。こちらは「Recreate」と違い順繰りに変更していくため、新旧が混在するもののダウンタイムはありません。当方法はマニフェストファイル上では [strategy] - [type] で設定できます。明示的に指定しない場合は「RollingUpdate」になるようです。
再度ハンズオンに入る前に「ロールアウト」という言葉を覚えておきます。この用語はアプリケーションをクラスター内にデプロイしサービスを動作させることを指します。
xxx > kubectl apply -f Deployment/rollout-depoyment.yaml deployment.apps/rollout-deployment created service/rollout created xxx > kubectl rollout status deploy rollout-deployment deployment "rollout-deployment" successfully rolled out xxx > kubectl get pod NAME READY STATUS RESTARTS AGE rollout-deployment-fc7c7cbdc-78d29 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-7wwhj 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-8k5sh 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-cwzc9 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-k8mkw 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-knjdj 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-v2hx4 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-w5n4f 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-xbdfn 1/1 Running 0 66s rollout-deployment-fc7c7cbdc-zjwd6 1/1 Running 0 66s xxx > kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.0.0.1443/TCP 3d1h rollout LoadBalancer 10.0.160.142 40.115.182.229 80:32053/TCP 101s
Deployment だけでなく Service のリソースも作成されています。また、「kubectl rollout ～～」でDeployment の結果を確認できます。Pod は 10個 できており、外部からのアクセスIPは「40.115.182.229」といった状態です。アクセスしてみると？
アクセスできました。
xxx > kubectl describe deploy rollout-deployment Name: rollout-deployment （略） Annotations: deployment.kubernetes.io/revision=1 （略） Selector: app=photo-view Replicas: 10 desired | 10 updated | 10 total | 10 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge ～～～～～ Pod Template: Labels: app=photo-view Containers: photoview-container: Image: sampleacrregistry999.azurecr.io/photo-view:v1.0 Port: 80/TCP （略） Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets:NewReplicaSet: rollout-deployment-fc7c7cbdc (10/10 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set rollout-deployment-fc7c7cbdc to 10
Deployment の概要が表示され「Annotations」行には「revision=1」があります。履歴管理のためのものでローリングアップに際して増分します。「Selector」行以降でローリングアップデート状況を確認できます。「Pod Template」行以降で Pod の仕様等を確認できます。
続いて その4 で ACR に登録した v2.0 を利用して挙動確認します。準備としてマニフェストファイルの一部を v1.0 から v2.0 に変更します。
xxx > kubectl apply -f Deployment/rollout-depoyment.yaml deployment.apps/rollout-deployment configured service/rollout unchanged xxx > kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE rollout-deployment 10/10 10 10 28m xxx > kubectl describe deploy rollout-deployment Name: rollout-deployment （略） Annotations: deployment.kubernetes.io/revision=2 （略） Pod Template: Labels: app=photo-view Containers: photoview-container: Image: sampleacrregistry999.azurecr.io/photo-view:v2.0 （略） OldReplicaSets:NewReplicaSet: rollout-deployment-7bfc98cff8 (10/10 replicas created)
（略）
見比べてみると、「Annotations」行には「revision=2」となり「Image」行は「v2.0」となっております。また、Old と New の ReplicaSet も勿論変更されております。内部的な動作としては新しい ReplicaSet を作成してそちらの Pod を増やす、古い方の Pod を減らす、そして0になるまで続けるといった塩梅です。外見としては把握しにくいですが整合を取りつつ内部ではロールアウトしています。
では、次にロールバックを見てみます。マニフェストを当初の v1.0 に戻します。
xxx > kubectl apply -f Deployment/rollout-depoyment.yaml deployment.apps/rollout-deployment configured service/rollout unchanged xxx > kubectl describe deploy rollout-deployment Name: rollout-deployment （略） Annotations: deployment.kubernetes.io/revision=3 （略） Pod Template: Labels: app=photo-view Containers: photoview-container: Image: sampleacrregistry999.azurecr.io/photo-view:v1.0 （略） OldReplicaSets:NewReplicaSet: rollout-deployment-fc7c7cbdc (10/10 replicas created) （略）
「Annotations」行には「revision=3」となり「Image」行は「v1.0」となっております。その上で Old と New 行なのですが、「revision=1」の際の英数文字の羅列に戻っております。revision こそ進んでいるものの内部の履歴を参照しロールバックをしていることが分かります。
また、ロールアウトは条件として Pod のテンプレートを変更したときのみ行われます。一通りの動きが分かったので削除します。（コマンドは割愛します）
ローリングアップデートの制御に関して
describe のコマンド結果にも表示されていましたが、使用できない Pod の制御として「maxUnavailable」の指定、クラスターで Pod を作成できる最大数として「maxSurge」を指定できます。共にデフォルト値は 25% です。こちらのマニフェストファイルの変更のハンズオンは割愛します。
実際には前述している「ブルー／グリーンデプロイメント」もハンズオンしようと思ったのですがここまでにたっぷりと触れてしまったので その8 はここで打ち切り（笑）にします。
ざっくりとした内容としてはブルー用（旧）のマニフェストファイル v1.0 とグリーン用（新）のマニフェストファイル v2.0 を準備し共にクラスターへデプロイします。apply 方法はいつもと変わりありません。3つずつ Pod がある想定で計6つ Pod が共存する形になります。
これに加え外部からアクセスする際の Service マニフェストを作成する際に v1.0 へ向けるようにするとブルー用（旧）へ向く形となります。v2.0 での確認を一通り終えたところで Service マニフェストを v2.0 へ向けるようにすれば当デプロイメント完了です！
解散！
