「docker」タグアーカイブ

k8s ミリしら向けの AWX on MicroK8s with プロキシ

投稿日時:
返信

Docker ぐらいならなんとかわかるけど、 Kubernetes (k8s) は全然わかっていない人向けに、プロキシ環境下の MicroK8s 上で AWX をインストールする手順と、その周囲情報を説明していく。

AWX とは

AWX とは、 Ansible Automation Controller (旧称: Ansible Tower) と呼ばれる Ansible の構成コードの実行を管理する WebUI を持ったツールの OSS版だ。

Ansible とは IaC (Infrastracture as Code) ができる CUI ツールであり、構成先に Python さえ入っていれば、そこに ssh するだけで実行できるのが特徴だ。
AWX はこれを Git などのソースコード管理ツールと連携しながら、 Web UI 上で実行・管理・記録できるツールとなる。

Ansible Automation Controller と比べると、 Red Hat によるサポートや LTS はなく、 ローリングリリースモデルを採用していて更新が激しい。
このため、エンタープライズ用途には基本的には向かないものの、元々そんなに破壊的変更が頻繁にあるタイプのツールではないため、小規模に使う程度ならかなり実用的になっている。
(但し 2024年9月現在、次回のメジャー更新の v25 あたりで、認可・認証の内部構成が大きく変わる予定ではある 1)

Kubernetes と MicroK8s

AWX を運用環境にインストールするには、 Kubernetes が必須となっている。

Kubernetes (多くは K8s と略される) は、コンテナ管理ツールのひとつで、コンテナオーケストレーションツールとも呼ばれる。

コンテナ管理といえば、 Docker が非常に有名だ。
Docker はどちらかというと開発者よりのツールで、一つのコンテナないし、 Docker Compose を使って一つのホスト（マシン）内に閉じた複数のコンテナの管理に特化している。

一方、多少規模のあるサービスをコンテナで運用する場合、複数ホストにまたがっていくつものコンテナを協調動作させる場合が多い。

Kubernetes であれば複数のホストに跨がって複数のコンテナを協調操作させる運用管理ができる。
例えば・・・

  • 異なるホストで動作しているコンテナを、同じ仮想ネットワークにあるかのように扱う
  • 負荷に応じてコンテナをスケーリングする
  • コンテナ起動やダウン時の自己修復や負荷分散のロジック等を自分で作り込む

といった事ができる。

続きを読む →

Docker Compose で、ベースイメージが更新された場合のみ再 up する

投稿日時:
更新日時:
返信

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

2日目は @ko-he-8 氏の /var/lib/docker/が肥大化していたけどdocker system prune --volumesで解決しなかったので調べてみた #Docker だった。
なんかの拍子にコンテナが管理外になってしまっていて docker system prune で削除できないときのお話になっている。
開発用の仮想マシンをリセットせずに使い続けていたりすると、こういう状況に良くなるよね…

Docker Compose だけで雑に本番運用する際に、定期的にリビルドしたい

信頼できるオフィシャルイメージを元に、カスタムイメージをビルドして本番運用する場合、 CI 等でビルドしたイメージをコンテナレジストリに push し、それを本番環境側で pull するのが一般的なベストプラクティスだ。

しかし、クラスタも構築せず VM 1台でいくつかのコンテナを動かすような小規模な運用ほ場合、わざわざ CI やレジストリを準備するのも面倒だ。
このため、運用環境上で Docker Compose を使ってイメージのビルドやコンテナの起動を行ってしまう単純な構成にしたくなる。

そんな時、ベースイメージのセキュリティ更新に追従するために、定期的にイメージをリビルドした上で、必要な場合に限ってコンテナを再 create ＆ up させる方法を考える。

BuildX 既定化による弊害

以前は、 docker-compose pull --no-parallel と docker-compose build --pull の標準出力のいずれかから、 新しいイメージが pull されたことを示す "Downloaded newer image" の文字列があるかどうかを確認し、 docker-compose up すればよかった。

ところが、 docker 23.0.0 にて、 Linux 環境における既定のビルダーが BuildKit というものに切り替わってしまった。
旧来の docker-compose V1 の docker-compose build ないし、 Docker Compose V2 の docker compose build 実行時は docker CLI を通じてビルドされる ため、この仕様変更の影響を受ける。
このため、規定の設定のままだと build の仕組みが変わってしまい、上述のベースイメージのダウンロードを検出できなくなった。

