はじめに

開発環境のセットアップは重要ですが、それと同時に非常に面倒だと感じています。
プログラマー三大美徳の1つである「怠惰」を叶えてくれるDockerについて記事を書きたいと思います。

Dockerを使った開発環境構築の流れ

要件定義

まずどんな技術スタックを使用するかを決める
- Next.js
- Rails
- MySQL etc

ディレクトリの構成を決める

my_app/
├── backend
├── frontend
├── docker-compose.yml
└── Dockerfile

Dockerfileの作成

イメージの設計図となるDockerfileを作成する

FORM	ベースイメージを指定
WORKDIR	作業ディレクトリを設定
COPY	ローカルファイルをコンテナ内へコピー
RUN	コマンドの実行
CMD	コンテナ作成時に実行されるコマンドの指定

docker-compose.ymlの作成

複数のコンテナをdocker-composeで管理する
起動のための設定を記述することによって、複数のDockerコンテナをひとつのコマンドで立ち上げることができる

コンテナのビルドと起動

イメージをビルドする

docker-compose build

コンテナを起動する

docker-compose up

コンテナとボリュームについて

自分はコンテナ内の作業が保存されないと聞いて、最初は「じゃあ意味ないやん」と思ったのですが、ちゃんと解決策はあります。
データや設定の永続化にはボリュームを活用することで、必要なデータを保持することができます。

コンテナの概念

コンテナとは、アプリケーションを実行するための独立した仮想環境です。
各コンテナはアプリケーション実行に必要なパッケージやライブラリを含む
軽量であり、あくまで実行環境の為不要になったら削除できる。
コンテナ内の作業や設定はコンテナが削除されると失われる
コンテナは何回も壊して作り直すもの！！

ボリュームの概念

ボリュームはコンテナ内で発生する永続的なデータを保存するための場所
ボリュームを使うことでデータが削除されず保存することができる。
例えば、MySQLコンテナ内で扱うデータベースのデータは、ボリュームに保存します
コンテナを削除して再構築しても、データベースの内容はボリュームに保持されているので、再起動後もデータは保持されます。
ローカルの変更内容がコンテナに反映される為ローカルとコンテナ間でデータを共有することも可能(ボリュームマウント)

ボリュームとボリュームマウントの違い

ボリューム
データの保存場所
ボリュームマウント
コンテナとボリュームを接続すること

実際にDockerを使った開発の流れ

1. Dockerfileから作成されたファイル(frontend, backend)のコードをローカルで編集

2. コンテを実行し、Railsのサーバを動かす
ローカルで編集したコードはボリュームマウントによってコンテナに反映される

3. コンテナ内で作業
コンテナへログイン

docker-compose exec コンテナ名 bash

データベースをマイグレーションしたり、必要なツールをインストールする

4. コンテナの停止
作業が終わったらdocker-compose downで停止
コンテナの作業は消えるがローカルの変更は保持されたままとなる

まとめ

Dockerは開発環境のセットアップを簡単にして、開発環境と本番環境で差異を無くし異なるユーザ間でも同じ環境を再現することができる
コンテナは軽量の一時的な実行環境であり、ボリュームを使うことでデータの永続化が可能
ローカルでコードを編集しコンテナ内で実行することで効率的に開発が進められる