Cloud Penguins

Flying penguins in the cloud.

TKGのダウンロードやドキュメントにさっくりたどり着く方法

今日は小ネタ。

今すぐTKGのCLIバイナリやドキュメントにアクセスしたい!ってこと、よくありますよね?(あるのか?)

これらはMy VMware からアクセスできるんですが、検索使ったとしても探すのがちょこっと面倒くさい。

GoogleでTKGで検索しても、たまごかけごはんばっかり引っかかってTanzu Kubernetes Gridにはなかなかたどり着けない。

ということで、TKGには https://www.vmware.com/go/get-tkg というショートカットが用意されていて、直接ダウンロードページに飛べるようになっています。

ぶっちゃけそれすら面倒なので、もっと簡単に飛ぶには、ブラウザの検索窓で "get-tkg"と入れればOK f:id:jaco-m:20210119113108p:plain

これで一番上にダウンロードページが出てきます。

f:id:jaco-m:20210119113203p:plain

右のDocumentationからドキュメントに飛ぶことも可能。

2020年買って良かったもの

n番煎じと言われても気にしない。jacopen的今年買って良かったモノを1年の振り返りがてら書いてみる。

ガジェット

SONY VLOGCAM ZV-1

ソニー Vlog用カメラ VLOGCAM ZV-1

ソニー Vlog用カメラ VLOGCAM ZV-1

  • 発売日: 2020/06/19
  • メディア: Camera

ソニーのVLOG向けカメラ。商品レビュー撮影モードの鬼のようなオートフォーカスの速さがヤバい。手ぶれ補正はないので出先で使うとそれなりにブレるが、これはCatalyst Browseでソフトウェア的に補正が可能。

普段はリモートワーク時のWebカメラとしての出番が多いが、出かける時はついでに持ち運んでいる。

eMeet luna

これまたリモートワークの友である会議用マイクスピーカー。1万円を切る価格なのに音質はとても良く、有線、無線いずれの使い方もできて便利。それまではコンデンサマイクを利用していたが、リモートワークにはオーバースペックなのと場所の問題もあったが、eMeet Luna導入で快適さが断然増した。

ATEM Mini

言わずと知れた超コスパスイッチャー。コロナ禍では品不足で全然買えなかったようだが、最近は在庫が安定してきた様子。自分はコロナ禍より前に買っていたので良かった。

USB接続できないカメラをWebカメラ化するのに利用したり、いくつかお手伝いしている配信のスイッチングなどにも利用している。

ハイセンスの65型テレビ

引っ越しを機に購入。国内メーカーとの比較で迷ったが、価格と品質のバランスでハイセンスを選択。65インチはちょっと大きすぎるかな?とも思ったが、実際に使ってみるとむしろちょうど良い大きさだった。F1ファンとしては、情報量がめっちゃ多いF1 ZONEも見やすく大満足。

ゲーミングPC

www.dospara.co.jp

オンライン配信をする際、それまで使っていたMacbook Proでは全然性能が足りず、かつMac版OBSの質も良くなかったためWindows移行を決意。ちょうどWSL2が出たタイミングで、普段の作業にも困らなくなってきたのも後押しになった。 どうせ買うなら十分なスペックのモノをということで、ドスパラのゲーミングPCを購入。Ryzen 3900Xに64GBメモリ。スペックの余裕は心の余裕。OBSはもちろんPremiereやAfter Effectsも快適に使えるので満足。

DELL XPS15

www.dell.com

自宅環境はゲーミングPCでいけるが、出先で配信の裏方をやる際にMacbook Proでは以下略のため、パワーのあるノートPCが必要になってきた。配信の為にはGPUパワーが重要ということで、GTX 1650 Tiを積んだXPS15を選択。ベゼルが細くてかっこいい。おかげで15インチだけどフットプリントはとても小さい。

出先での利用のほか、リビングでテレビを流しながら作業をする用途にも利用している。

トレーニング

コロナ禍で在宅勤務になったこともあり、こりゃ運動しないと体型ヤバいことになるなと思いオンラインのパーソナルトレーナーをつけてみた。結果、コロナ前よりも健康になってきた感ある。 以下はトレーニングのために購入してよかったもの。

