👨‍👨‍👧‍👦 🙉 🤧 k8sのパッケージとパッケージマネージャー 😐 🚧 👩‍🏫

私たちは皆、ある種のパッケージマネージャーを使用しています。その中には、クリーニングレディのAunt Galyaも含まれています。ただし、パッケージマネージャーの機能に関する一般的な合意はなく、標準のrpmおよびdpkg OSとビルドシステムはパッケージマネージャーと呼ばれます。私たちは、彼らの機能のトピックについて考えることを提案します-それが何であり、なぜ現代世界で必要なのか。そして、Kubernetesに向かって掘り下げ、これらの機能に関してHelmを慎重に検討します。

この図でテンプレート機能のみが緑色で強調表示されている理由と、アセンブリとパッケージング、環境の自動化などの問題を見てみましょう。しかし、心配しないでください、記事はすべてが悪いという事実で終わるわけではありません。コミュニティはこれに同意できず、代替ツールとソリューションを提供します-私たちはそれらに対処します。

Ivan Glushkov （ gli ）は、この詳細なプレゼンテーションのビデオおよびテキスト版であるRIT ++に関する彼のレポートでこれを手伝ってくれました。

RIT ++でのこのビデオおよびその他のDevOpsスピーチのビデオは公開されており、 YouTubeチャンネルで無料で視聴できます。作業上の質問に対する回答を探してください。

スピーカーについて： Ivan Glushkovは15年間ソフトウェアを開発しています。私はMZ、Echoでコメント用のプラットフォームで働いて、MCSTのElbrusプロセッサ用のコンパイラの開発に参加しました。彼は現在、Postmatesのインフラストラクチャプロジェクトに関与しています。 Ivanは主要なDevZenポッドキャストの1つであり、会議について説明しています。ここではRIT ++について、ここではHighLoad ++について説明します。

パッケージマネージャー

誰もが何らかのパッケージマネージャーを使用していますが、それが何であるかについての単一の合意はありません。共通の理解があり、それぞれに独自の理解があります。

どのタイプのパッケージマネージャーが最初に思い浮かぶのか思い出してみましょう。

すべてのオペレーティングシステムの標準パッケージマネージャー： rpm、dpkg、portageなど
さまざまなプログラミング言語のパッケージマネージャー： cargo、cabal、rebar3、mix 、...

主な機能は、パッケージのインストール、パッケージの更新、パッケージのアンインストール、および依存関係の管理のためのコマンドを実行することです。プログラミング言語内のパッケージマネージャーでは、事態はもう少し複雑です。たとえば、「パッケージの起動」や「リリースの作成」（ビルド/実行/リリース）などのコマンドがあります。これは既にビルドシステムですが、パッケージマネージャーとも呼ばれています。

これはすべて、あなたがそれをただ取ることができないという事実によるだけです...そして、Haskell愛好家にこの比較を許させてください。バイナリファイルは実行できますが、HaskellまたはCでプログラムを実行することはできません。最初に何らかの方法で準備する必要があります。そして、この準備はかなり複雑であり、ユーザーはすべてが自動的に行われることを望んでいます。

開発

多数のコンポーネントで構成される大規模プロジェクト用に作成されたGNU libtoolを使用した人は、サーカスを笑わない。それは本当に非常に難しく、いくつかのケースは原則的に解決できず、回避することしかできません。

それに比べて、Rustの貨物のような最新のパッケージ言語マネージャーははるかに便利です。ボタンを押すだけですべてが機能します。実際には、内部では多くの問題が解決されています。さらに、これらのすべての新しい機能には、特にデータベースなどの追加機能が必要です。パッケージマネージャー自体では任意の名前を付けることができますが、データベースと呼んでいます。データはそこに保存されます：インストールされたパッケージ、それらのバージョン、接続されたリポジトリ、これらのリポジトリのバージョンについて。これらはすべてどこかに保存する必要があるため、内部データベースがあります。

このプログラミング言語での開発、このプログラミング言語のテスト、開始-すべてが組み込まれ、内部にあるため、 作業は非常に便利になります 。ほとんどの現代言語はこのアプローチをサポートしています。支持しなかった人でさえ、支持を始めます。なぜなら、コミュニティは、現代世界ではそれなしでは不可能だと主張しているからです。

しかし、どのソリューションにも常に利点があるだけでなく、欠点もあります。ここでの欠点は、ラッパー、追加のユーティリティ、および組み込みの「データベース」が必要なことです。

Docker

Dockerはパッケージマネージャーであると思いますか？

どんな方法でも、基本的にははい。アプリケーションをすべての依存関係と完全に組み合わせて、ボタンをクリックするだけで機能させるための、より正確なユーティリティは知りません。パッケージマネージャーでない場合、これは何ですか？これは素晴らしいパッケージマネージャーです！

