Kubernetesでのマイクロサービスの開発についての質問が増えています。 開発者、特にインタープリター言語は、F5キーを押すだけで、ビルド/デプロイメントが結果を確認するのを待たずに、お気に入りのIDEでコードをすばやく修正したいです。 そして、モノリシックアプリケーションについては、データベースとWebサーバー（Docker、VirtualBoxなど）をローカルに上げるだけで十分です。その後、すぐに開発を楽しんでください。 マイクロサービスへのモノリスの鋸引きとKubernetesの出現により、相互依存関係が出現したため、事態は少し複雑になりました 。 これらのマイクロサービスが多ければ多いほど、問題が多くなります。 再び開発を楽しむには、1つまたは2つ以上のDockerコンテナ、場合によっては12個以上のDockerコンテナを作成する必要があります。
さまざまな時点で、問題のさまざまな解決策を試みました。 そして、蓄積された回避策、または単に「クランチ」から始めます。
1.松葉杖
ほとんどのIDEには、FTP / SFTPを使用してサーバー上のコードを直接編集する機能があります。 この方法は非常に明白であり、すぐに使用することにしました。 その本質は次のとおりです。
- 開発環境のポッド（dev / review）では、追加のコンテナーがSSHアクセスで起動され、アプリケーションをコミット/デプロイする開発者の公開SSHキーを転送します。
- initステージ（
prepare-app
コンテナー内）でコードをemptyDir
に転送して、アプリケーションとSSHサーバーを含むコンテナーからコードにアクセスできるようにします。
このようなスキームの技術的な実装をよりよく理解するために、Kubernetesに含まれるYAML設定のフラグメントを提供します。
構成
1.1。 values.yaml
ssh_pub_key: vasya.pupkin: <ssh public key in base64>
ここで、
vasya.pupkin
は変数
${GITLAB_USER_LOGIN}
値です。
1.2。 deployment.yaml
... {{ if eq .Values.global.debug "yes" }} volumes: - name: ssh-pub-key secret: defaultMode: 0600 secretName: {{ .Chart.Name }}-ssh-pub-key - name: app-data emptyDir: {} initContainers: - name: prepare-app {{ tuple "backend" . | include "werf_container_image" | indent 8 }} volumeMounts: - name: app-data mountPath: /app-data command: ["bash", "-c", "cp -ar /app/* /app-data/" ] {{ end }} containers: {{ if eq .Values.global.debug "yes" }} - name: ssh image: corbinu/ssh-server volumeMounts: - name: ssh-pub-key readOnly: true mountPath: /root/.ssh/authorized_keys subPath: authorized_keys - name: app-data mountPath: /app ports: - name: ssh containerPort: 22 protocol: TCP {{ end }} - name: backend volumeMounts: {{ if eq .Values.global.debug "yes" }} - name: app-data mountPath: /app {{ end }} command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"] ...
1.3。 secret.yaml
{{ if eq .Values.global.debug "yes" }} apiVersion: v1 kind: Secret metadata: name: {{ .Chart.Name }}-ssh-pub-key type: Opaque data: authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}" {{ end }}
最後のタッチ
その後、 必要な変数をgitlab-ci.ymlに渡すだけです 。
dev: stage: deploy script: - type multiwerf && source <(multiwerf use 1.0 beta) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf deploy --namespace ${CI_PROJECT_NAME}-stage --set "global.env=stage" --set "global.git_rev=${CI_COMMIT_SHA}" --set "global.debug=yes" --set "global.username=${GITLAB_USER_LOGIN}" tags: - build
Voila：展開を開始した開発者は、デスクトップからSFTP経由でサービスの名前（クラスターへのアクセスを安全に発行する方法を既に説明しました）を使用して接続し、クラスターに配信されるのを待たずにコードを編集できます。
これは完全に機能するソリューションですが、実装の観点からは明らかな欠点があります。
- ヘルムチャートを洗練する必要があり、読みがさらに複雑になります。
- サービスを展開した人だけがそれを使用できます。
- コードを使用してローカルディレクトリと同期し、Gitでコミットすることを忘れないでください。
2.テレプレゼンス
Telepresenceプロジェクトはかなり以前から知られていましたが、彼らが言うように、実際に私たちと一緒に実際に試してみました。 しかし、需要はその仕事を果たしており、今では、特にハブにテレプレゼンスに関する他の資料がなかったため、ブログの読者に役立つ経験を共有できることを嬉しく思います。
要するに、すべてがそれほど怖くないことが判明しました。 開発者による実行を必要とするすべてのアクションは、
NOTES.txt
というテキストファイルHelm-chartに配置しました。 したがって、Kubernetesにサービスをデプロイした後、開発者はGitLabジョブログでローカル開発環境を開始する指示を確認します。
!!! , Kubernetes !!! * * * VPN * * kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ ) * * config- kubectl ( ~/.kube/config) * * telepresence ( https://www.telepresence.io/reference/install ) * * Docker * * reporter https://gitlab.site.com/group/app * * registry / GitLab ( ): ######################################################################### docker login registry.site.com ######################################################################### * ######################################################################### telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8 #########################################################################
このマニュアルに記載されている手順については、最後の手順を除いて説明しません。 Telepresenceの起動中はどうなりますか？
Telepresenceを使用する
開始時に（上記の手順で指定された最後のコマンドに従って）以下を設定します。
- マイクロサービスが起動される名前空間（名前空間）。
- 展開したいデプロイメントの名前とコンテナー。
残りの引数はオプションです。 サービスがKubernetes APIと対話し、 ServiceAccountが作成された場合、デスクトップに証明書/トークンをマウントする必要があります。 これを行うには、オプション
--mount=true
（または
--mount=/dst_path
）を使用します。これにより、ルート（/）がKubernetesのコンテナーからデスクトップにマウントされます。 その後、（OSとアプリケーションの起動方法に応じて）クラスターの「キー」を使用できます。
まず、最も汎用性の高いアプリケーション起動オプション-Dockerコンテナを検討します。 これを行うには、
--docker-run
スイッチを使用して、コンテナ内のコードでディレクトリをマウントし
--docker-run
-v `pwd`:/app
これは、プロジェクトのあるディレクトリから開始することを意味することに注意してください。 アプリケーションコードは、コンテナの
/app
ディレクトリにマウントされます。
次に：
-v /tmp/app/var/run/secrets:/var/run/secrets
証明書/トークンを含むディレクトリをコンテナにマウントします。
最後に、このオプションの後に、アプリケーションが起動されるイメージが続きます。 注意 ：画像を組み立てるときは、
CMD
または
ENTRYPOINT
指定する必要があります！
実際、次に何が起こるのでしょうか？
- Kubernetesでは、指定された展開に対して、レプリカの数が0に変更されます。代わりに、
backend
コンテナが置き換えられた新しい展開が起動します。 - デスクトップでは、2つのコンテナが開始されます。1つ目はTelepresence（Kubernetesとの間でリクエストをプロキシします）、2つ目は開発中のアプリケーションです。
- アプリケーションを含むコンテナ内でexec'nitsyaを実行すると、展開中にHelmから渡されたすべてのENV変数にアクセスでき、すべてのサービスを利用できます。 あとは、お気に入りのIDEでコードを編集して結果を楽しむだけです。
- 作業の最後に、Telepresenceが実行されているターミナルを閉じる（Ctrl + Cを使用してセッションを終了する）と、Dockerコンテナーがデスクトップで停止し、Kubernetesですべてが初期状態に戻ります。 あとは、コミットしてMRを発行し、それをレビュー/マージ/ ...（ワークフローに応じて）に渡すだけです。
Dockerコンテナでアプリケーションを実行したくない場合（たとえば、PHPではなくGoで開発し、ローカルで収集する場合）、Telepresenceの起動はさらに簡単になります。
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=true
アプリケーションがKubernetes APIにアクセスする場合、 キーを使用してディレクトリをマウントする必要があります 。 Linuxには、 prootユーティリティがあります。
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
--docker-run
オプションを使用せずに
--docker-run
すると、すべての環境変数が現在のターミナルで使用できるようになるため、その中でアプリケーションを起動する必要があります。
NB ：たとえば、PHPを使用する場合、開発のためにさまざまなop_cache、apc、およびその他のアクセラレーターを無効にすることを忘れないでください。そうしないと、コードを編集しても目的の結果が得られません。
まとめ
Kubernetesを使用したローカル開発は、このプラットフォームの普及に比例してソリューションの必要性が高まっている問題です。 開発者から（顧客から）関連するリクエストを受け取った私たちは、最初の利用可能な手段でそれらを解決し始めましたが、それは長距離にわたって信頼できると証明されませんでした。 幸いなことに、これは私たちだけでなく現在だけでなく、より適切な手段がすでに世界に登場しているため、テレプレゼンスが最も有名です（ちなみに、Googleのスキャフォールドはまだあります）。 私たちの使用経験はそれほど素晴らしいものではありませんが、すでに「同僚」に推奨する理由が与えられています。試してみてください！
PS
その他のK8sのヒントとトリックのサイクル：