Gefyraを使用したKubernetesローカル開発環境の構築

開発にDockerを使用している場合は、すでにクラウドネイティブソフトウェアの作成に向けて順調に進んでいます。 コンテナ化は、システムの依存関係、言語要件、アプリケーション構成など、コードを実行するために不可欠なすべての要素を処理します。 しかし、Kubernetesのローカル開発のような、より複雑なユースケースを処理できるのでしょうか?

より複雑なシステムでは、コードを複数の補助サービス (データベース、ストレージボリューム、API、キャッシュレイヤー、メッセージブローカーなど) に接続する必要がある場合があります。 最新のKubernetesシステムでは、サービスメッシュとクラウドネイティブなデプロイパターン(プローブ、構成、構造パターン、動作パターンなど)も管理する必要があります。

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

ゲフィラとは何ですか? 

ゲフィラギリシャ 語で「ブリッジ」を意味する言葉にちなんで名付けられた、Kubernetesを使用したDockerベースの開発を容易にする包括的なツールキットです。 Kubernetesを本番プラットフォームとして使用する場合は、開発中に同じ環境で作業することが不可欠です。 この方法により、開発と運用のバランスが取れ、移行中の問題が最小限に抑えられます。

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

また、Gefyra では、コードを変更するときに複数のタスクを実行する必要はありません。 代わりに、Gefyra を使用すると、Dockerfile に変更を加えることなく、コードをクラスターに接続できます。 Dockerイメージを作成したり、レジストリに送信したり、クラスターを再起動したりする必要はありません。

このメソッドは、新しいコードや、コンテナーに接続されたデバッガーを使用して既存のコードを検査する場合に役立ちます。 これにより、GefyraはKubernetesベースの開発作業における生産性のスーパースターとなっています。

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

Gefyraは、ローカル開発マシンと開発クラスターを制御できるようにするいくつかのクラスター側コンポーネントをインストールします。 

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

ローカル開発をセットアップするには、開発者はマシン上のコンテナーでアプリケーションを実行する必要があります。 コンテナーには、Cargo という名前のサイドカー コンテナーが必要です。 サイドカーコンテナはネットワークゲートウェイとして機能し、CoreDNSサーブを使用してすべてのリクエストをクラスタに転送します(図1)。

Cargoは、アドホック接続シークレットを使用して、WireGuardで通過するすべてのトラフィックを暗号化します。 開発者は、お気に入りのコード エディターやデバッガーなどの既存のツールを使用して、アプリケーションを開発できます。

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

また、Gefyraでは、クラスタからローカルコンテナへの既存のトラフィックのブリッジングが可能で、開発者はクラスタからの実際のリクエストでコードをテストし、チーム内の変更について共同作業を行うことができます。 ローカルコンテナインスタンスは、他のPod、Service、またはIngressからリクエストを受信している間、クラスター内の補助サービスおよびリソースに接続されたままになります。 このセットアップにより、CI パイプラインでコンテナー イメージを作成し、小さな変更のためにクラスターを更新する必要がなくなります。

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

Gefyraのコア機能を含むPythonライブラリは、 そのリポジトリで入手できます。 プロジェクトに付属するCLIには、一部のユーザーにとっては圧倒される可能性のある引数の長いリストがあります。 開発者にとってよりアクセスしやすいものにするために、GefyraはDocker Desktop拡張機能を開発しました。

Gefyra拡張機能を使用すると、開発者はDocker DesktopでさまざまなKubernetesクラスターを操作できます。これらには、組み込みクラスター、ローカルプロバイダー (Minikube、K3d、Kind、Getdeck Beiboot など)、およびリモートクラスターが含まれます。 さっそく始めましょう。

Gefyra Docker Desktop のインストール

前提 条件： Docker Desktop 4.8 以降。

ステップ1:初期設定

まず、Docker Desktop で Docker 拡張機能 が有効になっていることを確認します (デフォルトで有効になっているはずです)。 [ 設定] |拡張機能 [ Docker 拡張機能を有効にする] ボックスを選択します (図 3)。

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

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

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

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

Gefyraをインストールすると、拡張機能を開いてGefyraのスタート画面を見つけることができます。 ここには、Kubernetesクラスタに接続されているすべてのコンテナのリストがあります。 もちろん、このセクションは新規インストールでは空です。

Gefyraを使用してローカルコンテナを起動するには、[ コンテナの実行 ]ボタンをクリックする必要があります。 このボタンは右上にあります(図6)。

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