マキシム・ラプシンは、すでにDockerを使用することではるかに簡単になったと述べています。 Dockerには、組み込みのビルドシステム、これらすべてのデータベース、バインディング、ユーティリティがあります。

すべての特典の価格はいくらですか？ Dockerを使用する人は、産業用アプリケーションについてほとんど考えません。私はそのような経験があり、実際に価格は非常に高いです：

Dockerイメージに保存する必要がある情報の量 （イメージサイズ）。すべての依存関係、ユーティリティの一部、ライブラリを内部にパックする必要があります。イメージは大きく、それを操作できる必要があります。
パラダイムシフトが行われていることは、はるかに複雑です。

たとえば、1つのプログラムを転送してDockerを使用するタスクがありました。プログラムはチームによって長年にわたって開発されました。私は来ます、私たちは本に書かれているすべてをします：私たちはユーザーの物語、役割を描き、彼らが何をどのように行うか、彼らの標準的なルーチンを描きます。

私は言う：

-Dockerはすべての問題を解決できます。これがどのように行われるかを見てください。

-すべてがボタンに表示されます-すばらしい！しかし、Kubernetesコンテナ内でSSHを実行したいと考えています。

-待て、SSHはどこにもありません。

-はい、はい、すべてがうまくいきます...しかし、SSHは可能ですか？

ユーザーの認識を新しい方向に変えるには、多くの時間がかかり、教育作業と多大な努力が必要です。

もう1つの価格要因は、 Dockerレジストリがイメージの外部リポジトリであり、何らかの方法でインストールおよび制御する必要があることです。独自の問題、ガベージコレクターなどがあり、これに従わない場合はしばしば落ちますが、これはすべて解決されます。

クベルネテス

やっとKubernetesに着きました。これは、コミュニティによって積極的にサポートされているクールなオープンソースのアプリケーション管理システムです。元々は1つの会社を辞めていましたが、Kubernetesには巨大なコミュニティがあり、それに追いつくことは不可能であり、実質的に代替手段はありません。

興味深いことに、すべてのKubernetesノードはコンテナを介してKubernetes自体で動作し、すべての外部アプリケーションはコンテナを介して動作します。すべてがコンテナを介して動作します 。これはプラスとマイナスの両方です。

Kubernetesには、分散性、フォールトトレランス、さまざまなクラウドサービスと連携する機能、マイクロサービスアーキテクチャに焦点を当てた機能など、多くの便利な機能とプロパティがあります。これらはすべて面白くてクールですが、Kubernetesにアプリケーションをインストールする方法は？

アプリケーションのインストール方法は？

Docker-registryにDockerイメージをインストールします。

このフレーズの背後には深aがあります。想像してください。たとえば、Rubyで記述されたアプリケーションがあり、DockerレジストリにDockerイメージを配置する必要があります。つまり、次のことを行う必要があります。

Dockerイメージを準備する
それがどのバージョンに基づいているのかを理解します;
それをテストすることができます;
収集し、以前にインストールしたDocker-registryに入力します。

実際、これは1行で大きな、大きな痛みです。

さらに、アプリケーションマニフェストをk8の用語（リソース）で記述する必要があります。最も簡単なオプション：

展開+ポッド、サービス+イングレス（おそらく）を説明します。
kubectl apply -f resources.yamlコマンドを実行し、すべてのリソースをこのコマンドに転送します。

ガンジーはスライドを手でこすります-Kubernetesでパッケージマネージャーを見つけたようです。ただし、kubectlはパッケージマネージャーではありません。彼は、私がこのようなシステムの最終状態を見たいと言っているだけです。これはパッケージをインストールしたり、依存関係を処理したり、ビルドしたりするのではなく、単に「この最終状態を見たい」だけです。

ヘルム

ついにヘルムに来ました。 Helmは多目的ユーティリティです。ここで、Helmの開発のどの領域を検討し、Helmと協力します。

テンプレートエンジン

まず、Helmはテンプレートエンジンです。どのリソースを準備する必要があるかを話し合いましたが、問題はKubernetesの観点から（そしてyamlだけでなく）書くことです。最も興味深いのは、これらがこの特定の環境における特定のアプリケーションの静的ファイルであることです。

ただし、複数の環境で作業し、本番環境だけでなく、ステージング、テスト、開発、および異なるチームの異なる環境がある場合、いくつかの同様のマニフェストが必要です。たとえば、それらの1つには複数のサーバーがあり、多数のレプリカが必要であり、もう1つには1つのレプリカしか必要ないためです。データベースがなく、RDSにアクセスできないため、内部にPostgreSQLをインストールする必要があります。そして、ここには古いバージョンがあり、すべてを少し書き直す必要があります。