可変式ダンベル

最初は自重トレーニングをやっていたが物足りなくなってきたため、可変式のダンベルを購入。細かく主さを調整できるパワーブロックタイプを購入。それまでは10kgのダンベルですら重たいと思っていたのだが、トレーナーから「20kg x2くらいはすぐに物足りなくなりますよ」と言われ、嘘やろと。でもまぁ、可変式であれば重たい側を使わなければいいだけだし、とりあえず買ってみようとこちらを選択。

それから半年経った今、20kgでは全然足りず最大重量の26kgでスクワットしてる。筋肉ってすごい

パワーグリップ

正直筋トレってあまり好きではなかった。みんな重たいダンベルやバーベルをすいすい挙げているのに、自分はその1/3すら持てない。腕や足の筋肉というよりも、握力が足りず手のひらが痛くなってしまい嫌になるパターンが多かった。 ・・・ということをトレーナーに話してみたところ、ウェイトトレーニングやるならパワーグリップは必須ですよと。え、なんそれ初めて聞くアイテム。 ということで、こちらを購入。

筋トレ上級者にはゴールドジムのパワーグリップが定番らしいのだが、レビューを見る限りその1/3の値段で遜色ない品質ということでこちらに。

効果はてきめんで、あ、筋トレってこんなに楽しくやれるものなんだと衝撃を受けるほどだった。握力を使うこと無く鍛えたいところに負荷をかけられるので、その分成長も早いように感じる。

チンニングバー

ダンベルでも良い感じに鍛えられていたのだけど、もっと別のパターンで腕や背中を鍛えたいなということでこちらの懸垂バーを購入。突っ張り棒のように設置するタイプで、自室の入り口に設置している。値段も安く中国産ということで、もし落ちたら大怪我だよな・・・と不安だったが、設置してみるとガッチリ固定されてビクともしない。今のところ不安になる挙動はなく、目論見通りのトレーニングが出来ているので満足。

その他

ミーレ食洗機

www.miele.co.jp

引っ越し先にはホシザキのビルトイン食洗機がついていた。これは洗いが10分程度で終わるユニークな製品だったが、如何せん洗浄力が弱かった。3倍の時間をかけていいからちゃんと汚れを落として欲しかったのだが・・・。

汚れの落ちない食洗機にフラストレーションが溜まってきたため、奮発してミーレの食洗機を購入。こちらは洗いに時間はかかるものの、洗浄力は十分にも関わらず静かで省エネ。洗剤の量も半分で済むようになった。QoL爆上がり。

眼鏡(乱視矯正入り)

今年初め、嫁の父親の付き添いで偶然訪れた眼鏡屋で視力検査してもらったところ、軽度の乱視があることが判明。1年ほど前から目の疲れに悩まされていたのだけど、これが原因だったようだ。

ということで乱視矯正入りの度無し眼鏡を購入。

体感できるほどの効果が出ており、PCを使うときには必ず眼鏡を使うようになった。頭痛も肩こりも軽減したように感じており、ほんと買って良かったなと思う。

React入門したい

今日は雑記。

CloudNative Days Tokyo 2020では、配信プラットフォームを自作したんだけどこれにはRailsを使っている。Railsを選択した理由は、開発を担当した自分と r_takaishiが過去に経験があり一番素早く作ることができたからだ。

正直Railsでほとんど困っておらず、圧倒的な速さで作ることができたので全然これでいいのだが、せっかくフロントエンドに手を出すのであれば新しいものを経験したい気持ちもあるっちゃある。

ということで、Reactデビューしてみることにする。ちなみにこのあたりの知識はゼロでガチの初心者。

手始めに参考にしているサイト

チュートリアル:React の導入 – React

正真正銘のReactだけの不純物なしでReact入門

初めてのReact「入門編」導入から基本まで〜TODOアプリを作ってを学ぼう! | 株式会社ウェブ企画パートナーズ

