入社後最初にしたことは “開発環境の Docker 化”
初めまして。LENDY を始めとしたサービス開発をしている中谷 (@tsukachu )といいます。
基本的に開発メンバーは東京のオフィスにいるのですが、現在は私だけ大阪からフルリモートで開発に参加しています。
実は昨日入社して丸 1 年が経過しました。
そこでこの 1 年を振り返って入社後に初めて投げた Pull Request の内容を記事にしました。
なぜ Docker の環境を追加したのか
当時リポジトリの README には一通り環境構築の手順が記載されていました。ただ各アプリケーションのインストールは brew install ~~~ だったり、DB の初期化や環境変数の設定等も各自ローカルで実行といった内容でした。
別のリポジトリでも同様の README があったので開発環境の準備が面倒な印象を受けたので、当時プライベートで Docker を利用し始めていたこともあり思い切って Docker 関連の Pull Request を作成したという経緯です。
当時投げた Pull Request の内容
当時は Docker の環境を全員で使おう、という流れではなかったのでレジストリは用意せず Dockerfile と docker-compose.yml の追加のみを実施したようです。
Docker を利用したかったら各自で image をビルド、というのは振り返ってみるとなかなかひどい。
ただこれでアプリケーションのインストールは Docker だけになったので、次は DB の初期化周りです。
DB の公式イメージに対して初期化を行いたい場合は以下の様に Dockerfile で/docker-entrypoint-initdb.d に対し sql ファイルを追加するだけです。
FROM ~~~~~~COPY /path/to/init.sql /docker-entrypoint-initdb.d
次に別リポジトリのプロジェクトと通信する場面があるので network 周りの整理です。
repository_a にある docker-compose.yml で docker-compose up をすると通常は、
$ docker-compose up -d
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
...
0f1b381a20f8 repository_a_default bridge local
...というように新しく network が作成されます。
なので repository_b に単純に docker-compose.yml を追加しても repository_b_default という network が作成され、別々の network になってしまい疎通が出来ません。
そこで repository_b の docker-compose.yml では以下の様に repository_a の network に属するようにしました。
version: ~services: app:
...
networks:
repository_a_default:
... ...networks: repository_a_default:
external: true
この段階で一通り問題なく開発が出来る環境になりました。
Docker 化してみて思ったこと
“Docker には Docker 特有の問題がある” ということ自体は否定しませんが、やはりリポジトリを clone して docker-compose up するだけで開発を始められるのは便利だと思います。
実は上記の Pull Request 以降も Docker の環境は少しずつ更新していっています。
また以前はリポジトリの README に情報を集約してましたが、現在では社内 wiki に環境構築のページを用意しリポジトリの clone から開発着手までの手順を一通り記載したりなど、新規の開発者も参加しやすいようになってきています。
一年経ってどうなったか
新規のプロジェクトでは全員が Docker の環境を利用するようになりました。それもあってレジストリに ECR を利用するようになり、中々形になってきた印象です。
ただ image の build/push の自動化には至っていないので、CI での自動化が次の課題だと感じてます。
今後もこういった過去に投げた Pull Request からネタになりそうなものを記事にしていこうと思うので、今後ともよろしくお願いします。
