Gefyra Docker 拡張機能を使用した Kubernetes 用のローカル アプリケーション開発環境の構築 

Dockerベースの開発アプローチを使用している場合は、クラウドネイティブソフトウェアの作成に向けてすでに順調に進んでいます。 ソフトウェアをコンテナー化することで、すべてのシステム レベルの依存関係、言語固有の要件、およびアプリケーション構成をコンテナー化された方法で管理できるため、コードが最終的に実行される環境に近づきます。 

ただし、複雑なシステムでは、データベース、ストレージボリューム、API、キャッシュレイヤー、メッセージブローカーなど、いくつかの補助サービスとコードを接続する必要があります。 最新の Kubernetes ベースのアーキテクチャでは、サービス メッシュと、プローブ、構成、構造パターン、動作パターンなどのクラウドネイティブ デプロイ パターンにも対処する必要があります。 

Kubernetes は、スケーラブルで回復力のあるサービス ベースのアプリケーションをオーケストレーションするための統一されたインターフェイスを提供します。 ただし、その複雑さは、特に Kubernetes クラスターのセットアップ経験が豊富な開発者にとっては圧倒される可能性があります。 そこで Gefyra の出番となり、開発者が Kubernetes を簡単に操作し、安全で信頼性が高く、スケーラブルなソフトウェアを作成するプロセスを改善します。

暗い背景に Gefyra と Docker のロゴと、2 つのパズルのピースの明るい紫色の輪郭

ゲフィラとは何ですか? 

ギリシャ語で「ブリッジ」を意味する Gefyra にちなんで名付けられた Gefyra は、Kubernetes を使用した Docker ベースの開発を容易にする包括的なツールキットです。Kubernetes を運用プラットフォームとして使用する場合は、開発中に同じ環境で作業することが不可欠です。 このアプローチにより、可能な限り高い「開発/本番パリティ」を確保し、開発から本番に移行する際の摩擦を最小限に抑えます。 

Gefyraは、ステロイドを提供する docker run オープンソースプロジェクトです。 これにより、ローカルの Docker を任意の Kubernetes クラスターに接続し、クラスター内で実行されるかのように動作するコンテナーをローカルで実行できます。 お気に入りのコードエディタで、お気に入りのツールを使用してローカルにコードを記述できます。 

さらに、Gefyra では、コードの変更からコンテナー イメージをビルドしたり、イメージをレジストリにプッシュしたり、クラスターで再起動をトリガーしたりする必要はありません。 代わりに、既存の Dockerfile を変更せずにローカル コードをクラスターに直接接続することで、この面倒なサイクルから解放されます。 この方法は、新しいコードだけでなく、実行中のコンテナーにアタッチできるデバッガーを使用して既存のコードを紹介する場合にも役立ちます。 これにより、Gefyra は Kubernetes ベースの開発作業における生産性のスーパースターとなっています。

ゲフィラはどのように機能しますか?

Gefyraは、ローカル開発マシンと開発クラスターを制御できるようにするいくつかのクラスター側コンポーネントをインストールします。 これらのコンポーネントには、ローカル開発マシンと Kubernetes クラスター間のトンネル、クラスター DNS のように動作するローカル DNS リゾルバー、高度な IP ルーティング メカニズムが含まれます。 Gefyraは、Docker、WireGuard、CoreDNS、Nginx、Rsyncなどの一般的なオープンソーステクノロジーを使用して、これらのコンポーネントの上に構築しています。

ローカル開発のセットアップでは、ネットワーク ゲートウェイとして機能し、すべての要求をクラスターに転送する CoreDNS サーバーを提供する Cargo というサイドカー コンテナーを使用して、開発者のコンピューター上でアプリケーションのコンテナー インスタンスを実行します (図 1)。 カーゴは、アドホック接続シークレットを使用して、WireGuardで通過するすべてのトラフィックを暗号化します。 開発者は、お気に入りのコード エディターやデバッガーなどの既存のツールを使用して、アプリケーションを開発できます。