まだ全然わかっていないのでこれから調べていくこと

  • JavaScriptで書いていくべきなの、それともTypeScriptを使ったほうがいいの
  • SSRとやらをするの?しなくていいの?NextJSとかExpressとか出てくるけどこいつらをどう使うの?
  • フレームワークを使ったほうがいいの?Gatsby.jsってやつ?
  • reduxってなんぞ
  • routerってなんぞ

キューブ型ベアボーンに積めるだけ積んで自宅サーバーを作る2020

クラウドの時代になっても、いや、クラウドの時代だからこそ、自宅に自由に触れる環境を作ってあれこれ実験したいもの。

これまで自宅にタワー型のサーバーやラックマウントサーバーなどさまざまなものを置いてみたものの、やはりネックになってしまうのはスペース騒音

タワー型は縦に並べていくのにやや難があり、都内ワンルームなどに住んでいた場合は人間様が使うスペースよりもサーバーのほうが場所食ってんじゃん、なんて状況になりかねない。

自宅に19インチラックを置くガチな人も世の中には一定数存在するのだが、こちらはスペースもさながら騒音が厳しい。少なくとも寝るスペースと同一にするのは難しいため、検証のときだけ起動するといった運用になってしまう。

福音だったIntel NUC

そんな中、2012年末に登場したIntel NUCは自宅サーバー勢には福音であった。

amzn.to

手のひらに乗るサイズなのにも関わらず、Core i3やi5が載っている。その当時でもSODIMMを2枚刺しすれば16GBにでき、自宅環境の劇的な小型化が可能になった。

2020年現在、32GBのSODIMMも値段がこなれてきており、新しいNUCであれば2枚刺しすることで64GBまで拡張できるようになった。多くの検証はこれ1台もしくは数台で十分賄えるでのはなかろうか。

amzn.to

NICが2つ必要ならば小型ベアボーンという選択肢

多くの検証はNUCで行けると書いたが、場合によってはNICが2つ欲しいというユースケースもある。例えばネットワークのセグメントを分けたいケースや、NASへのアクセスにNICを独占させたいケースもあるだろう。NUCはゲーミングモデル以外はNICが1つしかないため、どうしても必要な場合は、USBのNICを利用することになる。 しかしESXiを使いたい場合、利用できるUSB NICの選択肢はAX88179など少数に限られるのが悩ましい。

そこで出てくる選択肢が、小型のベアボーンや産業向けPCである。

例えばShuttleのDH310V2は、TDP65Wまでの第8世代/第9世代Coreが載る上にIntelチップのNICが2つ積まれている。また、公式サイトのカタログスペック的には32GBまでとなっているが、実際には64GBまで認識する。

amzn.to

さすがにNUCほど小さくはないが、それでも十分小型といえるサイズであり、我が家でも故障したNUCの後継として導入している。 f:id:jaco-m:20201221020840j:plain

さらに拡張性が必要な場合はどうする?

では小型ベアボーンでは足りない要件が出てきた場合はどうするべきか。例えば以下のような要件が考えられるだろう。

  • もっとメモリを積みたい
  • 3.5インチHDDを積みたい
  • GPUを積みたい
  • 10GbEを積みたい

じゃあ大人しくタワー型買おうよ って言いたくなるところをグッと抑えて選択肢を模索してみよう。

Mini-ITXマザーボード x 小型PCケース

Mini-ITXをアリにすると、選択肢はグッと広がる。PCI-E x16を1本積んだマザーが多く、GPUなり10GbEなり要件に合う拡張をするとよい。ただし、メモリスロットは2本であることが多いため最大メモリは64GBが上限となってしまう点は要注意だ。

お金に糸目をつけなければサーバー向けのXeonマザーを買う手もある。10GbEやメモリスロット4本積んだものもあるため、小型で超ハイスペックなマシンを組むことも可能だ。 そこまでして小ささにこだわるか?という気持ちになってくるが

amzn.to

ケースは要件に合わせて選ぶ。見るべきポイントは3.5インチのベイ数、拡張スロット周りのサイズ(GPUが入るかどうか)、電源容量あたり。

amzn.to

キューブ型ベアボーン

