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