IDE を含む開発セットアップを示す白いテキスト ボックスを含む黄色のグラフィック、IDE ボリューム、シェル、ログ、デバッガー、およびアプリ コンテナーとカーゴ サイドカー コンテナーを含む gefyra への接続。
図1: ローカル開発のセットアップ。

Gefyra は、WireGuard 接続の両端を管理し、開発者とクラスタの間に VPN トンネルを自動的に確立するため、Kubernetes API サーバーにストレスを与えることなく、接続を堅牢かつ高速にすることができます (図 2)。 さらに、Gefyraのクライアント側は、VPNエンドポイントを使用してローカルDockerネットワークを管理し、コンテナがすべてのトラフィックをクラスターに転送するVPNに参加できるようにします。

開発者コンピューターと開発者クラスター間の接続を示すボックスと矢印が付いた黄色のグラフィック。
図2: 開発者のコンピューターとクラスターを接続します。

Gefyraでは、クラスターからローカルコンテナへの既存のトラフィックをブリッジすることもできるため、開発者はクラスターからの実際のリクエストでコードをテストし、チーム内の変更について共同作業を行うことができます。 ローカルコンテナインスタンスは、他のポッド、サービス、またはイングレスからのリクエストを受信している間、クラスター内の補助サービスおよびリソースに接続されたままになります。 この設定により、継続的インテグレーション パイプラインでコンテナー イメージを構築し、単純な変更のためにクラスターの更新をロールアウトする必要がなくなります。

なぜGefyraをDocker拡張機能として実行するのですか?

Gefyraのコア機能は、 リポジトリで利用可能なPythonライブラリに含まれています。 プロジェクトに付属のCLIには、一部のユーザーにとって圧倒される可能性のある引数の長いリストがあります。 よりアクセスしやすくするために、Gefyraは、開発者がGefyraの複雑さを掘り下げることなく使いやすいDockerデスクトップ拡張機能を開発しました。

Docker Desktop 用の Gefyra 拡張機能を使用すると 、開発者は、組み込みの Kubernetes クラスター、Minikube、K3d、Kind、Getdeck Beibootなどのローカル プロバイダー、または任意のリモート クラスターなど、さまざまな Kubernetes クラスターを操作できます。 始めましょう。

Gefyra Docker Desktop のインストール

前提 条件: Docker Desktop 4.8 以降。

ステップ1:初期設定

Docker デスクトップで、 Docker 拡張機能 が有効になっていることを確認します。 (Docker 拡張機能は既定で有効になっている必要があります)。 [設定] |拡張機能 で [Docker 拡張機能を有効にする] ボックスを選択します (図 3)。

「Docker 拡張機能を有効にする」が選択された Docker デスクトップ インターフェイスを示すスクリーンショット。
図3: ドッカー拡張機能を有効にします。

また、[設定] Kubernetes を有効にする必要があります (図 4)。

「kubernetes を有効にする」と「システムコンテナを表示する(詳細)」が選択された Docker デスクトップのスクリーンショット。
図4: Kubernetes を有効にします。

GefyraはDocker Extensions Marketplaceに参加しています。 次の手順では、Docker Desktop に Gefyra をインストールします。 

手順 2: Gefyra 拡張機能を追加する

Docker デスクトップを開き 、[拡張機能の追加] を選択して、拡張機能マーケットプレースで Gefyra 拡張機能を見つけます (図 5)。

Docker 拡張機能マーケットプレースでの "gefyra" の検索を示すスクリーンショット。
図5: Docker Extensions Marketplace で Gefyra を見つけます。

Gefyra がインストールされたら、拡張機能を開いて、Kubernetes クラスターに接続されているすべてのコンテナーを一覧表示する Gefyra のスタート画面を見つけることができます。 もちろん、このセクションは新規インストールでは空です。
Docker と同様に、Gefyra でローカル コンテナーを起動するには、右上の [ コンテナーの実行] ボタンをクリックする必要があります (図 6)。

gefyra のスタート画面を示すスクリーンショット。
図6: ゲフィラのスタート画面。

