Garden v0.10.0: ラップトップには Kubernetes は必要ありません

ノート。 翻訳。: プロジェクトの Kubernetes 愛好家と ガーデン 私たちは最近のイベントで会いました KubeCon ヨーロッパ 2019彼らが私たちに良い印象を与えてくれた場所。 彼らのこの資料は、最新の技術的なトピックについて、顕著なユーモアのセンスを交えて書かれており、これを明確に裏付けるものであるため、私たちはこれを翻訳することにしました。

彼は（同じ名前の）メインについて話します 製品 ワークフローを自動化し、Kubernetes でのアプリケーション開発を簡素化することを理念とする会社です。 これを行うために、このユーティリティを使用すると、コードに加えられた新しい変更を開発クラスターに簡単に (文字通り XNUMX つのコマンドで) デプロイできるようになり、チームによるコードのアセンブリとテストを高速化するための共有リソース/キャッシュも提供されます。 XNUMX週間前、ガーデンは リリース0.10.0、ローカルの Kubernetes クラスターだけでなく、リモートの Kubernetes クラスターも使用できるようになりました。この記事では、このイベントについて説明します。

私が最もやりたくないのは、ラップトップで Kubernetes を使用することです。 パイロットはプロセッサーとバッテリーを消費し、クーラーがノンストップで回転するため、メンテナンスが困難です。

効果を高めるためのテーマのストック写真

Minikube、kind、k3s、Docker Desktop、microk8s など。 — Kubernetes をできるだけ便利に使用できるように設計された素晴らしいツールであり、そのことに感謝します。 真剣に。 しかし、どう考えても、明らかなことが XNUMX つあります。それは、Kubernetes は私のラップトップで実行するように設計されていないということです。 また、ラップトップ自体は、仮想マシンのレイヤーに分散されたコンテナのクラスターで動作するように設計されていません。 可哀想なこの子は最善を尽くしますが、明らかにそれが好きではなく、クーラーの唸り声に不快感を示し、私が無謀に膝の上に置くと太ももを火傷しようとしました。

たとえば、ラップトップ - ラップトップです。

ガーデン は、Skaffold や Draft と同じニッチな開発者ツールです。 これにより、Kubernetes アプリケーションの開発とテストが簡素化され、高速化されます。

約 18 か月前、Garden に取り組み始めた当初から、私たちは次のことを知っていました。 ローカル 分散システムの開発は一時的な解決策であるため、Garden には多くの柔軟性と強固な基盤があります。

これで、ローカルとリモートの両方の Kubernetes 環境をサポートする準備が整いました。 作業がはるかに簡単になり、アセンブリ、展開、テストをリモート クラスターで実行できるようになりました。

要するに：

Garden v0.10 を使用すると、ローカル Kubernetes クラスターのことを完全に忘れることができ、コードの変更に対して迅速に対応できます。 これらはすべて無料でオープンソースです。

ローカル環境でもリモート環境でも同じ利便性を享受できます

注意してもらえましたか？

他にも興味深い機能がたくさんあるので、とてもうれしいです。 開発クラスターの一般的な使用は、特に共同作業チームや CI パイプラインに対して、より広範な影響を及ぼします。

どのように？

まず第一に、クラスタ内ビルダー (標準の Docker デーモンでも Kaniko でも) とクラスタ内レジストリが共有されます。 クラスター全体にとって。 チームは、すべての開発者が利用できるビルド キャッシュとイメージを備えた開発クラスターを共有できます。 Garden はソース ハッシュに基づいて画像にタグを割り当てるため、タグとレイヤーは一意かつ一貫して定義されます。

つまり、開発者がイメージを作成すると、それは次のようになります。 チーム全体が利用できる。 私たちは毎日、同じ基本イメージをダウンロードし、コンピューター上で同じビルドを作成します。 どれだけのトラフィックと電力が無駄になっているか知りたいですか?

テストについても同じことが言えます。テストの結果はクラスター全体とすべてのチーム メンバーが利用できます。 開発者の XNUMX 人がコードの特定のバージョンをテストした場合、同じテストを再実行する必要はありません。

つまり、minikube を実行する必要がないというだけではありません。 この飛躍により、チームは次のような道を切り開くことができます。 多くの 最適化の機会 - 不必要なビルドやテストの実行はもう必要ありません。

CIはどうですか？

私たちのほとんどは、CI とローカル開発は XNUMX つの別個の世界であり、個別に構成する必要がある (共有キャッシュは使用しない) という事実に慣れています。 これで、それらを結合して余分なものを取り除くことができます。

CI 内および開発中に同じコマンドを実行できます。 及び 単一の環境、キャッシュ、テスト結果を使用します。

本質的に、CI は、あなたと同じ環境で動作する開発者ボットに変わります。

システム要素。 シームレスな開発とテスト

CI パイプラインの構成を大幅に簡素化できます。 これを行うには、ビルド、テスト、デプロイのために CI から Garden を実行するだけです。 あなたと CI は同じ環境を使用しているため、CI の問題が発生する可能性ははるかに低くなります。

無数の設定とスクリプトの行を調べ、プッシュし、待ち、期待し、果てしなく繰り返す...これらすべては過去のことです。 あなたはまさに発展途上です。 余計な動きは一切なし。

そして、物事を明確にするために： あなたまたは他のチームメンバーが Garden で何かを構築またはテストしたとき、同じことが CI にも起こりました。。 テストの実行後に何も変更していない場合は、CI のテスト (またはビルド) を実行する必要はありません。 Garden はすべてを自ら実行し、その後、起動前環境のセットアップ、アーティファクトのプッシュなどの他のタスクに進みます。

魅力的ですね。 どうやって試してみますか？

Добропожаловатьв GitHub リポジトリ！ Garden をインストールして例を試してみましょう。 既にGardenをご利用の方、またはもっと詳しく知りたい方向けに、 リモート Kubernetes ガイド。 チャンネルに参加してください Slack Kubernetes の #garden質問や懸念がある場合、または単にチャットしたい場合。 私たちはいつでもサポートする準備ができており、ユーザーからのフィードバックを歓迎します。

翻訳者からの追伸

間もなく、Kubernetes で動作するアプリケーション開発者向けの便利なユーティリティのレビューも公開する予定です。これには、Garden に加えて、他の興味深いプロジェクトが含まれています...それまでの間、私たちのブログもお読みください。

• «Kubernetes のヒントとコツ: ローカル開発とテレプレゼンスについて";
• «Kubernetes ポッドでデバッグするための kubectl-debug プラグイン";
• «Kubernetes のヒントとテクニック: 開発サイトへのアクセス";
• «Minikube を使用した Kubernetes の入門'。

出所： habr.com