Docker on ポンコツ地方エンジニアの技術ブログ

docker コンテナ起動時に /tmp ディレクトリの中身を削除する

Wed, 11 Dec 2024 00:00:00 +0900

Linux ではシステム起動時に /tmp ディレクトリの中身がクリアされます。
しかし、docker コンテナの場合は、通常はコンテナを再起動しても /tmp ディレクトリの中身はクリアされません。

docker コンテナで起動時に /tmp ディレクトリの中身をクリアするには、以下のように tmpfs ボリュームを使用する方法があります。

$ docker run --tmpfs /tmp my_image

docker compose の場合は以下のように指定します。

services:
 my_service:
 image: my_image
 volumes:
 - type: tmpfs
 target: /tmp
 # その他の設定

尚、docker compose で手動でボリュームを再作成したい場合は、以下のように docker compose down -v コマンドを使用して既存のボリュームを削除し、その後 docker compose up -d コマンドで新しいボリュームを作成してコンテナを起動します。

$ docker compose down -v
$ docker compose up -d

参考 URL

Stable Diffusion web UI を動かしてみた

Tue, 10 Dec 2024 00:00:00 +0900

ローカル環境で画像生成AIを使いたかったので、docker を使って Stable Diffusion web UI を動かしてみました。

環境

Ubuntu 20.04
docker 24.0.7

手順

Stable Diffusion web UI のリポジトリは以下になります。

https://github.com/AUTOMATIC1111/stable-diffusion-webui

Docker 版のリポジトリは以下です。

https://github.com/AbdBarho/stable-diffusion-webui-docker

まずはクローンしてきます。

$ git clone https://github.com/AbdBarho/stable-diffusion-webui-docker.git

あとは基本的に Setup に記載されている通りにすすめるだけです。

$ cd stable-diffusion-webui-docker
$ docker compose --profile download up --build
$ docker compose --profile auto up --build

しかし、私の場合、docker compose --profile auto up --build を実行したときにいくつかエラーが発生しました。

最初に発生したエラーは以下です。

@workspace Step 12/28 : RUN --mount=type=cache,target=/var/cache/apt apt-get update && apt-get install -y fonts-dejavu-core rsync git jq moreutils aria2 ffmpeg libglfw3-dev libgles2-mesa-dev pkg-config libcairo2 libcairo2-dev build-essential
the --mount option requires BuildKit. Refer to https://docs.docker.com/go/buildkit/ to learn how to build images with BuildKit enabled
ERROR: Service 'auto' failed to build : Build failed

生成AIに聞いてみた結果、どうやら buildx を手動でインストールする必要があるみたいでした。

まずバイナリをダウンロードします:

curl -SL https://github.com/docker/buildx/releases/download/v0.10.4/buildx-v0.10.4.linux-amd64 -o ~/.docker/cli-plugins/docker-buildx

ダウンロードしたファイルに実行権限を付与します:

chmod a+x ~/.docker/cli-plugins/docker-buildx

Docker Buildx が正しくインストールされたことを確認します:

docker buildx version

これで docker buildx コマンドが利用できるようになります。
再度 docker-compose --profile auto up --build を実行したところ、今度は以下のエラーが発生しました。

auto-cpu_1 | Installing extension dependencies (if any)
auto-cpu_1 | Traceback (most recent call last):
auto-cpu_1 | File "/stable-diffusion-webui/webui.py", line 13, in <module>
auto-cpu_1 | initialize.imports()
auto-cpu_1 | File "/stable-diffusion-webui/modules/initialize.py", line 23, in imports
auto-cpu_1 | import gradio # noqa: F401
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/gradio/__init__.py", line 3, in <module>
auto-cpu_1 | import gradio.components as components
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/gradio/components/__init__.py", line 3, in <module>
auto-cpu_1 | from gradio.components.bar_plot import BarPlot
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/gradio/components/bar_plot.py", line 7, in <module>
auto-cpu_1 | import altair as alt
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/__init__.py", line 649, in <module>
auto-cpu_1 | from altair.vegalite import *
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/vegalite/__init__.py", line 2, in <module>
auto-cpu_1 | from .v5 import *
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/vegalite/v5/__init__.py", line 2, in <module>
auto-cpu_1 | from altair.expr.core import datum
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/expr/__init__.py", line 11, in <module>
auto-cpu_1 | from altair.expr.core import ConstExpression, FunctionExpression
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/expr/core.py", line 6, in <module>
auto-cpu_1 | from altair.utils import SchemaBase
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/utils/__init__.py", line 14, in <module>
auto-cpu_1 | from .plugin_registry import PluginRegistry
auto-cpu_1 | File "/opt/conda/lib/python3.10/site-packages/altair/utils/plugin_registry.py", line 13, in <module>
auto-cpu_1 | from typing_extensions import TypeIs
auto-cpu_1 | ImportError: cannot import name 'TypeIs' from 'typing_extensions' (/opt/conda/lib/python3.10/site-packages/typing_extensions.py)

これについては現時点でのバグっぽいですが、以下に回避策がありました。

https://github.com/AbdBarho/stable-diffusion-webui-docker/issues/729

これで上手くいき、http://localhost:7860/ にアクセスすれば使用できました。

SDXLモデルの設定

SDXL モデルの設定については以下が参考になりました。

https://soroban.highreso.jp/article/article-042#651d4816a6d63105f25c3c7e-1aca58d91345337803792bb7

ただ、モデルと VAE の配置場所は現在のバージョンだと少し異なるようです。

モデル: data/models/Stable-diffusion
VAE: data/models/VAE

参考 URL

^ https://soroban.highreso.jp/article/article-042#651d4816a6d63105f25c3c7e-1aca58d91345337803792bb7

Jekyll + Docker で静的サイトを作成する

Wed, 11 Sep 2024 00:00:00 +0900

一番基本的なところを試してみたかっただけなのですが、嵌ったのでメモしておきます。

公式の Docker イメージは以下のようなのでこれを使いますが、長い間メンテナンスされていないようです。

https://hub.docker.com/r/jekyll/jekyll/

環境

Ubuntu 20.04
docker 24.0.7

新規作成

まずはドキュメントに従って、以下のコマンドでブログを新規作成してみます。

export site_name="my-blog"
docker run --rm \
 --volume="$PWD:/srv/jekyll" \
 -it jekyll/jekyll \
 sh -c "chown -R jekyll /usr/gem/ && jekyll new $site_name" \
 && cd $site_name

以下のエラーが出て失敗します。