前置きが長くなってしまったが、今回自分が試したもう一つの選択肢がキューブ型ベアボーンを使う方法だ。

自宅にvSphere環境とvSAN環境を構築し、その上にたまごかけごはんTanzu Kubernetes Gridを構築したかったので、以下のような要件があった。

  • 128GBメモリ (メモリの余裕は心の余裕)
  • 3.5インチベイ (3.5インチHDDが余ってたので活用したかった)
  • 10GbE (vSAN組むなら欲しい)

今回選んだのは、ShuttleのSH370R6V2というキューブ型ベアボーン。

このShuttleのSH370R6V2、日本の公式サイトだと最大64GBとなっているが、搭載できる第8/9世代CoreとH370チップセットは128GBまで対応している。また、グローバルのサイトにはUp to 128GBという記述もあり、おそらく問題ないと思われた。

メモリスロットは4本あるため、32GBのDDR4を買うことになる。今回は32GBx2のキットを2つ買う形にした。

amzn.to

CPUヘビーなワークロードを動かすつもりはないが、メモリ量に比例してVM数も増えると想定されるため、こちらもCore i7 9700 にして余裕を持たせることにした。

10GbE NICはESXi標準のドライバで認識できるIntelチップを積んだものを選択。安心を取るならIntel純正のもののほうが良いが、今回は節約してノーブランドのものを調達した。 ノーブランドの10GbE LANカードがオリオスペックに5製品入荷、実売5,940円から - AKIBA PC Hotline!

SH370R6V2はPCI-E x16とx4が1本ずつという構成。NICはx8のため、x16側を利用する形になる。なので、GPU積みたい場合は競合してしまうことになる。 x4側に刺しても認識はすると思うが、その分速度低下が起こりうる可能性がある。SH370R6V2はPCI-E Gen3なので、x4でも計算上10GbEは問題ない気はするのだが、自分の用途だとGPUは不要だったので未確認。 f:id:jaco-m:20201221025444p:plain公式サイトより

そうして起動した様子がこちら。ちゃんと128GB認識していることがわかる。 f:id:jaco-m:20201221024807j:plain

なお、購入した状態ではBIOSが古く、128GBでは起動せずにちょっと焦った。64GBで起動後、BIOSアップデートを行うことで解消したので、これから買おうという方は要注意。

10GbEもちゃんとリンクアップしている。 ちなみにSH370R6V2もGbEなNICを2つ標準で積んでいるので3NIC使えることになる。 f:id:jaco-m:20201221025028p:plain

自宅でvSAN組もうという人は世の中でも稀だと思うが、メモリ128GBにGPUないしは10GbEが積めるというのは結構良いのではなかろうか。

"Opinionated"をどうスッキリ訳すか

ニュアンスを正確に伝える翻訳って難しい。

 

プラットフォームやフレームワークの文脈でよく使われる単語に Opinionated がある。

 

f:id:jaco-m:20201210013851p:plain

 例えばCloud Foundryというアプリケーションプラットフォームの特徴としてもこの単語が使われている。

The Cloud Foundry cloud-native platform has three defining characteristics: it is structured, opinionated, and open.

- Cloud Foundry: The Definitive Guide  https://www.oreilly.com/library/view/cloud-foundry-the/9781491932421/ch01.html

Opinionatedとはどういう意味か。辞書を引いて意味を調べると、こんな感じだ。

opinionated

自説を曲げない、意固地な
・Someone known to be passive may become opinionated. : 従順だった人が意固地になることがある。

https://eow.alc.co.jp/search?q=opinionated

え、なんかめっちゃネガティブ・・・

 

日本語の記事でも翻訳には苦慮しているようで、なんとか表現を工夫して伝えようとしていることが分かる。

これが同社にとっての「opinionatedな」(自社の考えや提供価値を体現した)アプローチだ。
- CNCFのCOOに聞いた、CNCFとOCI、Docker、Kubernetes、Cloud Foundryとの関係 https://www.atmarkit.co.jp/ait/articles/1612/22/news032.html

 このようにCloud Foundryは、デベロッパーに対して無駄なことをさせずに、アプリケーションを書くことに集中させるため、時に「Opinionated(独善的)」という形容詞が付けられるほどだ。