BuildKit は規定では出力をいい感じにまとめてしまうので、そのままだとベースイメージの pull があったかどうか判別できない。

環境変数で DOCKER_BUILDKIT=0 を設定しておけば、旧来の Legacy Builder でビルドをしてくれるが、いつまでサポートされるかわからないので、 BuildKit を使う方法でなんとかしたい。

幸い、 docker build --progress=plain の出力の指定 は、 docker compose build でも働いてくれる。

この出力から ^#[0-9]+\s+resolve\s+ の正規表現がヒットする場所を探してくれば検出できそうだ。

Docker Compose V2 に対する出力オプション

また、既に廃止済みの docker-compose V1 の代替として、 Docker Engine 20.10.13 に Docker Compose V2 プラグイン がインストールされるようになって以降、現在はこちらの docker compose コマンド使う必要がある。

Compose V2 は、多くの面では docker-compose V1 と互換があり、作成されるコンテナ名のセパレータが一致しない事 （これも --compatibility フラグ で互換性を維持できる）以外はおおむねそのまま利用できる。

ただ、コマンドの UI 出力の内容や、それに纏わるオプションは V1 から大きく変わっているので、そこらへんは調整してやる必要がある。

--ansi never オプションを指定すると、ANSI エスケープコードが無効化され、ターミナルの色がつかなくなったり、パイプ時に余計な文字コードが確実につかなくなる…はずなのだが、指定しても up した時のログぐらいにしか効果が出ないような気はする。
規定値だと auto なので、パイプ処理された場合はそもそも ANSI エスケープコードがつかないはずではあるが、とりあえずオプションの方でも never を強制しといた方が良さそうなので設定しておく。

--progress plain オプションを指定すると、インタラクティブな出力が無くなり、以下のようにパイプで処理しやすいプレーンなテキストが出力されるようになる。
Docker Engine 24.0.3 に同梱されている Docker Compose 2.19.0 移行で compose のグローバルオプションに昇格したオプションであるため、それより低いバージョンだと指定できない点に注意。

$ docker compose --progress plain pull
 alpine-built1 Skipped - No image to be pulled
 alpine-built2 Skipped - No image to be pulled
 alpine-pure2 Skipped - Image is already being pulled by alpine-pure1
 alpine-pure1 Pulling
 070eb51debd9 Pulling fs layer
 070eb51debd9 Downloading [>                                                  ]   28.1kB/2.808MB
 070eb51debd9 Downloading [==================================>                ]  1.911MB/2.808MB
 070eb51debd9 Verifying Checksum
 070eb51debd9 Download complete
 070eb51debd9 Extracting [>                                                  ]  32.77kB/2.808MB
 070eb51debd9 Extracting [==================================================>]  2.808MB/2.808MB
 070eb51debd9 Pull complete
 alpine-pure1 Pulled

docker compose build, up のステータスの出力は、標準出力ではなくて標準エラーの方に出るので、パイプラインつなぐときは注意。

実際のコード例

compose.yaml が存在するディレクトリを /var/lib/docker-compose-dir とした場合、以下のようにできるだろう。

cd /var/lib/docker-compose-dir && { \
  /usr/bin/docker compose --ansi never --progress=plain pull --no-parallel; \
  /usr/bin/docker compose --ansi never --progress=plain build --pull; \
} 2>&1 | \
grep -E "Downloaded newer image|\s+Pull complete\s*$|^#[0-9]+\s+resolve\s+" && \
/usr/bin/docker compose --ansi never up -d

--

さて、こういうコードは cron 等で定期的に実行させたい。
そういった場合、あとから状況を確認しやすくするために、 docker compose の各出力は journald にも書き込んでおきたい。

条件分岐を行うための grep と、 journald に記録するコマンド (logger 等) の両方にパイプしたい場合、 bash や BusyBox ash 等が持つ プロセス置換 が使えそうだ。
crontab が起動するコマンドは、 sh という名前で POSIX 標準互換モードで動かすディストリビューションが多い (debian (Ubuntu) 系, fedora (RHEL, CentOS) 系) ので、明示的に bash (または ash) を呼び出し、その中でプロセス置換を行う方が安全だろう。

例えば Ubuntu の crontab 内で定期的にイメージのリビルドを行う場合、以下のようにすると良いだろう。

