開発環境は プロジェクト毎に Docker で管理してくと後々楽が出来る
読了まで:約2分
と
開発環境をプロジェクト毎に Docker 化する利点
- 普段
使う 環境と 開発環境の 分離が 出来る - 普段
使う 環境から 開発環境を 切り離せるし、 ソフトウェアの 依存解決も 楽になる - また、
普段の 環境では 動かせない ソフトウェアを 開発時に 動かせる 様にもなる
- 普段
- 開発時に
必要な ミドルウェアなどを 使い捨てで 実行出来る docker-compose
を使えば、 コマンド一発で 開発に 必要な サービスを 立ち上げられる - また
コマンド実行を make
経由にすれば、 面倒な コマンド入力からも 開放される
- 開発環境の
再現性が 上がる - 少なくとも
開発環境の 構築に 失敗して ホスト環境が 壊れる って 事は 無くなる - あと
集団で 開発する 場合、 他の 誰かに 開発環境を 用意させる 際も 楽になる
- 少なくとも
開発環境をプロジェクト毎に Docker 化する欠点
- 少なくとも
docker は キチンと 動作させる 必要が ある - また
Windows や macOS では docker を 動作させるのに VM が 必要なる (は ず) - Docker 上の
使わない コンテナを 放置すると、 ファイルの 容量が 結構 消費されてる 事が 発生する
自分の環境(NixOS)での利点
これは
で、elm
でelm
を
ちなみに
etc/docker-compose.dev.yml
- 開発環境を走らせる ための docker-compose.yml
etc/Dockerfile
- 開発環境となるコンテナを 用意する 為の Dockerfile
Makefile
- 上記ファイルを利用する 際に コマンドを make
経由で実行する
とmake
経由でdocker-compose
を
version: "3"
services:
serve:
build: .
working_dir: /app
ports:
- "8080:8080"
volumes:
- ../:/app
command:
- sh
- -c
- "usermod -u 1000 -o node && groupmod -g 100 -o node && sudo -u node yarn install && sudo -u node yarn run serve"
shell:
build: .
working_dir: /app
ports:
- "8080:8080"
volumes:
- ../:/app
command:
- sh
- -c
- "usermod -u 1000 -o node && groupmod -g 100 -o node && sudo -u node sh"
FROM node:current-alpine
ENV NPM_CONFIG_PREFIX=/home/node/.npm-global
RUN apk add --no-cache \
shadow sudo \
unzip zip bzip2 gzip p7zip tar xz \
gmp
CMD [ "sh" ]
.PHONY: serve shell
serve:
@docker-compose -f etc/docker-compose.dev.yaml run --rm --service-ports serve
shell:
@docker-compose -f etc/docker-compose.dev.yaml run --rm --service-ports shell
以上
と