【雑記】『プロフェッショナル 仕事の流儀』IT系まとめ
感化されやすい私にピッタリの番組（笑）
2006年1月から NHK で放送が開始され、既に13年以上続いている『プロフェッショナル 仕事の流儀』、この手の番組に感化されやすい私は気に入った回を見つけると何度も何度も繰り返しで見てしまいます。笑
そんな当番組ですが、ふと思い、IT系の人ってどれだけ出てきたんだろう？と考え、私目線ではありますが、まとめてみました。（漏れあったらスミマセン）
ちなみに、過去の動画は何年前までかは分からないものの、NHKオンデマンドの配信で閲覧することが可能です！
NHKオンデマンド - プロフェッショナル 仕事の流儀 - NHK
では早速
2006年
なし
2007年
石井裕氏（2007/02/08 放送）
コンピュータインターフェースの研究の最前線に立ち、MIT（マサチューセッツ工科大学）メディアラボ教授に就任されている方です。プロフェッショナルのオンデマンドはないですが、下記の記事は今年10月の記事でホットです。
渡辺誠一郎氏（2007/03/01 放送）
あのシリコンバレーにベンチャー企業を構え、最高技術責任者として指揮を取っていた方です。画像技術開発分野がメイン分野です。現在は日本に法人を設立して同社の CEO となっているようです。
南場智子氏（2007/03/08 放送）
インターネットの黎明期に産声をあげた DeNA を率いた方です。一時、CEO を退任しましたが2017年3月に CEO として再度指揮を執ることになりました。「永久ベンチャー」と掲げる程、様々な新規事業を産み出した同社。これも、南場氏の DNA があってこそなんでしょうか。
DeNAが創業からの20年で立ち上げた事業と撤退した事業まとめ : 東京都立 戯言学園
2008年
中村勇吾氏（2008/04/01 放送）
ウェブデザイナー、インターフェースデザイナー、映像ディレクター、多摩美術大学教授など様々な肩書きを持つ方です。クライアントワークをご覧頂くと分かるのですが、有名どころを数多く手がけています。個人的には『デザインあ』の映像監修に興味を持ちました。笑
2009年
なし
2010年
なし
2011年
なし
2012年
及川卓也氏（2012/01/23 放送）
Microsoft で日本語版・韓国語版 Windows の開発統括を務め、Google で各種サービスのプロダクトマネージャーを担当していた方です。日本のエンジニア界隈でも超がつく有名な方です。ちなみに、最近『ソフトウェア・ファースト』という本を出版され、私も絶賛読んでいる最中です。
機会があれば及川さんの講演を拝聴しにいきたいなぁと思います。
2013年
なし
2014年
真鍋大度氏（2014/05/12 放送）
ITの分野になるのかは分からないのですが、プログラミングが取り上げられた会だったので入れさせて頂きました。世界で活躍するメディアアーティストです。当時、この回はプチ衝撃を受け、何度も繰り返しで見ました。「クリエイティブ」・「ものづくり」のキーワードがしっくり来る回です。オススメです。
2015年
名和利男氏（2015/09/14 放送）
今から4年以上前ですが、私自身が当番組で一番感化され100回以上は見た（気がする）お気に入りの回です。セキュリティ分野に関してはそれまでそこまで興味が無かったものの、この回を境に興味を持ち始めるようになりました。とにかく「カッコイイ」です。下記は割と最近の記事で DDoS 攻撃が今ホットで危険、という内容です。
2016年
猪子寿之氏（2016/07/11 放送）
元エンジニアで今はチームラボ株式会社を率いるデジタルクリエイターの同氏。会社名にもあるように「革命は、チームで起こす」というのがモットーだそうです。メディアでも同社の映像技術は取り上げられており、話題が尽きません。
川上量生氏（2016/08/22 放送）
ドワンゴ・ニワンゴ・ニコ動といえばこの川上氏でしょうか。今でこそニコ動の勢いは昔ほどの勢いはないものの一時期の過熱ぶりは凄かったと思います。
2017年
名和利男氏（2017/06/19 再放送）
約2年前の放送のアンコールです。
2018年
なし
2019年
なし
と、2016年8月の川上氏を最後にここ3年くらい、IT系のアツい回がないのが残念なところです。また、回が追加されるようでしたらこちらの記事で取り上げるかもしれません。
それ以外でのお気に入りの回
2014/09/01 ナニワの軍師、再起のテーマパーク マーケター・森岡毅
マーケター、というよりはデータサイエンティストに近い同氏。ユニバーサル・スタジオ・ジャパンを題材に「どうお客様の心をつかむか」という内容で構成されていました。オススメです。
森岡毅（2014年9月1日放送）| これまでの放送 | ＮＨＫ プロフェッショナル 仕事の流儀
追記（Appendix）
2019/11/04
当記事をアップした後に Google からの検索流入が急に上昇しました。どうやら、数時間後？には既に記事が拾われていたようで「プロフェッショナル 仕事の流儀 it」で検索すると1ページ目に出ました！さすが Google さん、仕事が早いですぜ。。
どんなキーワードで引っかかるか分からないものですね・・・・。
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 へ向けるようにすれば当デプロイメント完了です！
解散！
第22回 Tokyo Jazug Nightに参加しました
今宵の Tokyo Jazug Night は？
私は今年の6末頃に Azure のサブスクリプションを取得し、翌月の Jazug Night から参加させて頂いているのですが、毎月の定例行事となってきました。このイベントがある時は何が何でも仕事を切り上げます。笑
ちなみに、今宵は「Azure Bot Service」と「PowerApps」（＋CloudFlare様のショートセッション）でした。
次世代コミュニケーションツール「チャットボット」の活用
〜Azure Bot ServiceでAzureのことに何でも答えてくれるLINEボットを作る〜
サイオステクノロジーの武井様が登壇されました。サイオスさんのブログはインフラネタを調べている際に何かと参考にさせて頂いてたので中の方のお話を拝聴することができて良かったです！
本日の登壇内容も上記ブログにアップされているのですが、サイオステクノロジーさんのブログは基礎的なところを始めとして応用的な技術ネタも数多くアップされており、「これが無料なのか、イイ時代になったなぁ。」と感じます。
と、本題に戻りまして Azure Bot Service ですが、今流行のチャットボットを簡易的なものであればノンコーディングで作成できるとのことで。Teams や Slack にも連携可能とのことなので情シス的な目線としてはヘルプデスク的な要素はこれに投げ込んでしまおうかなと画策中。武井様も情シスにオススメ的なことをおっしゃっていたのでこの辺連携できれば情シス的にもユーザ的にも Win-Win な関係を築けそうです。
気になる価格としては代表的なチャネル（＝Standard）であれば無料？なようで、共に利用する Web App も検証用途であれば F0（Free） で大丈夫なようです。
あとは、Application Insights や Bot の核となる
・Language Understanding Intelligent Service（LUIS）
・QnA Maker API
でどれくらいかかるか、ということで。Bot に関しては Free または試用版で作成することも可能なようです。
本日のデモでは実際に拾えなかった質問内容を Application Insights で表示するという例があり、精度を上げるサイクルを見ることができました。結局はチャットボットも空振ってしまうだけでは意味のないボットになってしまうので精度を上げていくのは重要課題なわけです。（「分かりません」ばっかりやん！というツッコミが Application Insights で拾われていたのは笑いのツボでした。笑）
実際の構築内容はサイオステクノロジーさんのブログに上がっているので気になったキーワードのみ上げます。
・LUIS の API キー Authoring Key / Endpoint Key
➡前者はあくまでも開発用。本番用としては読み取り専用の後者を利用する。
・Composite エンティティ
➡複合エンティティのこと。グルーピングを利用することで複雑な文章も解釈できるようになる？
ひとまずは、一度手を動かしてみるのが早そうなので近々 Azure Bot Service を利用して簡易的なものを私も作成してみようと思います！
武井様は 2019/11 の Windows × WSL の記事を担当されているようで改めての宣伝です。Azure 絡みなので記事を読んでみようと思います。
Azure SQL DatabaseとPowerAppsでお手軽にアプリ開発！
～リレーショナルデータを高速に可視化！～
2本目は FIXER の横山様による登壇でした。PowerApps は最近かなり気になっていたので当セッションを拝聴できてとても勉強になりました。よくよく考えてみると今回は1・2本目共に（ほぼ）ノンコーディングでサービスを作成、ということに着眼した内容でした。
当セッションの内容としては Azure SQL Database と PowerApps を利用して簡易的な AZ 試験対策アプリを作成したという内容です。構想含めて3日少々？で作成されたようで、ハマったところを除けばもっと早くアプリが出来るかも？とのことでした。
気になったことのメモ。
➡2024年までにローコードツールがアプリ開発の65%に。この兆候となると、今後はよりアイデア勝負で勝ち抜いていくのかがカギとなりそうです。
➡Build の Keynote でナデラ氏が話した内容で「注力する4つのプラットフォーム」に Power Platform も含まれている。
➡ PowerApps はパワポのノリで画面作成できる。横山様は説明しつつハンズオンでサクサクと進めていました。確かに「こりゃ楽チンだ！」という印象を受けました。
➡ SubmitForm と Patch は重要キーワード
Twitterの「#jazug」を眺めていた感じでは AZ 試験対策アプリは「欲しい！」という声が多く、個人的にも AZ-900 以外で出来たら普通に欲しいアプリでした。笑
こちら、後日FIXERさんのブログあたりに上がる模様？なので、記事がアップされ次第、改めてお伺いしたいと思います。
と、本日は旬の2本のネタが拝聴できて、とても勉強になりました。
ちなみに、2本のセッションの後には CloudFlare さんのショートセッションがあり巷で噂の「1.1.1.1」の無料 DNS サービスに関する内容でした。
この数字の羅列を見ると Google の Public DNS である「8.8.8.8」が有名ですが、Cloud Flare さんの DNS はより安全により速く使うことができるとのこと。これも時間がある時に試してみようと思います！
Kubernetes（AKS）をやさしく学ぶ旅 その7
少し間が開きましたが・・・・。
その6 では Pod の少し詳細な部分に触れ、ReplicaSet をこれからハンズオンする、というところで完了しました。
今までに構築してきた環境をベースに ReplicaSet のハンズオンを行います。
ハンズオン Start！
まずは、ReplicaSet を「5」で指定（replicas: 5）したマニフェストファイルを準備して ReplicaSet を作成します。
xxx > kubectl create -f ReplicaSet/replicaset.yaml replicaset.apps/photoview-rs created
その後、Pod 情報を確認してみると・・・・。
xxx > kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS photoview-rs-2mhpk 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-ghn9h 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-hpps2 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-m4fnl 1/1 Running 0 8m26s app=photoview,env=prod photoview-rs-sz5vb 1/1 Running 0 8m26s app=photoview,env=prod
この上で詳細情報（describe）を確認してみると・・・・。
xxx > kubectl describe rs photoview-rs （略） Replicas: 5 current / 5 desired （略）
正常に5つの ReplicaSet が作成されているようです！ちなみに、マニフェストファイルの「replicas: n」を変更すればそれに応じた ReplicaSet になります。ここで一度、ReplicaSet は削除してしまいますので、Pod もまとめて削除されます。
xxx > kubectl delete -f ReplicaSet/replicaset.yaml replicaset.apps "photoview-rs" deleted xxx > kubectl get pod NAME READY STATUS RESTARTS AGE photoview-rs-2mhpk 0/1 Terminating 0 15m photoview-rs-m4fnl 0/1 Terminating 0 15m xxx > kubectl get pod No resources found. ＊一度目の確認時にはまだ残っていたようです
クラスター内の制御はどう行っているの？
ReplicaSet のハンズオンを行ってみましたが、実際クラスター内で Pod を指定した数だけ起動するのはどのように行っているのでしょうか？これを制御しているのが「コントローラー」です。クラスターにおいて Pod が設定した数値になっているかを確認しそうでない場合は自動で修復を試みます。ちなみに、ReplicaSet は指定された数の Pod を起動するリソースではなく指定された数の Pod を起動した状態を維持するリソースです。（ここも本来はハンズオンがあるのですが割愛）
Pod に障害があった場合はどのような挙動になるの？
実際に ReplicaSet で Pod に障害が発生した場合はどうなるのでしょうか？挙動を確認してみます。
xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 2m25s 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-8vchz 1/1 Running 0 77s 10.244.1.6 aks-nodepool1-11226562-2 nginx-replicaset-jzthk 1/1 Running 0 77s 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Running 0 77s 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 77s 10.244.2.5 aks-nodepool1-11226562-1
ここで、意図的にPod「
xxx > kubectl delete pod nginx-replicaset-8vchz pod "nginx-replicaset-8vchz" deleted xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 4m59s 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-9k9q9 1/1 Running 0 17s 10.244.1.7 aks-nodepool1-11226562-2 nginx-replicaset-jzthk 1/1 Running 0 3m51s 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Running 0 3m51s 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 3m51s 10.244.2.5 aks-nodepool1-11226562-1
すると、「nginx-replicaset-8vchz」は消え「nginx-replicaset-9k9q9」が作成されます。ちなみに、IPアドレスも変わっております。終了した Pod に関しては再起動ではなく別途作成されることに注意しましょう。また、Kubernetes ではコンテナーアプリケーションを運用する際にステートフルなアプリケーションの場合、Pod の状態を保証できないため、その際は StatefulSet を利用する必要があります。（ステートフル＝クライアントのセッションを保持するもの）
Node に障害があった場合はどうなるのか？
Pod ではなく Node の障害の場合はどうなるのでしょうか？クラスターを構成するマシンが落ちた想定で進めてみます。
xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 Ready agent 62m v1.15.4 aks-nodepool1-11226562-1 Ready agent 60m v1.15.4 aks-nodepool1-11226562-2 Ready agent 61m v1.15.4 xxx > az vm stop --name aks-nodepool1-11226562-0 -g MC_AKSCluster_AKSCluster_japaneast About to power off the specified VM... It will continue to be billed. To deallocate a VM, run: az vm deallocate. xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 NotReady agent 64m v1.15.4 aks-nodepool1-11226562-1 Ready agent 62m v1.15.4 aks-nodepool1-11226562-2 Ready agent 64m v1.15.4 xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES （略） nginx-replicaset-lgmjf 1/1 Terminating 0 19m 10.244.0.8 aks-nodepool1-11226562-0（略）
タイムラグがありますが、「STATUS」列は「Terminating」になります。試しに「-0」だけでなく「-2」も落としてみました。
xxx > az vm stop --name aks-nodepool1-11226562-2 -g MC_AKSCluster_AKSCluster_japaneast About to power off the specified VM... It will continue to be billed. To deallocate a VM, run: az vm deallocate. xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 NotReady agent 68m v1.15.4 aks-nodepool1-11226562-1 Ready agent 66m v1.15.4 aks-nodepool1-11226562-2 NotReady agent 68m v1.15.4 xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 26m 10.244.2.4 aks-nodepool1-11226562-1nginx-replicaset-5vffm 1/1 Running 0 18s 10.244.2.12 aks-nodepool1-11226562-1 nginx-replicaset-9k9q9 1/1 Terminating 0 21m 10.244.1.7 aks-nodepool1-11226562-2 nginx-replicaset-fv8np 1/1 Running 0 5m43s 10.244.2.8 aks-nodepool1-11226562-1 nginx-replicaset-jzthk 1/1 Terminating 0 25m 10.244.1.5 aks-nodepool1-11226562-2 nginx-replicaset-lgmjf 1/1 Terminating 0 25m 10.244.0.8 aks-nodepool1-11226562-0 nginx-replicaset-mzfrw 1/1 Running 0 25m 10.244.2.5 aks-nodepool1-11226562-1 nginx-replicaset-s57gt 1/1 Running 0 18s 10.244.2.14 aks-nodepool1-11226562-1 ＊途中、「-0」をカバーして「STATUS」列が「ContainerCreating」のものも表示されました。
結果として、全てが「-1」に寄る形になっております。（負荷かかりそうですね。。）
ちなみに、「-0」と「-2」を Start として戻しても Pod が立ち上げた2台に配置されるわけではありませんでした。
ひとまず、ここで Pod は削除します。
負荷に応じて Pod の数を変える（ハンズオンなし）
Kubernetes はスケーラビリティが高いというところがメリットですが、2種類のスケーラビリティのキーワードを学びます。
・スケールアウト（水平スケール）
➡簡易的な説明として「台数を増やすこと」
・スケールアップ（垂直スケール）
➡簡易的な説明として「リソースを増強すること」
Pod で考える水平スケールとしては前述でマニフェストファイルを書き換えましたが、コマンドの発行でも可能です。「kubectl scale --replicas=n ～～」でOKです。
ちなみに、Kubernetes は、CPU使用率やそれ以外の各種メトリックを使用して、Pod の数をスケールすることが可能です。機能としては Horizontal Pod Autoscaler です。
ちなみに、当機能は ReplicaSet だけでなくその他の Deployment や StatefulSet 等にも利用が可能です。マニフェストに記述して実現します。
とまぁ、ハンズオン含め長くなってしまいましたが、前回の その6 と今回の その7 にてPod の詳細と ReplicaSet の動き等は完了とします！
MOTEX DAYS 2019 ユーザー事例発表会に登壇させて頂きました
かれこれ 3～4 ヶ月前のこと
MOTEX社様と打ち合わせをする機会がありまして、打ち合わせの中で登壇のご依頼を頂きました。弊社を担当して下さった営業さんは実は前職でも担当して下さってた経緯もあり、そんなこんなの縁での依頼でした。縁って大事ですね。
去年頃に同じ依頼を受けていたら実はお断りしていたかもしれません・・・・が、今年はこのブログでのアウトプットを始めとして、「色々なことに挑戦したい！」と決めた年だったので依頼を受けました。
資料作成～当日登壇前
資料作成自体はMOTEX社様が流れのテンプレートを作成して下さってたので叩き版自体、割と早いタイミングで完成しておりました。社内で数度レビューした後に実際に修正の上、模擬プレゼンも数度行いました。ちなみに、持ち時間は20分だったのですが、一度目の練習は25～30分近くかかってしまってました。笑
当日も付き添ってくれた上司の方と数度模擬練習を行った上で最終的には20分ちょっとまで縮んだのであとは本番で微調整しながら、という感じで臨みました。
当日の行きは品川まで新幹線だったのですが、乗った車両でまさかのライバル会社の宣伝が！しかし、今日の藤原君は応援するかのような視線を送ってくれているようにも見えました。（100.1%違う）
ココが事例発表会が開催された品川インターシティホール。ドキドキ。しているうちにリハーサルが始まり、基調講演が始まりと自分自身の出番が近づいてきました。。
登壇（本番）
予定通り、持ち時間20分を頂いてスタート。ほぼほぼ予定通りの流れで本筋の話とおまけ的な話も出来ました。聴講してくださった方はMOTEX社様の社員の方々も合わせて50人程でした。冒頭でもお話したのですが他のセッションが割と注目のキーワードだった中、当セッションにお越し頂き、誠に有難う御座いました！
初登壇でよかったこと・悪かったこと
よかったこと
・発表時間が予定通りの20分程で完了できたこと（ほぼニアだったかと）
・原稿らしい原稿は用意せず、練習通り、自然体で話せたこと。
・初志貫徹で決めたこと（極力技術寄りにならず平易に話すこと）を実践できた
悪かったこと
・作成したパワポが自社テンプレートでフォント埋め込みだったことを忘れていたこと。結果、大きなズレはなかったものの失態です。。
・プラスして一部のスライドのオブジェクトが大幅にズレていたこと。結果、登壇前に修正できたので良かったですが、振り返ればPC持ち込みにすれば解決した気がします。
・途中咳払いしてしまった、後半少し声が枯れてしまった。
➡ちゃんと水分を取っておくべきでした・・・・。
とまぁ、あっという間に発表は終わり、その後のセッションを拝聴しMOTEX社様と懇親を深めつつ、帰路につくのでした。ちなみに、以前のブログ記事で記載した3つのポイント（セキュリティの重要性を伝える・同業者の方と繋がる・コミュ障を克服する）は大方達成できたのかなと思うので満足です！
御礼
まずは今回の会がMOTEX社様の力なくしては開催されなかったこと、このようなイベントで登壇させて頂きまして、誠に有難う御座います。また、会が行われる中でお会いしたことのある社員の方々とコミュニケーションを取ることができて非常に嬉しかったです。
続きまして、前述もさせて頂いておりますがセッションに足を運んでくださいました皆様。拙い点が多々ありお聞き苦しかったとは思いますが、最後までご静聴頂きまして有難う御座いました！
最後におまけのような感じではありますが、午後帯一杯、終始おつきあい頂いた弊社の上司の方にも心から感謝しております。
Next LanScope？
事例発表の場には立たせて頂いたのですが、弊社もまだまだ LanScope Cat を活用してやりたいことが多々あります。スライドにも盛り込んでいたライセンス管理・セキュリティパッチ適用の平準化・MDM・Cylance Protect などなど。
LanScope An を利用していることもあり、MDM強化のため、「Syncpit」は導入したいなと考えております。ビジネスチャットの普及も後押ししていると思います。
また、マルウェア対策を強固にするため、CylancePROTECT の導入も考えたいです。特別講演で拝聴しましたが、他社の有名な製品と比べても見劣りしない、むしろ、（ほぼ）完全無欠の状態に引き上げることができます。
製品自体への「愛」を含めて社内のセキュリティレベルを上昇させたいです！！！！！
Kubernetes（AKS）をやさしく学ぶ旅 その6
まだまだつかめない Kubernetes の世界。。
その1～その5まで紹介してきている Kubernetes ですが、まだまだ、色々と理解しきれていないところがあります。そこで、今回は Pod についてもう少し掘り下げてみようと思います！
Pod とは
以前の記事で Pod の大まかな部分は記述していますが、設計思想を含め、Pod はどう扱っていくのが最適なのかの細かな話はできていません。
コンテナーの世界では「1コンテナーで1プロセス」という鉄則があるようで、シンプルな機能をもつアプリケーションにすることが理想とされています。ただし、Web - Proxy、SSL、OAuth等、メインコンテナーに付随する1つのまとまりになったコンテナーを作るのが便利なようです。Kubernetes では関連するコンテナーの集合体を Pod と呼びます。また、Podの特性を下記に記載します。
・アプリケーションのスケールアウトは Pod 単位
・Pod 内のコンテナーはネットワークとストレージを共有
Pod のデザインパターン
Pod をどのように設計していくかは作成するアプリケーションの機能・非機能要件によります。
・同一 Node で実行する必要があるか？
・同じタイミングでスケールする必要があるか？
プロキシの役割をするコンテナー
元は HTTP にしか対応していない Web アプリケーションを HTTPS に対応させる場合です。
上記のケースの場合、SSL Proxy Container から本来の HTTP Web Application に対しては http://localhost/ でアクセスできるので既存の Web Application のコードに対して変更は不要になります。
認証処理を行うコンテナー
Web Application が OAuth 認証を必要とする場合は Web Application 本体とは分離して認証処理の Pod を配置する必要があります。
上記2例は以上にして、注意点があります。それは Kubernetes のデプロイの最小単位は Pod だということです。アプリケーションを今後拡張していく上で将来的にどうスケールしたいかがデザインパターンを決定する上で重要になります。Web Application において前段のフロントとバックのビジネスロジックは必ずしもスケールのタイミングが一緒ではない（可能性が高い）ため、Pod は別管理にした方が望ましくなります。
Pod のその他もろもろ
Node のスケジューリングも学ぼうと思ったのですが、ボリュームも非常に多いため、こちらでは割愛致します。ちなみに、ざっくりとした概略等は前回の その5 で記載しております。
ReplicaSet について学ぼう（ハンズオン前まで）
クラスターに複数の Pod をデプロイする、ということで Kubernetes のコンセプトである自己修復機能を実現するための ReplicaSet について学びます。
ReplicaSet はクラスター内で動作させる Pod の数を設定した数字で維持する仕組みです。Node 障害で Pod が停止した際には ReplicaSet を使用し自動的に新しい Pod を立ち上げます。
ハンズオンは その7 にして、少々短いですが今回はここまでとします！
