この記事では、スタートアップ プロジェクトでオーケストレーションへのアプローチをどのように変更したか、変更した理由、その過程でどのような問題を解決したかについて話したいと思います。 この記事はユニークであるとはほとんど主張できませんが、問題を解決する過程で資料がかなりきしみながら私たちによって収集されたため、それでも誰かの役に立つ可能性があると思います。
私たちは何を持っていて、何を話しているのでしょうか？ そして、広告領域から開発して約2年の歴史を持つスタートアッププロジェクトでした。 このプロジェクトはもともとマイクロサービスとして構築され、そのサーバー部分は Symfony と少しの Laravel、Django、ネイティブ NodeJ で書かれていました。 サービスは基本的に、モバイル クライアント用の API (プロジェクトには 3 つあります) と、IOS 用の独自の SDK (顧客のアプリケーションに組み込まれています)、および同じ顧客の Web インターフェイスとさまざまなダッシュボードです。 すべてのサービスは最初は Docker 化され、docker-compose によって実行されました。
確かに、docker-compose はどこでも使用されていたわけではなく、開発者のローカル環境、テスト サーバー上、サービスの構築とテスト時のパイプライン内でのみ使用されていました。 ただし、本番環境では Google Kubernetes Engine (GKE) が使用されました。 さらに、プロジェクトの開始時に GKE の構成を完全に Web インターフェースを通じて行いました。これは非常に高速で、当時の私たちには便利だと思われました。 ここでは、GKE でサービスを実行するための Docker イメージを構築するプロセスのみが自動化されました。