/usr/local/lib/ruby/3.1.0/fileutils.rb:243:in `mkdir': Permission denied @ dir_s_mkdir - /srv/jekyll/my-blog (Errno::EACCES)

これでかなり嵌ったのですが、以下の記事を見つけました。

https://stackoverflow.com/questions/57503011/unable-to-build-cloned-jekyll-site-jekyll-3-8-5-error-permission-denied-d

どうやら環境変数を指定すればいいそうです。

export site_name="my-blog"
docker run --rm \
 -e JEKYLL_UID=1001 \
 -e JEKYLL_GID=1001 \
 --volume="$PWD:/srv/jekyll" \
 -it jekyll/jekyll \
 sh -c "chown -R jekyll /usr/gem/ && jekyll new $site_name" \
 && cd $site_name

これで、my-blog というフォルダが作成され、中に Jekyll のブログの雛形が作成されています。

ビルド

上記で作成した内容をビルドして静的サイトを生成します。
引き続き、環境変数を指定したうえでドキュメント通りに以下を実行します。

export site_name="my-blog"
docker run --rm \
 -e JEKYLL_UID=1001 \
 -e JEKYLL_GID=1001 \
 --volume="$PWD/$site_name:/srv/jekyll" \
 -it jekyll/jekyll \
 jekyll build

my-blog の中に _site というフォルダが出力されました。

サーバー起動

次はサーバーを起動してブラウザからアクセスしてみます。
こちらも引き続き、環境変数を指定したうえでドキュメント通りに以下を実行します。

export site_name="my-blog"
docker run --rm \
 -e JEKYLL_UID=1001 \
 -e JEKYLL_GID=1001 \
 --volume="$PWD/$site_name:/srv/jekyll" \
 -p 4000:4000 \
 -it jekyll/jekyll \
 jekyll serve --force_polling --livereload --host 0.0.0.0

以下のエラーが出ました。

<internal:/usr/local/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- webrick (LoadError)

webrick がないそうなので、my-blog 内の Gemfile に以下を追加します。

gem "webrick"

これで上記のコマンドを実行すれば無事サーバーが起動し、http://localhost:4000 にアクセスすることで閲覧できました。

所感

公式の Docker イメージ使って基本的なことを確認したかっただけなのに全然動かねぇじゃんって思いました。

参考 URL

https://stackoverflow.com/questions/57503011/unable-to-build-cloned-jekyll-site-jekyll-3-8-5-error-permission-denied-d

asciidoctor-pdf で admonition のアイコンを別の画像に差し替える

Mon, 09 Sep 2024 00:00:00 +0900

アイコン画像を別で用意して、それに差し替える方法です。

ドキュメント内で以下のように記述して、アイコンを画像ベースの設定に変更します。

:icons: image

そのうえで、PDF 作成用のテーマファイルで以下のように画像を指定します。

admonition:
 icon:
 note:
 image: '' # NOTEのアイコン画像のパスを指定
 caution:
 image: '' # CAUTIONのアイコン画像のパスを指定

参考 URL

redis コンテナでの redis-server の起動方法による違い

Thu, 27 Jun 2024 00:00:00 +0900

redis の公式のイメージを docker compose で動かしていたのですが、command を指定しない場合のデフォルトの実行コマンドは redis-server で、この場合、コンテナを再起動してもデータが残っていました。

しかし、コマンドを command: sh -c "redis-server" としたところ、コンテナ再起動でデータがクリアされたので、両者の違いについて ChatGPT に聞いてみました。

command: "redis-server":

この設定では、単純に redis-server コマンドが実行されます。Docker はこのコマンドを直接実行し、Redis サーバーが起動します。この場合、Redis サーバーが直接起動されるため、Redis のデフォルトの動作が適用され、データが残ります。再起動してもデータがクリアされないのは、Redis サーバーが正しく起動し、データをインメモリに保持しているためです。

command: sh -c "redis-server":

一方、この設定では、sh -c コマンドを使用してシェルでコマンドを実行します。sh -c コマンドは、指定されたコマンドをシェル経由で実行します。この場合、redis-server コマンドがシェル経由で実行されるため、Docker はシェルプロセスを起動し、そのシェルプロセスが redis-server コマンドを実行します。この場合、シェルプロセスがメインプロセスとなり、redis-server がそのサブプロセスとして実行されます。そのため、正しくプロセスが管理されない可能性があり、コンテナの再起動時にデータがクリアされる可能性があります。

[Docker] Python の Windows コンテナを動かしてみた

Mon, 18 Mar 2024 00:00:00 +0900

ホストもコンテナも Windows になるので、Dockerfile の記述方法や、コンテナ起動時のオプションの指定方法なども Linux とは異なります。

Windows 上で Docker を (Docker Desktop を使わずに) 動かす方法については以下を参照してください。

https://kuttsun.blogspot.com/2023/11/docker-windows.html

そのうえで、今回 Python の Windows コンテナを動かしてみました。

Docker Hub にある Python の Windows コンテナとしては、windowsservercore-ltsc2022 と windowsservercore-1809 があるようです。

https://hub.docker.com/_/python

今回は python:3.11-windowsservercore-1809 のイメージを使いました。

Dockerfile のサンプル

FROM python:3.11-windowsservercore-1809

CMD ["cmd.exe"]

Linux コンテナでは CMD [ "/bin/bash" ] のように記述していましたが、Windows コンテナでは CMD ["cmd.exe"] または CMD ["powershell.exe"] のように記述します。

コンテナ起動例

> docker run -it --rm ^
 --name コンテナ名 ^
 -v %CD%\workspace:C:\workspace ^
 --workdir=C:\workspace ^
 イメージ名

Linux ではカレントディレクトリを指定するために $(pwd) と記述したりしていましたが、Windows なので %CD% と記述します。
パスの区切りは \(バックスラッシュ) になります。
コマンド途中での改行も、Linux ではバックスラッシュでしたが、Windows なので ^ になります。
また、Windows コンテナなので、マウント先のパスも C ドライブからのパスで記述します。

とりあえずここまで。
追々いろいろ追記するかもしれません。

参考 URL

https://qiita.com/ishibashi-futoshi/items/db807d64624f43be1be9

[Docker] Windows コンテナを動かす

Tue, 21 Nov 2023 00:00:00 +0900

Docker Desktop を使わずに、Windows 10 に Docker のバイナリを直接インストールして、Windows コンテナを動かすまでをやってみました。

やり方は以下のドキュメントに記載されていました。

https://docs.docker.com/engine/install/binaries/#install-server-and-client-binaries-on-windows

記載の通り、これで動かせるようになるのは Windows コンテナのみで、Linux コンテナは動かせません。
Windows 上で Linux コンテナを動かしたい場合は、WSL を使う方法などがあります。

https://kuttsun.blogspot.com/2022/01/wsl2-ubuntu-docker.html

環境

Windows 10 Pro

Windows の機能の有効化

コントロールパネルの [Windows の機能の有効化または無効化] より、コンテナ にチェックを入れます。
これにチェックが入っていないと Docker コンテナが動きませんでした。

また、Hyper-V の有効化が必要という記事も見かけましたが、私の環境では Hyper-V を有効化しなくても動きました。
Hyper-V については以下を参照してください。

https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-requirements

インストール方法

バイナリのダウンロード

以下からインストールしたい Docker のバージョンのバイナリファイルをダウンロードします。

https://download.docker.com/win/static/stable/x86_64/

現時点で最新の 24.0.7 をダウンロードしました。

ProgramFiles への展開

ダウンロードした zip を ProgramFiles に展開するため、PowerShell を管理者で起動して以下を実行します。

> Expand-Archive <ダウンロードした zip へのパス> -DestinationPath $Env:ProgramFiles

$Env:ProgramFiles は環境変数 ProgramFiles を表示しており、通常は C:\Program Files というパスになります。
以降のコマンドは全て PowerShell で実行します。

サービスへの登録

Docker をサービスへ登録します。

> &$Env:ProgramFiles\Docker\dockerd --register-service

& は、PowerShell においてコマンドやスクリプトを呼び出す演算子です。
従って、環境変数展開後の C:\ProgramFiles\Docker\dockerd という文字列をコマンドとして実行しています。

サービスの開始

> Start-Service docker

動作確認

Hello World イメージを動かしてみます。

> &$Env:ProgramFiles\Docker\docker run hello-world:nanoserver

基本的にはこれで上手くいくはずですが、プロキシ環境下の場合は、後述するプロキシ設定が必要になります。

環境変数へパスを通す

毎回 &$Env:ProgramFiles\Docker\docker と打つのは面倒なため、$env:ProgramFiles\docker\ をPATHに追加します。

> [Environment]::SetEnvironmentVariable("Path", $env:Path + ";$env:ProgramFiles\docker\", [EnvironmentVariableTarget]::Machine)

PowerShell を一度閉じて、再度開きます。
これで以下のように docker と打つだけで実行できるようになります。

> docker run hello-world:nanoserver

プロキシ設定

プロキシ環境下では、プロキシサーバーの設定を行っていないと Docker イメージを pull できません。
設定方法については以下に記載がありました。

https://learn.microsoft.com/ja-jp/virtualization/windowscontainers/manage-docker/configure-docker-daemon

環境変数 HTTP_PROXY HTTPS_PROXY を設定します。

> [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://<IP address>:<port>", [EnvironmentVariableTarget]::Machine)

設定後、Docker サービスを再起動します。

> Restart-Service docker

docker クライアントのプロキシ設定

Linux では ~/.docker/config.json に設定しますが、Windows では %USERPROFILE%\.docker\config.json に設定します。

以下のように設定しておくことで、Dockerfile のビルドを行う際に --build-args などで都度プロキシの設定を行う必要がなくなります。

{
 "proxies": {
 "default": {
 "httpProxy": "http://<IPアドレス>:<port>",
 "httpsProxy": "http://<IPアドレス>:<port>",
 "noProxy": "localhost,127.0.0.1,host.docker.internal"
 }
 }
}

もしかしたら、一度 Docker サービスを再起動する必要があるかもしれません。

エラーが発生した場合

次のようなエラーが発生した場合、Docker サービスが起動していないか、プロキシにより通信が通っていないかのどちらか可能性が高いです。

Unable to find image 'hello-world:nanoserver' locally
docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
See 'docker run --help'

また、次のようなエラーが発生した場合、[Windows の機能の有効化または無効化] で コンテナ にチェックが入っていない可能性があります。

docker: Error response from daemon: hcs::CreateComputeSystem d5ccfe373c27d9053c87689f60075aed9acdca360d6cd42e1abdc5591bb60cbc: The request is not supported.

アンインストール

サービスから Docker を削除します。

> &$Env:ProgramFiles\Docker\dockerd --unregister-service

これだけではまだ完全にサービスは削除されていないので、一度 OS を再起動します。
その後、docker のフォルダを削除します。

> Remove-item -Recurse $Env:ProgramFiles\Docker

アップデート

現在のバージョンをアンインストールし、新しいバージョンをインストールします。

余談：他の Windows コンテナを動かしてみた

python3.11 の Windows コンテナを動かしてみました。

python イメージのタグ一覧が以下です。

https://hub.docker.com/_/python

Windows コンテナをベースとしている python3.11 のイメージとして以下の２つがあります。

3.11-windowsservercore-ltsc2022
3.11-windowsservercore-1809

私の PC では、3.11-windowsservercore-ltsc2022 は動かず、3.11-windowsservercore-1809 は動きました。
ベースとしている Windows コンテナの詳細は以下で確認できます。

https://hub.docker.com/_/microsoft-windows-servercore

参考 URL

[Docker] docker-compose の --scale でコンテナを複製した際に、コンテナ側で何番目のコンテナなのかを判別したい

Tue, 14 Nov 2023 00:00:00 +0900

本来、スケールは大きな負荷を処理できるようにするために使用し、スケールしたコンテナ毎に異なる構成を使用すべきではないと思いますが、それでも、スケールしたコンテナ毎にぞれぞれ別の構成が適用できると便利な場合もあります。その場合、複製したコンテナ内で、自身が何番目のコンテナなのかを把握できるのが最も都合が良いと考えます。

しかし、調べてみてもやり方が分からず、同様の質問はいくつか見つかりますが、現状、docker compose にはそのような機能は提供されていないようです。その代わりに、docker swarm でタスクスロットを使うことで、コンテナの番号をコンテナ内に設定することができました。

https://matsuand.github.io/docs.docker.jp.onthefly/engine/reference/commandline/service_create/

サンプル

以下のような docker-compose.yml を用意します。

version: '3'

services:
 server:
 image: nginx
 deploy:
 replicas: 3
 hostname: "server-{{.Task.Slot}}"

以下のコマンドでサービスを起動します。

$ docker swarm init # Swarmを初期化する（すでに初期化済みであれば不要）
$ docker stack deploy -c docker-compose.yml my_stack

docker ps で確認すると、コンテナが3つ起動しているのが確認できます。
ここで、3つのうちの1つのコンテナに入ってみます。

$ docker exec -it <コンテナ名> bash

コンテナ内で hostname を確認すると、番号が振られていることが確認できます。

# echo $(hostname)

尚、サービスを停止するには、以下のコマンドを使用します。

$ docker stack rm my_stack

参考 URL

YAML のアンカー/エイリアスと docker compose の profiles を使って docker-compose.yml を作成する

Fri, 25 Aug 2023 00:00:00 +0900

github などで公開されている docker-compose.yml を見ていると、見慣れない表記を見かけることがあり、調べてみると YAML のアンカー/エイリアス機能であることがわかりました。

これと、docker compose の --profiles を組み合わせて、docker-compose.yml 一つで様々な環境で動かすことができるようにしているのを見るととても便利だなと思ったので、メモしておきます。

yaml のアンカーとエイリアス

yaml 自体の標準機能です。
これを使うことで、記述内容を共通化して DRY にできます。

アンカー: & を付けることで、他の場所でも参照できるようにします。
エイリアス: * を付けて、アンカーで定義した内容を参照します。

サンプル1

aaa: &hoge
 bbb: 1111
 ccc: 2222
ddd: *hoge

上記の場合、以下の様に展開されます。

aaa:
 bbb: 1111
 ccc: 2222
ddd:
 bbb: 1111
 ccc: 2222

サンプル2

アンカー内にアンカーがあっても問題ありません。

aaa: &hoge
 bbb: 1111
 ccc: &piyo 2222
ddd: *hoge
eee: *piyo

上記の場合、以下の様に展開されます。

aaa:
 bbb: 1111
 ccc: 2222
ddd:
 bbb: 1111
 ccc: 2222
eee: 2222

マージ

<<: と記述することで、アンカーで定義した内容をそのまま入れ込むことができます。

aaa: &hoge
 bbb: 1111
 ccc: 2222
ddd:
 <<: *hoge
 eee: 3333

上記の場合、以下の様に展開されます。

aaa:
 bbb: 1111
 ccc: 2222
ddd:
 bbb: 1111
 ccc: 2222
 eee: 3333

アンカーの上書き

アンカー名と同じキーが後にあった場合、上書きされます。

aaa: &hoge
 bbb: 1111
 ccc: 2222
 ddd: 3333
eee:
 <<: *hoge
 bbb: 4444
fff:
 <<: *hoge
 ddd: 5555

上記は以下のように展開されます。

aaa:
 bbb: 1111
 ccc: 2222
 ddd: 3333
eee:
 bbb: 4444
 ccc: 2222
 ddd: 3333
fff:
 bbb: 1111
 ccc: 2222
 ddd: 5555

これを使って、内容の大部分を共通化しつつ一部分だけは変えたいということができます。

docker-compose.yml で使用する場合

docker-compose.yml 内で共通の設定を括りだそうと以下の様に書くとエラーになります。

common: &common
 image: hoge
service:
 app:
 <<: *common

docker compose によって common 自体が解釈されるためです。
この場合、プレフィックスとして x- を付けると、docker compose からは無視されるようになります。

x-common: &common
 image: hoge
service:
 app:
 <<: *x-common

docker compose の profile

docker-compose.yml で定義されたサービスに profiles を定義することで、サービスのグループ分けやタグ付けのようなことができます。
以下が公式ドキュメントによる説明です。

https://docs.docker.jp/compose/profiles.html

profiles で指定したサービスのみを起動させることができるようになります。

上記を踏まえた実用的なサンプル

上記を踏まえると、yaml のアンカー/エイリアスにより記述内容を共通化しつつ、profile によって起動するコンテナを切り替えることができます。

尚、今回の記事を書くことになった動機が、以下の Stable Diffusion 用の docker-compose.yml を見たときで、どういう意味なんだろうと思ったのがきっかけです。

https://github.com/AbdBarho/stable-diffusion-webui-docker

GPU を使う場合と、CPU を使う場合とで上手く共通化されており、また記述量も少なくサンプルとして丁度いいので、こちらをサンプルとして挙げさせていただきます。

docker-compose.yml の確認

ちなみに、docker compose によってどのように yaml ファイルが読み込まれるか確認するには、config オプションを使用します。

$ docker compose config

参考 URL

Telegraf で Jetson の GPU 情報を取得する

Sat, 27 May 2023 00:00:00 +0900

Telegraf で GPU 情報を取得しよううとしたのですが、Jetson には nvidia-smi のコマンドがありません。

どうしようかなと思っていたら、以下の記事に Jetson で GPU 情報を取得する方法が書いてありました。

https://www.influxdata.com/blog/nvidia-jetson-series-part-1-jetson-stats/

これを参考に、InfluxDB にデータを保存し、Grafana で可視化まで行いました。
尚、TIG Stack (Telegraf, InfluxDB, Grafana) については以下を参考にしてください。

https://kuttsun.blogspot.com/2021/12/telegraf-influxdb-garafana.html

環境

Jetson Xavier NX
Ubuntu 18.04
Telegraf 1.23.0

Telegraf, InfluxDB, Grafana は Docker で動作させています。

Jetson Stats のインストール

まずはホストに Jetson Stats をインストールします。

$ sudo apt-get update
$ sudo apt-get install python3-pip
$ sudo -H python3 -m pip install -U jetson-stats

インストール後、一度ログアウト or 再起動します。

jtop を実行して動作確認します。

Telegraf の設定

Jetson Stats を使って GPU の情報を取得する python スクリプトを作成し、それを Telegraf から定期的に実行するようにします。
ただし、今回 Telegraf は Docker コンテナで動かしているので、上記の記事そのままでは上手く行きません。

Python スクリプトの作成

上記の記事にある以下のスクリプトを jetson_stats.py という名前で保存しました。

# Import jtop python library. We will use this to access the Jetson_Stats service.
from jtop import jtop
import json, datetime

if __name__ == "__main__":

 with jtop() as jetson:
 # jetson.stats provides our system measurements as type dict.
 tmp = jetson.stats
 # time and uptime are proved as time objects. These needed to be converted before passing as a JSON string,
 tmp["time"] = str(tmp["time"].strftime('%m/%d/%Y'))
 tmp["uptime"] = str(tmp["uptime"])
 # We then convert our dict -&gt; Json string
 influx_json= {"jetson": tmp}
 print(json.dumps(influx_json))

このスクリプトを Telegraf から定期的に実行することになります。

Dockerfile の作成

今までは Telegraf の Docker イメージをそのまま使っていましたが、このコンテナには Python の実行環境が入っていないため、上記の Python スクリプトを動かすことができません。
そこで、以下のような Dockerfile を作成しました。

FROM telegraf:1.23.0

ARG DEBIAN_FRONTEND=noninteractive

COPY jetson_stats.py /usr/local/bin/

RUN apt update &amp;&amp; \
 apt install -y --no-install-recommends \
 python3 \
 python3-pip \
 python3-setuptools \
 python3-wheel &amp;&amp; \
 apt autoremove &amp;&amp; apt clean &amp;&amp; rm -rf /var/lib/apt/lists/*

RUN pip3 install \
 jetson-stats

jetson_stats.py をイメージ内にコピーし、あとは Python の実行環境と Jetson Stats をインストールしています。

docker-compose.yml の変更

コンテナ内で Jetson Stats を使うためには、/run/jtop.sock をマウントする必要があるようです。
ただ、それだけではアクセス権限の関係で以下のようなエラーが表示されました。

jtop.core.exceptions.JtopException: I can't access jetson_stats.service.

Docker コンテナの実行ユーザーを /run/jtop.sock の所有グループに加えたら解決できたので、group_add のプロパティを追加します。

https://github.com/rbonghi/jetson_stats

以上を踏まえ、docker-compose.yml を以下のように変更しました（今回に関連する部分のみ抜粋）。

services:
 telegraf:
 image: telegraf-python:latest
 container_name: telegraf
 hostname: ${HOSTNAME:?}
 environment:
 - NVIDIA_VISIBLE_DEVICES=all
 - NVIDIA_DRIVER_CAPABILITIES=all
 deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
 restart: unless-stopped
 ports:
 - 6514:6514
 volumes:
 - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /usr/bin/nvidia-smi:/usr/bin/nvidia-smi:ro
 # 以下は Jetson Xavier NX 用
 - /run/jtop.sock:/run/jtop.sock:ro # https://github.com/rbonghi/jetson_stats
 user: ${TELEGRAF_UID_GID:?}
 group_add:
 - "${JTOP_GID:?}"

環境変数の追加

上記の docker-compose.yml 内にある JTOP_GID という環境変数を定義します。
~/.bashrc に以下を追記します。

export JTOP_GID=$(stat -c '%g' /run/jtop.sock)

再読み込みします。

~$ source .bashrc

これで、/run/jtop.sock の所有グループを JTOP_GID で参照できます。

telegraf.conf の設定

telegraf.conf に以下を追記します。

[[inputs.exec]]
 ## Commands array
 commands = [
 "python3 /usr/local/bin/jetson_stats.py"
 ]

 ## Timeout for each command to complete.
 timeout = "5s"

 ## measurement name suffix (for separating different commands)
 name_suffix = "_jetson_stats"

 ## Data format to consume.
 ## Each data format has its own unique set of configuration options, read
 ## more about them here:
 ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
 data_format = "json"
 ## Array of glob pattern strings or booleans keys that should be added as string fields.
 json_string_fields = ["jetson_uptime", "jetson_nvp model", "jetson_NVENC", "jetson_NVDEC", "jetson_NVJPG"]

内容は前述の参考記事の中身そのままです。

テスト

Docker コンテナに入って、以下のコマンドを実行します。

python3 jetson_stats.py

json が取得できていれば OK です。

Grafana のダッシュボードを作成

Jetson Stats 用のテンプレートがないかなと探してみましたが、見つかりませんでした。
どうやら自分で作成するしかなさそうです。

参考として、jetson_stats.py を実行したら以下のような出力が得られます（わかりやすいように整形しています）。

{
 "jetson": {
 "time": "09/14/2022",
 "uptime": "0:40:39.970000",
 "jetson_clocks": "OFF",
 "nvp model": "MODE_10W_DESKTOP",
 "CPU1": 16,
 "CPU2": 13,
 "CPU3": 13,
 "CPU4": 14,
 "CPU5": "OFF",
 "CPU6": "OFF",
 "GPU": 0,
 "MTS FG": 0,
 "MTS BG": 0,
 "RAM": 1413804,
 "EMC": 1413804,
 "SWAP": 0,
 "APE": 150,
 "NVENC": "OFF",
 "NVDEC": "OFF",
 "NVJPG": "OFF",
 "fan": 0.0,
 "Temp AO": 42.0,
 "Temp AUX": 42.0,
 "Temp CPU": 42.5,
 "Temp GPU": 41.5,
 "Temp thermal": 42.15,
 "power cur": 4166,
 "power avg": 4166
 }
}

これらの値が InfluxDB に格納されているはずなので、その値を使ってダッシュボードを作成していきます。
尚、各プロパティの説明は以下にありました。

https://rnext.it/jetson_stats/jtop.html#jtop.jtop.jtop.stats

単位くらい書いておいてほしいなぁ〜。

参考 URL

[Docker] docker-compose の env_file 内でシェルスクリプトを実行する

Fri, 12 May 2023 00:00:00 +0900

Docker Compose の env_file ディレクティブを使用する場合、原則として env_file に指定されたファイル内でシェルのシンタックスを使用することはできません。

しかし、env_file にはシェルスクリプトを指定することもできますので、以下のようにシェルスクリプトファイル（例えば、env.shとします）を作成することで対応できます。

#!/bin/bash
export MY_VARIABLE=my_value

docker-compose.yml の env_file ディレクティブでシェルスクリプトファイルを指定します。

version: '3'
services:
 myservice:
 env_file:
 - ./env.sh

注意点として、シェルスクリプトのパーミッションを正しく設定する必要があります。
また、シェルスクリプト内で環境変数を定義する場合には export する必要があります。

ちなみに、env_file で定義された環境変数は、コンテナ内では使えますが、docker-compose.yml 内では使えません。
（これでちょっとはまりました。）

https://zenn.dev/rhene/scraps/781fdbecd340d3

参考 URL

Nginx で upstream の名前解決を無効化（回避）する方法

Thu, 16 Feb 2023 00:00:00 +0900

Docker で動かしている Nginx でリバースプロキシの設定を行い、別の Docker コンテナに転送するように設定したときにちょっとはまったのでメモです。

コンテナ同士はコンテナ名を使ってアクセスできるので、Nginx の設定では以下のようにリバースプロキシの設定を行っています。

location /some_path {
 proxy_pass http://container-name.docker-network:port;
}

このとき、Nginx は起動時に upstream の名前解決を行っているので、上記の URL の名前解決ができない場合（つまり転送先のコンテナが起動していない）と host not found in upstream というエラーが表示されて起動に失敗します。

私の場合、仕様によって起動するコンテナの数が異なったり、開発中は一部のコンテナだけ起動して確認したりするので、その都度 Nginx の設定を変えるのは面倒です。
なので、名前解決できなくても Nginx が起動できるように回避策がないかと調べた所、以下の記事に書いてありました。

https://serverfault.com/questions/700894/make-nginx-ignore-site-config-when-its-upstream-cannot-be-reached

resolver のディレクティブを使って名前解決してやることで回避できるそうです。

location /some_path {
 resolver 127.0.0.1 valid=30s; 
 # resolver 8.8.8.8 valid=30s; # or some other DNS
 # resolver 127.0.0.11 valid=30s; # or Docker's DNS server
 set $dummy_var http://container-name.docker-network:port;
 proxy_pass $dummy_var;
 }

私の場合、Nginx を Docker で動かしているので、127.0.0.11 をリゾルバに指定することで、転送先のコンテナが起動していなくても Nginx が起動できるようになりました。

参考 URL

Docker Volume をコピー（複製）する

Fri, 14 Oct 2022 00:00:00 +0900

Linux だと /var/lib/docker/volumes/<volume_name> に保存されているため、基本的にはこれを cp コマンドでコピーするだけで OK です。

# -p to preserve permissions
$ sudo cp -rp /var/lib/docker/volumes/source_volume /var/lib/docker/volumes/target_volume

参考 URL

TIG Stack を動かしてみる

Fri, 16 Sep 2022 00:00:00 +0900

サーバーリソースのメトリクスやログの収集・保存・可視化・アラートを行うためにTIG Stack (Telegraf, InfluxDB, Grafana) を使って一通り設定してみました。

一応、以前にも記事は書いていますが、

https://kuttsun.blogspot.com/2021/12/telegraf-influxdb-garafana.html

ちょっと情報が古くなっていたので、アップデートし、さらに出来る限り設定を自動化しました。

予備知識

時系列とは何ぞや？ TICK スタックとは何ぞや？みたいな話が以下に載ってました。

環境

TIG Stack は全て Docker で動かします。

Ubuntu 20.04
Docker 20.10.12
Telegraf 1.23.0
InfluxDB 1.8.10
Grafana 9.1.0

各ツールの役割

ツール	役割	Docker イメージ
Telegraf	データの収集	https://hub.docker.com/_/telegraf
InfluxDB	データの保存（時系列データベース）	https://hub.docker.com/_/influxdb
Grafana	データの可視化（UI）	https://hub.docker.com/r/grafana/grafana/

上記の Docker hub のページに各ツールの起動方法や設定方法などが一通り載っているので、それを参考に設定していきます。

Telegraf の設定

まずは設定ファイルの雛型（デフォルトの設定ファイル）を取得します。
Telegraf の Docker コンテナを起動し、コンテナ内から設定ファイルをホストにコピーしてきます。

$ docker run --rm telegraf telegraf config > telegraf.conf

この telegraf.conf を取得したいデータに応じて編集します。
これについてはいろいろあるので、別記事にまとめました。

docker-compose.yml

設定ファイルが必要なのは Telegraf だけなので、ここで TIG Stack を起動する docker-compose.yml のサンプルを載せます。
前提として、tigstack というネットワークを共通に使用しているので、以下のコマンドであらかじめ作成しておく必要があります。

$ docker network create tigstack

以下、docker-compose.yml のサンプルです。解説などは後述します。

Telegraf について

GPU の情報取得について

NVIDIA の GPU の情報を取得するために以下を指定しています。

environment:
 - NVIDIA_VISIBLE_DEVICES=all
 - NVIDIA_DRIVER_CAPABILITIES=all
deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
volumes:
 - /usr/bin/nvidia-smi:/usr/bin/nvidia-smi:ro

これについては以下の記事を参照してください。

/usr/bin/nvidia-smi のパスは環境によっては異なるかもしれません。

Docker の情報取得について

Docker の情報を取得するためには /var/run/docker.sock をマウントする必要があります。
さらに Telegraf の実行ユーザーが docker.sock にアクセスできるように、user を設定する必要があります。

volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
user: ${TELEGRAF_UID_GID:?}

これについては以下の記事を参照してください。

ホスト名の指定

Telegraf がメトリクスを InfluxDB に記録する際、ホスト名も記録されますが、Docker コンテナのホスト名はデフォルトだとランダムな値となり、このままでよくわからないので、設定します。
ここではホストマシンと同じホスト名を指定しました。

hostname: ${HOSTNAME:?}

これについては以下の記事を参照してください。

InfluxDB について

初回起動時にデフォルトのリテンションポリシーを設定するために以下を指定しています。

environment:
 DOCKER_INFLUXDB_INIT_MODE: setup
 DOCKER_INFLUXDB_INIT_RETENTION: 10d

docker-compose のアップデート方法

Mon, 12 Sep 2022 00:00:00 +0900

apt でインストールした docker-compose のバージョンが古いので、手動でアップデートする方法です。

docker-compose のリリースビルド一覧は以下で確認できます。

https://github.com/docker/compose/releases

# 現在インストールされている docker-compose をアンインストール
sudo apt remove docker-compose
# カーネル名を小文字にするため一度変数 kernel に代入
kernel=$(uname -s)
# ダウンロード
sudo wget -O /usr/bin/docker-compose https://github.com/docker/compose/releases/download/v2.10.2/docker-compose-${kernel,,}-$(uname -m)
# 実行権限の付与
sudo chmod +x /usr/bin/docker-compose

一応これで intel 系と arm 系で上手くいくことは確認しました。

参考 URL

https://github.com/docker/compose/releases

[Docker] コンテナ内の実行ユーザーをホストのユーザーと合わせる

Tue, 30 Aug 2022 00:00:00 +0900

Docker コンテナにホストのディレクトリをマウントしている場合、コンテナ内の実行ユーザーとホストのユーザーが一致していないと、コンテナ内で作成されたファイルにアクセス権限がなくて困ることがあります。

これはコンテナ内の実行ユーザーをホストのユーザーと合わせることで解決できますが、じゃあユーザーの指定はどうするのが一番良いか？ということで、以下の記事がとても参考になりました。

https://qiita.com/yohm/items/047b2e68d008ebb0f001

ほとんどの場合、以下で上手く行くそうです。

$ docker run -it \
 -v /etc/group:/etc/group:ro \
 -v /etc/passwd:/etc/passwd:ro \
 -u $(id -u $USER):$(id -g $USER) \
 ubuntu bash

私の場合もこれで上手く行きました。

参考 URL

https://qiita.com/yohm/items/047b2e68d008ebb0f001

overlayroot 環境内で docker を使う方法

Fri, 19 Aug 2022 00:00:00 +0900

overlayroot でルートファイルシステムを読み取り専用にしたところ、docker が使えなくなりました。

OS は Ubuntu 20.04 です。
overlayroot を有効にする方法などについては以前の記事を参考にしてください。

https://kuttsun.blogspot.com/2022/04/overlayroot-ubuntu.html

問題点

Docker がインストールされている環境で、overlayroot でルートファイルシステムを読み取り専用にした場合、docker コマンドを実行すると以下のようなエラーが発生します。

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

いろいろ調べてみた結果、基本的に overlayroot が有効な状態では docker は使えないようです。
一応以下にあるやり方で docker コンテナを立ち上げるところまではできました。

しかし、そもそも Docker ボリュームには DB のデータなどを逐次格納していっているので、tmpfs 上（＝メモリ上）だとメモリがすぐ枯渇してしまいそうです。
また、Docker コンテナ・イメージをアップデートしたい場合にも困ります。

というわけで、少なくとも /var/lib/docker の領域はパーティションを分けるしかないじゃないかというところに行き着きました。
以下のページでも書き込み可能としたい場合はパーティションを分ける方法が紹介されています。

https://armadillo.atmark-techno.com/index.php/blog/10899/8648

また、Docker に関するベストプラクティスでも、コンテナ用にパーティションを分けるとあります。

https://www.creationline.com/lab/aquasecurity/43087

その上で、Docker コンテナも read-only で起動すれば、ルートファイルシステムだけでなく Docker コンテナも保護できそうです。

対処方法

とりあえず以下のようにパーティションを分けることで overlayroot と docker の共存ができました。

パス	マウントポイント
/dev/sda1	EFI システムパーティション
/dev/sda2	/
/dev/sda3	/var

この状態で overlayroot をインストールし、/etc/overlayroot.local.conf に overlayroot="tmpfs:recurse=0" を記載します。コマンド一発でやる場合は以下です。

$ echo 'overlayroot="tmpfs:recurse=0"' | sudo tee -a /etc/overlayroot.local.conf

overlayroot のインストールや設定については以前の記事を参考にしてください。

https://kuttsun.blogspot.com/2022/04/overlayroot-ubuntu.html

今回はルートファイルシステムのみを読み取り専用にするので、tmpfs:recurse=0 を指定するらしいです。
以下が参考になりました。

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0568

これで再起動すれば、ルートファイルシステムのみが読み取り専用となり、/var は読み書き可能な状態となります。
docker も普通に使えました。

参考 URL

InfluxDB のコンテナ作成時にデータベースとリテンションポリシーの作成を行う

Tue, 09 Aug 2022 00:00:00 +0900

Docker を使って InfluxDB を動かしているのですが、データベースとリテンションポリシーをコンテナ起動時に作成できないかなと思い、調べてみたらやり方を見つけました。

以下のページが参考になりました。

https://www.easydevguide.com/posts/docker_influxdb_init

環境

InfluxDB: 1.8.10

作成方法

まず適当な名前（ここでは setup_influxdb.sh）でシェルスクリプトファイルを作成し、以下のような内容で記述します。

# create database
influx -execute "CREATE DATABASE dbname"
# create retention policy
influx -execute "CREATE RETENTION POLICY rpname ON dbname DURATION 30d REPLICATION 1 DEFAULT"

dbname, rpname, 保存期間などは適当に置き換えてください。

これを、InfluxDB のコンテナ内の /docker-entrypoint-initdb.d/ に配置します。
例えば、私の場合は docker-compse を使っているので、以下のようにマウントしました。

services:
 influxdb:
 image: influxdb:1.8.10
 container_name: influxdb
 restart: unless-stopped
 expose:
 - 8086
 volumes:
 - influxdb:/var/lib/influxdb
 - ./setup_influxdb.sh:/docker-entrypoint-initdb.d/setup_influxdb.sh:ro
volumes:
 influxdb:

これでコンテナ起動時にスクリプトが実行され、データベースとリテンションポリシーが作成されます。

確認方法

まずコンテナに入ります。

$ docker exec -it influxdb bash

データベースの一覧は以下で確認できます。

# influx
> show databases

リテンションポリシーの一覧は以下で確認できます。

# influx
> use dbname
> show retention policies

参考 URL

WSL2 上の Docker コンテナに外部からアクセスする

Fri, 29 Jul 2022 00:00:00 +0900

Ubuntu で Docker を使っている場合はホストとコンテナのポートマッピングさえ行えば外部からアクセスできました。
しかし、WSL2 を使っている場合は Windows と WSL2(Ubuntu) のポートフォワーディングの設定を行わないと外部からはアクセスできません。

尚、タイトルには「Docker コンテナに外部からアクセス」と書きましたが、Windows と WSL2 の話なので、Docker は関係ありません。

環境

ホスト: Windows 10
WSL2: Ubuntu 20.04

設定方法

WSL2 の IP アドレスを調べる

まずは WSL2 上で以下のコマンドを実行し、eth0 の IP アドレスを調べます。

$ ip addr show dev eth0

または hostname -I でも調べられます。

Windows と WSL2 のポートフォワーディング設定

コマンドプロンプトまたは PowerShell で以下のコマンドを実行します。

> netsh interface portproxy add v4tov4 listenport=<ポート> connectaddress=<WSL2のIPアドレス>

これで外部からアクセス可能になります。
設定ができているか確認したい場合は以下のコマンドを実行します。

> netsh interface portproxy show v4tov4

ipv4 をリッスンする: ipv4 に接続する:

Address Port Address Port
--------------- ---------- --------------- ----------
* 5001 172.20.93.38 5001

設定を削除したい場合は以下のコマンドを実行します。

> netsh interface portproxy delete v4tov4 listenport=<ポート>

設定の自動化

WSL2 の IP アドレスは起動の度に変わるので、Windows 起動時に自動で設定するようにします。

Windows 上で WSL2 の IP アドレスを取得

PowerShell で以下を実行します。

> $IP = wsl -d Ubuntu-20.04 exec hostname -I

しかし、私の環境では複数の IP アドレスが表示されてしまいました。

> $IP
172.20.93.38 172.17.0.1 172.18.0.1

なので、以下のようにスペースで区切って最初の IP アドレスだけを取得できるようにしました。

> $IP = (wsl -d Ubuntu-20.04 exec hostname -I).split(" ")[0]

スクリプトファイルの作成と実行

以上を踏まえ、以下のようなスクリプトファイルを作成します。

$IP = (wsl -d Ubuntu-20.04 exec hostname -I).split(" ")[0]
netsh interface portproxy delete v4tov4 listenport=<ポート>
netsh interface portproxy add v4tov4 listenport=<ポート> connectaddress=$IP

あとはこれをタスクスケジューラーでログオン時に実行するようにすれば OK です。

参考 URL

Telegraf が docker.sock にアクセスできない

Sat, 02 Jul 2022 00:00:00 +0900

Docker コンテナ内で Telegraf を動かして、Docker の情報を収集するには /var/run/docker.sock をマウントする必要がありますが、それだけでは以下のように Got permission denied のエラーが表示されました。

E! [inputs.docker] Error in plugin: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied
E! [inputs.docker] Error in plugin: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?filters=%7B%22status%22%3A%7B%22running%22%3Atrue%7D%7D&limit=0": dial unix /var/run/docker.sock: connect: permission denied

Telegraf の 1.20.3 以降、Telegraf の実行ユーザーは telegraf という非 root ユーザーに変わったらしいです。

https://www.influxdata.com/blog/docker-run-telegraf-as-non-root/

なので、Telegraf の実行ユーザーが docker コマンドを実行できるように、以下のように user を指定する必要があるそうです。

$ docker run --user telegraf:$(stat -c '%g' /var/run/docker.sock) ...

docker-compose の場合

yml 内ではシェル変数を参照できないので、あらかじめ環境変数を設定しておくなど、少し工夫が必要です。

$ export TELEGRAF_UID_GID=telegraf:$(stat -c '%g' /var/run/docker.sock)

docker-compose.yml で環境変数を参照します。

user: ${TELEGRAF_UID_GID}

ここらへんについては以下の記事が参考になると思います。

https://kuttsun.blogspot.com/2022/06/docker-composeyml-hostname.html

参考 URL

https://www.influxdata.com/blog/docker-run-telegraf-as-non-root/

docker-compose.yml での環境変数の参照とデフォルト値の設定

Fri, 01 Jul 2022 00:00:00 +0900

公式ドキュメントを見ていろいろ設定方法があることを知ったのでメモです。

https://docs.docker.com/compose/compose-file/#interpolation

以下、ほぼ訳しただけです。

環境変数の参照

$VARIABLE または ${VARIABLE} で参照できます。
もし VARIABLE が定義されていなければ、空文字に置換されます。

補間 (interpolation)

以下のようにして、環境変数が設定されていない場合のデフォルト値を指定できます。

${VARIABLE:-default} とすると、環境変数 VARIABLE が定義されていないか空の場合に default に置換されます。
${VARIABLE-default} とすると、環境変数 VARIABLE が定義されていない場合に default に置換されます。

同様に、以下のように必須変数を指定できます。

${VARIABLE:?err} とすると、環境変数 VARIABLE が定義されていないか空の場合にエラーとなります。
${VARIABLE?err} とすると、環境変数 VARIABLE が定義されていない場合にエラーとなります。

yaml のアンカー/エイリアス機能

以下の記事で初めて知ったのですが、x- で始まるキーを書くことで、docker-compose で無視されるようになるそうです。

https://techracho.bpsinc.jp/hachi8833/2020_02_07/87447

参考 URL

docker-compose.yml で HOSTNAME が参照できない？

Thu, 30 Jun 2022 00:00:00 +0900

docker-compose.yml で $HOSTNAME と記述すると以下のようなエラーが表示され、かなりはまってしまいました。

The HOSTNAME variable is not set. Defaulting to a blank string

Ubuntu では HOSTNAME が export されていないそうなので、環境変数として参照できないようです。
どうやらかなり昔からの仕様のようですが、Ubuntu 20.04 でも状況は変わっていません。

https://ubuntuforums.org/archive/index.php/t-898924.html

私は誤解していましたが、HOSTNAME は環境変数ではなくシェル変数です。

そして、export されていないから環境変数として yml からは参照できないと。
なので、以下のようにすれば参照できるようになります。

$ export HOSTNAME && docker-compose up

毎回 export するのが面倒な場合は .bashrc に書いておくのがいいかもしれません。

参考 URL

Portainer API を使って Docker Engine API を叩いてみる

Mon, 27 Jun 2022 00:00:00 +0900

Docker を WebUI で操作できる Portainer には API が用意されており、これを使えば Portainer の UI でできることを全て自動化できます。また、Portainer API を介して Docker Engine API も叩くことができるので試してみました。

Portainer の API のドキュメントは以下です。

https://docs.portainer.io/api/docs

Docker Engine API のドキュメントは以下です。

https://docs.docker.com/engine/api/v1.41/

Python + aiohttp で実装してみました。

環境

Docker 20.10.12
Portainer 2.13.1
Python 3.8.10
aiohttp 3.8.1

サンプルコード

細かい解説は後にして、先にコード全体を載せます。

import asyncio
import aiohttp

PORTAINER_URL="http://portainer_url"

async def main():
 async with aiohttp.ClientSession() as session:

 # トークンを取得
 r = await session.post(f'{PORTAINER_URL}/api/auth', json={ 'Username': 'Admin', 'Password': 'AdminPassword' })
 data = await r.json()
 jwt = data['jwt']
 
 # ヘッダー
 headers={ 'Authorization': f'Bearer {jwt}' }
 #headers={ 'X-API-Key': 'token' }

 # EnvironmentID を取得
 r = await session.get(f'{PORTAINER_URL}/api/endpoint_groups', headers=headers)
 environments = await r.json()
 id = environments[0]['Id']

 # コンテナ一覧の取得
 r = await session.get(f'{PORTAINER_URL}/api/endpoints/{id}/docker/containers/json', json={ 'all': 'true' }, headers=headers)
 containers = await r.json()
 print(containers)

if __name__ == '__main__':
 asyncio.run(main())

トークンの取得

Portainer のアカウントを使って JWT トークンを取得します。

r = await session.post(f'{PORTAINER_URL}/api/auth', json={ 'Username': 'Admin', 'Password': 'AdminPassword' })
data = await r.json()
jwt = data['jwt']

このトークンは8時間の間だけ有効だそうです。
または、Portainer の myaccount 画面からでも API トークンを発行できます。
それぞれヘッダーの書き方が少し異なります。

前者の場合は

headers={ 'Authorization': f'Bearer {jwt}' }

後者の場合は

headers={ 'X-API-Key': 'token' }

のように記述します。

Environment(endpoint) ID の取得

Portainer は複数の Docker ホストを管理できるので、Docker Engine API を叩く際にはどのホストの Docker に対する操作かを指定する必要があります。　　　　なので、Docker Engine API を叩く前に Environment の一覧を取得します。

https://app.swaggerhub.com/apis/portainer/portainer-ce/2.13.1#/endpoint_groups/EndpointGroupList

r = await session.get(f'{PORTAINER_URL}/api/endpoint_groups', headers=headers)
environments = await r.json()
id = environments[0]['Id']

コンテナの一覧を取得

コンテナの一覧を取得してみます。
API の仕様は以下を参照してください。

https://docs.docker.com/engine/api/v1.41/#tag/Container

Portainer のエンドポイント /api/endpoints/{id}/docker より後ろが docker のエンドポイントと同じになるみたいですね。

r = await session.get(f'{PORTAINER_URL}/api/endpoints/{id}/docker/containers/json', json={ 'all': 'true' }, headers=headers)
containers = await r.json()

ここまでやれば、後は大体のことができるんじゃないかと思います。

参考 URL

リバースプロキシの背後で Grafana を動かす

Fri, 24 Jun 2022 00:00:00 +0900

サーバー側だけでなく Grafana 側の設定も行う必要があったのでメモです。

一応公式ドキュメントに方法が載っています。

https://grafana.com/tutorials/run-grafana-behind-a-proxy/

今回はサブディレクトリで設定したかったのと、Grafana を docker-compose で動かしていたので、docker-compose.yml の環境変数で以下のように設定しました。

environment:
 - GF_SERVER_ROOT_URL=%(protocol)s://%(domain)s:%(http_port)s/grafana/
 - GF_SERVER_SERVE_FROM_SUB_PATH=true

サーバー側の設定は普通にリバースプロキシの設定を行うだけなので省略します。

参考 URL

[Docker] ログドライバーでログの出力先を syslog に設定する

Thu, 23 Jun 2022 00:00:00 +0900

Docker コンテナで標準出力されているログを syslog に記録するようにログドライバーを設定します。

Docker のログドライバーで設定できるものには他にもいろいろあります。

https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/logging/configure/

オプションはログドライバーによって異なるようで、syslog の場合は以下になります。

https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/logging/syslog/

以上を踏まえ、docker-compose でログドライバーを設定する例が以下になります。

logging:
 driver: syslog
 options:
 tag: 'my-app-name'

デフォルトでは appname がコンテナIDになって分かりづらいので、tag で設定しています。

余談

コンテナ内で動かしている Python のアプリケーションでは、もともと logging モジュールで syslog に記録するよう設定していました。
これを標準出力にし、Docker のログドライバーで設定できるようにすれば、コンテナを使う側が出力先を決められて便利かなと思いました。

しかし、Python 側では5段階に分けられていたログレベルが、標準出力を介すことで、Info (stdout) と Error (stderr) の2レベルに平坦化されてしまうことが分かり、結局 Python 側で syslog に記録するようにしました。

もしかしたから何か上手いやり方があるのかもしれませんが・・・。

参考 URL

https://qiita.com/Esfahan/items/5e5a9ae7882bb0eaaf5f

[Docker] OpenCV + python のマルチステージビルドを行う

Mon, 20 Jun 2022 00:00:00 +0900

Python の OpenCV で GStreamer を使う場合、自前でビルドする必要があり、そのための Dockerfile を以前作成しました。

その時の記事が以下です。

https://kuttsun.blogspot.com/2021/11/opencv-gstreamer.html

ただ、これで作成した Docker イメージのサイズが 2.5GB くらいあり、もっとサイズを小さくできないかなと考えていました。

その過程でマルチステージビルドというものを知ったのですが、OpenCV のビルドの成果物をどうやって最後のステージに持ってきたらよいか分からず悩んでいたら、以下のページを見つけました。

ビルドステージでは、make install の後、ldconfig で共有リンクを作成しています。
リリースステージでは /usr/local/lib 以下を全てコピーし、ldconfig で共有リンクを作成しています。

というわけで、これを参考にマルチステージビルドを行ってみました。ただ、私の場合、/usr/local/lib のコピーだけでは依存パッケージが不足していて動かなかったので、/usr/lib と /usr/share の中身も全部コピーしたら動くようになりました。

COPY --from=build /usr/lib /usr/lib
COPY --from=build /usr/share /usr/share
COPY --from=build /usr/local/lib /usr/local/lib
RUN ldconfig

以上で、イメージサイズを 1.9GB まで減らせました。
ここらへん、本当に依存しているパッケージだけをコピーするようにできれば、まだまだサイズを小さくできそうではあります。

以下、Dockerfile のサンプルです。

# Stage1: build
FROM ubuntu:20.04 as build

# tzdataのタイムゾーン入力を求められないようにする
# https://tmyoda.hatenablog.com/entry/20210124/1611416396
ENV TZ=Asia/Tokyo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

RUN apt update && \
 apt install -y --no-install-recommends \
 software-properties-common && \
 update-ca-certificates && \
 # 必要なパッケージをインストール
 apt install -y \
 python3-pip \
 libgl1-mesa-dev \
 libsm6 \
 git \
 wget \
 unzip \
 # OpenCV: Required build dependencies
 # https://docs.opencv.org/4.x/d2/de6/tutorial_py_setup_in_ubuntu.html
 cmake \
 python3-dev \
 python3-numpy \
 libavcodec-dev \
 libavformat-dev \
 libswscale-dev \
 libgtk2.0-dev \
 libgtk-3-dev \
 # OpenCV: Optional Dependencies
 libpng-dev \
 libjpeg-dev \
 libopenexr-dev \
 libtiff-dev \
 libwebp-dev \
 # OpenCV のビルド時に -D WITH_QT=ON を設定するために以下が必要だった
 qtbase5-dev \
 qtdeclarative5-dev \
 # gstreamer のインストール
 # https://gstreamer.freedesktop.org/documentation/installing/on-linux.html
 libgstreamer1.0-dev \
 libgstreamer-plugins-base1.0-dev \
 libgstreamer-plugins-bad1.0-dev \
 gstreamer1.0-plugins-base \
 gstreamer1.0-plugins-good \
 gstreamer1.0-plugins-bad \
 gstreamer1.0-plugins-ugly \
 gstreamer1.0-libav \
 gstreamer1.0-doc \
 gstreamer1.0-tools \
 gstreamer1.0-x \
 gstreamer1.0-alsa \
 gstreamer1.0-gl \
 gstreamer1.0-gtk3 \
 gstreamer1.0-qt5 \
 gstreamer1.0-pulseaudio && \
 # aptのクリア
 apt autoremove && apt clean && rm -rf /var/lib/apt/lists/*

# OpenCV のビルドとインストール
# https://docs.opencv.org/master/d2/de6/tutorial_py_setup_in_ubuntu.html
# https://toriten1024.hatenablog.com/entry/2018/09/29/012205
# https://dlrecord.hatenablog.com/entry/2017/12/15/145356
# https://atmarkit.itmedia.co.jp/ait/articles/1704/10/news134.html
RUN mkdir opencv && \
 cd /opencv && \
 # OpenCV のダウンロード
 wget https://github.com/opencv/opencv/archive/4.5.3.zip --no-check-certificate && \
 unzip 4.5.3.zip && \
 # OpenCV の cmake
 cd /opencv/opencv-4.5.3 && \
 mkdir build && \
 cd /opencv/opencv-4.5.3/build && \
 cmake -D CMAKE_BUILD_TYPE=RELEASE \
 -D BUILD_DOCS=OFF \
 -D BUILD_EXAMPLES=OFF \
 -D BUILD_TESTS=OFF \
 -D WITH_1394=OFF \
 -D WITH_GSTREAMER=ON \
 -D WITH_FFMPEG=ON \
 # cv2.waitKey() を使うためには WITH_QT=ON にする必要があった
 -D WITH_QT=ON \
 .. && \
 # OpenCV のビルド ※ $(nproc) はコア数を返す、make を並列処理させて高速化したい場合は指定する
 #make -j${nproc} && \
 #make -j2 && \
 make && \
 make install && \
 ldconfig && \
 # 後始末
 rm -rf /opencv


# Stage2: release
FROM ubuntu:20.04

# tzdataのタイムゾーン入力を求められないようにする
# https://tmyoda.hatenablog.com/entry/20210124/1611416396
ENV TZ=Asia/Tokyo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

RUN apt update && \
 # 必要なパッケージをインストール
 apt install -y --no-install-recommends \
 python3-pip \
 python3-numpy \
 # aptのクリア
 && \
 apt autoremove && apt clean && rm -rf /var/lib/apt/lists/*

# Copy binary and dependencies
COPY --from=build /usr/lib /usr/lib
COPY --from=build /usr/share /usr/share
COPY --from=build /usr/local/lib /usr/local/lib
RUN ldconfig

# 必要なプラグインをインストール
RUN pip3 install \
 aiohttp \
 rich \
 ruamel.yaml \
 pymongo==3.12.0 \
 influxdb \
 flask \
 flask-cors \
 pytest \
 pytest-mock \
 mongomock \
 websockets \
 --trusted-host pypi.org \
 --trusted-host files.pythonhosted.org

# bash起動
CMD [ "/bin/bash" ]

参考 URL

[Docker] コンテナ内からホストにアクセスする

Fri, 17 Jun 2022 00:00:00 +0900

コンテナ内では localhost はコンテナ自身を指すので使えません。
かといってホストの IP アドレスを直接参照すると、IP アドレスが変わったときに困ります。

このような場合、host.docker.internal を使います。

host.docker.internal はもともと Windows と Mac でしか使えなかったようですが、Docker 20.10 からLinux でも使えるようになったそうです。
この機能を有効化するには --add-host で host.docker.internal:host-gateway を指定する必要があるようです。

$ docker run -it --rm \
 --add-host=host.docker.internal:host-gateway \
 image_name

docker-compose の場合は extra_hosts で指定します。

services:
 app:
 extra_hosts:
 - "host.docker.internal:host-gateway"

参考 URL

[Docker] コンテナ内からホストにアクセスする

Thu, 16 Jun 2022 00:00:00 +0900

ググってもなかなかサンプルが見当たらずかなりはまりました。

最終的には以下のページが参考になりました。

https://qiita.com/shiitake256/items/a9cd1f525fd97c224f52

Docker + Traefik の基本的な設定は以前の記事をご覧ください。

https://kuttsun.blogspot.com/2022/06/docker-traefik.html

環境

Docker 20.10.12
Traefik v2.7

イメージ図

やりたいことは以下のような感じです。

<ホストのURL>/api1/ へのアクセスはポート3000へ
<ホストのURL>/api2/ へのアクセスはポート4000へ

サンプル

簡単な解説をコメントに書いています。

ports:
 - 3000:3000
 - 4000:4000
labels:
 - traefik.enable=true
 #------------------------------
 # foo という名前のルーターを定義し、エントリーポイント http と関連付け
 - traefik.http.routers.foo.entrypoints=http
 # リクエストパス /api1 とマッチするよう指定
 - traefik.http.routers.foo.rule=PathPrefix(`/api1{regex:$$|/.*}`)
 # foo-middleware という名前のミドルウェアを定義し、ルーター foo と関連付け
 - traefik.http.routers.foo.middlewares=foo-middleware
 # サービスにリクエストを行う前にリクエストパスの先頭の /api1 を取り除くように指定
 - traefik.http.middlewares.foo-middleware.stripprefix.prefixes=/api1
 # foo-service という名前のサービスを定義し、ルーター foo と関連付け
 - traefik.http.routers.foo.service=foo-service
 # foo-service へのアクセスをポート3000 へ飛ばす
 - traefik.http.services.foo-service.loadbalancer.server.port=3000
 #------------------------------
 - traefik.http.routers.bar.entrypoints=http
 - traefik.http.routers.bar.rule=PathPrefix(`/api2{regex:$$|/.*}`)
 - traefik.http.routers.bar.middlewares=bar-middleware
 - traefik.http.middlewares.bar-middleware.stripprefix.prefixes=/api2
 - traefik.http.routers.bar.service=bar-service
 - traefik.http.services.bar-service.loadbalancer.server.port=4000

ports でホストのポートとマッピングしていますが、実際には expose でコンテナ側のポートを開けるだけのほうがよいと思います。

参考 URL

Docker + Traefik で複数のポートを公開しているコンテナのルーティングを行う

Wed, 15 Jun 2022 00:00:00 +0900

ググってもなかなかサンプルが見当たらずかなりはまりました。

最終的には以下のページが参考になりました。

https://community.traefik.io/t/docker-container-with-multiple-ports/4657/2

Docker + Traefik の基本的な設定は以前の記事をご覧ください。

https://kuttsun.blogspot.com/2022/06/docker-traefik.html

環境

Docker 20.10.12
Traefik v2.7

イメージ図

やりたいことは以下のような感じです。

api1.localhost へのアクセスはポート3000へ
api2.localhost へのアクセスはポート4000へ

サンプル

簡単な解説をコメントに書いています。

ports:
 - 3000:3000
 - 4000:4000
labels:
 - traefik.enable=true
 #------------------------------
 # foo という名前のルーターを定義し、
 # エントリーポイント http (traefik側で設定した任意の名前) と関連付け
 - traefik.http.routers.foo.entrypoints=http
 # ルーター foo のホスト名を "api1.localhost" に設定
 - traefik.http.routers.foo.rule=Host(`api1.localhost`)
 # foo-service という名前のサービスを定義し、ルーター foo と関連付け
 - traefik.http.routers.foo.service=foo-service
 # foo-service へのアクセスをポート3000 へ飛ばす
 - traefik.http.services.foo-service.loadbalancer.server.port=3000
 #------------------------------
 - traefik.http.routers.bar.entrypoints=http
 - traefik.http.routers.bar.rule=Host(`api2.localhost`)
 - traefik.http.routers.bar.service=bar-service
 - traefik.http.services.bar-service.loadbalancer.server.port=4000

ports でホストのポートとマッピングしていますが、実際には expose でコンテナ側のポートを開けるだけのほうがよいと思います。

参考 URL

Docker + Traefik でリバースプロキシサーバーを立てる

Tue, 14 Jun 2022 00:00:00 +0900

最初 nginx でリバースプロキシサーバーを構築していたのですが、いろいろ調べていく中で Traefik というサーバーの存在を知りました。

https://doc.traefik.io/traefik/

公式ではエッジルーターという言い方がされていますが、要はリバースプロキシ＋ロードバランサーという感じらしいです。
nginx より後発で、Docker との親和性が高いとのことで試しに使ってみました。

環境

Docker: 20.10.12
Traefik: v2.7

Traefik 自身も Docker で動かします。

docker network の作成

アプリと Traefik で共通で使用するネットワークを作成しておきます。

$ docker network create sample-network

Traefik の設定

Traefik の設定は /etc/traefik/traefik.yml に記述する方法と、docker-compose.yml で指定する方法があるようです。
前者の例が多いですが、後者の方が docker-compose.yml 一つで設定が完結して良いと思うのは私だけでしょうか？

設定ファイルに記述する例

traefik.yml というファイルを作成して、以下のように記述します。

# Providers config
providers:
 # Docker との連携を有効にする
 docker:
 # false に指定することで Label 付けしていない docker コンテナを Traefik が無視するようになる
 exposedByDefault: false
 # 使用するネットワーク
 network: sample-network
entryPoints:
 # http という任意の名前のエントリーポイントを定義し、80番ポートをリッスンするよう指定
 http:
 address: ':80'
 https:
 address: ':443'
# API/Dashboard config
api:
 # WebUI にアクセスできるように設定
 insecure: true

Trafik を起動します。
ネットには docker-compose を使った例が多いですが、とりあえず docker run で動かしてみます。

$ docker run -it --rm \
 --name reverse-proxy \
 --network sample-network \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v $(pwd)/traefik.yml:/etc/traefik/traefik.yml \
 -p 80:80 \
 -p 8080:8080 \
 traefik:v2.7

とりあえずこれで、http://localhost:8080 にアクセスすると Traefik の WebUI が表示されるかと思います。

docker-compose.yml で設定する例

上記の設定を docker-compose.yml のみで行った場合の例です。

version: '3.9'
services:
 reverse-proxy:
 image: traefik:v2.7
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 # ファイルで設定する場合は以下
 #- type: bind
 # source: ./traefik.yml
 # target: /etc/traefik/traefik.yml
 ports:
 - 80:80
 - 8080:8080
 networks:
 - sample-network
 command:
 # traefik.yml の代わりに command で設定
 - --providers.docker.exposedByDefault=false
 - --providers.docker.network=sample-network
 - --entryPoints.http.address=:80
 - --entryPoints.https.address=:443
 - --api.insecure=true
networks:
 sample-network:
 external: true

アプリケーション側の設定

ルーティングの設定などは全てコンテナのラベルで設定します。他のサーバーだとサーバー側の設定を変更する必要がありますが、 Traefik+Docker だとコンテナの増減に対して対応しやすいなと思いました。

とりあえず docker run で動かしてみます。

docker run -it --rm \
 --network sample-network \
 -l "traefik.enable=true" \
 -l "traefik.http.routers.api.entrypoints=http" \
 -l "traefik.http.routers.api.rule=Host(\"api.localhost\")"
 sample_app

これで http://api.localhost/ に該当のアプリにアクセスすれば繋がると思います。
解説は次に書いてあります。

docker-compose での例

上記の設定は、docker-compose.yml で以下のように設定します。
コメントで簡単な解説をつけておきました。

labels:
 # Traefik の有効化(exposedByDefault:false に設定した場合に必要)
 - traefik.enable=true
 # api という名前のルーターを定義し、
 # エントリーポイント http (traefik.yml で定義した名前) と関連付け
 - traefik.http.routers.api.entrypoints=http
 # ルーター api のホスト名を "api.localhost" に設定
 - traefik.http.routers.api.rule=Host(`api.localhost`)

基本は以上です。
他の詳細な設定については追々記事を書こうかなと思っています。

参考 URL

Portainer を Docker Swarm で動かす

Fri, 27 May 2022 00:00:00 +0900

以前 Portainer を docker-compose で動かしました。

https://kuttsun.blogspot.com/2022/04/portainer-docker-compose.html

今回はこの Portainer を Docker Swarm が有効になっている環境で動かしてみます。
クラスタを構成している全ノードが Portainer で管理できるようになります。

環境

Docker 20.10.12
Portainer 2.13.1

Docker Swarm の有効化

以下のコマンドを実行します。

$ docker swarm init

ちょっと試すだけならばここまでで OK です。
必要なら worker ノードの追加なども行ってください。

Portainer の起動

公式ドキュメントが以下になります。

https://docs.portainer.io/v/ce-2.9/start/install/agent/swarm/linux

こちらに yml ファイルの置き場所が記載されているので、Community Edition のほうのファイルをダウンロードします。

$ curl -L https://downloads.portainer.io/ce2-13/portainer-agent-stack.yml -o portainer-agent-stack.yml

中身はこんな感じです。

version: '3.2'

services:
 agent:
 image: portainer/agent:2.13.1
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - /var/lib/docker/volumes:/var/lib/docker/volumes
 networks:
 - agent_network
 deploy:
 mode: global
 placement:
 constraints: [node.platform.os == linux]

 portainer:
 image: portainer/portainer-ce:2.13.1
 command: -H tcp://tasks.agent:9001 --tlsskipverify
 ports:
 - "9443:9443"
 - "9000:9000"
 - "8000:8000"
 volumes:
 - portainer_data:/data
 networks:
 - agent_network
 deploy:
 mode: replicated
 replicas: 1
 placement:
 constraints: [node.role == manager]

networks:
 agent_network:
 driver: overlay
 attachable: true

volumes:
 portainer_data:

これを docker stack deploy で起動します。

$ docker stack deploy -c portainer-agent-stack.yml portainer
Creating network portainer_agent_network
Creating service portainer_agent
Creating service portainer_portainer

以上で完了です。
あとは http://localhost:9000 にアクセスすれば OK です。

起動した portainer を停止・削除したい場合は以下のコマンドを実行します。

$ docker stack rm portainer

参考 URL

Docker コンテナ内から Docker コマンドを使う

Thu, 26 May 2022 00:00:00 +0900

Docker コンテナ内のアプリケーションから Docker コンテナの操作をしたかったので、やってみました。

環境

Docker 20.10.12

DinD と DooD

Docker コンテナ内から Docker を扱う方法としては以下の２つがあるようです。

DinD: Docker in Docker
- Docker コンテナの中で Docker デーモンを動かす
- コンテナの中にコンテナを作成したりできる
- 非推奨
DooD: Docker outside of Docker
- ホストの docker.sock をコンテナにマウントし、Docker デーモンを共有する
- ホスト上の Docker コンテナを操作できる
- 基本的にこちらを使う

ここらへん以下のページが分かりやすかったです。

https://qiita.com/YukiMiyatake/items/2e68aa69a5ca3921d55d

DinD は Docker の開発用途のためのものらしく、セキュリティリスクなどもあることから非推奨で、基本的には DooD のほうを使うべきだそうです。
今回の用途的にも DooD のほうなので、DooD を試してみました。

DooD サンプル

ググってみると以下のようなサンプルが多いです。

$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker

確かにこれでコンテナ内で docker コマンドが使えました。
この場合では docker という Docker 一式が入ったイメージを使っているので、/var/run/docker.sock をマウントするだけで使えています。

しかし、実際にはアプリケーションのランタイムイメージをベースとすることが多いと思います。
試しに Ubuntu のイメージを使うと、以下のようにエラーになります。

$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:20.04
# docker ps
bash: docker: command not found

Docker クライアントがインストールされていないからです。

この場合、コンテナ内で docker.io をインストールすれば docker コマンドが使えるようになります。
ついでに docker-compose もインストールしています。

$ sudo apt update
$ sudo apt install -y docker.io docker-compose

というわけで、DooD では

/var/run/docker.sock をマウント
ベースイメージに Docker クライアントがインストールされていなければインストール

で、コンテナ内から Docker コマンドが使えるようになります。

参考 URL

OpenAPI + Swagger + Redoc + GitLab Pages で API ドキュメントを管理する

Tue, 24 May 2022 00:00:00 +0900

APIドキュメントを簡単に作成・閲覧できるようにしたいと思い、OpenAPI で作成、Swagger および Redoc で表示、GitLab Pages で公開までを行いました。

概要

OpenAPI で yaml を作成
GitLab CI/CD により自動で Swagger および Redoc でビルドし、GitLab Pages に公開
ローカル環境用に Swagger および Redoc を Docker で動かす

ディレクトリ構造

今回試しに作成したファイル一式は以下となります。詳細は後述します。

$ tree -a
.
├── .gitlab-ci.yml
├── README.md
├── docker-compose.yml
├── openapi
│ └── openapi.yaml
└── public
 └── index.html

OpenAPI の yaml を作成

Open API Specification (OAS) は REST API の仕様を記述するフォーマットです。記述方法についてはググったらたくさん出てくるので割愛します。

例えば、以下のような yaml を作成します。

openapi: 3.0.0
info:
 version: 1.0.0
 title: OpenAPI Sample
paths:
 /users:
 get:
 summary: Get Users
 responses:
 '200':
 description: OK

ローカル環境の作成

ひとまず GitLab は置いておき、まずはローカル環境で Swagger および Redoc が動くようにしてみます。
３つのサービスを動かしたかったので、docker-compose 使いました。
作成した docker-compose.yml は以下です。

version: '3'
services:
 # エディター
 swagger-editor:
 image: swaggerapi/swagger-editor
 ports:
 - "8081:8080"
 # ビューワー（Swagger-UI 版）
 swagger-ui:
 image: swaggerapi/swagger-ui
 volumes:
 - ./openapi:/usr/share/nginx/html/openapi
 environment:
 API_URL: ./openapi/openapi.yaml # Swagger UIの画面を開いたときに初期値として表示するファイル
 ports:
 - '8082:8080'
 # ビューワー（Redoc 版）
 redoc:
 image: redocly/redoc
 volumes:
 - ./openapi:/usr/share/nginx/html/openapi
 environment:
 SPEC_URL: ./openapi/openapi.yaml # Redocの画面を開いたときに初期値として表示するファイル
 PORT: 8080 # nginx port(default:80)
 ports:
 - '8083:8080'

特に難しいところはないかと思います。
docker-compose up で動かしたあと、ブラウザでアクセスすればOKです。

http://localhost:8081 で Swagger Editor にアクセスして編集が行えます。
http://localhost:8082 で Swagger UI での表示を確認できます。
http://localhost:8083 で Redoc での表示を確認できます。

ただ、Swagger Editor は別にいらなかったかもしれません。
私の場合、結局 VSCode で yaml を編集し、ブラウザの表示を更新して確認、ってやってます。

閲覧に関しては Swagger より Redoc のほうが個人的に見やすいですね。

GitLab Pages で公開する

ローカルでの環境は以上で整ったので、次は GitLab に push したら自動ビルドを行って GitLab Pages に公開するように設定します。
GitLab Pages や GitLab CI/CD については割愛します。

Swagger + GitLab Pages については以下のページが参考になりました。

https://lab.astamuse.co.jp/entry/2019/11/13/114500

ただ、今回 swagger-ui-dist のバージョンを上げたので、sed コマンドで修正するファイルを index.html から swagger-initializer.js に変更する必要がありました。
これについては以下のページが参考になりました。

https://qiita.com/hidao/items/d13e7dda3da02d37dd45

Redoc + GitLab Pages については以下のページが参考になりました。

https://medium.com/hoursofoperation/auto-generate-swagger-docs-to-gitlab-pages-ca040230df3a

以上の２つを組み合わせ、最終的に作成した .gitlab-ci.yml は以下です。
Swagger と Redoc のそれぞれで閲覧できるようにディレクトリを分けてみました。
プロキシ環境下でなければプロキシ関係の設定は不要です。

image: node:18-alpine

variables:
 # プロキシサーバー
 PROXY: 'http://example:8080'
 # ドキュメントのあるディレクトリ
 DOCS_FOLDER: "swagger"
 # ドキュメントファイル
 SPEC_TO_DISPLAY: "openapi.yaml"
 # デプロイ先
 DEPLOY_SWAGGER: "public/swagger"
 DEPLOY_REDOC: "public/redoc"

cache:
 paths:
 - ./node_modules

pages:
 stage: deploy
 before_script:
 # プロキシ環境下での下準備
 - npm -g config set proxy $PROXY
 - npm -g config set https-proxy $PROXY
 - npm -g config set registry http://registry.npmjs.org/
 - npm config set strict-ssl false
 # Swagger UI
 - npm install swagger-ui-dist@4.11.1
 # Redoc
 - npm install -g redoc-cli@0.13.14
 script:
 - mkdir -p $DEPLOY_SWAGGER
 - mkdir -p $DEPLOY_REDOC
 # Swagger UI
 - cp -rp node_modules/swagger-ui-dist/* $DEPLOY_SWAGGER
 - cp -rp $DOCS_FOLDER/* $DEPLOY_SWAGGER
 - sed -i "s#https://petstore\.swagger\.io/v2/swagger\.json#$SPEC_TO_DISPLAY#g" $DEPLOY_SWAGGER/swagger-initializer.js
 # Redoc
 - redoc-cli build -o $DEPLOY_REDOC/index.html $DOCS_FOLDER/$SPEC_TO_DISPLAY
 artifacts:
 paths:
 - public
 only:
 - main

ちなみに、Swagger の yaml ファイルは GitLab 上で Swagger でプレビュー表示されるので、外部に公開する必要がなければこれで十分かもしれません。

https://blog.kyanny.me/entry/2020/08/06/012807

参考 URL

MkDocs + GitLab Pages でドキュメント管理

Mon, 23 May 2022 00:00:00 +0900

マークダウンで書いたドキュメントを簡単に管理・閲覧できるようにしたいと思い、MkDocs と GitLab Pages を使ってみました。

概要

Markdown で書いたドキュメントを MkDocs を使って静的サイトに変換します。
MkDocs のビルドは GitLab CI/CD を使って自動で行い、出力された静的サイトを GitLab Pages で公開します。
また、ローカル環境での確認用に、Docker を使って MkDocs が動作する環境を作成します。

GitLab-Runner の設定は済んでいる前提です。

ローカル環境の構築

ひとまず GitLab は置いておき、まずはローカル環境で MkDocs が動くようにしてみます。
作成した Dockerfile は以下です。

FROM python:3.9-slim

RUN pip install \
 mkdocs \
 mkdocs-material \
 pygments

CMD ["mkdocs", "serve", "-a", "0.0.0.0:8000"]

ビルドします。

$ docker build -t mkdocs .

ドキュメントの新規作成（初回のみ）

ドキュメントを何も作成していない状態でコンテナを起動するとエラーとなります。
まずはコンテナ起動時に mkdocs new doc を実行してドキュメントを新規作成しました。

docker run -it --rm \
 -u "$(id -u $USER):$(id -g $USER)" \
 -v $(pwd)/workspace:/workspace \
 --workdir="/workspace" \
 mkdocs mkdocs new doc

以下のようにファイルが作成されます。

$ tree workspace/
workspace/
└── doc
 ├── docs
 │   └── index.md
 └── mkdocs.yml

コンテナの起動

ドキュメント作成済みであれば、以下のようにしてコンテナを起動します。

docker run -it --rm \
 -u "$(id -u $USER):$(id -g $USER)" \
 -v $(pwd)/workspace:/workspace \
 -p 8000:8000 \
 --workdir="/workspace/doc" \
 mkdocs

ブラウザで http://localhost:8000 にアクセスすれば MkDocs のページが表示されます。

GitLab Pages で公開する

ローカルでの環境は以上で整ったので、次は GitLab に push したら MkDocs のビルドを行って GitLab Pages に公開するように設定します。
作成した .gitlab-ci.yml は以下です。

image: python:3.9-slim

before_script:
 - pip install --upgrade pip
 - pip install mkdocs
 - pip install mkdocs-material
 - pip install pygments

pages:
 stage: build
 script:
 - cd workspace/doc
 - mkdocs build
 - mv site ../../public
 artifacts:
 paths:
 - public
 only:
 - main

特に難しいところはないかと思います。
mkdocs build でビルドすると site に出力されるので、public にリネームして GitLab Pages に公開しています。

参考 URL

Jetson Xavier NX を触ってみた

Thu, 28 Apr 2022 00:00:00 +0900

Jetson Xavier NX を搭載したボックスコンピューターを触る機会があったのでメモです。

ボックスコンピューターは以下です。

https://www.aaeon.com/jp/p/nvidia-jetson-xavier-nx-ai-edge-poe-boxer-8253ai

CUDA や Docker は最初からインストールされていました。

ゴールとしては Docker コンテナ上で GPU を使って推論を行うことです。

先に結論を書いておくと、

CPU アーキテクチャが arm なので、arm に対応したベースイメージを使う必要がある
Jetson は GPU ドライバーの都合上、現時点で CUDA 11 以降に対応していない
- インストールされているバージョンは 10.2
つまり、arm で CUDA 10.2 のイメージを使う必要があるが、Docker Hub にはその組み合わせの公式イメージがない
NVIDIA GPU CLOUD (NGC) にある l4t-ml:r32.5.0-py3 のイメージを使えばいいとのこと
- これが Jetson Xavier NX にインストールされている JetPack と同等のイメージになる

Jetson, JetPack, L4T について調べてみた

ここらへんの関係がよくわからなかったので、少し調べてみました。

NVIDIA Jetson シリーズは JetPack という形で、OS、NVIDIA ドライバー、CUDA や cuDNN などのフレームワークも含めた形で提供されているらしいです。

インストールされている JetPack と OS のバージョンは以下の方法で確認できます。

https://senooken.jp/post/2020/12/04/

$ dpkg-query --show nvidia-l4t-core
nvidia-l4t-core 32.5.0-20210115151051

インストールされている OS は L4T 32.5 でしたが、これは JetPack 4.5 になるっぽいです。

https://developer.nvidia.com/embedded/jetpack-archive

尚、最新の JetPack 4.6 でも CUDA は 10.2 らしいですが、これは GPU ドライバーの都合上みたいです（後述）。

nvidia-smi がない？

GPU の状況を確認するためによく使う nvidia-smi が Jetson にはありませんでした。

https://senooken.jp/post/2020/11/19/

代わりに tegrastats で確認できました。

ストレージ容量が少ない

ストレージ容量が 16GB しかなく、空き容量もほとんどないので、このままでは Docker イメージが入りません。
なので、外部ストレージとして 2.5 インチの SSD を用意して、そちらに Docker イメージを保存するように設定変更しました。
これについては以下を参照してください。

CUDA バージョン

nvidia-container-cli が使えたので、何もしなくても Docker から GPU を使うことはできそうでした。
インストールされている CUDA のバージョンなどは以下でした。

$ nvidia-container-cli info
NVRM version: (null)
CUDA version: 10.2

Device Index: 0
Device Minor: 0
Model: Xavier
Brand: (null)
GPU UUID: (null)
Bus Location: (null)
Architecture: 7.2

結構古かったです。

んで、CUDA のバージョンを上げられないかなぁと思って調べてみると、以下のページが見つかりました。

どうやら Jetson は GPU ドライバーの都合上、現時点では CUDA 11 以降に対応していないとのこと。
なので、Dockerfile のイメージは CUDA 10.2 のものを使う必要がありそうです。

CPU が arm

CUDA 云々の前に、そもそも CPU アーキテクチャが arm なので、今まで他のマシンで使っていた Dockerfile のビルドを行うとすぐに失敗しました。
ベースとする Docker イメージを arm 系のものにする必要がありそうです。

Docker Hub に nvidia/cuda-arm64 というイメージがあるのでこれっぽいですが、現在ではもうサポートされておらず 11.1 でバージョンが止まっています。

https://hub.docker.com/r/nvidia/cuda-arm64

ドキュメントを追ってみると、現在では nvidia/cuda のイメージで複数のアーキテクチャをサポートできるっぽいので、上記はもうサポートされないとのこと。

https://gitlab.com/nvidia/container-images/cuda/-/blob/master/README.md

しかし、nvidia/cuda にある CUDA 10.2 のイメージの OS/ARCH には linux/arm64 が含まれていません。仕方ないので nvidia/cuda-arm64 内で探してみますが、今度は CUDA 10.2 のイメージがなく、11 以降のイメージしかありません。

つまり、Docker Hub にある NVIDIA の公式イメージには、arm アーキテクチャで CUDA が 10.2 のイメージがないということがわかりました。

NVIDIA GPU CLOUD (NGC) のイメージを使えばいいらしい

さてどうしたもんかと悩んでいたら、同じようなことを質問している人がいました。

https://forums.developer.nvidia.com/t/cuda-10-2-and-cublas10-deb-package-to-install-on-arm64-docker-container/177030

これに対する回答として、l4t-ml:r32.5.0-py3 を使ってみてとのこと。
このイメージは Docker Hub ではなく NVIDIA GPU CLOUD (NGC) からプルできるそうです。

https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-ml

見ての通り、これは JetPack 4.5 と同等の Docker イメージらしいです。
ちなみに、Docker Hub からのプルではないため、イメージ名は以下のように指定します。

$ docker pull nvcr.io/nvidia/l4t-ml:r32.5.0-py3

一応プルできるところまでは確認できました。

OpenCV のインストールに失敗する

nvcr.io/nvidia/l4t-ml:r32.5.0-py3 のイメージを使うことでようやく Dockerfile のビルドを開始できるところまで漕ぎ着けましたが、OpenCV のインストールに失敗しました。

調べてみると以下のページが見つかりました。

https://nisshingeppo.com/ai/jetson-opencv/

どうやら pip ではインストールできないようなので、ソースコードからビルドを行う必要がありそうですが、OpenCV に依存するライブラリも pip でインストールできなくなります。

尚、Ubuntu 20.04 のベースイメージだと OpenCV のインストールは pip でできました。

参考 URL

[Docker] Swarm を WebUI で管理できる Swarmpit を動かしてみる

Wed, 27 Apr 2022 00:00:00 +0900

Docker Swarm モードにおけるクラスタ構成を Web で確認できる Swarmpit というのを知ったので、動かしてみました。

環境

Ubuntu 20.04
Docker 20.7

動かし方

GitHub に Swarm 用の docker-compose.yml が公開されているので、クローンしてデプロイするだけで使えます。
なので、Swarm モードが有効になっていることが前提となります。

Swarm モードが有効になっていれば、以下のコマンドを実行するだけで OK です。

$ git clone https://github.com/swarmpit/swarmpit -b master
$ docker stack deploy -c swarmpit/docker-compose.yml swarmpit

特に何も変更することなく動きました。
起動するまで結構時間がかかりました。

参考 URL

https://github.com/swarmpit/swarmpit

[Docker] Image, Container, Node, Service, Stack などの概念

Tue, 26 Apr 2022 00:00:00 +0900

Docker について、特に Swarm モードを使い始めるとここらへんの概念がややこしくなってきたので、整理してみました。

ただ当ブログ全般に言えますが、私自身が正しく理解できているかどうかは自信がないので、あくまで参考ということで、内容の保証はいたしかねます。

概念図

以下のページの図がわかりやすかったです。

これを踏まえつつ、とりあえず簡単に理解するためには以下のような感じでよいのかなと思います。

Docker イメージ

イメージは、アプリケーションのコード、ランタイム、ライブラリ、環境変数、構成ファイルなど、アプリケーションの実行に必要なすべてのものを含んだ、実行可能パッケージです。
このイメージを動作させるためにインスタンス化したものがコンテナと言えます。

Docker コンテナ

コンテナは Docker における最小の動作単位です。
コンテナはイメージから作成されます。
上述のページでは、コンテナはイメージのランタイムインスタンスである、という言い方をしていますが、イメージを実際に動作可能にしたものがコンテナである、と言ってもいいかもしれません。

コンテナを動作させると、ホストからは一つのプロセスとして認識されます。
カーネルはホストと共有しています。

尚、イメージおよびコンテナはレイヤー構造となっており、各レイヤーはベースレイヤーとの差分情報を持っています。
ここらへん、以下のページがわかりやすかったです。

https://qiita.com/okmtz/items/f8231c83134a6363647b

また、コンテナ内で動かすアプリケーションは１つにするのが基本だそうです。
理由などは以下を見ていただくのが早いです。

https://matsuand.github.io/docs.docker.jp.onthefly/get-started/07_multi_container/

データボリューム

コンテナ内にデータを保存した場合、コンテナの破棄とともにそのデータも消えてしまいます。
そのため、データが消えてしまわないように永続化する際に使うのがデータボリュームです。

https://docs.docker.jp/engine/userguide/dockervolumes.html

データボリュームはコンテナ内の指定したパスにマウントして使います。

docker-compose

前述したとおり、Docker では１つのコンテナで１つのアプリケーションを動かすのが基本です。
しかし、実際のシステムでは複数のアプリケーションが連携して動作するものが多いと思います。
そういった複数のコンテナ（アプリケーション）が連携して動作するシステムについて、イメージのビルドや依存関係を考慮して各コンテナの起動・停止などを簡単に行えるようにできるツールが docker-compose です。

Swarm モード

Swarm モードは Docker 自体に含まれるオーケストレーション機能です。
複数の Docker ホストをまとめて、クラスタを構成することができます。

ノード

ノードは Swarm モードによるクラスタを構成する単位で、Docker ホスト１つにつきノードを１つ作成することになります。

例えば、２つの物理マシン上でそれぞれ Docker を使っている場合は、各マシンにノードを作成してクラスタを構成します。
ただし、VirtualBox や WSL などの仮想環境を使うと一つの物理マシン上で複数の Docker ホストが存在することもあるので、必ずしも「ノードの数＝マシンの数」となるわけではありません。

尚、ノードにはクラスタ全体を管理する manager ノードと、コンテナを実行する worker ノードがあります。

サービスとタスク

Swarm モードにおいて、ノードの作成の次はサービスの作成を行います。サービスを作成すると、タスク（コンテナ）が作成されて、各ノードに配置されます。タスクというのはコンテナを起動したりするやつで、よくわからなければ基本的にタスク≒コンテナと考えてよさそうです。

つまり、サービスを作成するとは、同じ機能を持ったタスク（コンテナ）を複数作成して（レプリカセット）、各ノードに配置するということになります。この各ノードに配置されたタスク（コンテナ）のレプリカセットがサービスです。

非 Swarm モードにおけるコンテナ作成（つまり普通にコンテナを作成する場合）が、Swarm モード有効時ではサービスを作成することに相当する、と考えればわかりやすいかもしれません。

従って、１つのコンテナでは基本的に１つのアプリケーションしか動いていないのと同様に、１つサービスでは基本的に１つの機能しか持っていません。
レプリカがあるためタスク（コンテナ）自体は複数ありますがが（冗長化）、機能としてはタスク（コンテナ）１つ分しかありません。
そのため、複数のサービスが連携して動作するシステムの場合、次のスタックを使うことになります。

スタック

サービスの集合体がスタックです。
非 Swarm モードで依存関係のあるコンテナを一度に起動・終了したりする場合、前述したように docker-compose を使ったりしますが、これが Swarm モードではスタックに相当します。非 Swarm モードにおけるコンテナと docker-compose の関係が、Swarm モードではサービスとスタックの関係になる、といえばわかりやすいかもしれません。

スタックでは基本的に docker-compose.yml がそのまま使えますが、一部使えない項目や、逆に必要となる項目などもあるので、こちらはまた別途記事を作成したいと思います。

オーバーレイネットワーク

Swarm モードでは、Docker ホスト間を相互接続するために、オーバーレイネットワークが作成されます。
デフォルトで Ingress という名前のオーバーレイネットワークが作成されます。

https://matsuand.github.io/docs.docker.jp.onthefly/network/overlay/

参考 URL

[Docker] Swarm モードのローリングアップデートを試してみた

Sun, 24 Apr 2022 00:00:00 +0900

Docker Swarm のチュートリアルの続きで、ローリングアップデートを試してみました。

前回の記事は以下。

https://kuttsun.blogspot.com/2022/04/docker-swarm_22.html

準備

redis:3.0.6 のイメージでサービスを開始します。

$ docker service create --replicas 3 --name redis --update-delay 10s redis:3.0.6
zzbrzxvmf40nt9jj8dw0upfqf
overall progress: 3 out of 3 tasks 
1/3: running [==================================================>] 
2/3: running [==================================================>] 
3/3: running [==================================================>] 
verify: Service converged

--replicas 3 を指定しているので、タスク（コンテナ）が３つ作成されます。

これを今から redis:3.0.7 のイメージを使うようにアップデートします。

--update-parallelism で同時に更新するタスクの数を指定できるようですが、今回は指定していないので、１つずつ更新されていきます。
また、--update-delay 10s を指定しているので、各タスクの更新は10秒の間隔を空けて行われます。

確認

アップデートの前に先に現状を確認します。

$ docker service inspect --pretty redis

ID:		zzbrzxvmf40nt9jj8dw0upfqf
Name:		redis
Service Mode:	Replicated
 Replicas:	3
Placement:
UpdateConfig:
 Parallelism:	1
 Delay:		10s
 On failure:	pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Update order: stop-first
RollbackConfig:
 Parallelism:	1
 On failure:	pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Rollback order: stop-first
ContainerSpec:
 Image:		redis:3.0.6@sha256:6a692a76c2081888b589e26e6ec835743119fe453d67ecf03df7de5b73d69842
 Init:		false
Resources:
Endpoint Mode:	vip

以下はチュートリアルにはありませんが、もう少しサービスの状況を確認しておきます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
zzbrzxvmf40n redis replicated 3/3 redis:3.0.6 
$ docker service ps redis
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
78sw528i15lh redis.1 redis:3.0.6 worker1 Running Running 2 minutes ago 
ryj86p3my9v4 redis.2 redis:3.0.6 manager1 Running Running about a minute ago 
cwoso93243ra redis.3 redis:3.0.6 worker1 Running Running 2 minutes ago

redis というサービスが２つのノード上で合計３つ動作しているのが確認できます。

アップデート

以下のコマンドで、redis:3.0.7 にアップデートを開始します。

$ docker service update --image redis:3.0.7 redis

別の端末で docker service ps を実行すれば、タスク（コンテナ）が順にアップデートされていくのが確認できます。

確認

アップデートが全て完了したら、以下のように各タスク（コンテナ）が redis:3.0.6 から redis:3.0.7 にアップデートされているのが確認できます。

$ docker service ps redis
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
9zedj7hcwbsk redis.1 redis:3.0.7 manager1 Running Running 12 seconds ago 
yy3ov31879rx \_ redis.1 redis:3.0.6 manager1 Shutdown Shutdown 13 seconds ago 
fize7rde390v redis.2 redis:3.0.7 worker1 Running Running 59 seconds ago 
tn49red4crkq \_ redis.2 redis:3.0.6 worker1 Shutdown Shutdown about a minute ago 
os380kdgnmfg redis.3 redis:3.0.7 manager1 Running Running 37 seconds ago 
3scdfazrhn6z \_ redis.3 redis:3.0.6 Pworker1 Shutdown Shutdown about a minute ago

アップデートに失敗した場合

アップデートに失敗した場合は処理が一時停止状態になるようです。
docker service inspect でアップデートの状況を確認できます。

$ docker service inspect --pretty redis

一時停止した更新を再開するには、 docker service update <サービス ID> を実行します。

$ docker service update redis

参考 URL

[Docker] Swarm モードに入門してみた

Fri, 22 Apr 2022 00:00:00 +0900

Docker をプロダクションで使っていくにあたり、コンテナの管理やアップデートをどうしようかと考えていました。
最初はこれを機に Kubernetes を使ってみようかと思ったのですが、学習コストが高いうえに、対象が小さなシステムなのでちょっと大仰すぎるなぁと思ってたところ、Docker 自体に Swarm モードというオーケストレーション機能が含まれていることを知ったので、そちらを試しに使ってみることにしました。

というわけで、以下のチュートリアルを少しやってみました。

http://docs.docker.jp/engine/swarm/swarm-tutorial/toc.html

手順としては上記をなぞるだけになるかもしれませんが、自分にとってわかりにくかったところや、他のサイトで調べたりしたことなどを補足しながら書いていこうと思います。
一応、Swarm のドキュメントは以下になります。

http://docs.docker.jp/engine/swarm/toc.html

ちなみに Kubernetes と Docker Swarm の比較は以下のページがとても参考になりました。

https://circleci.com/ja/blog/docker-swarm-vs-kubernetes/

環境

Ubuntu 20.04
- Docker 20.10.7
Ubuntu 20.04 on WSL2 on Windows10
- Docker 20.10.10

Docker はインストール済みの前提です。
Docker がインストールされていれば Swarm モードも使えます。

チュートリアルでは Docker ホストは３つありますが、用意できなかったので Ubuntu と WSL2 上の Ubuntu の２つでやりました。

概要

Docker Swarm モードは manager ノードと worker ノードから構成されます。
ノードというのは Docker のホスト（Docker エンジンが動作している環境）の単位になります。

manager ノードはクラスタを管理するノード
worker ノードはコンテナを稼働させるノード
manager ノードは worker ノードを兼ねることもできる

Swarm モードの有効化

Swarm モードを有効化するには docker swarm init を実行します。
このコマンドを実行すると manager ノードが作成されるので、manager ノードを作成したいマシン上で実行します。

$ docker swarm init
Swarm initialized: current node (z9voajpw84i4jk2fomqwsmnc7) is now a manager.

To add a worker to this swarm, run the following command:

 docker swarm join --token SWMTKN-1-23t6ldii7xxyyol2ulu0qddlqgwp3i1xpckiij2yjpintebbjq-bw598idhl229sykrhyiykviiw 192.168.1.10:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

出力結果には worker ノードを manager ノードに登録するためのコマンドが表示されます（後述）。

また、１つのマシンに複数のIPアドレスが割り当てられている場合、以下のように --advertise-addr オプションで他のノードとの通信に使用するIPアドレスを指定することもできます。

$ docker swarm init --advertise-addr 192.168.1.10

確認

Swarm モードが有効になっているかどうかは docker info で確認できます。

$ docker info

抜粋ですが、以下のような出力が確認できます。

Swarm: active
 NodeID: z9voajpw84i4jk2fomqwsmnc7
 Is Manager: true
 ClusterID: 61lmt9ptc8jyphn725cj96vxj
 Managers: 1
 Nodes: 1

ノードに関する情報は docker node ls で確認できます。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

worker ノードの作成

worker ノードの作成には docker swarm init を実行したときの出力結果に表示されたコマンドを使います。
manager ノードを作成したマシンとは別のマシンで以下のコマンドを実行します。

$ docker swarm join --token SWMTKN-1-23t6ldii7xxyyol2ulu0qddlqgwp3i1xpckiij2yjpintebbjq-bw598idhl229sykrhyiykviiw 192.168.1.10:2377
This node joined a swarm as a worker.

もし上記のコマンドが分からない場合は、docker swarm join-token worker で確認できます。

$ docker swarm join-token worker
To add a worker to this swarm, run the following command:

 docker swarm join --token SWMTKN-1-23t6ldii7xxyyol2ulu0qddlqgwp3i1xpckiij2yjpintebbjq-bw598idhl229sykrhyiykviiw 192.168.1.10:2377

尚、既に worker ノードを作成済みであったり、manager ノードを作成しているマシンで docker swarm join を実行した場合、以下のエラーが表示されます。

Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.

確認

先ほどと同じように docker node ls で確認できます。
尚、このような Swarm を管理するコマンドは manager ノードが動作しているマシンでのみ実行可能です。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
hqi4gtcdh4a7ya8myg0x0my37 worker1 Ready Active 20.10.12
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

サービスのデプロイ

ノードを作成したので、そこにサービスを追加していきます。
まずは manager ノードにサービスを追加します。
上述したように、manager ノードは worker ノードも兼ねることができるので、サービスを動かすこともできます。

manager ノードが動作しているマシンで docker service create を実行します。

$ docker service create --replicas 1 --name helloworld alpine ping docker.com
84aq1iszx44xq2f3cmohfl2tu
verall progress: 1 out of 1 tasks 
1/1: running [==================================================>] 
verify: Service converged

ここでは、alpine のベースイメージで helloworld という名前のコンテナを作成し、コンテナ内で ping docker.com というコマンドを実行しています。
--replicas 1 はコンテナの数です。

確認

docker service ls で実行中のサービスを確認できます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
84aq1iszx44x helloworld replicated 1/1 alpine:latest

サービスの詳細を調べる

別記事に書きました。

https://kuttsun.blogspot.com/2022/04/docker-swarm.html

サービスのスケール

Swarm で実行しているサービスをスケールするには、docker service scale <サービスID>=<タスク数> を実行します。
尚、サービス内で実行中のコンテナを「タスク」（task）と呼ぶそうです。

$ docker service scale helloworld=5
helloworld scaled to 5
overall progress: 5 out of 5 tasks 
1/5: running [==================================================>] 
2/5: running [==================================================>] 
3/5: running [==================================================>] 
4/5: running [==================================================>] 
5/5: running [==================================================>] 
verify: Service converged

確認

docker service ps <サービスID> で確認すると、インスタンスが合計５つになったのが分かります。
タスク（コンテナ）は Swarm のノード間で分散されています。

また、各ノードで docker ps を実行することでコンテナの情報が確認できます。

サービスの削除

$ docker service rm helloworld
helloworld

確認

docker service ls で helloworld サービスが削除されたのを確認できます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS

docker service inspect で調べようとしてもそんなサービスはないと言われます。

$ docker service inspect helloworld
[]
Status: Error: no such service: helloworld, Code: 1

docker ps でタスク（コンテナ）も削除されたことを確認できます。

ノードの削除

とりあえずここまでやってみました。
チュートリアルでは次はローリングアップデートとなっていますが、そこはまた今度にします。

尚、上記サービスは削除しましたが、ノードは残ったままです。
ノードの削除方法（Swarm モードの停止方法）を別記事に書きました。

https://kuttsun.blogspot.com/2022/04/docker-swarm_21.html

参考 URL

[Docker] Swarm モードの停止

Thu, 21 Apr 2022 00:00:00 +0900

Docker Swarm モードを停止するには、Worker ノードと Manager ノードを削除します。

Worker ノードの削除

ノードの切り離し

Worker ノードで docker swarm leave を実行すると、Worker ノードが Swarm から切り離されます。

$ docker swarm leave
Node left the swarm.

確認

Manager ノードで docker node ls を実行すると、Worker ノードの STATUS が Down になったのが確認できます。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
hqi4gtcdh4a7ya8myg0x0my37 worker1 Down Active 20.10.12
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

ノードの削除

次に Manager ノードで以下のコマンドを実行すれば、Manager ノードの管理上から Worker ノードが削除されます。

$ docker node rm <ノードID or ホスト名>

確認

docker node ls を実行すると、Worker ノードが削除されたのが確認できます。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

Manager ノードの削除

Manager ノードの削除でも docker swarm leave を実行しますが、そのまま実行すると以下のようなメッセージが出力されます。

$ docker swarm leave
Error response from daemon: You are attempting to leave the swarm on a node that is participating as a manager. Removing the last manager erases all current state of the swarm. Use `--force` to ignore this message.

Manager ノードを削除するとSwarm の現在の状態がすべて消去されるために警告が表示されていますが、--force を指定すれば削除できます。

$ docker swarm leave --force
Node left the swarm.

一応以下の公式ドキュメントを見ると、もう少し詳しく書いてあります。

https://matsuand.github.io/docs.docker.jp.onthefly/engine/reference/commandline/swarm_leave/

要約すると、Manager ノードが複数いる環境では、Manager ノードを Worker ノードに降格させてから削除するのが安全で、最後の Manager ノードの削除、つまり Manager ノード削除後にその Swarm をもう利用しない場合のみ --force をつけて削除しろ、という感じでしょうか。

Swarm が無効になったこを確認

docker info を実行すると、出力の中に Swarm: inactive となっているのが確認できるかと思います。

参考 URL

Portainer を docker-compose で動かす

Tue, 19 Apr 2022 00:00:00 +0900

Docker の GUI 管理ツールである Portainer を docker-compose で動かしてみました。

環境

Docker 20.10.7
portainer-ce 2.11

docker-compose.yml

Docker での動かし方は公式ドキュメントに記載されています。

https://docs.portainer.io/v/ce-2.11/start/install/server/docker/linux

これを docker-compose に落とし込んだのが以下です。

version: '3'
services:
 portainer:
 image: portainer/portainer-ce
 container_name: portainer
 restart: unless-stopped
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - portainer_data:/data
 ports:
 - 8000:8000
 - 9000:9000
 - 9443:9443
volumes:
 portainer_data:

通常 HTTPS で 9443 番ポートでアクセスしますが、HTTP でアクセスしたい場合は 9000 番ポートを使用します。
8000 番ポートは Edge コンピュート機能を使用する場合にのみ必要とありますが、使っていないので詳細はわかりません。それ以外には特筆すべき点はないかと思います。

これで http://localhost:9000 にアクセスすれば画面が表示されます。

Portainer Agent を追加する

以上で Portainer が使えるようになったのですが、Docker Volume の中が閲覧出来ませんでした。
これを有効化するには、Docker Swarm または Portainer Agent を追加する必要があるようです。

https://docs.portainer.io/user/docker/volumes/browse

Docker Swarm はまた別記事にするとして、ここでは Portainer Agent を追加します。
やり方については以下の記事が参考になりました。

https://stackoverflow.com/questions/64735377/install-portainer-portainer-agent-using-docker-compose

version: '3.2'
services:
 agent:
 image: portainer/agent
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - /var/lib/docker/volumes:/var/lib/docker/volumes
 portainer:
 image: portainer/portainer-ce
 command: -H tcp://agent:9001 --tlsskipverify
 ports:
 - "9000:9000"
 volumes:
 - portainer_data:/data
volumes:
 portainer_data:

これで Docker Volume の中を閲覧できるようになりました。

Docker Swarm での動かし方は別記事に書きました。

https://kuttsun.blogspot.com/2022/05/portainer-docker-swarm.html

参考 URL

[Docker] Swarm モードで動作中のサービスについて調べる

Fri, 15 Apr 2022 00:00:00 +0900

Docker Swarm モードで動作中のサービスについて調べる方法です。
尚、Swarm の管理に関するコマンドは、manager ノード上でのみ実行可能です。

サービスの一覧を調べる

docker service ls で取得できます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
sgwdtal1gqc7 helloworld replicated 1/1 alpine:latest

サービスの詳細を調べる

docker service inspect <サービスID or NAME> で調べられます。

しかし、このままだと出力が JSON 形式で見づらいので、--pretty を付けて見やすくしたほうが良いです。

$ docker service inspect helloworld --pretty

ID:		sgwdtal1gqc7j0ht0pgl6ehh6
Name:		helloworld
Service Mode:	Replicated
 Replicas:	1
Placement:
UpdateConfig:
 Parallelism:	1
 On failure:	pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Update order: stop-first
RollbackConfig:
 Parallelism:	1
 On failure:	pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Rollback order: stop-first
ContainerSpec:
 Image:		alpine:latest@sha256:4edbd2beb5f78b1014028f4fbb99f3237d9561100b6881aabbf5acce2c4f9454
 Args:		ping 192.168.4.1 
 Init:		false
Resources:
Endpoint Mode:	vip

サービスがどのノードで動作しているか調べる

docker service ps <サービスID or NAME> で調べられます。

$ docker service ps helloworld 
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
aeg3t0tj1emt helloworld.1 alpine:latest manager1 Running Running about a minute ago

例えば、１つのサービスが２つのノード上で５タスク動作している場合は以下のような出力になります。

$ docker service ps helloworld 
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
aeg3t0tj1emt helloworld.1 alpine:latest manager1 Running Running 13 minutes ago 
rmf7xhyljero helloworld.2 alpine:latest worker1 Running Running 10 minutes ago 
yfezzc46q7ua helloworld.3 alpine:latest worker1 Running Running 10 minutes ago 
c3kc1qowfj72 helloworld.4 alpine:latest worker1 Running Running 10 minutes ago 
wudt0zzznt1d helloworld.5 alpine:latest manager1 Running Running 9 minutes ago

helloworld というサービスが５つ動作しており、それが２つのノードに均等に割り振られているのが確認できます。

参考 URL

http://docs.docker.jp/engine/swarm/swarm-tutorial/inspect-service.html

Docker イメージの保存先を変更

Fri, 08 Apr 2022 00:00:00 +0900

ストレージの容量が少ない場合など、新たに SSD を接続し、そちらに Docker イメージを保存する方法です。

以下のページが参考になりました。

https://github.com/atinfinity/lab/wiki/change_docker_image_directory

環境

Ubuntu 18.04

手順

Docker サービスの停止

$ sudo service docker stop

既存データの退避

既存のデータは /var/lib/docker にあるので、これを外部ストレージに移動します。
SSD は /mnt/ssd にマウントしており、そこに docker というディレクトリを作成してデータを移動します。

$ sudo mkdir /mnt/ssd/docker
$ sudo rsync -aXS /var/lib/docker/. /mnt/ssd/docker/

設定変更

/etc/docker/daemon.json を開きます。

$ sudo nano /etc/docker/daemon.json

以下を記述して、保存先を /mnt/ssd/docker に設定します．

{
 "graph": "/mnt/ssd/docker"
}

設定の反映

$ sudo systemctl daemon-reload
$ sudo service docker start

動作確認

$ docker info | grep "Docker Root Dir"
Docker Root Dir: /mnt/ssd/docker

古いデータを削除

/var/lib/docker を削除します。

$ sudo rm -rf /var/lib/docker

`error creating overlay mount to` というエラーが表示される

Docker コンテナを作成しようとした際に、error creating overlay mount to みたいなエラーが表示されました。
私の場合はファイルシステムが NTFS だったことが原因でした。
EXT4 でフォーマットすれば正常にできました。

参考 URL

https://github.com/atinfinity/lab/wiki/change_docker_image_directory

GitLab の root の初期パスワードを調べる

Thu, 07 Apr 2022 00:00:00 +0900

久しぶりに新規に GitLab を構築したら仕様が変わっていて困ったのでメモ。

以前は初回アクセス時にパスワード変更の画面が表示されていたと思うのですが、GitLab 14.9 では表示されませんでした。

環境

Docker で GitLab を動かしています。

gitlab-ce:14.9.2-ce

root の初期パスワードの確認

root でログインするための初期パスワードは /etc/gitlab/initial_root_password に記載されているそうです。

今回 Docker で GitLab を動かしているので、以下のようにコンテナに入ってから確認します。

$ docker exec -it gitlab bash
# cat /etc/gitlab/initial_root_password

gitlab はコンテナ名です。

root の初期パスワードの変更

初期パスワードは24時間経ったら削除されるとあるので、ログインできたらパスワードを変更しておきます。

右上のユーザーメニューから「Edit Profile」を選択
サイドメニューより「Password」を選択

参考 URL

https://qiita.com/masa2223/items/78aaf76329637e6ca12d

nvidia-docker2 (nvidia-container-toolkit) のインストール

Thu, 31 Mar 2022 00:00:00 +0900

Docker コンテナ内で GPU を使うためには NVIDIA Container Toolkit をインストールする必要があります。

公式ドキュメントは以下です。

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

インストール方法

上記のページにインストール手順も書いてあります。
（以下は見やすくするためにコマンドを分割しています。）

$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
$ curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add -
$ curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
$ sudo apt update
$ sudo apt install -y nvidia-docker2

nvidia-docker2 がトップレベルのパッケージらしいので、インストールするときは nvidia-container-toolkit ではなく nvidia-docker2 を指定するようです。
ここらへん以下のページが参考になりました。

https://qiita.com/tkusumi/items/f275f0737fb5b261a868

まぁ公式ドキュメントが nvidia-docker2 をインストールするようになっていますし、それに従えばよいかと。

また、古い記事では nvidia-docker と書いてあったりしますが、ここらへんの変遷は以下が参考になりました。

https://qiita.com/ksasaki/items/b20a785e1a0f610efa08

動作確認

nvidia-container-cli で確認できます。

$ nvidia-container-cli --version
cli-version: 1.8.1
lib-version: 1.8.1
build date: 2022-02-14T12:02+00:00
build revision: abd4e14d8cb923e2a70b7dcfee55fbc16bffa353
build compiler: x86_64-linux-gnu-gcc-7 7.5.0
build platform: x86_64
build flags: -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -DNDEBUG -std=gnu11 -O2 -g -fdata-sections -ffunction-sections -fplan9-extensions -fstack-protector -fno-strict-aliasing -fvisibility=hidden -Wall -Wextra -Wcast-align -Wpointer-arith -Wmissing-prototypes -Wnonnull -Wwrite-strings -Wlogical-op -Wformat=2 -Wmissing-format-attribute -Winit-self -Wshadow -Wstrict-prototypes -Wunreachable-code -Wconversion -Wsign-conversion -Wno-unknown-warning-option -Wno-format-extra-args -Wno-gnu-alignof-expression -Wl,-zrelro -Wl,-znow -Wl,-zdefs -Wl,--gc-sections

$ nvidia-container-cli info
NVRM version: 470.103.01
CUDA version: 11.4

Device Index: 0
Device Minor: 0
Model: NVIDIA GeForce RTX 3080
Brand: GeForce
GPU UUID: GPU-565ac97c-fe71-f49b-1ac0-7ac93c7dab8d
Bus Location: 00000000:01:00.0
Architecture: 8.6

参考 URL

docker イメージのファイル保存、読み込み

Tue, 29 Mar 2022 00:00:00 +0900

ネットに繋がらない環境で docker コンテナを動かすために docker イメージをファイルから読み込むことがあったので、そのメモです。

イメージをファイルに保存

$ docker save イメージ名:タグ > filename.tar

ファイルをロードしてイメージを作成

$ docker load -i filename.tar

または

$ docker load < filename.tar

イメージ名とタグ名はもとのものと同じで読み込まれました。

参考 URL

https://uxmilk.jp/55512

[Python] `error in modulated_deformable_im2col_cuda: no kernel image is available for execution on the device` のエラーが表示される

Fri, 25 Mar 2022 00:00:00 +0900

pytorch で DCNv2 を使って推論を行っているアプリで、以下のエラーが表示されました。

error in modulated_deformable_im2col_cuda: no kernel image is available for execution on the device

Docker コンテナ内でアプリを動かしていたのですが、DCNv2 のビルドをやり直したら解消されました。
具体的には以下の make.sh を実行します。

https://github.com/jinfagang/DCNv2_latest

参考 URL

WSL2 の Ubuntu で Docker を動かす

Thu, 20 Jan 2022 00:00:00 +0900

DockerDesktop が有償になったので、WSL2 の Ubuntu に Docker をインストールして動かすようにしてみました、

環境

Windows 10
Ubuntu 20.04

WSL2 および Ubuntu はインストール済みの前提です。
以下のページに書いてあるので、まだの場合は参考にしてください。

https://kuttsun.blogspot.com/2022/01/wsl2.html

プロキシ設定

環境に応じてプロキシの設定を行っておきます。

.bashrc をエディタで開き、最後に以下を追記します。

export http_proxy=http://example.com:8080
export https_proxy=http://example.com:8080
export no_proxy=任意のIPアドレス

apt のプロキシ設定

/etc/apt/apt.conf を作成して以下のように記述します。

Acquire::http::proxy "http://example.com:8080/";
Acquire::https::proxy "https://example.com:8080/";

再起動します。

$ exit

Docker のインストール

公式ドキュメントに沿ってインストールします。

$ sudo apt-get remove docker docker-engine docker.io containerd runc
$ sudo apt-get update
$ sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose

ユーザーを docker グループに追加

$ sudo gpasswd -a $(whoami) docker

これで docker コマンド実行時に sudo が不要になります。

docker のプロキシ設定

/etc/default/docker をエディタで開いて以下を追加します。

export http_proxy=http://example.com:8080
export https_proxy=http://example.com:8080

また、~/.docker/config.json に以下を記述します。

{
 "proxies": {
 "default": {
 "httpProxy": "http://example.com:8080",
 "httpsProxy": "http://example.com:8080"
 }
 }
}

再起動します。

$ exit

docker デーモンの起動

$ sudo service docker start

動作確認

$ docker info
$ docker run hello-world

すると、私の場合以下のエラーが表示されました。

docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.

docker デーモンが起動しているか確認します。

$ sudo service docker status
* Docker is not running

原因がわからず悩んでいたところ、以下の記事を見つけました。

https://qiita.com/neight0903/items/ef0e2170b712b194c3fc

私の場合、既に DockerDesktop はアンインストールしていました。
もともとは DockerDesktop と WSL2 を使って動かしていたのですが、今回 DockerDesktop なしで動くようにしようとしているところで、 DockerDesktop だけでなく WSL2 も一度アンインストールして最初からやり直すと上手く行きました。

docker デーモンの自動起動

このままでは WSL を起動する度に docker デーモンを手動で起動する必要がありますが、以下のページに自動起動させる方法があります。

まずは sudo service docker start をパスワードなしで実行できるように設定します。

$ sudo visudo

以下を追記します。

ユーザー名 ALL=(ALL:ALL) NOPASSWD: /usr/sbin/service docker start

あとは .bashrc に以下を追記します。

$ nano .bashrc

if [ $(service docker status | awk '{print $4}') = "not" ]; then
 sudo service docker start > /dev/null
fi

Windows と WSL2 のポートフォワーディングの設定

WSL2 上の Docker コンテナに外部からアクセスしたい場合、Windows と WSL2 のポートフォワーディングの設定が必要です。
詳細は以下の記事を参照してください。

https://kuttsun.blogspot.com/2022/07/wsl2-docker.html

参考 URL

Docker コンテナの内容を変更して、既存のイメージに上書きする

Thu, 13 Jan 2022 00:00:00 +0900

docker commit を行う際に忘れがちなのでメモです。

$ docker commit コンテナ名 使用中のイメージ名:タグ

例

$ docker commit hoge piyo:latest

hoge というコンテナを piyo:latest というイメージで保存します。
そのイメージが既に存在する場合は上書きされます。

参考 URL

https://qiita.com/mats16/items/712575dc50513dfdf0a2

GPU を複数積んでいるマシンで、GPU を指定して Docker コンテナを動かす

Wed, 12 Jan 2022 00:00:00 +0900

タイトルの通りです。docker run での指定方法と、docker-compose での指定方法です。

docker run での指定方法

以下のページが参考になりました。

https://cocoinit23.com/docker-run-multi-gpu/

全ての GPU を指定する場合は --gpus all を指定します。

特定の GPU を指定する場合は --gpus '"device=0"' のように指定します。

docker-compose での指定方法

--gpus all に相当する書き方は以下です。

deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]

--gpus '"device=0"' に相当する書き方は以下です。

deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
 device_ids: ['0']

詳細は公式のドキュメントに書いてあります。

https://docs.docker.com/compose/gpu-support/

docker-compose のアップデート

私の環境では docker-compose のバージョンは 1.25.0 でしたが、docker-compose で GPU を使えるようにするためには 1.28.0 以上でなければならないようなので、そのような場合にはアップデートが必要です。
docker-compose のアップデート方法については以下を参考にしてください。

https://kuttsun.blogspot.com/2022/09/docker-compose.html

参考 URL

Telegraf で Docker の情報を取得して Grafana で可視化する

Mon, 27 Dec 2021 00:00:00 +0900

サーバーリソースの可視化は以前やったので、今度は Docker の情報を可視化してみました。

Grafana のダッシュボードは以下を使いました。

https://grafana.com/grafana/dashboards/10585

これに書いてあることをやっただけですが・・・。

telegraf.conf の設定

以下を追加します。

[[inputs.docker]]
 endpoint = "unix:///var/run/docker.sock"
 
 gather_services = false

 container_name_include = []
 container_name_exclude = []

 timeout = "5s"

 docker_label_include = []
 docker_label_exclude = []

 perdevice = true

 total = false

docker-compose.yaml の設定

Telegraf の volume に /var/run/docker.sock を追加します。
また、/var/run/docker.sock にアクセスするためには Telegraf の実行ユーザーを Docker と同じにする必要があります。

https://www.influxdata.com/blog/docker-run-telegraf-as-non-root/

volumes:
 - /var/run/docker.sock:/var/run/docker.sock
users: 1000:133 # UID:GID

さらに、情報を習得したい全サービスに以下を追加してグループ化します。

labels:
 - "docker.group=<some_name>"

ラベルの名前は何でもいいようです。
ラベルを設定しなかったサービスの情報は取得されませんでした。

Grafana の設定

以下から JSON ファイルをダウンロードし、Grafana でインポートします。

https://grafana.com/grafana/dashboards/10585

以上で以下のようなダッシュボードが表示されます。

参考 URL

[Python] Docker コンテナ内のアプリのログをホストの Syslog に追加する

Fri, 24 Dec 2021 00:00:00 +0900

docker コンテナ内で動作している python アプリのログをホストの syslog に追加します。

Ubuntu 20.04 で作業しましたが、rsyslog は最初からインストールされていました。

概要

Python 標準の logging モジュールに syslog 出力用のハンドラ SysLogHandler があるので、アプリ側ではそれを指定するだけで OK です。

Syslog はホストに対して UDP でログを送信して追加します。
理由は以下です。

docker コンテナ内でアプリを動かしているので、今後コンテナが増えたときコンテナごとに rsyslog を設定してやるのが面倒そう
各コンテナのログを一箇所に集約したい
syslog の記録には TCP or UDP のポート 514 が使用されるらしいが、SysLogHandler では UDP しか対応していないよう

rsyslog の設定変更

UDP のポート514 でログを待ち受けるように設定を変更します。

/etc/rsyslog.conf を編集します。

$ sudo gedit /etc/rsyslog.conf

以下の２行のコメントを外します。

module(load="imudp")
input(type="imudp" port="514")

変更後は再起動します。

$ sudo systemctl restart rsyslog

アプリ側の実装

ログに関する設定を logging.yaml に切り出しています。

https://kuttsun.blogspot.com/2021/12/python_21.html

その前提のうえで、以下のように指定するだけでログが UDP で送信されるようになります。

root:
 level: DEBUG
 handlers: [syslog]
handlers:
 syslog:
 class: logging.handlers.SysLogHandler
 formatter: syslog_format
 address: ['host.docker.internal', 514]
 #address: '/dev/log'
 level: INFO
formatters:
 syslog_format:
 format: 'appname: %(module)s %(message)s'

IPアドレスについては、docker コンテナからホストのIPアドレスを参照する必要があるので host.docker.internal を指定します。
（localhost はコンテナ自身を指すので使えない)
ちなみに host.docker.internal はもともと Windows と Mac でしか使えませんでしたが、最近 Linux でも使えるようになったそうです。

https://qiita.com/skobaken/items/03a8b9d0e443745862ac

これ使えなかったら直接IPアドレスを指定しないといけなくなり、ホストのIPアドレスが変わるたびに修正しないといけなくてマジ困ります。ってかこれを知るまでずっと困ってました。

参考 URL

docker デーモンが勝手に再起動する原因の調査と対策

Fri, 17 Dec 2021 00:00:00 +0900

docker コンテナをずっと動作させていたのですが、次の日の朝に止まっていたことがありました。
その原因の調査と対策方法についてのメモです。

環境

Ubuntu 20.04
Docker 20.10.7

原因の調査

まずは docker のログを調べてみます。 syslog から docker に関するログを表示します。

$ grep 'dockerd' /var/log/syslog

Dec 17 07:02:17 hostname dockerd[1880]: time="2021-12-17T07:02:17.017091451+09:00" level=info msg="Processing signal 'terminated'" 

中略

Dec 17 07:02:27 hostname dockerd[1880]: time="2021-12-17T07:02:27.985252607+09:00" level=info msg="Daemon shutdown complete" 
Dec 17 07:02:27 hostname systemd[1]: docker.service: Succeeded.
Dec 17 07:02:28 hostname dockerd[327103]: time="2021-12-17T07:02:28.012481765+09:00" level=info msg="Starting up" 

中略

Dec 17 07:02:28 hostname dockerd[327297]: time="2021-12-17T07:02:28.618499702+09:00" level=info msg="Daemon has completed initialization" 
Dec 17 07:02:28 hostname dockerd[327297]: time="2021-12-17T07:02:28.627472728+09:00" level=info msg="API listen on /run/docker.sock"

docker としては、終了指示を受けたから停止して、その後正しく再起動しているようです。

じゃあ何で（誰が）終了したのかということで、今度はログ全部を表示して docker 再起動の少し前をログを見てみました。

$ cat /var/log/syslog

怪しいログとして以下がありました。

Dec 17 07:02:06 hostname systemd[1]: Starting Daily apt download activities...

中略

Dec 17 07:02:17 hostname systemd[1]: Stopping Docker Application Container Engine...

日次処理が走った後に docker を再起動している？
また、ググってみたら以下のページが見つかりました。

https://stackoverflow.com/questions/65090971/docker-daemon-unexpectedly-exits

というわけで、ソフトウェアの自動アップデートが走った結果 docker が再起動したのが原因のようです。
実際、ソフトウェアのアップデートの設定を確認したら、たしかに自動アップデートするようになっていました。
自動アップデートを無効にしてもいいですが、とりあえずこれはこのままにしておきました。

docker コンテナの restart フラグ

今までも docker コンテナをサービス化するときには restart フラグを設定していました。
restart については以下に記述があります。

https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/start-containers-automatically/#use-a-restart-policy

今回はエラーで Docker デーモンが再起動したわけではないので、今回のような場合でも Docker コンテナを再起動させるためには unless-stopped ではなく always を指定しないといけないっぽいですね。

ちなみに、GUI アプリで restart を unless-stopped or always に指定してサービス化した場合、 ×ボタンなどでアプリを終了してもすぐ再起動して GUI が立ち上がるようになるので、そこは注意が必要です。
まぁ GUI アプリをサービス化なんてしませんね。

参考 URL

Docker のディスク使用量を調べる

Thu, 02 Dec 2021 00:00:00 +0900

Docker イメージ、コンテナ、ボリュームのサイズを調べる方法です。

以下のコマンドでわかります。

$ docker system df

出力結果

TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 35 4 26.48GB 24.36GB (92%)
Containers 4 4 125.5MB 0B (0%)
Local Volumes 3 3 320.1MB 0B (0%)
Build Cache 0 0 0B 0B

より詳細に（個別に）知りたい場合は -v をつけます。

$ docker system df -v

参考 URL

https://stackoverflow.com/questions/57430694/is-there-a-way-to-determine-the-size-of-a-docker-volume-on-my-macos-machine

OpenCV + GStreamer の Docker コンテナを作成

Tue, 16 Nov 2021 00:00:00 +0900

OpenCV では既定で ffmpeg が使われます。これを gstreamer を使うように設定変更したかったのですが、gstreamer を使うためには OpenCV を自分でビルドしてインストールする必要があるようです。
なので、OpenCV で gstreamer を使うための Dockerfile を作成しました。

環境

Ubuntu 20.04
Python 3.8.10
OpenCV 4.5.3

前置き

python で OpenCV を扱う場合、opencv-python をインストールすれば、OpenCV もインストールされるようです。
試しに以下のコードで OpenCV の情報を確認してみます。

import cv2
print(cv2.__version__)
print(cv2.getBuildInformation())

Video I/O の FFMPEG が YES になっており、GStreamer が NO になっています。

これを、ffmpeg を無効にして、gstreamer を有効にするため、自分で OpenCV のビルドを行います。

注意事項

せっかく自分で OpenCV をビルドしても、opencv-python をインストールすると、デフォルトの OpenCV が使われるようでした。
OpenCV のビルド時に python のパスを適切に設定していれば、opencv-python をインストールしなくても import cv2 が使えるはずなので、opencv-python はインストールしないようにします。

適当な Dockerfile を用意

今回は Ubuntu:20.04 のイメージを使いました。

インストール手順

GStreamer と OpenCV の公式のドキュメントが以下になります。

これを参考にインストールしていきます。

最終的に作成した Dockerfile

大体以下のような感じになりました。
途中参考になったページの URL などをソース内にメモしています。

FROM ubuntu:20.04

# tzdataのタイムゾーン入力を求められないようにする
# https://tmyoda.hatenablog.com/entry/20210124/1611416396
ENV TZ=Asia/Tokyo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

RUN apt update && \
 apt -y install \
 software-properties-common \
 # 必要なパッケージをインストール（必要に応じて取捨選択）
 python3-pip \
 libgl1-mesa-dev \
 libsm6 \
 git \
 wget \
 unzip \
 # OpenCV: Required build dependencies
 cmake \
 python3-dev \
 python3-numpy \
 libavcodec-dev \
 libavformat-dev \
 libswscale-dev \
 libgtk2.0-dev \
 libgtk-3-dev \
 # OpenCV: Optional Dependencies
 libpng-dev \
 libjpeg-dev \
 libopenexr-dev \
 libtiff-dev \
 libwebp-dev \
 # OpenCV のビルド時に -D WITH_QT=ON を設定するために以下が必要だった
 qtbase5-dev \
 qtdeclarative5-dev \
 # gstreamer のインストール
 # https://gstreamer.freedesktop.org/documentation/installing/on-linux.html
 libgstreamer1.0-dev \
 libgstreamer-plugins-base1.0-dev \
 libgstreamer-plugins-bad1.0-dev \
 gstreamer1.0-plugins-base \
 gstreamer1.0-plugins-good \
 gstreamer1.0-plugins-bad \
 gstreamer1.0-plugins-ugly \
 gstreamer1.0-libav \
 gstreamer1.0-doc \
 gstreamer1.0-tools \
 gstreamer1.0-x \
 gstreamer1.0-alsa \
 gstreamer1.0-gl \
 gstreamer1.0-gtk3 \
 gstreamer1.0-qt5 \
 gstreamer1.0-pulseaudio && \
 # aptのクリア
 apt clean && rm -rf /var/lib/apt/lists/*

# OpenCV のビルドとインストール
# https://docs.opencv.org/master/d2/de6/tutorial_py_setup_in_ubuntu.html
# https://toriten1024.hatenablog.com/entry/2018/09/29/012205
# https://dlrecord.hatenablog.com/entry/2017/12/15/145356
# https://atmarkit.itmedia.co.jp/ait/articles/1704/10/news134.html
RUN mkdir opencv && \
 cd /opencv && \
 # OpenCV のダウンロード
 wget https://github.com/opencv/opencv/archive/4.5.3.zip && \
 unzip 4.5.3.zip && \
 # OpenCV の cmake
 cd /opencv/opencv-4.5.3 && \
 mkdir build && \
 cd /opencv/opencv-4.5.3/build && \
 cmake -D CMAKE_BUILD_TYPE=RELEASE \
 -D BUILD_DOCS=OFF \
 -D BUILD_EXAMPLES=OFF \
 -D BUILD_TESTS=OFF \
 -D WITH_1394=OFF \
 -D WITH_GSTREAMER=ON \
 -D WITH_FFMPEG=OFF \
 # cv2.waitKey() を使うためには WITH_QT=ON にする必要があった
 -D WITH_QT=ON \
 .. && \
 # OpenCV のビルド ※ $(nproc) はコア数を返す、make を並列処理させて高速化したい場合は指定する
 #make -j${nproc} && \
 #make -j3 && \
 make && \
 make install && \
 # 後始末
 rm -rf /opencv

# 必要なプラグインをインストール（必要に応じて取捨選択）
RUN pip3 install \
 pyyaml \
 pymongo \
 flask \
 pytest \
 mongomock

# bash起動
CMD [ "/bin/bash" ]

Docker コンテナの起動

上記で作成した Dockerfile をビルドしたらコンテナを起動します。
カメラにアクセスできるよういろいろ指定していますが、ここらへんは環境に応じて変更してください。

xhost +local:docker

docker run -it --rm \
 --name containername \
 -e DISPLAY=${DISPLAY} \
 -v /tmp/.X11-unix/:/tmp/.X11-unix/ \
 -v /dev/bus/usb:/dev/bus/usb \
 --privileged --device /dev/dri:/dev/dri \
 --device-cgroup-rule='c 189:* rmw' \
 -v $(pwd)/workspace:/workspace \
 --workdir="/workspace" \
 imagename:latest

実際に OpenCV と GStreamer が使えるかどうかの動作確認に別の記事で書きました。

OpenCV + Gstreamer を使う

参考 URL

docker-compose でアプリの起動を遅らせる

Mon, 08 Nov 2021 00:00:00 +0900

docker-compose.yml の depends_on はあくまでコンテナの依存関係だけであり、アプリの起動や初期化までは待ってくれません。

現在の docker-compose には condition というのがあり、コンテナの状態をチェックして起動を制御することが可能なようです。

ただ、そのために healthcheck の方法を定義しないといけないなどちょっと面倒だったので、今回は sleep を入れて無理やり起動を遅らせる方法をとりました。

sleep の入れ方ですが、以下の２つの方法を思いつきました。

command で指定する例

docker-compose.yml の command で以下のように記述します。

command: bash -c "sleep 5 && python3 sample.py"

entrypoint で指定

docker-compose.yml の entrypoint で起動時に実行するスクリプトファイルを指定し、そのスクリプトファイルの中で sleep を実行します。

entrypoint: "/hoge/entrypoint.sh"

参考 URL

docker-compose で GPU を使う

Tue, 02 Nov 2021 00:00:00 +0900

docker run では --gpus all としていたのですが、docker-compose ではどう指定すればいいのかわからなかったので調べてみました。

基本的には以下に書かれている通りです。

https://docs.docker.com/compose/gpu-support/

docker-compose では例えば以下のように記述します。

deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
environment: 
 - NVIDIA_VISIBLE_DEVICES=all
 - NVIDIA_DRIVER_CAPABILITIES=all

参考 URL

docker-compose での環境変数の参照方法

Fri, 29 Oct 2021 00:00:00 +0900

docker コンテナ内でホストと同じユーザーIDを指定するために、ホストの環境変数を参照していました。

例えば、docker コンテナ内でホストと同じユーザーIDを指定するために以下のように記述していましたが、

docker run -it \
 -e LOCAL_UID=$(id -u $USER) \
 -e LOCAL_GID=$(id -g $USER) \
 hoge:0 bash

これを docker-compose.yml ではどう書けばいいのか？結果的には以下のように記述することで上手くいきました。

environment: 
 - LOCAL_UID=${id:-u ${USER}}
 - LOCAL_GID=${id:-g ${USER}}

参考 URL

https://qiita.com/reflet/items/a96752b4cd3838ea6932

Rocket.Chat で使用している MongoDB をアップグレードする

Wed, 20 Oct 2021 00:00:00 +0900

Rocket.Chat をアップグレードしたら、MongoDB をアップグレードするように警告が表示されるようになったので、MongoDB もアップグレードしました。

アップグレードについては、以下の記事が参考になりました。

https://linuxhandbook.com/mongodb-upgrade-rocket-chat/

環境

アップグレード前

Rocket.Chat 3.10.4
MongoDB 4.0.22

アップグレード後

Rocket.Chat 4.0.3
MongoDB 5.0.3

やったこと

Rocket.Chat を 4.0.3 にアップグレード

3.10.4 から 4.0.3 へのアップグレードはバージョンを変更するだけでいけました。

docker コンテナ停止
docker-compose.yml の Rocket.Chat のバージョンを 4.0.3 に変更
docker コンテナ起動

この時点で Rocket.Chat 4.0.3、MongoDB 4.0.22 の組み合わせとなりましたが、以下のメッセージが表示されるようになりました。

rocketchat_1 | +----------------------------------------------+
rocketchat_1 | | SERVER RUNNING |
rocketchat_1 | +----------------------------------------------+
rocketchat_1 | | |
rocketchat_1 | | Rocket.Chat Version: 4.0.3 |
rocketchat_1 | | NodeJS Version: 12.22.1 - x64 |
rocketchat_1 | | MongoDB Version: 4.0.27 |
rocketchat_1 | | MongoDB Engine: wiredTiger |
rocketchat_1 | | Platform: linux |
rocketchat_1 | | Process Port: 3000 |
rocketchat_1 | | Site URL: http://localhost:3000 |
rocketchat_1 | | ReplicaSet OpLog: Enabled |
rocketchat_1 | | Commit Hash: 6e49fc9466 |
rocketchat_1 | | Commit Branch: HEAD |
rocketchat_1 | | |
rocketchat_1 | +----------------------------------------------+
rocketchat_1 | +----------------------------------------------------------------------+
rocketchat_1 | | DEPRECATION |
rocketchat_1 | +----------------------------------------------------------------------+
rocketchat_1 | | |
rocketchat_1 | | YOUR CURRENT MONGODB VERSION (4.0.22) IS DEPRECATED. |
rocketchat_1 | | IT WILL NOT BE SUPPORTED ON ROCKET.CHAT VERSION 5.0.0 AND GREATER, |
rocketchat_1 | | PLEASE UPGRADE MONGODB TO VERSION 4.2 OR GREATER |
rocketchat_1 | | |
rocketchat_1 | +----------------------------------------------------------------------+

MongoDB version 4.0.22 is deprecated, please upgrade your installation.

MongoDB 4.0 は非推奨なので、4.2 以上へアップグレードするよう促されます。
なので、ついでに最新の 5.0 までアップグレードします。

MongoDB を 4.2 にアップグレード

4.0 から 4.2 へのアップグレードは docker-compose.yml を修正して再起動するだけでいけました。

docker コンテナ停止
docker-compose.yml の MongoDB のバージョンを 4.0 に変更
docker コンテナ起動

MongoDB を 4.4 にアップグレード

4.2 から 4.4 へのアップグレードは docker-compose.yml を修正して再起動するだけではだめでした。
先に以下のコマンドを実行する必要があります。

$ docker exec mongo bash -c 'mongo --eval "db.adminCommand( { setFeatureCompatibilityVersion: \"4.2\" } )"'`