- ONSのトリはVinton Cerf氏登場 そしてCloud FoundryとKubernetesはどうなる?  https://thinkit.co.jp/article/13794

 このように、そのまま日本語に訳すのではなく、Opinionatedという英単語を直接記した後、日本語の補足を加えるというケースが多く見られる。

ポジティブな意味でのOpinionated

しかしプロダクトの特徴に使われるくらいなのだから、当然ポジティブな意味で使っている。

Cloud Foundryは、アプリケーションを開発してcf pushというコマンドを一発叩くだけで、コンテナイメージへの生成からインターネット上への公開まで全ての作業を自動で行ってくれるプラットフォームだ。

f:id:jaco-m:20201210020242j:plain

 超絶便利な一方で、世の中全てのWebアプリケーションを動かせるというわけではない。Cloud Foundryの恩恵を受けながら動かしていくには、12 Factor Appなどいくつかの制約に従う必要がある。

利用者に制約を課す代わりに高い生産性を提供する=Opinionated というわけだ。

 

Constraints are liberating - 制約は自由をもたらす

OpinionatedなWebフレームワークとしてよく取り上げられるのが、Ruby on Railsだ。フレームワークという存在自体が既にOpinionatedだとも言えるが、Railsはその中でも特にその傾向が強い、そしてそのメリットを強烈に印象づけた先駆けといえる。

設定より規約(Convention over configuration) の考え方に則り、あれこれ設定させるのではなくフレームワークの規約に従って開発をさせることで、重要なことに注力できるようになる。規約から外れたことは出来ないため柔軟性は少し落ちるかもしれないが、それを遥かに上回る生産性というメリットがついてくる。

Railsを表現する言葉として 制約は自由をもたらす(Constraints are liberating) というものがあるが、一見矛盾したこの2つの考え方を両立させるのが、規約を重要視したWebフレームワークであり、Opinionatedな仕組みなのである。

で、どうやって訳すのか

 ここまで読んだ諸兄には、Opinionatedのポジティブな文脈での利用法が伝わったと思うが、じゃあこれをどう訳せば日本語としてスッキリするだろうか。

自分は仕事でCloud Foundryに関わることが多いのだが、口で説明するとこんな感じになってしまう。

「Cloud Foundryの特徴はOpinionatedなところにあり・・・えー、Opinionatedという言葉は日本語にすると『独善的』とも訳されることがあるんですが、そういうネガティブな話では無くもっとポジティブな感じで、制約を課すことでむしろ生産性を上げていくという意味でして・・・」

結局先に上げた記事のように、Opinionatedという英単語をそのまま使いつつ日本語で補足するという形になってしまう。

『こだわり』の翻訳

そう悩むこと数年。ついに出会った、個人的にスッキリくる訳がこれである。

『こだわり』

だいぶ前に読んだ何かの記事で使われていた訳だ。出典はちょっと失念してしまったのだが、『○○は、こだわりの強いプラットフォームであり・・・』といった形の表現をされていてた。

なるほど、これはいいかもしれない。

辞書で引いてみるとこういう説明がなされている。

拘わる
読み方:こだわる・かかわる
別表記:拘る

拘わるとは、比較的どうでもいい事を気にしすぎて、いつまでも気にかけたり必要以上に手を加えたりしたがることを意味する表現。「かかずらう(拘う)」ともいう。

「拘わる(こだわる・かかわる)」の意味や使い方 Weblio辞書

おおう、ネガティブ。

そう、『拘る』という言葉は本来ネガティブな意味で使われる言葉だ。しかしご存じのように、『シェフのこだわりランチ』のような形でポジティブな用法もある。これは比較的最近生まれた用法らしい。

ネガティブな用法で使うときは『拘り』と漢字にし、ポジティブな用法で使うときはひらがなにすることが多い。

この二面性がある感じ、Opinionatedと一緒ではないか。

 

