そんな今日この頃でして、、、

コード書いたり映画みたり。努力は苦手だから「楽しいこと」を探していきたい。

Dockerを本番投入した話

このまま忘れてしまうのも勿体無いので記録に残しておこうかなと。

blue1st.hateblo.jp

技術系のネタは最近は別ブログの方でやってたけど、具体的なコードなんかは無いので今回はこっちで。

blue1st-tech.hateblo.jp

思い出した・思いついたら随時追記していく予定。


概要

フィーチャーフォンの時代からのサービスで、 無茶な拡張や教育不足や委託によるアレな開発状況によって、 コードも環境も技術的負債が山盛りの状態だった。

幸いにしてサーバを移設する機会に恵まれたので、 状況を改善するべく検討を進めた。

解決したかった問題

様々な部分において、環境ごとの差異が看過できない状態になっていた。

サーバによってインストールされているランタイムやモジュールのバージョンが異なることもあれば、 パスが異なることをコードにベタに記述してバージョン管理しないことにより対処している部分があったり、 そもそも環境によって同名のスクリプトの内容が書き換えられていたり。

バージョン管理ももはや正しく機能していなくて、必要なファイルだけ明示的に本番環境に上げるような綱渡りな運用になっていた。

おそらくリアルタイムでは、「急いで対応しなきゃいけないから仕方ない、後でちゃんと揃えよう」とかなんとか考えていたのかもしれないが、 往々にしてそういう意識は長続きしないもの。

結果として、どのサーバ環境での挙動が「正」なのかも分からない状態となっていた。

こうなってくると新たに環境を構築するのも困難だし、 リリース前の検証作業も不確実なものとなってしまう。

Dockerの導入

もちろんそれぞれ個別には対処法はあるにはあるんだけど、 それを全て長期的に完全に徹底していくことは困難なように思えた。

個人的には「気をつければ」とか「ちゃんと確認すれば」とかいった前提で成り立っているような運用というのは即ち無用にリソースを消費している状態なので、 今問題ないからといって看過すべきではなくすぐにでも改善すべきだと思っている。

そういったストレスを抱えながら開発運用していくよりも、 Dockerを用いた「可搬性ある形」を前提として使い方を習得してもらうほうが現実的で長期的なメリットもあると考え導入に踏み切ることにした。

(とはいえ、僕が使いたかったから理由を揃えて押し切ったという側面はちょっとある。 退社時期的にちょっと申し訳ない気もしている。)


続きを読む