流れとしては以下です。

上記のコマンドを実行
docker コンテナ停止
docker-compose.yml の MongoDB のバージョンを 4.4 に変更
docker コンテナ起動

MongoDB を 5.0 にアップグレード

先ほどと同じです。
上記のコマンドのバージョンを 4.4 に変更して実行します

$ docker exec mongo bash -c 'mongo --eval "db.adminCommand( { setFeatureCompatibilityVersion: \"4.4\" } )"'`

流れとしては以下です。

上記のコマンドを実行
docker コンテナ停止
docker-compose.yml の MongoDB のバージョンを 5.0 に変更
docker コンテナ起動

参考 URL

https://linuxhandbook.com/mongodb-upgrade-rocket-chat/

VSCode の Remote-Containers を起動したときに、マウントのパスに無効な文字が含まれているというエラーが表示された

Wed, 01 Sep 2021 00:00:00 +0900

ホストのディレクトリをコンテナにマウントしたかったのですが、以下のようなエラーが表示されました。

docker: Error response from daemon: create /home/user/workspace: "/home/user/workspace" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.

devcontainer.json の mounts の設定は以下です。

"mounts": [
	"source=${localWorkspaceFolder}/workspace,target=/workspace",
],

type を省略してしまっていたのですが、type のデフォルトは volume なので、ボリュームをマウントしようとしてエラーになっていたみたいです。
以下のように type=bind を指定したら上手くいきました。

"mounts": [
	"source=${localWorkspaceFolder}/workspace,target=/workspace,type=bind",
],

参考 URL

Tesseract が動作する docker イメージを作成する

Mon, 28 Jun 2021 00:00:00 +0900

Tesseract を使って OCR を行うための環境を、Docker を使って構築しました。開発言語は Python を想定しています。

環境

Ubuntu 20.04

Dockerfile の作成

Dockerfile のサンプルです。

USB カメラのキャプチャ画像に対して OCR を行いたかったので、OpenCV と GUI の表示に必要なパッケージもインストールしています。

FROM ubuntu:20.04

# Tesseract、訓練済みモジュール、その他必要なパッケージをインストール
RUN apt -y install \
 tesseract-ocr \
 tesseract-ocr-jpn \
 git \
 python3-pip \
 libgl1-mesa-dev \
 libsm6

# python パッケージをインストール
RUN pip3 install pyocr pytesseract opencv-python

# aptのクリア
RUN apt clean && rm -rf /var/lib/apt/lists/*

# bash起動
CMD [ "/bin/bash" ]

これをビルドします。

$ docker build -t tesseract-dev .

コンテナ起動

以下のようにして起動します。

docker run -it --rm \
 --name tesseract-dev \
 -e DISPLAY=${DISPLAY} \
 -v /tmp/.X11-unix/:/tmp/.X11-unix/ \
 --device /dev/video0:/dev/video0 \
 tesseract-dev

確認

Tesseract がインストールされていることを確認します。

$ tesseract 4.1.1
 leptonica-1.79.0
 libgif 5.1.4 : libjpeg 8d (libjpeg-turbo 2.0.3) : libpng 1.6.37 : libtiff 4.1.0 : zlib 1.2.11 : libwebp 0.6.1 : libopenjp2 2.3.1
 Found AVX2
 Found AVX
 Found FMA
 Found SSE
 Found libarchive 3.4.0 zlib/1.2.11 liblzma/5.2.4 bz2lib/1.0.8 liblz4/1.9.2 libzstd/1.4.4

ついでに Tesseract で OCR 出来ることを確認します。

$ tesseract test.jpg output -l jpn

参考 URL

OpenVINO が動作する Docker イメージを作る

Thu, 24 Jun 2021 00:00:00 +0900

Docker Hub に OpenVINO の公式イメージがあるので、それを使って画像解析を行うための開発環境をサクッと構築します。

https://hub.docker.com/u/openvino

いろいろなイメージがありますが、開発用なので、サンプルやデモアプリなども入っている openvino/ubuntu18_dev を使います。

また、開発言語は Python を想定しています。

環境

Ubuntu 20.04
Docker 20.10.2
Visual Studio Code 1.57.1
OpenVINO 2021.2

Dockerfile の作成

公式イメージをそのまま使ってもいいですが、開発用として git や pip などは欲しいので入れておきます。
また、依存パッケージのインストール、サンプルやデモアプリのビルドも済ませておきます。

FROM openvino/ubuntu18_dev:2021.2

USER root

# 依存パッケージのインストール
RUN cd /opt/intel/openvino/install_dependencies && ./install_openvino_dependencies.sh

# サンプル、デモアプリのビルド
RUN cd /opt/intel/openvino/inference_engine/samples/cpp && ./build_samples.sh
RUN cd /opt/intel/openvino/inference_engine/demos && ./build_demos.sh
# /opt/intel/openvino_2021/deployment_tools/demo にデモアプリがある

# 他に必要なものを適宜インストール
RUN apt -y install wget git python3-pip
RUN pip3 install onnxruntime flask
RUN git clone https://github.com/ultralytics/yolov5

# aptのクリア
RUN apt clean && rm -rf /var/lib/apt/lists/*

USER openvino

# bash起動
CMD [ "/bin/bash" ]

これを myopenvino としてビルドしました。

$ docker build -t myopenvino:2021.2 .

コンテナ起動

例えば、以下のように起動します。

docker run -it --rm \
 --name openvino
 -e DISPLAY=${DISPLAY} \
 -v /tmp/.X11-unix/:/tmp/.X11-unix/ \
 -v /dev/bus/usb:/dev/bus/usb \
 --privileged --device /dev/dri:/dev/dri \
 --device-cgroup-rule='c 189:* rmw' \
 myopenvino:2021.2

-e DISPLAY=${DISPLAY} と -v /tmp/.X11-unix/:/tmp/.X11-unix/ は推論結果を描画するために指定しています。
-v /dev/bus/usb:/dev/bus/usb は USB カメラなどを使えるように指定しています。
--privileged --device /dev/dri:/dev/dri --device-cgroup-rule='c 189:* rmw' は GPU や Movidius Myriad などで推論を行う場合にも対応できるように指定しています（全部必要なわけではないと思いますが・・・）。
詳細は以下を参考にしてください。

https://docs.openvinotoolkit.org/2021.2/openvino_docs_install_guides_installing_openvino_docker_linux.html#use_a_docker_image_for_gpu

VSCode + Remote-Containers で起動できるようにする

実際に開発するとなると VSCode でデバッグしたいことが多々あると思うので、Remote-Containers を使って起動できるようにします。

Dockerfile は上記と同じものを使うとして、devcontainer.json で上記のコンテナ起動時の引数と同じものを指定すれば OK です。

例えば、以下のような感じです。

{
	"runArgs": [
		"-e", "DISPLAY=${env:DISPLAY}",
		"--privileged",
		"--device", "/dev/dri:/dev/dri",
	],

	"mounts": [
		"source=/tmp/.X11-unix/,target=/tmp/.X11-unix/,type=bind",
	 	"source=/dev/bus/usb,target=/dev/bus/usb,type=bind",
	],
}

参考 URL

VSCode + Remote-Containers で python の開発環境を作成する

Fri, 18 Jun 2021 00:00:00 +0900

VSCode の Remote-Containers を使い、python 開発用の docker コンテナを作成し、そのコンテナ中で python のデバッグをできるようにします。

環境

Ubuntu 20.04
Visual Studio Code 1.56.2
Remote Development 0.21.0

これらはインストールされている前提です。

設定ファイルの作成

コマンドパレットを開いて(Shift + Ctrl + p)、Remote-Container: Add Development Container Configuration Files を実行します。

Python3 を選択し、続いて Python のバージョンを選択します。
その後、Node.js をインストールするかどうか表示されますが、今回は必要ないのでチェックを外しました。

OK を押すと、以下のファイルが作成されます。

.devcontainer
├── Dockerfile
└── devcontainer.json

コンテナ起動

画面左下のマークを押し、Reopen in Container を選択するとコンテナが起動します。

拡張機能のインストール

Remote-Containers を使う場合、VSCode の拡張機能もコンテナ用に別途インストールする必要があるみたいです。

devcontainer.json の extensions に記載しておけば、コンテナ作成時に自動的に拡張機能もインストールされるようです。
今回は設定ファイル作成時に Python を選択したので、最初から下記の２つが記載されていました。

 "extensions": [
 "ms-python.python",
 "ms-python.vscode-pylance"
 ],

従って、コンテナを起動した時点で python と pylance は最初から入っているはずなのですが、何故か私の環境ではインストールされていません。

仕方がないので、手動でインストールしました。

手動でのインストール

まず、DEV CONTAINER のところの雲のアイコンをクリックします。

ローカルにインストールされている拡張機能一覧が表示されるので、コンテナ内にインストールしたい拡張機能にチェックを入れます。

インストールが完了した後は一度 VSCode を再起動したほうがよいかと思います。

デバッグを開始する

あとはローカル環境で python のデバッグを行う場合と同じです。

https://kuttsun.blogspot.com/2020/01/vscode-python.html

参考 URL

Grafana のダッシュボードをログインなしで閲覧できるようにする

Fri, 11 Jun 2021 00:00:00 +0900

タイトルの通りです。

Grafana には一応 Snapshot という機能がありますが、日時の範囲が固定で、範囲を変えても範囲外のデータは閲覧できなかったりと、その名の通りあくまでスナップショットです。

なので、ログインしなくてもダッシュボードの閲覧だけは出来るように設定します。

環境

docker および docker-compose を使って構築しています。

Grafana v7.5.7

設定

設定方法は grafana.ini を編集するか、環境変数を設定するかのどちらかで行います。

今回は docker-compose.yml で環境変数を設定しました。

GF_AUTH_ANONYMOUS_ENABLED を true に設定すれば、ログインなしでもダッシュボードの閲覧ができるようになります。

以下、設定例です。

version: '3.1'
services:
 influxdb:
 container_name: influxdb
 image: influxdb:1.8.6
 ports:
 - "8086:8086"
 volumes:
 - influxdb:/var/lib/influxdb
 grafana:
 container_name: grafana
 image: grafana/grafana
 links:
 - influxdb
 ports:
 - "3000:3000"
 environment:
 - GF_AUTH_ANONYMOUS_ENABLED=true
 volumes:
 - grafana:/var/lib/grafana
volumes:
 influxdb:
 grafana:

尚、環境変数の一覧は Grafana の Server Admin > Settings で確認できます。

Docker on ポンコツ地方エンジニアの技術ブログ

docker コンテナ起動時に /tmp ディレクトリの中身を削除する

参考 URL

Stable Diffusion web UI を動かしてみた

環境

手順

SDXLモデルの設定

参考 URL

Jekyll + Docker で静的サイトを作成する

環境

新規作成

ビルド

サーバー起動

所感

参考 URL

asciidoctor-pdf で admonition のアイコンを別の画像に差し替える

参考 URL

redis コンテナでの redis-server の起動方法による違い

[Docker] Python の Windows コンテナを動かしてみた

Dockerfile のサンプル

コンテナ起動例

参考 URL

[Docker] Windows コンテナを動かす

環境

Windows の機能の有効化

インストール方法

バイナリのダウンロード

ProgramFiles への展開

サービスへの登録

サービスの開始

動作確認

環境変数へパスを通す

プロキシ設定

docker クライアントのプロキシ設定

エラーが発生した場合

アンインストール

アップデート

余談：他の Windows コンテナを動かしてみた

参考 URL

[Docker] docker-compose の --scale でコンテナを複製した際に、コンテナ側で何番目のコンテナなのかを判別したい

サンプル

参考 URL

YAML のアンカー/エイリアスと docker compose の profiles を使って docker-compose.yml を作成する

yaml のアンカーとエイリアス

マージ

アンカーの上書き

docker-compose.yml で使用する場合

docker compose の profile

上記を踏まえた実用的なサンプル

docker-compose.yml の確認

参考 URL

Telegraf で Jetson の GPU 情報を取得する

環境

Jetson Stats のインストール

Telegraf の設定

Python スクリプトの作成

Dockerfile の作成

docker-compose.yml の変更

環境変数の追加

telegraf.conf の設定

テスト

Grafana のダッシュボードを作成

参考 URL

[Docker] docker-compose の env_file 内でシェルスクリプトを実行する

参考 URL

Nginx で upstream の 名前解決を無効化（回避）する方法

参考 URL

Docker Volume をコピー（複製）する

参考 URL

TIG Stack を動かしてみる

予備知識

環境

各ツールの役割

Telegraf の設定

docker-compose.yml

Telegraf について

GPU の情報取得について

Docker の情報取得について

ホスト名の指定

InfluxDB について

Nginx で upstream の名前解決を無効化（回避）する方法