次の手順は、ローカルまたはリモートの Kubernetes クラスターのどちらを使用しているかによって異なります。 ローカル クラスターを使用している場合は、一致する kubeconfig ファイル を選択し、必要に応じてコンテキストを設定するだけです (図 7)。 

リモート・クラスターの場合は、追加のパラメーターを手動で指定する必要があります。 これを行う方法がわからなくても、次のセクションで詳細な例を説明するので、心配しないでください。

青い「kubeconfigを選択」ボタンを示すgefyraインターフェイスのスクリーンショット。
図7: Kubeconfigを選択します。

Kubernetes デモのワークロード

次の例は、Gefyra が Docker Desktop に含まれる Kubernetes の機能を活用して、a と a backend frontend の 2 つのサービスで構成される単純なアプリケーションの開発環境を作成する方法を示しています (図 8)。 

どちらのサービスも Python プロセスとして実装され、フロントエンド サービスはバックエンドから取得した color プロパティを使用して HTML ドキュメントを生成します。 2 つのサービス間の通信は HTTP 経由で確立され、バックエンド アドレスが環境変数としてフロントエンドに渡されます。

フロントエンドサービスとバックエンドサービスの接続を示す黄色のグラフィック。
図8: フロントエンドとバックエンドのサービス。

Gefyra チームは、 GitHub で見つけることができる Kubernetes デモ ワークロード用のリポジトリを作成しました。 

このチュートリアルの内容を説明するビデオをご覧になりたい場合は、 YouTubeでこのビデオをチェックしてください。 

前提

現在の Kubernetes コンテキストが Docker Desktop に切り替えられていることを確認します。 この手順により、ユーザーは Kubernetes クラスターと対話し、 を使用してアプリケーションをデプロイ kubectlできます。

kubectl config current-context
docker-desktop

リポジトリのクローンを作成する

次のステップは、リポジトリのクローンを作成することです。

git clone https://github.com/gefyrahq/gefyra-demos

ワークロードの適用

次の YAML ファイルは、コンテナーに渡され frontend る環境変数を介して SVC_URL 確立された 2 つのサービス間の通信を使用して、バックエンド サービスとフロントエンド サービスで構成される単純な 2 層アプリを設定します。 

これは、 と という名前の 2 つのポッドと backend frontend、それぞれ と backend frontendという名前の 2 つのサービスを定義します。ポッドは backendquay.io/gefyra/gefyra-demo-backend ポート 5002 のイメージ。 ポッドは frontendquay.io/gefyra/gefyra-demo-frontend ポート 5003 のイメージ。 コンテナには frontend 、 という名前の SVC_URL環境変数も含まれています。この環境変数は、値 backend.default.svc.cluster.local:5002に設定されます。

backend サービスは、ラベルを使用して app: backend ポッドを選択し backend 、ポート 5002 を公開するように定義されています。frontend サービスは、ラベルを使用して app: frontend ポッドを選択し frontend 、ポート 80 をロード バランサーとして公開し、コンテナーのポート 5003 にトラフィックをルーティングするように定義されています frontend

/gefyra-demos/kcd-munich> kubectl apply -f manifests/demo.yaml
pod/backend created
pod/frontend created
service/backend created
service/frontend created

ワークロードの準備を見てみましょう。

kubectl get pods
NAME         READY    STATUS    RESTARTS   AGE
backend     1/1            Running    0                    2m6s
frontend     1/1            Running    0                    2m6s

バックエンドポッドとフロントエンドポッドの初期化が完了したことを確認したら(出力の列を確認してください READY )、Webブラウザーで http://localhost に移動してアプリケーションにアクセスできます。 この URL は、Docker Desktop の Kubernetes 環境から提供されます。 

ページを読み込むと、アプリケーションの出力がブラウザに表示されます。 出力は視覚的に見事ではないかもしれませんが、機能的であり、ニーズに必要な機能を提供する必要があります。

黒いテキストで「hello world」を表示する青いバー。

それでは、フロントエンドコンポーネントによって生成された出力の色を修正または調整する方法を調べてみましょう。

フロントエンドプロセスでのGefyraの「コンテナの実行」の使用

