コンテナ起動時間の改善

[sudachi0114]

• やりたいこと

  • 元祖目標: DB プロセスの起動待ち
  • go の web アプリケーション自体の起動を、DB (MySQL) のサービスが起動してから (サービスが立ち上がって疎通が成立することが確認できてから) 行いたい。

• 何故やりたいか

  • (今はお勉強が本当の理由だが、本来は) サービスの安全性 (安「定」性?) のため

---

• できていること
  • 現在、コンテナ単位では db コンテナが起動してから、app コンテナを起動するようになっている。
  • 以下のように、docker-compose.yml の app で depends_on に db を指定することで、db コンテナが起動してから、app コンテナが起動するようになっている

  app:
    build: 
        ...
    depends_on: 
      - "db"
  db:
    ...

[sudachi0114]

db コンテナの起動を待ってから、app コンテナを立てることで
アプリケーションの起動までの時間が、体感的に少し遅くなった感じがする。
(いろいろいじって変更しているからかもしれないが..)

[sudachi0114]

いちいち go get しているのがよくないっぽい??
build したものを起動.. それでもビルドする以上は go get が必要か..

[sudachi0114]

Dockerfile の方でビルドして、ビルドしたバイナリを実行することで高速化している例があったので
それに習ったのだけど、ソースの変更が反映されなくなってしまった...
( 途中でﾁｮｯﾄ気がついたし、それはそう..という感じなのだが..
参考元はどうやってファイル更新をかけたことを反映させているんだろう, という話になる..)

• 以下は知見
  docker-compose.yml で Dockerfile を参照している場合
  それによって docker image が作られていて (つまり、この ⬆️ Dockerfile からビルドされているイメージがある)
  Dockerfile が更新されたとしても、イメージがリビルドされたりすることはないっぽいです。

なので、更新がかからないなあ..と思った時は
project-name_service-name とかいうイメージがあった場合は、そのイメージを再構築することで反映させなければいけない
今回は web-db-doker_app というイメージがあって、それを Dockerfile の変更に対応させてあげる必要があった。
(対応させる <- How? -> image (今回は web-db-doker_app) を rm すれば、次に docker-compose up が呼び出されたときに、再びイメージのビルドが行われる)

あと、Dockerfile を更新して、それが反映されているつもりで、docker-compose.yml から必要だった処理を外して
docker-compose up すると、コンテナ内で実行されるハズだったコマンドが実行されない (今回は)
-> ログが出力されない
-> 何が悪いのかわからーーん
となってしまったので、Dockerfile を使う場合は、一度それだけで docker build . して、そのイメージが正しく使えるかどうかをチェック
＋ docker-compose 使う場合は、docker-compose 用にビルドされたイメージの消去
を合わせ技でやらないといろいろ困ることになる

(＋欲しい知見: docker build のときの log ってもうちょっと Host 側の標準出力に出力されませんでしたっけ?
--verbose みたいなオプションないのかな.. コンテナ内で行ってる ls の実行結果とかみたいのになー)

[sudachi0114]

追跡調査: 参考にしてたやつは、ソースの反映がそのままコンテナイメージに反映されてなかった。
エンドポイントを新たに追加して、コンテナを立て直してみたけど、反映されなかった。
使用されているイメージをいったん手動で削除して、再び docker-compose up を行って、イメージのビルドを行ったら、新たに作成したエンドポイントで応答があった。

なので、local では test で動作保証して、その保証の元に新たにイメージをビルド -> コンテナ作成 -> サービス (API)
という感じになっているんだろうと推測。

新たな疑問: では、go の開発 (web API のバックエンド開発) における docker の使い方のベストプラクティスってどんな感じに使うものなんだ..??

[sudachi0114]

docker-compose で使用している Dockerfile によりビルドされるイメージは

docker-compose build

でビルド (リビルド) できるらしい。

ref: https://zenn.dev/tomi/articles/2020-10-14-go-docker

[sudachi0114]

go の場合、ソースの更新があると「新たなソースに基づいて、ビルドしてサービスを実行」という感じになるが
ソースの更新に応じて、コンテナ内のサービスにホットリロード機能をつける (再度ビルドを走らせる) には realize というライブラリを使うのが良いらしい。

ref: https://zenn.dev/h_sakano/articles/b38336d99f43e4e9e90b

Docker go ホットリロード [検索]
とかしても、realize が多く出てくる。

[sudachi0114]

次点 (後発?) で Air というライブラリもあるそう
ref: https://teitei-tk.hatenablog.com/entry/2020/12/04/164126

あと fresh というのもあるらし
ref: https://github.com/gravityblast/fresh
( fresh よりも、realize の方が細かく設定できるとのこと)

逆だった。realize の方が開発が止まっている感じ..

手元で環境作ってみようとしたら go get ができなくて困った..

$  go get -u github.com/oxequa/realize
go: github.com/oxequa/realize upgrade => v2.0.2+incompatible
go: finding module for package github.com/oxequa/interact
go: finding module for package gopkg.in/urfave/cli.v2
go: finding module for package github.com/labstack/echo
go: finding module for package github.com/fatih/color
go: finding module for package github.com/go-siris/siris/core/errors
go: finding module for package github.com/sirupsen/logrus
go: finding module for package github.com/fsnotify/fsnotify
go: finding module for package github.com/labstack/echo/middleware
go: found github.com/oxequa/interact in github.com/oxequa/interact v0.0.0-20171114182912-f8fb5795b5d7
go: found gopkg.in/urfave/cli.v2 in gopkg.in/urfave/cli.v2 v2.3.0
go: found github.com/fatih/color in github.com/fatih/color v1.10.0
go: found github.com/fsnotify/fsnotify in github.com/fsnotify/fsnotify v1.4.9
go: found github.com/go-siris/siris/core/errors in github.com/go-siris/siris v7.4.0+incompatible
go: found github.com/labstack/echo in github.com/labstack/echo v3.3.10+incompatible
go: found github.com/labstack/echo/middleware in github.com/labstack/echo v3.3.10+incompatible
go: found github.com/sirupsen/logrus in github.com/sirupsen/logrus v1.8.1
go: github.com/oxequa/realize imports
	gopkg.in/urfave/cli.v2: gopkg.in/urfave/[email protected]: parsing go.mod:
	module declares its path as: github.com/urfave/cli/v2
	        but was required as: gopkg.in/urfave/cli.v2

go version < 1.13 (?) くらいまでなら一時的な解決作もあるらしいが..
「負債」になるみたいなことが

確かに realize は release も2018年で止まってるなあ..

[sudachi0114]

結局 air を使って

やることは

• コンテナへ、ソースコードの置いてあるボリュームをマウント ( docker-compose.yml で定義)
• .air.toml でビルド (のコンテキスト? って読んでいいのか? フローなのか?) を定義
• app コンテナで air -c .air.toml を実行

すると、マウントされたボリュームに配置されているソースコードの変更を感知して
リビルド -> サービス提供をしてくれる。嬉しい。

refs:

• x: realize + dockerでGolangのホットリロード付き開発環境を構築する
• Realize から Air に移行し、 Go(echo) + Air + docker-compose でホットリロードを利用して開発を行う。
• air 公式 .air.toml サンプル

TODO: blog の記事にする。

---

docker の alpine image でサービス提供しようとすると timezone 周りで失敗することがあったので

• Timezoneが取れるalpineのDockerイメージを作る
• Alpine LinuxでDockerコンテナ開発を加速する

この辺、もう少し勉強したいなあ..

---

commit: 3fae569 にて Air を組み込むことで解決