前回、前々回に引き続きインターン中に行ったメニューについて書かせていただきます。
メニューについて
このメニューは、実際に稼働しているMySQLサーバをDockerのコンテナに置き換えることを主目的としたもので、以下のように進めました。
MySQLの設定などを確認する
docker-compose.yamlを書く(コンテナを作る)
本番環境へのデプロイ手順をまとめ、メンターなどに問題がないかを確認
実際にデプロイ
実際にしたこと
1. MySQLの設定などを確認する
実際に置き換えるサーバへログインし、MySQLの稼働状況や設定などを把握しました。
2. docker-compose.yamlを書く(コンテナを作る)
前回までに得た情報や、1で得た情報などをもとに、docker-compose.yamlを書いていきます。
今回、MySQLで扱っているDBが400GB近いサイズのスレーブだったので、レプリケーションにかなりの時間がかかってしまうことや、ホストのストレージ容量の空きが無いなどで、一からマスターDBとレプリケーションをするのは不可能な状況だったので、コンテナからホストのMySQLのデータベースディレクトリをマウントする方法を取りました。
3. 本番環境へのデプロイ手順をまとめ、メンターなどに問題がないかを確認
今回は時間がそれほどなかったので(インターン終了日前日の退勤時間直前)、メンターの方がデプロイ手順をまとめてくださりました。
4. 実際にデプロイ
実際に作ったコンテナをデプロイの手順に従ってデプロイしました。
ここで問題が発生しました。データベースに対しIPアドレスでアクセス制御をかけていたのですが、Dockerのネットワークがブリッジになっていたため、アクセス元のアドレスが正しく認識されず、アクセス拒否が発生してしまいました。
これの解決策としてmysqlコンテナのnetwork_modeをbridgeからhostにし、ホストのネットワークを利用することにより、解決しました。
感想
RDBはコンテナ化に向いていないアプリケーションだと感じました。
特にデータが大きくなるような環境の場合、今回のようにホストのディレクトリをマウントすることになり、MySQLの公式が推奨している方法と大きくかけ離れていまい、あまりよろしくないからです。ちなみに推奨されている方法は起動時にdumpデータを読み、終了時にdumpデータを吐き出す方法ですが、こちらもデータベースの規模が大きくなると現実的な方法ではなくなってしまいます。
このメニューを通して私は、何でもかんでもコンテナにするのではなく、コンテナにしたときのメリット・デメリットを見極めて行かなければならないと実感しました。
