ドッカーコン
Wasm、Docker、Kubernetes の概要
ナイジェル・ポールトン、トレーナー、セルフ
写し
したがって、Kubernetesは世界で最も発音しやすい単語ではありません。 面白い話です。 何年も前、私が初めてKubernetesに取り組み始めたとき、妻は私がZoomの通話などでKubernetesについて話しているのを聞いていました。 彼女は私がそれについて言及しているのを聞いていました。 そして、当時、私たちの家族ではあまり定着していなかった言葉でした。 そして、彼女は私たちの家族の中で、それを「クンベルノーツ」と呼んでいたことで有名です。 またあのKumbernautsの仕事をしているのですか? 私は「Kubernetes、気にしないで」という感じです。
超クイックハンドショーをすることはできますか? WebAssemblyですでに何かをしているのは誰ですか? さて、これは私にとって良い聴衆です。 ですから、このセッションはもともとワークショップとして行われました。 でも、テーブルなどはないので、今はライブデモのようなものです。 ただし、GitHubリポジトリへのリンクをお見せします。そこでは、後で自分の時間にすべてのコマンドやことを実行できます。 では、さあ、さっそく始めましょう。 これは私です。 私はDockerとコンテナ、Kubernetesに関わってきましたが、現在はWebAssemblyに少し関わっています。
目次
シーンの設定
非常に簡単に、WebAssemblyのシーンを少し設定したいと思います。 何年も前、初めてVMware、仮想マシンを手に入れたとき、私は若かったです。 テクノロジーについてはあまり理解していませんでしたが、テクノロジーは大好きです。 そして、仮想マシンやVMwareを初めて体験したことは、文字通り私の心を揺さぶりました。 コンピュータ上で複数のコンピュータを動かすというアイデアは、プッ、頭が爆発するような感じでした。 そして、これが大きなものになることをほぼすぐに理解しました。 それで、私は深いところから飛び込むことに決めました、そしてそれは私のキャリアにとって本当にポジティブでした。 それから数年後、Dockerが登場しました。 しかも、本当に早かったのです。 Docker 0で少しやりました。7、しかし 0。9 初めてハマったときです。 しかし、初めてLinuxコンテナを起動して、それが仮想マシンとどのように異なるかを理解したときのことを今でも覚えています。 また、あの、プッ、頭が爆発する瞬間がありました。 そして、私は真っ直ぐに飛び込み、これが世界を変えるだろうと考え、VMwareが行ったのと同じように実現しました。 Kubernetesでも同様の経験をしましたが、Kubernetesが仮想マシンやDockerほど世界を変えたとは感じません。
現在に早送りします。 そして、このWasmまたはWebAssemblyを耳にし始めました。 そして、何度も聞いて、ある時点で「なるほど、少なくともコンセプトが何であるかを理解しなければならない」と思うようになるのです。そうすれば、誰かとの会話で恥ずかしい思いをしないように。 だから、私は大丈夫な本を書きます。 そして、本を書いた途端、人々は突然、あなたが驚くほど賢く、何でも知っていると思うようになります。 そして、それはあなたに大きなプレッシャーをかけます。 イベントで人が私のところに来ると、誰かが私のところに来るのではないかとちょっと怖かったのですが、このウェブアセンブリについてどう思いますか? そして、私は「わからない」と答えるでしょう。 とにかく、私はWebAssemblyを理解しようとしましたが、冗談ではなく、すぐに出ました。 VMwareやDockerの場合と同様でした。 頭が爆発するような感じでした。 これが世界を変えるでしょう。 私は真っ直ぐに深いところに飛び込みました。 そして今日、私たちはここにいます。
いずれにせよ、このようなイベントやその他のクラウドネイティブなイベントでは、クラウドコンピューティングの3つの方法について話しているのを耳にするでしょう。 したがって、最初の方法は仮想マシンでした。 彼らは一種の雲全体を蹴り飛ばしました。 私たちはすべてを仮想マシンで行いました。 それに伴い、コンテナはより小さく、より速く、よりポータブルになりました。 よりポータブルで、本当に小さいという理由だけで。 しかし、仮想マシンではできないようなことをしたり、場所を走ったり、実行したりすることはできました。 そして、彼らははるかに効率的でした。 ですから、彼らはクラウドコンピューティングの第二の波のようなものを推進した、あるいは推進したのだと思います。 さて、第3の波が来ています。 だから、私たちは皆そこにいます。 ボディボードやサーフボードなど、何でも持っています。 ボディボードやサーフィンをしたことがあるかどうかはわかりませんが、ちょっと海に出て、波紋を見て、あれは波になるんじゃないかと思うんです。 そして、そうであるときもあれば、そうでないときもあります。 でも、1年前は波がかなり遠いように感じました。 でも今は、波が来たような気がします。 私はボードに乗って、これを少し与えています。 そして、それは大きな波になりそうです。
いずれにせよ、それが基本的に場面の設定です。 今、私は恥知らずなプラグが欲しいです。 今日は一日最後のセッションですよね? 5時過ぎの4時半、階下のブレイクアウトルーム2。 YouTubeや後日どこかでこれを視聴している場合は、このセッションへのリンクがあります。 しかし、私たちはWebAssemblyの未来について、その強み、短所、良いユースケースは何か、そして何に役立たないかについて、かなり正直でオープンな会話をするつもりです。 しかし、これもWebAssemblyとコンテナの融合です。 それは物ですか? そして、それが物であるならば、それは良いことなのでしょうか? そうではありませんか? それはともかく、あとで、そうですね。
私たちがすること
これがアジェンダです。 これが私たちがやろうとしていることです。 さて、私はあなたにただ見るように勧めています。 あなたが望むならついて行くことができますが、私は少しペースを維持しなければなりません。 非常にシンプルなRustWebアプリケーションを作成します。 今、私は可能な限りRust開発者から離れています。 私の生活がRustに依存しているなら、Rustのコードを書くことはできませんでした。 しかし、私たちはそれを非常に簡単にするツールを使用します。 Dockerが物事をシンプルにする方法、いいですか? そこで、簡単なRust Webアプリを作成します。 これを WebAssembly バイナリにコンパイルします。 WebAssembly バイナリとは何かについては、後で少し説明します。 そして、私たちはそれを見るでしょう。 次に、それをテストして、機能することを確認します。 そして、それはとても簡単なことなので、なぜわざわざこのセッションを見に来たのか、と思うでしょう。 あるいは、「うわー、それが実はクールな部分だ」と思うでしょう。 それがとてもシンプルであるという事実は、それについての良いところです。 ちなみに、これらは使用するコマンドです。
Fermyonの人々によるSpinと呼ばれるWebAssemblyフレームワークを使用します。 他のフレームワークや他の WebAssembly ランタイムとツールは存在します。 しかし、これは私たちにとってそれを非常に簡単にするでしょう。 ただし、この後、WebAssembly アーティファクトを使用します。 そして、すでに知っているDockerツールを使用して、これをOCIイメージまたはDockerイメージにコンテナ化しますね。 次に、docker run を使用し、そのコンパイルされた WebAssembly アプリを Docker コンテナ内で実行します。 次に、それをDocker Hubにプッシュします。 繰り返しになりますが、他のレジストリも存在します。 Docker Hubは非常にシンプルです。 基本的に、OCIレジストリやOCIアーティファクトをサポートするレジストリはどれでもクールです。
そこで、このアプリをビルドしてコンパイルします。 次に、それをビルドしてDockerコンテナにパッケージ化します。 次に、Kubernetesクラスター、マルチノードクラスターを構築します。 大丈夫です。 すべてあなたのラップトップで実行できます。 ロードバランサーがここのポート 8081で私のマシンに公開されます。 そして、このポートは、Kubernetesクラスター上で実行しているときに、WebAssemblyアプリにアクセスするために少し後で使用します。
3ノードのKubernetesクラスター、遠端のノード、コントロールプレーンノードをスピンアップしますよね? そして、2人の労働者。 重要なことは、これらのWebAssemblyワークロードを実行できるようにするソフトウェアをそこに用意することです。 そして、それはすべて超シンプルなコンテナ入りのものです。 Kubernetesの基本を知らない人はいますか? そして、そうしなくても全く問題ありません。 なるほど、そうですね。
つまり、Kubernetesはこの超高レベルのオーケストレーターです。 あと少しでスライドが出来ます。 しかし、Kubernetesはその頂点に位置しています。 そして、私たちからの作業を受け入れて、ノード1、実行してください、またはノード2、このタスクを実行してください、と言っているのです。 Kubernetesは実際にはコンテナを実行したり、そのような低レベルのことを行うことはできません。 そのためのツールがユーザーです。 そして、おそらくKubernetesがコンテナを実行するための最も一般的なツールは、containerdと呼ばれるツールです。 そのため、実際にスピンアウトするほとんどのKubernetesクラスターには、このコンテナ化されたソフトウェアがすでに含まれています。 私たちのビルドは少し特別なものになるでしょう。 そこにはWebAssemblyランタイムがあります。 今は専門用語がたくさんあります。私たちはそれを見るつもりです。 ですから、これが大変に感じられてもストレスを感じないでください。 WebAssembly アプリを実行するのに十分なソフトウェアを備えた 3 ノード クラスター。 ノードの1つにラベルを付けて、KubernetesがWebAssemblyアプリをスケジュールできるようにします。 そして、ランタイムクラスと呼ばれるものをデプロイします。 専門用語が多すぎます。 本当にすみません。
非常に簡単な話ですが、これはもともとワークショップになる予定でした。 私たちは 45 分の予算を立て、先日それを実行しましたが、 17 分で終わりました。 ですから、これは複雑に見えるかもしれませんが、いざやってみると、実はそうではなく、とても簡単なことなのです。 いずれにせよ、ランタイムクラスをKubernetesクラスターにデプロイします。 ランタイム クラスを参照するアプリケーションをデプロイします。 これにより、アプリケーションが正しいノードでスケジュールされるようになります。 そして、私のラップトップのWebクライアントやブラウザ、そのポート 8081でアプリケーションにアクセスできるようにするための、ネットワーキングやイングレスなどがたくさんあります。 それが計画です。
前提 条件
いくつかの前提条件、大丈夫です。 最新バージョンの Docker Desktop が必要です。 6つの前提条件があります。 ですから、写真を撮る場合は、6番が上がるまで待ってください。 ちなみに一番下にあるGitHubリポジトリです。 あなたが一緒に行きたい場合、または後で家やホテルなどでこのエクササイズをしたい場合。 比較的新しいバージョンのDocker Desktopが必要になる理由は、WebAssemblyの機能やサポートが組み込まれているためです。 現時点では、これらは実験的な機能のようなもので、それらを有効にする方法をお見せします。 将来的には、ビデオで見ている場合、デフォルトでオンになっている可能性があります。
はい、Docker Hubアカウントは必要ありません。 Kubernetesクラスターがレジストリからソフトウェアをプルできる必要があるため、ソフトウェアをレジストリにプッシュする方法がある限り、他のレジストリも存在します。 Rustがインストールされている必要があります。 他の言語もサポートされています。 Python、C、Go、たくさんの言語。 ここでは、Rustをお見せします。 Fermyon Spin アプリケーション。 kubectl が必要になります。 それがKubernetesコマンドラインユーティリティです。 本当に複雑に見えますが、そうではありません。 そして、kubernetesクラスタを構築するためのk3dです。 写真を撮りたいなら、今がチャンスです。
デモ
さあ、デモに取り掛かる時が来ました。 次に、単純なアプリケーションをWebAssemblyバイナリとしてビルドしてコンパイルしようとしています。 さて、それでは。 最初に行うことは、インストールされているFermyon Spinアプリケーションを使用することです。
したがって、現時点ではDocker Desktopでは、開発中の設定と機能に入ると、イメージのプルと保存が有効になっているコンテナを使用したいと考えています。 そして、このチェックボックスはWasmを有効にします。 私が将来言うように、これらはデフォルトでオンになるかもしれません。 現時点では、これら2つのチェックボックスをクリックしてから、[適用して再起動]ボタンを押す必要があります。
マシンにSpinがインストールされていることがわかります。 Rustがインストールされている場合は、wasmターゲット32 wasiターゲットを追加する必要があります。 私はすでにそれを私のマシンにインストールしています。 こちらがこちらです。 さて、これが何をしようとしているのか、これは興味深いことです。 これは WebAssembly の中核です。 アプリケーションをコンパイルするとき、通常は「はい、このアプリケーションをArmとLinux、またはArm上のLinux用にコンパイルしたい」と言うでしょう。 または、AMD64上のLinux、そのようなもの。 WebAssembly は独自の命令セットまたはアーキテクチャバイナリ命令セットであり、ARM 上の Linux にコンパイルする代わりに、Qasm にコンパイルできるようになりました。 そのアプリケーションは、WebAssembly ランタイムを持つ任意のシステムまたはホストのどこでも実行できます。 そのため、一度ビルドすればどこでも実行できるという約束を非常に果たしているため、コンテナよりもはるかに移植性に優れています。 だから、私はそれをインストールしました。 その他の前提条件。 いや、そうは思いません。
もし新しくスピンすれば、今画面上に表示されているどの言語でも新しいアプリケーションを構築できるようになります。 私が言ったように、私はRustをコーディングする方法の手がかりがありませんが、私は勇敢です。 そこで、HTTP Rust アプリケーションをデプロイします。 ですから、もしReturnを押すとしたら、もちろんDockerConと呼ぶことにします。 ところで、皆さんはDockerConを楽しんでいますか? はい。 その話をしているんです。 なるほど、かっこいい。 だから私はそれをDockerConと呼んでいます。 説明は気にしません。 そして、このWebアプリケーションが応答するようにしたいのですが、私は言うつもりです、なぜなら、私は 90や 80に引っかかっているかもしれません。 しかし、それにより、DockerConという新しいディレクトリが作成されます。 そして、そのディレクトリの内容を見ると、基本的に3つのファイルがあります。 Rustアプリケーション lib.rs です。 ですから、もし私がvimを使ってこれを編集するとしたら、いつものように「こんにちは、フェルミオン」と言うでしょう。 DockerConでは、真ん中に大文字のCが付く予定です。 変更を保存します。 基本的にはそれがアプリケーションです。 シンプルなWebサーバー。
ここでの spin.toml ファイルは少し重要です。 これは Spin に伝えます - そして、すぐに Spin が何であるかをもう一度説明します - しかし、これは Spin に WebAssembly アプリケーションの実行方法とビルド方法を教えてくれます。 つまり、Spin は WebAssembly フレームワークであり、WebAssembly ランタイムと、WebAssembly アプリケーションの構築とデプロイを容易にする一連のツールが付属しています。 たとえば、この線はここの下部に近いです。 アプリケーションをWebアセンブリバイナリにビルドするためにスピンビルドを実行すると、舞台裏ではこの種の恐ろしいRustコマンドが実行されます - cargoはRustアプリケーションをコンパイルできるRustツールチェーンのツールです。 だから、カーゴビルドダッシュダッシュターゲット何とか行く代わりに、私はただスピンビルドに行くつもりです。 それでは、Spinさん、それを簡単にしてくれてありがとう。 しかし、それはまた、アプリケーションの実行方法をSpinランタイムに指示します。
WebAssembly バイナリをビルドする
ここで、WebAssemblyバイナリを構築します。 つまり、基本的には3つのファイルです。 今のところcargo.tomlは気にしません。 そこで、私たちが興味を持っているのは2つのファイルだけです。 私が今スピンビルドを行い、うまくいけば会議中にWi-Fiがそれほど長くかからないことを願っていますが、これはそのアプリケーションをWebAssemblyバイナリとしてビルドまたはコンパイルするでしょう。 指を交差させて、それほど時間はかかりません。 デモの神々に祈りを捧げます。 だから、それは悪くない。 さて、ちょっと待ってください。 今、私が別のツリーを実行すると、より多くのファイルがロードされます。 まあまあ、でも先延ばしにしたり怖がったりしないでください。 これはdockercon.wasmです。 これは、コンパイルされた Web アセンブリ バイナリです。 だから新しいスピン。 名前を付け、パスを付け、ビルドをスピンします。
今、私はかなり賢いと感じています。 Rustアプリケーションをコンパイルしました。 Rustを知らない場合でも、Rustは学習して作業するのが難しい言語であると確実に伝えられています。 そして、WebAssemblyは超新しいです。 私は一気に賢い人ではありませんが、WebAssemblyアプリケーションをコンパイルしたばかりで、かなり気分がいいです。 超。 したがって、.wasmである任意のファイル ファイルは WebAssembly アプリケーションです。
さて、さて、ファイルを手に入れましたが、それは実際に機能しますか? まあ、テストのために、私たちがすることはスピンアップすることだけです。 そして、それが私たちのアプリケーションを起動します。 そして、ここのローカルホスト、 30000でリッスンしています。 だから、ブラウザに飛び移ると、生意気な新しいタブ。 ああ、それは小さいですね。 これを巨大にしましょう。 できるだけ大きくなりましょう。 500%。 それが最大級の成果だ、誰が知っていただろう? 500%以上になることはできません。しかし、私たちのアプリケーションがあります。 実際に機能しています。 しかし、それは私たちがここにいる目的ではありません。 私たちは、Dockerで実行し、Kubernetesでも実行できるようにするためにここにいます。
OCIイメージとしてのパッケージ
では、私たちはどこにいるのでしょうか? さて、Wasmアプリケーションを構築してコンパイルしました。 次に、OCIイメージとしてパッケージ化します。 Dockerで実行し、Docker Hubにプッシュします。 では、DockerのDockerですよね? WebAssemblyでも。 そして、何かを構築するために、DockerはDockerfileが本当に好きですが、私はまだ持っていません。 したがって、ここでは、アプリケーションのルートディレクトリに新しいDockerfileを作成します。 そして、Dockerfileが含まれているGitHubリポジトリにジャンプします。 さて、見てください、私たちはDockerConにいますよね? そして、たくさんのセッションに行くと、目が血を流したくなるような巨大なDockerfileが表示されます。 まあ、ここでは最先端のもの、WebAssemblyなど、何でも揃っていますよね? したがって、これは複雑なDockerfileになると思います。 なんということ。 私は、おそらく今日ここDockerConで目にする最も簡単で単純なDockerファイルだと思います。 そこで、このテキストをすぐにファイルにコピーします。 そして、私たちは、通常のようにLinuxベースイメージからビルドする代わりに、これはWebAssemblyアプリであると言っています。 それは何も必要ありません。 空のスクラッチイメージから構築します。 そして、私たちがやっているのは、コピーしているだけです。
さて、これは重要です。 ここでは、ビルドされたWebAssemblyバイナリをコピーしています。 そして、それをコンテナのルートフォルダにコピーしています。 大丈夫です。 これは、spin.tomlをすぐに編集する必要があるため、重要になります。 しかし、spin.tomlでもコピーしています。これは、Kubernetesで実行するときにランタイムに指示を与えることになるからです。 このアプリケーションを実行する正確な方法。 だから、ええと、ああ、私はコピーボタンを利用できるようにするには大きすぎました。 ですから、それをここにコピーすれば、とても簡単に、それは保存されます。 また、spin.toml ファイルを変更する必要があります。これは、コンテナで見たように、WebAssembly バイナリをコンテナのルートフォルダにコピーしているからです。 ここでは、この長い道のりは必要ない。 つまり、dockercon.wasmという名前だったのです。 それに対する変更を保存すると、dockerビルドを実行する準備が整います。
さて、docker buildxを使用します。 大丈夫です。 buildx を実行する必要はありません。 最新バージョンのDockerDesktopでdockerbuildを実行することもできますが、古いバージョンなどを実行している場合に備えて、ここではbuildxを使用します。 ここには、まだ見ていないかもしれない新しい旗があります - このプラットフォームのwasi/wasmフラグです。 これは、イメージにメタデータを書き込み、アーキテクチャがこれであり、オペレーティングシステムがそれであると言うことになります。 そして、docker runなどのツールは、実行時にこれを参照し、適切な環境を構築するのに役立ちます。 次に、画像にタグを付けています...しかし、私はそれをタグ付けしたいです。 後でDocker Hubにプッシュします。 Docker HubのユーザーIDはNigel Poultonなので、そのように名前を付けました。 だから、それを作ろう、そしてそれはすでに作られているのだから、そうすべきですよね?
基本的に、私たちが行っているのは2つのファイルをコピーすることだけです。 そのうちの1つは本当に小さなWebAssemblyバイナリで、もう1つは設定ファイルでした。 だから、一番上に戻ると、これは線を越えて折り返すことになりますよね。 しかし、Dockerイメージでは、私はそれを何と呼んでいましたか? だから。 大丈夫です。 だから私はいくつかの行の折り返しを持っていますが、これはここでのDockerイメージです。 そして、半分のメガですよね? 最初に言ったわけではなく、あるいは暗示していたのかもしれませんが、クラウドコンピューティングの第2の波としてコンテナが登場したとき、コンテナは仮想マシンよりも小さく、高速で、移植性に優れていました。 WebAssemblyは、従来のLinuxコンテナよりも小さく、高速で、移植性が高く、安全です。
つまり、コンテナイメージとして、 500k、素晴らしいです。 大丈夫です。 さて、Dockerイメージとしてパッケージ化されたので、docker runで実行できます。 ええと、コンテナをdockerconと呼ぶことにします。 もちろん、繰り返しになりますが、私たちはDockerConに参加しています。 ここでのランタイムフラグは、「よし、これはちょっと特別だ」と言っています。 これは従来のLinuxコンテナではありません。 ですから、containerdさん、これを実行するときは、runCを使用してカーネルと通信し、名前空間を構築し、フォーク、処理、およびそこでアプリを起動し、別のランタイムと対話するようにお願いします。 ここではplatform=wasi/wasmも指定していますが、そうする必要はありません。
これを本当に簡単にやらせてください。 docker inspectを実行して、ここでイメージのIDを取得するだけです。これをお見せしたかっただけです。 はい。 ですから、イメージを構築したとき、フラグの 1 つであるプラットフォーム フラグがアーキテクチャと OS を設定すると言いました — docker run はこれを読み取ることができます。 これをdocker runコマンドラインで実際に指定する必要はありません。 ただし、完全を期すために、ここで正しいdocker runコマンドがあることを確認してください。 そうです。 ここでは、私のラップトップのポート 5005 でアプリケーションを公開し、正しいものを参照しています。
だから、私がただdocker runに行くと、ああ、いや、私はあなたに何を教えるでしょう、私はpsをdockerします。 これは、多くの行の折り返しです。 もっと簡単にやれる方法を教えてくれる人がいるのはわかりますが、ステージに立っているときのタイピングは衝撃的です。 これは君たちが見なくても問題ないと思う。 はい。 それが1つです。 したがって、そのdockerrunコマンドを再度実行すると。 コンテナがあります。 今、ポート 5005に行くと、ローカルホスト 5005だったと思います。 そして、また超小型化。 大きくしましょう。 OCIイメージとしてパッケージ化され、Dockerコンテナとして実行される同じWebAssemblyアプリケーション。 とても簡単で、私にもできた。 素晴らしい、進歩。
実際にKubernetes上でも実行したいと考えています。 そのために、これを少し大きくして、みんなが再び見えるようにするつもりです。 Docker Hubにプッシュします。 繰り返しますが、通常のdocker pushコマンドです。 会議Wi-Fiとはいえ超小型で衝撃的です。 それは非常に迅速に到着するでしょう。 今すぐDocker Hubに移動してこのページを更新すると、spinという新しいイメージが表示されます。 さあ始めます。 そして、オペレーティングシステムのアーキテクチャwasi / wasmができました。 そして約 500 メガ。 そのため、Docker Hubにも掲載されています。 そして、ここで正しく理解すべきポイントは、私がこれを強調しすぎていることを知っているということです。 私はRustの開発者ではありません。 ええ、私はDockerについて少し知っています。 しかし、これらはここでDockerを使用して作業している通常のコマンドにすぎません。 WebAssemblyには、これまでのところ新しいものはなく、組織に所属している場合や、これらのツールの学習とデプロイに多くの時間と労力を費やし、スタッフがこれらのツールを使用するために多くの時間と労力を費やしている個人である場合、これは非常に強力なものになる可能性があります。
Kubernetes クラスターを構築する
これでDocker Hubにプッシュされたので、Kubernetesクラスタを構築する準備が整いました。 ここでは、この部分についてすぐに説明します。 k3d を使用してクラスターを構築しますが、これはラップされていますのでご安心ください。 実行中のコマンドを示すスライドがあります。 会議のWi-Fiがどれだけの時間がかかるかわからないので、これを始めます。 それがなくなると、PowerPointに戻ります。 これがここで実行しているコマンドです。
つまり、K3Dは、Docker内で実行されるKubernetesの非常に小さなディストリビューションです。 マシンにDocker Desktopがあれば、マルチノードのKubernetesクラスターをローカルでスピンアップするのは非常に簡単です。 コマンドは基本的にk3d cluster createと言っているので、それをwasmと呼ぶことにします。 これにより、単一のコントロールプレーンノードを持つ小さなKubernetesクラスターが実現します。 コントロールプレーンとワーカーノードを構築するイメージを指示しています。 そして、ラップトップのポート 8081 からこのクラスタ内のアプリケーションにアクセスできるようにしたいと言います。 また、ワーカーノードも2つ取得できますか?
右側には、実際に何が得られるかの写真があります。 重要なことは、このイメージには、KubernetesワーカーノードにすでにブートストラップされたすべてのWasmのものが付属していることです。 したがって、ここで構築しているこのクラスターにWebAssemblyのものをインストールする必要はありません。 私たちはそれを検査し、舞台裏で何が起こっているのかを確認します。 ただし、既存のKubernetesクラスターがあり、ランタイムやshimなどのWebAssemblyサポートを追加したい場合は、既存のKubernetesクラスターがある場合は、Kwasmプロジェクトを確認することをお勧めします。
今、これは私にとって真実の瞬間のようなものです。 このクラスターは会議の Wi-Fi 上に構築されていますか? ちょっとシュレディンガーの猫っぽい感じがしますよね? それは、私たちがそれを観察するまで、つまり波動関数を崩壊させるまで、死んでいると同時に生きているのです。 そこで、その波動関数を崩壊させようとしているかどうかを見てみようと思っていますが、今は成功裏に構築されています。 これも失敗し、まだ構築を試みています。 では、実際には何が起こるのでしょうか? ブーム!ここに戻ってきました。 そこでは量子物理学に拍手喝采が送られました。 それに感謝します。 したがって、kubectl get nodesを実行すると、3ノードクラスタが必要になります。 1 つのプレーン ノードと 2 つのワーカー ノード。 次に、WebAssembly の構成に進みます。
では、すぐにスライドに戻ります。 先ほど、Kubernetesは超高レベルのオーケストレーターであり、コンテナの構築、開始、停止といった低レベルの作業を他のツールに依頼すると言いました。 つまり、Kubernetesは天国やどこにでも存在し、怠惰なのです。 それは、コンテナを作りたくない、というようなものです:containerd、あなたは私のためにそれをします。 また、containerd は containerd と呼ばれていますが、コンテナを起動することはできません。 だから、よし、じゃあ、他の誰かに始めてもらおう、っていうんだ。 これは基本的なKubernetesのものです、いいですか? ただし、runC と呼ばれる低レベルのランタイムと通信します。 だからrunC、名前空間やCgroupなどを構築するという恐ろしいカーネル作業を行って、コンテナをポップしてください。 そして、runCは仕事を終え、休息を取りたいと思っています。 そこで、シムを起動すると、シムは基本的に実行中のコンテナの間に座り、コンテナをループ上に保持します。 また、containerd がコンテナを停止または再起動したい場合は、shim と通信できます。 瓌。 基本的なKubernetesのもの。 ただし、この図の containerd のすべては Kubernetes に対して不透明です。 つまり、Kubernetesは下を見ることができないか、下にあるものを気にしません。 そして正直なところ、シムの下では、containerdでさえ実際にはそれを見ていません。 つまり、この種のアーキテクチャは、runCをまったく異なるものに置き換えることができるということです。 Kubernetesは知らないし、気にもしません。 containerdはほとんど知らないか、気にしません。 だから、ワズムシムを入れることができます。
ワズムシム
さて、WasmシムのアーキテクチャはrunCとは少し異なります。 写真が撮れましたよね? つまり、Wasmシムには2つの主要なコンポーネントがあります。 このコードはrunwasiと呼ばれ、基本的に左側のcontainerdとインターフェースするRustライブラリです。 私の権利です。 そこには、WebAssemblyランタイムという別のソフトウェアがあります。 そして、それが実際にWebAssemblyホストを起動し、WebAssemblyアプリケーションなどを起動するものです。 現在、runwasi は公式の containerd プロジェクトです。 だから、これはすべて合法的なものです。 私はこれをとても誇りに思っていますよね? そのルンワシのロゴをデザインしました。 恥ずかしいプラグですが、私はそれが大好きです。 私は開発者ではないので、コミュニティに貢献できるさまざまな方法が大好きです。 そして、ロゴを作りました。 いずれにせよ、containerdを使ったWebAssemblyのものに対しては、常にrunwasiです。 ですから、世の中にはたくさんの異なるものがあります。 ここでは spin ランタイムを使用しています。 大丈夫です。
これが基本的なアーキテクチャです。 さて、この図に戻りましょう。 WebAssembly アプリケーションがポップされます。 基本的にはそういうものです。 したがって、実際には、ここに戻ると、ワーカーノードの少なくとも1つにWebAssemblyランタイムがあることを確認します。 それで、私はコマンドラインに戻りました。 この 3 ノード クラスターがあります。 そして、私は「はい、docker exec」と言います。 そして、エージェント1と呼ぶことにします。 そこで、そこに砲弾を取り付けます。 そして、それを一番上に載せます。 まず、containerdが実行されていることを確認する必要があります。 大丈夫です。 だから、ここにコンテナがあります。 それが実行されているのです。 次に、このマシンにWebAssemblyシムがあることを確認する必要があります。 したがって、lsは、通常、binディレクトリにインストールされます。 また、常に containerd-shim プレフィックスが付きます。 大丈夫です。
つまり、このマシンには5つのシムがあることがわかります。 RunC は、Linux コンテナを実行するためのデフォルトのものです。 他の4つはWebAssemblyシムです、いいですか? そして、私たちが気にしているのは、素晴らしいスピンシムです。 ただし、そのディレクトリにインストールするだけでは十分ではありません。 ああ、この次のコマンドを入力する必要があるのは本当に長いパスがあります、いいですか? これらの shim が containerd に登録されているか、containerd 設定ファイルに存在することを確認する必要があります。 これは通常/etcにあります。 しかし、k3d クラスターでは、ファイルシステムの深さは約 1000 層です。 つまり、var の中にあるのです。 これを正しく理解すれば、私はとても誇りに思うでしょう: var/lib/rancher/k3s/agent/etc/containerd/config.toml、 瓌。 設定ファイルの下部も見てください。 ここには 4 つの WebAssembly ランタイムがあり、containerd 設定ファイルで参照されていますが、一番上にあるこの 1 つ、スピン ランタイムに興味があります。 工場。 時間の都合上、いいですか? 私は、それがロードされていることを確認するためだけにアクティブなcontainerd構成をダンプする別の超長いコマンドを持っています。 私を信じてください、それはロードされています。
現在、3ノードのKubernetesクラスタがあります。 WebAssembly shim があり、その中に WebAssembly ランタイムがあります。 Docker HubにWebAssemblyアプリケーションをロードしています。 Kubernetesクラスターでこのアプリケーションを実行する準備がほぼ整いました。 しかし、あなたは何を知っていますか? 実際に今すぐにでも実行できます。 このクラスターでは、コントロールプレーンノードを含むすべてのノードがまったく同じ設定であるため、すべての containerd が実行され、すべてのスピンシムが実行されています。
現実の世界では、一部のノードでは一部の Wasm シムがオンになり、一部のノードでは Wasm シムがオンになっておらず、一部のノードでは他の Wasmシムがオンになっているという、より異種ノード構成になる可能性があります。 したがって、このような状況では、Kubernetesノードにラベルを付けて、作業を正しいノードにスケジュールできるようにする必要があります。 今、私たちはそのエージェント-1 がワズムシムをつけていることを知っています。 他のものもそうですが、私たちはまだやってきたばかりで、この1つがそうであることを確信しています。 したがって、kubectlラベルを実行するとします。 さあ行こう。 さて、agent-の1、そして私たちはただwasm=yesラベルを追加するつもりです。 あなたが望むどんなラベルでも、それは問題ではありません。 そのため、そのノードにラベルを付けました。 さて、最後に必要なのはランタイムクラスです。 ここにはまだ何もないことを確認します、kubectl get runtime class。 私は本当にこのランタイムクラスに短い名前があればいいのにと思います。 それは正しいようです。 大丈夫です。 ランタイムクラスはまだありません。 古いPowerPointで非常に迅速に。 3 ノード クラスタがあります。 私たちは、 spin, WebAssembly shim on runtime が agent-1で実行されていることを知っています。 私たちはそれをラベル付けしました。 次に、ランタイムクラスを追加しています。
ここで、ランタイム クラスは 2 つのことを行います。 そのラベルを持つノードを選択します。 つまり、黄色の上の白いテキストはここでは良くありません - wasm=yesラベルを持つ任意のノードに作業を選択または送信またはスケジュールすると言っています。 しかし、作業をcontainerdに渡すときは、runCシムの代わりにスピンシムを使用するように指示してください。 瓌。 大丈夫です。 つまり、アプリケーションをデプロイできるということです。 すぐにdeployment.ymlファイルで確認できます。 これはこのランタイム クラスを参照し、アプリケーションはノードにデプロイされます。 残り8分。 ああ、私は時間を超えて走るつもりはないと言いましたし、時間を超えて走るつもりもありません。
ただし、ここではコマンドラインに直行します。 それを手に入れたので、ランタイムクラスが必要です。 そして、それはここにあります。 こちらのGitHubリポジトリに1つあります。 rc.yaml と呼ばれます。 そして、ご覧の通り、私はそれを貼り付けるつもりです。 このテキストは、ランタイムのファイルに貼り付けると少し大きくなります。 だから、私がvim rc.yamlに行くなら。 おっと。 そして、そこに貼り付けます。 基本的に、名前が付けられていることがわかります。 それはrcスピンと呼ばれています。 これについては、この後すぐにデプロイメントファイルで参照します。 これは、スピンシムが作業を実行していることを確認し、wasm=yes を持つ任意のノードにそれを送信します。 ファブローゾ。
これで、ランタイム クラスが作成されました。 次に、アプリケーションファイルを作成する必要があります。 だから、私がvim app.yamlに行くなら。 そして、ここでGitHubに戻ると、ここにapp.yamlファイルがあることがわかります。 すぐに説明します。 右。 大丈夫です。 Kubernetesについてあまり知らないと、これは恐ろしいことに見えるでしょう。 そうではありません。 基本的には「いいよ」と言っているのです。 これが私たちのアプリケーションです。 Docker Hubにアップされています。 それをイメージと呼んでいます。 Kubernetesクラスターで3つのコピーを取得できますか? そして、Kubernetesをスケジュールするとき、それは特別なものであるため、Wasmアプリケーションです。 作成したランタイムクラスのルールに従ってスケジュールします。 したがって、エージェント1 し、WebAssembly shim、つまり spin shim がそれを実行していることを確認します。
ここには、私が立ち入らないものがいくつかあります。 これにより、接続できるようになります。 したがって、そのファイルを保存してkubectl apply -f app.yamlを実行すると、これがアプリケーションをKubernetesにデプロイする方法です。 そして、デプロイが作成されたことがわかります。 サービスが作成され、イングレスが作成されました。 そして、kubectl get deployを実行すると、3つのレプリカが表示されるはずです。
ああ、ああ。 ランタイムクラスを適用しませんでした。 ああ、誰かが見ている。 それが大好きです。 さて、それではkubectl deleteを実行します。 本当にありがとうございました、なぜなら、ステージ上でのライブでは、時計が点滅しているときにそれをトラブルシューティングするつもりはなかったからです。 だから、きれいにするために、最初にこれを削除するつもりです。 ええと、kubectl apply、apply。 ええと、ランタイムクラスです。 それは崩壊しています。 そうではありません。 私はそれを保存しなかったのですか? 大きく。 ああ、アプリのチームワーク。 私の好みです。 輝かしい。 さて、アプリをデプロイしたものを見つけましょう。 あ それが1つです。 右。 いや、あれでもあれでもない。 これ。 右。 さて、kubect get deploy。 すでに3つが稼働しています! それを取り戻してください。 あなたはそこで自分自身に拍手を送っています。 拍手しているのは私であるべきです。
これで、アプリケーションは実行されています。 私が確認したいのは、kubectl get pods -o wideを実行すると、見ることができるはずだということです。 ラップされているので見づらいですが、それらはすべてエージェント1で実行されています。 したがって、ランタイム クラスとラベルはその役割を果たしました。 正しいノードに送信されました。 だから、ここでブラウザに戻ったら。 これを失おう。 そして、私がローカルホストに行くと、それはyoフラグに 8081 されました。 [更新] をクリックした場合。 それはやった。 Dockerで実行するため、すでにそこにありましたが、今回はKubernetesクラスターと通信しています。 これはKubernetes上で実行されており、残り3分半で完了します。
だから、すぐにリキャップするんだ。 たくさんの観客の助けを借りて。 ありがとうございます。 感謝します。 そして、Dockerのクールなものがたくさんあります。 フェルミヨンのクールなものがたくさんあります。 containerdの人々からのたくさんのクールなもの。 非常に単純なソースコードを取りました。 WebAssembly バイナリとしてコンパイルしました。 それをプッシュしたか、ある意味でコンテナ化しました。 コンテナイメージにしました。 Docker Hubにプッシュしました。 Wasmアプリを実行するKubernetesクラスターを構築して構成しました。 そして、実際にWasmアプリを実行しました。 これがデモです。 そして、初めて難しそうに思えた方は、後でリプレイでもう一度見てみてください。 GitHub リポジトリに移動します。 自分でやってください。 あなたはそれが難しくないことを本当に理解するでしょう。
質疑応答
どなたかご質問はありますか? そして、もしそうなら、マイクの1つに走って大声で話してください。 真ん中にこいつがいるんだ。 できるだけ早く。 そして、その後時間があれば、あなたのところに行きます。 マイクで素敵に、そして大声でお願いします。
素晴らしいデモ。 したがって、実際には、Kubernetesはcontainerd以下で実行されるものについて何も知りませんでした。 しかし、あなたはまだランタイムクラスを作成する必要がありましたか?
そこで問題となったのは、KubernetesがWebAssemblyについて知らないのに、なぜKubernetesでランタイムクラスを作成しなければならなかったのかということでした。 基本的には、スケジューリングを支援し、そのWebAssemblyのワークロードを確認するためのものです。 私はこの質問に答えていないような気がします。
では、これらのコンテナを別のノードにスケジュールしたくない場合は、ランタイムクラスを作成する必要はありませんか?
ええ、ですから、別のノードでスケーリングしたい場合は、別のノードにラベルを付けるだけで済みます。
これらのノードでスケジュールするには、ラベルを付ける必要があります。 つまり、その必要がない場合、コンテナがすでにすべてのノードで構成されている場合です。
はい。 したがって、私の例では、containerdは3つのノードすべてにWasmシムを持っているため、それを行う必要はありませんでした。 いいえ、もちろんです。 その他の質問
さて、問題はなぜですか? それを明確にするために、WebAssemblyとDockerがあります。 これらは両方とも移植性のために設計されており、私はただ、冗長な達成方法とは対照的に、なぜこれらが相乗効果があるのかを理解しようとしています。
ですから、今日は4時5分に来てください、なぜなら、私たちはパネルディスカッションでそのようなことについて話すつもりだからです。 しかし、私はそれについてあなたに挑戦するつもりです。 私はDockerとコンテナが大好きですが、移植できるようには設計されていません。 コンテナをビルドすると、OS と CPU アーキテクチャに固定されます。 コンテナは小さいため、ポータブルと呼んでいます。 レジストリとノード間では、VM よりもコピーが簡単です。 しかし、それは移植性ではありません。 つまり、WebAssemblyは、ランタイムがどこにでもある限り、どこでも実行できますが、コンテナ、はい、Container Build Toolsを使用すると、複数のプラットフォーム向けに簡単にビルドできます。 しかし、複数のアーキテクチャがある場合は、複数のイメージが必要です。 そのため、画像のスプロール現象が少し発生します。
正直、皆さん、本当にありがとうございました。 私たちは時間通りに釘付けになっています。 本当に感謝します。 あなた自身に拍手を送ります。 ありがとうございます。
さらに詳しく
- Docker + Wasm Technical Preview 2 の発表
- デスクトップ上に Kubernetes 対応アプリケーションを構築する
- Docker デスクトップの最新リリースを入手します。
- 質問がありますか? Docker コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。
自分に合ったサブスクリプションを見つける
今すぐ専門家に連絡して、Dockerサブスクリプションのコラボレーション、セキュリティ、サポートの完璧なバランスを見つけてください。