docker compose の dockerfile_inline の変数エスケープ

Docker Compose v2.17.3 から、 dockerfile_inline 構文compose.yaml の中に Dockerfile をインライン記述できるようになった。
compose.yaml ファイル一つで複数のコンテナを立ち上げられるので、地味に便利。

さて、この機能における変数の扱いについての理解に関して…、
突然だが Docker クイズ!!

以下の compose.yaml をビルドしたら、 /out.txt には何が出力されているだろうか?

services:
  inline:
    build:
      context: .
      dockerfile_inline: |
        FROM alpine
        ARG arg3="dockerfile"
        ARG argDupl="dockerfile"
        RUN  export arg2=buildcontainer \
          && export argDupl=buildcontainer \
          && cat <<EOS > /out.txt
        --------
        arg2=$arg2
        arg3=$arg3
        arg2=\$arg2
        arg3=\$arg3
        --------
        EOS
        RUN cat /out.txt

docker compose --progress=plain build --no-cache オプションを付けてビルドし、 /out.txt のダンプがどうなるか見てみよう。
果たして、正解は…?

ドロドロドロドロドロドロ (ドラムロール音)

 

\デーン!!!/

#6 [inline 3/3] RUN cat /out.txt
#6 0.496 --------
#6 0.496 arg2=
#6 0.496 arg3=
#6 0.496 arg2=arg3=--------
#6 DONE 0.5s

正解できただろうか?

解説

続きを読む

自動で最新状態を維持! 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 サンドボックスへマッピングされないからだ。

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

続きを読む