あと、MySQL のコンテナを複数立てて、Master/Slave 構成にしているんだけど、コンテナでそこまでやるケースって、そんなに多いんかな。
RDB のクラスタ構成だったら、RDS なり SQL Database といったマネージドサービスを使う方法が主流では？　といった疑問が出てきたりもしたので、本に書いてある事を全て実践してみるかどうかは未知数だ。

また、ローカルでいくつもコンテナを立ち上げているという都合上、ベースは Alpine を使っている。
絶対に使った方がいい理由がない限り、Alpineは避けた方がよいのでは？（「軽いから！」という理由だけで Alpineを採用するのは危険なのでは？）と、さんざん調べてそういう結論に行き着いたので、Alpine をゴリゴリ使い倒す前提で進めていく必要があるかどうかは迷いどころだ。

詳しくは、Dockerfile も docker-compose.yml も雰囲気で書いてたんで、ちゃんと勉強しなおしてみた。の、「Q. Dockerイメージのベースディストリは、Alpine がいい感じなの？」のトコに書いた。

感想

「開発環境の構築は、Dockerを使えば簡単！」
みたいな話が時々聞こえてくるけど、アレ多分、
「docker-compose.yml と Dockerfile を書いてくれた人がチームにいて、それを利用しているだけ」（中身は理解していない）
か
「Web上に落ちてた ocker-compose.yml と Dockerfile を使ってるだけ」（中身は理解していない）
のどっちかだと思う。

ベースイメージを選定するだけでも相当苦労したし、ベースイメージで使用しているパッケージマネージャーが何なのかを知るだけでも凄い苦労をさせられたし、Dockerfileをちゃんと書くためには Linux の知識が絶対に必要になるし、Dockerfile の書き方だけじゃなくて docker-compose.yml の書き方も知っておく必要があるし（Dockerコンテナを単体で動かす事なんて、ほとんど無いと思う）で、結構大変だぞ？

「Laradocを使えば簡単♪」といった類の意見も、ちょっと受け入れられない。
ちょっと触ってみる、という程度の用途ならアリだと思うけど、あんな巨大で恐らくはプロダクトでは使用しないイメージも大量に詰め込まれているセットなんて、実プロダクトでの使用はアウトだろう。
（「不要な部分をカットし、必要な分だけを絞り込めばいい」という意見もあると思うが、そもそも Dockerfile をちゃんと書けない人間が、そんな事ができるとは思えん。少なくとも自分はできなかった。）

「有志が作成したイメージ」も、危うさが残る。
そのイメージの作者がバージョンアップにずっと追従してくれる保証なんてどこにも無い以上、本番環境への導入を見据えた上で使うのはド危険すぎる。
それに、何かしらの追加が必要になった場合、その第三者が作成した Dockerfile 解析する必要があり、それも結構手間だし。
そういのは、「ちょっと使って、後は捨てる」といった用途に限った方がいいと思う。

バージョンアップの必要性が迫ってきて、作者がバージョンアップに追従していなかった場合、公式のイメージをベースにまた Dockerfile を書き直す事になる可能性がある以上、最初から公式のイメージをベースにしといた方がよくないか？　そして、公式のイメージをベースとした Dockerfile をちゃんと書けるようにしといた方がいいんじゃないのか？

・・・って考えて、「今まで雰囲気で書いてたけど、ちゃんと書けるようにしとこう」と思って調べ始めたら、こんな状態だ。
正直、ここまで時間かけるつもりは無かったが、環境構築の土台の部分だし、いい加減なままにしておくと後で酷い目に遭う可能性は非常に高そうなので、納得いくまできっちり調べる事にした。

人によっては「やりたい事があるなら、それに向けて最短距離で走るのが正解だ」
という意見もあるだろう。
が、俺はこの場面において、土台の知識を固める方向を選んだ。

その考えが正解なのかどうかは知らんし、効率がよかったのかは知らん。
分かるのは多分、数ヶ月後～数年後だ。

Relative Posts:

【Docker】WordPress のテーブル定義書をドキュメント化してみる

May 3, 2021

Docker hub にて、イメージ選択した時に出てくる「OS/ARCH」の選択項目について、詳しく調べてみる。

June 23, 2020

福岡の物流エンジニアが、七転び八起きしたあと九回転び、寝っ転がったまま何かやってる事を垂れ流しているブログ