このすべての多様性は、Kubernetesのマニフェストを取得し、どこでもコピーして、すべての場所で修正する必要があるという事実につながります。ここで1桁を置き換えてください。これは非常に不快になりつつあります。

解決策は簡単です。 テンプレートを入力する必要があります。つまり、マニフェストを作成し、その中に変数を定義してから、外部で定義された変数をファイルとして送信します。テンプレートは最終的なマニフェストを作成します。すべての環境で同じマニフェストを再利用することが判明したため、はるかに便利です。

たとえば、ヘルムのマニフェスト。

Helmの最も重要な部分はChart.yamlです 。これは、それがどのようなマニフェストであるか、どのバージョン、どのように機能するかを記述しています。
テンプレートは、Kubernetesリソーステンプレートであり、その中にある種の変数が含まれています。これらの変数は、外部ファイルまたはコマンドラインで定義する必要がありますが、常に外部で定義する必要があります。
values.yamlは、これらのテンプレートの変数を含むファイルの標準名です。

chartをインストールするための最も単純な起動コマンドは、helm install ./wordpress（フォルダー）です。一部のパラメーターを再定義するには、「これらのパラメーターを正確に再定義し、そのような値を設定したい」と言います。

Helmはこのタスクに対応しているため、図では緑色でマークしています。

確かに、短所が表示されます：

冗長性 。リソースはKubernetesの観点から完全に定義されており、追加の抽象化レベルの概念は導入されていません。Kubernetesに書きたいものをすべて書き、そこで変数を置き換えます。
繰り返してはいけません-適用されません。 多くの場合、同じことを繰り返す必要があります。異なる名前の2つの類似したサービスがある場合、フォルダー全体を完全にコピーし（ほとんどの場合これを行う）、必要なファイルを変更する必要があります。

これをすべて説明するパッケージマネージャーであるHelmの方向に突入する前に、Helmが依存関係でどのように機能するかを見てみましょう。

依存関係を扱う

Helmは依存関係を扱うのが困難です。まず、依存するものに適合するrequirements.yamlファイルがあります。要件を処理しながら、彼はrequirements.lockを実行します。これは、すべての依存関係の現在の状態（ナゲット）です。その後、彼はそれらを/ chartsというフォルダーにダウンロードします。

管理するツールがあります：誰が、どのように、どこに接続するか- タグと条件 、どの外部パラメータに応じて、どの環境で、どの依存関係に接続するか、接続しないかを決定します。

ステージング環境用のPostgreSQL（または本番用のRDS、テスト用のNoSQL）があるとします。このパッケージを本番環境にインストールすると、PostgreSQLはインストールされません。タグと条件を使用するだけで、PostgreSQLはそこに必要ないからです。

ここで面白いのは何ですか？

Helmは、すべての依存関係とアプリケーションのすべてのリソースを混合します。
ソート->インストール/更新

/チャート内のすべての依存関係（これらの依存関係は、たとえば100）をダウンロードした後、Helmは内部のすべてのリソースを取得してコピーします。テンプレートをレンダリングした後、彼はすべてのリソースを1か所に集め、自分の順序で並べ替えます。この順序に影響を与えることはできません。パッケージが何に依存しているかを自分で判断する必要があります。パッケージに推移的な依存関係がある場合は、requirements.yamlの説明にそれらすべてを含める必要があります。これに留意する必要があります。

パッケージマネージャー

Helmはアプリケーションと依存関係をインストールし、Helmのインストールを指示できます-そして、パッケージをインストールします。これがパッケージマネージャーです。

同時に、パッケージをアップロードする外部リポジトリがある場合は、ローカルフォルダーとしてではなく、「このリポジトリからこのパッケージを取得し、そのようなパラメーターでインストールします」と言うだけでアクセスできます。

多くのパッケージを備えたオープンなリポジトリがあります。たとえば、次のコマンドを実行できます。helm install -f prod / values.yaml stable / wordpress

安定したリポジトリからwordpressを取得し、自分でインストールします。検索/アップグレード/削除のすべてを実行できます。実際、Helmはパッケージマネージャーです。

ただし、短所もあります。すべての推移的な依存関係を内部に含める必要があります。これは、推移的な依存関係が独立したアプリケーションであり、テストと開発のためにそれらを個別に操作したい場合に大きな問題です。

もう1つのマイナス点は、 エンドツーエンド構成です。データベースがあり、その名前をすべてのパッケージに転送する必要がある場合、これは可能ですが、実行するのは困難です。

