「Docker で動くようにすること」(to dockerize)じゃない、ツールの方の dockerize (jwilder さん作)を使って、同じDocker network 内(setup_remote_docker したもの)に立ち上げ中のコンテナの準備ができるのを待たせる方法。
# 名前が紛らわしいのは検索性を低めてると思いますが
どうせならツールも自力でセットアップせずに docker hub にあるものを呼べばよいということで、
docker run jwilder/dockerize -wait http://sample.test/ -timeout 3m -wait-retry-interval 5s
上は、http://sample.test/ が応答を返すまで、最大3分間、5秒おきに問い合わせ。
CircleCI の中で待ちたかった(コンテナの立ち上げが終わってからテストを流す)ので、ターゲットのコンテナと同じ Docker network でこれを呼ぶと、.circleci/config.yml は
- steps:
(中略)
- run:
name: Run Docker Containers
command: docker-compose up -d
- run:
name: Wait until the target docker container fully set up
command: |
docker run --network my_network \
jwilder/dockerize -wait http://my_service/about/ -timeout 3m -wait-retry-interval 5s
- run:
name: テストとか
こんな感じでいけました。
CircleCI公式のDocker image には dockerize も入ってる
しかし、その後、CircleCIの用意してくれているDockerベースのDocker Container を使う場合、そのコンテナには Docker だけでなく Docker Compose や Dockerize も含まれているということに気づきました。
「あれ? じゃ上のコード無意味で、直接 dockerize を呼べばいいだけでは?」と思い直し、これを試してみたのですが、
- run:
name: Wait until docker container fully set up, from the same docker network
command: |
dockerize -wait http://my_service/api/doc -timeout 3m -wait-retry-interval 10s
ネットワークが違うのでアクセスできません。そりゃそうか。CircleCIの中で立ち上がったDocker MachineのIPアドレスが取れれば、それでアクセスできそうだけど。
ドキュメントにありました。同じコンテナか、同じネットワークのコンテナからのアクセスとするのが正しいやり方のようです。CircleCIが使ってるprimary のコンテナにはもう Dockerize コマンドの実体があるので、同じものを再度リモートから取得するのはもったいない気もしますが。
sleepでwait
CircleCI のドキュメントのサンプルでも
- run:
command: |
git push heroku fan-in-fan-out:master
heroku run rake db:migrate
sleep 5 # sleep for 5 seconds to wait for dynos
heroku restart
みたいなことが書いてあって、”sleep 5″って、それいつでも大丈夫なの? と思ったので調べました。まあサンプルはサンプルなので。
