はじめに
Debian限定で書いていますが、どのプラットフォームにも当てはまる話だと思います。
apt-get install mysql-clientが失敗する
これは去年の9月頃にTwitterで話題になっていました。
Oracleがmysqlに意地悪したのでmysql-clientパッケージはdefault-mysql-clientへ変更になりましたという話。
修正方法については下記ブログ様の記事を参照ください。
yourmystar-engineer.hatenablog.jp
自分のリポジトリも影響を受けたのでdefault-mysql-clientに変更することで対応しました。
が、その際に考えました
apt-get install xxxxだと、その時点のリポジトリの環境に左右されるので
「 直接リポジトリのURLを指定してビルドした方が良い かもしれない。」と。
(けれどもDockerfileの見通し悪くなることが嫌だなとも考えてました。依存関係pkgも同じ方法にでinstallする必要があるため)
であれば直接URL指定してpkgを取得すれば良いか。
と思って下記の様な感じで置き換えてました。
※1
# wget https://deb.debian.org/debian-debug/pool/main/n/pkg名/mysql-client_all.deb # apt install ./mysql-client_xxxx_all.deb
すると、暫くの間は問題がなかったものの、また docker-compose up --buildの際にリポジトリ が404だったり503でビルドに失敗する様に。
ググったら似た様な事象の方を発見。
上記の例はリポジトリのlistの取得に失敗する例ですが、
pkgの場所が変わることを考慮していなかったため、取得するURLが変わると対応できなくなる。
(debianも自分等のリポジトリ内ならリダイレクトぐらいしてくれても良いのでは？)
結果どうしたか
- 定期的にCIツールで監視して失敗の都度対応したりするのが良い...?
けれども個人開発のツール群等に割くリソースがあまりないので
ソースからビルドする作戦で当分はごまかすことに。。。
依存関係が多いpkgはURLが変わることが多い様なので、
- どうしてもしくじりたくない時間のかかるライブラリ はソースから取得してきて、ビルドする。
のがまだましなのかな、という結論になりました。今の所。
参考までに、dockerhubに上がっている公式イメージのDockerfileの多くは apt install {パッケージ}としているので、私のしている事は時代に逆行しているかもしれません。
ところでDocker神話の理由
普段、様々なプラットフォームで仕事しているので
ツールを開発する際にまずdokcerイメージを作成してホストに依存しない環境作りをしています。 PC変えてもツールは動くのでまぁ便利。
Windowsだろうが、Macだろうがdocker-compose up --build して使いたいコマンドは execをすることでわざわざ環境構築をせずにいつでもどこでもちょこちょこ開発できていたのですね。
はじめに Dockerfileを作る手間がありますが、途中で依存関係につまずくことが少なくなるので逆に開発速度は向上しました。(体感)
注記
- よわエンジニアなので依存関係の解消はDockerfileを作る前に手動で確認する。
- 自分用のツールだし最新版の更新より依存関係解消に注力する。