このセクションの最初の部分では、Kubernetes クラスターに基づくリソース (バックエンド API) に関連付けられているローカル マシンでフロントエンド プロセスを実行する方法について説明します。 これは、データベースからメッセージブローカー、またはアーキテクチャで使用されるその他のサービスまで、あらゆるものにすることができます。

Gefyra のスタート画面から [コンテナーの実行] を使用してローカル コンテナーを開始します (図 9)。

青い「コンテナの実行」ボタンを示すgefyraインターフェイスのスクリーンショット。
図9: ローカル コンテナーを実行します。

このプロセスの最初のステップに入ると、 kubeconfig' とコンテキストが自動的に設定されます。 ホスト上のデフォルトのkubeconfigがどこにあるかわからない場合、これは命の恩人です。

[次へ]ボタンを押して、コンテナの設定に進みます(図10)。

「kubernetes 設定の設定」ステップを示す gefyra インターフェイスのスクリーンショット。
図10: コンテナーの設定。

[コンテナーの設定] ステップでは、ローカル コンテナーの Kubernetes 関連のパラメーターを構成できます。この例では、すべてが既定の Kubernetes 名前空間で行われます。 最初のドロップダウン入力で選択します(図11)。 

[画像] の下のドロップダウン入力で、ローカルで実行する画像を指定できます。選択した名前空間で使用されているすべてのイメージが一覧表示されます ( [名前空間 ] セレクターから)。 便利じゃないですか? クラスターで使用されているイメージについて心配したり、自分で見つけたりする必要はありません。 代わりに、この例で実行したいように、手元の画像を操作するための提案が表示されます (図 12)。 たとえば、マシン上に構築したばかりの完全に新しい画像が必要な場合は、任意の画像を指定できます。

コンテナー設定の下に [ワークロードの選択] ドロップダウン メニューを表示する gefyra インターフェイスのスクリーンショット。
図11: 名前空間とワークロードを選択します。
画像のドロップダウンメニューを示すgefyraインターフェイスのスクリーンショット。
図12: 実行する画像を選択します。

クラスターで実行されているフロントエンド コンテナーの環境をコピーするには、 環境のコピー元 セレクターから ポッド/フロントエンド を選択する必要があります (図 13)。この手順は、環境変数を使用して クラスター内のポッド に渡されるバックエンド サービス アドレスが必要なため重要です。

最後に、コンテナー設定の上部で、コンテナー イメージの次の run コマンドを上書きして、コードのリロードを有効にする必要があります。

poetry run flask --app app --debug run --port 5002 --host 0.0.0.0
「環境のコピー元」の下の「ポッド/フロントエンド」の選択を示すgefyraインターフェイスのスクリーンショット。 "
図13: フロントエンドコンテナのコピー環境。

ポート 5002 でコンテナー プロセスを開始し、このポートをローカル コンピューターに公開しましょう。 さらに、コードディレクトリ (/gefyra-demos/kcd-munich/frontend)をマウントして、コードの変更をすぐに表示しましょう。 とりあえず以上です。 [実行]ボタンをクリックすると、プロセスが開始されます。

インストールの進行状況バーを示す gefyra インターフェイスのスクリーンショット。
図14: Gefyra コンポーネントのインストール。

Gefyraのクラスタ側コンポーネントをインストールし、ローカルネットワーク部分を準備し、コンテナイメージをプルしてローカルで起動するには、数秒かかります(図14)。 この準備ができると、このコンテナーから Docker Desktop のネイティブ コンテナー ビューにリダイレクトされます (図 15)。

Dockerデスクトップのネイティブコンテナビューを示すスクリーンショット。
図15: ログビュー。

[ ターミナル ]タブを使用してコンテナ内を見回すことができます(図16)。 シェルにコマンドを入力する env と、Kubernetesに付属するすべての環境変数が表示されます。

実行中のコンテナのターミナルビューを示すスクリーンショット。
図16: ターミナルビュー。

