自動で最新状態を維持! Docker Compose でコンテナのイメージを定期的に更新・再起動する方法

本記事は、 Docker/コンテナ仮想環境 Advent Calendar 2024 8日目の記事だ。

「Docker は開発向けの環境だ、運用するなら K8s などのコンテナオーケストレーションツールを使え!」…とひとは言う。
しかし、 DB やアプリ等々の複数のコンテナをひとつのマシンで動かすなら、 Docker Compose でビルドまで担わせてしまう手軽さと手っ取り早さはなかなか捨てがたい。

趣味の範囲や、チームの範囲でしか使わず、そんながっつり作り込んだシステムでも無ければ、ベースイメージが更新される度に自動的にコンテナを差し替えてしまいたくなる。
そんな状況で、実行しているイメージやビルドするベースイメージに更新があった場合のみ、自動でコンテナを Recreate して再アップさせる cron ジョブを考えてみる。

Compose で定期 pull とビルドしてイメージの更新があったら再 up する cron コマンド

cd /path/to/dirname/; { docker compose --ansi never pull --no-parallel; docker compose --ansi never --progress=plain build --pull; } 2>&1 | bash -c "tee >( logger -i -t user/docker-auto-rebuild -p user.info )" | grep -E '\s+Pull complete\s*$|^#[0-9]+\s+resolve\s+' && docker compose --ansi never up -d 2>&1 | logger -i -t user/docker-auto-recreate -p user.info

こんなコマンドを、 cron に登録してやろう。

動作確認したバージョンは、 Docker Engine v27.3.1, Docker Compose vv2.29.7 だ。

$ docker version --format "Client: {{.Client.Version}}, Server: {{.Server.Version}}"
Client: 27.3.1, Server: 27.3.1
$ docker compose version
Docker Compose version v2.29.7

実行ログは journalctl を使って以下のように実行したら見れるぞ。

$ journalctl -t user/docker-auto-rebuild -t user/docker-auto-recreate --since "1day ago"

続きを読む

docker の snap パッケージをプロキシ環境で使う方法と、 compose で build エラーになる話

本記事は、 Docker/コンテナ仮想環境 Advent Calendar 2024 - Qiita 5日目の記事だ。

Linux で docker をインストールする場合、どのようにしているだろうか?
OS 標準のパッケージマネージャーからのインストールが一般的? それとも、 Docker 公式のリポジトリ (Install - Docker Docs) を使っているだろうか?

そんな docker インストールする方法のひとつに Snap (Snapcraft) がある。

Snap (Snapcraft) とは

Snap (Snapcraft) は、Canonical が開発・管理している、アプリケーションをパッケージ化して配布するためのシステムのひとつだ。 Canonical は Ubuntu を支援している企業だが、 Ubuntu 以外の多くの主要なディストリビューションでも Snap を利用できる。

依存関係を含む一式がコンテナ化されており、異なる Linux ディストリビューション間で共通のパッケージで動作するのが特徴だ。 サンドボックス化したファイルシステム内でインストールしたアプリケーションを動かすという、セキュリティ面の特徴もある。

snap 版 docker は、 /home/ 以下のファイルしか参照できない強い制限 1 や、インストール時に docker グループを作成してくれない制限があるが、それ以外はわりと問題なく動く。

Snap 版 docker に於けるプロキシ設定手順

プロキシの設定さえ適切に行えば、 snap 版 docker もプロキシ環境下で動作する。

基本的な設定箇所は、 Docker DaemonDocker CLI の設定と同じだが、前述のサンドボックス化の関係で、記述するファイルの場所が異なる。

具体的には

  • /etc/docker/daemon.json の替わりに /var/snap/docker/current/config/daemon.json
  • ~/.docker/config.json の替わりに ~/snap/docker/current/.docker/config.json

をそれぞれ書き換える。

特に後者 (~/snap/docker/current/* 以下) については、一度そのユーザーで何らかの docker コマンド (後述の例では docker info) を実行してから設定しなくてはならない。
そうしないと、フォルダが Snap サンドボックスへマッピングされないからだ。

では、インストールからの手順を追ってみよう

続きを読む

Hyper-V 等の VM 上にプロキシと DNS を立てる

本ブログでは、ちょいちょいプロキシ環境下での設定方法を紹介しているが、
そういったプロキシ環境下での動作の検証のため、以下を満たすプロキシサーバーを立てたい。

  • OS は Ubuntu 24.04
  • squid によって 8080 ポートにて HTTP プロキシする
  • bind9 によって自身のアドレスを proxy.example.com として名前解決する DNS サーバーとなる

とりあえず、 squid と bind9 をいれて、設定ファイルを必要最低限書き換えてみよう。

export CURRENT_IP_ADDRESS=`hostname -I | tr -s ' ' '\n' | tail -n 1`
sudo apt update
sudo apt -y install squid bind9 bind9utils
sudo sed -i -r -e 's/^(#\s?)?(http_access allow localnet)/\2/' -e 's/^http_port 3128/http_port 8080/' /etc/squid/squid.conf
sudo sed -i -e 's%^\s*\(//\)\?\s*forwarders {%        forwarders {\n                8.8.8.8;\n        };\n\0%' -e 's%^};%\0\nzone "proxy.example.com" in {\n  type master;\n  file "proxy.example.com.zone";\n};%' /etc/bind/named.conf.options
sudo tee /var/cache/bind/proxy.example.com.zone << EOF > /dev/null
\$TTL 86400
@       IN      SOA     proxy.example.com. root.proxy.example.com. (
                        2023070301      ;Serial
                        3600            ;Refresh
                        1800            ;Retry
                        604800          ;Expire
                        86400           ;Minimum TTL
)
@       IN      NS      proxy.example.com.
@       IN      A       $CURRENT_IP_ADDRESS
EOF
sudo systemctl restart squid named

これだけ。

解説

続きを読む

MicroK8s で kustomization.yaml を apply すると error: accumulating resources になる問題

MicroK8s で kustomization.yaml を apply した際に、 error: accumulating resources が発生する問題についてのメモ。

端的に言うと、snap でインストールした MicroK8s で、内部的に git コマンドが実行される操作をすると、おかしくなる模様。

発生する問題

snap で MicroK8s をインストールし、 kubectl apply -k する。
このとき、Kustomize に指定する kustomization.yaml には、直接的または間接的に remote directory 方式のリソースを参照する。

$ sudo snap install microk8s --classic --channel=latest/stable
$ cat << EOF > ./kustomization.yaml
resources:
- https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1
EOF
$ microk8s kubectl apply -k .

すると、以下のようなエラーが発生する。

ホストOS に git がインストールされている場合:

error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1': URL is a git repository': failed to run '/snap/microk8s/6364/usr/bin/git fetch --depth=1 https://github.com/kubernetes-sigs/kustomize v3.3.1': /usr/lib/git-core/git-remote-https: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE
: exit status 128

ホストOS に git がインストールされていない場合:

error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/kubernetes-sigs/kustomize//examples/helloWorld/?timeout=120&ref=v3.3.1': URL is a git repository': failed to run '/snap/microk8s/6364/usr/bin/git fetch --depth=1 https://github.com/kubernetes-sigs/kustomize v3.3.1': fatal: unable to find remote helper for 'https'
: exit status 128

ワークアラウンド

続きを読む