cd /var/lib/docker-compose-dir && { \
  /usr/bin/docker compose --ansi never --progress=plain pull --no-parallel; \
  /usr/bin/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 "Downloaded newer image|\s+Pull complete\s*$|^#[0-9]+\s+resolve\s+" && { \
  /usr/bin/docker compose --ansi never up -d 2>&1 | \
  logger -i -t user/docker-auto-recreate -p user.info; \
}

なお、実際には cron 内のコマンドでは改行できないので、改行は削除して記述しよう。

Docker run の起動時に任意コードを実行後 bash や ash を終了しない

投稿日時:
更新日時:
返信

この記事は、 Docker Advent Calendar 2022 の 23日目の記事だ。
空いていたので埋めちゃうよ。

この記事では、 bash や ash で任意のコードの実行後、ターミナルを終了せずに入力待ちにする方法について紹介する。
特に、 docker run の実行後に、その環境を維持したまま入力待ちにすることを考える。

例えば、 Windows コマンドプロンプトや PowerShell であれば、 CMD /K *** オプションや、 -NoExit -Command *** オプションで実現できるような内容だ。

本来なら、 docker build にてその任意コードの実行後の内容をイメージにするべきだが、 わざわざ build するまでもないとか、 build できない事情などもあるかもしれない。

ということで、 bash の場合と、 alpine などで使われる BusyBox ash それぞれについて、 docker run 実行時に任意コード実行後、ターミナルの入力待ちにする方法を紹介する。

bash の場合

bash の場合、 --rcfile オプションにて、起動時に実行するコマンドを指定できる。

ただし、 --rcfile はファイルを指定する必要があるため、 替わりにプロセス置換で実行コードを与えてやる方法をとる。

user@hostmachine:~$ docker run --rm -it debian:bullseye bash -c "bash --rcfile <(echo 'ls && export '\''FOO=B A R'\'' && MY_TIME=\$(date)')"
bin   dev  home  lib64  mnt  proc  run   srv  tmp  var
boot  etc  lib   media  opt  root  sbin  sys  usr
root@container:/# echo $FOO : $MY_TIME
B A R : Thu Dec 22 15:00:00 UTC 2022
root@container:/#

プロセス置換はコンテナ内で実行される必要があるため、一旦 bash -c にてコンテナ内で bash 実行させ、その中で改めて --rcfile オプションを指定した bash を起動する流れとなる。

実際に実行したいコマンドは、 echo で文字列として書き出す。
上記例では、 ls && export 'FOO=B A R' && MY_TIME=$(date) と言う文字列を echo させている。

引用符が二重三重になっていて、エスケープが非常に難しくなっているので注意。

BusyBox ash

alpine 3.15 以降に含まれる BusyBox の ash であれば、意外にもプロセス置換が使える。

しかし、 --rcfile に相当するオプションは残念ながら無い。
替わりに、 ash には ENV という環境変数に記載されたファイルを ash 起動時に実行する機能がある。

これを使おう。

user@hostmachine:~$ docker run --rm -it alpine:3.15 ash -c "ash -c 'export ENV=\$1;ash' -s <(echo 'ls && export '\''FOO=B A R'\'' && MY_TIME=\$(date)')"
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr
/ # echo $FOO : $MY_TIME
B A R : Thu Dec 22 15:00:00 UTC 2022
/ #

ash の -c のコマンドに対して引数を与える -s オプションを使ってプロセス置換のファイルを与え、 それを $1 経由で ENV 環境変数にセット。 その状態で再度 ash を起動させれば、 bash と同様のことが行える。

ENV 環境変数に直接プロセス置換のファイルを指定せず、わざわざ一旦引数を経由させているのは、 入力を受け付ける ash プロセスが動いている間、 プロセス置換のファイルにアクセス可能にする必要があるためだ。
例えば、 export ENV=<(echo 'command');ash と実行しても、 ash 実行の段階ではプロセス置換のファイルが閉じられているので、コマンドは実行されない。

もうちょっと複雑で実用的な例

エスケープが何重にもなっていてややこしいが、書き方さえ気をつければ基本的にどんな内容でも実行可能だ。

apt パッケージマネージャーのリポジトリを書き換えた状態で、 bash を起動する方法 （Ubuntu <= 22.04）:

docker run --rm -it ubuntu:22.04 bash -c "bash --rcfile <(echo 'sed -i -E '\''s%^(deb(-src|)\s+)https?://archive\.ubuntu\.com/ubuntu/%\1http://ftp.udx.icscoe.jp/Linux/ubuntu/%'\'' /etc/apt/sources.list && apt update && FooBar=`date -uIs`')"

〃 （Ubuntu 24.04）:

docker run --rm -it ubuntu:24.04 bash -c "bash --rcfile <(echo 'sed -i -E '\''s%^(URIs:\s+)https?://archive\.ubuntu\.com/ubuntu%\1http://ftp.udx.icscoe.jp/Linux/ubuntu%'\'' /etc/apt/sources.list.d/ubuntu.sources && apt update && FooBar=`date -uIs`')"

apk パッケージマネージャーのリポジトリを書き換えた状態で、 ash を起動する方法 （Alpine）:

docker run --rm -it alpine:3.15 ash -c "ash -c 'export ENV=\$1;ash' -s <(echo 'sed -i -E '\''s%^https?://dl-cdn\.alpinelinux\.org/alpine/%http://ftp.udx.icscoe.jp/Linux/alpine/%'\'' /etc/apk/repositories && apk update && FooBar=`date -uIs`')"

参考: https://stackoverflow.com/questions/74094552/how-not-to-terminate-after-carried-out-commands-in-bash

プロキシ環境下で Docker Desktop から Rancher Desktop への移行する

投稿日時:
更新日時:
返信

この記事は、 Docker Advent Calendar 2022 の 22日目の記事だ。

Windows 上や mac OS 上で、手軽に Docker や Kubernetes の環境を構築するための、 Docker Desktop というツールが存在する。

この Docker Desktop は、 2021年8月31日以降、営利企業での利用は基本的に有料サブスクリプションが必須 となった。
更に、 2022年10月27日以降、 Docker Team プランにて 100人のユーザー数上限が設けられ 、それ以上の場合は Docker Business プランの契約が必要となっている。

まぁ、営利企業ならそれぐらい払えよって話なんだが、のっぴきならん理由でなかなかそうもいかない諸兄も少なくないだろう。

正直、 Business プランで Docker Desktop 以外の機能を全く使わない（ないし使えない）場合、 $21/user/month はだいぶ高い。

ということで、代替？になるかわからんが、主に Windows での実行をスコープに、 同一コンセプトの Rancher Desktop への移行を紹介してみよう。

Rancher Desktop について

Rancher Desktop は、 Docker Desktop と同様 PC の仮想環境上にコンテナデーモンを起動させ、 デスクトップから手軽に Docker CLI (with Moby/dockerd) や nerdctl (with containerd) を利用できるようにするツールだ。

かつての SUSE Linux の開発元、 現在の openSUSE プロジェクトの主要スポンサーとなっている SUSE 社 が開発している、 Rancher ソリューションの一環として、 オープンソースで開発されているプロジェクトである。

WSL2 上に dockerd や containerd デーモンを立ち上げ、 他の WSL2 ディストリビューションや ホストOS から Docker CLI や nerdctl が使えるようになっている。

Windows の Docker CLI からも、 WSL 内の Docker CLI からも、 Docker outside of Docker (DooD) が問題なくできるなど、基本的な機能はしっかりしている。

Docker Desktop と比較すると、以下のような利点がある。

  • 無料で利用できる
  • nerdctl にも対応している
  • Kubernetes のバージョンが選べる
  • VPN 環境下でも問題が発生しにくい

一方で、使っているといくつかの問題が目につく。 (1.9.0 現在)

  • プロキシ環境下で イメージの pull させる公式手順がない
  • WSL 内からの CLI の実行にいくつか難がある
    • docker CLI の実行が、 2～3 テンポ遅い
    • docker run に --interactive ( -i ) オプションを付けないと、標準出力がホスト側に表示されない

また、問題とまでは言わないまでも、いくつか注意点もある。

  • 付属の docker-compose が、 docker compose コマンドと同等の Compose V2 である
  • Hyper-V の仮想化に依存するため、 VPN 環境下と相性が悪い
    • ネットワークスタックの構造の変更で解消し、むしろ利点となった。

Docker Desktop から Rancher Desktop への移行

Windows 版に於ける、 Docker Desktop から Rancher Desktop への移行手順をまとめておく。

1. Docker Desktop を削除

続きを読む →

置換ができない/複数ある場合に sed の終了コード0以外にする

投稿日時:
返信

本記事は、 シェルスクリプト Advent Calendar 2021 の 4日目 の記事だ。
そして、 且つ docker Advent Calendar 2021 4日目 の記事でもある。

どちらのカレンダーもまだまだスッカスカなので、禁じ手で埋めにかかってしまった。

Docker 公式イメージ などをベースにして、カスタムしてイメージをビルドして使おうとした際、 なるべくなら /etc/apt/apt.conf.d/ 等のように、設定用のファイルを追加して、ツール側がいい感じにマージして利用してくれるのが望ましい。
しかし、 場合によってはやむを得ず、既存のファイルを sed コマンドなどで編集せざるを得ないこともあるだろう。

カスタムイメージの Dockerfile をビルドする際に、当初は意図通り書き換えられていても、イメージが更新された結果、イメージのリビルド時にファイルの書き換えが意図しない結果となってしまう場合がある。 1

通常、 sed コマンドは、置換が発生してもしなくても、 終了コード 0 で終了する。
このため、書き換えの成否にかかわらず、 docker build 時にエラーにならないため、コンテナ実行時に初めて置換が意図しない結果だったことに気づくことがある。

そこで、sed コマンドの書き換えで適切なパターンが見つからなかった場合に 0以外の終了コードを返し、ビルド時にエラーとする方法を考える。

続きを読む →

Samba が動く Docker Desktop のコンテナで、ボリューム内のファイルを見る

投稿日時:
返信

本記事は、 docker Advent Calendar 2021 2日目 の記事だ。
昨日は、 @subretu氏 の DockerfileにおけるCMDとRUNの挙動 だった。

docker のコンテナやボリュームの中身を見る際に、 ホスト PC から SMB ファイル共有で参照できると都合が良い。

と言うことで以前、以下のような記事を作成したが、 Docker Desktop では利用できない問題があった。

Aqua Ware つぶやきブログ
 
2020.02.12
無認証 SMB を samba で秒で立ち上げる Dockerfile (& docker-compose)
https://aquasoftware.net/blog/?p=1259
docker 上の Linux (alpine) で Samba を立ち上げ、 無認証の SMB 共有を開始する Dockerfile をメモっておく。使用例手っ取り早く実行したい場合、以下のような docker-compose.yml を Dockerfile と同じフォルダに保存し、version: '3'services: smb: build: . ports: - 445:445コマンドプロンプト等のターミナルで、以下のように実行する。docker-compose builddocker-compose up何に使うのかdocker でデータを永続化する際、 Bind Mounts を使えば、デスクトップ側にファイルが永続化されているため、そのま...

今回は、それを解消する手段について紹介したい。

先に断っておくが、私自身でいくつかの PC で試したところ、上手くいく PC とダメな PC がハッキリと分かれてしまい、現時点ではどのような条件だとダメなのかハッキリわかっていない。

続きを読む →

VPN に繋ぐと WSL2 や Hyper-V VM でネットワークに繋がらなくなる問題を解消する

投稿日時:
更新日時:
5

OpenVPN や Cisco AnyConnect, GlobalProtect 等といった VPN に接続した際、 Hyper-V 仮想マシン内からや、 WSL2 のディストリビューション内、 Windows Sandbox 内、 WSL2 ベースの Docker コンテナ内 等々、 Hyper-V 系の技術を使った仮想環境から、 PC 外のネットワークにアクセスしようとすると、 以下のようなエラーが発生して失敗する。

$ # curl 利用時の例
curl: (6) Could not resolve host: example.com
curl: (5) Could not resolve proxy: proxy.example.com

$ # apt で更新しようとした場合の例
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'proxy.example.com'

エラーの内容からわかるとおり、アクセス先やプロキシーのドメイン名を DNS で解決できなくなっている。

このような問題が発生することは以前から知っていたのだが、このご時世で VPN 使うことが増えてきて、いい加減鬱陶しくなってきたので、なんとかしようと思う。

解決方法

とりあえず、まずは 2種類 の解決方法から。

続きを読む →

AWX をインストールした後の Server Error を解決したかった話

投稿日時:
返信

この記事は、 Ansible AWX をインストールしたときに、 Server Error に なったりならなかったりする 問題に対処したときのポエムだ。

はじめに断っておくが、最終的に AWX 8.0.0 で解消しているっぽいものの、 原因や正確な条件などは不明なままである。
また後述するが、 （タイトルに反して）おそらく Ansible AWX の問題ではなく、 postgres:9.6 の docker イメージの問題ではないかと思われる。

発生した問題の状況

続きを読む →