特に興味深いのは、 SVC_URL フロントエンドをバックエンドプロセスに向ける変数で、もちろん、まだクラスター内で実行されているプロセスです。これで、URL http://localhost:5002 を参照すると、わずかに異なる出力が得られます。

黒いテキストで「こんにちはkcd」を表示する青いバー

それはどうしてですか。 ローカル コンテナーに既にマウントされているコード、特に app.py Flask サーバー を実行するコードを見てみましょう (図 17)。

カラフルなアプリのスクリーンショット。 黒い背景にPyコード。
図 17: App.py コード

Gefyra の例のコードの最後の行には、テキスト が表示され、このコードに加えられた変更は、 Hello KCD!ローカル コンテナーで直ちに更新されます。 開発者はコードを自由に変更し、コンテナーを再構築または再デプロイすることなく、変更が反映されていることをリアルタイムで確認できるため、この機能は注目に値します。

Gefyra の例のコードの 12 行目は、変数 SVC に格納されているサービス URL に要求を送信します。 SVC の値は、Kubernetes クラスター内のポッドからコピーされる という名前の SVC_URL環境変数から読み取られます。 URL は、 backend.default.svc.cluster.local:5002Kubernetes サービス オブジェクトとポートを指す完全修飾ドメイン名 (FQDN) です。 

これらの URL は、相互に通信するために Kubernetes のアプリケーションによって一般的に使用されます。 ローカルコンテナプロセスは、ネイティブ接続パラメータを使用してKubernetesで実行されているサービスにリクエストを送信でき、開発者が変更を加える必要はありません。

ほとんどの開発シナリオでは、先ほど説明した Gefyra の機能で十分です。 つまり、Gefyra を使用して、Kubernetes クラスター内のリソースと通信できるローカル コンテナーを実行し、ローカル ポートでアプリにアクセスできます。 ただし、フロントエンドがまだKubernetesで実行されている間にバックエンドを変更する必要がある場合はどうなりますか? ここで、Gefyraの「ブリッジ」機能が登場し、次に説明します。

Gefyraとバックエンドプロセスとの「ブリッジ」

フロントエンドプロセスをローカルで実行し、ブリッジを介してKubernetesで実行されているバックエンドプロセスに接続することを選択できます。 ただし、このアプローチは、特にフロントエンドに興味がないバックエンド開発者にとって、必ずしも必要または望ましいとは限りません。 この場合、フロントエンドをクラスターで実行したままにして、Docker Desktop のコンテナー ビューで停止ボタンを選択してローカル インスタンスを停止する方が便利な場合があります。

まず、バックエンドサービスのローカルインスタンスを実行する必要があります。 フロントエンドと同じですが、今回はバックエンド コンテナー イメージを使用します (図 18)。

「ポッド/バックエンド」のセットアップを示すgefyraインターフェイスのスクリーンショット。
図18: バックエンド コンテナー イメージの実行。

上記のフロントエンドの例と比較すると、バックエンドコンテナイメージ()を実行できます。quay.io/gefyra/gefyra-demo-backend:latestこれは、ドロップダウンセレクターによって提案されます。 今回は、Kubernetes で実行されているバックエンド ポッドから環境をコピーする必要があります。 ボリュームマウントがバックエンドサービスのコードに設定され、機能するようになったことに注意してください。

コンテナーを起動した後、バックエンド API 応答を提供する http://localhost:5002/color を確認できます。 バックエンド サービスを見る app.py と、この応答のソースがわかります。8 行目で、このアプリは color プロパティが (図 19) に設定された green JSON 応答を返します。

アプリを示すスクリーンショット。 「色」が「緑」に設定されたPyコード。
図19: 色を確認します。

この時点では、バックエンド サービスのローカル インスタンスのみを実行していることに注意してください。 今回は、このコンテナーは外部依存関係なしで実行されるため、Kubernetes ベースのリソースへの接続は必要ありません。

アイデアは、 http://localhost 上のKubernetesクラスターから提供されるフロントエンドプロセス(まだ青)にバックエンド情報を取得して、その出力をレンダリングさせることです。 これは、Gefyraのブリッジ機能を使用して行われます。 次のステップでは、クラスターで実行されているバックエンドプロセスをローカルコンテナインスタンスとオーバーレイして、ローカルコードがクラスターで有効になるようにします。

