今まで、オンプレミス最高だ…と思っていたわけではないですが、新しい技術から安定しつつある技術になっているDockerを触ってみたのでメモ。

技術を適切に使うには『適材適所』であることを忘れない

サーバレスにしても何にしてもそうなのですが、技術って結局『適材適所』なのですよね。サービスの設計思想であったり、ユースケースを考えて設計すべきだなと改めて思わされます。

たとえば、アプリケーションの構築にしても前提がDockerホスティングであるかどうか、によっても異なっているように思いますし、結果としては設計時にきちんとディスカッションする必要があると思っています。

同一サーバ内で環境依存を減らすことができるのは素晴らしい

それでも、今後Dockerと向き合っていく必要があるポイントとしては『環境依存』を少なくすることができるからだと思っていますし、再利用性が高いということにも繋がります。

また、環境移行などがあった場合にも同様にサクッと移動することができることは素晴らしいことです。ボリュームとか移行してしまえば最低限の構築で終わらせることができます。

とくに、Sonatype Nexus Repository Managerのインストールをやってみた（2019年5月編） - focusmark.で記載しているシステムとは相性がすごく良いと思っています。
その理由として、Dockerコンテナは動くようにセットアップされている点もありますが、プログラミング言語のバージョンが他の環境に依存しないということも挙げられます。

HTTPサーバはDockerコンテナ化させるのか否か

仮想サーバ上に個人が複数サービス立ち上げたりするときに利用するのであれば、Dockerコンテナで起動させるのではなく、ネイティブで存在させておくのがベスト・プラクティスではないかなと思っています。

初心者なのでよくわからない、ということもありますが、

  • 80番や443番など使う複数のサービスを並行的に利用し、設定がある程度流動的に変わる可能性が高いため
  • TLS証明書などの更新時の処理が面倒そう（偏見）

また、何かしらのファイルのみを置く場合などシンプルな構成を行うためにDockerを起動することも考えると『ちょっとしんどいなぁ…』という感じになります。

この辺りのことを考慮すると、はじめに粒度を決めておいて、Docker化させるか、従来どおりのインストールを実行するか考える必要があると思っています。

もちろん、Docker化させることによって、再現するときの苦労は減ると思いますが、たいてい構築するときってほとんど同じようなOSなどを使うので、最新のものに切り替える手間ことを考えると存在していないものは割り切ったほうが早いかなと思っています。

また、同じような設定を利用する場合はシェルスクリプトなどを組んだ上でサクッと適応、というようなことも視野にいれたほうが良いかもしれません。（nginxの設定であったり、将来的に移行する可能性のあるツールであったり。もちろん、シェルスクリプトの動きを確認するために使い捨てのDockerコンテナを用意する、というのはあると思います。）

改めて思う『インストール』の大切さ

最後のオチとして、全部Dockerコンテナにするのはやめといたほうがいいぞ！ということです。もちろん、バージョン依存があるようなシステム（Javaとか）はDocker化させておいたほうが幸せになると思いますが、オーバヘッドなど考えると大切だと思います。

それ以上に、「Dockerが流行っているから」といって、安易にDockerを使うのは良くないと思っています。というのも、結果として設定時のコマンドなど、意味を理解せずに無防備なサービスが多く存在することはある一種の恐怖でもあると思っています。

その上で、ローカルでの検証などデザイナーが行う場合はコンテナは便利なものですし、複数のサービスを運用する場合にサポートされているアプリケーションのバージョンが異なる場合にも気にせず運用できます。冒頭にも記載した通り、『適材適所』で使い分けていく必要があるのではないでしょうか。