Dockerでよくある話。最近立て続けに典型的なのを踏んだので書いておきます。Dockerを運用する上で気をつけるポイントについてです。
ブログサーバーのアップデートで出会ったトラブル
このブログサーバーは、ConoHa VPS上でdocker-composeによって構成されています。SSL証明書意外、すべての設定をGitHubで管理しており、デプロイや構成管理もちゃんと出来てとても便利な環境です。
ところが、トラブルは突然にやってくるもので・・・最近出会った2件をご紹介します。
事案１：CentOSでMariaDBが起動しなくなった事件
まずはCentOSです。MariaDBを動かしているコンテナがCentOSベースなんですが、ある時、ベースイメージをアップデートしたら、MariaDBが起動しなくなりました。
特に何かを変えたということはなく、ベースイメージとなっているCentOSのimageをuntagして、再取得し直したくらい。データ領域は外部ボリュームですので、データ紛失は無いです。もちろんMariaDBのバージョンも上げてませんし。
で、なだろう？と思ったら、なんとユーザーmysqlのuidが変わっていた（1個ズレていた）。これによって、データディレクトにアクセスできず、起動できなくなってしまったのでした。データディレクトリのオーナーを更新して解決しました。
これがDockerでは良くある「latestの罠」です。ベースイメージとして「centos:latest」とか取ってきちゃうと（っていうか、デフォルトで「centos」をpullすると、「centos:latest」が落ちてきます）、実はバージョンが上がっていた、なんてことがあるわけで。そのタイミングで、システム定義のユーザーアカウントが変わっていたりすると、こういうことが起きます。
これを避ける方法としては・・・
- イメージをバージョン指定でpullする。「docker run -it centos:6.9 /bin/bash」等
- メリット：環境が大きく変わってしまうことを避けられる。
- メリット：パッチレベル等を安定的に追いかけられる。
- デメリット：最新ではなく、古いOS環境を使い続けることになる。
- デメリット：イメージ、OSがいつまでメンテされるか不安。
- uidを含めた、アプリケーションの期待する設定については、システムデフォルトに期待せず、確実にプロビジョニングで設定する
- メリット：ベースイメージに左右されない環境を維持することができる
- メリット：アプリケーションの必要とするシステム設定までリポジトリ等で管理できる
- デメリット：管理資産が増える。要するにカスタマイズ環境になる。
- デメリット：どこまでやれば良いか分からない。
これくらいが考えられます。ただ、いずれもメリット・デメリットがありますので、実際に適応する場合は実運用を含めよく考える必要があるのが悩ましいところです。
事象２：Ubuntuでhhvmが起動しなくなった事件
続いてはUbuntu。同じように、hhvmが起動しなくなりました。hhvmは標準リポジトリのものではなく、hhvmのリポジトリを追加してインストールしていますので、ここで不整合が起きた可能性とか、いろいろ悩みました。
結論から言うと、これまたuid問題だったわけですが・・・
まず、hhvmはwww-dataユーザーで動かしています。sudoでwww-dataで起動しているんですが、本来は設定ファイルに書かれたユーザー権限で動いてほしいところなんです。たしか暫く前まで（今も？）、これが効かなかったんですよね。それで設定ファイルに「user=httpd」と書いていた（意味がない）のをすっかり忘れていたと。なんでhttpdだったかって、以前WebサーバーApacheを使っていた名残だと思われます。
この状態で、おそらく、今回ベースイメージを変更したことで、httpdユーザーが作られなくなった。パッケージの依存関係が変わったことが被疑です。結局、設定ファイルの「user=httpd」のところをwww-dataにしたら動き出しました。こんな設定がこのタイミングで効いてくるなんて。
パッケージ依存関係が変わるというのは中々に厄介で、ベースイメージ作り変えたら、突然ユーザーが消えたり（※そういう意味では前述のCentOSもこれかも）、コマンドが無くなったり、ファイルが無くなったりします。そういえば最近tzdataも導入されなくなってて、コンテナ内の時間がUTCになってたとか・・・
インフラの特性に合わせた運用は必要
以上、今回のトラブルで分かったことは、やっぱり試験環境は必要だなっていうことです。Dockerの場合、この試験環境の構築がとても楽で、事象の再現性も高いため、インフラ運用の観点から見ると、「圧倒的に楽」であることは間違い無いです。
こういったトラブルの事象だけを見て、やっぱりDocker使えない、不安定、とか言うのは間違いです。いずれも通常のOS環境でも仮想化環境でも、普通に起こりうる事象です。そもそもベースイメージアップデート＝OSアップデートなので、その検証がこんな短時間で出来ることのメリットのほうが遥かに大きいですから。Immutableってのも、あくまでイメージ、コンテナとしてのImmutabilityです。
もちろん、Dockerコンテナは、既存アプリケーション環境のパッケージングにも使えます。イメージを固定し、最低限の変更だけを適応するような運用を組み上げることで、例えば特定のOS環境を維持し続けるようなこともできます。
一方で、Dockerインフラの運用性の高さは、こうやって、最新OS環境（イメージ）を追従して、セキュリティの高い状態、より性能の良い状態、保守レベルの高い状態を維持し続ける手続きがより簡単にできることのほうにあると私は考えています。Infrastructure as Codeの一つの効果です。
誰かの要件を完全に満たす理想のインフラなんて世の中には存在しないです。ただ、その仕組みのメリットを享受する姿勢があるか否か、この一点においてのみ、システムやインフラには選択性が生まれ、新しいイノベーションに進んでいくことが出来るんじゃないかな、と思っています。
ちなみに、今回やろうとしていたことは、ブログサイトの常時SSL化です。これについては別に書きます。
コメント