スタート画面の Gefyra コンテナーの一覧に戻ると、ローカルで実行されている各コンテナーの [ ブリッジ ] 列が表示されます (図 20)。 このボタンをクリックすると、ローカル コンテナーのクラスターへのブリッジを作成できます。

右端に「ブリッジ」列を示すgefyraインターフェイスのスクリーンショット。
図20: [ブリッジ] 列は右端に表示されます。

次のダイアログで、ブリッジ構成を入力する必要があります(図21)。

ブリッジ設定を示すgefyraインターフェイスのスクリーンショット。
図21: ブリッジ設定を入力します。

ブリッジの "Target" を、現在クラスター内のフロントエンド プロセスを提供しているバックエンド ポッドに設定し、ブリッジのタイムアウトを 60 秒に設定してみましょう。 また、クラスターで実行されているプロキシのポートをローカルインスタンスにマップする必要があります。 

ローカル コンテナーがクラスターとは異なるポートでリッスンするように構成されている場合は、ここでマッピングを指定できます (図 22)。 この例では、サービスはクラスターとローカル コンピューターの両方のポート 5003 で実行されているため、そのポートをマップする必要があります。 ブリッジ ボタンをクリックした後、Gefyraのスタートビューのコンテナリストに戻るまでに数秒かかります。

ポートマッピング設定を示すgefyraインターフェイスのスクリーンショット。
図22: ポート マッピングを指定します。

[ブリッジ] ボタンのアイコンの変化を観察し、停止記号を表示します (図 23)。これは、ブリッジ機能が動作可能になり、このボタンをもう一度クリックするだけで終了できることを意味します。

橋の柱と青い停止ボタンの接写図を示すgefyraのスクリーンショット。
図23: 停止記号を示す橋の列。

この時点で、ローカル コードは、フロントエンド プロセス自体に変更を加えることなく、変数に格納されている SVC_URL URL を使用して、クラスター内のフロントエンド プロセスからの要求を処理できます。 これを確認するには、ブラウザ(Docker DesktopのKubernetesから提供される)で http://localhost を開き、出力が緑色になっていることを確認します。 これは、ローカル コードが color プロパティの値を green 返しているためです。 この値は IDE で任意の有効な値に変更でき、すぐにクラスターに反映されます。 これがこのツールの驚くべき力です。

バックエンドへの変更が完了したら、コンテナのブリッジを解放することを忘れないでください。 これにより、クラスターが元の状態にリセットされ、フロントエンドに元の「美しい」青いH1が再び表示されます。 このアプローチにより、Kubernetes クラスター自体を変更することなく、ローカル コードを使用して Kubernetes で実行されているコンテナーをインターセプトできます。 これは、Kubernetes クラスター自体に変更を加えなかったためです。 代わりに、Kubernetesで実行されているコンテナをローカルコードでインターセプトし、その後そのインターセプトをリリースしました。

結論

Gefyra は使いやすい Docker Desktop 拡張機能で、Kubernetes と接続して開発ワークフローとチーム コラボレーションを改善します。 これにより、Kubernetesに接続したまま通常どおりコンテナを実行できるため、時間を節約し、高い開発/本番パリティを確保できます。 

Blueshoe開発チームは GitHubのスターを高く評価し、Discordコミュニティに参加して詳細を確認することを歓迎します。

著者について

Michael Schilonkaは、Kubernetesがソフトウェア開発プラットフォームにもなり得ると強く信じています。 彼はミュンヘンを拠点とするエージェン シーBlueshoe の共同創設者兼マネージングディレクターであり、 GefyraGetdeckのテクニカルリードです。 彼は、Kubernetes 全般と、開発に Kubernetes をどのように使用しているかについて話します。 LinkedInで彼をフォロー して、接続を維持してください。

フィードバック

「Gefyra Docker拡張機能を使用したKubernetesのローカルアプリケーション開発環境の構築」に関する0の考え