こんにちは。SREチームでリーダーをやっている木村です。
座右の名は「明日自分が交通事故にあっても、システムの運用を滞りなくする」です。
ビザスクは、サービスが開始されてから長年モノリシックな構成で開発を続けてきたのですが、サービスと組織の成長に伴い、2020年 10月から全てを作り直す システムリプレース を行い、サービスに成長に合わせた構成に刷新しています。
(システムリプレースの詳細は Google Open Cloud Summit 我々はなぜレガシー AppEngine Python2 から Cloud Run に移行しようとしたのか？ を参照してください)
これに伴い サービス毎にシステムを分割をしたのですが、徐々に増えていくサービスを増えていく中で
ローカル開発をするにあたって、全てのサービスを立ち上げないと行けないのが辛い。。。。。
という課題がありました。
結論から言うと、まだその課題の具体的な解決策は見つかっていない状態なのですが、そのままにしても良くない。ということで改善を行いましたので
その話をさせていただきます。
ローカル環境のディレクトリ構成について
まずはローカル環境の構成ですが、各 Micro Service にリポジトリ単位で docker-compose.yaml を配置している形にしています。
当然のことながら、各サービスは docker compose コマンドで起動しないとローカル環境は起動しません。が
全部を動かすためには、全部のサービスで
cd ~/visaq/app/{MicroServiceRepos} && docker compose run .... としなければならく、これはなかなかつらい状況です。
また、Micro Service に完全移行をしている状況ではないので、モノリシックな Legacy Service も起動しなければいけません。
visasq❯ tree -L 2 . ├── app │ ├── app-advisor | | └── docker-compose.yaml │ ├── app-search | | └── docker-compose.yaml │ ├── app-vq | | └── docker-compose.yaml │ └── visasq | | └── docker-compose.yaml
どうにかならないのか？？？
ということをちょこちょこ聞くのですが、ごめんなさい俺も知りたい というのが正直な所ですが、わからない状態で大きく行動を取ると
顧客が本当に欲しかったものと別なモノができそうなので、まずは点の課題を解決をしました。
【今本当に解決したい課題】1回で全部のサービスの起動をできたら良い
ということで、docker compose の構成を変えることなく、一回の起動で全てのサービスを起動させるためにはどうしたらよいか？
という所で考えましたが、一番安直な方法として、
全部のサービスの束ねる docker compose を作ればいけるやん
と思いついて、やってみました。
複数の docker compose を束ねる為に事前に必要なこと
1つ目に開発メンバーのローカル環境でリポジトリがどこにあるか？を把握している必要があります。
管理しやすい CLI ツールを作るためのビザスクの取り組みについて
で CLI ツールで自分のワークスペースをどこに配置するか？を設定で持たせるように $HOEE/.config/visasq/cofig.json という設定ファイルを置いて
ワークスペースのカレントディレクトリを知ることができるようにしています。
cat ~/.config/visasq/config.json| jq .
{
# このセクションのactivate が true 以下のディレクトリにリポジトリが展開されます
"workspaces": [
{
"name": "default",
"activate": true,
"currentDir": "/Users/ryusuke.kimura/projects/visasq"
},
{
"name": "sample",
"activate": false,
"currentDir": "/Users/ryusuke.kimura/projects/sample"
}
}
また Micro Service のリポジトリがどれか？を知る必要もあるので、これもCLI ツールで取得できるようになっています。
visasq-ctl repository list ┌────────────────────────────────────────────────────────────────────────────┐ │ application │ https://github.com/visasq/xxxxxx │ サービスAリポジトリ │ ├─────────────┼──────────────────────────────────────────┼───────────────────┤ │ application │ https://github.com/visasq/xxxxxx │ サービスbリポジトリ │ └────────────────────────────────────────────────────────────────────────────┘ . . .
この2つの機能で
がわかるので、各サービスの docker compose のエントリポイントを知る状態になっています。
ここまでができれば、後は束ねる docker compose ファイル少し工夫すればできそうです。
version: "3.9"
x-logging: &x-logging
options:
max-size: 1000k
services:
micro-serviceA:
entrypoint: {micro-service A の EntryPoint}
working_dir: /app
env_file:
- ./{serviceA}/docker/local/app.env
environment:
PORT: 8080
volumes:
- ./{serviceA}:/src:cached
networks:
default: # ホストへのポートマッピングとインターネットへの接続に必要
visasq-local-intra:
logging: *x-logging
micro-serviceB:
entrypoint: {micro-service B の EntryPoint}
working_dir: /app
env_file:
- ./{serviceB}/docker/local/app.env
environment:
PORT: 8080
volumes:
- ./{serviceB}:/src:cached
networks:
default: # ホストへのポートマッピングとインターネットへの接続に必要
visasq-local-intra:
logging: *x-logging
.
.
.
とこんな感じで相対パス指定をしなくてはいけない部分を工夫すると、束ねることができました。
さぁこれで素敵な世界が作れるぞ!!! と起動するわけですが、そうは問屋が卸しません。
$ make local-all
(簡単なTask Runner は Makefile を配置して、起動できるようにしています)
$ docker compose ps NAME COMMAND SERVICE STATUS PORTS visasq-serviceA "docker-entrypoint.s…" app running 0.0.0.0:30070->30070/tcp visasq-serviceB "docker-entrypoint.s…" app running 0.0.0.0:30071->30070/tcp visasq-serviceC "docker-entrypoint.s…" app running 0.0.0.0:30072->30070/tcp visasq-serviceD "docker-entrypoint.s…" app running 0.0.0.0:30073->30070/tcp visasq-serviceE "docker-entrypoint.s…" app running 0.0.0.0:30074->30070/tcp visasq-serviceF "docker-entrypoint.s…" app running 0.0.0.0:30075->30070/tcp visasq-serviceG "docker-entrypoint.s…" app running 0.0.0.0:30076->30070/tcp visasq-DBA "docker-entrypoint.s…" app running 0.0.0.0:30077->30070/tcp visasq-DBB "docker-entrypoint.s…" app running 0.0.0.0:30078->30070/tcp visasq-DBC "docker-entrypoint.s…" app running 0.0.0.0:30079->30070/tcp visasq-DBD "docker-entrypoint.s…" app running 0.0.0.0:30080->30070/tcp . . .
とまぁ全部起動すると Docker コンテナが20程度立ち上がってしまいます..................
いや、まぁMicro サービスとしては正しいんだけども、そこまで重厚でなくても................
と。
ただ暫定的ではありますが、一発で起動はできたので、直近の課題に対しては確かに解決はしました。
いやすごい知りたいのですが..............皆さん 複数のマイクロサービスの効率的なローカル管理って知っていますか.....
こうなんというか、まとまりのない終わりになってしまったのですが、お伝えしたかったのは
- docker compose でローカル構成する形が多いけども、まぁちょっと工夫すれば、一気に Docker Container を立ち上げることはできる
- 暫定的な対応手段としては、まぁどうにかなる
- どこも一緒で Micro サービスのローカル環境難しい問題の一つのパワー的な解決方法ですが、共有したかった
になります。 またもう少し工夫が近いタイミングで必要になってくるので(まだマイクロサービスが増えるので)
もう1段階ローカル環境の改善が進んできたら、アウトプットをしていきたい。と思っています。
ビザスクの SRE チームは、段階的でありますが、継続的なローカル開発環境についてコミットメントをしています。
で、「お前のやり方よりも俺のやり方スマートにできるぜぃ( ｰ`дｰ´)ｷﾘｯ」って思った方は是非こちらも見てください。
GitHub visasq/recruting-public
それではまた
