docker

TL;DR Docker HubにあるMariaDBの公式イメージのメジャーバージョンアップを行う場合、環境変数MARIADB_AUTO_UPGRADEにnon-emptyな値に設定したほうがよい 経緯 Redmineで利用しているMariaDBのバージョンアップを行った。10.4.25から10.6.8に一気に上げた。 途中10.5.15を経由したのだが、その際に以下のメッセージが出たのが気になった。 redmine_db | 2022-06-25 05:16:20+00:00 [Note] [Entrypoint]: MariaDB upgrade (mysql_upgrade) required, but skipped due to $MARIADB_AUTO_UPGRADE setting Docker HubのMariaDB公式サイトを見に行くと確かに以下の記述がある。 Set MARIADB_AUTO_UPGRADE to a non-empty value to have the entrypoint check whether mysql_upgrade/mariadb-upgrade needs to run, and if so, run the upgrade before starting the MariaDB server. Before the upgrade, a backup of the system database is created in the top of the datadir with the name system_mysql_backup_*....

Ubuntu20.04で構築しているDocker環境にて Dockerコンテナで構築したZabbix serverでDockerホストにzabbix agentをインストールして監視する場合、Zabbix serverの接続元IPがDocker内部IPになってしまう。既定ではDockerコンテナのIPは毎回変わるため、zabbic agent側でzabbix serverのIPを指定できない(configファイルに記載が必須)。 Dockerホスト1台で運用する環境であれば、内部IPを固定してしまえばよい。 当方では、2台でActive-Standbyで運用しており、自サーバがActiveの場合は内部IPでアクセスが来るが、Standbyの場合には(自サーバでないActiveサーバの)外部IPでアクセスが来るため、serverとして2つのIPを指定したい。 https://www.zabbix.com/forum/zabbix-help/379138-one-node-monitored-by-2-differents-zabbix-servers によると、configのSERVER値に複数のIPをカンマ区切りで指定することもできるらしい。 一方で、SERVER値にはホスト名の指定もできるので、ホスト名に対するAレコードを複数登録して動作確認したところ、こちらも問題なく動作した。なお、PTRレコードは不要。 環境によっては、IP直指定よりもDNSの方がよいというところもあるだろう。

Dockerにて、本家のイメージを使って運用している。 4.0.22から4.0.24にアップしたところ、以下のエラーが出て監視画面が表示されなくなってしまった。 DateTime::__construct(): Invalid date.timezone value '"Asia/Tokyo"', we selected the timezone 'UTC' for now. よくよくみると、「Asia/Tokyo」の前後にダブルクォーテーションとシングルクォーテーションがついている。ひょっとしてと思い、Dockerで環境変数を指定している箇所 PHP_TZ="Asia/Tokyo" をダブルクォーテーションなしで PHP_TZ=Asia/Tokyo と修正したところ、無事表示されるようになった。

私の勤めている会社では、サーバは全部で4台、そのうち3台はパッケージシステムやADが動作しているWindowsサーバでそのまま運用するだけ(過去に開発されて引き継いだAccessアプリはこの3台のWindows上で動作) 内製アプリは残りの1台でやりくりしています。とは言え利用者は限られているのでリソース的には余裕です。 Dockerで複数コンテナを立てて運用していましたが、Kubernetesが流行っていることも知っていたので是非導入したいと思い、チャレンジしていました。 結論としては、うちの規模では割りに合わない、Docker運用に戻すことにしました。 Dockerのメリットは コンテナ化することで複数のサーバを独立に動作させることができる PublicなDockerイメージからDockerfileでイメージを構築する形にすれば、Dockerfileさえあればどの環境でも同じように動作させることができる docker-composeを利用すれば、コンテナ起動時の連携設定等も行える Kubernetesのメリットは、上記に加えて 同一イメージのコンテナを複数立てて負荷分散する設定を簡単に行える Blue-Greenデプロイのように既存の環境を維持したままのDeployが設定で簡単にできる あたりが一例としてあると思います。 一方でDockerに対するKubernetesのデメリットとして DBの運用が難しい PVCを使えばできるようだが、壁は低くない 非Publicなコンテナを利用するのであれば、別途Registryサーバが必要 ネットワーク構成が複雑、外部に公開するためにまぁまぁの設定が必要 複数ノードで負荷分散を可能にするための抽象化だが、そこまでいらない場合にはつらい 現状では、内製アプリが死んでも即困る状況ではなく、気付いたらDockerコンテナを起動すれば良い程度の状況なので、Kubernetesで複数コンテナを分散運用する必要もなく… ただDBだけは守る必要があるので、しっかりバックアップしてすぐに復旧できるようにしたい。となるとDockerでホストVolumeを使ってやるくらいがメンテしやすい。 このような理由でDockerに戻します。 その上で、DBのバックアップやリストアなどの手順をAnsibleでコード化しておく、あたりが今のインフラ規模ではベストだと判断しました。 Kuberetesのソリューションには、シングルで運用できるminikubeやmicrok8s,k3sなどのソリューションがあり簡単に始められますが、運用にあたっては同一コンテナの負荷分散が必要、のような必要性がないと難しいと思いました。お金をかけられるのであれば、EKSなどのマネージドサービスがベストだと思います。

社内のLinuxサーバは極力Ansibleで状態を管理し、サービスはDockerコンテナで運用している(DB除く)。いわゆるIaC(Infrastracture as Code)を実践しているつもり。 これの何が嬉しいかというと、正直なところ個人的にコマンド一発で全てが出来上がるのが楽しい、というところが大きかったりする。ピタゴラスイッチ、ルーブ・ゴールドバーグ・マシンを見ているような爽快感、とでも言うのだろうか。 そんな感覚はない場合、紙の手順書をコードに置き換えるのは面倒と感じるのもわかる。何が面倒かと言えばコードには曖昧さが許されないことだと思う。手順書は曖昧に書いて「言わなくてもわかるよね」という雰囲気で終わらせることもできるが、コードは書いたようにしか動かない。コードに落とすためには対象のプログラム・システムの仕様を正確に理解しないといけないし、何をもって正常とするのか、それはどんなケースでも正常と言えるのか、突き詰めて考えないといけない。この辺りが利用する組織や文化によって大きな壁になるのだと思う。 ただ、慣れてしまえばむしろ誰かが決めた書式・ルールに従って手順書を書く手間、変更された際に保守する手間もなくなるし、手元の仮想化環境などで簡単に再現してテストできる、最高の環境になる。