docker-composeでRailsの開発環境を作って作業しているとMySQL、Rails、Redis、Sidekiqに加えてAdminerなどをサービスとして起動しているひとが多いと思います。
mastodonのdocker-compose.ymlなんかはまさしくそんな感じです。
他にはelasticsearch、tor、privoxyがコメントアウトされている状態です。
version: '3'
services:
db:
restart: always
image: postgres:14-alpine
shm_size: 256mb
networks:
- internal_network
healthcheck:
test: ["CMD", "pg_isready", "-U", "postgres"]
volumes:
- ./postgres14:/var/lib/postgresql/data
environment:
- "POSTGRES_HOST_AUTH_METHOD=trust"
redis:
restart: always
image: redis:6-alpine
networks:
- internal_network
healthcheck:
test: ["CMD", "redis-cli", "ping"]
volumes:
- ./redis:/data
# es:
# restart: always
# image: docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2
# environment:
# - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
# - "cluster.name=es-mastodon"
# - "discovery.type=single-node"
# - "bootstrap.memory_lock=true"
# networks:
# - internal_network
# healthcheck:
# test: ["CMD-SHELL", "curl --silent --fail localhost:9200/_cluster/health || exit 1"]
# volumes:
# - ./elasticsearch:/usr/share/elasticsearch/data
# ulimits:
# memlock:
# soft: -1
# hard: -1
web:
build: .
image: tootsuite/mastodon
restart: always
env_file: .env.production
command: bash -c "rm -f /mastodon/tmp/pids/server.pid; bundle exec rails s -p 3000"
networks:
- external_network
- internal_network
healthcheck:
test: ["CMD-SHELL", "wget -q --spider --proxy=off localhost:3000/health || exit 1"]
ports:
- "127.0.0.1:3000:3000"
depends_on:
- db
- redis
# - es
volumes:
- ./public/system:/mastodon/public/system
streaming:
build: .
image: tootsuite/mastodon
restart: always
env_file: .env.production
command: node ./streaming
networks:
- external_network
- internal_network
healthcheck:
test: ["CMD-SHELL", "wget -q --spider --proxy=off localhost:4000/api/v1/streaming/health || exit 1"]
ports:
- "127.0.0.1:4000:4000"
depends_on:
- db
- redis
sidekiq:
build: .
image: tootsuite/mastodon
restart: always
env_file: .env.production
command: bundle exec sidekiq
depends_on:
- db
- redis
networks:
- external_network
- internal_network
volumes:
- ./public/system:/mastodon/public/system
healthcheck:
test: ["CMD-SHELL", "ps aux | grep '[s]idekiq\ 6' || false"]
## Uncomment to enable federation with tor instances along with adding the following ENV variables
## http_proxy=http://privoxy:8118
## ALLOW_ACCESS_TO_HIDDEN_SERVICE=true
# tor:
# image: sirboops/tor
# networks:
# - external_network
# - internal_network
#
# privoxy:
# image: sirboops/privoxy
# volumes:
# - ./priv-config:/opt/config
# networks:
# - external_network
# - internal_network
networks:
external_network:
internal_network:
internal: true
Railsのルーティングを修正したり、新たなGemをインストールしてinitializersの中身を書き換えたらその設定を反映させるためにRailsの再起動が必要です。
その際、docker-compose upしているセッションをCtrl-C等々で止めて再度docker-compose upするといったことをしていましたがこれが遅い。
なぜなら再起動するたびにRailsだけではなくMySQL、Redis、Sidekiq、Adminerも再起動するからです、時間がかかるのは当然です。
docker-compose restart [SERVICE...]で単体サービスだけを再起動する
あるとき、Railsのルーティングが期待した通りにならず、20回くらい試してるときにこれらの一連の動作が遅くて消耗していました。
例えば、Railsがwebという名前のサービスで動作している場合は
docker-compose restart web
このようにwebだけを再起動できます。
こんな単純なことなのですが、開発のストレスを軽減してくれるのでおすすめです。
他にも--timeoutオプションが指定できたりします、詳細は以下の公式ドキュメントをご覧ください。
docker-compose restart | Docker Documentation https://docs.docker.com/compose/reference/restart/
sidekiqは?
sidekiqの再起動が必要になったら
docker-compose restart sidekiq
このように再起動すればOKです。
ルーティングがうまくいかなかった理由
Railsのルーティングが期待した通りになっていなかったのはresouces usersが2つ記載されていたのが原因でした。
なにかのタイミングでdeviseか元の開発者が2つ記載してしまっていたけど、memberやcollectionを追加していなかったからたまたま動作していたようです。
Rails.application.routes.draw do
resouces :users
(snip...)
resouces :users do
collection do
patch 'import'
end
end
end
このようにimportというアクションを追加したかっただけなのにRailsのルーティングは上から適用されるので下に書いてあるcollection doの箇所は反映されません、それに気づかずにハマってました。