多くの場合、1つの小さなパケットをインストールすると動作します。世界は複雑です。アプリケーションはアプリケーションに依存し、アプリケーションもアプリケーションに依存します。それらを何らかの形で巧みに構成する必要があります。 Helmはこれをサポートする方法を知らないか、大きな問題を抱えてサポートしています。また、動作させるためにタンバリンでたくさん踊らなければならない場合もあります。これは悪いので、図の「パッケージマネージャー」は赤で強調表示されます。

組み立てと包装

Kubernetesでアプリケーションを取得して実行することはできません。それをアセンブルする必要があります。つまり、Dockerイメージを作成し、Dockerレジストリに書き込むなどです。 Helmのパッケージの定義全体はそうですが。パッケージが何であるか、どの機能とフィールドがそこにあるべきか、署名と認証を決定します（会社のセキュリティシステムは非常に満足しています）。そのため、一方ではビルドとパッケージングがサポートされているように見えますが、他方ではDockerイメージの処理は構成されていません。

Helmでは、Dockerイメージなしでアプリケーションを実行することはできません。同時に、Helmはアセンブリおよびパッケージング用に構成されていません。つまり、実際には、Dockerイメージを操作する方法がわかりません。

これは、小さなライブラリのアップグレードインストールを行うために、コンパイラを実行するために離れたフォルダに送信される場合と同じです。

したがって、Helmは画像の操作方法を知らないと言います。

開発

次の頭痛は開発です。開発では、コードを迅速かつ便利に変更したいと考えています。パンチカードに穴を開けた時が過ぎ、5日後に結果が得られました。編集者がエディターで1つの文字を別の文字に置き換えることに慣れているので、コンパイルを押すと、既に変更されたプログラムが機能します。

ここで、コードを変更する場合、追加のアクションが多く必要であることがわかります。Dockerファイルを準備します。 Dockerを実行して、イメージを構築します。どこかにプッシュする。 Kubernetesクラスターにデプロイします。そして、あなたがプロダクションで欲しいものを手に入れて、コードをチェックすることができます。

破壊的な更新ヘルムのアップグレードによる不便さが依然としてあります。 kubectl execを使用して、すべてがどのように機能するかを確認し、コンテナ内を確認しました。すべてが正常です。この時点で、更新を開始し、新しいイメージをダウンロードし、新しいリソースを起動し、古いリソースを削除します。最初からすべてを開始する必要があります。

最大の痛みは大きな画像です。ほとんどの企業は小さなアプリケーションでは動作しません。多くの場合、スーパーモノリスでなければ、少なくとも小さなモノリスです。時間が経つにつれて、年輪が成長し、コードベースが増加し、徐々にアプリケーションが非常に大きくなります。 2 GBを超えるDockerイメージに繰り返し遭遇しました。プログラムの1バイトを変更し、ボタンを押すと、2ギガバイトのDockerイメージがアセンブルされ始めたと想像してください。次に、次のボタンを押すと、サーバーへの2 GBの転送が開始されます。

Dockerでは、レイヤーを操作できます。ある層があるかどうかを確認し、不足している層を送信します。しかし、世界は非常に多くの場合、1つの大きなレイヤーになります。 2 GBがサーバーに移動し、DockerレジストリでKubernetesに移動しますが、最終的に起動するまですべての方法で展開されます-安全にお茶を飲むことができます。

Helmは、大きなDockerイメージに関するヘルプを提供しません。私はこれをすべきではないと信じていますが、Helm開発者はすべてのユーザーよりもよく知っているので、Steve Jobsはそれに笑います。

開発ブロックも赤になりました。

環境自動化

最後の方向-環境の自動化-は興味深い分野です。 Docker（および関連モデルとしてのKubernetes）の世界以前には、「このサーバーまたはこれらのサーバーにアプリケーションをインストールして、レプリカがn個、依存関係が50個あり、すべて自動的に機能したい！」と言う方法はありませんでした。それはそうでしたが、そうではありませんでした！

Kubernetesはこれを提供します。たとえば、「ここに新しい環境を展開しています。アプリケーションを準備したすべての開発チームがボタンをクリックするだけで、これらすべてのアプリケーションが新しい環境に自動的にインストールされます」。理論的には、Helmがこれを支援し、外部データソース（S3、GitHub）からどこからでも構成を取得できるようにする必要があります。

Helmには特別なボタン「Do me good on already finally！」があり、すぐに良くなることが望ましいです。 Kubernetesではこれを行うことができます。

Kubernetesはどこでも実行でき、APIを介して機能するため、これは特に便利です。 AWSまたはGoogle Cloud Engineでminikubeをローカルで起動すると、すぐにKubernetesを取得でき、どこでも同じように機能します。ボタンを押すだけで、すべてがすぐに正常に動作します。

当然、Helmを使用するとこれが可能になります。そうでなければ、ヘルムを一般的に作成することのポイントは何でしたか？

しかし、結果は違います。

環境の自動化はありません。