Docker へのLaravelの移植を実行中。悪戦苦闘メモ

Docker へのLaravelの移植を実行中。悪戦苦闘メモ

作成したLaravelアプリを簡単に配布したい。
そう考えて色々検討した結果、Dockerへの移植という案が浮上しました。

しかし(知識不足で)一筋縄ではいかず悪戦苦闘。
これまでの経験を備忘録として残します。

基礎知識編～Dockerの重要なファイルについて

まず先に記載させてもらいます。
これはあくまでもDockerに触って1か月に満たない時点の理解度での備忘録です。
極めていくにつれ「そんなことないよ？」というシーンも多く出てくると思います。
でも、初心者にとってはこの大雑把な理解こそが大切であると思い、そのまま記録として残そうと考えました。
その点、ご理解いただけると嬉しいです。

大雑把なDockerの仕組み

この辺はネット上に記事が沢山あるので、図等での詳細解説は省きます。
大雑把に言えばOSの上に仮想OSを作り、この上にシステムを乗せようというものです。

しかし、他の仮想OSと大きく違う事は『最小構成だけを使おう』という【コンテナ】という考え方。
Laravelの場合で言えば仮想OSの上にApacheやNgnix、Mysql、PHPというコンテナが設置されLaravelの動く環境をこの中で構成します。

一度構成を作成してしまえば別環境でも簡単に作成した環境を展開できる点が最大のメリットです。
Dockerをインストールし、その上に作成した環境を展開すれば同じ状況が出来るというわけです。

Dockerに読み込ませるデータの置き場所

私が最初に悩んだのがこれです。
フォルダ構成は分かったけど、それをどこに置くのさ。

結論は簡単でした。【どこでもいい】のです。

理由は、Dockerの構成ファイルを展開する際にそのディレクトリの構成ファイルをdocker-composeで読ませる為、どこに置いていてもパスで渡せばOKと言う事です。

最初の混乱の元凶、Dockerfileとdocker-compose.yml

コンテナの読込をdocker-compose.ymlに書いてこれをdocker-composeに渡せばよい事は分かりましたが、WEB上の記事は書き方がバラバラです。

記事によっては両方とも記載しているものもありますし、一方だけのものもあります。
Dockerfile って当たり前のように書いてあるけど、それがそもそも解らない…。初心者からするともう何が何やらｗ

と言う事で、まずは次のように理解しました。

非常に≒ではありますが、大きく違う事が1つあります。それが下の項目【build】と【image】です。

build:とimage:の違い

docker-compose.ymlに記載する項目の中に、buildとimageがあります。

この2つは上のDockerfile が関係しどちらかをchoiceします。

※2つとも記載している記事を見かける事もありますが、私はこれが正しいのかわかりません。少なくとも一方だけにした方が環境構築は判り易くなります。

image も build も使うイメージを宣言しているパーツですが、Build は文字通りイメージをビルドするための宣言です。その為、基本構成から大きく変わらないのであればimageを使うことが多くなると思います。

Dockerfileで出来る事

これまで触った感じでは、大体の事は出来るのではないかと感じています。
得に便利なのが、コンテナ作成時に様々なアプリを登録できるという点です。
例えば、PHPのコンテナが展開する際にcomposerまでインストールしてしまうとか、MeCabを入れるとか、そんな設計を簡単に行えます。

課題は、Dockerfileを作り変えた時にIDが変わる為、何度も作り変えると使っていないイメージが大量に格納されている事です。完成系が出来たら不要なものは削除するというのがベストであると思います。

私が悩んだのはmysqlコンテナ作成時のこんな事です。

これは Dockerfile で作成する事も エントリーポイントを作成してvolumesで読ませて実行させることもできます。

と言う事で、次はVolumesで何が出来るのかを記載します。

volumes:で出きる事

基本的に、コンテナの中で操作する事は一通りできるようです。

例えば、先に挙げたmysqlのデータベース作成とユーザー作成はvolumesにsqlファイルを読ませることで実装できます。

Dockerは、Volumesで指定されたフォルダの中の【.sh】【.sql】ファイルを全て読み込み実行してくれます。特にmysqlのイメージに記載しているVolumesでは .sqlに記載したデータはコンテナ >> myaql -u name -ppassword でログインした状態で展開してくれるため、SQL文を書くだけでやりたいことが揃うという優れものです。

記載方法は例えば次のような感じです。

docker-compose.yml での指定は ./entrypoint/initdb.d/ だけですが、このディレクトリに格納された【.sql】の記載されたファイルを勝手に読み込んでくれるので create_star.sql をしっかりと展開してくれます。

evn_file:とenvironment:

上の【docker-compose.yml】の例ではもう一個特徴のある書き方があります。

これです。
ネット上の多くの事例では以下の様に記載されている事が多いです。

実は、env_file:で行っている事もこれと同じです。

違うのはファイルとしてまとめて置いたものを読み込ませているか、直接 docker-compose.yml に書き込んでいるかのみです。

env_fileでの指示はファイルの拡張子も含めて指定する為、命名ルールはありません。
また、Directoryの構成ルールもないため、自分が分かりやすい方法で管理する事が出来ます。
※.env.devのファイル名はデベロッパー用の.envだよと意味を付加して命名しただけの自社ルールでこれでもOKです。

まとめ

Dockerで構成できればシステムのお客様への納品が格段に速くなると思い作成に踏み切りました。
が、やはり一筋縄ではいかないなぁ～と実感しています。

さぁ、スーパーセールも近い事だしあっちもこっちも全開で頑張っていきましょう！