Docker、マイクロサービス、Gitワークフロー
私たちは、マイクロサービスアーキテクチャを備えたnode.jsでWebアプリを開発している若い会社です。
実際の開発ワークフロー：
- 各マイクロサービスはプライベートリポジトリに保存されます
- さまざまな開発者/チームが特定のリポジトリ（マイクロサービス）にアクセスできます
- 各開発者は、Dockerを使用してローカルで作業できます。彼は、bitbucketからプルされたすべてのマイクロサービスを含むDockerの「開発環境イメージ」をプルする必要があります。彼は自分のローカルマイクロサービスソースパスをボリュームとしてDockerコンテナーにマッピングし、開発を開始できます。
問題：各開発者は、Dockerコンテナーを通過するすべてのマイクロサービスソースを確認できます。 「Microservice1」にのみアクセス/アクセスできる開発者は、「Microservice2」のソースを見る必要はありません。外部のフリーランサーがマイクロサービスを開発していると仮定したい場合は、システムのソース全体に貴重な知的財産が含まれている可能性があるため、システムのソース全体を見せたくありません。
ソリューション？
あなたの問題はあなたが記述しているのと同じ「開発環境イメージ」にマイクロサービスをall入れていることのようです。したがって、どのサービスコンテナでも他のすべてを見ることができます。
あなたがしなければならないのは、各マイクロサービスに特定のDockerイメージを構築し、適切なデフォルトと各特定のマイクロサービスを含むベースイメージDockerに構築することです。
この基本イメージから新しいサービスを開発できます。基本イメージには他のサービスが含まれていないため、問題を心配する必要はありません。
それぞれのサーバー/クライアントイメージが必要な場合もあります（質問の詳細は、これが重要であるかどうかを実際に回答するには十分ではありません）。外部の請負業者について質問している場合、これも役立つかもしれませんが、マイクロサービスが実際にどのように機能するかによって異なります。
Dockerの大きな利点の1つは、この種のことを実行できることです。 「実行するものすべてが同じDockerイメージを使用する」単一の種類を作成すると、Dockerの要点が失われます。
コードで誰かを信頼していない場合は、コードをそのマシンに送信しないでください。限目。
Dockerは、最新のいくつかのリリースでネットワーキングをかなり改善しました。マイクロサービスごとに1つのコンテナーを使用するようにシステムを設計する場合、開発環境がリモートサーバーと通信し、本番環境とテスト環境をすべて同じホスト上で、コンテナー内のマイクロサービスの観点から見ると、違いは、追加のレイテンシです。
開発者の「信頼できる」層と「信頼できない」層が必要な場合は、これを段階的に追加できます。ただし、エンダーランドが指摘したように、コンテナーを1つだけ使用することで、Dockerのポイントを見逃しているように見えます。複数のコンテナを使用すると、個々のサービスのアップグレード、バックアップ、再起動などを簡単に実行できます。個々のサービスをより簡単に分離できるため、通常、開発はより迅速です。各サービスは、インターフェースについて同意するだけでよく、他の内部の詳細については同意しません。
マイクロサービスをテストするために、システムの残りの部分が利用可能になることを必要としない場合が多い。独自のコンテナを起動して、 curl 、 postman 、または自動テストスクリプトでそれを強打することができます。開発者が作業しやすく、独自の情報を含まないモック開発環境を提供できます。
現在、個別のコンテナーに分割するのはより困難に感じるかもしれませんが、長期的にはそれだけの価値があります。