リモートクラスタの場合は、追加のパラメータを手動で指定する必要があります。 次のセクションで従うための詳細な例を示します。

Kubernetes デモのワークロード

次の例は、GefyraがDocker DesktopのKubernetes機能を使用して、単純なアプリケーションの開発環境を作成する方法を示しています(図8)。

これら 2 つのサービスには a と a backend frontend が含まれ、Python プロセスとして実装されます。 また、フロントエンド サービスは、バックエンドから取得した color プロパティを使用して HTML ドキュメントを生成します。 2 つのサービスは HTTP を使用して通信し、バックエンド アドレスを環境変数としてフロントエンドに与えます。

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

ただし、ビデオチュートリアルがお好みの場合は、 YouTubeのこのビデオをご覧ください。 

前提

現在の Kubernetes コンテキストを Docker Desktop に切り替える必要があります。 この手順では、ユーザーは Kubernetes クラスターを操作し、 を使用して kubectlアプリケーションをデプロイできます。

kubectl config current-context
docker-desktop

1. リポジトリをクローンする

まず、リポジトリをクローンする必要があります。

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

2. ワークロードを適用する

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

これは、 と という名前の 2 つのポッドと、backendそれぞれ と frontendfrontendという名前の 2 つのサービスbackendを定義します。ポッドは backend、 quay.io/gefyra/gefyra-demo-backend ポート 5002 のイメージ。

ポッドは frontend 、 quay.io/gefyra/gefyra-demo-frontend ポート 5003 のイメージ。 frontendコンテナには、 という値backend.default.svc.cluster.local:5002に設定された という名前のSVC_URL環境変数があります。

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環境から提供されます。

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

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

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

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

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

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

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

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

[画像] の下のドロップダウン入力で、ローカルで実行する画像を指定できます。ここには、(名前空間セレクタから)選択した 名前空間 で使用されているすべての画像が一覧表示されます。 これにより、クラスターにどのような画像があるかを気にしたり、自分で見つけたりする必要がなくなります。

代わりに、手元の画像で作業するように提案されますが、これはこの例で実行したいことです (図 12) 。 マシンで作成した新しい画像であっても、必要な画像を指定できます。

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

コンテナー設定の上部では、次のコンテナー イメージの実行コマンドを上書きして、コードの再読み込みを有効にする必要があります。

poetry run flask --app app --debug run --port 5002 --host 0.0.0.0

ポート 5002 でコンテナー プロセスを開始し、このポートをローカル コンピューターに公開しましょう。 また、コードディレクトリ (/gefyra-demos/kcd-munich/frontendをマウントします )を使用して、コードの変更をすぐに表示できるようにします。 次に、[ 実行 ]ボタンをクリックしてプロセスを開始します。

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

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

特に注目すべきは、SVC_URLフロントエンドがバックエンドプロセスを指す変数で、バックエンドプロセスはまだクラスター内で実行されています。これで、URL http://localhost:5002 を参照すると、わずかに異なる出力が表示されます。

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

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の「ブリッジ」機能が登場し、次に説明します。

4. Gefyraとバックエンドプロセスとの「橋渡し」

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

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

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

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

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

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

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

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

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

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

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

この時点で、ローカル コードは、変数に格納され SVC_URL ている URL を使用して、クラスター内のフロントエンド プロセスからの要求を処理できます。 これは、フロントエンドプロセス自体に変更を加えることなく実行できます。 

これを確認するには、ブラウザで http://localhost を開き(Docker DesktopのKubernetesから提供されます)、出力 greenが. これは、ローカル コードが color プロパティの値 green を返しているためです。 この値はIDEで有効な値に変更でき、すぐにクラスタに反映されます。 これがこのツールの驚くべき力です。

バックエンドへの変更が完了したら、コンテナのブリッジを解放することを忘れないでください。 これにより、クラスターが元の状態にリセットされ、フロントエンドに元の「美しい」青色のH1が再び表示されます。 

このアプローチにより、Kubernetesクラスタ自体を変更することなく、ローカルコードでKubernetesで実行されているコンテナをインターセプトできます。 これは、Kubernetes クラスター自体に変更を加えていないためです。 代わりに、Kubernetesで実行されているコンテナをローカルコードでインターセプトし、そのインターセプトを後でリリースしました。

結論

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

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

著者について

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