‫わかりました｡
‫今週は､ このことについてお話したいと思います｡ このことについて､ やっている人も､ 心配している人も､
‫コメントで感想を聞かせてください｡ キャプテン 先週か先々週だったかもしれませんが､
‫いくつかの記事について話していました｡
‫特に3､ 4ヶ月前の記事では､ コンテナのセキュリティ・スキャンについて話していました｡
‫これらは､ あなたのアプリの依存関係としても保存されます｡
‫この画像の良いところは､ コードやアプリケーション､ 依存関係にある既知の脆弱性や潜在的なセキュリティ上の欠陥をスキャンするのに非常に適した場所となることです｡
‫ですから､ 私たちはそれをコンテナスキャンとかイメージスキャンと呼んでいます｡
‫業界ではさまざまな用語が使われていますが､ スキャナーはたくさんありますし､ 数も多いです｡
‫そして､ それらにはすべて長所と短所があり､ もしあなたがこれに聞き覚えがあるならば｡
‫これは､ 昔のウイルス対策戦争で､ さまざまなウイルス対策スキャナーがあり､ それぞれ異なるものを検知していたのとよく似ています｡
‫しかし､ 現在､ コンテナスキャンで一般的に最初に話題になるのは､ 既知のオープンデータベースを使用することです｡
‫これは､ 主にオープンソースソフトウェアに存在する既知の脆弱性というキーワードですが､ オープンソースに限ったことではありません｡
‫たまたまオープンソースが多かっただけで､ ソースを見ることができるため､ 欠点を見つけることができる傾向にあるのです｡
‫だから､ 結局は業界として､ どこに問題があるのかを早く見つけ出すことになるのです｡
‫そのため､ 既知の脆弱性のデータベースがあり､ 常に更新されているのです｡
‫そのため､ 画像とその依存関係をスキャンするスキャナーは､ 無料のものもあれば､ そうでないものもあります｡
‫自分のアプリだけでなく､ どんなアプリでも､ インストールされている依存関係を取得することができます｡ 例えば､ Open
‫SSLやcurlのような脆弱性がある場合､ コンテナイメージの中にその依存関係が含まれています｡
‫これらのスキャナーは､ 脆弱性を見つけてアップデートし､
‫うまくいけば修正プログラムを適用できるようにするためのものです｡
‫しかし､ 一日の終わりに､ Linuxで彼らが本当に依存しているものの一つは､ オペレーティングシステム､ またはこの場合は､ Debian
‫Sにブーンするようなベースイメージです｡ O. S.
‫アルパイン的なもの
‫これらの異なるベースイメージは､ しばしばシステム上のどこにファイルがあるのか､ そしてそれらのファイルがどのプログラムに関連しているのかを翻訳する必要があります｡
‫そのため､ これらのファイルはオペレーティングシステムのファイルパスのどこかに存在し､
‫それらがすべてパッケージとしてまとめられ､ ベンダーはスキャナがパッケージの場所を見つけるための翻訳を提供する必要があるのです｡
‫OKです｡
‫そういう背景があったんですね｡
‫そして､ LinuxのすべてのOSディストリビューションがその機能を提供しているわけではなく､ また､ すべてのディストリビューションが他と同様にその機能を提供しているわけでもないことが判明したのです｡
‫そのため､ 脆弱性をスキャンしようとすると問題が発生する可能性があります｡
‫つまり､ UbuntuであろうとSであろうと､ あなたのベースとなるイメージです｡ O. Sやレッドハット､ アルパインなど､ そのイメージに含まれる既知の脆弱性の完全なデータベースをスキャンすることができるという点で重要なのです｡
‫ところで､ この記事をライブチャットに投じようと思うのですが､
‫この記事を通して､ 興味深い点が1つありました｡
‫それを確認することができます｡
‫興味深いのは､ この下の方にある「アルパイン問題」ですが､ これは私たち容器メーカーにとって非常に興味深い議論だと思います｡
‫容器を作っている人､ 少なくとも容器を作ることに興味がある人かもしれませんね｡
‫そして､ そのようなイメージを作る場合､ 懸念されるのがセキュリティです｡ セキュリティは､ 多くの場合､ すべてを「安全だ」「セキュリティはできている」とひとくくりにしてしまいますが､
‫それは本当に正しいことではありません｡
‫私たちは皆
‫長くやっていると､ セキュリティにはいろいろなものがあり､ 本当に安全なものなどないことが分かってきます｡
‫そうですね｡
‫私たちはいつも「最も安全なシステムは電源を切っているものだ」と冗談を言っているのかもしれません｡
‫アルパインは本当に素晴らしいディストリビューションで､ アルパイン・リナックスのベースイメージを提供していますし､
‫その良いところは非常にミニマルであることです｡
‫O. S.
‫フルOSで比較することもできますが､ ここではイメージそのものについて話しているのであって､
‫コンテナイメージはホストOSではありません｡
‫ホストOSの話はしたくないので､ コンテナのベースイメージの話をしたいと思います｡
‫この業界では､ 私たちはオンラインでこの話をするのが好きなのですが､
‫私たちのコミュニティのツァイトガイストは､ クールでトレンディなものをキャッチしています｡
‫それから､ これは実際にやってみたのですが､ セキュアなDockerベースイメージをグーグルで検索しても､ Alpineという単語を検索しても､
‫このページには出てこないんです｡
‫しかし､ アルパインに期待するのは､ アルパインが自動でセキュリティを確保する方法であるとか､
‫より優れたセキュリティであるといったことを､ 多くの業界関係者が推奨していることでしょう｡
‫そして､ それを主張する理由は､ それが小さいからです｡
‫つまり､ ファイル数が少なければ､ 潜在的な脆弱性も少なくなり､ パッチを当てる対象も少なくなるということです｡
‫そうですね｡
‫そして､ これはWindows 2000時代の2008年から何十年にもわたって行ってきたことなのです｡
‫Windows 2008が発売されたとき､ マイクロソフトはWindows Serverの小型版であるcoreという新バージョンを出したのを覚えています｡
‫そして当時､ 最も大きな論点の1つは､ パッチ適用を減らすことによるセキュリティの向上でした｡
‫理論的には､ マシン上のソフトウェアの数が少なければ､ パッチや潜在的な脆弱性に関して心配することは少なくなるわけです｡
‫しかし､ スペースは必ずしも第一の要因ではありません｡ 実際､ サーバーを生業としているオペレーターとしては､
‫このスペースが安いとは思えません｡
‫この100メガという容量は､ たとえ5枚の画像を保存する場合でも､ 私のサーバーに500メガもの容量を確保する必要はないんだ｡
‫また､ クラウドでは､ イメージベースのサーバーバックアップを行うことはありません｡
‫昔はフルイメージバックアップを行っていたので､ バックアップの多くはオペレーティングシステム全体を何度も何度も繰り返し行っていました｡
‫特に最近はクラウドネイティブが多いので､ 画像やサイズについて話すとき､ 画像やその品質に関する私のトップ3の要因の中にサイズが入っていないように思います｡
‫ですから､ 画像を見て､ セキュリティ上の懸念があるかどうか､ あるいは､ 1ギガか20メガかにかかわらず､
‫画像を使用することについては､ 最終的にはストレージのコストになるかもしれませんが､ そのコストは私のコストリストの中で最も安いものの1つですから､
‫それほど気になりません｡
‫人間が一番高価で､ あとはCPEメモリネットワークなどのコンピューティングパワーはディスクよりも常に高価です｡
‫だから､ いきなりアルパインをやれとはあまり勧めないんです｡
‫実際､ 私がDockerプロダクションについて話しているのを見たことがある人なら､
‫私が話していることの一つは､ DebianやUbuntuやSent OSにこだわるということで､ もしあなたが慣れているものであれば､ そのイメージにこだわることです｡
‫しかし､ 最近でも､ この1年､ 特にこの3ヶ月の間に､
‫アルパインをベースイメージとして使うべきでないという指標をいくつも目にするようになりました｡
‫このブログの記事で､ アルパイン問題をめぐる新しい議論を考えてみると､
‫今のアルパインは最適な場所ではないかもしれない､ ということです｡
‫だから､ セキュリティスキャナを使うような人には､ アルパインは実は不向きなんです｡
‫もうひとつ､ 最近気づいたのは､ アルパインは部分的に､ 思いもよらないような問題が忍び込んでいることがあるということです｡
‫最近､ 何人かの学生から､ ノード・モンでアルパインを動かそうとすると､ 既知の問題があると言われたことがあります｡
‫そして､ そうしました｡
‫私は......意識していませんでした｡
‫私はテストしていませんが､ アルパインを使ってノーJになったという人が続出しています｡ S. node mineとNode minus
‫somethingとno J Sは､ ファイルが変更されたときに自動的にnodeアプリを再起動するファイルモニタリングに使うものです｡
‫しかし､ UbuntuやDebianでは問題が起きなかったのに､
‫alpineでは問題が起きていることが明らかになったのです｡
‫だから､ 多くの人が私のところに来て､ アルパインをどう思うか､ 全部アルパインに変えたほうがいいかと言うんです｡
‫Debianで構築しているイメージは全部持っていったほうがいいのか､ それとも免疫があるのか､ Sなのか｡ O. Sとか｡
‫そして､ Alpineの方が小さくて安全だと聞いたから､
‫全部Alpineに移行した方がいいのか｡ 正直なところ､
‫最近の私の答えはもっと複雑で､ 検討した方がいいと思います｡
‫そのため､ デフォルトのイメージはすべて､ Alpine イメージよりもわずかに大きい 80 メガサイズの Debian
‫アンダーを使用するようにデフォルト設定されています｡
‫つまり､ それは小さな要因で､ IO Tデバイスのようなものを使っていない限り､
‫大きなモチベーションにはならないんです｡
‫小型のフラッシュメモリーを使用する場合､ 端の方などは気になるものです｡
‫しかし､ デフォルトのイメージを見てみると､ バックグラウンドにあるデフォルトのイメージはすべて､
‫Docker run nodeやduck､ run my sequelとタイプすれば､ そのイメージになります｡
‫これらはすべてデフォルトでDebian上で動作します｡ なぜなら､ 6年前にDockerが最初に作った方法だからです｡
‫しかし､ そのすべてにアルパインのオプションが用意されるようになったのです｡
‫だから､ アルパインのタグを使えば､ 私の続編はアルパインだと言って､ アルパインのタグを使うのはいいのですが､ だからといって､
‫常に良い体験ができるわけではありません｡
‫すべてのパッケージがAlpineパッケージマネージャで利用できるわけでもありません｡
‫実際､ 私は自分用にセキュリティツールや様々なユーティリティを持っていますが､ その中にはアルパインで動作するものとしないものがあります｡
‫ビルドに失敗したからといって､ 手作業でビルドの方法を調べたり､ ライブラリが違うからとトラブルシューティングをしたりするのは､
‫正直言って嫌です｡
‫だから､ ほとんどのツールはDebianのままにしておいて､ 他のものはAlpineを通して使っているんだ｡
‫パッケージマネージャを取得するためのアプリやapt apt パッケージマネージャはパッケージマネージャの王様みたいなものなので､
‫結局のところ､ ほとんどすべてがDebianでそのまま動くということが分かっているんです｡
‫もし､ 何かのパッケージがあれば､ それはおそらくaptになるでしょう｡
‫そうですね｡
‫Yumに何かが見えてこないかもしれない｡
‫Pyneのパッケージマネージャでは見かけないかもしれませんが､ DebianやUbuntuなどのベースイメージには常にaptが搭載されています｡
‫ですから､ 画像について考えるとき､ そしてベースとなる画像を構築するとき､ これらのことを総合すると､
‫セキュリティは間違いなく重要な要素なのです｡
‫しかし､ セキュリティを重視するのであれば､ 画像をスキャンするのも一つの方法です｡
‫だから､ アルパインでやりたい人には不利かもしれませんね｡
‫その場合は､ 本文中に投げ込んだので､ 絶対にこの記事を読んでください｡
‫もうひとつは､ スペースメリットが本当に重要なのか､ ということです｡
‫もし､ 潜在的な安全性で少し損をしているのなら､ 画像サイズはそれほど重要ではありません｡
‫特に､ JavaやHPなどを扱うときによくある､ 800や900のマグサイズの画像を持っている人ならなおさらです｡
‫これらの画像は､ 一般的に80メガや5メガに匹敵する非常に大きな画像です｡
‫だから､ そういうことを少し考えてみてください｡
‫アウトラインの方が安全だと聞いたからと言って､ 自動的にすべての荷物を入れ替えないようにしましょう｡
‫もちろん､ アルパインが小さいからこそ､ セキュリティ面でのメリットもたくさんあります｡
‫潜在的な脆弱性はほとんどないのですが､
‫脆弱性はあるわけです｡
‫UbuntuとDebianのことです｡
‫最後に､ UbuntuやDebianのような他のイメージを見たことがないのであれば､
‫これらのイメージは時間とともに小さくなってきていることをお伝えします｡
‫というのも､ 古い画像にあったものが新しい画像に引き抜かれたり､
‫ソフトウェアに問題が発生したりすることがあるからです｡
‫例えば､ 支払いやIPコンフィグ､ あるいはP Sコマンドなどです｡
‫何年も前の画像にあったものが､ 現在のバージョンのデフォルト画像にはない場合があり､
‫常にそこにあるものと思い込んでいると､ ちょっとした問題になります｡
‫だから最近は､ たとえboonを使って箱から出してイメージ化しても､ もしかしたらDebianを使ったデフォルトのイメージを使っているかもしれない､
‫という習慣になっています｡
‫プロセスリスト用の P S コマンドや curl など､ 今すぐ必要なものも apt でインストールしますし､
‫将来のバージョンでそれらが削除されたとしても､ 私のイメージには常にそれらが入っているようにするためです｡
‫だから､ ここでDockerのイメージL Sをするだけでは､ マシンをクリーンアップしていないので､ ダメなんです｡
‫実はここにあるのは2つだけなので､
‫DockerイメージのプルをUbuntuにして､
‫デビューインにして､ Alpineにすると､ この数字は常に変化します｡
‫一番多い数字が現状どうなっているのか実はよくわからないので､ もう一度そのDocker image
‫lessをやってみましょう､ と｡
‫そうすると､ アルパインが5.5メガになるわけですが､ これはかなり異常ですよね｡
‫その背景には､ 静的バイナリやリンクバイナリをどのように構築しているかという､ 非常にクールな理由があるのですが､
‫それは本当に小さいものではありません｡
‫Ubuntuを見ると､ 三年前のブーンは百二十メグだったでしょう｡
‫少なくとも百三十メグ｡
‫そして現在では87まで下がり､ 現在のDebianのバージョンは1対1になっています｡
‫というのも､ 普通なら Debian よりも恩恵が大きいと思うでしょうし､ Debian
‫の次のリリースでそれが変わるとは思えないからです｡
‫この答えはおそらく私よりも早く知っている人がチャットにいると思いますが､
‫私はバージョンCの実験的なものがあるかもしれないと思います｡
‫もし､ あなたが自分のコンテナについて考えているなら､
‫私は1,000個のコンテナを動かしているかもしれません｡
‫ベースレイヤーが同じだとすると､ そのレイヤーは提供システム上では1回分しか占めないことを忘れないでください｡
‫自動刈り込みによってイメージをきれいに保ち､ 実行中のアプリケーションのほとんどをベースイメージの1つか2つのバージョン内に収めるなどして､
‫サーバー上にすべてのバージョンが存在しないようにすれば､ このようなもので多くのスペースを占有することはありませんね｡
‫では､ 実験を見てみましょう｡
‫実際はもっと大きいんですけどね｡
‫それは残念だ｡
‫昨年のある時期に､ boon toとDebianが何かに移行して､ 独自のスリムを持っているという記事を読んだように記憶しています｡
‫確かに多くのものを外に出してくれるのですが､ 「どうしてこんなものが小さくなっているのだろう」と思うかもしれません｡
‫それは､ 圧縮しているからではなく､ 本質的でないツールを削除したり､
‫コアツールのために不要になったライブラリを削除しているに過ぎないのです｡
‫だからこそ､ P.A.のようなことができるのです｡ S. と支払い､ カーネルなどのユーティリティがこれらの画像から消えていきます｡
‫だから､ とにかく用心してください｡
‫ですから､ 素晴らしい議論だと思いますし､ この中で皆さんのコメントを聞いたり､
‫コメントを読んだりするのを楽しみにしています｡
‫アルパインについて､ また､ なぜアルパインを選ぶのか､
‫なぜ他のベース画像よりアルパインを選んだ方がいいのか､ などについて､
‫いくつかの講座でお話しする予定です｡