「Cloud Foundryって結構こだわりが強いプラットフォームなんです。Kubernetesほどなんでもアリなプラットフォームではないんですが、12 Factor Appsに従ってアプリを作ることで、cf pushだけでアプリをデプロイできて。」

 

うん、だいぶスッキリしたな。

 

「イラストでわかるDockerとKubernetes」は完全に良書

すごいタイミングですごい本が出たもんだ。

本日はKubernetes Advent Calendar 2020 その1 向けのエントリー。

本当はCF for k8sの記事を書くつもりだったのだけど、先週盛り上がりまくったDockershimのDeprecated話の後ですごーく良い本が出てきたので、これは紹介せねばということで急遽内容を変更。

jaco.udcp.info

CF for k8sの話も途中まで書いちゃっているのでまた日を改めて公開する。

あの神資料が本になったよ

ということで今日の話題はこちら。

今ではDockerやKubernetesに関する本もだいぶ出揃い、使い方を学ぶのには困らなくなってきた。それに、基本的な使い方だけであれば書籍で体系的に学ばなくとも、ネット上に転がっているサンプルをそのままコピペするだけで難なく動かせてしまう。

10年前であればセットアップだけで数日かかっていたような複雑なソフトウェアでさえ、 docker-compose up するだけで動かせてしまう。これはDockerを学び始めた人の誰もが体感するところだろう。

これ自体はとても良いことなのだけど、言い方を変えると仕組みを理解しないまま使い続けられてしまう。例えば先ほどの『Docker非推奨問題』で不必要に慌ててしまったり、環境をKubernetesへステップアップさせていく際の支障となったり。こういった『何らしかの躓きポイント』は、出来る限り早めに取り除いておきたい。

ぜんぜんわからない 俺たちは雰囲気でDockerをやっている

しかし毎日車に乗っている人が必ずしも車の仕組みに詳しくないのと同様に、毎日 dockerkubectl を叩いていても、なかなか仕組みには詳しくならない。仕組みを理解していくには、世の中の膨大な資料を自分で調べたり、あるいは Kubernetes The Hard Way のようにステップバイステップで触っていくなどの努力が必要だ。

この分野で食っていく人にはそうして欲しいのだけど、Dockerを触る全ての人がそうすべきだとは思わない。もっと素早く、体系的に学べる資料があったほうが良いだろう。

ということで、これまではNTTの徳永さんの、この神資料を紹介していた。

www.slideshare.net

で、今回。この神資料が本になったのだ!

これでSlideShareを社内ネットワークから接続拒否しているようなエンタープライズ企業の人にも勧められる!

仕組みを理解するのに簡潔かつ明快な章立て

徳永さんによって書かれた本書。目次は以下のようになっている。

(目次)
第1章 コンテナ技術の概要
1-1 コンテナを見てみよう
1-2 コンテナ技術の基本的な特徴
1-3 本書で注目するDockerとKubernetes
第2章 Dockerの概要
2-1 DockerによるBuild、Ship、Run
2-2 コンテナのレイヤ構造
2-3 DockerのアーキテクチャとOCIランタイム
2-4 まとめ
第3章 Kubernetesの概要
3-1 Kubernetesの特徴
3-2 Kubernetesクラスタとkubectl
3-3 Kubernetesにおける基本的なデプロイ単位
3-4 KubernetesにおけるPod群のデプロイにまつわるリソース
3-5 設定項目やボリュームに関するリソース
3-6 Kubernetesにおけるサービスディスカバリ
3-7 KubernetesのPodとCRIコンテナランタイム
3-8 まとめ
第4章 コンテナランタイムとコンテナの標準仕様の概要
4-1 コンテナランタイムと2つのレイヤ
4-2 いろいろな高レベルランタイム
4-3 いろいろな低レベルランタイム
4-4 OCIの標準仕様
4-5 runcを用いたコンテナ実行
4-6 実行環境作成に用いられる要素技術

目次を見るだけで気づくかもしれないが、例の問題はこの本を読めば完全に理解できる

対象となる読者はコンテナ入門者。ただしDockerを学びたい人が1冊目に読む本ではない。他の本やWebの資料を基に基本的な使い方を理解した人が、二冊目として本書を利用して仕組みの理解を深めるとよさそうだ。

仕組みの説明をするとどうしても分量が多くなってしまうものだが、本書は目次や索引含めて148ページしかない。2時間程度でさっくり読めてしまうだろう。そういった意味でも、二冊目として最適なものだと言える

図が多くて分かりやすい

前回の自分の記事の対するコメントでもいくつか頂いたのだが、やはり仕組みの説明には図を使うのが分かりやすい。

前述の徳永さんの資料も図解が素晴らしかったのだが、本書は図+文章でより理解しやすくなっている。 f:id:jaco-m:20201208211454j:plain

特にコンテナランタイムの図解は必見。コンテナランタイムは高レベルランタイムと低レベルランタイムで役割が異なるのだが、学び初めはどうしても混同しやすい。図を頭に入れて置くことで、スッキリ理解しながら読み進めることができるだろう。

プログラミングの学習では、書籍をそのまま丸写ししていく写経が良いと言われるが、本書の図を手書きして自分の言葉で説明ができるよう、模写していくのもありかもしれない。

f:id:jaco-m:20201208213010j:plain ちなみにこちらは自分が先日の記事を書く前に、とある人に説明する際に描いた絵

やっぱり難しいKubernetes部分

若干気になったのはKubernetesに関する図解。Kubernetes自体の規模が大きく複雑なのもあるからか、やや抽象化されすぎて分かりづらいものもあった。また、Kubernetesの7角形に拘った表現が多かったが、紙面ならばもうちょっと表現の工夫が出来たのではないかなと思うところがあった。

ただそれでも、相当分かりやすい部類の説明であることには変わりないので、是非読んでみて欲しい。

Kubernetesの部分を特に掘り下げて理解していきたい場合は、Kubernetes完全ガイドにステップアップしていくのが良いだろう。この本も図解が非常に豊富で、Kubernetesを学ぶのには最強の本だ。

ということで

「イラストでわかるDockerとKubernetes」、本当におすすめです。

Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ

今話題のこれ。

kubernetes.io

これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。

blog.inductor.me

blog.inductor.me

にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない

タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。

Dockerは非推奨じゃないし、これからもバンバン使え

まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが

自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は関係が無い

Kubernetesを使っていてもDockerはバンバン使っていいし、今のあなたたちが行っているワークフローには何の変化もない

今回の件で騒いでいる人たちは、この部分を勘違いしているように思う。

今までもこれからも、Dockerを使うことは推奨するし、本番で動かすときはDockerで作ったイメージをKubernetesに持って行って良い。

じゃあ何で非推奨って話になったのか

今回の件は、Kubernetes内部のコンテナランタイムとしてDockerを利用するのがDeprecatedになったという話。言い方を変えると、Kubernetesを自前で構築して使ってる人くらいにしか影響がない。 上記の記事で十分に説明されていると思うけど、自分が他の人に説明する際に使った絵を使うとこんな感じだ。

普通にDockerを使う場合

普段 docker run のようなコマンドを使っていると思うが、内部的にはざっくりこんな感じの動きになっている。 docker コマンドはDockerのAPIを通じて、最終的には裏側にいるコンテナランタイムによって実行される。Dockerは内部で containerd という仕組みを使っていて、そこで動く。 f:id:jaco-m:20201203162951p:plain

KubernetesでDockerを使っている場合

KubernetesのコンテナランタイムでDockerを指定している場合はこうなる。人間がdockerコマンドを叩く代わりに、kubernetesの中の人がDocker APIを叩いてくれるイメージだ。 f:id:jaco-m:20201203163334p:plain

上記の絵を、もうちょっと付け加えるとこう。Kubernetesがコンテナランタイムと喋るときにはCRIという仕様を元に行うのだけど、DockerはCRIに対応していない。なので、 dockershim というブリッジを経由して通信を行っている。 f:id:jaco-m:20201203163809p:plain

今回の話

でも実は、Docker内部の containerd は、CRIに対応しているのである。 え、じゃあcontainerdと直接通信すれば、dockershimもdocker apiも要らないんじゃない?

f:id:jaco-m:20201203164237p:plain

そう、今回の話は、ただそれだけの話なのである。

ふつうに考えればcontainerdを直接叩いた方が運用の面でも、セキュリティの面でも、リソース効率の面でも効率がいい。実際多くのディストリビューションがcontainerdやcri-oといったCRIを喋れるコンテナランタイムを直接使うようになっている。

ならば、もうそろそろDockerのところは必要性が薄れてきたよね、となったのが今回の話。

Dockerが大きく普及したのが2013年ごろ。Kubernetesが登場したのが2014年。この段階ではKubernetesがDockerをコントロールする構図は自然な流れだった。

その後様々なコンテナ規格の乱立が始まったため、標準規格を定めようという動きになったのが2015年から2016年にかけて起こり、そこでcontainerdやCRIが登場した。こうした歴史的な経緯を経て、より効率の良い方向へと変わってきたわけだ。

これからもバンバンDockerを使えというワケ

繰り返しになるが、今回の件はKubernetes内部の一部品としてDockerが使われなくなるというだけなので、Kubernetesの利用者には何の影響もないと言って良い

ごく一部の利用者には影響があるかもしれないが、そういった深い使い方をしている人であれば、そもそも今回の件で慌てることはないだろう。

利用者には影響はないという理由

Dockerがここまで普及したのは、Build, Ship, Runというワークフローを確立したところにある。

f:id:jaco-m:20201203165855p:plain

  • Dockerfileを書き、 docker build コマンドでイメージを作成する。
  • docker push コマンドでイメージをRegistryにpushする
    • 他の人がpushしたイメージをそのまま使うことも出来る
  • docker run でコンテナを実行する
    • docker-compose を使うとより便利

Kubernetesを使う場合も、このワークフローはそのまま利用することが出来る。

f:id:jaco-m:20201203170245p:plain

Build, Shipのフェーズはそのままで、Runのところが変わる。 docker rundocker-compose up する代わりに、YAMLでManifestを書き kubectl apply するわけだ。開発のワークフローはそのままに、より高度な運用(Run)が出来るようになったのがKubernetesの利点である。

じゃあ今回の件で何が変わるか? 何も変わらない

f:id:jaco-m:20201203170725p:plain

今まで通りにDockerfileを書いてDocker image作ればいいし、kubectl apply するところも全く同一だ。 デプロイした先でのKubernetesの内部コンポーネントの通信先がちょこっと変わっているだけである。

そう、だからDockerは今まで通り便利なツールとして使い続けられるし、もちろんDocker以外のツールを使ってもいい。

標準規格によって、利用者はどんなツールを使っても互換性の問題に悩むこと無く恩恵にあずかれるのが、今のCloud Native技術だしCNCFの存在意義である。そして今回の話は、標準規格がしっかりしているからこそ出来た、極めて健全な発展を裏付けるものなのだ。 だって大きな互換問題が発生するんであればこうも簡単にDeprecatedに出来ないよね。

互換性の問題でレガシーを引きずるソフトウェアがごまんとある中でこういった移行ができるのは、むしろ賞賛されるべきことだと考える。

ビジネスとしてのDocker(社)の動きについて

Docker社がビジネス的な観点で大きなチャンスをモノにできなかった話は、言わんとすることは分かるし自分としても思うところはたくさんある。

しかし、今回の件は決してDockerがビジネス的に衰退したから切り捨てられるってわけじゃなくて、技術的にあるべき形に進化したというだけだ。

そりゃ確かにDocker swarmあたりを成功させていれば、ここまでのKubernetes1強にはならなかったかもしれない。しかしそれは全く別次元の話であって、今回の件に絡めて『Dockerはオワコン』みたいな話に持って行くのも、なんか違うんじゃないかな。

結論

もう何度目の繰り返しになるか分からないけど、 DockerもKubernetesも超便利な仕組みだし、まだまだ発展していくのでこれからも便利に使っていこう。

追記

良いタイミングで良い本が出たので紹介。今回の件で慌てちゃった人にはすごくお勧め

jaco.udcp.info