記事一覧 on ポンコツ地方エンジニアの技術ブログ

Cloudflare Pages に Web Analytics を導入する

Wed, 22 Jul 2026 00:00:00 +0900

Cloudflare Dashboard で、Workers & Pages を選択します。

対象の Pages プロジェクトを選択した後、Metrics タブを選択し、ページ下部にある Web Analytics → Enable をクリックします。

これで OK です。

Cloudflare Web Analytics を導入する

Tue, 21 Jul 2026 00:00:00 +0900

Cloudflare を経由していないサイトの場合の設定方法です。

Cloudflare Web Analytics にサイトを追加

Cloudflare Dashboard で、 Analytics > Web Analytics と進みます。

Add a site をクリックします。

ホスト名を入力し、Done をクリックします。

Cloudflare を経由していないサイトの場合、登録後に JavaScript snippet が表示されるのでコピーします。

このスニペットを、通常はの直前などに入れます。

VS Code での Git Worktree の使い方

Mon, 13 Jul 2026 00:00:00 +0900

環境

Ubuntu 22.04
Visual Studio Code 1.128.0

事前準備

VS Code の設定で、git.detectWorktrees を ON にします。

ワークツリーの作成だけなら OFF の状態でもできましたが、ワークツリーを切り替えたり削除したりするには ON にする必要がありました。

ワークツリーの作成

ソース管理タブのリポジトリ横のメニューから作成できます。

ブランチの作成と、フォルダの場所を入力します。
デフォルトでは以下のようなフォルダ構成になります。

リポジトリ名
リポジトリ名.worktrees
 └── ブランチ名

ワークツリーが作成されたのが確認できます。

ワークツリーを作業ツリーで開く

作成したワークツリー横のメニューから「現在のウィンドウで作業ツリーを開く」または「新しいウィンドウで作業ツリーを開く」を選択します。

あとはいつも通り変更してコミットなどを行います。

ワークツリーの削除

ソース管理タブのリポジトリにて、ワークツリー横のメニューから作成できます。
（右クリックからでもいけます）

該当のワークツリーを作業ツリーで開いている場合は削除できませんので、その場合はメインリポジトリに切り替えてから削除する必要があります。

Ubuntu で Orca を使う

Sun, 12 Jul 2026 00:00:00 +0900

環境

Ubuntu 24.04

ダウンロード

以下から Linux 用の AppImage をダウンロードします。

https://www.onorca.dev/

実行手順

実行権限を与えて実行するだけです。

chmod +x orca-linux.AppImage
./orca-linux.AppImage

エラーがでた場合

私の環境では以下のエラーが出ました。

libfuse2 がない

エラー内容は以下です。

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

libfuse2 が必要みたいなので、以下で追加しました。

sudo add-apt-repository universe
sudo apt update
sudo apt install libfuse2

chrome-sandbox の権限エラー

[40727:0718/110452.982911:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_orca-lhdNQH6/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (コアダンプ)

--no-sandbox をつければとりあえず起動できます。

./orca-linux.AppImage --no-sandbox

原因

Electron製のOrcaは、内部のChromiumプロセスを隔離するため、Linuxでは主に次のいずれかのsandbox方式を使います。

user namespace sandbox 一般ユーザー権限のままLinux namespaceを作成する方式
SUID sandbox chrome-sandbox をroot所有・権限4755で実行する方式

Ubuntu 22.04では1のuser namespace方式がそのまま利用できたため、AppImage内のchrome-sandboxがSUID設定されていなくても起動できました。

Ubuntu 24.04ではAppArmorによる以下の制限が既定で有効になっています。

kernel.apparmor_restrict_unprivileged_userns=1

これによりOrcaがuser namespace sandboxを作れずエラーになります。

制限をUbuntu 22.04相当に戻す方法もありますが、システム上の全アプリケーションに対して非特権user namespaceの制限を解除することになります。

とりあえずは Orca 側の対応待ちという感じです。

以上で無事起動しました。
使い方などは気が向いたらまた別途。

Codex のレート制限リセット権の有効期限の確認方法

Thu, 09 Jul 2026 00:00:00 +0900

Codex で付与されたレート制限リセット権は有効期限が30日間となっていますが、現状、有効期限がいつまでかを簡単に確認する術がないようです。
以下に Windows 環境で確認するためのスクリプトが記載されていたので、これを参考に Ubuntu 用のスクリプトを作成しました。

https://note.com/moz_ai_tech/n/n84feff773b79

スクリプトの作成

ファイル名は何でもよいですが、例えば check_codex_reset_credits.sh として、以下の内容を保存してください。

#!/usr/bin/env bash
set -euo pipefail

AUTH_FILE="${HOME}/.codex/auth.json"
API_URL="https://chatgpt.com/backend-api/wham/rate-limit-reset-credits"

if ! command -v jq >/dev/null 2>&1; then
 echo "ERROR: jq が見つかりません。先にインストールしてください。"
 echo " sudo apt update && sudo apt install -y jq"
 exit 1
fi

if ! command -v curl >/dev/null 2>&1; then
 echo "ERROR: curl が見つかりません。先にインストールしてください。"
 echo " sudo apt update && sudo apt install -y curl"
 exit 1
fi

if [ ! -f "$AUTH_FILE" ]; then
 echo "ERROR: 認証ファイルが見つかりません: $AUTH_FILE"
 echo "Codex にログイン済みか確認してください。"
 exit 1
fi

ACCESS_TOKEN="$(jq -r '.tokens.access_token // empty' "$AUTH_FILE")"
ACCOUNT_ID="$(jq -r '.tokens.account_id // empty' "$AUTH_FILE")"

if [ -z "$ACCESS_TOKEN" ]; then
 echo "ERROR: access_token が取得できませんでした。"
 echo "$AUTH_FILE の形式が想定と異なるか、Codex の認証状態が無効です。"
 exit 1
fi

TMP_RESPONSE="$(mktemp)"
trap 'rm -f "$TMP_RESPONSE"' EXIT

if [ -n "$ACCOUNT_ID" ]; then
 HTTP_CODE="$(
 curl -sS \
 -o "$TMP_RESPONSE" \
 -w "%{http_code}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "OpenAI-Beta: codex-1" \
 -H "originator: Codex Desktop" \
 -H "ChatGPT-Account-ID: ${ACCOUNT_ID}" \
 --max-time 30 \
 "$API_URL"
 )"
else
 HTTP_CODE="$(
 curl -sS \
 -o "$TMP_RESPONSE" \
 -w "%{http_code}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "OpenAI-Beta: codex-1" \
 -H "originator: Codex Desktop" \
 --max-time 30 \
 "$API_URL"
 )"
fi

if [ "$HTTP_CODE" != "200" ]; then
 echo "ERROR: API 呼び出しに失敗しました。HTTP status: $HTTP_CODE"
 echo "レスポンス:"
 cat "$TMP_RESPONSE"
 echo
 exit 1
fi

jq -r '
 def fmt_time:
 if . == null or . == "" then
 "不明"
 else
 # jq の fromdateiso8601 は小数秒つき ISO8601 で失敗することがあるため除去する
 sub("\\.[0-9]+Z$"; "Z")
 | fromdateiso8601
 | localtime
 | strftime("%Y-%m-%d %H:%M:%S %Z")
 end;

 "利用可能なリセット権: \(.available_count // 0) 個",
 "",
 "状態\t付与日時\t有効期限",
 (
 (.credits // [])
 | map([
 (.status // "不明"),
 (.granted_at | fmt_time),
 (.expires_at | fmt_time)
 ])
 | .[]
 | @tsv
 )
' "$TMP_RESPONSE" | column -t -s $'\t'

実行手順

sudo apt update
sudo apt install -y curl jq

chmod +x check_codex_reset_credits.sh
./check_codex_reset_credits.sh

注意

このスクリプトは、参照記事の PowerShell 版と同じく、~/.codex/auth.json から access_token と account_id を読み取り、https://chatgpt.com/backend-api/wham/rate-limit-reset-credits に GET します。

注意点として、この方法は公式に公開された安定 API ではなく、参照記事でも「内部APIを使った非公式な確認方法」と説明されています。
Codex 側の仕様変更で動かなくなる可能性があります。

Ollama で Gemma4 12B を動かして VS Code から使う

Fri, 12 Jun 2026 00:00:00 +0900

環境

Ubuntu 22.04
CPU: Intel Core i7-11700
GPU: RTX 4070 12GB

Ollama のインストール

以下のページにコマンドが記載されているので、実行します。

https://ollama.com/download/linux

$ curl -fsSL https://ollama.com/install.sh | sh

確認

$ ollama --version
ollama version is 0.30.7

Gemma4 12B のインストールと起動

以下のコマンドを実行するとモデルのダウンロードが始まり、完了後に起動します。

$ ollama run gemma4:12b

>>> が表示されて入力受付待ちになるので、何かメッセージを入力すると応答が返ってきます。
日本語でもいけました。
終了するには Ctrl + d を入力します。

尚、ダウンロードだけしたい場合は pull を使います。

$ ollama pull gemma4:12b

VS Code から使う

状態確認

Ollama はインストールすれば勝手にサービスとして登録されます。
以下のコマンドで Ollama is running と返ってくれば OK です。

$ curl http://localhost:11434
Ollama is running

ollama run を実行しておく必要もありません。

GitHub Copilot Chat から使う

📝 注記

先に結論として、GitHub Copilot Chat からは上手くいかなかったので、後述の Continue を使いました

以下に説明がありますが、ollama launch vscode を実行します。

https://docs.ollama.com/integrations/vscode

Ollama が VS Code を検出し、ローカルモデルとの連携設定を支援してくれます。
実行後、以下のような設定画面が表示されます。

$ ollama launch vscode
Select models for Visual Studio Code: Type to filter... 
 
 Recommended 
 minimax-m3:cloud 
 State-of-the-art coding & agent capabilities with multimodal reasoning and support for up to 1M context
 kimi-k2.6:cloud 
 State-of-the-art coding, long-horizon execution, and multimodal agent swarm capability 
 glm-5.1:cloud 
 Long-horizon agentic engineering with autonomous execution and sustained iteration 
 qwen3.5:cloud 
 Reasoning, coding, and agentic tool use with vision 
 nemotron-3-super:cloud 
 Reasoning, coding, and agentic tool use 
 gemma4:31b-cloud 
 Agentic workflows and multimodal reasoning 
 gemma4 
 Agentic workflows and multimodal reasoning, ~12GB, (not downloaded) 
 qwen3.6 
 Agentic software engineering model with multimodal capabilities, ~28GB, (not downloaded) 
 
 More 
 ▸ gemma4:12b 
 
 1 models selected - press tab to edit

すでにダウンロード済みの gemma4:12b を選択します。

VS Code を再起動すると、GitHub Copilot Chat のモデル選択で gemma:12b が選択できるようになっています。

レスポンスでエラー

試しに GitHub Copilot Chat から gemma4:12b にメッセージを送ると以下のエラーが返ってきました。

Sorry, your request failed. Please try again.

Client Request Id: 11cba335-5cfd-41d2-93ac-26d191e904f8

Reason: Response too long.: Error: Response too long. at _G._provideLanguageModelResponse (/usr/share/code/resources/app/extensions/copilot/dist/extension.js:1710:13790) at process.processTicksAndRejections (node:internal/process/task_queues:104:5) at async _G.provideLanguageModelResponse (/usr/share/code/resources/app/extensions/copilot/dist/extension.js:1710:14793)

GitHub Copilot Chat の Local Models 機能はまだ比較的新しく、上手くいかない等の報告も多数あるようです。

なので、GitHub Copilot Chat から使うのは諦めて、後述の continue を使いました。

Continue から使う

VS Code の拡張機能から Continue をインストールします。

インストールしたらサイドバーにアイコンが追加されるので、クリックします。
Select model から Add Chat model を選択します。

以下のように選択肢、Connect を押します。

Provider: Ollama
Model: Autodetect

すると、モデルで gemma4:12b が選択できるようになっています。

これで使えるようになります。

モデルのロード・アンロードについて

Ollama は、リクエストが来るとモデルをメモリにロードし、一定時間使われなければ自動でアンロードするそうです。
公式FAQでは、デフォルトではモデルはメモリ上に5分保持され、その後アンロードされると説明されています。

https://docs.ollama.com/faq?utm_source=chatgpt.com

VS Code で WSL 上の SSH の設定を使って Remote SSH で接続する

Wed, 03 Jun 2026 00:00:00 +0900

以下に Windows の bat ファイルを使って WSL の SSH クライアントを呼び出す方法が書いてあったので、やり方をまとめてみました。

https://github.com/microsoft/vscode-remote-release/issues/937#issuecomment-578416517

尚、上記のやり方だと Windows 側の設定が使えなくなります。私はそれで問題ありませんが、併用したいという場合の解決策は以下で提示されていました。

https://zenn.dev/kurusugawa/articles/vscode-remote-ssh-with-wsl

概要

VS Codeの「Remote - SSH」拡張機能はデフォルトでWindows側のOpenSSH（またはGit for WindowsのSSH）を使用するため、WSL（Linux）側に設定した ~/.ssh/config や鍵、ControlMasterなどの機能を利用することができません。

解決策は、「Windows側でダミーのバッチファイル（.bat）を作成し、その中からWSLの ssh コマンドを呼び出すようにVS Codeに設定する」という方法です。

設定手順

1. バッチファイル（`ssh.bat`）の作成

Windows　側の適当なフォルダ（例: C:\Users\ユーザー名\ssh.bat など）に ssh.bat という名前のファイルを作成し、以下の内容を記述します。

※バッチファイルを作成する際は、文字コード（エンコーディング）を 「ANSI」または「UTF-8」 で保存してください。（UTF-16だと正しく動作しない場合があります）

@echo off
C:\Windows\System32\wsl.exe bash -ic "ssh %*"

2. VS Code（Windows側）の `settings.json` の編集

次に、VS Codeが標準の SSH ではなく、今作成したバッチファイルを使用するように設定します。

Windows側でVS Codeを開きます。
Ctrl + , で設定を開き、画面右上の「設定(JSON)を開く」アイコンをクリックして settings.json を開きます。
以下の2つの設定項目を追加（または既存のものを修正）します。

{
 // 1で作成したバッチファイルの「絶対パス」を指定（バックスラッシュは2つ重ねる）
 "remote.SSH.path": "C:\\Users\\あなたのユーザー名\\bin\\ssh.bat",
 // ローカル（Windows）側での不要なサーバープロセスの立ち上げを抑制する
 "remote.SSH.useLocalServer": false
}

3. リモート接続を実行する

設定が完了したら、実際に接続を行います。

設定を確実に反映させるため、VS Codeを一度完全に閉じて再起動します。
左下の緑色のリモート接続アイコン（または F1 キーを押して Remote-SSH: Connect to Host…）をクリックします。
WSL（Linux）側の ~/.ssh/config に記載されているホスト名（例: oci-ubuntu）を選択します。
初回接続時のみ「接続先のOSプラットフォーム（Linux / Windows / macOS）」を聞かれるので、Linux を選択します。

OCI や AWS EC2 でセッション切断後も処理を止めないよう tmux を使う

Sat, 30 May 2026 00:00:00 +0900

OCI や AWS EC2 で作業していると、SSH セッションを閉じたタイミングで実行中のプログラムが止まってしまうことがあります。

この問題は、tmux の「セッションを切り離す（detach）」を使うだけでほぼ解決できます。
私は今回初めて tmux を使ったため、必要な操作に限定してメモしておきます。

先にまとめ

「SSH を閉じても処理を動かし続ける」目的なら、tmux は以下だけで運用できます。

SSH ログイン後に tmux セッションを作る
tmux 内でプログラムを起動する
Ctrl+b → d で切り離す
SSH を切断しても処理は継続する
再ログイン後に tmux へ再接続する

コマンドだけ見ると以下です。

# セッション作成
tmux new -s app

# （tmux 内で）プログラム実行
python main.py

# 切り離し: Ctrl+b, d

# いまあるセッション確認
tmux ls

# 再接続
tmux attach -t app

tmux のインストール

Ubuntu 系なら以下で入ります。

sudo apt update
sudo apt install -y tmux

確認（バージョン表示）

tmux -V

まずは 1 回動かしてみる

1. セッションを作る

tmux new -s app

app はセッション名です。
あとで再接続するときに使うので、用途が分かる名前を付けると楽です。

📝 注記

tmux だけ打った場合、もし tmux サーバーがまだ動いていなければ、新しいセッションを作って接続します（デフォルト名で作成）。
すでに tmux が動いていて接続済みでない場合は、最近使われたセッションにアタッチします（新しいセッションは作成されません）。上記のコマンドは明示的に新規の名前付きセッションを作るコマンドになります。

2. プログラムを起動する

tmux の画面の中で、普段どおりコマンドを実行します。

python main.py

たとえば API サーバーなら、以下のように常駐するコマンドでも同じです。

uvicorn app:app --host 0.0.0.0 --port 8000

3. セッションを切り離す（detach）

以下の順でキーを押します。

Ctrl+b
d

これで tmux の外に戻ります。
プログラムは tmux セッション内でそのまま動き続けますので、SSH 自体を切断して問題ありません。
再ログイン後に tmux へ戻れます。

4. 再接続する（attach）

tmux ls でセッション一覧を見て、名前を確認します。

tmux ls

以下のコマンドで再接続します。

tmux attach -t app

セッションを終了して抜ける（プロセスを停止してセッションを閉じる）

tmux をデタッチせずにそのままセッションを終了して抜けたい場合は、主に次の方法があります。

セッション内から終了する（推奨 — プロセスを安全に停止）

tmux attach -t <セッション名> でセッションに戻る
実行中のプロセスを Ctrl+C などで停止する
シェルで exit または Ctrl+D を押すとウィンドウが閉じ、最後のウィンドウが閉じるとセッションは終了します

外からセッションを強制的に終了する（注意: プロセスが強制終了される）

tmux kill-session -t <セッション名>
全てのセッションを終了する場合は tmux kill-server

注意: セッションを閉じると、そのセッション内で動いていたプロセスは終了します。処理を継続させたい場合はデタッチしてください。

今回の用途で最低限覚えるコマンド

用途	コマンド
新規セッション作成	`tmux new -s app`
セッション一覧	`tmux ls`
セッション再接続	`tmux attach -t app`
セッション削除（停止）	`tmux kill-session -t app`

💡 ヒント

セッション内で動いているプロセスを止めたいときは、まず tmux に再接続して Ctrl+c で停止するのが安全です。

キー操作の最小セット

tmux は Ctrl+b を押したあとに次のキーを押す操作が基本です（prefix キー）。

コマンド	内容
`Ctrl+b` → `d`	セッション切り離し
`Ctrl+b` → `c`	新しいウィンドウ作成
`Ctrl+b` → `n`	次のウィンドウへ移動
`Ctrl+b` → `p`	前のウィンドウへ移動
`Ctrl+b` → `,`	ウィンドウ名を変更

最初は Ctrl+b → d だけ覚えれば十分です。

よくあるハマりどころ

SSH を切ったら止まった

tmux の中で起動せず、通常シェルで起動している可能性があります。
tmux attach -t app で戻って、そこで起動し直してください。

`tmux attach` で「no sessions」になる

セッションが存在しない状態です。新しく作成します。

tmux new -s app

セッション名を忘れる

tmux ls

一覧を出して、その名前で attach すれば戻れます。

OCI の Ubuntu インスタンスの初期設定

Fri, 29 May 2026 00:00:00 +0900

swap の設定

以下のように、Ubuntu のイメージにはスワップがありません。

$ free -m
 total used free shared buff/cache available
Mem: 954 343 225 4 538 610
Swap: 0 0 0

2GB のスワップファイル（Swap）を追加します。
すべてのコマンドは、管理者権限（sudo）を付けてターミナルで実行します。

1. スワップファイルの作成

dd または fallocate コマンドで 2GB のファイルを作成します。ここでは確実かつ高速な fallocate を使用します。

sudo fallocate -l 2G /swapfile

⚠️ 警告

もし「fallocate failed: Operation not supported」のようなエラーが出た場合は、以下の dd コマンドを代わりに試してください。
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

2. 適切な権限の設定

セキュリティのため、スワップファイルは root ユーザーのみが読み書きできるように権限を 600 に制限します。

sudo chmod 600 /swapfile

3. スワップ領域の初期化

作成したファイルをスワップ領域としてフォーマットします。

sudo mkswap /swapfile

4. スワップの有効化

システムにスワップファイルを認識させ、有効化します。

sudo swapon /swapfile

5. 設定の確認

スワップが正しく有効化されたか確認します。2GB（約 2.0GiB）のスワップが表示されていれば成功です。

sudo swapon --show
# または
free -h

6. 再起動後も自動で有効化する設定

上記の設定だけでは、インスタンスを再起動するとスワップが解除されてしまいます。再起動後も自動的に有効化されるよう、/etc/fstab に追記します。

6-1. fstab のバックアップ（推奨）

念のため、設定ファイルをバックアップしておきます。

sudo cp /etc/fstab /etc/fstab.bak

6-2. 設定の追記

以下のコマンドを実行して、/etc/fstab の末尾に設定を追記します。

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

【おまけ】カーネルパラメータの最適化（推奨）

Linux には、メモリがどれくらい減ったらスワップを開始するかを決める swappiness という値があります。
初期値は 60 であることが多いですが、クラウド環境（特に SSD ストレージ）では **10〜20** 程度に下げて、できるだけ物理メモリを優先して使うように設定するのが一般的です。

1. 現在の swappiness を確認

cat /proc/sys/vm/swappiness

2. 一時的に `10` に変更

sudo sysctl vm.swappiness=10

3. 永続的に反映

再起動後もこの設定を維持するため、/etc/sysctl.conf の末尾に追記します。

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

これで 2GB のスワップ設定はすべて完了です！

タイムゾーンの変更

# 現在のタイムゾーンを確認
timedatectl
# JST に変更
sudo timedatectl set-timezone Asia/Tokyo
# 変更されたことを確認
timedatectl

nano のインストール

sudo apt update
sudo apt install -y nano

git のインストール

sudo apt update
sudo apt install -y git

glab のインストールと認証

諸事情で GitHub ではなく GitLab を使っているので、glab をインストールします。

1. ダウンロード

apt でインストールできるバージョンは古いので、公式リリースからダウンロードしてインストールします。

詳細は以下を参照してください。

https://blog.ponkotools.com/posts/2026/05/10/glab/

2. GitLab でのアクセストークン（PAT）の発行

CLI から GitLab にアクセスするために、事前にブラウザ側（GitLab のウェブ画面）で Personal Access Token（個人用アクセストークン）を発行しておく必要があります。
WSL を使っているからか、web での認証ではうまくいきませんでした。

GitLab にログインします（SaaS 版の gitlab.com または社内などのオンプレミス版）。
面左上の自分のアイコン＞ Preferences（設定）＞左メニューの Access Tokens の順に開きます。
Add new token をクリックし、以下のように入力します：
Token name: 任意の名前（例: oci-ubuntu-cli）
Expiration date: 空欄（無期限）または任意の有効期限
Scopes（権限）: CLI をフル活用するために、api と write_repository以下にチェックを入れます。

Create personal access token をクリックします。

画面に一度だけトークン（glpat-xxxx…）が表示されるので、必ずコピーして手元に控えておきます。（画面を閉じると二度と見られなくなります）

3. CLI の認証設定（ログイン）

OCI の Ubuntu ターミナルに戻り、以下のコマンドを実行して対話型セットアップを開始します。

glab auth login

実行すると、いくつか質問されるので以下のように回答していきます。

┃ What GitLab instance do you want to sign in to?
┃ > gitlab.com
┃ GitLab Self-Managed or GitLab Dedicated instance

gitLab.com（本家）を使っている場合は、そのまま gitLab.com を選択して Enter。
自社サーバーなどの場合は GitLab Self-Managed or GitLab Dedicated instance を選択し、その後 URL（例: https://gitlab.example.com）を入力します。

- Signing into gitlab.com
┃ How would you like to sign in?
┃ > Token
┃ Web

Token を選択します。

- Signing into gitlab.com
┃ What domains does this host use for the container registry and image dependency proxy?
┃ > gitlab.com,gitlab.com:443,registry.gitlab.com

そのまま Enter を押します。

The minimum required scopes are 'api' and 'write_repository'.
Generate a personal access token at https://gitlab.com/-/user_settings/personal_access_tokens?scopes=api,write_repository
┃ Paste your authentication token:
┃ >

先ほど GitLab 画面でコピーしたトークン（glpat-xxxx…）を貼り付けて Enter を押します。

┃ Choose default Git protocol:
┃ SSH
┃ > HTTPS
┃ HTTP

HTTPS を選択します。

セットアップが完了したら、以下のコマンドで無事にログインできているか確認します。

glab auth status

ご自身のユーザー名や「Logged in to gitlab.com」といったステータスが表示されれば、GitLab CLI の設定はすべて完了です！

tmux のインストール

セッションが切れても実行中のプログラムが停止しないよう tmux を使うためにインストールします。

sudo apt update
sudo apt install -y tmux

docker のインストール

1. インストール

公式ドキュメントの Install using the apt repository に従って最新版の docker をインストールします。

https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

2. docker の権限を設定 (sudo を不要にする)

sudo gpasswd -a $(whoami) docker
sudo chgrp docker /var/run/docker.sock

不要なサービスの停止

参考: https://qiita.com/ynott/items/4312cb34611d2e462779

systemctl | grep running で稼働中のサービス一覧を出力し、そのうち不要なものを AI に尋ねた結果が以下です。

確実に停止・無効化して良いサービス

サービス名	役割と停止して良い理由
`ModemManager.service`	3G/4G/5G などのモバイルモデムを管理するサービス。クラウドのサーバーでモデムを使うことはないため、完全に不要です。
`fwupd.service`	マザーボードやデバイスのファームウェアをアップデートするデーモン。仮想マシン（VM）のファームウェアは OCI 側が管理するため不要です。
`rpcbind.servicerpcbind.socket`	NFSv3（ネットワークファイルシステム）などで使われる古いポートマップサービス。NFS でストレージをマウントする予定がなければ不要です。
`iscsid.serviceiscsid.socket`	iSCSI ストレージに接続するためのクアドラント。OCI のブロック・ボリュームを iSCSI 経由で直接マウント（手動アタッチなど）していない限り、標準の準仮想化（Paravirtualized）アタッチであれば不要です。
`udisks2.service`	主にデスクトップ環境で USB メモリなどのディスクを自動認識・マウントするためのサービス。サーバー用途では不要です。

停止・無効化のコマンド例
単に stop するだけだと再起動時にまた動いてしまうので、disable –now で自動起動の解除と停止を同時に行います。

sudo systemctl disable --now ModemManager fwupd rpcbind rpcbind.socket iscsid iscsid.socket udisks2

条件付きで停止・削除できるサービス（効果大）

環境によっては不要、あるいは別の手段に切り替えることで大幅に軽量化できる重要ポイントです。

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）

Ubuntu のパッケージ管理システム「Snap」と、OCI の管理エージェントです。

判断基準
OCI のダッシュボードからインスタンスのメトリック（CPU使用率のグラフなど）を見たり、OS の診断機能を使ったりしない、かつ自分で snap コマンドを使ったアプリ（Nextcloud などの Snap版）を動かす予定がない場合。

解説
oracle-cloud-agent は便利ですが、メモリが 1GB 以下の環境ではかなりの重荷になります。これらを Snap ごと削除すると、数十MB〜100MB 以上のメモリが浮きます。

完全に削除する場合のコマンド

sudo snap remove oracle-cloud-agent
sudo apt purge snapd -y

メモリ使用量の変化

上記のサービスをすべて停止した場合の比較です。

サービス停止前

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 360Mi 72Mi 4.9Mi 677Mi 594Mi
Swap: 2.0Gi 21Mi 2.0Gi

サービス停止後

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 299Mi 313Mi 4.9Mi 483Mi 655Mi
Swap: 2.0Gi 10Mi 2.0Gi

OCI Bastion 経由でプライベート・サブネット内の Ubuntu インスタンスに SSH で接続

Wed, 27 May 2026 00:00:00 +0900

前回、Oracle Linux インスタンスへ OCI Bastion 経由で SSH 接続する手順を書きました。

今回は、前回記事で触れた基本的な構成を前提に、Ubuntu インスタンスを対象とした OCI Bastion 経由の SSH 接続手順だけをまとめます。
Oracle Linux と共通する VCN / Bastion の作成や一般的なネットワーク設定は省略し、Ubuntu 固有の注意点に絞って解説します。

前提

ターゲット OCI インスタンスには Ubuntu のイメージを使う
インスタンスは プライベートサブネット に配置し、パブリックIPなし で作成する
Bastion サービスは事前に作成済みで、プライベートサブネットをターゲットにしている

Ubuntu でのインスタンス作成時のポイント

1. イメージに Ubuntu を選択する

インスタンス作成画面のイメージ選択で、Ubuntu を選びます。
OCI の無料枠対象であれば Always Free 適格 のマークを確認してください。
私は今回 Ubuntu 24.04 Minimal を選択しました。

2. ネットワーキング設定

ここは Oracle Linux のときと同じく以下のように設定します。

プライベートサブネットを選択する
パブリックIP の割当てはなしにする

SSH キーについても同様です。

Ubuntu での Bastion セッション作成

Bastion 自体は、Oracle Linux のときに作成済みなのでそれを使います。
ただ、セッションの作成方法が異なり、Ubuntu の場合は 管理対象 SSH セッションではなく、SSHポート転送セッションを使う のが一般的です。

Bastion セッションの設定

OCI コンソールで「アイデンティティとセキュリティ」 > 「要塞（Bastion）」に移動する
作成した Bastion を選択し、「セッションの作成」をクリックする
以下のように設定する

項目	内容
セッション・タイプ	SSHポート転送セッションを選択します。
ターゲット・ホスト	Ubuntu インスタンスをIPアドレスまたはインスタンス名で指定します。
SSH キー	ご自身のPCにある SSH 公開鍵をアップロード or ペーストするか、新規に生成します。

「セッションの作成」を実行し、状態が アクティブ になるまで待つ

鍵のパーミッション

Linux の SSH では秘密鍵の権限が緩いと接続が拒否されます。以下のように chmod 600 で制限しておきます。

# 例
chmod 600 ~/.ssh/<Ubuntuの秘密鍵>
chmod 600 ~/.ssh/<セッションの秘密鍵>

SSH での接続方法

方法１

Bastion セッションがアクティブになったら、右側のメニューから「SSH コマンドのコピー」を使います。以下のようなコマンドがコピーされます。

ssh -i <privateKey> -N -L <localPort>:10.0.1.203:22 -p 22 ...

項目	内容
`<privateKey>`	セッション作成時の秘密鍵のパスを設定します。
`<localPort>`	基本的には「（1024番〜65535番の間であれば）あなたのPCで現在使われていない任意のポート番号」なら何番でも自由です。よく使われるのは、覚えやすい 12345 や 2222、50022 などだそうです。

上記を踏まえたうえで、まずは以下のようにコマンドを時刻します。

# 例
ssh -i ~/.ssh/bastion_id_rsa -N -L 12345:10.0.1.143:22 -p 22 ...

すると画面が止まった（待機状態）になります。
これでトンネルが維持されている状態ですので、このターミナル画面は閉じずにそのまま放置してください。

この状態で新しく別のターミナル画面を開き、以下のコマンドを実行して Ubuntu インスタンスにログインします。

ssh -i ~/.ssh/Ubuntu作成時の秘密鍵 -p 12345 ubuntu@localhost

📝 注記

あなたのPCの 12345 番ポート（localhost:12345）に接続することが、そのままトンネルを通じて向こう側のUbuntuに繋がるため、接続先は localhost となります。
OCI の Ubuntu インスタンスのユーザー名は ubuntu なので、それを指定します。

方法２

前述の方法だとターミナルを２つを使わないといけません。
これをコマンド一発でやる場合、以下のように打ちます。

ssh -i <Ubuntuの秘密鍵> -o ProxyCommand="ssh -i <セッションの秘密鍵> -W %h:%p -p 22 ... ubuntu@10.0.1.143

方法３

上記のコマンドも結局めちゃくちゃ長いので、自分のPCの ~/.ssh/config に設定を書いてしまうのが最もスマートです。

~/.ssh/config をテキストエディタで開き、以下のように追記します。

# 1. Bastion（要塞）自体の設定
Host oci-bastion
 HostName host.bastion.....oci.oraclecloud.com
 Port 22
 # ★セッションを作成するたびに、以下のUser（ocid...の部分）だけ書き換える
 User ocid1.bastionsession.oc1.....amaaaaaa...
 IdentityFile ~/.ssh/セッション作成時の秘密鍵

# 2. ターゲットとなるUbuntuの設定
Host oci-ubuntu
 HostName 10.0.1.143
 User ubuntu
 IdentityFile ~/.ssh/Ubuntu作成時の秘密鍵
 ProxyCommand ssh oci-bastion -W %h:%p

設定した後は以下のコマンドだけで接続できます。

ssh oci-ubuntu

また、3時間ごとにセッションを作り直した際も、上の User の部分（ocid1.bastionsession…）だけを書き換えるだけで済みます。

VS Code の Remote SSH もこれで使えるようになります。

Ubuntu へのログイン後に確認すること

接続に成功すると、プロンプトが次のようになります。

ubuntu@<hostname>:~$

参考

OCI Bastion 経由でプライベート・サブネット内のインスタンスに SSH で接続

Tue, 26 May 2026 00:00:00 +0900

日本語では要塞と訳されています。

手元の PC からこの Bastion（踏み台の役割）を経由させることで、インスタンス自体にパブリックIPを一切持たせないまま、手元の PC のターミナルから直接 SSH 接続できるようになります。

設定には、ネットワーク（VCN）の構築段階からいくつか重要なポイント（ルーターやセキュリティ・リストの設定など）があり、結構はまったのでメモとして残しておきます。

仕組みとメリット

完全無料で、自分で踏み台用のサーバー（EC2など）を1台管理・維持する必要がありません。
接続が必要なときだけ、手元のPCから「3時間だけ有効な一時的な接続セッション（トンネル）」を発行して侵入します。時間が経てば自動で完全に閉じられるため、セキュリティが非常に強固です。

環境

ホストPC: Ubuntu 22.04
インスタンス: Oracle Linux 9

📝 注記

インスタンスが Oracle Linux の場合と、Ubuntu などの他の OS の場合とで方法が一部異なります。
今回は Oracle Linux 9 の場合で、Ubuntu についてはまた別で書きます。

Step1: VCN とサブネットの作成

まずは土台となる仮想クラウド・ネットワーク（VCN）を作成します。
手動で細かく作ることもできますが、「VCNウィザード」を使うのが一番簡単で確実です。
インターネットに出るための「インターネット・ゲートウェイ」だけでなく、プライベートVMがアップデート等で外と通信するための「NATゲートウェイ」や「サービス・ゲートウェイ」も自動で作成・紐付けされます。

OCIコンソールメニューから「ネットワーキング」 > 「仮想クラウド・ネットワーク」に移動します。

アクションから「VCNウィザードの起動」をクリックします。

「インターネット接続性を持つVCNの作成」を選択し、「VCNウィザードの起動」をクリックします。

以下の情報を入力・確認して「次へ」進み、作成します。

項目	内容
VCN名	任意の名前（例: my-bastion-vcn）
VCNの構成 CIDRブロック	10.0.0.0/16（デフォルトのままでOK）
パブリック・サブネットのCIDR	10.0.0.0/24
プライベート・サブネットのCIDR	10.0.1.0/24

Step2: インスタンスの作成

次に、パブリックIPを持たない接続先のインスタンスを作成します。
「コンピュート」 > 「インスタンス」から「インスタンスの作成」をクリックします。
インスタンスの作成については別記事でも書いているので詳細は割愛しますが、イメージは Oracle Linux 9 を選びます。

そして、ネットワーキングセクションで以下を選択します。

プライベート・サブネット（Step 1で作成したもの）を選択。
「パブリックIPアドレスの割当て」で「パブリックIPなし」を選択。

SSHキーのセクションでは、ご自身のPCで作成した公開鍵（.pub）をアップロード、または新規で生成して秘密鍵を保存してください。

設定したら「作成」をクリックします。

Stes3: Bastion プラグインの有効化 (Oracle Linux の場合のみ)

作成したインスタンスの詳細画面に入り、管理タブの「Oracle Cloud エージェント」で要塞を探し、有効化します。

要塞のステータスが停止済となります。
OSの内部でプログラムのダウンロードや配置が行われており、ステータスが「実行中」になるまでには5分〜10分ほどかかることがあります。

📝 注記

ここで要塞を有効にしておかないと、後述の管理対象SSHセッションの作成で API エラーとなります。

Step4: Bastionの作成

「アイデンティティとセキュリティ」 > 「要塞」（Bastion）に移動します。

「要塞の作成」をクリックし、以下のように設定します。

項目	内容
要塞名	任意の名前
ターゲット仮想クラウド・ネットワーク	Step 1で作成したVCN
ターゲット・サブネット	ターゲットVMがいる「プライベート・サブネット」を選択します。
CIDRブロックの許可リスト	0.0.0.0/0 （特定のIPだけに絞るとより安全です）

「要塞の作成」をクリックします（アクティブになるまで数分かかります）。

Step5: セッションの作成

作成した Bastion の詳細画面に入り、「セッションの作成」をクリックします。

以下のように設定します。

項目	内容
セッション・タイプ	Oracle Linux の場合は管理対象SSHセッションを選択します。
ユーザー名	Oracle Linux の場合は `opc` です。
ターゲット・コンピュート・インスタンス	Step2 で作成したプライベートVMを選択します。
SSHキー	ご自身のPCにある SSH 公開鍵をアップロード or ペーストするか、新規に生成します。VM作成時に使ったものと同じ、またはペアになるものをアップロードしても OK です（後述）。

「セッションの作成」をクリックします。
状態が作成中となり、しばらく経つとアクティブになります。

Step6: SSH接続の実行

セッションが「アクティブ」になったら、いよいよ接続です。作成したセッションの右側にある「3つの点」メニューから「SSHコマンドのコピー」をクリックします。

コピーされるコマンドは以下のような形をしています。

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1..." opc@10.0.1.x

<privateKey> 2箇所ありますので、それぞれ VM インスタンス作成時の秘密鍵、Bastion セッション作成時の秘密鍵のパスに変更して実行します。

# 例
ssh -i ~/.ssh/VM用の秘密鍵 -o ProxyCommand="ssh -i ~/.ssh/Bastion用の秘密鍵 -W %h:%p ..." opc@10.0.1.x

📝 注記

セッション作成時の SSH キーを VM 作成時と同じものにした場合は、2箇所とも同じ秘密鍵のパスを指定します。

📝 注記

Linux のルールとして、秘密鍵の権限が緩いままだとSSH接続が拒否されてしまいます。この場合、以下のコマンドでパーミッションを変更します。
chmod 600 ssh-key-xxxx.key

実行すると、Bastionを経由してパブリックIPのないプライベートVMに直接SSHログインが完了します。

SSH キーについての補足

セッション作成時のSSHキーはVM作成時と同じでも別のものでも大丈夫です。

OCI の Bastion サービスは、接続時に「2枚の壁（認証）」を通過するイメージになります。

Bastionセッション作成時のSSHキー（壁1：入口の鍵）

ローカルPCから、OCIのBastionサービス（要塞）に侵入するための鍵です。
Bastionサービス自体が「あなたは本当にこのセッションを作った本人ですか？」を確かめるために使います。

VM作成時のSSHキー（壁2：奥の部屋の鍵）

Bastionを通り抜けたあと、ターゲットのプライベートVMにログインするための鍵です。
VM（OS）側が「あなたはログインを許可されたユーザーですか？」を確かめるために使います。

このように鍵の役割が独立しています。
ただ、「同じ鍵」を使った場合と「別の鍵」を使った場合で、最後に実行するSSHコマンドの書き換え方が少し変わります。

① 同じ鍵を使った場合（一番シンプル）

すべて1つの秘密鍵（例: id_rsa）で開くので、コピーしたコマンド内の2箇所の <privateKey> に同じ秘密鍵のパスを指定すればOKです。

ssh -i ~/.ssh/id_rsa -o ProxyCommand="ssh -i ~/.ssh/id_rsa -W %h:%p ..." opc@10.0.1.x

② 別の鍵を使った場合（それぞれ指定が必要）

コマンドの「前半」と「後半」で、それぞれの秘密鍵を指定する必要があります。

前半の -i: VM作成時の秘密鍵を指定
中間の ProxyCommand内の -i: Bastionセッション作成時の秘密鍵を指定

ssh -i ~/.ssh/VM用の秘密鍵 -o ProxyCommand="ssh -i ~/.ssh/Bastion用の秘密鍵 -W %h:%p ..." opc@10.0.1.x

管理やコマンドの書き換えをシンプルにしたい場合は、「同じ鍵（ペア）」を使ってしまうのが一番迷わなくてラクです。

セキュリティ的な問題は？

個人開発や一般的な社内検証環境レベルであれば、同じ鍵を使い回しても実用上のセキュリティリスクは非常に低い（実質的に問題ない）と言えます。

ただし、厳格なエンタープライズ（企業）の運用基準や、セキュリティの理想論（ベストプラクティス）の観点から見ると、いくつか「知っておくべきリスクと理由」があります。
なぜ分けるのが理想とされるのか、その理由は以下です。

1. 鍵が漏洩した際の影響範囲（爆発半径）が広がる

これが最も大きな理由です。

鍵を分けている場合： もしBastion用の鍵が外部に漏れても、攻撃者はBastionの入り口までしか来られません。ターゲットVMの鍵が無事なら、中のデータにはアクセスできません。

同じ鍵を使っている場合： その1つの秘密鍵が漏洩した瞬間、Bastionの突破からターゲットVMへのログインまで、すべての防御壁が同時に崩壊します。

ひとつの鍵にすべての権限を持たせることは、セキュリティの世界で嫌がられる「単一障害点（Single Point of Failure）」を作ることになってしまいます。

2. 「誰が・どこに」アクセスしたかの監査（ログ）が曖昧になる

本番環境やチーム開発において重要な視点です。

Bastion（要塞）の本来の目的は、「いつ、誰が、どのサーバーに入ったか」を厳密に記録・コントロールすることです。

Bastion用の鍵：「あなたがクラウド環境のネットワークに入った」ことを証明する
VM用の鍵：「あなたが特定のサーバーの opc ユーザーとしてログインした」ことを証明する

これらを同じ鍵にしてしまうと、鍵の管理者が同一人物である前提になってしまい、「Bastionを通過した人と、実際にVMを操作した人が本当に同一人物か？」という厳密なトレース（監査ログの信頼性）が担保しにくくなります。

参考

OCI (Oracle Cloud Infrastructure) で VM インスタンスを作成する

Thu, 21 May 2026 00:00:00 +0900

OCI (Oracle Cloud Infrastructure)

OCI には Always Free（永久無料枠） という非常に強力な特典があり、4 OCPU / 24 GB メモリ という、他社クラウドであれば有料級のハイスペックな Arm サーバー（Ampere A1）を無料で 24時間365日動かすことができます。

OCI のコンピュート環境：VM とコンテナインスタンスの違い

OCI でアプリケーションを動かすアプローチとして、主に 「VM Compute（仮想マシン）」 と 「コンテナインスタンス（Container Instances）」 の 2つがあります。

どちらも Docker コンテナを動かせますが、その管理レイヤーと仕様には明確な違いがあります。

比較項目	VM Compute (仮想マシン)	コンテナインスタンス
管理の単位	OS（Linux / Windows）	コンテナ（Dockerイメージなど）
インフラ管理	必要（OSアップデート、SSH管理）	不要（サーバーレス。オラクルが基盤を管理）
起動スピード	数分（OSのブート時間必要）	数秒（コンテナの起動のみ）
永続ストレージ	ブロック・ボリュームを自由に追加・マウント可能	エフェメラル（一時的。再起動でデータ消滅）
永久無料枠	あり（4 OCPU / 24 GBメモリまで無料）	なし（秒単位の従量課金）

どちらを選ぶべきか？

コンテナインスタンスはサーバーレスで運用が手軽ですが、永久無料枠（Always Free）の対象外となります。また、コンテナの再起動によって内部のデータが消去される特性を持ちます。

そのため、「24時間いつでも無料で動かし続けたい」「生成されるログやデータをローカルディスクに安全に保持（永続化）したい」という場合は、VM Compute を選択するのが最適です。

OCI への登録

https://www.oracle.com/jp/cloud/free/ にアクセスして「無料で始める」をクリックして各種情報を入力します。
ちょっとした注意事項として、住所は英語で入力する必要があります。

参考

インスタンスの作成

ホームより インスタンス を選択します。

ホームにない場合は、左上のメニューから コンピュート > インスタンス でも OK です。

続いて インスタンスの作成 を選択します。

基本情報

イメージ

デフォルトでは Oracle linux になっています。
Oracle Linux は Red Hat Enterprise Linux（RHEL）をベースにした OS だそうです。

セキュリティの「保護インスタンス」は、仮想マシン（VM）の乗っ取りや、悪意のあるプログラムによるOS改ざんを防ぐための「セキュリティ強化機能が有効になっている状態」を指すそうですので、保護インスタンスになっているものを選択しておいたほうが良さそうです。

シェイプ

Always Free 対象のものとして以下の２つがあります。

項目	Ampere (A1.Flex)	AMD (E2.1.Micro)
最大リソース	4 OCPU / 24 GB（分配可能）	1 OCPU / 1 GB × 2台
アーキテクチャ	Arm (aarch64)	x86_64
主な用途	開発環境、Docker、高負荷な処理、Webサーバー	軽量なスクリプト実行、VPNサーバー、検証用

VM.Standard.A1.Flex

現在OCIで提供されている中で最もハイスペックかつ使い勝手の良い無料枠インスタンスです。
Ampere を選択し、VM.Standard.A1.Flex をチェックします。

シェイプ名横の ▼ を押すと CPU と RAM の設定ができます。

「4 OCPU / 24 GB」までは無料で使えるらしいです。

VM.Standard.E2.1.Micro

Ampere A1 は人気のため、空きがなくて作成できないことが多いです。
また、システムが Arm（Aarch64）アーキテクチャに対応しておらず、どうしても従来の x86_64 環境が必要な場合もあったりします。
そのような場合はこちらを選びます。
ただし、スペックは Ampere A1 に比べて大幅に低くなります。

専門と前世代 を選択し、VM.Standard.E2.1.Micro をチェックします。

上記のうち好きな方を選び、次へを押します。

セキュリティ

保護インスタンスの設定ができますが、予期せぬエラーや「動かない」トラブルの原因になりやすいそうなので、今回は OFF のままとしました。

ネットワーキング

プライマリVNIC

初めて OCI を使うので、まだ「既存のネットワーク」が存在しないため、新しく 新規仮想クラウド・ネットワーク を選択します。サブネットも自動的に 新規パブリック・サブネットの作成 に切り替わり、名前などが自動入力されます。

２回目は既存のネットワークを選択すれば OK です。

パブリックIPv4アドレス割当て

今回は外部からの通信（インバウンド）を受ける必要はないため、 パブリックIPv4アドレスの割当て は OFF にしておきました。

SSHキーの追加

キー・ペアを自動で生成 を選択し、秘密キーのダウンロード を押して秘密鍵をダウンロードしておきます。

📝 注記

SSH キーなしを選択すると、後述するように Cloud Shell からもインスタンスにアクセスできませんでした。外部から SSH でアクセスする予定がなくても SSH キーは作成しておかないといけないようです。

ストレージ

ここは全てデフォルトのままとしました。

「カスタム・ブート・ボリューム・サイズ…」について チェックがOFF（デフォルト）の場合、標準サイズである 46.6 GB のディスクが自動で割り当てられます。
OCIの無料枠では最大で合計200GBまでストレージが使え、ここにチェックを入れて数値を 100 や 200 に増やすことも可能です。
ただ、後からでもディスクサイズは簡単に拡張できるため、最初はデフォルトのままで様子見するのが安全です。

「転送中暗号化の使用」について デフォルトでONになっていますが、これは「仮想マシンとストレージの間の通信を暗号化して盗聴を防ぐ」というインフラ側の高度な保護機能です。
パフォーマンスへの影響も無視できるレベルですので、ON（今の状態）のままにしておきましょう。

「自分が管理するキーでこのボリュームを暗号化」について チェックがOFF（デフォルト）の場合、Oracleが管理する標準の暗号鍵で自動的にディスクが暗号化されます。
個人開発で自前の鍵管理（Vault/KMSなど）を入れると管理コストが増えて複雑になるため、OFFのままで問題ありません。

作成

次へ進み、「作成」 を押すとインスタンスが作成されます。
しばらく待つとインスタンスが作成されます（ステータス表示が 実行中 に変わります）。

API エラーが発生した場合

これは設定の間違いではなく、「現在、Oracleのデータセンター側で、無料枠用のArmサーバー（Ampere）の在庫が一時的に切れている」という、OCIの無料枠で最も頻繁に発生する有名な現象です。
世界中で無料枠のAmpereは非常に人気があるため、椅子取りゲームのようになっています。

解決策は以下です。

1：x86の「AMD枠」に切り替えて即時作成する（確実・おすすめ）

Arm（Ampere）の在庫がなくても、もう1つの無料枠であるAMD（VM.Standard.E2.1.Micro）であれば、在庫に余裕がありすんなり作成できるケースが非常に多いです。

2：「フォルト・ドメイン」を変更して再トライする

同じAmpere（Arm）のまま、サーバーが置かれる物理的な区画（フォルト・ドメイン）を変更することで、運よく在庫が引っかかることがあります。

3：数日〜数週間、時間を変えてクリックし続ける

どうしても強力な「Arm（4 OCPU / 24 GBを狙いたいなど）」が良い場合、誰かがインスタンスを削除して在庫が空くのを待つことになります。

インスタンスの起動

コンピュートの画面から インスタンス を選択し、該当のインスタンスをクリックします。

右上から起動を押します。

これでしばらく待つとインスタンスが起動します。

インスタンスへ接続（Cloud Shell で接続）

OCI 上から Cloud Shell でインスタンスに接続してみます。

Cloud Shell の起動

画面右上の 開発者ツール をクリックし、Cloud Shell を選択します。

画面下に端末が表示されますが、まだインスタンスの中には入っていません。
Cloud Shell が単体で起動しただけです。

ネットワークの変更

端末上部の「ネットワーク：パブリック」と表示されたプルダウンから「エフェメラル・プライベートネット・・・」を選択します。

インスタンス作成時に作成した VCN とサブネットを選択し、アクティブなネットワークとして使用 を押します。

秘密鍵ファイルのアップロード

先程ダウンロードした秘密鍵ファイルを端末上にドラッグ＆ドロップしてアップロードします。

Linux のルールとして、秘密鍵の権限が緩いままだとSSH接続が拒否されてしまうため、以下のコマンドでパーミッションを変更します。（※ファイル名はご自身のものに書き換えてください）

chmod 600 ssh-key-xxxx.key

SSH コマンドでログインする

以上で準備は完了です。
以下のコマンドで Cloud Shell インスタンスへと接続します。

ssh -i ssh-key-xxxx.key <username>@<private_ip_address>

<username> は、インスタンスのデフォルトのユーザー名です。
Oracle Linux および Redhat Enterprise Linux 互換イメージの場合、デフォルトのユーザー名は opc、Ubuntu イメージの場合、デフォルトのユーザー名は ubuntu だそうです。

<private_ip_address> は接続先インスタンスのプライベートIPアドレスです。
コンピュート > インスタンス で確認できます。10.0.x.x のような数字を入れてください。

コマンド入力後、Are you sure you want to continue connecting (yes/no)? と聞かれたら、 yes と入力してEnterを押します。

無事にプロンプトが <username>@instance-xxxx:~$ に切り替われば、インスタンスに接続できています。

とりあえずはここまで。

参考

Cloudflare Pages で静的サイトを公開する（GitLab 連携）

Sun, 17 May 2026 00:00:00 +0900

前提・環境

ソース管理: GitLab (GitHub でもやり方は同じ)
ホスティング: Cloudflare Pages
DNS: Cloudflare（既存ドメインのサブドメインに展開する想定）

GitLab 側で必要なこと

ほぼ何もしなくて構いません。
.gitlab-ci.yml を書く必要はなく、Cloudflare Pages が直接 git clone してビルドします。

最低限の準備は次のとおりです。

リポジトリが Cloudflare からアクセスできること（Public ならそのまま、Private なら次節の OAuth で許可します）
プロダクションブランチ（main など）を決めておくこと

ブランチ運用は Cloudflare Pages 側で自動的に処理されます。

プロダクションブランチへの push → 本番デプロイ
それ以外のブランチへの push → 自動でプレビュー URL が発行される

Cloudflare Pages 側のセットアップ

Cloudflare ダッシュボード → Workers & Pages を選択します。

Create application を選択します。

下部にある Get started をクリックします。

Import an existing Git repository の Get started を選択します。

Git プロバイダの接続

GitHub だけでなく GitLab も公式サポートされています。
GitLab のタブを選択し、Connect GitLab から OAuth で認証を行います。
認証後、対象リポジトリを選び、Begin setup を選択します。

ビルド設定で指定する項目

Framework preset: 使っているフレームワークに該当があれば選びます。自前のシェルスクリプトでビルドするなら None で構いません
Build command: リポジトリ直下から実行されるビルドコマンド
Build output directory: 成果物のディレクトリ（例: dist、public）
Root directory: 通常は空欄でリポジトリ直下
Environment variables: 必要に応じて設定します

初回デプロイの確認

Save and Deploy を選択すると数分でビルドが走り、プレビュー URL（<project>.pages.dev）が発行されます。
ここでまず動作確認をしてから、カスタムドメインを当てに行きます。

カスタムドメインの設定

DNS も Cloudflare で管理しているなら、ほぼワンクリックで終わります。

初回デプロイ完了後、Add custom domain を選択するとカスタムドメインの設定画面に移行します。

メニューからアクセスする場合は、Workers & Pages の Custom domains タブを選択します。

Set up a custom domain を選択します。
続いて、適用したいドメインを入力し、Continue をクリックします。
すると、CNAME レコードが自動で追加されます（手動編集は不要です）。

Activate domain をクリックすると設定完了です。
TLS 証明書も Cloudflare 側で自動発行されます（数分待ちます）

SSL/TLS モードの変更

SSL/TLS モードは Full (strict) にしておきます。
Cloudflare Pages の出口側は有効な証明書を持つので、Full (strict) でもエラーにはならず、Flexible のように HTTPS が中途半端な状態を避けられます。

SSL/TLS の Overview を選択し、SSL/TLS encryption の Configure をクリックします。

Full (Strict) を選択して、Save をクリックして完了です。

気をつけること

`NODE_VERSION` の明示

Cloudflare Pages のデフォルト Node は古いことがあります。
package.json の engines だけでは効かないので、ビルド設定の環境変数で明示します。

ビルド時間と無料枠

無料枠は 同時ビルド 1 並列・月 500 回までです。
push のたびにビルドが走るので、頻繁な push を続けると上限に近づきます。CI ライクに何度も push しまくる運用には向きません。

初回ビルドは npm install がフレッシュで 5〜10 分かかることもあります。2 回目以降はキャッシュが効きます。

プレビュー URL の検索エンジン除外

Cloudflare Pages は本番ドメイン以外（<project>.pages.dev や <branch>.<project>.pages.dev）にも 自動で X-Robots-Tag: noindex を付けます。Google にプレビュー版がインデックスされる事故は基本的に起きません。

まとめ

すべて 無料枠で完結し、自前のサーバー運用はゼロです。
GitLab に push して数分で本番反映される、最小構成になっています。

GitLab Pages + Cloudflare プロキシでも同じことはできますが、TXT 検証や SSL モード調整など「2 サービスを連携させるための作業」が発生します。
Cloudflare 内で完結させると、覚えることが 1 箇所にまとまって精神的に楽です。

Claude Code の認証情報とチャット履歴を devcontainer とホストで共有する

Wed, 13 May 2026 00:00:00 +0900

環境

Ubuntu 24.04
VSCode 1.119.0

きっかけ

devcontainer をリビルドするたびに Claude Code に再ログインするのが地味にストレスでした。さらに、ホスト側で進めていた会話の続きが devcontainer 側からは見えず、「あの修正の文脈どこに残してたっけ」となりがちでした。

ゴール構成

ホスト・devcontainer のどちらで起動しても 同じ認証情報 を使える
ホストで途中まで進めた会話を devcontainer 側でも そのまま継続 できる
リビルドしても再ログイン不要

Claude Code が何を見ているかを把握する

設定の前に、Claude Code が以下の 2 つを参照していることを押さえておきます。

種類	場所	役割
認証情報・設定	`~/.claude.json`	API キーなど
セッション履歴	`~/.claude/projects/<エンコードしたパス>/`	プロジェクトごとの会話履歴

ポイントは、セッション履歴の格納先が プロジェクトの絶対パスをスラッシュ → ハイフンに変換した名前 になっていることです。

例えばホスト側で /home/<username>/<project_name> を開いていた場合は、

~/.claude/projects/-home-<username>-<project_name>/

の下に履歴が溜まります。

つまり、履歴を共有したいなら ホストとコンテナで「ワークスペースの絶対パス」を一致させる必要がある ということです。~/.claude だけ bind mount しても、コンテナ側のワークスペースパスがホストと違えば別フォルダ扱いになり、履歴は共有されません。

設定する 2 つのマウント

必要なマウントは性質の違う 2 種類になります。

1. `.claude` / `.claude.json` のマウント (= コンテナ側ユーザーの home に合わせる)

Claude Code は そのプロセスの $HOME/.claude を読みに行きます。devcontainer のデフォルトユーザーは vscode なので、~ は /home/vscode です。したがってターゲットも /home/vscode/.claude にします。

2. ワークスペースのマウント (= ホスト側の絶対パスに合わせる)

こちらはセッション履歴のキーになる「プロジェクトの絶対パス」を一致させるのが目的なので、ターゲットを ホスト側と同じパス にします。ホストの ~/<project_name> を開いているなら、コンテナ内でも /home/<username>/<project_name> にマウントするということです。

ターゲットの基準が違う (ユーザー基準 vs ホスト基準) のがややこしい部分なので、表にしておきます。

マウント	ターゲット	基準
`~/.claude` `~/.claude.json`	`/home/vscode/.claude` `/home/vscode/.claude.json`	コンテナ内ユーザーの home
ワークスペース	`/home/<username>/<project_name>` 等	ホスト側の絶対パス

devcontainer.json の例

上記を踏まえた .devcontainer/devcontainer.json の抜粋です。

{
 "name": "my-devcontainer",
 "build": {
 "dockerfile": "Dockerfile",
 "args": {
 // ホストの $HOME を build arg として Dockerfile に渡す
 // (workspace の親ディレクトリを事前に作るために使う。後述)
 "WORKSPACE_PARENT": "${localEnv:HOME}"
 }
 },

 // ワークスペースのマウント先をホスト側の絶対パスと一致させる。
 // フォルダ名は localWorkspaceFolderBasename で動的解決するので、
 // ホスト側を rename しても devcontainer.json の編集は不要。
 "workspaceMount": "source=${localWorkspaceFolder},target=${localEnv:HOME}/${localWorkspaceFolderBasename},type=bind,consistency=cached",
 "workspaceFolder": "${localEnv:HOME}/${localWorkspaceFolderBasename}",

 "mounts": [
 // .claude / .claude.json はコンテナ内ユーザー (vscode) の home にマウント
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached"
 ],

 "remoteUser": "vscode"
}

${localEnv:HOME} は ホスト側 の $HOME (例: /home/<username>)、${localWorkspaceFolderBasename} は VSCode が開いているフォルダ名 (例: <project_name>) に展開されます。両者を組み合わせることで、ホストで開いているパスと完全に同じ絶対パスをコンテナ内に作れます。

Dockerfile 側で親ディレクトリを用意しておく

workspaceFolder に指定したパスの 親ディレクトリ がコンテナ内に存在しないと、Dev Containers の起動チェックで「ワークスペースが存在しません」とエラーになります。bind mount はマウント時にターゲットを作ってくれますが、Dev Containers のチェックがそれより先に走るためです。

そこで Dockerfile 側で親ディレクトリだけ先に作っておきます。

FROM mcr.microsoft.com/devcontainers/base:bookworm

# devcontainer.json の workspaceFolder (= ホストの $HOME/<フォルダ名>) と
# 同じ絶対パスをコンテナ内に用意しておく。
ARG WORKSPACE_PARENT=/home/vscode
RUN mkdir -p "${WORKSPACE_PARENT}"

ARG のデフォルト値を /home/vscode にしておけば、build arg を渡し忘れても既存ユーザーのホームが使われるだけで build が壊れることはありません。

ユーザーは vscode のままでよい

「ワークスペースが /home/<username>/<project_name> なのに whoami すると vscode になっている」というアンバランスさが気になるかもしれませんが、機能上は問題ありません。

devcontainers/base の vscode ユーザーは UID 1000
ホスト側の Linux ユーザーも通常 UID 1000

UID が一致していれば bind mount したファイルにそのまま読み書きできるためです。vscode ユーザーが自分の home (/home/vscode/) 以外の場所で作業すること自体は何も問題を起こしません。

ユーザー名まで揃えようとすると base image の改造が必要になり、devcontainer features が前提にしている vscode ユーザーが消えて壊れがちです。ホストと揃えるのは「絶対パス」だけで十分 と割り切るのが楽です。

注意点

ホスト側に ~/.claude と ~/.claude.json が存在している必要があります。なければ bind mount に失敗します。ホスト側でも一度 Claude Code を起動して認証を済ませておくのが手っ取り早いです。
セッション履歴を ホストと同時に書き込まない よう注意してください。両方から同じプロジェクトを同時に触ると、ファイルロック等の衝突で履歴が壊れることがあります。基本「どちらか一方で作業する」運用が安全です。
設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドしないと反映されません。

まとめ

Claude Code のセッション履歴は プロジェクトの絶対パスをキー にして格納される。
なので「ホストとセッション共有したい」ならコンテナ内のワークスペースパスをホスト側と完全一致させる必要がある。
マウント先は 2 系統で基準が違う:
- .claude / .claude.json は コンテナ内ユーザーの home に合わせる
- ワークスペースは ホスト側の絶対パス に合わせる
ワークスペースの親ディレクトリは Dockerfile 側で mkdir -p しておく必要がある。
フォルダ名は ${localWorkspaceFolderBasename} で動的解決すれば、rename にも追従する。

Cloudflare で取得した独自ドメインを GitLab Pages に設定する方法

Tue, 12 May 2026 00:00:00 +0900

全体の流れ

GitLab側: カスタムドメイン登録と検証コードの取得
GitLab側: Pagesの公開範囲（Visibility）の設定
Cloudflare側: DNSレコード（CNAME/TXT）の設定
最終確認: SSL証明書の発行とプロキシの有効化

1. GitLab側でカスタムドメインを追加する

まず、GitLabに「このドメインを使います」と伝えて、検証用のコードを発行します。

プロジェクトの左メニュー [Deploy] > [Pages] を開きます。
Domains & settings のタブを選択し、[Add Domain] をクリックします。
使用したいドメイン（例: blog.example.com）を入力し、[Create new domain] をクリックします。
表示された画面から以下の2点をメモします。
- TXTレコードの値: gitlab-pages-verification-code=...
- CNAMEのターゲット: username-12345.gitlab.io

自分の「名前空間（Target）」を確認する方法

GitLab PagesのデフォルトURLを確認してください。例：https://username-12345.gitlab.io/my-project

この場合、Cloudflare側で指定するターゲットは username-12345.gitlab.io です。 .gitlab.io の直前まで（スラッシュより前のホスト部分）が、あなたの「名前空間（Namespace）」となります。

2. プロジェクトはPrivateのまま、Pagesだけを公開する

「ソースコードは見せたくないが、ブログとして誰でも見れるようにしたい」場合は、以下の設定が必須です。

[Settings] > [General] を開きます。
[Visibility, project features and permissions] セクションを展開します。
Project visibility は [Private] のままにします。
下の方にある [Pages] の権限設定を [Everyone] に変更します。
- ※ここが Only Project Members だと、独自ドメインにアクセスしてもGitLabのログイン画面が出てしまいます。
[Save changes] で保存します。

3. Cloudflare側でDNSレコードを設定する

Cloudflareの管理画面の左メニューから [Domains] > [Overview] を開き、該当のドメインをクリックします。

さらに左メニューから [DNS] > [Records] を開き、Add record をクリックして、以下の2つのレコードを追加します。

① CNAMEレコード（接続用）

項目	設定値の例	補足
Type	`CNAME`
Name	`blog`	サブドメイン部分のみ入力
Target	`username-12345.gitlab.io`	先ほど確認したGitLabのホスト名
Proxy status	DNS only (灰色雲)	SSL発行をスムーズにするため最初は必ず「灰色」にする

② TXTレコード（ドメイン所有確認用）

項目	設定値の例	補足
Type	`TXT`
Name	`_gitlab-pages-verification-code.blog`	`_gitlab-pages-verification-code.` の後にサブドメイン名を付ける
Content	`gitlab-pages-verification-code=...`	GitLabからコピーした検証コード

4. 仕上げ：検証とプロキシ有効化

① GitLabで検証する

DNS設定後、GitLabのPages設定画面で [Verify]（更新マーク）ボタンを押します。「Verified」になれば成功です。

⚠️ すぐに認証されない場合があります。 Cloudflare管理ドメインはDNSのTTLが短いため反映は比較的早いですが、DNSの浸透には最大48時間かかることがあります。Verifyが通らない場合は時間をおいて再試行してください。

② SSL証明書の発行を待つ

検証完了後、数分〜30分ほどでLet’s Encryptの証明書が自動発行され、https:// でアクセスできるようになります。

③ CloudflareのプロキシをONにする

https:// で正常に表示されたことを確認してから、CloudflareのDNSレコードを [Proxied（オレンジ雲）] に切り替えます。

プロキシを ON にするメリット

CDNによる高速化: 画像やJSがキャッシュされ、表示速度が向上します。
セキュリティ強化: DDoS保護やWAFが利用可能になります。
アクセス解析: Cloudflare側でトラフィックやアクセス地域を確認できます。

④ CloudflareのSSL/TLS設定を変更する

プロキシを有効にしたら、Cloudflareの [SSL/TLS] > [Overview] を開き、暗号化モードを確認します。

モード	説明	推奨
`Full`	GitLab側の証明書を検証せず暗号化	初心者・通常利用向け
`Full (strict)`	GitLab側にLet’s Encryptなど信頼されたCA発行の証明書が必要	SSL発行が正常に完了していれば利用可

⚠️ Full (strict) はSSL証明書が有効な状態でのみ機能します。証明書の発行前や更新タイミングで一時的にエラーになるリスクがあるため、迷ったら Full を選択してください。

5. 運用上の注意：キャッシュの扱い

Cloudflareのプロキシを有効にすると、CSSや画像などの静的ファイルがキャッシュされます。 サイトを更新しても古いコンテンツが表示される場合は、Cloudflareのキャッシュをクリアしてください。

手動でキャッシュをクリアする方法:

Cloudflareダッシュボードの [Caching] > [Configuration] を開く
[Purge Cache] > [Purge Everything]（または特定URLを指定）を実行する

まとめ

GitLab Pagesを独自ドメインで運用する主なポイントは以下の3点です。

正しいCNAMEターゲットを設定する — GitLabのPages URLから実際のホスト名を確認して使う
PagesのVisibilityを「Everyone」にする — Privateプロジェクトでも公開アクセスを許可する
SSL発行前はプロキシを灰色に保つ — 証明書が発行されてからオレンジ雲に切り替える

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

Mon, 11 May 2026 00:00:00 +0900

環境

Ubuntu 24.04

きっかけ

git remote -v を眺めていたら、Personal Access Token (PAT) が remote URL に丸ごと埋め込まれている状態になっていました。

origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (fetch)
origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (push)

.git/config はリポジトリに含まれないため「push しても外には出ない」ものの、ローカルで露出する経路は意外と多くあります。

シェル履歴 (~/.bash_history ~/.zsh_history)
エディタや CI のログ、画面共有・スクリーンショット
うっかり配布した dotfiles リポジトリ
マルウェアやリモートアクセスで .git/config が読まれる

しかも classic PAT はスコープが粗く、repo 権限があれば private リポジトリ全体の閲覧・書き換え、強制 push による履歴破壊、GitHub Actions secrets の窃取まで可能になります。攻撃者は奪った瞬間には何もせず静かに watch することもできるため、「使われた形跡がない」では安心できません。

これを機に、PAT を URL に埋めず GitHub CLI (gh) の credential helper に任せる構成に切り替えました。

ゴール構成

remote URL は素の https://github.com/USER/REPO.git
認証は gh が credential helper として処理 (トークンは OS のセキュアストア管理)
devcontainer を作り直しても再ログイン不要

手順

1. 露出したトークンを revoke (最優先)

remote URL を書き換える前に、まず GitHub 側でトークンを無効化します。

classic PAT: https://github.com/settings/tokens
fine-grained PAT: https://github.com/settings/personal-access-tokens

該当トークンを Delete した瞬間に無効になります。順序として これを先にやる ことが大切です。後の手順を待っている間に古いトークンが他経路で使われるリスクを断ちます。

2. `gh` をインストール

devcontainer 環境なら ghcr.io/devcontainers/features/github-cli feature で gh がすでに入っています。

ホスト (Ubuntu 24.04) に入れる場合は、以下の記事を参考にしてください。

GitHub CLI (gh) のインストールと基本的な使い方

3. `gh auth login` で認証

gh auth login

対話で以下のように選びます。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

Authenticate Git with your GitHub credentials? → Yes が肝で、これが git config --global credential.helper を gh 経由に書き換えてくれます。以後 git push のたびに gh が裏でトークンを取り出して認証してくれます。

devcontainer のようなヘッドレス環境ではブラウザは自動で開きません。表示される 8 桁のワンタイムコードをコピーし、ホスト側のブラウザで https://github.com/login/device に貼って承認します。

✓ Authentication complete.
✓ Logged in as USER

4. remote URL からトークンを除去

git remote set-url origin https://github.com/USER/REPO.git
git remote -v

トークン部分が消えていれば OK です。git fetch origin がパスワードを聞かれずに通れば認証は機能しています。

5. シェル履歴の残骸を確認

revoke 済みでも、ローカル履歴に残ったトークン文字列は気持ちが悪いものです。

grep -rn 'ghp_' ~/.bash_history ~/.zsh_history 2>/dev/null

ヒットしたら該当行を削除します (history -d <行番号> でメモリ上を消した後、ファイルも編集しておきます)。

devcontainer での認証共有

gh の認証情報は ~/.config/gh/hosts.yml (と OS のセキュアストア) に保存されます。devcontainer をリビルドすると ~/.config/gh が消えて再ログインが必要になるため、ホストの設定を bind mount で共有します。

.devcontainer/devcontainer.json:

"mounts": [
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.config/gh,target=/home/vscode/.config/gh,type=bind,consistency=cached"
]

前提として ホスト側に ~/.config/gh ディレクトリが存在している必要があります (なければ bind mount に失敗します)。ホストにも gh を入れて gh auth login 済みにしておくのが一番シンプルです。事情があってホスト側で gh を使わない場合でも、空ディレクトリだけ作っておけばマウント自体は通ります。

mkdir -p ~/.config/gh # ホスト側で実行

設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドすると反映されます。

補足: SSH 鍵にしないのか

SSH 鍵認証もアリですが、

鍵ファイル自体の管理 (~/.ssh のパーミッション、複数マシン間の同期) が発生します
GitHub Actions など他用途で gh をどのみち使うことが多いです

そのため、個人開発の HTTPS なら gh auth login ひとつに寄せた方がメンテが楽だと感じています。複数アカウントの切替も gh auth switch で済むのが良いところです。

まとめ

PAT を URL に埋めるのは「公開リポジトリに含まれない」だけでローカル経路の露出リスクは大きいです。露出に気付いた時点で revoke が最優先となります。
gh auth login で credential helper を任せれば URL からトークンを排除でき、トークンは OS のセキュアストアに隔離されます。
devcontainer ではホストの ~/.config/gh を bind mount しておくと、リビルドのたびに再ログインしなくて済みます。

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

Sun, 10 May 2026 00:00:00 +0900

ブラウザを開かずに Issue を確認したり、MR（マージリクエスト）を作成したり、CI/CD パイプラインの状況を監視したりできるため、エンジニアの生産性を大きく向上させてくれます。

1. インストール方法

devcontainer を使っていない場合は、ホスト側に glab をインストールして使います。devcontainer を使う場合は、コンテナイメージに glab をインストールしておくか、devcontainer の Dockerfile / devcontainer.json で導入しておきます。

一般的な手順としては、Dockerfile に curl で glab の公式パッケージを取得して apt install するか、apt リポジトリからインストールする形です。コンテナ内で glab --version を実行して、インストールが正しくできていることを確認してください。

OS ごとの主要なインストールコマンドは以下の通りです。

OS	インストールコマンド
macOS	`brew install glab`
Windows (winget)	`winget install glab`
Windows (scoop)	`scoop install glab`
Linux (Ubuntu/Debian)	`sudo apt install glab`（※公式リポジトリ推奨）

インストール後、glab --version で正常にインストールされたか確認しましょう。

バージョンが古かったり、上記でインストールできない場合は、公式リリースからダウンロードしてインストールします。

https://gitlab.com/gitlab-org/cli/-/releases

例えば以下です。

cd /tmp
wget https://gitlab.com/gitlab-org/cli/-/releases/v1.97.0/downloads/glab_1.97.0_linux_amd64.deb
sudo dpkg -i glab_1.97.0_linux_amd64.deb

2. 初期設定（認証）

インストールが完了したら、GitLab アカウントと連携させます。

glab auth login

実行すると対話形式で以下の項目を聞かれます：

GitLab インスタンスの種類: GitLab.com か自前運用のサーバー（Self-Managed）かを選択。
認証方法: Web を選択するとブラウザが開いて簡単に認証できます。
プロトコル: SSH または HTTPS を選択。

設定が完了すると、~/.config/glab-cli/config.yml に設定が保存されます。

3. devcontainer での認証情報共有

glab の認証情報は ~/.config/glab-cli/config.yml に保存されます。devcontainer をリビルドするとコンテナ内の ~/.config/glab-cli が消えて再ログインが必要になるため、ホスト側の設定を bind mount で共有しておくと便利です。

一般的には、.devcontainer/devcontainer.json の mounts にホストの ~/.config/glab-cli を追加します。例:

"mounts": [
 "source=${localEnv:HOME}/.config/glab-cli,target=/home/vscode/.config/glab-cli,type=bind,consistency=cached"
]

もし gh など別の CLI も devcontainer 内で使うなら、同じように ~/.config/gh を共有することもできます。

ホスト側に ~/.config/glab-cli が存在していれば、ホストで一度 glab auth login しておけばコンテナ側でも同じ認証を使えます。ホストにディレクトリがない場合は、mkdir -p ~/.config/glab-cli で空ディレクトリを作成しておけばマウントが通ります。

このようにしておけば、glab の認証設定をホストと devcontainer で共通化し、コンテナ再構築後も再ログイン不要で作業を続けやすくなります。

4. よく使う基本コマンド集

glab のコマンド体系は glab <リソース名> <アクション> という形式で、gh と非常に似ています。

■ Merge Request (MR) を操作する

開発のメイン作業となる MR 操作です。

MR の一覧表示: glab mr list
MR の作成: glab mr create --fill（現在のブランチから自動入力で作成）
MR の詳細表示: glab mr view <id>
MR を承認: glab mr approve <id>
MR をマージ: glab mr merge <id>

■ Issue (課題) を管理する

Issue 一覧: glab issue list
Issue 作成: glab issue create -t "タイトル" -description "内容"

■ CI/CD パイプラインを確認する

glab 独自の強力な機能の一つが、CI パイプラインのリアルタイム監視です。

パイプラインの状態表示: glab pipeline status
実行中のログをリアルタイム表示: glab pipeline ci view
失敗したジョブの再実行: glab ci retry

4. `gh` と `glab` の主な対応表

GitHub CLI に慣れている方向けのクイック比較です。

機能	GitHub (`gh`)	GitLab (`glab`)
認証	`gh auth login`	`glab auth login`
PR / MR 作成	`gh pr create`	`glab mr create`
PR / MR チェックアウト	`gh pr checkout <id>`	`glab mr checkout <id>`
リポジトリ作成	`gh repo create`	`glab project create`
CI 監視	`gh run watch`	`glab pipeline ci view`

5. 自社運用の GitLab (Self-Managed) で使うコツ

glab は GitLab.com だけでなく、会社などで独自に立てている GitLab サーバーでも使えます。その場合、環境変数でホストを指定しておくと便利です。

export GITLAB_HOST=gitlab.example.com

まとめ

glab を導入することで、「コードを書く → プッシュする → ブラウザで MR を作る → CI の完了を待つ」という一連の流れをターミナルから一歩も出ずに行えるようになります。

まずは glab mr list から始めて、快適な GitLab ライフを送りましょう！

参考リンク:

GitHub CLI (gh) のインストールと基本的な使い方

Sat, 09 May 2026 00:00:00 +0900

GitHub CLI (gh) は、GitHub が公式に提供しているコマンドラインツールです。

ブラウザを開かなくても、リポジトリの clone、Issue の確認、Pull Request の作成、GitHub Actions の実行状況確認などをターミナルから操作できます。Git と組み合わせて使うと、日常の GitHub 作業をかなり短い導線にできます。

この記事では、Windows と Ubuntu で gh をインストールし、最初に覚えておくと便利な基本コマンドをまとめます。

gh でできること

gh を使うと、たとえば以下のような作業をターミナルから実行できます。

GitHub へのログイン
リポジトリの clone / 作成 / 表示
Issue の一覧表示 / 作成 / 表示
Pull Request の一覧表示 / 作成 / checkout / merge
GitHub Actions の workflow / run の確認
ブラウザで現在のリポジトリや PR を開く

GitHub の画面を見に行く回数を減らせるので、コードを書いている流れを止めにくいのが大きなメリットです。

インストール

Windows にインストールする

Windows では、公式手順として WinGet を使う方法が一番簡単です。

PowerShell または Windows Terminal を開いて、以下を実行します。

winget install --id GitHub.cli

インストール後、ターミナルを開き直して確認します。

gh --version

バージョン情報が表示されればインストール完了です。

アップデートする場合は以下です。

winget upgrade --id GitHub.cli

もし WinGet を使わない場合は、GitHub CLI の Releases ページから MSI インストーラーをダウンロードして導入することもできます。

Ubuntu にインストールする

Ubuntu では、標準の apt リポジトリからそのままインストールできます。

まずパッケージ情報を更新してから、gh をインストールします。

sudo apt update
sudo apt install gh

確認します。

gh --version

アップデートする場合は、通常の apt パッケージと同じです。

sudo apt update
sudo apt install gh

もし apt で見つからない場合や、GitHub CLI の最新版を追いたい場合は、GitHub CLI 公式リポジトリを追加する方法もあります。

type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)
sudo mkdir -p -m 755 /etc/apt/keyrings
wget -nv -O /tmp/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg
sudo cp /tmp/githubcli-archive-keyring.gpg /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo mkdir -p -m 755 /etc/apt/sources.list.d
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh

通常利用なら、まずは sudo apt install gh で十分です。

初期設定: GitHub にログインする

インストールできたら、GitHub アカウントでログインします。

gh auth login

対話形式でいくつか質問されます。個人利用で GitHub.com を使うなら、だいたい以下の選択で問題ありません。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

ポイントは、Authenticate Git with your GitHub credentials? で Yes を選ぶことです。これにより、gh だけでなく通常の git push や git fetch の HTTPS 認証も gh に任せられます。

ブラウザが開いたら GitHub にログインして認証します。WSL やサーバー上などブラウザを開きにくい環境では、表示されたワンタイムコードを手元のブラウザで入力して認証します。

ログイン状態は以下で確認できます。

gh auth status

普通の git コマンドでも gh の認証情報は使われる？

使われます。ただし、gh auth login の途中で以下を選んでいることが前提です。

? Authenticate Git with your GitHub credentials? Yes

この設定を有効にすると、gh が Git の credential helper として設定されます。そのため、以下のような普通の Git コマンドでも、gh でログインした認証情報が利用されます。

git fetch origin
git pull
git push origin main

確認するには、Git の credential helper 設定を見ます。

git config --global --get credential.helper

環境によって表示は少し違いますが、gh auth git-credential を使う設定になっていれば OK です。

注意点として、この仕組みが使われるのは基本的に HTTPS の remote URL です。

git remote -v

remote URL が以下のようになっていれば、HTTPS 経由です。

origin https://github.com/OWNER/REPO.git (fetch)
origin https://github.com/OWNER/REPO.git (push)

一方で、git@github.com:OWNER/REPO.git のような SSH の remote URL を使っている場合は、Git の認証は SSH key 側で行われます。この場合でも gh コマンド自体の GitHub API 操作には、gh auth login の認証情報が使われます。

よく使う基本コマンド

ここからは、最初に覚えておくと便利なコマンドです。

リポジトリ操作

リポジトリを clone します。

gh repo clone OWNER/REPO

たとえば GitHub CLI 本体のリポジトリなら以下です。

gh repo clone cli/cli

現在のリポジトリをブラウザで開きます。

gh repo view --web

新しいリポジトリを作成します。

gh repo create

対話形式で公開範囲やローカルディレクトリの扱いを選べます。スクリプト化したい場合は、--public や --private などのオプションを付けて実行できます。

gh repo create my-app --private --source=. --remote=origin

Issue 操作

Issue の一覧を表示します。

gh issue list

Issue の詳細を表示します。

gh issue view 123

Issue を作成します。

gh issue create --title "ログイン画面の文言を修正する" --body "ボタンの表記を変更する"

ブラウザで Issue を開きたい場合は --web を付けます。

gh issue view 123 --web

Pull Request 操作

Pull Request の一覧を表示します。

gh pr list

現在のブランチから Pull Request を作成します。

gh pr create

コミットメッセージやブランチ情報からタイトル・本文を自動入力したい場合は --fill が便利です。

gh pr create --fill

Pull Request の詳細を表示します。

gh pr view 123

Pull Request のブランチをローカルに checkout します。

gh pr checkout 123

レビューや CI の状態を確認します。

gh pr checks 123

マージします。

gh pr merge 123

GitHub Actions 操作

workflow の一覧を表示します。

gh workflow list

実行履歴を表示します。

gh run list

最新の workflow run を確認します。

gh run view

実行中の workflow を待ちます。

gh run watch

失敗したジョブのログを確認する場合は、まず gh run list で run ID を確認してから以下を実行します。

gh run view RUN_ID --log-failed

便利な使い方

現在のページをブラウザで開く

現在のリポジトリを GitHub 上で開きます。

gh browse

Issue や PR の URL を組み立てる必要がないので、地味に便利です。

自分に関係する状況をまとめて見る

自分に関連する Issue、PR、レビュー依頼などを確認できます。

gh status

朝の作業開始時に一度実行すると、見るべきものをざっと把握できます。

エイリアスを作る

よく使うコマンドは短い別名を付けられます。

gh alias set prs 'pr list --author @me'
gh prs

この例では、自分が作成した Pull Request 一覧を gh prs で表示できます。

Windows と Ubuntu で共通して気をつけること

ターミナルを開き直す

Windows ではインストーラーが PATH を更新します。gh が見つからない場合は、Windows Terminal や PowerShell を開き直してください。

Ubuntu でも、インストール後にシェルがコマンドの場所をキャッシュしている場合があります。うまく認識されないときは、ターミナルを開き直すか hash -r を実行します。

Git の認証方式をそろえる

gh auth login で HTTPS を選び、Git の認証にも gh を使う設定にした場合、リモート URL も HTTPS にしておくと扱いやすいです。

git remote -v
git remote set-url origin https://github.com/OWNER/REPO.git

SSH を使いたい場合は、gh auth login の対話で SSH を選び、SSH key の登録も gh に任せることができます。HTTPS と SSH のどちらでも使えますが、チームや自分の環境で片方に寄せておくとトラブルシュートが楽です。

GitHub Enterprise Server を使う場合

会社などで GitHub Enterprise Server を使っている場合は、ホスト名を指定してログインします。

gh auth login --hostname github.example.com

通常の GitHub.com とは認証先が別になるため、gh auth status でどのホストにログインしているか確認しておくと安心です。

まとめ

gh を入れておくと、GitHub 上の操作をターミナルから自然に扱えるようになります。

まずは以下の流れだけ覚えておけば十分です。

gh auth login
gh repo clone OWNER/REPO
gh issue list
gh pr list
gh pr create --fill
gh run list

慣れてきたら gh pr checkout、gh pr checks、gh run watch あたりを使うと、Pull Request と CI の確認がかなり楽になります。

参考 URL

ブログ移転の報告

Tue, 28 Apr 2026 00:00:00 +0900

移転しました

Blogger で作成していたブログを、こちらに移転しました。

最近は生成 AI が当たり前になり、自分で調べものをすることも少なくなって、記事もあまり書けていませんでしたが、これからも細々と続けていきたいと思います。

過去の記事についてはまだ全て移動できていませんが、少しずつ移動させていきます。

Jekyll で asciidoctor-diagram を使う

Tue, 27 May 2025 00:00:00 +0900

Jekyll で Asciidoc を使えるようにしたのですが、Asciidoc 内でダイアグラムを使うためには以下の設定が必要です。

Asciidoctor Diagram の有効化

Gemfile に以下を追加します。

group :jekyll_plugins do
 gem 'asciidoctor-diagram'
 gem 'asciidoctor-diagram-plantuml'
end

以下のページには記述がありませんでしたが、私の環境では asciidoctor-diagram-plantuml も必要でした。

https://github.com/asciidoctor/jekyll-asciidoc?tab=readme-ov-file#enabling-asciidoctor-diagram

生成された画像の保存

Jekyll に、ビルドプロセスの途中で Asciidoctor Diagram が出力した画像ファイルを削除しないよう指示するために、 _plugins/jekyll-ext.rb を作成し、以下を記述します。

class Jekyll::Cleaner
 def cleanup!; end
end

詳細は以下をご参照ください。

https://github.com/asciidoctor/jekyll-asciidoc?tab=readme-ov-file#preserving-generated-images

参考 URL

https://github.com/asciidoctor/jekyll-asciidoc

Jekyll で画像を記事と同じフォルダに置く

Fri, 21 Mar 2025 00:00:00 +0900

Jekyll では画像などは assets 配下に置くのが普通で、_post などに置いてもその中の画像は _site には出力されません。

しかし、記事内からのみ参照する画像は記事と同じフォルダにあったほうが管理しやすいです。これについては、jekyll-postfiles というプラグインを使うことで解決できました。

https://nhoizey.github.io/jekyll-postfiles/

インストール方法は、Gemfile に以下を追記するだけです。

group :jekyll_plugins do
 gem 'jekyll-postfiles'
end

参考 URL

https://nhoizey.github.io/jekyll-postfiles/

Jekyll で Minimal Mistakes のテーマを適用する

Thu, 19 Dec 2024 00:00:00 +0900

いろいろテーマを探してみましたが、多機能かつドキュメントが充実していたのでこれにしてみました。

以下の記事で作成した環境に対して適用します。

https://kuttsun.blogspot.com/2024/09/jekyll-docker.html

尚、デモページ、およびドキュメントは以下です。

テーマの適用

Gemfile に以下を追加します。

gem "minimal-mistakes-jekyll"

_cofig.yml でテーマを指定します。

theme: minimal-mistakes-jekyll

必要に応じて各記事のレイアウトを変更します。

layout: single

選択できるレイアウトについては以下を参照してください。

https://mmistakes.github.io/minimal-mistakes/docs/layouts/

テーマを適用するだけならこれだけで OK でした。

その他の設定

公式のドキュメントに詳しく書かれているので、ここでは個人的に必要なものだけ抜粋して記載します。

スキンを変更する

https://mmistakes.github.io/minimal-mistakes/docs/configuration/#skin

_config.yml に以下のように記述します。

minimal_mistakes_skin: "default"

記事内の目次を作成する

https://mmistakes.github.io/minimal-mistakes/docs/layouts/#table-of-contents

フロントマターで以下のように設定します。

---
toc: true
toc_label: "My Table of Contents"
toc_icon: "cog"
---

記事を広げる

https://mmistakes.github.io/minimal-mistakes/docs/layouts/#wide-page

記事を目次のスペースまで広げるには、フロントマターで以下を設定します。

classes: wide

ページの作成

_pages というフォルダを作成し、そこに記事を追加します。
_config.yml に以下を追加し、_pages フォルダのドキュメントを変換対象に指定します。

collections:
 pages:
 output: true

カテゴリごとの記事一覧ページを作成

https://mmistakes.github.io/minimal-mistakes/docs/layouts/#archive-layout

_pages に category-archive.md というファイルを作成し、以下のような内容を記述します。

---
title: "Posts by Category"
layout: categories
permalink: /categories/
author_profile: true
---

タグごとの記事一覧ページを作成

カテゴリとほぼ同じです。

https://mmistakes.github.io/minimal-mistakes/docs/layouts/#archive-layout

_pages に tag-archive.md というファイルを作成し、以下のような内容を記述します。

---
title: "Posts by Tag"
permalink: /tags/
layout: tags
author_profile: true
---

年ごとの記事一覧ページを作成

カテゴリとほぼ同じです。

https://mmistakes.github.io/minimal-mistakes/docs/layouts/#archive-layout

_pages に year-achive.md というファイルを作成し、以下のような内容を記述します。

---
title: "Posts by Year"
permalink: /year-archive/
layout: posts
author_profile: true
---

サイドバーを作成する

_data/navigation.yml を作成し、以下のような内容を記述します。

docs:
 - title: Getting Started
 children:
 - title: "Quick-Start Guide"
 url: /docs/quick-start-guide/
 - title: "Structure"
 url: /docs/structure/
 - title: "Installation"
 url: /docs/installation/
 - title: "Upgrading"
 url: /docs/upgrading/

 - title: Customization
 children:
 - title: "Configuration"
 url: /docs/configuration/
 - title: "Navigation"
 url: /docs/navigation/
 - title: "UI Text"
 url: /docs/ui-text/
 - title: "Authors"
 url: /docs/authors/
 - title: "Layouts"
 url: /docs/layouts/

 - title: Content
 children:
 - title: "Working with Posts"
 url: /docs/posts/
 - title: "Working with Pages"
 url: /docs/pages/
 - title: "Working with Collections"
 url: /docs/collections/
 - title: "Helpers"
 url: /docs/helpers/
 - title: "Utility Classes"
 url: /docs/utility-classes/

 - title: Extras
 children:
 - title: "Stylesheets"
 url: /docs/stylesheets/
 - title: "JavaScript"
 url: /docs/javascript/

サイドバーを表示させたい記事のフロントマターに以下を追加します。

sidebar:
 nav: "docs"

全ての記事に表示したい場合は、_config.yml で以下のようにデフォルト値を設定します。

defaults:
 - scope:
 path: ""
 values:
 sidebar:
 nav: "docs"
 show_date: true

画面上部にナビゲーションを作成する

https://mmistakes.github.io/minimal-mistakes/docs/navigation/

_data/navigation.yml を作成し、以下のような内容を記述します。

main:
 - title: "Quick-Start Guide"
 url: /docs/quick-start-guide/
 - title: "Posts"
 url: /year-archive/
 - title: "Categories"
 url: /categories/
 - title: "Tags"
 url: /tags/
 - title: "Pages"
 url: /page-archive/
 - title: "Collections"
 url: /collection-archive/
 - title: "External Link"
 url: https://google.com
 target: _blank

記事に投稿日を表示

https://mmistakes.github.io/minimal-mistakes/docs/configuration/#post-dates

_config.yml に以下を設定します。

defaults:
 - scope:
 path: ""
 type: posts
 values:
 show_date: true

投稿日のフォーマットを指定

https://mmistakes.github.io/minimal-mistakes/docs/configuration/#post-dates

_config.yml で以下のように設定します。

date_format: "%Y-%m-%d"

コードブロックにコピーボタンを付ける

https://mmistakes.github.io/minimal-mistakes/docs/configuration/#code-block-copy-button

_config.yml に以下を設定します。

enable_copy_code_button: true

サイト内検索を有効にする

https://mmistakes.github.io/minimal-mistakes/docs/configuration/#site-search

_config.yml に以下を追加します。

search: true

検索エンジンは変更できるようです（上記リンク参照）。

パンくずリストの作成

参考 URL

https://gwenneg.com/2024/08/17/blogging-with-minimal-effort.html

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

asciidoctor-pdf で見出し前の改ページを無効にする

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

asciidoctor-pdf で PDF を作成したときに、見出しレベル２の前に改ページが自動挿入されて無駄に余白があるページがあったので、これを無効化する方法です。

PDF 作成時に指定するテーマファイルで設定します。

https://docs.asciidoctor.org/pdf-converter/latest/theme/heading/#chapter

これを踏まえ、heading-chapter で break-before を auto に指定すれば改ページが無効になりました。

heading:
 chapter:
 break-before: auto

ただ、auto なので、場合によっては改ページされる場合もあるかもしれません。

尚、上記の設定は doctype が book の場合のみ有効なようです。

参考 URL

https://docs.asciidoctor.org/pdf-converter/latest/theme/heading/#chapter

Asciidoc で include ディレクティブを使用している場合の画像へのパス

Thu, 26 Sep 2024 00:00:00 +0900

画像を読み込んでいるファイルを、別の階層にあるファイルから include ディレクティブで読み込むと、相対パスの位置が変わってしまいます。

画像を読み込んでいるファイルを単体で表示したときにはそのファイルからの相対パスになりますが、include しているファイルを表示したときには、include しているファイルからの相対パスになってしまいます。

同様のことで悩んでいる方はそれなりにいるようで、実際私もかなり困っています。

とりあえずの解決方法としては、私にとっては以下の方法が一番役に立ちました。

https://stackoverflow.com/questions/75919047/images-in-various-locations-in-included-asciidoc-files

ちょっと手間ですが、include 直前で imagedir を都度セットします。

:imagesdir: hoge
include::hoge/included_file.adoc

ただし、多重で include している場合は上記では上手くいきません。
この場合は、試行錯誤の結果、以下のようにすることで上手くいきました。

ifdef::imagesdir[:imagesdir: {imagesdir}/hoge]
ifndef::imagesdir[:imagesdir: hoge]

include::hoge/included_file.adoc

imagesdir が既に定義されている（＝別のファイルから include されている）場合は、現在の imagesdir に付加する形で imagesdir を再定義します。
imagesdir が定義されていない（＝別のファイルから include されていない）場合は、前述と同じように imagesdir を定義します。

参考 URL

https://stackoverflow.com/questions/75919047/images-in-various-locations-in-included-asciidoc-files

Jekyll で Asciidoc を使用する

Thu, 12 Sep 2024 00:00:00 +0900

markdown だけでなく asciidoc も使えたら便利なので。

以下の記事で作成した環境に対して asciidoc を使えるようにします。

https://kuttsun.blogspot.com/2024/09/jekyll-docker.html

調べたところ以下のプラグインを使えば出来そうだったので、これを使ってみます。

https://github.com/asciidoctor/jekyll-asciidoc

Gemfile の変更

ドキュメントの通りに、Gemfile に以下を追加します。

group :jekyll_plugins do
 gem 'jekyll-asciidoc'
end

_config.yml に以下を追加します。

plugins:
 - jekyll-asciidoc

尚、jekyll-asciidoc は他のプラグインより先に記述する必要があるそうです。
詳細は以下を参照してください。

https://github.com/asciidoctor/jekyll-asciidoc?tab=readme-ov-file#plugin-ordering

これで、_post フォルダ内に asciidoc で書いたドキュメントを追加すれば OK です。
ファイル名は Jekyll の決まりとして、YYYY-MM-DD-title.adoc のように日付が入っている必要があります。

https://jekyllrb-ja.github.io/docs/posts/

以下、サンプル通りに記事を作成してみました。

= Sample Page
:page-layout: post
:page-permalink: /sample/
:url-asciidoctor: https://asciidoctor.org

This is a sample page composed in AsciiDoc.
Jekyll converts it to HTML using {url-asciidoctor}[Asciidoctor].

[source,ruby]
puts "Hello, World!"

ただし、layuout は post に変更しています。
レイアウトについては以下。

https://qiita.com/a999/items/6c29ce072c19448ea579

これできちんと表示されることを確認しました。

include ディレクティブを使用するときの相対パス

asciidoc では include ディレクティブを使用して他の asciidoc ファイルを読み込むことができますが、このままやっても上手く描画されませんでした。
同様の内容が issue に挙がっていました。

https://github.com/asciidoctor/jekyll-asciidoc/issues/182

ベースディレクトリの設定がデフォルトではプロジェクトルートになっているので、ソースディレクトリとなるように設定すれば良さそうです。

https://github.com/asciidoctor/jekyll-asciidoc?tab=readme-ov-file#specifying-the-base-directory

_config.yml に以下を追記すれば上手くいきました。

asciidoctor:
 base_dir: :docdir
 safe: unsafe

参考 URL

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

[PySide] Windows で実行するとオーバーフローエラーが発生

Fri, 30 Aug 2024 00:00:00 +0900

PySide6 で作成したアプリを Pyinstaller で exe 化して実行すると、オーバーフローのエラーが発生しました。

エラーの内容は以下です。

OverflowError: Python int too large to convert to C long

該当箇所のコードは、以下のように QLineChart を使ってグラフを作成している箇所でした。

series = QLineSeries()

# 省略...

qdt = QDateTime()
qdt.setSecsSinceEpoch(int(dt.timestamp()))

series.append(qdt.toMSecsSinceEpoch(), count)

toMSecsSinceEpoch() はエポックタイムをミリ秒で返す関数です。
これを append 関数に渡すと、32bit の範囲を超えているとしてエラーが発生していました。

ビルド環境も実行環境も 64bit なのに、何故 32bit の long int として扱われているのか？
調べてみたところ、以下の記事に辿り着きました。

https://stackoverflow.com/questions/72568201/why-overflowerror-occured-only-on-pyside6

どうやら float でキャストすれば良さそうということで、以下のように修正したところ、正常に動作するようになりました。

series.append(float(qdt.toMSecsSinceEpoch()), count)

参考 URL

https://stackoverflow.com/questions/72568201/why-overflowerror-occured-only-on-pyside6

[python] pipenv で無関係のパッケージが勝手にアップデートされる

Wed, 17 Jul 2024 00:00:00 +0900

pipenv でパッケージをインストールしたときに、全く関係ないパッケージが勝手にアップデートされて困ったことがありました。

--keep-outdated を付与すればいいという情報もありますが、現在の pipenv ではこのオプションは削除されています。

とりあえず以下のようにして回避しました。

1. Pipfile 内の全てのパッケージのバージョンを指定

Pipfile をエディタで開き、でバージョンを指定していなかったパッケージに全てバージョンを記入しました。
バージョンは、Pipfile.lock を参照して、現在インストールされているバージョンを記入しました。

2. すべてのパッケージをアンインストール

$ pipenv uninstall --all

3. Pipfile.lock を削除

$ rm Pipfile.lock

4. 新しい依存関係をインストール

$ pipenv install

参考 URL

Shotcut でフリーズフレームを入れる

Sat, 06 Jul 2024 00:00:00 +0900

動画編集ソフトの Shotcut にはフレーズフレーム機能はありませんが、以下のようにすることで簡単にフリーズフレームを入れることができます。

環境

Shotcut 24.06.26

図中の動画は以下のサイトから適当にダウンロードしてきました。

https://pixabay.com/ja/

やり方

フリーズフレームを入れたい場所に再生ヘッドを移動し、「再生ヘッドで分割する」を選択します。

「ファイル > 書き出し > フレーム」で、フレームを静止画としてエクスポートします。

エクスポートした静止画を取り込み、それを分割した動画の間に挿入します。

あとは、挿入した静止画を選択し、右クリックして「プロパティ」を開き、長さを変更します。

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 がそのサブプロセスとして実行されます。そのため、正しくプロセスが管理されない可能性があり、コンテナの再起動時にデータがクリアされる可能性があります。

[PySide] qasync を使って非同期処理をバックグランドで行う

Mon, 22 Apr 2024 00:00:00 +0900

PySide6 で GUI アプリを作成している中で、I/O バウンドな処理の完了を待っていると GUI が固まりました。

通常、バックグラウンドで何か処理を行う際に GUI の処理を止めないようにするために、QThread などを使って別スレッドで処理を行いつつ GUI スレッドを回したりします。
今回もそうやって作っていたのですが、完了までに時間のかかる I/O バウンドな処理を行わせたい場合、上手くいかない場合がありました。 I/O バウンドな処理なので、ayncio を使って非同期処理にしてやればいいと思ったのですが、Qt のイベントループと asyncio を適切に統合する必要があるようで、どのように記述すればいいのかいまいち分かりませんでした。

そんな中、qasync というライブラリを使えば、とても簡単に処理を組み込むことができました。

https://github.com/CabbageDevelopment/qasync

コードの記述も、QThread を使う場合に比べシンプルでスッキリします。

ちなみに、asyncqt というライブラリもありますが、こちらは既にメンテナンスされていないようです。 qasync は asyncqt のフォークで、現在でもメンテナンスされているようなので、使うなら qasync のほうが良いと思います。

環境

python 3.11
pyside6 6.6.3.1
qasync 0.27.1

サンプルコード

import sys
import asyncio
from PySide6.QtWidgets import QApplication, QMainWindow, QPushButton, QVBoxLayout, QWidget, QLabel
from qasync import QEventLoop, asyncSlot

class MainWindow(QMainWindow):
 def __init__(self):
 super().__init__()
 self.setWindowTitle("qasync sample")

 self.label = QLabel("Press the button.", self)
 self.button = QPushButton("Start", self)
 self.button.clicked.connect(self.on_button_clicked)

 layout = QVBoxLayout()
 layout.addWidget(self.label)
 layout.addWidget(self.button)

 container = QWidget()
 container.setLayout(layout)
 self.setCentralWidget(container)

 @asyncSlot()
 async def on_button_clicked(self):
 self.label.setText("waiting...")
 self.button.setEnabled(False)

 # I/O バウンドな処理を想定
 await asyncio.sleep(5)

 self.label.setText("Press the button.")
 self.button.setEnabled(True)

if __name__ == "__main__":
 app = QApplication(sys.argv)
 loop = QEventLoop(app)
 asyncio.set_event_loop(loop)
 window = MainWindow()
 window.show()
 with loop:
 loop.run_forever()

参考 URL

- https://github.com/CabbageDevelopment/qasync

Ubuntu のユーザー名を変更する

Tue, 02 Apr 2024 00:00:00 +0900

Ubuntu 20.04 で確認しました。

新しいユーザーを作成する

ログインユーザー自身のユーザー名は変更できないので、一時的に管理者権限を持ったユーザーを作成します。

Ubuntu の場合は以下のように GUI で簡単に追加できます。

設定 > ユーザー > ユーザーを追加

ユーザー名とグループ名の変更

作成した新しいユーザーでログインして行います。

ユーザー名の変更

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

$ sudo usermod -l new_username -d /home/new_username -m old_username

尚、usermod コマンドの -g オプションでグループ名も一緒に変更できるような記述も見つけましたが、私の場合、usermod: グループ 'new_username' は存在しません のエラーが表示されてできなかったため、ユーザー名とグループ名の変更を分けて行いました。

グループ名の変更

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

$ sudo groupmod -n new_username old_username

以上で、変更後のユーザーでログインして問題なく使えることを確認しました。
ただ、唯一、ユーザーのアイコン画像だけがクリアされていました。

参考 URL

[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

YOLOv8 を動かそうとしたら ImportError: libGL.so.1: cannot open shared object file: No such file or directory のエラーが出た

Wed, 28 Feb 2024 00:00:00 +0900

python で YOLOv8 を動かそうとしたら以下のエラーが出ました。

from ultralytics import YOLO

Traceback (most recent call last):
 File "/workspace/yolov8/test1.py", line 1, in <module>
 from ultralytics import YOLO
 File "/usr/local/lib/python3.11/site-packages/ultralytics/__init__.py", line 5, in <module>
 from ultralytics.data.explorer.explorer import Explorer
 File "/usr/local/lib/python3.11/site-packages/ultralytics/data/__init__.py", line 3, in <module>
 from .base import BaseDataset
 File "/usr/local/lib/python3.11/site-packages/ultralytics/data/base.py", line 12, in <module>
 import cv2
 File "/usr/local/lib/python3.11/site-packages/cv2/__init__.py", line 181, in <module>
 bootstrap()
 File "/usr/local/lib/python3.11/site-packages/cv2/__init__.py", line 153, in bootstrap
 native_module = importlib.import_module("cv2")
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: libGL.so.1: cannot open shared object file: No such file or directory

このエラーは、OpenCV が GPU の OpenGL ライブラリを見つけられないことが原因で起きているエラーのようです。

YOLOv8 (ultralytics) をインストールすると依存関係にある OpenCV もインストールされるようですが、以下のページによれば、検出結果の可視化などを行ったりする場合のみ OpenCV が必要で、他のコア機能は OpenCV に依存しないとあります。

しかし、私の場合、検出結果の可視化とか何もしていない、というかそもそも最初の import 文のところでエラーになってしまっています。

尚、opencv-python ではなく、opencv-python-headless をインストールすれば解決できる場合もあるそうですが、私の場合、それでも上記のエラーが発生しました。

仕方がないので、OpenGL のライブラリをインストールして解決しました。

$ sudo apt update
$ sudo apt install -y libgl1-mesa-glx libglib2.0-0

参考 URL

[Python] Iris データセットを Pandas で読み込む

Wed, 21 Feb 2024 00:00:00 +0900

機械学習のサンプルデータとしてよく使われるものの一つに Iris（アヤメ）のデータセットがあります。その読み込み方法です。

Iris のデータセットを取得する方法自体はいくつかあるようです。

https://py-memo.com/python/load-iris/

今回は Iris のデータは機械学習用の定番のライブラリである scikit-learn を使いました。

サンプルコード

import pandas as pd
from sklearn.datasets import load_iris

iris = load_iris()
df_iris = pd.DataFrame(iris.data, columns=iris.feature_names)

# 目的変数である花の種類（target）のカラムを作成（花の種類を数値から文字列に変換して追加）
df_iris['target'] = iris.target_names[iris.target]

print(df_iris)

 sepal length (cm) sepal width (cm) petal length (cm) petal width (cm) target
0 5.1 3.5 1.4 0.2 setosa
1 4.9 3.0 1.4 0.2 setosa
2 4.7 3.2 1.3 0.2 setosa
3 4.6 3.1 1.5 0.2 setosa
4 5.0 3.6 1.4 0.2 setosa
.. ... ... ... ... ...
145 6.7 3.0 5.2 2.3 virginica
146 6.3 2.5 5.0 1.9 virginica
147 6.5 3.0 5.2 2.0 virginica
148 6.2 3.4 5.4 2.3 virginica
149 5.9 3.0 5.1 1.8 virginica

[150 rows x 5 columns]

load_iris 関数で呼び出されたデータセットは numpy 形式です。
これを扱いやすいように Pandas でデータフレームに変換しています。
また、load_iris 関数では、説明変数は iris.data、目的変数は iris.target に実装されています。
カラム名は iris.feature_names に入っています。

iris.target は花の種類を数値として保持しており、その数値に対応した花の名前は iris.target_names に定義されています。
花の種類をカラムに追加する際には文字列に変換して追加しています。

参考 URL

WSL で使用しているディスクスペースを解放する

Tue, 20 Feb 2024 00:00:00 +0900

WSL 上の Ubuntu で docker を使っていたのですが、ストレージの空き容量が少なくなってきたので docker イメージを削除しても空き容量が変化しませんでした。

調べてみたところ、どうやら仮想ディスクの最適化まで行わないとディスクスペースは解放されないようです。

ただ、私の PC はストレージ容量が少なく、頻繁に Docker イメージを消して容量を確保しているため、都度コマンドを打つのは面倒ということで、スクリプト化しました。

コマンドとしては、diskpart を使う方法と、Optimize-VHD を使う方法があるみたいですが、Optimize-VHD は Hyper-V を有効化する必要があり、Windows Home では使えないということで、今回は diskpart を使うことにしました。

diskpart でスクリプトを実行する方法は以下に記載されています。

https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/diskpart-scripts-and-examples

サンプル

まずは diskpart で実行するスクリプトを作成します（ここでは sample.txt としました）。

select vdisk file="%USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk

file のパスは環境によって異なると思うので、以下を参考に調べてください。

https://01futabato10.hateblo.jp/entry/2022/12/02/095031

そのうえで、以下のバッチファイルを作成します。

wsl --shutdown
diskpart /s sample.txt

あとはこのバッチファイルを実行するだけで OK です。

参考 URL

[python] ONVIF 対応カメラの RTSP 接続文字列を取得する

Thu, 15 Feb 2024 00:00:00 +0900

ネットワークカメラの映像を取得するためにまず RTSP の接続文字列を取得する必要があったので、ONVIF の Profile S から取得してみました。

ONVIF Profile S の仕様は以下にあります。

https://www.onvif.org/profiles/specifications/

尚、単純に RTSP の接続文字列を取得したいだけなら ONVIF Device Manager というツールがあるので、それを使ったほうが楽です。

環境

python 3.11
onvif-zeep 0.2.12
onvif2-zeep 0.3.4

ONVIF クライアントの python 実装である onvif-zeep onvif2-zeep を使ってみました。
この２つの違いですが、以下のページによれば、onvif2-zeep のほうは WSDL と H.265 に対応しているようです。

https://pypi.org/project/onvif2-zeep/

以下、onvif-zeep onvif2-zeep それぞれのサンプルコードです。

onvif-zeep でのサンプル

準備

pip install onvif-zeep

サンプルコード

from onvif import ONVIFCamera

def get_all_rtsp_urls(camera_ip, username, password):
 # ONVIFデバイスに接続
 camera = ONVIFCamera(camera_ip, 80, username, password)

 # プロファイルを取得
 media = camera.create_media_service()
 profiles = media.GetProfiles()
 #print(profiles)

 # すべてのプロファイルに対して RTSP URL を取得
 for profile in profiles:
 name = profile['Name']
 try:
 token = profile['token']
 stream_uri = media.GetStreamUri({
 'StreamSetup': {
 'Stream': 'RTP-Unicast',
 'Transport': {
 'Protocol': 'RTSP'
 }
 },
 'ProfileToken': token
 })
 uri = stream_uri.Uri
 print(f'{name}: {uri}')
 except Exception as e:
 print(f'{name}: {e}')

if __name__ == "__main__":
 camera_ip = "192.168.0.1"
 username = "username"
 password = "password"

 get_all_rtsp_urls(camera_ip, username, password)

onvif2-zeep のサンプル

準備

pip install onvif2-zeep

WSDL のダウンロード

onvif2-zeep を使用する場合、WSDL のファイル一式が必要なようです。
以下のリポジトリからダウンロードできます。

https://github.com/onvif/specs

サンプルコード

上記のコードから以下の２箇所を変更するだけです。

from onvif2 import ONVIFCamera

...

camera = ONVIFCamera(camera_ip, 80, username, password, './wsdl')

ONVIFCamera の引数の最後で、WSDL ファイルのあるパスを指定します。

実行結果

Panasonic のカメラで試した結果が以下となります。

H264_1280x960: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile8
H264_800x600: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile7
H264_640x480: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile6
H264_320x240: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile5
JPEG_1280x960: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile4
JPEG_800x600: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile3
JPEG_640x480: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile2
JPEG_320x240: rtsp://192.168.0.1/ONVIF/MediaInput?profile=1_def_profile1

ただ、H.265 のストリームがあるカメラ場合、onvif-zeep onvif2-zeep のどちらで試しても以下のように Unknown error: Configuration not complete のエラーが出て取得することができませんでした。

H26x_1: Unknown error: Configuration not complete
H26x_2: Unknown error: Configuration not complete
JPEG_1: rtsp://192.168.0.1/ONVIF/MediaInput?profile=def_profile5
JPEG_2: rtsp://192.168.0.1/ONVIF/MediaInput?profile=def_profile6

カメラ側のプロファイル設定の問題のような気がしますが、よくわかりませんでした。

ちなみに、他に TOA のカメラも試しましたが、こちらは H.265 の場合でも問題なく取得することができました。

参考 URL

https://www.onvif.org/profiles/specifications/

Gymnasium の環境を動かしてみる

Mon, 12 Feb 2024 00:00:00 +0900

強化学習について勉強しようと思い、まずはサンプルとしてよく取り上げられる OpenAI の gym の CartPole などを動かそうとしてみたところ、上手く動きませんでした。
調べてみたところ、gym は現在ではもう更新されておらず、代わりに gym を fork した gymnasium というのがあるようなので、こちらを使って動かしてみました。

実行環境は docker を使って構築します。
とりあえず学習・推論はせず、単純に動かすだけです。

環境

WSL2(Ubuntu 22.04)
docker 24.0.7
python 3.11
swig 4.2.0
gymnasium 0.29.1

Dockerfile

FROM python:3.11

# 先に swig をインストールしておかないと gymnasium のインストールに失敗しました
RUN pip install swig
RUN pip install gymnasium[box2d]

CMD [ "/bin/bash" ]

コンテナの起動

GUI を動かすので、コンテナは以下のように起動します。

docker run -it --rm \
 -v $(pwd)/workspace:/workspace \
 -v /etc/group:/etc/group:ro \
 -v /etc/passwd:/etc/passwd:ro \
 -u $(id -u $USER):$(id -g $USER) \
 -e DISPLAY \
 -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
 --workdir /workspace \
 imagename

これについては以下が参考になりました。

https://qiita.com/Spritaro/items/f907a9b52cb78e4fbec0

CartPole のサンプル

import gymnasium as gym

# 環境を作成
# render_mode は描画モードの指定。human は人間が見てわかるように動画として表示するという意味
env = gym.make("CartPole-v1", render_mode="human")

for episode in range(10):
 # 環境をリセット
 observation, info = env.reset()
 step = 0
 while True:
 # 行動をランダムに選択
 action = env.action_space.sample() # これがエージェントの行動になるので、本来はAIが行動を決定するべきところ
 # 選択した行動を実行
 observation, reward, terminated, truncated, info = env.step(action)
 #print(env.render()) # 状態の可視化(human の場合は不要)
 # 終了した場合、次のエピソードへ
 if terminated or truncated:
 print(f"Episode{episode+1} finished after {step+1} timesteps")
 break
 step += 1
env.close()

LunarLander のサンプル

同様に以下のようにして LunarLander も動きました。

import gymnasium as gym

# 環境を作成
# render_mode は描画モードの指定。human は人間が見てわかるように動画として表示するという意味
env = gym.make("LunarLander-v2", render_mode="human")

for episode in range(10):
 # 環境をリセット
 observation, info = env.reset()
 step = 0
 while True:
 # 行動をランダムに選択
 action = env.action_space.sample() # これがエージェントの行動になるので、本来はAIが行動を決定するべきところ
 # 選択した行動を実行
 observation, reward, terminated, truncated, info = env.step(action)
 #print(env.render()) # 状態の可視化(human の場合は不要)
 # 終了した場合、次のエピソードへ
 if terminated or truncated:
 print(f"Episode{episode+1} finished after {step+1} timesteps")
 break
 step += 1

env.close()

FrozenLake のサンプル

同様に以下のようにして FrozenLake も動きました。

import gymnasium as gym

# 環境を作成
# render_mode は描画モードの指定。human は人間が見てわかるように動画として表示するという意味
env = gym.make("FrozenLake-v1", render_mode="human")

for episode in range(10):
 # 環境をリセット、現在の観測値（observation）と情報（info）を取得
 observation, info = env.reset()
 step = 0
 while True:
 # 行動をランダムに選択
 action = env.action_space.sample() # これがエージェントの行動になるので、本来はAIが行動を決定するべきところ
 # 選択した行動を実行
 observation, reward, terminated, truncated, info = env.step(action)
 #print(env.render()) # 状態の可視化(human の場合は不要)
 # 終了した場合、次のエピソードへ
 if terminated or truncated:
 print(f"Episode{episode+1} finished after {step+1} timesteps")
 break
 step += 1
env.close()

参考 URL

Windows と Ubuntu でマウスとキーボードを共有する

Fri, 26 Jan 2024 00:00:00 +0900

Barrier というソフトを使って、マウスとキーボードを共有します。

環境

Windows 10
- barrier 2.4.0
Ubuntu 20.04
- barrier 2.3.2

Barrier を使う場合、どちらかをサーバーとして設定する必要がありますが、今回は Windows をサーバーとしました。

Windows 側

インストール

GitHub の Releases から最新の exe をダウンロードしてインストールします。
Bonjourというソフトをインストールするかどうか聞かれますが、インストールしませんでした。

設定

「サーバー」にチェックを入れる
「サーバーの構成設定」を選択し、「モニタの結びつき」で任意のマスをクリックして、クライアント側のモニターを追加する
- モニター名を後述のクライアント側の名前に合わせて入力する
メニューバーから、「Barrier > 設定の変更」を選択し、「SSL を使用」のチェックを外す。
開始を押す

Ubuntu 側

インストール

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

$ sudo apt install barrier

設定

「クライアント」にチェックを入れる
「サーバーIP」にIPアドレスを入力する
メニューバーから、「Barrier > Change Settings」を選択し、「Enable SSL」のチェックを外す。
開始を押す

追加の設定

ログイン画面（ロック画面）になるとマウスとキーボードが効かなくなるので、以下の設定も行いました。

Windows (サーバー) 側

Barrier の設定で、権限昇格を「常に」に変更しました。
恐らくセキュリティ的によろしくないので、やるなら自己責任でお願いします。

Ubuntu (クライアント) 側

Ubuntu 20.04 を使用している場合、GNOME デスクトップ環境がデフォルトで採用されているため、GDM (GNOME Display Manager) の設定を変更しました。

まず、GDMの設定ファイルを開きます。

sudo nano /etc/gdm3/custom.conf

[daemon] セクションに以下を追加します。

[daemon]
Greeter-setup-script=/usr/bin/numlockx on

変更を有効にするためにGDMを再起動します。

sudo service gdm restart

ただし、セキュリティ的にはよろしくないので、やるなら自己責任でお願いします。

参考 URL

GitLab Pages でディレクトリ一覧を表示したい

Mon, 25 Dec 2023 00:00:00 +0900

GitLab Pages で公開しているサイトにアクセスしたときに、配下ディレクトリの一覧を表示させる方法です。

GitLab 12.8 までは nginx の autoindex を有効にして index of で表示させることができたようですが、セキュリティの観点からその機能は削除されたそうです。

なので、どうにかしてインデックスページを作成し、GitLab Pages に公開するしかありません。例えば、Hugo や Jekyll で Sitemap やインデックスページの自動生成機能を使う方法があるようです。

ただ、今回私はシェルスクリプトファイルで作成することにしました。

以下、サンプルです。

#!/bin/bash

# 公開ディレクトリ内のディレクトリ一覧を取得
dirs=(public/*/)

# HTMLで一覧を表示するための変数
list="<ul>"

# ディレクトリのHTMLリストを生成
for d in "${dirs[@]}"; do
 # フォルダ一覧のみに制限するため、publicディレクトリ内のサブディレクトリのみを対象としています。
 dir=$(echo $d | sed -e 's/public\///' -e 's/\///')
 list="$list<li><a href='$dir'>$dir</a></li>"
done

list="$list</ul>"

# index.htmlファイルを作成
title="タイトル"
cat > public/index.html << EOF
<!DOCTYPE html>
<html>
 <head>
 <meta charset="UTF-8">
 <title>$title</title>
 </head>
 <body>
 <h1>$title</h1>
 $list
 </body>
</html>
EOF

これを、.gitlab-ci.yml の script の最後に実行すれば OK です。

上記はディレクトリに限定していますが、応用でファイル一覧を出力できると思います。

GitLab Pages でブランチ毎にディレクトリを分けて公開したい

Wed, 20 Dec 2023 00:00:00 +0900

mkdocs で作成したサイトを GitLab Pages で公開していたのですが、これをブランチ毎にディレクトリを分けて公開するようにしました。

基本的には、キャッシュを有効にするだけで可能です。
各ブランチでの成果物も一緒に Pages で公開したいため、キャッシュのキーは固定値にします。
以下、 .gitlab-ci.yml の抜粋です。

pages:
 stage: build
 script:
 - mkdocs build
 - rm -rf public/${CI_COMMIT_REF_NAME}
 - mv site public/${CI_COMMIT_REF_NAME}
 artifacts:
 paths:
 - public
 cache:
 # ブランチ毎に別のキャッシュを利用したい場合はブランチ名をキーにするが、
 # 今回は全ブランチのビルド結果も一緒に公開したいため、キーは全ブランチで共通の固定値にする
 key: "common-key"
 #key: "$CI_COMMIT_REF_NAME"
 paths:
 - public

site ディレクトリが mkdocs の成果物が入っているディレクトリですが、これを public/ブランチ名 に配置しています。

注意点

デフォルトでは、保護されたブランチと保護されていないブランチではキャッシュが共有されないため、この場合はプロジェクトの設定変更が必要です。
これを知らずに何度試してもキャッシュが共有されずはまっていました・・・。

https://gitlab-docs.creationline.com/ee/ci/caching/#use-the-same-cache-for-all-branches

変更する設定は以下です。

サイドメニューより、Settings > CI/CD を選択
General pipelines を開く
Use separate caches for protected branches のチェックボックスをオフにする
Save changes をクリックして保存

参考 URL

[Python] ModuleNotFoundError: No module named 'websockets.legacy' のエラーが出た

Fri, 01 Dec 2023 00:00:00 +0900

Python のアプリを Nuitka で実行ファイルにして動かすと、Websockets に関するエラーが出ました。

尚、python で実行したときには正常に動作しています。

環境

Python 3.11
Nuitka 1.9.2
Websockets 11.0.3

エラーの内容

具体的には以下のようなエラーが出ました。

Traceback (most recent call last):
 File "/foo/main.py", line 36, in subprocess
 File "/foo/asyncio/runners.py", line 190, in run
 File "/foo/asyncio/runners.py", line 118, in run
 File "/foo/asyncio/base_events.py", line 653, in run_until_complete
 File "/foo/websocket_manager.py", line 47, in run
 File "/foo/websocket_client.py", line 38, in run
 File "/foo/websockets/imports.py", line 77, in __getattr__
 File "/foo/websockets/imports.py", line 27, in import_name
ModuleNotFoundError: No module named 'websockets.legacy'

とりあえずの対処法

以下に同じエラーの報告がありました。

https://github.com/python-websockets/websockets/issues/974

上記を参考に以下のように変更すればとりあえず解決しました。

変更前

import websockets

async for websocket in websockets.connect(uri):

変更後

import websockets.client

async for websocket in websockets.client.connect(uri):

本来の解決方法

上記のコードですが、どうやらこれは古い記述方法みたいです。
最近の websockets (11.x 以降) では、接続の作成と処理は以下のように行うことを推奨しているようです。

import websockets

while True:
 try:
 async with websockets.connect(uri) as websocket:
 # メッセージ処理 
 except Exception:
 # ここに再接続ロジックなど 
 await asyncio.sleep(retry_delay)

ただし、これで今回のエラーが解決するかどうかは試していません。

参考 URL

https://github.com/python-websockets/websockets/issues/974

[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

[Python] Pyinstaller, Nuitka で作成した実行ファイルで GLIBC のエラーが発生する

Fri, 17 Nov 2023 00:00:00 +0900

pyinstaller, nuitka で作成した実行ファイルを別のマシンで実行するとエラーが出て動きませんでした。

具体的には以下のような GLIBC に関するエラーが表示されました。

Pyinstaller の場合

[10562] Error loading Python lib '/home/username/dist/main/libpython3.11.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /home/username/dist/main/libpython3.11.so.1.0)

Nuitka の場合

./sample.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./sample.bin)
./sample.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./sample.bin)
./sample.bin: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /home/username/main.dist/libpython3.11.so.1.0)
./sample.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/username/main.dist/libpython3.11.so.1.0)
./sample.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/username/main.dist/libpython3.11.so.1.0)
./sample.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/username/main.dist/libpython3.11.so.1.0)

これの回避策は、サポートしたいシステムより古いシステムでビルドを行うことだそうです。

私の場合、python:3.11 の Docker イメージを使ってビルドを行っていましたが、このイメージのディストリビューションは Debian 12 でした。そこでビルドした成果物を Ubuntu 20.04 のマシンで動かすと上記のエラーが発生しました。

なので、ビルドに使用する Docker イメージを python:3.11-buster に変更したところ、エラーなく動作するようになりました。

尚、buster というのは Debian のコードネームのことで、Debian 10 のことだそうです。
詳細は以下を参照してください。

https://www.debian.org/releases/index.ja.html

参考 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

[Python] pytest で motor のテストを行う

Mon, 13 Nov 2023 00:00:00 +0900

MongoDB 用の非同期ライブラリに motor を使用しており、pytest でテストコードを記述する際にモックをどうすればいいか悩みました。

当初は pymongo を使って同期的に使用していたため、MongoDB のモックには mongomock を使用していましたが、motor を使用する場合には mongomock-motor が使うとテストできました。

https://pypi.org/project/mongomock-motor/

インストール

pip install mongomock-motor

サンプルコード

上記のページにあるサンプルコードを pytest で実行する例です。

import pytest
from mongomock_motor import AsyncMongoMockClient

@pytest.mark.asyncio
async def test_mock_client():
 collection = AsyncMongoMockClient()['tests']['test-1']

 assert await collection.find({}).to_list(None) == []

 result = await collection.insert_one({'a': 1})
 assert result.inserted_id

 assert len(await collection.find({}).to_list(None)) == 1

参考 URL

https://pypi.org/project/mongomock-motor/

シェルスクリプトで sudo 権限で実行されているどうかをチェックする

Sun, 12 Nov 2023 00:00:00 +0900

id -u コマンドを使用して実行ユーザーの UID（ユーザーID）を確認することでチェックできます。

#!/bin/bash

# スクリプトをsudoで実行しているか確認
if [ "$(id -u)" -ne 0 ]; then
 echo "このスクリプトはsudoで実行する必要があります。"
 exit 1
fi

通常、root ユーザーの UID は 0 となります。

Rocket.Chat 移行後にアップロードファイルの URL が古いままになっている

Thu, 19 Oct 2023 00:00:00 +0900

Rocket.Chat を移行したのですが、アップロード済みファイルの URL と、サイト URL のリセット値が、移行前の古い URL のままになっていました。

概要

Rocket.Chat を移行し、ドメイン (サイトURL) が変わった
その際、Rocket.Chatを 3.10.14 から 6.2.12 にアップグレードしている
- MongoDB も 4.0 から 5.0 にアップグレード
Rocket.Chat 起動時に指定する環境変数 ROOT_URL は移行後の URL を設定済み
Rocket.Chat の管理者メニューで設定できる サイト URL も移行後の URL を設定済み

この状況で、以下の２つの不具合を確認しました。

アップロード済みのファイルの URL (ダウンロードリンク) が移行前の古い URL になっている
Rocket.Chat の管理者メニューで設定できる サイト URL について、リセットボタンを押すと移行前の古い URL がセットされる

先に結論

1. については MongoDB のデータを直接修正すれば直りました。
2. については未解決です。

MongoDB のデータを確認することにしたきっかけ

いろいろググっていく中で以下のページに辿り着きました。

https://www.ryadel.com/en/rocket-chat-change-root_url-site-url-rocketchat/

こちらの方法を試しても今回発生している不具合は直りませんでしたが、これをきっかけに MongoDB の中身を調査していくことで修正できました。

MongoDB の中身の確認方法については以下が参考になりました。

調査の過程と修正方法

Rocket.Chat と MongoDB は docker で動かしています。
なので、まず MongoDB の docker コンテナに入ります。

$ docker exec -it rocketchat-mongo bash

コンテナに入ったら MongoDB シェルを開き、rocketchat のデータベースを選択します。

# mongo
> use rocketchat

コレクションを表示してみます。

> show collections

たくさん表示されますが、ここから不具合内容に該当する箇所を推測して調査していきます。

1. アップロードファイルのダウンロードリンクについて

前述の 1. についてですが、こちらはアップロードファイルに関することなので、rocketchat_uploads の中身を表示してみました。

> db.rocketchat_uploads.find()

20件のみ表示されますが、適当なデータ一件について中身をみると以下のような感じになっていました。

{
 "_id": "27JzjqpXHxAHBzaxp",
 "name": "hoge.jpg",
 "size": 51268,
 "type": "image/jpeg",
 "rid": "MgKrXXN4XmQwtMMjgjXnWzpNvR6YrRpH4F",
 "userId": "jXnWzpNvR6YrRpH4F",
 "store": "GridFS:Uploads",
 "_updatedAt": ISODate("2023-07-26T03:58:50.233Z"),
 "instanceId": "R252ARSHBKR3RrXHY",
 "identify": {
 "format": "jpeg",
 "size": {
 "width": 495,
 "height": 700
 }
 },
 "complete": true,
 "etag": "HoMjiYj2fbb799RFK",
 "path": "/ufs/GridFS:Uploads/27JzjqpXHxAHBzaxp/%E5%90%8D%E7%A7%B0%E6%9C%AA%E8%A8%AD%E5%AE%9A%201.jpg",
 "progress": 1,
 "token": "68c8A8CAb8",
 "uploadedAt": ISODate("2023-07-26T03:58:50.852Z"),
 "uploading": false,
 "url": "http://old_domain:port/ufs/GridFS:Uploads/27JzjqpXHxAHBzaxp/%E5%90%8D%E7%A7%B0%E6%9C%AA%E8%A8%AD%E5%AE%9A%201.jpg",
 "typeGroup": "image"
}

見てわかる通り、url のフィールドにファイルへの絶対パスが記録されているため、これを修正しないと直らないんじゃないかと思いました。

というわけで、以下のコマンドでドメインの部分のみを置換します。

db.rocketchat_uploads.find().forEach(function(row) {
 row.url = row.url.replace(new RegExp("old_domain", 'g'), "new_domain");
 db.rocketchat_uploads.save(row);
});

これで Rocket.Chat のほうを確認すると、URL が直っていました。

2. サイト URL` のリセット値について

次に前述の 2. についてですが、設定に関することなので rocketchat_settings を確認してみました。こちらはついては中身を全てを見たかったので、以下のようにして json ファイルに出力して確認しました。

$ mongoexport -d rocketchat -c rocketchat_settings -o rocketchat_settings.json --type=json mongodb://localhost:27017

で、中身を確認してみましたが、それらしい設定は見当たりませんでした。
他のコレクションもいろいろ確認してみましたが、それらしい設定は見つかっていません。

というわけで未解決ですが、特に実害はないので放っておいてます。

参考 URL

Rocket.Chat のアップグレード手順

Wed, 11 Oct 2023 00:00:00 +0900

アップグレード手順については以下に記載されています。

https://docs.rocket.chat/deploy/deploy-rocket.chat/updating-rocket.chat

アップグレードのフローが以下になります。

https://whimsical.com/upgrade-version-path-rocket-chat-51eoS7aUunTan5wLt2CBHU

これに従ってアップデートしますが、いくつかはまったポイントがありました。

環境

アップグレード前のバージョンは以下です。

Rocket.Chat Version: 3.10.4
NodeJS Version: 12.18.4 - x64
MongoDB Version: 4.0.28
MongoDB Engine: wiredTiger
Platform: linux

Rocket.Chat も MongoDB も docker で動かしています。

Rocket.Chat 3.18.7 へのアップグレード

現在のバージョンが 3.10.4 なので、3系の最新の 3.18.7 にアップグレードしました。
すると、データベースバージョンのエラーが表示されたました。

+----------------------------------------------------------------------+
| |
| ERROR! SERVER STOPPED |
| |
| Your database migration failed: |
| Start date cannot be later than expire date |
| |
| Please make sure you are running the latest version and try again. |
| If the problem persists, please contact support. |
| |
| This Rocket.Chat version: 3.18.7 |
| Database locked at version: 213 |
| Database target version: 232 |
| |
| Commit: 660c9f5e896982932e1d02d35ddd6013c6b03e11 |
| Date: Mon May 30 19:06:57 2022 -0300 |
| Branch: HEAD |
| Tag: 3.18.7 |
| |
+----------------------------------------------------------------------+

対策は以下に書いてありました。

https://martinschoeler.github.io/docs/administrator-guides/database-migration/

MongoDB のコンテナに入り、以下のコマンドを実行してバージョンを強制的に一つ上げます。

# mongo
> use rocketchat
> db.migrations.update({_id: 'control'},{$set:{locked:false,version:231}})

これで Rocket.Chat を再起動すれば OK でした。

Rocket.Chat 3.18.7 から 4.8.7 へのアップグレード

次に4系の最新の 4.8.7 にアップグレードしました。
これはすんなりいきました。

MongoDB のアップグレード

上記のフローによれば、Rocket.Chat を5系にアップグレードする前に、MongoDB を 5.0 以上までアップグレードする必要があります。
方法については以下に記載されています。

https://docs.growi.org/ja/admin-guide/admin-cookbook/upgrade-mongodb.html

MongoDB 4.0 から 4.2 へのアップグレード

現在のバージョンが 4.0 なので、まずは 4.2 にアップグレードしました。これはすんなりいきました。

MongoDB 4.2 から 4.4 へのアップグレード

次に 4.4 にアップグレードしたところ、以下のようなエラーとなりました。

{"t":{"$date":"2023-10-13T00:38:13.842+00:00"},"s":"W", "c":"STORAGE", "id":22347, "ctx":"initandlisten","msg":"Failed to start up WiredTiger under any compatibility version. This may be due to an unsupported upgrade or downgrade."}
{"t":{"$date":"2023-10-13T00:38:13.842+00:00"},"s":"F", "c":"STORAGE", "id":28595, "ctx":"initandlisten","msg":"Terminating.","attr":{"reason":"95: Operation not supported"}}
{"t":{"$date":"2023-10-13T00:38:13.842+00:00"},"s":"F", "c":"-", "id":23091, "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":28595,"file":"src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp","line":958}}
{"t":{"$date":"2023-10-13T00:38:13.843+00:00"},"s":"F", "c":"-", "id":23092, "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"}

MongoDB を 4.2 に戻してコンテナに入り、以下のコマンドを実行します。

# mongo
> db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

これで Rocket.Chat を再起動すれば OK でした。

MongoDB 4.4 から 5.0 へのアップグレード

次に 5.0 にアップグレードしたところ、同様のエラーとなりました。
MongoDB を 4.4 に戻してコンテナに入り、以下のコマンドを実行します。

# mongo
> db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )

これで Rocket.Chat を再起動すれば OK でした。

Rocket.Chat 4.8.7 から 5.4.10 へのアップグレード

MongoDB を 5.0 までアップグレードしたので、次は Rocket.Chat を5系の最新の 5.4.10 にアップグレードしました。
すると以下のエラーが表示されました。

/app/bundle/programs/server/node_modules/fibers/future.js:313
 throw(ex);
 ^

MongoServerSelectionError: connect ECONNREFUSED 127.0.0.1:27017
 at Timeout._onTimeout (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/sdam/topology.js:312:38)
 at listOnTimeout (internal/timers.js:557:17)
 at processTimers (internal/timers.js:500:7) {
 reason: TopologyDescription {
 type: 'ReplicaSetNoPrimary',
 servers: Map(1) {
 'localhost:27017' => ServerDescription {
 _hostAddress: HostAddress { isIPv6: false, host: 'localhost', port: 27017 },
 address: 'localhost:27017',
 type: 'Unknown',
 hosts: [],
 passives: [],
 arbiters: [],
 tags: {},
 minWireVersion: 0,
 maxWireVersion: 0,
 roundTripTime: -1,
 lastUpdateTime: 17764280,
 lastWriteDate: 0,
 error: MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017
 at connectionFailureError (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connect.js:381:20)
 at Socket.<anonymous> (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connect.js:301:22)
 at Object.onceWrapper (events.js:520:26)
 at Socket.emit (events.js:400:28)
 at emitErrorNT (internal/streams/destroy.js:106:8)
 at emitErrorCloseNT (internal/streams/destroy.js:74:3)
 at processTicksAndRejections (internal/process/task_queues.js:82:21)
 }
 },
 stale: false,
 compatible: true,
 heartbeatFrequencyMS: 10000,
 localThresholdMS: 15,
 setName: 'rs0',
 maxSetVersion: 2,
 maxElectionId: ObjectId {
 [Symbol(id)]: Buffer(12) [Uint8Array] [
 127, 255, 255, 255, 0,
 0, 0, 0, 0, 0,
 0, 10
 ]
 },
 commonWireVersion: 13,
 logicalSessionTimeoutMinutes: undefined
 }
}

解決策は以下にありました。

https://github.com/RocketChat/Rocket.Chat/releases/tag/5.0.0

環境変数 MONGO_URL MONGO_OPLOG_URL に directConnection=true を追加します。
例えば、MONGO_URL=mongodb://mongo/rocketchat?replicaSet=rs0&directConnection=true のような感じです。

これで Rocket.Chat を再起動すれば OK でした。

Rocket.Chat を最新にアップデート

最後に、Rocket.Chat を現在の最新バージョンである 6.3.9 にアップグレードしました。以上で完了です。

[Python] OS の時刻（システムクロック）に影響を受けないように時間の計測を行う

Fri, 08 Sep 2023 00:00:00 +0900

time.monotonic() を使えば OK です。

元々、以下の様に time.time() を使って処理時間の計測を行っていたのですが、この場合、計測途中でシステムクロックが変更されてしまうと、計測時間も影響を受けてしまいます。

import time

start = time.time()

# この間にシステムクロックが変更されると計測時間にも影響を与える

elapsed_time = time.time() - start

# 過去に戻ると負の値に、未来に行くと大きな値になってしまう
print(elapsed_time)

time.monotonic() を使えばシステムクロックの影響を受けないので、純粋に処理にかかった実時間を計測できます。

参考 URL

https://docs.python.org/ja/3.10/library/time.html#time.monotonic

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

`ImportError: cannot import name '_compare_version' from 'torchmetrics.utilities.imports'` のエラーが出る

Mon, 21 Aug 2023 00:00:00 +0900

Stable Diffusion を動かそうとして以下のエラーが出ました。

ImportError: cannot import name '_compare_version' from 'torchmetrics.utilities.imports'
(/usr/local/lib/python3.8/site-packages/torchmetrics/utilities/imports.py)

以下に対策が載っており、torchmetrics を 0.11.4 にダウングレードすれば解決しました。

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

$ pip install torchmetrics==0.11.4

参考 URL

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

[VSCode] Markdown Preview Enhanced で HTML 出力する際にサイドバーの目次を入れる

Thu, 20 Jul 2023 00:00:00 +0900

ずっとやり方が分からなかったのですが、英語版のマニュアルにやり方が書いてありました。

サイドバーのTOCを生成するには、VSCode の Markdown Preview Enhanced の設定でスクリプトの実行を有効にする必要があります。

https://shd101wyy.github.io/markdown-preview-enhanced/#/html?id=configuration

尚、上記の情報は現時点の日本語版のマニュアルには書いてありませんでした。

https://shd101wyy.github.io/markdown-preview-enhanced/#/ja-jp/html?id=%e8%a8%ad%e5%ae%9a

環境

VSCode 1.80.1
Markdown Preview Enhanced v0.6.8

スクリプトの実行を有効にする

拡張機能の設定で enableScriptExecution で検索すると設定項目が表示されるのでチェックを入れます。

尚、有効にするとセキュリティリスクがありますので、その点ご注意ください。

html の出力

あとはマークダウンのプレビュー画面で右クリックし、HTML に出力するだけでサイドバーに目次が出力されます。
尚、デフォルトではサイドバーは閉じた状態となっていました。
マークダウン内に toc: true を記述すると、サイドバーが開いた状態となりました。

以下サンプルです。

---
html:
 toc: true
---

# 見出し1

## 見出し2

### 見出し3

### 見出し3

# 見出し1

## 見出し2

参考 URL

WSL でディストリビューションを削除して再インストール後に起動エラーになる

Fri, 14 Jul 2023 00:00:00 +0900

スタートメニューから Ubuntu 20.04 をアンインストールして、再度 MS ストアからインストールして起動しようとしたら以下のエラーが表示されました。

Error code: Wsl/Service/CreateInstance/MountVhd/ERROR_FILE_NOT_FOUND

まず、インストールされているディストリビューションを確認します。

> wsl -l
Linux 用 Windows サブシステム ディストリビューション:
Ubuntu-20.04 (既定)

アンインストールしたはずのディストリビューションが残っていると思うので、以下のコマンドで登録を解除します。

> wsl --unregister Ubuntu-20.04

これで、再度ディストリビューションを起動すれば OK です。

参考 URL

https://www.techgaku.com/fix-ubuntu-boot-error-on-wsl-after-reinstall/

Microsoft ストア版の WSL をインストールする

Thu, 06 Jul 2023 00:00:00 +0900

WSL について、Windows のコンポーネント（組み込み）として提供されているものと、Microsoft Store で提供されているものがあるのを知りました。

きっかけは、WSL2 上の Ubuntu で systemd を使おうとしたら使えなかったことで、調べていくと WSL 自体のバージョンが 0.67.6 以降だと systemd が使えることがわかりました。

WSL 自体のバージョンは以下のコマンドで確認できるらしいのですが、

> wsl --version

私の環境ではバージョンが表示されず、コマンドの説明が表示されてしまいました。

これは、どうやら WSL のバージョンが古いのが原因らしく、最新版は Microsoft Store からインストールできるらしいと。
ここで、2022年11月に正式版としてリリースされたストア版の WSL を知り、自分が使っていたのは「Windows の機能の有効化または無効化」からインストールしたコンポーネント版で、古いプレビュー版の WSL だということを知りました。

https://qiita.com/omu_kato/items/f9a6b5a02e25f5f2a487

ストア版の WSL は普通に Microsoft Store で検索すれば見つかるので、そこでインストールするだけです。

尚、既にコンポーネント版を使っていてもストア版をインストールして使えるようですが、私の環境では Ubuntu 22.04 を起動しようとすると Error code: Wsl/Service/CreateInstance/MountVhd/ERROR_FILE_NOT_FOUND のエラーが出てしまいました。

これについては、以下を参考に WSL から Ubuntu 22.04 の登録を解除すれば直りました。

https://www.techgaku.com/fix-ubuntu-boot-error-on-wsl-after-reinstall/

参考 URL

EasyTAG 2.4.3 で画像がある場合に mp3 ファイルのタグ書き込みに失敗する

Sun, 02 Jul 2023 00:00:00 +0900

Windows で EasyTAG 2.4.3 の場合に発生します。

いろいろ試しても上手くいかず悩んでいたのですが、以下に報告が上がっていました。

https://gitlab.gnome.org/GNOME/easytag/-/issues/5

2.4.2 にダウングレードすると問題なく書き込めました。

参考 URL

https://gitlab.gnome.org/GNOME/easytag/-/issues/5

systemd で環境変数を展開する

Wed, 14 Jun 2023 00:00:00 +0900

環境変数を参照する Python アプリを systemd でサービス化したときにかなりはまってしまいました。

systemd はユーザーの環境変数を参照しないようなので、ユニット定義ファイルで環境変数を設定する必要があるそうで、Environment で記述したり、外部ファイルに定義して EnvironmentFile で読み込む方法があるようです。

また、上記だと変数を展開することができないので、そのような場合には以下のように ExecStartPre で systemctl の set-environment を使う方法などがあるようです。

https://qiita.com/kobanyan/items/f8e8a3bd5406e1d290fb

ただ、今回の私の場合は、シェル変数 HOSTNAME を環境変数に export して参照したかったのですが、systemd にはホスト名を表す特殊な変数として %H があるようなので、これを使って以下のようにすれば解決できました。

[Unit]
Description=My Python App

[Service]
ExecStart=/path/to/your/python/app.py
Environment="HOSTNAME=%H"

[Install]
WantedBy=multi-user.target

参考 URL

VSCode で現在アクティブなタブの背景色を変更する

Mon, 12 Jun 2023 00:00:00 +0900

Visual Studio Code のエディタで現在アクティブなタブの背景色が、デフォルトだと他のタブとあまり変わらなくて分かりづらいので、設定で変更しました。

メニューより、ファイル > ユーザー設定 > 設定を選択します。

設定の検索より workbench.colorCustomizations と入力し、「settings.json で編集」をクリックします。

そして、以下のように tab.activeBackground を追記します。

"workbench.colorCustomizations": {
 "tab.activeBackground": "#1b77cf"
}

参考 URL

https://tekunabe.hatenablog.jp/entry/2021/05/23/134458

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

MongoDB と 2106 年問題

Tue, 23 May 2023 00:00:00 +0900

ボタン電池がなくなり、RTC が遥か未来になったときに MongoDB が動作しなくなりました。（正確には、Python アプリにおいて、MongoDB の初期化を行う際にエラーとなりました。）

MongoDB のバージョンは 6.0.5 です。

調べてみると、MongoDB の ObjectID は先頭の4バイトがタイムスタンプ(UNIX タイム)となっているそうです。
MongoDB はこれを符号なし整数として扱っていて、その場合の上限は 4,294,967,295 であり、これは UTC で2106年2月7日6時28分16秒となります。
というわけで、MongoDB はいわゆる 2106 年問題を孕んでいることになります。

https://www.wdic.org/w/TECH/2106%E5%B9%B4%E5%95%8F%E9%A1%8C

ちなみに、4バイトがタイムスタンプを符号付き整数として扱っている場合は 2038 年問題となります。

参考 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

[Python] SyslogHandler でログを送信したときに `Bad file descriptor` のエラーになる

Wed, 05 Apr 2023 00:00:00 +0900

SyslogHandler を使ってログを記録していたのですが、Bad file descriptor のエラーが表示されてはまってしまいました。

表示されたエラーは以下です。

Traceback (most recent call last):
 File "/usr/lib/python3.8/logging/handlers.py", line 940, in emit
 self.socket.sendto(msg, self.address)
OSError: [Errno 9] Bad file descriptor

アプリをマルチプロセスで動かしており、FastAPI ( +uvicorn) を使うとこのエラーが出るようになりました。

環境

Python 3.8.10

対処方法

調べても原因がさっぱりわからなかったのですが、最終的に以下のページにたどり着きました。

https://github.com/python/cpython/issues/87362

どうやら Python の logging モジュールの不具合のようで、Python のバージョンを 3.11 まで上げると直りました。

参考 URL

https://github.com/python/cpython/issues/87362

[Python] マルチプロセスにおけるロギング (QueueHandler, QueueListener)

Tue, 04 Apr 2023 00:00:00 +0900

SyslogHandler で UDP でログを記録していたのですが、マルチプロセスでは Socket 通信のところでエラーが発生しました。
マルチプロセスでのロギングでは、QueueHandler と QueueListner を使ってログを一箇所に集約して書き込むようにする必要があります。

環境

Python 3.8.10

基本的な書き方

とりあえずマルチプロセスは置いておいて、QueueHandler と QueueListener の基本的な使い方です。

import os
from multiprocessing import Queue
from logging import StreamHandler, handlers, basicConfig, getLogger, Formatter, DEBUG

# 標準出力の設定
stream_handler = StreamHandler()
stream_handler.setFormatter(Formatter('%(asctime)s [%(levelname)s] [%(name)s] %(message)s'))
# Syslog 出力の設定
syslog_handler = handlers.SysLogHandler(address=('localhost', 514))
syslog_handler.setFormatter(Formatter(f'{os.environ.get("HOSTNAME")} ris-main: %(message)s'))
# ファイル出力の設定
file_handler = handlers.TimedRotatingFileHandler('log/sample.log')
file_handler.setFormatter(Formatter(fmt='%(asctime)s.%(msecs)03d [%(levelname)s] [%(name)s] %(message)s', datefmt='%Y-%m-%d %H:%M:%S'))
# キューハンドラの設定
que = Queue()
queue_handler = handlers.QueueHandler(que)
basicConfig(level=DEBUG, handlers=[queue_handler])

# リスナーの作成と開始
queue_listener = handlers.QueueListener(que, *[stream_handler, syslog_handler, file_handler])
queue_listener.start()

logger = getLogger(__name__)

logger.info('this is info')
logger.debug('this is debug')
logger.critical('this is critical')

queue_listener.stop()

logger を使って書いたログは QueueHandler によりキューに入れられます。
QueueListner はキューに溜まったログを取り出して、StreamHandler SyslogHandler TimedRotatingFileHandler で記録されます。

尚、上記は basicConfig を使って設定していますので、ライブラリなどのロギングにも影響します（対処方法は後述）。

マルチプロセスで試してみた

上記を踏まえ、プロセスを３つ立ち上げ、各プロセス100回ログを記録させてみたサンプルが以下です。

import os
from multiprocessing import Process, Queue
from logging import StreamHandler, handlers, basicConfig, getLogger, Formatter, DEBUG

def hoge(index):
 logger = getLogger(__name__)

 for count in range(100):
 logger.info(f'({index}) this is info')
 logger.debug(f'({index}) this is debug')
 logger.critical(f'({index}) this is critical')

# 標準出力の設定
stream_handler = StreamHandler()
stream_handler.setFormatter(Formatter('%(asctime)s [%(levelname)s] [%(name)s] %(message)s'))
# Syslog 出力の設定
syslog_handler = handlers.SysLogHandler(address=('localhost', 514))
syslog_handler.setFormatter(Formatter(f'{os.environ.get("HOSTNAME")} ris-main: %(message)s'))
# ファイル出力の設定
file_handler = handlers.TimedRotatingFileHandler('log/sample.log')
file_handler.setFormatter(Formatter(fmt='%(asctime)s.%(msecs)03d [%(levelname)s] [%(name)s] %(message)s', datefmt='%Y-%m-%d %H:%M:%S'))
# キューハンドラの設定
que = Queue()
queue_handler = handlers.QueueHandler(que)
basicConfig(level=DEBUG, handlers=[queue_handler])

# リスナーの作成と開始
queue_listener = handlers.QueueListener(que, *[stream_handler, syslog_handler, file_handler])
queue_listener.start()

# プロセスの立ち上げ
processes = []
for i in range(3):
 p = Process(target=hoge, args=(i,))
 p.start()
 processes.append(p)

# プロセスの終了を待つ
for process in processes:
 try:
 process.join()
 except KeyboardInterrupt:
 process.join(1)

queue_listener.stop()

問題なくログが記録できていることが確認できました。

basicConfig を使わずに設定する

上述したように、basicConfig を使うとライブラリなどの全てのモジュールに影響するので、logger に対して設定を行うようにします。
ただ、そうなると都度設定を行う必要が出てくるので、以下のページを参考に共通の関数を作成しました。

http://joemphilips.com/post/python_logging/

ただし、QueueHandler を使う場合、キューを渡してやる必要があるので、それはグローバル変数として用意することにしました。
ここらへん、もっと良い実装方法はないかなぁとは思いますが・・・。

以下、サンプルです。

# mylogger.py
import multiprocessing
import logging
import logging.handlers

log_queue = multiprocessing.Queue()

def getLogger(modname) -> logging.Logger:
 """ 共通のロガーを作成するための関数
 logging.getLogger と簡単に差し替えられるように同じ関数名としておく
 """

 # キューハンドラの設定
 queue_handler = logging.handlers.QueueHandler(log_queue)
 logger = logging.getLogger(modname)
 logger.addHandler(queue_handler)
 logger.setLevel(logging.DEBUG)
 return logger

# main.py
import os
from logging import handlers, StreamHandler, Formatter, DEBUG, INFO
from mylogger import getLogger, log_queue

# 標準出力の設定
stream_handler = StreamHandler()
stream_handler.setFormatter(Formatter('%(asctime)s [%(levelname)s] [%(name)s] %(message)s'))
stream_handler.setLevel(DEBUG)
# Syslog 出力の設定
syslog_handler = handlers.SysLogHandler(address=('localhost', 514))
syslog_handler.setFormatter(Formatter(f'{os.environ.get("HOSTNAME")} ris-main: %(message)s'))
syslog_handler.setLevel(INFO)
# ファイル出力の設定
file_handler = handlers.TimedRotatingFileHandler('log/sample.log')
file_handler.setFormatter(Formatter(fmt='%(asctime)s.%(msecs)03d [%(levelname)s] [%(name)s] %(message)s', datefmt='%Y-%m-%d %H:%M:%S'))
file_handler.setLevel(INFO)

# リスナーの作成と開始
queue_listener = handlers.QueueListener(
 log_queue,
 *[stream_handler, syslog_handler, file_handler],
 respect_handler_level=True)
queue_listener.start()

logger = getLogger(__name__)

logger.info('this is info')
logger.debug('this is debug')
logger.critical('this is critical')

queue_listener.stop()

また、ここでは標準出力とそれ以外で、出力するログレベルを変えています。
この場合、QueueHandler の respect_handler_level を True にして、各ハンドラー側のレベルを優先するように設定してやる必要があります。

参考 URL

[PySide] QTimer の使い方

Tue, 28 Mar 2023 00:00:00 +0900

スレッドを使わずに定期的に GUI を更新するために、QTimer の使い方と挙動について簡単に調べてみました。

環境

Python 3.8.10
PySide 6.2.2.1

サンプルコード

import sys
import time
from datetime import datetime
from PySide6.QtCore import (QTimer, Signal)
from PySide6.QtWidgets import (QApplication, QWidget, QVBoxLayout, QLabel)


class MainWindow(QWidget):
 """メインウィンドウ
 """

 countup = Signal(int)

 def __init__(self, parent=None):
 super().__init__(parent)

 self.__count = 0

 layout = QVBoxLayout()
 self.__label = QLabel(self.__current_count())
 layout.addWidget(self.__label)
 self.setLayout(layout)

 self.__timer = QTimer(self)
 self.__timer.timeout.connect(self.__timeout)
 self.__timer.start(1000)
 self.__timer.singleShot(10000, self.__single_shot1)
 self.__timer.singleShot(15000, self.__single_shot2)

 def __timeout(self):

 self.__count += 1
 print(f'{datetime.now()}, {self.__count}')
 self.__label.setText(self.__current_count())
 #time.sleep(3)

 def __current_count(self) -> str:
 return f'現在のカウント: {self.__count}'

 def __single_shot1(self):
 print(f'{datetime.now()}, 10秒経過')

 def __single_shot2(self):
 print(f'{datetime.now()}, 15秒経過')

if __name__ == "__main__":
 app = QApplication(sys.argv)
 main_window = MainWindow()
 main_window.show()
 ret = app.exec()
 sys.exit(ret)

2023-03-27 14:04:40.166652, 1
2023-03-27 14:04:41.115886, 2
2023-03-27 14:04:42.066937, 3
2023-03-27 14:04:43.026873, 4
2023-03-27 14:04:44.026648, 5
2023-03-27 14:04:45.026877, 6
2023-03-27 14:04:46.026574, 7
2023-03-27 14:04:47.026898, 8
2023-03-27 14:04:48.026477, 9
2023-03-27 14:04:49.027008, 10秒経過
2023-03-27 14:04:49.027169, 10
2023-03-27 14:04:50.027045, 11
2023-03-27 14:04:51.026868, 12
2023-03-27 14:04:52.027034, 13
2023-03-27 14:04:53.026916, 14
2023-03-27 14:04:54.026824, 15秒経過
2023-03-27 14:04:54.027010, 15

処理に時間がかかった場合はどうなる？

上記のコードでは、1秒ごとに __timeout 関数が実行されますが、もしその中で処理に時間がかかったとしたらどうなるか？
試しに3秒のスリープを入れてみました（上記のコメントアウトを解除）。

2023-03-27 14:07:10.458991, 1
2023-03-27 14:07:13.462465, 2
2023-03-27 14:07:16.464238, 3
2023-03-27 14:07:19.467192, 4
2023-03-27 14:07:22.470589, 10秒経過
2023-03-27 14:07:22.471410, 5
2023-03-27 14:07:25.475184, 6
2023-03-27 14:07:28.478740, 15秒経過
2023-03-27 14:07:28.480526, 7
2023-03-27 14:07:31.484492, 8

3秒経過後、すぐに __timeout がコールされています。
前の処理が完了しないと次の処理は行われないようです。

参考 URL

Nginx の proxy_pass で名前解決されない

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

nginx を Docker コンテナとして動かしており、ホスト側へリバースプロキシを行おうとした際にはまってしまいました。

環境

docker 20.10.21
nginx 1.23.3

問題と対策

Docker コンテナ内からホストにアクセスする際には host.docker.internal を指定します。
これについては以下の記事を参照してください。

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

その上で、nginx の設定で以下のようにリバースプロキシの設定を行いました。

server {
 listen 80 default_server;
 server_name _;

 location /hoge {
 resolver 127.0.0.11 valid=30s;
 set $dummy_var http://host.docker.internal:5000;
 rewrite /hoge/(.*)$ /$1 break;
 proxy_pass $dummy_var;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

すると、以下のように名前解決できないというエラーが表示されました。

尚、コンテナ内に入って curl などを使ってテストすると、きちんと host.docker.internal の名前解決がされていました。
いろいろ調べてみると、どうやら proxy_pass では /etc/hosts が参照されないそうです。

どのように対応しようか悩んでいたところ、upstream の設定ではきちんと /etc/hosts が参照されるようでしたので、以下のように設定して回避することにしました。

upstream backends {
 server host.docker.internal:5000;
}

server {
 listen 80 default_server;
 server_name _;

 location /hoge {
 resolver 127.0.0.11 valid=30s;
 set $dummy_var http://backends;
 rewrite /hoge/(.*)$ /$1 break;
 proxy_pass $dummy_var;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

参考 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

Linux で端末にリアルタイムに日時を表示する

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

watch コマンドと date コマンドを組み合わせると簡単にできます。

例えば以下のような感じです。

$ watch -t -n 0.01 date +%T.%N

watch は引数で指定したコマンドを一定間隔ごとに繰り返し実行するコマンドです。
-t はヘッダを非表示にします。
-n はコマンドを実行する間隔（秒）です。
ここでは date コマンドを 0.01 秒ごとに実行しています。
+%T.%N は日時の書式です。
例えば、以下のようにすれば日付も表示されます。

$ watch -t -n 0.01 "date '+%Y/%m/%d %T.%N'"

書式にスペースを含む場合、シングルコーテーションやダブルコーテーションで括る必要があります。

参考 URL

[Python] asyncio.Queue の動きを確認してみた

Wed, 01 Feb 2023 00:00:00 +0900

put や get がコルーチンになっていたので、どういう動きになるのか確認してみました。

環境

Python 3.8.1

サンプルコード

import asyncio

async def put(q:asyncio.Queue):
 count = 0
 while count <= 100:
 print(f'({count}) before put')
 await q.put(count)
 print(f'({count}) after put')
 count += 1
 if count % 5 == 0:
 # 5回送ったらスリープ
 await asyncio.sleep(0.01)

async def get(q:asyncio.Queue):
 count = 0
 while count < 100:
 count = await q.get()
 print(f'({count}) get')

async def main():
 q = asyncio.Queue()
 await asyncio.gather(*[ put(q), get(q) ])

asyncio.run(main())

出力は以下のようになりました。

(0) before put
(0) after put
(1) before put
(1) after put
(2) before put
(2) after put
(3) before put
(3) after put
(4) before put
(4) after put
(0) get
(1) get
(2) get
(3) get
(4) get
(5) before put
(5) after put
(6) before put
(6) after put
(7) before put
(7) after put
(8) before put
(8) after put
(9) before put
(9) after put
(5) get
(6) get
(7) get
(8) get
(9) get

put したあと、sleep したところで制御が他に移っています。
get のほうは、キューの中身を全部取り終わって次のデータ待ちになったところで制御が他に移っています。

[Python] 同期処理を非同期化して扱う

Thu, 26 Jan 2023 00:00:00 +0900

async のついていない関数を非同期化して、async のついた非同期関数と同じように扱いたいというときの方法です。

環境

python 3.8.1

概要

同期関数を非同期化するには run_in_executor を使用します。

ただし、CPU バウンドな処理を非同期化しても並列では実行されないので、マルチプロセス化などを行う必要があります。これについては以下の記事が参考になりました。

https://pod.hatenablog.com/entry/2019/03/21/162511

また、run_in_executor で実行する関数に名前付き引数を渡す場合、functools.partial を使う必要があります。

引数で渡せる値は、Python の仕様上 Picklable な値のみだそうです。
ラムダ式やモジュールトップレベル以外で定義された関数やクラスは渡せません

https://docs.python.org/ja/3/library/pickle.html#what-can-be-pickled-and-unpickled

サンプルコード

上記を踏まえたサンプルコードです。
同期処理として CPU バウンドを想定した処理を２つ、非同期処理として I/O バウンドを想定した処理を２つ、計４つの処理を並列で動かしています。

import asyncio
import time
from functools import partial
from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor

def cpu_bound(index):
 # CPU バウンドな処理を想定
 count = 0
 while count < 1000:
 print(f'cpu_bound[{index}] count={count}')
 count += 1
 time.sleep(0.01)

async def io_bound(index):
 # I/O バウンドな処理を想定
 count = 0
 while count < 1000:
 print(f'io_bound[{index}] count={count}')
 count += 1
 await asyncio.sleep(0.01)

async def main():
 loop = asyncio.get_running_loop()
 executor = ProcessPoolExecutor(max_workers=2)
 tasks = [
 loop.run_in_executor(executor, partial(cpu_bound, 0)),
 loop.run_in_executor(executor, partial(cpu_bound, 1)),
 io_bound(0),
 io_bound(1),
 ]
 await asyncio.gather(*tasks)

asyncio.run(main(), debug=True)

ProcessPoolExecutor により、CPU バウンドな処理はそれぞれ個別のプロセスとして動作させています。
I/O バウンドな処理はどちらもメインプロセスで動作します。
従って、I/O バウンドな処理のほうが少し終わるのが遅くなります。

参考 URL

Grafana Cloud で InfluxDB v2 のデータを可視化する

Fri, 06 Jan 2023 00:00:00 +0900

InfluxDB v2 ではそれ自体でダッシュボードの作成もできますが、まだまだ使いにくかったり細かい設定ができなかったりしたので、使い慣れている Grafana を使うことにしました。
また、この機会に Grafana もオンプレミス版からクラウドサービスの Grafana Cloud に変更しました。

Grafana Cloud へのサインアップ方法などは割愛します。

データソースの設定

サイドメニューから Data Sources を選択します。
Add data source をクリックし、InfluxDB をクリックします。
InfluxDB の情報を入力します。

InfluxDB Cloud の場合、Query Language は Flux を選択します。
また、URL, トークン、バケット名が必要になるので、以下を参考に取得しておきます。

https://kuttsun.blogspot.com/2022/12/influxdb-cloud.html

ダッシュボード（パネル）の作成

InfluxDB v1 では GUI でポチポチと設定していくだけでグラフが表示できましたが、InfluxDB v2 では Flux で処理を書いていく必要があります。
最初は難しかったですが、慣れればこちらのほうが簡単に思えてきました。
いくつか例を挙げます。

基本

以下にサンプルがあります。

https://grafana.com/docs/grafana/latest/datasources/influxdb/query-editor/#use-macros

from(bucket:"バケット名")
 |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
 |> filter(fn:(r) => r._measurement == "メジャーメント名")
 |> filter(fn:(r) => r["_field"] == "表示したいフィールドの名前")
 |> aggregateWindow(every: v.windowPeriod, fn: mean)

基本的にはこれでグラフが作成できます。

一日ごとのデータを表示

例えば株価の終値を表示したい場合などは以下のようにすることでできました。

import "timezone"

option location = timezone.location(name: "Asia/Tokyo")

from(bucket:"バケット名")
 |> range(start: -30d, stop: now())
 |> filter(fn:(r) => r._measurement == "メジャーメント名")
 |> filter(fn:(r) => r["_field"] == "表示したいフィールドの名前")
 |> aggregateWindow(every: 1d, fn: last)

ポイントは aggregateWindow(every: 1d, fn: last) で、一日ごとの最後の値を取得しています。

また、タイムゾーンを指定しないと UTC での終値（つまり、日本時間の9時の時点の値）が取得されてしまったので、JST を指定しました。

https://www.influxdata.com/blog/time-zones-in-flux/

尚、私の場合はグラフではなくテーブル表示にしたかったため、グラフの表示期間に関わらず range(start: -30d, stop: now()) で直近30日固定表示にしています。

累積グラフの作成

cumulativeSum を使います。

https://docs.influxdata.com/influxdb/cloud/query-data/flux/cumulativesum/

例えば、日次損益の集計を行う場合などは以下のようにするとできました。

import "timezone"

option location = timezone.location(name: "Asia/Tokyo")

from(bucket:"バケット名")
 |> range(start: -30d, stop: now())
 |> filter(fn:(r) => r._measurement == "メジャーメント名")
 |> filter(fn:(r) => r["_field"] == "表示したいフィールドの名前")
 |> aggregateWindow(every: 1d, fn: last)
 |> cumulativeSum()

一日ごとの値は取り出す方法は前述の例と同じです。
あとはそれを cumulativeSum() で加算していくだけです。
これにより、一日ごとの値を加算してグラフに表示できます。

参考 URL

Influxdb Cloud を使ってみた

Mon, 26 Dec 2022 00:00:00 +0900

今までは AWS や GCP 上に InfluxDB の環境を用意して使っていたのですが、InfluxDB Cloud というクラウドサービスがあることを知ったので、使ってみました。
バージョンも今までは v1 を使っていましたが、クラウドなので v2 に変わります。

準備

バケットの作成

InfluxDB v1 系でいう、データベースとリテンションポリシーを合わせたようなものかなと思います。

サイドメニューより Load Data > Buckets を選択します。
画面右側の GENERATE BUCKET > クリックします。
バケット名を入力し、必要に応じてデータの保存期間を指定します（デフォルトでは 30 日経ったら古いデータが削除されます）。

トークンの取得

サイドメニューより Load Data > API Tokens を選択します。
画面右側の GENERATE API TOKEN > All Access API Token を選択します。
トークンが表示されるのでコピーします。

コピーしたトークンは環境変数などに設定して使います。

$ export INFLUX_TOKEN=コピーしたトークン

URL の取得

API エンドポイントとなる URL は以下で取得できます。

画面上部のメールアドレスを選択 > Settings をクリック

Python からデータを書き込む

以下の記事を参考にしてください。

https://kuttsun.blogspot.com/2022/12/python-influxdb-18-influxdbclient.html

必要な情報はバケット名、トークン、URL です。

ダッシュボードの作成

別途記事にします。

参考 URL

https://dev.classmethod.jp/articles/send-and-visualize-data-with-influxdb-cloud/

[Python] InfluxDB 1.8 で influxdb_client を使う

Wed, 21 Dec 2022 00:00:00 +0900

python で InfluxDB v1 に対してデータの読み書きを行う際に、ayncio を使って非同期化したいなと思ったのですが、今使っているライブラリの InfluxDBClient は asyncio に対応していないようでした。

代わりに influxdata 社の influx-client を使うと asyncio を使えそうだったのですが、こちらは基本的に InfluxDB v2 以降にのみ対応しているようで、Flux という言語にしか対応していません。
InfluxDB v1 以前は InfluxQL という SQL に近い言語が使われていました。

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

https://rabbit-note.com/2022/09/12/influxdb-2-flux/

ただ、InfluxDB 1.7以降でも設定を変更することで Flux が使えるようになるそうです。

https://github.com/influxdata/influxdb-client-python#influxdb-1-8-api-compatibility

従って、InfluxDB v1 でも Flux を有効にしたうえで、Flux でクエリを記述してデータを取得するようにすれば、asyncio を使って非同期化することができそうです。
ちなみに、データの書き込みに関しては Flux は関係ありませんでした。

以下、InfluxDB v1 の前提で書いていますが、v2 でも基本的には同じです。
bucket token の指定方法が異なるだけです。

環境

InfluxDB 1.8.10

Flux 言語を有効化する

InfluxDB を Docker で動かしていたのですが、環境変数に以下を追加するだけで OK でした。

INFLUXDB_HTTP_FLUX_ENABLED=true

サンプルコード

データの書き込み (write_api)

import asyncio
from influxdb_client.client.influxdb_client_async import InfluxDBClientAsync
from influxdb_client.client.write.point import Point
from influxdb_client.domain.write_precision import WritePrecision

if __name__ == '__main__':
 
 async def main():
 url = 'http://<url>:8086'
 username = 'username'
 password = 'password'
 dbname = 'dbname'
 rpname = 'rpname'
 # https://zeppelin.apache.org/docs/0.10.1/interpreter/influxdb.html
 bucket = f'{dbname}/{rpname}' # InfluxDB 1.8 では dbname/rpname がバケット名として使われる
 token = f'{username}:{password}' # InfluxDB 1.8 では username:password がトークンとして使われる
 org = "-" # InfluxDB 1.8 ではよくわからん
 
 data = []
 data.append({
 'fields': {
 'hoge': 1
 },
 'measurement': 'measurement',
 'tags': {
 'hostname': 'hostname',
 }
 })
 points = [ Point.from_dict(i, WritePrecision.MS) for i in data ]
 
 async with InfluxDBClientAsync(url=url, token=token, org=org) as client:
 write_api = client.write_api()
 successfully = await write_api.write(bucket=bucket, record=points)
 print(successfully)

データの読み込み (query_api)

import asyncio
from influxdb_client.client.influxdb_client_async import InfluxDBClientAsync

if __name__ == '__main__':
 
 async def main():
 url = 'http://<url>:8086'
 username = 'username'
 password = 'password'
 dbname = 'dbname'
 rpname = 'rpname'
 # https://zeppelin.apache.org/docs/0.10.1/interpreter/influxdb.html
 bucket = f'{dbname}/{rpname}' # InfluxDB 1.8 では dbname/rpname がバケット名として使われる
 token = f'{username}:{password}' # InfluxDB 1.8 では username:password がトークンとして使われる
 org = "-" # InfluxDB 1.8 ではよくわからん

 query = f"""
 from(bucket: "{bucket}")
 |> range(start: -10m)
 |> filter(fn:(r) => r._measurement == "measurement")
 |> filter(fn: (r) => r["_field"] == "field")
 |> aggregateWindow(every: 1m, fn: mean, createEmpty: false)
 """

 async with InfluxDBClientAsync(url=url, token=token, org=org) as client:
 tables = await client.query_api().query(query=query)
 for table in tables:
 print(table)
 for record in table.records:
 print (record.values)

 asyncio.run(main())

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

https://qiita.com/riverplus/items/20456e4188a4c0f5f62d

参考 URL

Grafana から Rocket.Chat へ通知を行う

Tue, 13 Dec 2022 00:00:00 +0900

Grafana 自体は Rocket.Chat に対応していませんが、Webhook を使うことで Rocket.Chat に通知できます。
アラートの基本的な設定方法については以下を参照してください。

Grafana でアラートを設定する

ここでは Rocket.Chat への通知の設定のみ記載します。

Rocket.Chat 側の設定

管理画面のメニューから サービス連携 を選択し、Incoming で新規作成を行います。
スクリプトを有効にし、以下のスクリプトを記入します。


class Script {

 process_incoming_request({ request }) {
 let color = "#00FF00"; // green
 switch(request.content.state) {
 case 'ok':
 color = '#00FF00';
 break;
 case 'paused':
 color = '#666666';
 break;
 case 'alerting':
 color = '#FF0000';
 break;
 case 'pending':
 color = '#CCCCCC';
 break;
 case 'no_data':
 color = '#333333';
 break;
 default:
 color = '#666666';
 }
 return {
 content:{
 text: request.content.title,
 "attachments": [{
 "color": color,
 "title": request.content.title,
 "title_link": request.content.ruleUrl,
 "text": request.content.message,
 "image_url": request.content.imageUrl,
 }]
 }
 };
 }
}

その他、投稿先チャンネルや投稿ユーザーなどの基本的な設定を行います。
Grafana の設定で Webhook URL が必要になるのでコピーしておきます。

Grafana 側の設定

Grafana のサイドメニューから Alert rules を選択し、Contact Points で以下の設定を行います。

New contact point をクリック
Name にはわかりやすい名前を適当に入力する
Contact point type で Webhook を選択する
Webhook URL に上記で取得した URL を入力する

Rocket.Chat に関する設定は以上で完了です。

参考 URL

https://gist.github.com/ATofighi/79895715ae0a8f5bdeff058a64012275

Grafana から Slack へ通知を行う

Wed, 07 Dec 2022 00:00:00 +0900

Grafana のアラートで Slack のチャンネルへ通知を行う方法です。
アラートの基本的な設定方法については以下を参照してください。

Grafana でアラートを設定する

ここでは Slack への通知の設定のみ記載します。

Webhook URL の取得

まず、通知したい Slack のチャンネルの Webhook URL を取得します。 Webhook URL は、以下からワークスペースとチャンネルを指定して取得できます。

https://slack.com/services/new/incoming-webhook

Contact Point の設定

Grafana のサイドメニューから Alert rules を選択し、Contact Points で以下の設定を行います。

New contact point をクリック
Name にはわかりやすい名前を適当に入力する
Contact point type で Slack を選択する
Webhook URL に上記で取得した URL を入力する

Slack に関する設定は以上です。

参考 URL

https://fclout.hateblo.jp/entry/2020/06/20/Grafana%E3%81%8B%E3%82%89Slack%E3%81%B8%E9%80%9A%E7%9F%A5%E3%81%99%E3%82%8B

Ubuntu の Emergency Mode で日本語配列のキーボードを使う

Fri, 02 Dec 2022 00:00:00 +0900

Ubuntu 18.04 が emergency mode で起動した時に、キーボードの配列が日本語配列になっていなくて困ったのでメモです。

以下を実行すれば日本語配列のキーボードが使えるようになりました。

loadkeys jp

尚、上記のコマンドを入力するために、私の環境では以下のようにキーを押す必要がありました。

入力したい文字	実際に押したキー
`l`	`k`
`o`	`o`
`a`	左下の ctrl
`d`	`s`
`k`	`j`
`e`	`e`
`y`	`y`
`s`	`a`
スペース	`.`
`j`	`h`
`p`	`p`

これが何の配列になっていたのかはわかりませんでした。

参考 URL

https://kledgeb.blogspot.com/2016/05/ubuntu-1604-60.html

Grafana でアラートを設定する

Wed, 30 Nov 2022 00:00:00 +0900

Grafana で任意の値が閾値を超えたら（または下回ったら）アラートを発報するように設定します。

設定方法は Grafana のバージョンによって大きく異なるようですが、今回使用した Grafana 9.1.0 では、以下の３段階で設定を行うようです。

Alert rules: アラート条件の設定
Contact points：通知先の登録
Notification policy：アラート条件と通知先の関連付け

環境

Grafana 9.1.0

アラート条件の設定

左のサイドメニューより、Alerting > Alert rules をクリックします。
New alert rule をクリックします。
1. Set a query and alert condision で監視したい値や閾値を設定します。（具体的な設定例は後述します。）
2.Alert evaluation behavior でアラート保留状態となる時間を設定します。
デフォルトでは１分毎に評価し、アラートを検出した後５分が経過したら通知が行われるようになっています。
3. Add details for your alert でこのアラートの名前や説明を記載します。
4. Notifications で通知先のラベルを指定します（後述）。
指定しなかった場合はデフォルトの通知先が使用されます（後述）。
設定が完了したら画面右上の Save で保存します。

通知先の登録

左のサイドメニューより、Alerting > Contact points をクリックします。
New contact points をクリックします。
Name で適当な名前を付け、Contact point type で通知方法を選択します（後述）。
設定が完了したら Save contact point で保存します。

具体的な設定例

通知先によって異なるため、別記事にまとめます。

アラート条件と通知先の関連付け

左のサイドメニューより、Alerting > Notification policies をクリックします。
デフォルトの通知先の変更や、特定のラベルのアラートに対する通知先を設定します（後述）。
Save policy をクリックして保存します。

デフォルトの通知先を指定

Root policy の右側にある Edit をクリックします。
Default contact point でデフォルトの通知先を指定します。

特定のラベルに対する通知先を指定

New specific policy をクリックします。
Add matcher でラベルの条件を指定し、Contact point で通知先を指定します。

参考 URL

https://doc.cloud.global.fujitsu.com/lib/monitoringservice/jp/usersguide/capter02/alerting/alert_rule/

[Pytnon] pymongo で一括処理（Bulk Method）を行う

Thu, 27 Oct 2022 00:00:00 +0900

Bulk Method を使い前は以下のようにして一件ずつ update_one で追加（更新）していました。

これを BulkMethod を使って一括で処理するようにしてやります。

initialize_ordered_bulk_op initialize_unordered_bulk_op で初期化します。

今回は initialize_unordered_bulk_op を使用します。

Bulk Method で update_one を使うには、find と upsert メソッドを組み合わせるようです。

https://www.mongodb.com/docs/manual/reference/method/Bulk.find.upsert/

また、update_one で３件のデータを追加（更新）する

まずは処理しやすくするためにサンプルデータを配列で用意しました。

sample_data = []
for i in range(3):
 sample_data.append({
 'filter': {
 'camera_id': "1",
 'detected_id': str(start_id + i + 1),
 },
 'update': {
 'label': 'person',
 'captured_at': captured_at.isoformat(),
 'disappeared_at': captured_at.isoformat(),
 'thumbnail': None
 }
 })

上記のデータについて、例えば以下のように処理します。

from pymongo import MongoClient,

client = MongoClient('mongodb://localhost:27017/')
db = client['dbname']
col = db['col_name']

bulk = col.initialize_unordered_bulk_op()

for data in sample_data:
 bulk.find(data['filter']).upsert().update_one({ '$setOnInsert': data['update'] })

result = bulk.execute()

$setOnInsert については以下のページが参考になりました。

レスポンスは以下のようなデータが返ってきます。

{
 'writeErrors': [],
 'writeConcernErrors': [],
 'nInserted': 0,
 'nUpserted': 2,
 'nMatched': 1,
 'nModified': 0,
 'nRemoved': 0,
 'upserted': [
 {
 'index': 1,
 '_id': ObjectId('635878690bdc2e90f9e0e8bf')
 },
 {
 'index': 2,
 '_id': ObjectId('63588e750bdc2e90f9e0f1f2')
 }
 ]
}

nUpserted は新規に追加されたドキュメントの数です。
nMatched は find の条件に一致したされたドキュメントの数です。
nModified は更新されたドキュメントの数です。
upserted は新規追加されたデータのインデックスと、MongoDB によって割り当てられた ID となります。

参考 URL

overlayroot の有効無効をシェルスクリプト化

Tue, 18 Oct 2022 00:00:00 +0900

overlayroot を使ってファイルシステムを読み取り専用にしましたが、現在読み取り専用になっているのかどうかのチェックと、有効無効を簡単に切り替えられるようなスクリプトを作成してみました。

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

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

overlayroot が有効か無効かをチェック

#!/bin/bash

mount | grep 'overlayroot on / type overlay' &> /dev/null
if [ $? == 0 ]; then
 echo "overlayroot enabled" 
else
 echo "overlayroot disabled"
fi

&> /dev/null は標準出力と標準エラー出力の破棄です。

https://qiita.com/ritukiii/items/b3d91e97b71ecd41d4ea

$? は直前に実行したコマンドの終了値です（0は成功、1は失敗）。

https://qiita.com/zayarwinttun/items/0dae4cb66d8f4bd2a337

overlayroot を無効にする

#!/bin/bash

sudo overlayroot-chroot rm /etc/overlayroot.local.conf

overlayroot-chroot で一時的に書き込み可能状態にして /etc/overlayroot.local.conf を削除しているだけです。

overlayroot を有効にする

#!/bin/bash

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

/etc/overlayroot.local.conf を作成して overlayroot="tmpfs:recurse=0" を記述しているだけです。

サンプル

以上を踏まえて作成してみたのが以下のスクリプトです。

#!/bin/bash
# ex: ./overlayroot.sh disable
# ex: ./overlayroot.sh enable
# ex: ./overlayroot.sh

timeout=3

# 現在の overlayroot の状態を取得
mount | grep 'overlayroot on / type overlay' &> /dev/null
if [ $? == 0 ]; then
 overlay=true
 echo "overlayroot enabled"
else
 overlay=false
 echo "overlayroot disabled"
fi

if [[ $1 = disable ]]; then
 # overlayroot を無効にする
 if [ $overlay = true ]; then
 echo "disable overlayroot..."
 sudo overlayroot-chroot rm /etc/overlayroot.local.conf
 echo -e "\nReboot after ${timeout} seconds"
 sleep ${timeout}
 sudo reboot
 else
 echo "overlayroot already disabled"
 fi
elif [[ $1 = enable ]]; then
 # overlayroot を有効にする
 if [ $overlay = true ]; then
 echo "overlayroot already enabled"
 else
 echo "enable overlayroot..."
 echo 'overlayroot="tmpfs:recurse=0"' | sudo tee /etc/overlayroot.local.conf
 echo -e "\nReboot after ${timeout} seconds"
 sleep ${timeout}
 sudo reboot
 fi
fi

echo -e "\nCloses after ${timeout} seconds"
sleep ${timeout}

参考 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

Markdown Preview Enhanced で HTML 出力に PNG 画像を base64 で埋め込む

Mon, 03 Oct 2022 00:00:00 +0900

VSCode でマークダウンを書くのに Markdown Preview Enhanced を使用していますが、HTML で出力する際、SVG は base64 で埋め込まれましたが、PNG はデフォルトでは埋め込まれません。

これについて、以下に説明があります。

https://shd101wyy.github.io/markdown-preview-enhanced/#/ja-jp/html

文書の最初に以下を記述すれば PNG が base64 で埋め込まれました。

---
html:
 embed_local_images: true
---

参考 URL

https://shd101wyy.github.io/markdown-preview-enhanced/#/ja-jp/html

NTP サーバー/クライアント chrony の設定

Thu, 29 Sep 2022 00:00:00 +0900

chrony を使って NTP サーバー、NTP クライアントのぞれぞれを設定してみました。

環境

Ubuntu 20.04
chrony 3.5

インストール

$ sudo apt install chrony

NTP サーバーとしての設定

/etc/chrony/chrony.conf をエディタで編集します。

$ sudo nano /etc/chrony/chrony.conf

上位サーバーの無効化

17行目〜20行目をコメントアウトします。

#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2

認証の無効化

24行目をコメントアウトします。

#keyfile /etc/chrony/chrony.keys

アクセス許可

特定のセグメントからのみアクセスを許可したい場合は以下のように追記します。

# Allow NTP client access from local network.
allow 192.168.4.0/24

全セグメントから許可シたい場合は allow とだけ記載するようです。

上位の NTP サーバーがいなくても同期を取れるようにする

以下を追記します。

# Serve time even if not synchronized to a time source.
local stratum 5

再起動

設定が完了したら chrony を再起動します。

$ sudo systemctl restart chrony

NTP クライアントとしての設定

/etc/chrony/chrony.conf をエディタで編集します。

$ sudo nano /etc/chrony/chrony.conf

17行目〜20行目をコメントアウトし、pool <NTPサーバーのIPアドレス> iburst> を追記します。

#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2
pool 192.168.0.10 iburst

時刻同期について

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

chrony は iburst オプションの付いた NTP サーバーに対して、起動直後に短い間隔で4回問い合わせをするそうです。また、デフォルトでは makestep 1 3 の設定がありますが、これは chrony の起動時に、1.0 秒以上時刻ずれが 3 回続いた場合、step モードで一気に時刻補正をするという意味だそうです。そうでない場合は slew モードで少しずつ時刻補正を行うそうです。

再起動

設定が完了したら chrony を再起動します。

$ sudo systemctl restart chrony

確認

chronyc sources を実行し、サーバー名の最初に * と表示されていれば同期が取れています。

$ chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample 
===============================================================================
^* 192.168.0.10 5 6 377 34 -7277ns[-2447ns] +/- 41us

ちょっとはまったところ

きちんと同期がとれているか確認するために、サーバー側の日時を Ubuntu の GUI で変更し、クライアントの PC を再起動してみましたが、同期されませんでした。
何でだろうと思っていたら、日時を GUI で変更したときに chrony のサービスが停止していました。

chrony が動いているかどうかは以下のコマンドで確認できます。

$ sudo systemctl status chrony

もし chrony が停止していた場合は、以下のコマンドで起動します。

$ sudo systemctl start chrony

この状態でクライアントの PC を再起動したら、起動時に日時が同期されました。

もし PC 再起動後に chrony が停止していた場合は有効化されていないので、以下のコマンドを実行します。

$ sudo systemctl enable chrony

参考 URL

[Python] yaml 内の環境変数を展開して読み込む

Wed, 28 Sep 2022 00:00:00 +0900

pyaml-env を使うと簡単にできました。

インストール

$ pip install pyaml-env

サンプル

yaml 内では、環境変数を展開したい行に !ENV を書くようです。

url: !ENV 'http://${HOST}:${PORT}'

from pyaml_env import parse_config
 
config = parse_config('sample.yaml')
print(config)

参考 URL

https://www.wenyanet.com/opensource/ja/61162b748356b8749f1e4126.html

InfluxDB のコマンド (InfluxQL)

Thu, 22 Sep 2022 00:00:00 +0900

ちょっと何かしたいというときに毎回コマンドを調べているので、個人的によく使うコマンドをまとめてみました。

環境

Ubuntu 20.04
InfluxDB 1.8.0

事前知識

influx コマンドで DB との対話モードとなります。
この状態でコマンドを実行していきます。
尚、対話モードに入らずに以下のようにしてコマンドを実行することもできます。

$ influx -execute "コマンド"

以下、対話モードになっている前提でコマンドのみ記載します。

データベースの作成

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#create-database

create database <データベース名> を実行します。

> create database sampledb

データベースの表示

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#show-databases

show databases を実行します。

> show databases
name: databases
name
----
sampledb
_internal

リテンションポリシーの作成

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#create-retention-policy

create retention policy <リテンションポリシー名> on <データベース名> を実行します。

> create retention policy samplerp on sampledb duration 30d replication 1 default

duration : 保存期間を指定
- https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#durations
replication : でレプリケーション数を指定
default : このリテンションポリシーをデフォルトにする

リテンションポリシーの表示

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#show-retention-policies

use <データベース名> でデータベースを選択し、show retention policies で表示します。

> use sampledb
Using database sampledb
> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------
autogen 0s 168h0m0s 1 false
samplerp 720h0m0s 24h0m0s 1 true

リテンションポリシーの保存期間を変更

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#alter-retention-policy

alter retention policy <リテンションポリシー名> on <データベース名> duration <保存期間> を実行します。

> alter retention policy samplerp on sampledb duration 180d

show retention policies で変わったことを確認します。

> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------
autogen 0s 168h0m0s 1 false
samplerp 4320h0m0s 24h0m0s 1 true

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

[Python] psutil を使おうとしたら `command 'aarch64-linux-gnu-gcc' failed with exit status 1` のエラーがでた

Tue, 13 Sep 2022 00:00:00 +0900

arm 系の CPU 環境において、Ubuntu のイメージを使った Docker コンテナ内で、python の psutil を使ってストレージの情報を取得しようとしたところ、psutil のインストール時に以下のエラーが表示されました。

error: command 'aarch64-linux-gnu-gcc' failed with exit status 1

crossbuild-essential-arm64 と python3-dev をインストールすれば解決しました。

$ sudo apt install crossbuild-essential-arm64 python3-dev

参考 URL

https://qiita.com/yuta_vamdemic/items/277a5a692840d06c4cd9

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

Telegraf で CPU の温度を取得する

Wed, 24 Aug 2022 00:00:00 +0900

タイトルの通りです。

環境

Ubuntu 20.04

CPU の温度観測プローブを調べる

以下の記事が参考になりました。

https://qiita.com/koara-local/items/1fac13704123717f5cc8

/sys/class/thermal に thermal_zone0 〜 thermal_zone3 の４つのディレクトリがあり、このうちのどれかが CPU の温度観測用のファイルのようです。
これらの中にある type ファイルを見ることで、何の温度を表しているかが分かるようです。

$ cat /sys/class/thermal/thermal_zone0/type
acpitz
$ cat /sys/class/thermal/thermal_zone1/type
acpitz
$ cat /sys/class/thermal/thermal_zone2/type
pch_skylake
$ cat /sys/class/thermal/thermal_zone3/type
x86_pkg_temp

どうやら私の環境では thermal_zone3 が CPU の温度のようです。
なので、/sys/class/thermal/thermal_zone3/temp を見ることで CPU の温度が取得できます。

$ cat /sys/class/thermal/thermal_zone3/temp
35000

1000 倍された値が表示されるので、上記の場合 35℃ です。

Telegraf の設定

上記のファイルを監視するように、telegraf.conf に以下を記述するだけです。

[[inputs.file]]
 files = ["/sys/class/thermal/thermal_zone3/temp"]
 name_override = "cpu_temperature"
 data_format = "value"
 data_type = "integer"

参考 URL

シェルスクリプトをダブルクリックで端末内で実行する

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

Ubuntu 20.04 にて、デスクトップに置いたシェルスクリプトファイルをダブルクリックで実行し、かつ端末内で実行する方法です。
結構はまったのでメモしておきます。

#!/bin/bash
gnome-terminal -- bash -c "echo sample;sleep 5"

端末がすぐ閉じるのを防ぐために sleep 5 を入れています。

#!/bin/bash
gnome-terminal -- bash -c "/home/username/sample.sh;sleep 5"

参考 URL

https://askubuntu.com/questions/1259265/make-gnome-terminal-request-user-confirmation-before-close

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

Rocket.Chat の REST API でダイレクトメッセージを送る

Wed, 17 Aug 2022 00:00:00 +0900

アプリケーションから Rocket.Chat のユーザーに対してダイレクトメッセージを送りたかったので、調べてみたら、REST API を使うことでできました。

使用した API の仕様は以下です。

https://developer.rocket.chat/reference/api/rest-api/endpoints/core-endpoints/chat-endpoints/postmessage

例えば Windows の場合、以下のようなコマンドで動作を確認できました。
（ユーザー名の部分だけ変更してください。）

curl.exe -X POST^
 -H "X-Auth-Token: <Token>"^
 -H "X-User-Id: <User-Id>"^
 -H "Content-type:application/json"^
 http://rocketchat-url/api/v1/chat.postMessage^
 -d "{\"channel\": \"@ユーザー名\", \"msg\": \"This is a direct message!\" }"

Token と User-Id は、マイアカウント > パーソナルアクセストークンから作成できます。
REST API の実行権限のあるアカウントで作成する必要があります。

メッセージの内容については上記の API 仕様を参照してください。
例えば、以下のようにして通知者名とアイコンを変更することができます。

curl.exe -X POST^
 -H "X-Auth-Token: <Token>"^
 -H "X-User-Id: <User-Id>"^
 -H "Content-type:application/json"^
 http://rocketchat-url/api/v1/chat.postMessage^
 -d "{\"channel\": \"@ユーザー名\", \"msg\": \"This is a direct message!\", \"alias\": \"ほげ\", \"emoji\": \":thumbsup:\" }"

参考 URL

[Python] アドレス (id) は変更せずに辞書 (dict) をコピーしたい

Sat, 13 Aug 2022 00:00:00 +0900

わかってしまえば当たり前なのですが、ちょっとハマったのでメモ。

結論から先に言うと、clear() update() を使うことで実現できました（ただし排他には要注意）。

環境

Python 3.8.10

前提知識

以下の話はググれば解説されているページがいくらでも見つかりますが・・・。

dict はミュータブルな型なので、代入する場合には注意が必要です。

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

dict_a = dict_b # 代入

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

代入した場合には同じオブジェクトを指すようになるので、以下のように id が同じになります。

dict_a={'key_a': 'value_a'}, id:140351608696704
dict_b={'key_b': 'value_b'}, id:140351608696768
----------
dict_a={'key_b': 'value_b'}, id:140351608696768
dict_b={'key_b': 'value_b'}, id:140351608696768

なので、dic_a を変更したら dict_b の中身も変わります。

これを回避するには（つまり id は別で中身だけをコピーしたい場合は） copy() を使います。

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

dict_a = dict_b.copy()

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

この場合は新たにオブジェクトが作成されるので、id は別で中身は同じになります。

dict_a={'key_a': 'value_a'}, id:139764478058368
dict_b={'key_b': 'value_b'}, id:139764478058432
----------
dict_a={'key_b': 'value_b'}, id:139764476783232
dict_b={'key_b': 'value_b'}, id:139764478058432

じゃあ id を変えずに中身だけをコピーするには？

clear() と update() を使えばできます。

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

dict_a.clear()
dict_a.update(dict_b)

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

dict_a={'key_a': 'value_a'}, id:139790269009792
dict_b={'key_b': 'value_b'}, id:139790269009856
----------
dict_a={'key_b': 'value_b'}, id:139790269009792
dict_b={'key_b': 'value_b'}, id:139790269009856

dict_a dict_b の中身は同じですが、dict_a の id は変わっていません。

関数に引数で渡す場合

Python では全て参照渡しなので、dict を関数に渡して関数内で変更した場合、その関数の外にも影響を与えます。


def change_dict(target_dict):
 target_dict['hoge'] = 'piyo'

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

change_dict(dict_a)

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

dict_a={'key_a': 'value_a'}, id:139844338024320
dict_b={'key_b': 'value_b'}, id:139844338024384
----------
dict_a={'key_a': 'value_a', 'hoge': 'piyo'}, id:139844338024320
dict_b={'key_b': 'value_b'}, id:139844338024384

本題

じゃあ、関数内で dict を丸ごと差し替えたい場合はどうすればよいか？
引数で渡した値に丸ごと新しい dict を代入すると、その引数の参照先が変わるだけなので、参照元には反映されません。

def change_dict(target_dict):
 target_dict = {'hoge': 'piyo'}

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

change_dict(dict_a)

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

dict_a={'key_a': 'value_a'}, id:139712684732288
dict_b={'key_b': 'value_b'}, id:139712684732352
----------
dict_a={'key_a': 'value_a'}, id:139712684732288
dict_b={'key_b': 'value_b'}, id:139712684732352

かと言って、copy() を使うと新たにオブジェクトが作成されるので、この場合も参照元には反映されません（コピー前のオブジェクトを参照しているため）。

def change_dict(target_dict):
 target_dict = {'hoge': 'piyo'}.copy()

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

change_dict(dict_a)

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

dict_a={'key_a': 'value_a'}, id:2642357453888
dict_b={'key_b': 'value_b'}, id:2642357181760
----------
dict_a={'key_a': 'value_a'}, id:2642357453888
dict_b={'key_b': 'value_b'}, id:2642357181760

なので、参照元にも変更を反映したい場合には、前述したように clear() update() を使います。

def change_dict(target_dict):
 target_dict.clear()
 target_dict.update({'hoge': 'piyo'})

dict_a = {"key_a": "value_a"}
dict_b = {"key_b": "value_b"}

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

print(f'----------')

change_dict(dict_a)

# 値と id の確認
print(f'dict_a={dict_a}, id:{id(dict_a)}')
print(f'dict_b={dict_b}, id:{id(dict_b)}')

dict_a={'key_a': 'value_a'}, id:2371211616000
dict_b={'key_b': 'value_b'}, id:2371211612864
----------
dict_a={'hoge': 'piyo'}, id:2371211616000
dict_b={'key_b': 'value_b'}, id:2371211612864

排他には注意

clear() update() という２つの関数を使って dict を更新するので、並列処理を行っている場合には排他が必要です。
clear() と update() の間で値が読み込まれるということが発生しうるからです。

私の場合、マルチプロセスで動いているアプリで実際にそれが発生しました。
（使っていたのは普通の dict ではなく multiprocessing.Manager().dict() ですが）

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

Ubuntu に nginx を入れてリバースプロキシとして使用する

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

環境

Ubuntu 20.04

インストール

$ sudo apt install nginx

http://localhost にアクセスして nginx が起動していることを確認します。

設定

nginx の設定ファイルは /etc/nginx/nginx.conf ですが、この中を見ると、http ディレクティブの中に以下の記述があります。

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

conf.d と sites-enabled の中に置いた設定ファイルが読み込まれるようになっています。
２つの使い分けについては以下のページが参考になりました。

https://qiita.com/tomokon/items/e782636c1e5ec6b5dfdc

というわけで、sites-available に設定ファイルを作成して、sites-enabled にシンボリックリンクを作成します。

conf ファイルの追加

$ sudo nano /etc/nginx/sites-available/sample.conf

以下を追記します。

server {
 listen 80 default_server;
 server_name _;
 location / {
 proxy_pass http://localhost:5000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

server_name の _; は catch-all の意味らしく、任意の URL に対して有効になります。

http://nginx.org/en/docs/http/server_names.html

proxy_pass が遷移先の URL です。
その他の設定については以下を参考にさせてもらいました。

https://lh182051.hateblo.jp/entry/2019/11/22/010641

デフォルトの設定の削除

sites-enabled の中には最初から default という設定へのシンボリックリンクがあります。
設定内容次第ではこの default の設定が邪魔になることもあるので、そのような場合は削除しておきます。

今回の場合は default_server と server_name _; が重複しているので、削除しておかないと上手くルーティングできません。

$ sudo rm /etc/nginx/sites-enabled/default

シンボリックリンクの作成

$ sudo ln -s /etc/nginx/sites-available/sample.conf /etc/nginx/sites-enabled/sample

nginx を再起動します。

$ sudo systemctl restart nginx

以上で完了です。

参考 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

ImageMagick で画像を一括で変換

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

Ubuntu で大量の画像ファイルを一括で変換したいときは、ImageMagick のコマンドを使うと便利です。

インストール

私の環境では最初からインストールされていましたが、ない場合は以下でインストールできます。

$ sudo apt install imagemagick

画像の変換

例えば、全ての png 画像を jpg に変更したい場合は以下のようにしします。

$ mogrify -format jpg *.png

元のファイルは残ったままです。

リサイズ

jpg ファイルを全てリサイズしたい場合、以下のようにします。

$ mogrify -resize 100x100 *.jpg

ただし、この場合アスペクト比は維持されます。なので、例えば、640x360 の画像を上記のコマンドでリサイズすると、100x56 のサイズになります。

アスペクト比を無視して強制的にリサイズしたい場合は ! をつけます。

$ mogrify -resize 100x100! *.jpg

また、割合で指定したい場合は以下のようにします。

$ mogrify -resize 50% *.jpg

参考 URL

Rocket.Chat の読み取りチャンネルで絵文字の追加を許可する

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

デフォルトだと読み込み専用チャンネルでは絵文字（リアクション）の追加ができませんが、設定を変更すればできるようになります。

チャンネルの設定画面で「反応を許可する」を ON にすればいいだけですが、これを設定できるのはデフォルトだと Admin または Owner 権限を持つユーザーのみです。

他のロールにもこの権限を付与したい場合は、root でログインし、「管理 > 権限」を選択し、「ReadOnly時の反応を設定する」にチェックを入れます。

参考 URL

https://martinschoeler.github.io/docs/administrator-guides/permissions/

Firefox でブックマーク、検索バー、ロケーションバー（アドレスバー）を新しいタブで開く

Thu, 14 Jul 2022 00:00:00 +0900

よく忘れるのでメモ。

ロケーションバー（アドレスバー）に about:config を入力
「危険を承知の上で使用する」をクリック
browser.tabs.loadBookmarksInTabs で検索して true に変更
- ブックマークをクリックしたときに新しいタブで開くようになる
browser.search.openintab で検索して true に変更
- 検索バーでの検索結果が新しいタブに表示されるようになる
browser.urlbar.openintab で検索して true に変更
- ロケーションバー（アドレスバー）の入力内容が新しいタブで表示されるようになる

参考 URL

Ubuntu にインストールした Rocket.Chat のクライアントソフトが起動しなくなった

Tue, 12 Jul 2022 00:00:00 +0900

Ubuntu にインストールした Rocket.Chat のデスクトップクライアントアプリが、ある時から急にアプリを起動しても何もウィンドウが表示されなくなってしまいました。

試しにコマンドラインから起動してみたところ、以下のようなエラーが表示されていました。

$ rocketchat-desktop 
(node:8749) UnhandledPromiseRejectionWarning: SyntaxError: Unexpected end of JSON input
 at JSON.parse (<anonymous>)
 at ElectronStore.Conf._deserialize (/opt/Rocket.Chat/resources/app.asar/node_modules/conf/dist/source/index.js:67:43)
 at ElectronStore.get store [as store] (/opt/Rocket.Chat/resources/app.asar/node_modules/conf/dist/source/index.js:278:43)
 at new Conf (/opt/Rocket.Chat/resources/app.asar/node_modules/conf/dist/source/index.js:131:32)
 at new ElectronStore (/opt/Rocket.Chat/resources/app.asar/node_modules/electron-store/index.js:69:3)
 at getElectronStore (/opt/Rocket.Chat/resources/app.asar/app/main.js:1311:25)
 at getPersistedValues (/opt/Rocket.Chat/resources/app.asar/app/main.js:1324:34)
 at /opt/Rocket.Chat/resources/app.asar/app/main.js:1363:33
 at Generator.next (<anonymous>)
 at /opt/Rocket.Chat/resources/app.asar/node_modules/tslib/tslib.js:117:75
(Use `rocketchat-desktop --trace-warnings ...` to show where the warning was created)
(node:8749) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)

原因はよくわかりませんが、設定ファイルを全削除することで起動するようになりました。

$ rm -rf ~/.config/Rocket.Chat

参考 URL

https://github.com/RocketChat/Rocket.Chat.Electron/issues/1746

GitLab CI/CD で Uploading artifacts to coordinator... too large archive のエラーが表示された

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

GitLab CI/CD で成果物をアップロードする際に、サイズが大きすぎるとのエラーが表示されました。

ERROR: Uploading artifacts to coordinator... too large archive id=XXXX responseStatus=413 Request Entity Too Large status=413 Request Entity Too Large token=XXXXX
FATAL: too large 
ERROR: Job failed: exit status 1

GitLab の設定

まずは GitLab の以下の設定を確認します。

「Settings > Continuous Integration and Deployment > Maximum artifacts size (MB) 」

デフォルトでは 100MB に設定されているので、必要ならここを変更します。

しかし、今回は 7MB 程度のファイルだったので、これが原因ではありませんでした。

リバースプロキシの設定

今回 nginx でリバースプロキシの設定を行っていたのですが、client_max_body_size の設定を行っていなかったのが原因でした。
client_max_body_size のデフォルト値は 1MB だそうです。
とりあえず以下のように 0 を設定して無制限にしておきました。

server {
 listen 80;
 server_name example.com;
 client_max_body_size 0;
}

参考 URL

https://pauledenburg.com/gitlab-ci-upload-artifact-fails-large/

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

[Python] aiohttp で multipart/form-data を使う

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

複数のデータを送るときに使う multipart/form-data を aiohttp で送る方法です。

公式ドキュメントは以下です。

https://docs.aiohttp.org/en/stable/multipart.html

基本サンプル

import asyncio
import aiohttp

async def main():
 with aiohttp.MultipartWriter("form-data") as mpwriter:
 mpwriter.append('hello1')
 mpwriter.append('hello2')
 async with aiohttp.ClientSession() as session:
 res = await session.post(f'url', data=mpwriter)
 print(res)

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

以下のような内容で送信されました。

Content-Type: multipart/form-data; boundary=69ae25abec5c4a038dc2deb4a0952eb3

--69ae25abec5c4a038dc2deb4a0952eb3
Content-Type: text/plain; charset=utf-8
Content-Length: 6

hello1
--69ae25abec5c4a038dc2deb4a0952eb3
Content-Type: text/plain; charset=utf-8
Content-Length: 6

hello2
--69ae25abec5c4a038dc2deb4a0952eb3--

テキストデータ

mpwriter.append にテキストを渡した場合、デフォルトでは Content-Type は text/plain になるそうです。

バイナリデータ

mpwriter.append にバイナリデータを渡した場合、デフォルトでは Content-Type は application/octet-stream になるそうです。
変更したい場合は以下のように第２引数で指定します。

mpwriter.append(image, {'Content-Type': 'image/jpeg'})

また、name や filename などを指定したい場合は、set_content_disposition を使用するようです。

part = mpwriter.append(image, {'Content-Type': 'image/jpeg'})
part.set_content_disposition('form-data', name="name", filename="filename")

JSON を送りたい場合

append_json に dict 型のデータを渡せばOKです。

mpwriter.append_json({'test': 'passed'})

JSON と画像を一緒に送る例

以前、requests モジュールを使って multipart/form-data のデータを送る記事を書きました。

https://kuttsun.blogspot.com/2022/06/webapi-multipartform-data.html

これを aiohttp で書いてみたのが以下です。

import asyncio
import aiohttp
from datetime import datetime

async def main():
 with aiohttp.MultipartWriter("form-data") as mpwriter:
 for camera_id in ['hoge', 'piyo']: # 各カメラのID
 # 適当なテキストデータ
 json_data = {
 'camera_id': camera_id,
 'datetime': datetime.now().isoformat()
 }
 # 適当な画像ファイルを読み込む
 image = None
 filename = 'send_image.jpg'
 with open(filename, 'rb') as f:
 image = f.read()

 # JSON の追加
 part = mpwriter.append_json(json_data)
 part.set_content_disposition('form-data', name=camera_id)

 # 画像の追加
 part = mpwriter.append(image, {'Content-Type': 'image/jpeg'})
 part.set_content_disposition('form-data', name=camera_id, filename=camera_id)

 # 送信
 async with aiohttp.ClientSession() as session:
 res = await session.post(f'http://localhost:8000', data=mpwriter)
 print(res)

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

参考 URL

https://docs.aiohttp.org/en/stable/multipart.html

[Python] flask で async/await を使う

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

flask[async] のインストールすれば、普通に async/await の構文が使えました。

公式ドキュメントは以下です。

https://flask.palletsprojects.com/en/2.1.x/async-await/

環境

Ubuntu 20.04
Python 3.8.10

インストール

$ pip install flask[async]

サンプルコード

import sys
import time
import asyncio
from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/test', methods=['GET'])
async def test():
 start = time.time()
 await asyncio.sleep(1)
 return jsonify({"elapsed time": time.time() - start})

if __name__ == '__main__':
 app.run(host='0.0.0.0', port=5000, debug=True)

参考 URL

https://flask.palletsprojects.com/en/2.1.x/async-await/

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

MkDocs の設定いろいろ

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

MkDocs の細かい設定いろいろです。

必要に応じて適宜更新していきたいと思います。

URL を自動でハイパーリンクする

以下の拡張機能を有効にします。

markdown_extensions:
 - pymdownx.magiclink

Material for MkDocsで打ち消し線が動作するようにする

以下の拡張機能を有効にします。

markdown_extensions:
 - pymdownx.tilde

スペース2個でリストがインデントされるようにする

デフォルトではスペース4個でないとリストがインデントされません。
これをスペース2個でもインデントされるようにするには、mdx_truly_sane_lists という拡張機能をインストールします。

$ pip install mdx_truly_sane_lists

mkdocs.yml に以下を追記します。

markdown_extensions:
 - mdx_truly_sane_lists:
 nested_indent: 2

更新日時を表示する

$ pip install mkdocs-git-revision-date-localized-plugin

plugins:
 - search
 - git-revision-date-localized

Material for MkDocs を使っている場合はこれだけで全ページの下部に更新日時が表示されるようになります。
オプション設定で書式などを変更することもできるようです。

https://timvink.github.io/mkdocs-git-revision-date-localized-plugin/options/

参考 URL

WebAPI で multipart/form-data を使う

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

AI を使った画像解析システムなどでは、画像をリクエストで投げて推論結果をレスポンスでもらう、というのをよくやるかと思います。

そういった API で、最初は画像を Base64 に変換して JSON で渡していたのですが、エンコード/デコードの処理時間があるため、バイナリでデータを送りたいと考えました。
また、１度のリクエストで複数枚の画像を送る必要があるのと、画像の対する付加情報（カメラのIDや画像の取得日時など）も一緒に渡す必要があるということで、multipart/form-data を使って送ってみることにしました。

multipart/form-data についての詳細は割愛しますが、バウンダリ文字列で区切って複数のデータを送信するやつで、HTML の form 文とかで使われるやつです。

今まで WebAPI では json と yaml しか扱ったことありませんでしたが、調べた感じ、WebAPI でも multipart/form-data を使ってテキストとバイナリを一緒に送るというのはよくある手法っぽいです。

リクエスト内容

例として、POST で以下のような内容を送ります。

ヘッダー（抜粋）

Content-Type multipart/form-data; boundary=cc874efaa4e6a1e85c14280c96a7b237

サンプルコードを後に載せていますが、バウンダリ文字列は自動生成でリクエスト毎に異なります。
基本的に意識しなくても大丈夫でした。

ペイロード

テキストについては一つずつ text/plain で送ろうかとも思いましたが、今後データが増えた時にサーバー側の処理が面倒かなと思い、JSON にまとめることにしました。
画像データ以外は JSON でまとめて送り、画像データはバイナリで送ります。
これをカメラ台数分送ります。カメラ毎に JSON と画像をマッピングする必要がありますが、試行錯誤した結果、name にカメラを識別するためのIDを設定することにしました。つまり、name の値を見てどのカメラの JSON データ、画像データかを識別する想定です。
後述するサンプルコードで試した結果、ペイロードは以下のような形になりました。

--cc874efaa4e6a1e85c14280c96a7b237
Content-Disposition: form-data; name="カメラのID"

{
 "camera_id": "1",
 "datetime": "2021-08-05T17:07:01.388437",
}
--cc874efaa4e6a1e85c14280c96a7b237
Content-Disposition: form-data; name="カメラのID"; filename="ファイル名"
Content-Type: image/jpeg

<ここに画像のバイナリデータが入る>
--cc874efaa4e6a1e85c14280c96a7b237--

複数カメラ分のデータを送信した場合、並びは以下ようになりました。

１台目のカメラの JSON データ
２台目のカメラの JSON データ
１台目のカメラの画像データ
２台目のカメラの画像データ

name でどのカメラかを判別できるので、基本的にこの並びは意識しなくても大丈夫でした。

サンプルコード

Python での実装例です。

クライアント側

上記のリクエストを requests モジュールを使って送信するサンプルです。

import requests
import json
from datetime import datetime

if __name__ == '__main__':
 data = {}
 files = {}
 # 複数カメラを想定して送信
 for camera_id in ['hoge', 'piyo']: # 各カメラのID
 # 適当なテキストデータ
 json_data = {
 'camera_id': camera_id,
 'datetime': datetime.now().isoformat()
 }
 # 適当な画像ファイルを読み込む
 image = None
 filename = 'send_image.jpg'
 with open(filename, 'rb') as f:
 image = f.read()

 # 送信
 # data,files は dict 型でなければならないので、カメラIDをキーとして渡すことにした。このキーが name に設定される
 data[camera_id] = json.dumps(json_data), # dict -> str への変換
 # filename や Content-Type を指定して送りたい場合
 files[camera_id] = (filename, image, 'image/jpeg')
 # 画像のみで送りたい場合。filename は name と同じになり、Content-Type は付与されなかった
 #files[camera_id] = image
 res = requests.post(f'http://localhost:8000', files=files, data=data)
 print(res)

サーバー側

上記のリクエストを Flask で受信するサンプルです。

import json
from flask import Flask, request

if __name__ == '__main__':
 app = Flask(__name__)

 @app.route('/', methods=['POST'])
 def index():
 print(request.headers)
 #print(request.get_data()) # 生データ
 # JSON データの受け取り
 for key, value in request.form.items():
 json_data = json.loads(value) # str から dict への変換
 print(f'json, key={key}:, value={json_data}, type={type(json_data)}')
 # 画像データの受け取り
 for key, value in request.files.items():
 print(f'image, key={key}, type={type(value)}') # FileStorage 型
 #print(value.headers)
 # ファイルに保存して確認
 with open(f'{key}.jpg', 'wb') as f:
 f.write(value.read())
 # ファイルの保存だけなら以下でも可
 #value.save(f'{key}.jpg')
 return {}, 200

 app.run(port=8000, debug=True)

OpenAPI で multipart/form-data を記述する

OpenAPI で API の仕様書を作成しているのですが、multipart/form-data は以下のように記述するようです。
ただ、上述したような name をカメラのIDとするような記述はできないようです。
ここでは json_data image という値で記述しています。

また、Content-Type を記述したい場合は encoding を使うそうですが、Swagger で試しに送信しても付与されていませんでした。あと、Redoc ではリクエストボディの内容が表示されませんでした。
``multipart/form-data` 自体に対応していないのかもしれません。

/endpoint:
 post:
 summary: サンプル
 description: 説明
 requestBody:
 content:
 multipart/form-data:
 schema:
 type: object
 required:
 - json_data
 - image
 properties:
 data:
 type: object
 required:
 - camera_id
 - datetime
 description: 画像以外のデータ(JSON)
 properties:
 camera_id:
 type: string
 description: カメラの識別子
 example: 'hoge'
 datetime:
 type: string
 format: date-time
 description: 画像の取得日時(ISO8601)
 example: '2021-08-05T17:07:01.388437'
 image:
 type: string
 format: binary
 description: 画像データ(バイナリ)
 encoding:
 image:
 contentType: image/jpeg;

参考 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

Ubuntu の IP アドレスを固定化する

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

いつもは GUI で設定するのですが、あるとき IP アドレスを変更しても再起動後に元に戻ってしまうという現象が発生して悩んでいました。
調べたら他の人が IP アドレスを固定化してたのが原因だとわかったので、ついでにそのやり方をメモしておきます。

環境

Ubuntu 20.04

設定方法

/etc/netplan/ に yaml ファイルを作成します。

ここに作成したファイルが名前順に読み込まれ、後に読み込まれた内容のほうが優先されるようです。

Ubuntu Desktop の場合、デフォルトで 01-network-manager-all.yaml があり、ネットワークマネージャーでの設定が反映されるようになっています。

IP アドレスを固定化したい場合は、/etc/netplan/99_config.yaml など、後に読み込まれるようなファイル名でファイルを作成し、設定を上書きしてやるそうです。
yaml ファイルの書き方なども含め、公式ドキュメントは以下になります。

https://ubuntu.com/server/docs/network-configuration

例えば以下のような感じです。

network:
 version: 2
 ethernets:
 eth0:
 addresses:
 - 192.168.1.10/24
 gateway4: 192.168.1.1
 optional: true

参考 URL

Redmine のチケットを一括で他のプロジェクトに移動させる

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

ちょっとだけ迷ったのでメモです。

チケットの一覧で、チケットを複数選択
右クリックして「編集」を選択
プロジェクトを変更する

参考 URL

https://linkerdesign.github.io/journal/2013/01/redmine.html

Redmine に Git のリポジトリを追加したら internal error が表示される

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

私の場合ですが、タグ名に日本語を使っていたのが原因のようでした。

環境は以下です。

Redmine 3.4.2
Git 1.8.3.1

ちょっと古いバージョンなので最新バージョンではわかりませんが、この環境下では、ブランチやタグの名前に日本語を使っていると internal error となるようです。
Redmine のログを見ていてタグの表示でエラーになっているっぽかったので気が付きました。

参考 URL

https://plugins.co.jp/2015/05/git%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%AB%E6%97%A5%E6%9C%AC%E8%AA%9E%E5%90%8D%E3%82%92%E3%81%A4%E3%81%91%E3%82%8B%E3%81%A8redmine%E3%81%AE%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA/

Redmine に Git のリポジトリを追加したら 404 エラーが表示される

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

まずはファイルパスが正しいかを疑うべきですが、それが正しい場合はアクセス権が原因の可能性があります。

例えば、私の場合、/home/username/xxxx.git という場所にベアリポジトリを作成していたのですが、xxxx.git のアクセス権しか変更していませんでした。

$ sudo chmod o+rx xxxx.git

しかし、その一つ上の /home/username にアクセス権が設定されていなかったため、Redmine からは見ることができなかったようです。
以下のように設定変更すれば解決しました。

$ sudo chmod o+rx /home/username

参考 URL

https://www.pistolfly.com/weblog/2010/11/redminegit.html

GitLab でプライベートリポジトリの分も草を生やす

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

GitLab のプロフィールに表示されるコミットグラフですが、デフォルトでは自分以外の人からは Public なリポジトリの分しか見えません。

Private なリポジトリのコミット分も見えるようにするには、以下の設定を変更します。

Preferences > Profile > Private contributions

参考 URL

https://www.igorkromin.net/index.php/2018/09/13/gitlab-finally-shows-private-project-contributions-in-the-profile-commit-graph/

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

Jetson Xavier NX でルートファイルシステムを overlayroot で読み込み専用に設定する

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

以前、Ubuntu で overlayroot を使ってルートファイルシステムを読み込み専用にしてみたのですが、Jetson Xavier NX で同じように試してみたところ、それだけではだめでした。

恐らくですが、ブートローダーが EXTLINUX であることが原因のような気がしています。

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/uboot_guide.html#wwpID0E0YD0HA

Jetson Xavier NX ではどうやってやればいいのかググってみると、NVIDIA のフォーラムで議論されているのが見つかりました。

その中で、解決策として提示されていたのが以下です。

https://github.com/negachov/overlayroot-jetpack

環境

Jetson Xavior NX
Ubuntu 18.04
JetPack 4.5.1

overlayroot のインストールと有効化

以下の記事を参考にしてください。

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

Jetson Xavier NX ではこれに加え、次のことが必要でした。

/boot/initrd の置き換え

GitHub にスクリプトが公開されているので、まずこれをクローンします。

$ git clone https://github.com/negachov/overlayroot-jetpack

あとは以下を実行するだけです。

$ cd overlayroot-jetpack
$ sudo ./update-initramfs-jetpack
$ reboot

これで、再起動後に overlayroot が有効になっていました。

参考 URL

Ubuntu のファイルシステムを overlayroot で読み込み専用にする

Mon, 25 Apr 2022 00:00:00 +0900

電源ブチ切り対策の一環として、overlayroot で Ubuntu の rootfs を read only にしてみました。

やり方はいろいろググってみましたが、以下のサイトがとても参考になりました。

環境

Ubuntu 20.04 (デスクトップ版)

現在の状態を確認

mount コマンドで確認してみます。

$ mount

抜粋ですが、以下の状態が確認できます。

/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)

overlayroot のインストール

サーバー版には最初からインストールされているそうですが、デスクトップ版にはインストールされていないので、apt でインストールします。

$ sudo apt install overlayroot

overlayroot の有効化

overlayroot を有効化するには、以下のいずれかの対応が必要だそうです。

カーネルパラメーターに overlayroot=XXX を指定する
/etc/overlayroot.local.conf に overlayroot="XXX" を指定する
/etc/overlayroot.conf に overlayroot="XXX" を指定する

設定内容は上位のほうが優先されるそうです。
今回は /etc/overlayroot.local.conf に設定を追加します。
まずはエディタで開きます。

$ sudo gedit /etc/overlayroot.local.conf

以下を追記します。

overlayroot="tmpfs"

コマンド一発でやるなら以下です。

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

tmpfs はメモリ上に作成ファイルシステムで、一時的にデータを格納するために使われます。

https://linuc.org/study/knowledge/441/

Linux ではマウントするファイルシステムの情報が /etc/fstab に書かれていますが、ここが overlayroot における下位レイヤーとなり、読み込み専用レイヤーとなります。
そして、先ほど追記した tempfs が上位レイヤーとなり、書き込み可能レイヤーとなります。
ここらへんは後述するように mount コマンドで確認可能です。

ただし、tmpfs はメモリ上に作成されたファイルシステムなので、再起動時にはデータは消えます。

ルートファイルシステムのみを読み取り専用にする

パーティションを分けている場合などで、ルートファイルシステムのみを読み取り専用にするためには、/etc/overlayroot.local.conf に tmpfs:recurse=0 を指定するらしいです。
コマンド一発でやる場合は以下。

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

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

これで再起動すれば、ルートファイルシステムのみが読み取り専用となり、他のパーティションは読み書き可能な状態となります。

確認

先ほどと同じように mount コマンドで確認してみます。

$ mount

抜粋ですが、以下の状態が確認できました。

/dev/sda2 on /media/root-ro type ext4 (ro,relatime)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime,inode64)
overlayroot on / type overlay (rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_)

ルートファイルシステムが /media/root-ro に読み込み専用(ro)の下位レイヤー(lowerdir) として設定され、tmpfs が /media/root-rw/overlay に書き込み可能(rw)な上位レイヤー(upperdir) して設定されているのが確認できます。

ファイルが消えることを確認

ついでに、ホームディレクトリに適当にファイルを作成し、再起動時にファイルが消えていることを確認します。

overlayroot の無効化

/etc/overlayroot.local.conf を削除するか、/etc/overlayroot.local.conf を編集して中身を overlayroot="" に変更すれば、overlayroot の無効化されます。

しかし、現在は overlayroot が有効化になっている状況なので、このまま変更しても再起動後にはまた元に戻ってしまいます。
そのため、この変更は一時的に書き込みを許可した状態で行う必要があります。
一時的に書き込み可能な状態にするには以下のコマンドを実行します。

$ sudo overlayroot-chroot

そして、/etc/overlayroot.local.conf を削除するか、/etc/overlayroot.local.conf を編集して中身を overlayroot="" に変更します。

# rm /etc/overlayroot.local.conf

exit でシェルから抜ければ書き込み可能状態は終了します。

# exit

再起動後、overlayroot が無効状態になっています。

GRUB メニューで時間がかかることの対策

overlayroot を有効にした状態で再起動すると、GRUB メニューが表示され、30秒ほど待たされるようになります。
詳細は以下をご参照ください。

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

起動が30秒も遅くなるのは困るので、以下を参考にして GRUB の設定を変更しました。

※以下は overlayroot を無効にした状態で行う必要があります！

/etc/default/grub をエディタで開きます。

$ sudo nano /etc/default/grub

以下を追記します。

GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT

設定を反映するために以下のコマンドを実行します。

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

これで overlayroot を有効にしても起動時間は変わらなくなりました。

参考 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

Ubuntu に GitLab-Runner を直接インストールする

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

docker で GitLab-Runner を動かしたことはありましたが、今回初めてホストに直接インストールしました。

公式ドキュメントは以下です。

https://docs.gitlab.com/runner/install/

インストール

apt でインストール

まずはリポジトリを追加します。

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

apt でインストールします。

$ sudo apt-get install gitlab-runner

しかし、この方法でインストールしたら結構古いバージョン (11.2.0) がインストールされてしまいました。
最新のバージョンは 14.9.1 のはずなんですが・・・。

今動かしている GitLab と互換性がなく上手く動かなったので、最終的には次に示すように deb パッケージからインストールしました。

deb パッケージからインストール

https://docs.gitlab.com/runner/install/linux-manually.html

ドキュメントだと curl を使うようになっていますが、上手くダウンロードできなかったのと、環境変数 arch が空だったので、以下のコマンドでダウンロードしました。

$ wget "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"

次のコマンドでインストールします。

$ dpkg -i gitlab-runner_amd64.deb

GitLab への登録

インストールが完了したら Gitlab-Runner を GitLab に登録します。

https://docs.gitlab.com/runner/register/index.html#linux

$ sudo gitlab-runner register

対話形式で入力していきます。

まず、GitLab の URL を指定します。

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.example

次にトークンを入力します。
トークンは GitLab に管理者でログインし、Menu > Admin > Runner で確認できます。

Please enter the gitlab-ci token for this runner:
U6YYzWyiQYzzfCdDH1dv

ランナーの詳細を入力します。

Please enter the gitlab-ci description for this runner:

ランナーを識別するためのタグを指定します。

Please enter the gitlab-ci tags for this runner (comma separated):

次はオプションなので何も入力せず進みました。

Enter optional maintenance note for the runner:

最後にスクリプトの実行方法を指定します。
今回はホスト上で直接実行させたかったので、shell を指定します。

Please enter the executor: virtualbox, docker+machine, docker, docker-ssh, parallels, kubernetes, shell, ssh, docker-ssh+machine:

GitLab の Menu > Admin > Runner で登録されたことが確認できます。

参考 URL

TortoiseGit で過去のコミットの作者（コミッター）を修正する

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

間違ったアカウント（メールアドレス）でコミットしてしまった場合に、後から TortoiseGit で修正する方法です。

TortoiseGit で過去のコミットメッセージを変更する方法を以下の記事にまとめていますが、

TortoiseGit でコミットメッセージを変更する

コミットメッセージではなく、コミッターの情報を変更したい場合、ここにもう少し手順が必要です。

まずはコミットメッセージを修正する画面を表示する

上記のページを参考に、まずはコミットメッセージを修正する画面を表示します。

そしたら、「コミットを編集/分割する」にチェックを入れて「Amend」をクリックします。

すると、通常コミット時と同じ画面が表示されるので、「作者を設定」にチェックを入れ、右の欄にユーザー名とメールアドレスを入力してコミットします。

「他のコミットを追加しますか？」という画面が表示されますが、コミッターの修正だけであれば「いいえ」を選択します。

他のコミットも編集する場合は同様に修正していきます。
以上です。

git で clone する場合に 503 エラーが表示される

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

ローカルネットワークにある GitLab からクローンをしようとした際、503 エラーが表示されました。

ググってみるとプロキシ設定が原因という記事が出てきますが、一応プロキシ設定はしているつもりでした。

しかし、どうやら Git はワイルドカードを使ったプロキシ設定を認識してくれないようです。

今回、環境変数 no_proxy に 192.168.1.* のように設定していたのですが、これを 192.168.1.2 のように指定すると正しく表示されました。

[PySide] ARM アーキテクチャ環境に PySide をインストールできない？

Mon, 11 Apr 2022 00:00:00 +0900

pip で pyside2 および pyside6 をインストールしようとすると失敗しました。

デバイスは Jetson Xavier NX です。
表示されたエラーは以下です。

# pip install pyside2
ERROR: Could not find a version that satisfies the requirement pyside2 (from versions: none)
ERROR: No matching distribution found for pyside2

調べた感じ、どうやら ARM アーキテクチャの場合、pip ではインストールできない？

PySide2 であれば、一応 apt でビルド済みパッケージをインストールすることはできました。

$ sudo apt install python3-pyside2*

しかし、動かしたいアプリは PySide6 を使っており、PySide6 についてはパッケージが見当たりませんでした。

参考 URL

Ubuntu に SSD をマウント

Sat, 09 Apr 2022 00:00:00 +0900

Ubuntu 20.04 のマシンに 2.5インチの SSD を追加し、起動時に自動でマウントするようにしました。

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

https://qiita.com/suisuina/items/7b55a640fdd6b299aa46

手順

UUID の確認

GUI で確認

Ubuntu の場合、メニューから disks を起動すれば、GUI で確認可能です。

コマンドで確認

まずは以下のコマンドでウントしたい SSD のパスを探します。

$ sudo fdisk -l

...

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 312580095 312578048 149.1G 83 Linux

今回は /dev/sda1 でした。
次に以下のコマンドで UUID を確認します。

$ sudo blkid /dev/sda1
/dev/sda1: LABEL="ssd" UUID="74172d4c-526a-42ac-9215-b6ea2dd93d9e" TYPE="ext4" PARTUUID="cb5573bc-01"

起動時にマウントするように設定

/etc/fstab を編集します。

$ sudo nano /etc/fstab

以下を追記します。

UUID=XXXXX /mnt/ssd auto defaults 0 0

今回マウント先は /mnt/ssd としました。

再起動して確認します。

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

Ubuntu 20.04 に古い NVIDIA Driver と CUDA をインストール

Wed, 30 Mar 2022 00:00:00 +0900

古いグラフィックボードが手に入ったので、それに対応した NVIDIA Driver および CUDA をインストールしたときのメモです。

環境

Ubuntu 20.04
GPU：NVIDIA Quadro 2000

NVIDIA Driver のインストール

以下のコマンドでインストールするドライバーのバージョンがわかります。

$ ubuntu-drivers devices

または、以下のページで必要なドライバーのバージョンを調べることもできます。

https://www.nvidia.com/Download/index.aspx

以上より必要なドライバーは 390 だとわかりました。
ドライバーは上記のページからダウンロードできますが、Ubuntu の場合は apt でインストールしたほうが楽です。

$ sudo apt -y install nvidia-driver-390

一度再起動し、nvidia-smi でドライバーが正しくインストールされたか確認します。

$ nvidia-smi
Tue Mar 15 13:51:47 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.144 Driver Version: 390.144 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Quadro 2000 Off | 00000000:01:00.0 On | N/A |
| 30% 48C P12 N/A / N/A | 577MiB / 964MiB | 0% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1193 G /usr/lib/xorg/Xorg 141MiB |
| 0 2102 G /usr/lib/xorg/Xorg 220MiB |
| 0 2276 G /usr/bin/gnome-shell 206MiB |
+-----------------------------------------------------------------------------+

CUDA のインストール

NVIDIA Driver と CUDA のバージョンの関係は以下で確認できます。

https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html

今回インストールした NVIDIA Driver は 390.144 なので、CUDA は 9.1 インストールします。

CUDA のインストール方法ですが、以下でプラットフォームに応じた方法を調べることができます。

https://developer.nvidia.com/cuda-downloads

Ubuntu 20.04 では以下が表示されました。

$ wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin
$ sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600
$ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/7fa2af80.pub
$ sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ /"
$ sudo apt-get update
$ sudo apt-get -y install cuda

しかし、このコマンドでは CUDA のバージョンが指定されていないため、実行してしまうと最新の CUDA がインストールされてしまいます。
なので、次に示すように、バージョン 9.1 を指定してインストールしてやります。

CUDA 9.1 のインストール

CUDA 9.1 をインストールしたいところですが、apt でインストールできる CUDA の一覧を見てみても 9.1 はありません。
なので、以下を参考に Ubuntu 16.04 用のパッケージをインストールしました。

$ curl -sL http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub | sudo apt-key add

$ wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo apt update

$ sudo apt --fix-broken install
$ sudo apt install cuda-toolkit-9-1
$ sudo reboot
$ rm cuda-repo-ubuntu1604_9.1.85-1_amd64.deb

注意点として、apt で cuda-9-1 をインストールすると NVIDIA Driver も最新に更新されてしまうので、cuda-toolkit-9-1 をインストールする必要があります。

https://zenn.dev/takeshita/articles/a02402e59d72a7

インストールが完了したら、~/.bashrc の末尾に以下を追記します。

export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"

ここで再起動します。

CUDA バージョンの確認

nvidia-smi で確認できるはずなのですが、私の環境では何も表示されました。
ただ、nvcc では確認できたので、インストールはされているんじゃないかと。

$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Nov__3_21:07:56_CDT_2017
Cuda compilation tools, release 9.1, V9.1.85

また、以下でも確認できます。

$ cat /usr/local/cuda/version.txt
CUDA Version 9.1.85

CUDA のインストール後に NVIDIA Driver がおかしくなってしまった場合

前述したように、NVIDIA Driver と CUDA のバージョンが合っていなければ動作がおかしくなります。

以下を参考に NVIDIA Driver と CUDA を削除してからインストールをやり直す必要があります。

https://qiita.com/not_charge/items/dce7512544a7ead04bca

$ sudo apt-get --purge remove nvidia-*
$ sudo apt-get --purge remove cuda-*

docker コンテナ内で GPU が使えるか確認しようとして諦めた

せっかく CUDA がインストールできたので、機械学習で GPU が使えそうか確認します。
まず pytorch を使い、ホスト上で以下のコードで確認してみました。

import torch
print(torch.cuda.is_available())

すると、以下のようにエラーが表示されました。

UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 9010). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at /pytorch/c10/cuda/CUDAFunctions.cpp:115.)
 return torch._C._cuda_getDeviceCount() > 0

PyTorch のバージョンも CUDA に合わせる必要があるようです。
以下のページを参考に pytorch のバージョンを指定してインストールしてみます。

https://varhowto.com/install-pytorch-cuda-9-1/

すると以下のエラーが表示されました。

$ pip3 install torch==1.1.0 torchvision==0.3.0 -f https://download.pytorch.org/whl/cu90/torch_stable.html
Looking in links: https://download.pytorch.org/whl/cu90/torch_stable.html
/usr/share/python-wheels/urllib3-1.25.8-py2.py3-none-any.whl/urllib3/connectionpool.py:999: InsecureRequestWarning: Unverified HTTPS request is being made to host '172.20.16.253'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
ERROR: Could not find a version that satisfies the requirement torch==1.1.0 (from versions: 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.7.0, 1.7.1, 1.8.0, 1.8.1, 1.9.0, 1.9.1, 1.10.0, 1.10.1, 1.10.2, 1.11.0)
ERROR: No matching distribution found for torch==1.1.0

ここらへんから面倒になり、先に docker コンテナを作ることにしました。
まずは NVIDIA Container Toolkit をインストールしようと以下のページを見ると、

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

動作要件が以下のようになっていました。

GNU/Linux x86_64 with kernel version > 3.10
Docker >= 19.03 (recommended, but some distributions may include older versions of Docker. The minimum supported version is 1.12)
NVIDIA GPU with Architecture >= Kepler (or compute capability 3.0)
NVIDIA Linux drivers >= 418.81.07 (Note that older driver releases or branches are unsupported.)

というわけでここで諦めました。

参考 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

Markdown で外部の Markdown ファイルを読み込んで表示

Thu, 24 Mar 2022 00:00:00 +0900

Markdown 自体に外部ファイルを読み込んで表示する構文はないようです。

しかし、VSCode の Markdown Preview Enhanced というプラグインでは、以下のようにして外部ファイルを読み込んでプレビュー表示することができます。

@import "hoge.md"

詳しい使い方は以下に記載されています。

https://github.com/shd101wyy/markdown-preview-enhanced/blob/master/docs/ja-jp/file-imports.md

参考 URL

https://github.com/shd101wyy/markdown-preview-enhanced/blob/master/docs/ja-jp/file-imports.md

[Python] `most likely due to a circular import` が表示されたときの対処法

Wed, 23 Mar 2022 00:00:00 +0900

コードを確認しても正しいはずなのにこのエラーが表示されて困ったことがありました。

原因は、モジュール名とファイル名が被っていたことでした。

例えば、ファイル名を pandas.py とかにして、その中で以下のように pandas を使っていたりするとこのようなエラーが表示されます。

import pandas as pd

df = pd.DataFrame([0,1,2])
print(df)

AttributeError: partially initialized module 'pandas' has no attribute 'DataFrame' (most likely due to a circular import)

imoprt pandas で自身のファイルを読み込むことになり、再帰読み込みになってしまっているからです。
知らないと結構はまることになるやつだと思います。

Windows PC から NAS に接続できなくなった

Sat, 19 Mar 2022 00:00:00 +0900

ちょっと古めの NAS を持っているのですが、Windows 10 の PC からアクセスできなくなりました。

以前はアクセスできていたはずなのですが、いつの間にかアクセスできなくなっていました。スマホからはアクセスできているので機器の故障ではなく、またネットワークに問題がないことも確認済みです。

んで、いろいろ調べていたのですが、どうやらその NAS には SMB1 のプロトコルでアクセスする必要があるみたいで、Windows 10 では機能を有効化しないといけないようです。

上述したように以前はアクセスできていたはずなんですけど・・・、Windows Update かなんかで設定が変わったんですかね？

[スタート]-[Windows システムツール]-[コントロールパネル] を開く
[プログラム]-[プログラムと機能] を開く
[Windows の機能の有効化または無効化] をクリック
「SMB 1.0/CIFS ファイル共有のサポート」の「SMB 1.0/CIFS クライアント」にチェックを入れて [OK] をクリック

1. [今すぐ再起動]をクリックする。

再起動後にアクセスできるようになりました。

参考 URL

[Python] NumPy 入門

Mon, 14 Mar 2022 00:00:00 +0900

Python で高速に数値計算を行うためのライブラリである NumPy の基本的な使い方です。

環境

Python 3.8.10
numpy 1.22.2

インストールとインポート

$ pip install numpy

numpy をインポートする際、慣例的に np とすることが多いそうです。

import numpy as np

配列の作成

NumPy 配列は numpy.array で作成します。
戻り値の型は numpy.ndarray となります。

import numpy as np

# 一次元配列
arr1 = np.array([1,2,3])
print(type(arr1))
print(arr1)

# 二次元配列
arr2 = np.array([[1,2,3],[4,5,6]])
print(type(arr2))
print(arr2)

<class 'numpy.ndarray'>
[1 2 3]
<class 'numpy.ndarray'>
[[1 2 3]
 [4 5 6]]

空の配列を作成

import numpy as np

arr = np.empty(0)

print(arr)
print(type(arr))

[]
<class 'numpy.ndarray'>

import numpy as np

#(2,3)の形状の配列
arr = np.empty((2,3))

print(arr)
print(type(arr))

[[6.23042070e-307 1.33512376e-306 1.11261230e-306]
 [7.56577399e-307 9.34600963e-307 1.15860970e-311]]
<class 'numpy.ndarray'>

配列の自動生成

整数型

numpy.arange(開始値,終了値,間隔値) で整数型の配列を作成できます。

import numpy as np

arr = np.arange(21,31,1)
print(arr)

[21 22 23 24 25 26 27 28 29 30]

浮動小数型

numpy.linspace(開始値,終了値,要素数) で浮動小数型の配列を作成できます。

import numpy as np

arr = np.linspace(21,30,10)
print(arr)

[21. 22. 23. 24. 25. 26. 27. 28. 29. 30.]

値が全て0の配列

import numpy as np

arr = np.zeros(5)
print(arr)

[0. 0. 0. 0. 0.]

値が全て1の配列

import numpy as np

arr = np.ones(5)
print(arr)

[1. 1. 1. 1. 1.]

値が全て同じ任意の値の配列

import numpy as np

arr = np.full(5,2)
print(arr)

[2 2 2 2 2]

値が全て同じ任意の値の5x5の配列

import numpy as np

arr = np.full((5,5),2)
print(arr)

[[2 2 2 2 2]
 [2 2 2 2 2]
 [2 2 2 2 2]
 [2 2 2 2 2]
 [2 2 2 2 2]]

単位行列

import numpy as np

arr = np.eye(5)
print(arr)

[[1. 0. 0. 0. 0.]
 [0. 1. 0. 0. 0.]
 [0. 0. 1. 0. 0.]
 [0. 0. 0. 1. 0.]
 [0. 0. 0. 0. 1.]]

転置

以下のいずれかで転置できます。

numpy.transpose(配列)
配列.transpose()
配列.T

上記の３つは同じ挙動です。
また、shape で行列の形状を確認できます。

import numpy as np

# 2x3 の配列を生成
arr = np.random.randint(0,100,(2,3))
print(arr)
print(arr.shape)

# 配列の転置
arr = arr.T
print(arr)
print(arr.shape)

[[96 23 98]
 [62 95 13]]
(2, 3)
[[96 62]
 [23 95]
 [98 13]]
(3, 2)

転置方法を指定

import numpy as np

# 2x3x4 の配列を生成
arr = np.random.randint(0,100,(2,3,4))
print(arr)
print(arr.shape)

# 配列の転置
arr = arr.transpose((1,0,2))
print(arr)
print(arr.shape)

[[[90 75 5 21]
 [ 6 6 98 11]
 [16 75 99 46]]

 [[72 48 52 2]
 [ 2 75 49 29]
 [51 30 41 40]]]
(2, 3, 4)
[[[90 75 5 21]
 [72 48 52 2]]

 [[ 6 6 98 11]
 [ 2 75 49 29]]

 [[16 75 99 46]
 [51 30 41 40]]]
(3, 2, 4)

平坦化

flatten または ravel で配列を一次元化できます。 flatten は配列をコピーして平坦化されるそうですが、ravel は元の配列から変更されるようです。

import numpy as np

# 2x3x4 の配列を生成
arr = np.random.randint(0,100,(2,3,4))
print(arr)
print(arr.shape)

# 配列の平坦化
arr = arr.ravel()
print(arr)
print(arr.shape)

[[[17 6 76 10] 
 [83 33 17 4] 
 [ 5 91 62 26]]

 [[97 33 84 5]
 [ 9 62 95 12]
 [41 93 28 46]]]
(2, 3, 4)
[17 6 76 10 83 33 17 4 5 91 62 26 97 33 84 5 9 62 95 12 41 93 28 46]
(24,)

reshape と resize

reshape と resize はどちらも配列の形状を変更するための関数ですが、reshape は元の配列の要素数が変わるような変更はできないのに対し、resize は好きな形状に変更することができます。

resize で元の配列よりもサイズが小さい場合は値が切り捨てられ、大きい場合は複製されます。

import numpy as np

# 2x3の配列を生成
arr = np.random.randint(0, 100, (2,3))
print(arr)

# 2x3の配列を3x2の配列に変形する
print('reshape 2x3 -> 3x2')
arr1 = np.reshape(arr, (3,2))
print(arr1)

print('resize 2x3 -> 3x2')
arr2 = np.resize(arr, (3,2))
print(arr2)

# 2x3列の配列を2x2の配列に縮小する
print('resize 2x3 -> 2x2')
arr3 = np.resize(arr, (2,2))
print(arr3)

# 2x3列の配列を4x5の配列に拡大
print('resize 2x3 -> 4x5')
arr4 = np.resize(arr, (4,5))
print(arr4)

[[55 23 6]
 [24 44 17]]
reshape 2x3 -> 3x2
[[55 23]
 [ 6 24]
 [44 17]]
resize 2x3 -> 3x2
[[55 23]
 [ 6 24]
 [44 17]]
resize 2x3 -> 2x2
[[55 23]
 [ 6 24]]
resize 2x3 -> 4x5
[[55 23 6 24 44]
 [17 55 23 6 24]
 [44 17 55 23 6]
 [24 44 17 55 23]]

四則演算

配列同士で四則演算を行う方法として、関数を使用する方法と演算子を使用する方法があります。
ただし、乗算などは一般的な行列の積ではなく、同じ行と列の値同士の積となるようです。

import numpy as np
arr1 = np.array([100,200,300])
arr2 = np.array([40,50,60])

print(arr1 + arr2)
print(np.add(arr1, arr2))

# 減算
print(arr1 - arr2)
print(np.subtract(arr1, arr2))

# 乗算
print(arr1 * arr2)
print(np.multiply(arr1, arr2))

# 除算
print(arr1 / arr2)
print(np.divide(arr1, arr2))

[140 250 360]
[140 250 360]
[ 60 150 240]
[ 60 150 240]
[ 4000 10000 18000]
[ 4000 10000 18000]
[2.5 4. 5. ]
[2.5 4. 5. ]

参考 URL

Ubuntu にリモートデスクトップ接続する

Sun, 13 Mar 2022 00:00:00 +0900

Windows から Ubuntu にリモートデスクトップで接続する方法です。

Ubuntu 側

Xrdp サーバーをインストールします。

$ sudo apt -y install xrdp

Windows 側

リモートデスクトップで Ubuntu の IP アドレスを入力して接続します。

画面が真っ暗な場合

同じユーザーで既に Ubuntu にログイン済みの場合、真っ暗な画面が表示されます。

Ubuntu 側で一度ログアウトするか、別途 SSH などで Ubuntu に接続し、以下のコマンドで gnome-session を終了させます。

$ pkill gnome-session

参考 URL

暗号資産（仮想通貨）の年末調整・確定申告メモ

Sat, 12 Mar 2022 00:00:00 +0900

先に言っておきますが、内容の保証はできませんのであしからずご了承ください。

国内取引所から送付される年間取引報告書を使って確定申告を行います。
海外の取引所については利用していないのでわかりません。

年末調整

基礎控除申告書に給与所得以外の所得の合計額を記入する欄があります。
ここに記入すると副業がばれるんじゃないかと心配になりますが、確定申告する場合はここには何も書かなくていいそうです。

ちなみに、副業が会社にばれるのは住民税が理由だそうです。

https://www.aerial-p.com/media/crypto-salaryman.html

確定申告の際に住民税を自分で納付するようにすれば大丈夫だそうです。

確定申告

暗号資産の税務上の取り扱いについては、国税庁が以下に公表しています。

https://www.nta.go.jp/publication/pamph/pdf/virtual_currency_faq_03.pdf

暗号資産に関する所得の計算に当たっては、国税庁が公表している暗号資産の計算書を使うと便利だそうです。

https://www.nta.go.jp/publication/pamph/shotoku/kakuteishinkokukankei/kasoutuka/index.htm

上記のページに書いてありますが、暗号資産交換業者から送付される年間取引報告書を利用して計算する場合には、「総平均法用」の計算書を使います。

申告書の作成

e-Tax で行います。

https://www.e-tax.nta.go.jp/index.html

「各ソフト・コーナー」＞「確定申告書作成コーナー」を選択します。

「作成開始」から提出方法を選択し、方法に応じた認証等を行います。

申告書の作成で、「所得税」を選択します。

収入金額・所得金額の入力

「給与所得」に源泉徴収票を参考に入力
「雑所得」＞「その他」に計算した暗号資産の所得を入力

入力方法については以下のページが参考になりました。

必要経費について

以下が参考になりました。

https://coincheck.com/ja/article/411#i3

参考 URL

https://www.cryptact.com/journal/https-www-cryptact-com-journal-02howto-cryptocurrency-taxfiling

[PySide] FlowLayout を作成する

Tue, 08 Mar 2022 00:00:00 +0900

Qt でウィンドウの幅によって列数がレスポンシブに変わる（自動で改行される）ようなレイアウトを組むには自分で作成する必要があるみたいです。

こういうレイアウトを Flow Layout というようです。

この Flow Layout を、QLayout を継承して作成する方法が公式ドキュメントに載っています。

https://doc.qt.io/qt-5/qtwidgets-layouts-flowlayout-example.html

ただ、私の環境ではこのコードをそのまま PySide で実装しても細かい部分の挙動がおかしかったので、以下のページも参考にしつつ修正しました。

環境

Python 3.8.10
PySide 6.2.2.1

サンプルコード

以下が作成した FlowLayout クラスです。
解説などは上記のページに載っているので割愛します。

import sys
from PySide6.QtWidgets import QApplication, QSizePolicy, QWidget, QLayout, QLayoutItem, QPushButton, QScrollArea
from PySide6.QtCore import (Qt, QSize, QRect, QPoint)

class FlowLayout(QLayout):

 def __init__(self, parent=None, margin:int=0, hspacing:int=-1, vspacing:int=-1):
 super().__init__(parent)
 self.setContentsMargins(margin, margin, margin, margin)

 self.__itemlist = []
 self.__hSpacing = hspacing
 self.__vSpacing = vspacing

 def __del__(self):
 item = self.takeAt(0)
 while item:
 del item
 item = self.takeAt(0)

 def addItem(self, item:QLayoutItem):
 self.__itemlist.append(item)

 def count(self):
 return len(self.__itemlist)

 def itemAt(self, index:int):
 if 0 <= index and index < len(self.__itemlist):
 return self.__itemlist[index]
 return None

 def takeAt(self, index:int):
 if 0 <= index and index < len(self.__itemlist):
 return self.__itemlist.pop(index)
 return None

 def expandingDirections(self):
 return Qt.Orientations(Qt.Orientation(0))

 def hasHeightForWidth(self):
 return True

 def heightForWidth(self, width:int):
 height = self.doLayout(QRect(0, 0, width, 0), True)
 return height

 def setGeometry(self, rect:QRect):
 super().setGeometry(rect)
 self.doLayout(rect, False)

 def sizeHint(self):
 return self.minimumSize()

 def minimumSize(self):
 size = QSize()
 for item in self.__itemlist:
 size = size.expandedTo(item.minimumSize())
 margins = self.contentsMargins()
 size += QSize(margins.left() + margins.right(), margins.top() + margins.bottom())
 return size

 def doLayout(self, rect:QRect, testOnly:bool):
 left, top, right, bottom = self.getContentsMargins()
 effectiveRect = rect.adjusted(+left, +top, -right, -bottom)
 x = effectiveRect.x()
 y = effectiveRect.y()
 lineHeight = 0

 for item in self.__itemlist:
 wid = item.widget()
 spaceX = self.__hSpacing
 if spaceX == -1:
 spaceX = wid.style().layoutSpacing(QSizePolicy.PushButton, QSizePolicy.PushButton, Qt.Horizontal)
 spaceY = self.__vSpacing
 if spaceY == -1:
 spaceY = wid.style().layoutSpacing(QSizePolicy.PushButton, QSizePolicy.PushButton, Qt.Vertical)

 nextX = x + item.sizeHint().width() + spaceX
 if nextX - spaceX > effectiveRect.right() and lineHeight > 0:
 x = effectiveRect.x()
 y = y + lineHeight + spaceY
 nextX = x + item.sizeHint().width() + spaceX
 lineHeight = 0

 if not testOnly:
 item.setGeometry(QRect(QPoint(x, y), item.sizeHint()))

 x = nextX
 lineHeight = max(lineHeight, item.sizeHint().height())

 return y + lineHeight - effectiveRect.y() + top + bottom

if __name__ == '__main__':

 class MainWindow(QScrollArea):

 def __init__(self, parent=None):
 super().__init__(parent)

 widget = QWidget()
 flowlayout = FlowLayout(widget, 10, 5)
 for i in range(100):
 button = QPushButton(f"Sample {i}")
 flowlayout.addWidget(button)
 self.setWidgetResizable(True)
 self.setWidget(widget)

 app = QApplication(sys.argv)
 window = MainWindow()
 window.show()
 sys.exit(app.exec())

参考 URL

[Python] tracemalloc を使ってメモリリークの発生箇所を特定する

Sat, 26 Feb 2022 00:00:00 +0900

メモリの使用量が綺麗に右肩上がりになっているアプリがあったので、メモリリークの発生箇所を特定する方法を調べてみたところ、標準モジュールの tracemalloc で出来そうなので、使ってみました。

tracemalloc については以下のページを参考にさせていただきました。

https://kazuhira-r.hatenablog.com/entry/2019/04/19/003328

環境

Python 3.8.10

サンプルコード

スレッド化し、5秒ごとにメモリ使用量トップ10と、メモリ増加量トップ10を表示するようにしてみました。

import tracemalloc
import time
from datetime import datetime
from threading import Thread

class MemoryCheker:

 def __init__(self):
 self.__is_running = False
 self.__snapshot = None

 def start(self):
 print(f'{self.__class__.__name__} start')
 self.__is_running = True
 self.__thread = Thread(target=self.__run)
 self.__thread.start()

 def stop(self):
 print(f'{self.__class__.__name__} stopping')
 self.__is_running = False
 self.__thread.join()
 print(f'{self.__class__.__name__} stopped')

 def __run(self):

 while self.__is_running:
 snapshot = tracemalloc.take_snapshot()
 top_stats = snapshot.statistics('lineno')
 print(f'[ Top 10 : {datetime.now()}]')
 for stat in top_stats[:10]:
 print(stat)
 if self.__snapshot != None:
 top_stats = snapshot.compare_to(self.__snapshot, 'lineno')
 print('[ Top 10 Difference ]')
 for stat in top_stats[:10]:
 print(stat)
 self.__snapshot = snapshot
 time.sleep(5)

if __name__ == '__main__':

 tracemalloc.start()
 memory_checker = MemoryChecker()
 memory_checker.start()
 
 # do something
 
 memory_checker.stop()

これでメモリリークしている箇所にあたりをつけ、原因を特定することができました。

参考 URL

https://kazuhira-r.hatenablog.com/entry/2019/04/19/003328

[PySide] QListWidget の使い方

Fri, 25 Feb 2022 00:00:00 +0900

QListWidget を使っていていろいろはまったのでメモです。

環境

Python 3.8.10
PySide 6.2.2.1

カスタムウィジェットをセットする

setItemWidget でアイテムとウィジェットを関連付けする必要があります。

custom_widget = CustomWidget()

# Create QListWidgetItem
item = QListWidgetItem(list_widget)
# Set size hint
item.setSizeHint(custom_widget.sizeHint())

# Add QListWidgetItem into QListWidget
self.addItem(item)
self.setItemWidget(item, custom_widget)

先頭行に追加する

insertItem() で 0 行目にアイテムを追加すればいいと思っていたら、実際には最後に追加されてしまいました。
悩んでいたところで以下の記事を見つけたのですが、どうやら QListWidgetItem でアイテムを作成する際、親ウィジェットを指定してはいけないようです。

https://stackoverflow.com/questions/45258159/how-to-add-a-qlistwidgetitem-on-top-of-the-qlistwidget

custom_widget = CustomWidget()

# Create QListWidgetItem
item = QListWidgetItem() # 親を指定しない
# Set size hint
item.setSizeHint(custom_widget.sizeHint())

# Add QListWidgetItem into QListWidget
self.insertItem(0, item)
self.setItemWidget(item, custom_widget)

ちなみに、insertItem よりも setItemWidget を先に処理していると上手く動きませんでした。

アイテムを削除する

takeItem を使います。
削除なのに take というのが分かりづらい・・・。

item = self.takeItem(row)
self.removeItemWidget(item)
del item

ドキュメントによれば、リストから削除されても実体は残っているようなので、del で削除しています。
だから take なのかな？

ちなみに removeItemWidget はアイテムと関連付けられているウィジェットを削除しますが、del item としているので、もしかしたら不要かもしれません。

https://qiita.com/tatsuteb/items/959700c1d7b42c7c8b5a

QListWidget のサイズをコンテンツに合わせる

カスタムウィジェットのサイズに上手く合わないことがあったので、どうしたらいいのか調べていたら、以下の記事を見つけました。

https://stackoverflow.com/questions/6337589/qlistwidget-adjust-size-to-content

以下のように sizeHint() をオーバーライドすればいいようです。

def sizeHint(self):
 s = QSize()
 s.setHeight(super().sizeHint().height())
 s.setWidth(self.sizeHintForColumn(0))
 return s

ただ、私の場合、上記だとウィジェットとスクロールバーが重なって表示されたりしたので、以下のようにスクロールバーの幅も考慮するように変更しました。

def sizeHint(self):
 s = QSize()
 s.setHeight(super().sizeHint().height())
 s.setWidth(self.sizeHintForColumn(0) + self.verticalScrollBar().sizeHint().width() * 2)
 return s

参考 URL

Blogger のテーマが保存できない

Thu, 24 Feb 2022 00:00:00 +0900

Blogger テーマの「HTML を編集」で保存した際、以下のように「更新できません」と表示されどうしようもなくなったことがありました。

何回試しても、「処理しています…」が長く表示された後、「更新できませんでした」と表示されます。

原因ですが、いろいろ試行錯誤してみた結果、どうやらテンプレートの文字数が多すぎたようです。

外部の JavaScript ファイルや CSS ファイルのコードを直接埋め込んでいるところがあったのですが、それを CDN から読み込むように変更したところ、正しく更新できるようになりました。

[PySide] QThread を使って時間のかかる処理をスレッド化する

Sun, 20 Feb 2022 00:00:00 +0900

例えばボタンをクリックしたときに重い処理を実行する場合など、そのまま処理すると GUI が固まってしまうため、スレッド化してやります。

概要

python の標準モジュールに threading がありますが、PySide を使っている場合は QThread を使います。
本質的にはどちらも同じだそうですが、Signal/Slot など、Qt との対話を行うなら QThread を使ったほうが良いようです。

https://stackoverflow.com/questions/1595649/threading-in-a-pyqt-application-use-qt-threads-or-python-threads

ちなみに、Qt には QtConcurrent という QThread よりも高レベルな API がありますが、こちらは PySide では提供されていないようです。

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

https://doc.qt.io/qtforpython/PySide6/QtCore/QThread.html

また、PySide で GUI を止めることなく重い処理をするサンプルとして、以下がありました。

https://doc.qt.io/qtforpython/examples/example_corelib__threads.html

上記のサンプルでは QThread を継承し、run をオーバーライドしていますが、このやり方は良くないそうで、moveToThread を使って処理をスレッドに渡すやり方のほうが一般的なようです。
詳しくは以下で解説されています。

とはいえ、moveToThread を使った公式のサンプルが見当たらなかったので、知らない人は知らないんじゃないかなぁと思ったり・・。

というわけで、QThread と moveToThread 使ったスレッド化のサンプルです。

環境

Python 3.8.10
PySide 6.2.2.1

サンプルコード

解説は後にして、まずはコード全体です。

import sys, threading
from PySide6.QtWidgets import QApplication, QWidget, QPushButton, QLabel, QVBoxLayout
from PySide6.QtCore import Qt, QObject, QThread, Signal, Slot
import shiboken6
import time

class Worker(QObject):
 """バックグラウンドで処理を行うクラス
 """

 countup = Signal(int)

 def __init__(self, parent=None):
 super().__init__(parent)
 self.__is_canceled = False

 def run(self):
 print(f'worker started, thread_id={threading.get_ident()}')
 count = 0
 while not self.__is_canceled:
 count += 1
 self.countup.emit(count)
 time.sleep(0.001)
 print(f'worker finished, thread_id={threading.get_ident()}')

 def stop(self):
 self.__is_canceled = True

class MainWindow(QWidget):
 """メインウィンドウ
 """

 def __init__(self, parent=None):
 super().__init__(parent)

 self.__thread = None

 layout = QVBoxLayout()
 button = QPushButton('Start')
 button.clicked.connect(self.__start)
 layout.addWidget(button)
 button = QPushButton('Stop')
 button.clicked.connect(self.__stop)
 layout.addWidget(button)
 self.__label = QLabel()
 layout.addWidget(self.__label)
 self.setLayout(layout)

 def __start(self):
 """開始
 """
 print(f'start, thread_id={threading.get_ident()}')
 self.__stop()

 self.__thread = QThread()
 self.__worker = Worker()
 self.__worker.moveToThread(self.__thread) # 別スレッドで処理を実行する
 # シグナルスロットの接続（self.__countup をスレッド側で実行させるために Qt.DirectConnection を指定）
 self.__worker.countup.connect(self.__countup, type=Qt.DirectConnection)
 # スレッドが開始されたら worker の処理を開始する
 self.__thread.started.connect(self.__worker.run)
 # ラムダ式を使う場合は Qt.DirectConnection を指定
 #self.__thread.started.connect(lambda: self.__worker.run(), type=Qt.DirectConnection) 
 # スレッドが終了したら破棄する
 self.__thread.finished.connect(self.__worker.deleteLater)
 self.__thread.finished.connect(self.__thread.deleteLater)

 # 処理開始
 self.__thread.start()

 def __stop(self):
 """停止
 """
 print(f'stop, thread_id={threading.get_ident()}')
 if self.__thread and shiboken6.isValid(self.__thread):
 # スレッドが作成されていて、削除されていない
 if self.__thread.isRunning() or not self.__thread.isFinished():
 print('thread is stopping')
 self.__worker.stop()
 self.__thread.quit()
 self.__thread.wait()
 print('thread is stopped')

 def __countup(self, count):
 """countup シグナルに対する処理
 """
 self.__label.setText(f'count={count}, thread_id={threading.get_ident()}')

 def closeEvent(self, event):
 """closeEvent のオーバーライド（ウィンドウを閉じたときにスレッドを終了させる）
 """
 self.__stop()

if __name__ == "__main__":
 app = QApplication(sys.argv)
 main_window = MainWindow()
 main_window.show()
 sys.exit(app.exec())

カウントアップした変数の内容を表示するだけのシンプルなコードです。
スロットがどのスレッドで実行されているかわかるように、スレッドIDも表示しています。

簡単な解説

Worker が別スレッドで行いたい処理ですが、こいつ自身はスレッド云々を意識せず（どこで実行されるかを意識せず）、処理内容のみを責務としています。
どこで実行するかを意識するのは、処理を開始する MainWindow です。

シグナルスロット接続時の注意

以下の部分です。

self.__worker.countup.connect(self.__countup, type=Qt.DirectConnection)

self.__countup は MainWindow 内の関数なので、普通に接続するとメインスレッド側で処理が行われてしまいます。
これをスレッド側で処理が行われるようにするには Qt.DirectConnection を指定する必要があります。
countup シグナルはスレッド側で動いている Worker で emit されるので、Qt.DirectConnection を指定することでシグナルを emit するスレッド側での実行を指定することになります。
ここらへん、以下で詳しく解説されています。

ちなみに、以下のスレッド開始時の処理ですが、

self.__thread.started.connect(self.__worker.run)

self.__worker は moveToThread でスレッド側で処理を行うように指定しているので、明示的に Qt.DirectConnection を指定しなくてもよいのですが、これを仮に以下のようにラムダ式などを使った場合は、上記と同じ理由で Qt.DirectConnection を指定する必要があります。

self.__thread.started.connect(lambda: self.__worker.run(), type=Qt.DirectConnection)

例えば、self.__worker.run に引数を与えて開始したい場合などはこういうケースもあるのではないかと思います。
でもその場合 moveToThread を使う意味がなくなりそうですが・・・。（実際、moveToThread を使わなくても上手く動きます。）

終了処理

スレッドが終了したら deleteLater でオブジェクトの破棄を行っています。

self.__thread.finished.connect(self.__worker.deleteLater)
self.__thread.finished.connect(self.__thread.deleteLater)

https://tukunen13.hatenablog.jp/entry/2017/05/25/004652

また、スレッドを開始したままウィンドウを閉じたときのために、closeEvent をオーバーライドしてスレッドを停止するようにしています。

オブジェクトの判定

Start ボタンを押したときにスレッドを停止してから再度開始していますが、その際に既にスレッドが破棄されていないかどうか判定しています。
オブジェクトが破棄されているかどうかは shiboken を使います。

https://stackoverflow.com/questions/11328219/how-to-know-if-object-gets-deleted-in-python

スレッドの終了判定

QThread に isRunning と isFinished という関数がありますが、どっちを使えばいいのかいまいち分からなかったので両方見るようにしました。
ここらへん微妙です・・・。

参考 URL

[PySide] QPushButton にレイアウトを設定している場合にサイズがおかしい

Sat, 19 Feb 2022 00:00:00 +0900

QPushButton に QVBoxLayout などを setLayout() で設定している場合に、ボタンの縦のサイズが小さすぎてレイアウトが潰れた状態になりました。

レイアウトのサイズに応じてボタンのサイズを変更するにはどうしたらいいのかと悩んでいたら以下の記事を見つけました。

https://stackoverflow.com/questions/61571582/qt-qpushbutton-vertical-size-fit-to-contents

sizeHint() をオーバーライドし、レイアウトが設定されていればそのサイズを、設定されていなければ基底クラスのサイズを返せばいいようです。

PySide 6.2.2.1

def sizeHint(self):
 if self.layout():
 # the button now has a layout, return its size hint
 return self.layout().sizeHint()
 # no layout set, return the result of the default implementation
 return super().sizeHint()

参考 URL

https://stackoverflow.com/questions/61571582/qt-qpushbutton-vertical-size-fit-to-contents

[Python] マルチスレッド

Fri, 18 Feb 2022 00:00:00 +0900

python でのスレッドの作成、開始、終了の方法です。いつもどうだったっけ？となるので、出来るだけシンプルなコードでメモしておきます。

環境

Python 3.8.10

スレッドの起動と停止

import time
from threading import Thread
from datetime import datetime

class Sample:

 def __init__(self):
 self.__is_running = False

 def start(self):
 print('start')
 self.__is_running = True
 self.__thread = Thread(target=self.__run)
 self.__thread.start()

 def stop(self):
 print('stopping')
 self.__is_running = False
 self.__thread.join()
 print('stopped')

 def __run(self):

 while self.__is_running:
 print(f'{datetime.now()} running')
 time.sleep(1)

if __name__ == '__main__':
 sample = Sample()
 sample.start()
 time.sleep(10)
 sample.stop()

排他処理

上記をベースに、スレッドを複数開始しないように排他をかけてみます。

import time
from threading import Thread, Lock
from datetime import datetime

class Sample:

 def __init__(self):
 self.__lock = Lock()
 self.__is_running = False

 def start(self):
 if self.__is_running:
 print('already running')
 else:
 with self.__lock:
 print('start')
 self.__is_running = True
 self.__thread = Thread(target=self.__run)
 self.__thread.start()

 def stop(self):
 if not self.__is_running:
 print('not running')
 else:
 with self.__lock:
 print('stopping')
 self.__is_running = False
 self.__thread.join()
 print('stopped')

 def __run(self):

 while self.__is_running:
 print(f'{datetime.now()} running')
 time.sleep(1)

if __name__ == '__main__':
 sample = Sample()
 sample.start()
 sample.start()
 sample.start()
 time.sleep(10)
 sample.stop()
 sample.stop()
 sample.stop()

with の代わりに acquire と release を使ってもいいです。

** 出力結果 **

start
already running
already running
2022-02-14 14:29:16.802901 running
...
stopping
stopped
not running
not running

既にスレッド起動中の場合は一度停止してから再起動

上記の print('already running') のところで self.stop() をコールすればよいです。

参考 URL

[PySide] インスタンスが破棄されているかどうかを調べる

Thu, 17 Feb 2022 00:00:00 +0900

PySide を使っていて、既にインスタンスが破棄されているオブジェクトにアクセスした際、以下のようなエラーが表示されます。

RuntimeError: Internal C++ object (PySide6.QtCore.QThread) already deleted.

これを回避するため、インスタンスが破棄されているかどうかを知るにはどうすればいいか調べてみたところ、以下が見つかりました。

https://stackoverflow-com.translate.goog/questions/11328219/how-to-know-if-object-gets-deleted-in-python?_x_tr_sl=en&_x_tr_tl=ja&_x_tr_hl=ja&_x_tr_pto=wapp

shiboken というモジュールを使えばいいそうです。
公式ドキュメントは以下です。

https://doc.qt.io/qtforpython/shiboken6/shibokenmodule.html

環境

PySide 6.2.2.1
Python 3.8.10

サンプルコード

import shiboken6

print shiboken6.isValid(hoge)

参考 URL

[Python] datetime の strftime で Invalid format string になる

Wed, 16 Feb 2022 00:00:00 +0900

strftime で datetime から文字列に変換する際、Ubuntu では上手く動くのに、Windows だと ValueError: Invalid format string のエラーが発生しました。

どうやら Ubuntu と Windows で一部書式が異なるようです。

https://teratail.com/questions/361511

例えば、ゼロパディングをなくしたい場合は、以下のようになります。

# Linux の場合
today.strftime('%-m')

# Windows の場合
today.strftime('%#m')

Python の範囲内であればクロスプラットフォームで動作すると思っていたのにこんな罠があるとは。

上記の例であれば以下のようにすればいいだけですが、

str(today.month)

strftime を使い場合、大抵もっと複雑な書式で指定すると思うので、どう対応すればいいんでしょうね。

参考 URL

https://teratail.com/questions/361511

Ubuntuでデスクトップにアプリのショートカットを作る（デスクトップエントリ）

Sat, 12 Feb 2022 00:00:00 +0900

今までやったことなかったのでメモ。

環境

Ubuntu 20.04

.desktop ファイルの作成

.desktop という拡張子でファイルを作成し、デスクトップに配置します。
内容は以下のように記述します。

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Exec=/home/user/run.sh
Name=Application Name
Comment=Test Application
Icon=/home/user/Pictures/icon.png

内容については省略します。

実行権限の付与

このファイルに実行権限を与えます。

$ chmod 755 test.desktop

デスクトップでこのファイルをダブルクリックすると、「起動を許可」というメニューがあるので、それを選択します。
すると、アイコンが変わり、ダブルクリックでアプリケーションが起動するようになります。

起動の許可が表示されない、テキストエディタが起動する場合

私の場合の例ですが、.desktop ファイルの Exec の項目でシェルスクリプトファイルを指定していた場合に、この状況が発生しました。

Exce で指定しているシェルスクリプトファイルにも実行権限を与えてやると解決しました。

参考 URL

http://appcel.sblo.jp/article/187826978.html

[PySide] Qt Style Sheet を使って UI のデザインを変更する

Fri, 11 Feb 2022 00:00:00 +0900

UI のデザインを変更したい場合、QSS という、CSS とほぼ同じ構文のスタイルシートを使って変更できます。

QSS ファイルの拡張子は qss が一般的なようですが、エディタによっては css のほうが便利かもしれません。
QSS 専用のエディタもあるようです。

https://qiita.com/takavfx/items/f385bd339d9f352d34cf

環境

PySide 6.2.2.1

ファイルの読み込みと適用方法

スタイルシートを読み込み、QApplication に対して setStyleSheet() で設定するとアプリケーション全体へ適用されるようです。

QMainWindow {
 background-color: #444444;
}

import sys
from PySide6.QtWidgets import QWidget, QApplication, QMainWindow, QVBoxLayout, QPushButton
from PySide6.QtCore import Qt

class MainWindows(QMainWindow):
 def __init__(self):
 super().__init__()

 container = QWidget()
 vbox_layout = QVBoxLayout(container)

 button = QPushButton('button0')
 vbox_layout.addWidget(button, alignment=Qt.AlignCenter)

 self.setCentralWidget(container)

if __name__ == "__main__":

 try:
 with open('style.qss', 'r') as f:
 style = f.read()
 except:
 style = ''

 app = QApplication(sys.argv)
 app.setStyleSheet(style)
 window = MainWindows()
 window.show()
 window.resize(360, 240)
 sys.exit(app.exec())

QSS の書き方については以下のページがとても参考になりました。

https://unpyside.com/2021/05/03/qss-basic/

特定のウィジェットにのみ適用する方法

setObjectName() で名前を設定し、IDセレクタを使って指定します。

QMainWindow {
 background-color: #444444;
}

/* ボタン全体へ適用 */
QPushButton {
 background-color: cyan;
 color: #444444;
}

/* button0 のみに適用 */
QPushButton#button0 {
 background-color: magenta;
 color: #ffffff;
}

import sys
from PySide6.QtWidgets import QWidget, QApplication, QMainWindow, QVBoxLayout, QPushButton
from PySide6.QtCore import Qt

class MainWindows(QMainWindow):
 def __init__(self):
 super().__init__()

 container = QWidget()
 vbox_layout = QVBoxLayout(container)

 button = QPushButton('button0')
 button.setObjectName('button0')
 vbox_layout.addWidget(button, alignment=Qt.AlignCenter)

 button = QPushButton('button1')
 vbox_layout.addWidget(button, alignment=Qt.AlignCenter)

 button = QPushButton('button2')
 vbox_layout.addWidget(button, alignment=Qt.AlignCenter)

 self.setCentralWidget(container)

if __name__ == "__main__":

 try:
 with open('style.css', 'r') as f:
 style = f.read()
 except:
 style = ''

 app = QApplication(sys.argv)
 app.setStyleSheet(style)
 window = MainWindows()
 window.show()
 window.resize(360, 240)
 sys.exit(app.exec())

カスタムウィジェットにスタイルを適用する

QWidget 継承して作ったカスタムウィジェットに QSS を適用するには、paintEvent をオーバーライドする必要があります。
これについては以下の記事に書いています。

https://kuttsun.blogspot.com/2022/02/pyside-qss.html

参考 URL

[PySide] カスタムウィジェットに QSS を適用する

Thu, 10 Feb 2022 00:00:00 +0900

QWidget を継承して作成したカスタムウィジェットに Qt Style Sheet を適用するには、paintEvent をオーバーロードする必要があるようです。

https://wiki.qt.io/How_to_Change_the_Background_Color_of_QWidget/ja

環境

PySide 6.2.2.1

サンプルコード

CustomWidget {
 background-color: cyan;
}

import sys
from PySide6.QtWidgets import QWidget, QApplication, QMainWindow, QVBoxLayout, QHBoxLayout, QPushButton, QLabel, QStyleOption, QStyle
from PySide6.QtCore import Qt
from PySide6.QtGui import QPainter

class CustomWidget(QWidget):
 """適当にボタンとラベルと横に並べただけのカスタムウィジェット"""

 def __init__(self):
 super().__init__()

 layout = QHBoxLayout()

 button = QPushButton('button')
 layout.addWidget(button, alignment=Qt.AlignCenter)

 label = QLabel('label')
 layout.addWidget(label, alignment=Qt.AlignCenter)

 self.setLayout(layout)
 
 def paintEvent(self, event):
 opt = QStyleOption()
 opt.initFrom(self)
 painter = QPainter(self)
 style = self.style()
 style.drawPrimitive(QStyle.PE_Widget, opt, painter, self)


class MainWindows(QMainWindow):
 def __init__(self):
 super().__init__()

 container = QWidget()
 vbox_layout = QVBoxLayout(container)

 widget = CustomWidget()
 vbox_layout.addWidget(widget, alignment=Qt.AlignCenter)

 self.setCentralWidget(container)

if __name__ == "__main__":

 try:
 with open('style.qss', 'r') as f:
 style = f.read()
 except:
 style = ''

 app = QApplication(sys.argv)
 app.setStyleSheet(style)
 window = MainWindows()
 window.show()
 window.resize(360, 240)
 sys.exit(app.exec())

カスタムウィジェット内全体に適用

上記のサンプルでは背景色を適用していますが、ボタンとラベルには適用されていません。
これの対応方法は調査中です。

参考 URL

https://wiki.qt.io/How_to_Change_the_Background_Color_of_QWidget/ja

[PySide] 'PySide6.QtCore.Signal' object has no attribute 'connect' のエラーが表示される

Mon, 07 Feb 2022 00:00:00 +0900

PySide で、Signal をコンストラクタで初期化すると 'PySide6.QtCore.Signal' object has no attribute 'connect' のエラーが表示されました。

環境

PySide 6.2.2.1

エラーとなる例

例えば、以下のようなコードではエラーになります。

class Sample(QObject):
 
 def __init__(self):
 super().__init__(None)
 
 self.signal = Signal(int)
 self.signal.connect(self.__slot)

これについて調べると、以下が見つかりました。

https://stackoverflow.com/questions/36559713/pyside-qtcore-signal-object-has-no-attribute-connect

どうやら、シグナルを使うには以下の必要があるようです。

クラス内で定義する必要がある（コンストラクタで初期化ではダメ）
QObject を継承し、super().__init__() をコールする必要がある

解決方法

以下のようにすると上手く動作します。

class Sample(QObject):
 
 signal = Signal(int)
 
 def __init__(self):
 super().__init__(None)

 self.signal.connect(self.__slot)

コンストラクタで for を使ってシグナルを一気に作成したり発報したりしたかったのですが、できないんですかね？

どうしても for で楽がしたい

苦肉の策で、以下のようなコードを思いつきました。

class Sample(QObject):
 
 signal_a = Signal(int)
 signal_b = Signal(int)
 
 def __init__(self):
 super().__init__(None)

 self.__dict__['signal_a'].connect(self.__slot)

 def emit_sample(self, signal_name):
 if signal_name in self.__dict__.keys():
 self.__dict__[signal_name].emit(0)

シグナルの宣言は個別に行う必要がありますが、self.__dict__ でインスタンス変数の一覧を取得し、その中からシグナル名でシグナルを探してきます。
微妙ですね。

参考 URL

https://stackoverflow.com/questions/36559713/pyside-qtcore-signal-object-has-no-attribute-connect

[PySide] ボタンにフォーカスがある場合の点線を消す

Wed, 02 Feb 2022 00:00:00 +0900

CSS を使って以下を指定すれば消せます。

QPushButton:focus {
 outline: none;
}

参考 URL

https://stackoverflow.com/questions/17280056/qt-css-decoration-on-focus

[PySide] QStackedLayout で Alignment を設定したい

Tue, 01 Feb 2022 00:00:00 +0900

QStackedLayout の addWidget では alignment を指定できません。

QVBoxLayout や QHBoxLayout のように alignment を指定したい場合はどうすれいいのか？
ということでググってみたものの情報が少なく、参考になりそうなのは以下くらい。

こういうこと？なんか違う気がする・・・。

import sys
from PySide6.QtWidgets import *
from PySide6.QtCore import Qt
from PySide6.QtCharts import *

class MainWindows(QWidget):
 def __init__(self):
 super().__init__()

 container = QWidget()
 # コンテナを親として QVBoxLayout を作成（つまり、コンテナ配下に QVBoxLayout を作成）
 vbox_layout = QVBoxLayout(container)
 vbox_layout.addWidget(QPushButton('test1'), alignment=Qt.AlignCenter)

 stacked_layout = QStackedLayout()
 stacked_layout.addWidget(container)
 self.setLayout(stacked_layout)

if __name__ == "__main__":
 app = QApplication(sys.argv)
 window = MainWindows()
 window.show()
 window.resize(360, 240)
 sys.exit(app.exec())

一応表示は正しいんですけどね。

参考 URL

[PySide] for 文でシグナルの接続にラムダ式を使う場合の注意

Mon, 31 Jan 2022 00:00:00 +0900

for ループでウィジェットを動的に作成する際、シグナルとの接続でラムダ式を使う場合には注意が必要です。

例えば、以下のコードはラムダ式を使っていますが、

for i in range(5):
 button = QPushButton(f'Button{i}')
 button.clicked.connect(lambda: print(f'Button{i} clicked'))

この場合、どのボタンを押しても Button4 clicked と出力されます。
ラムダ式は遅延評価のためです。

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

https://kuttsun.blogspot.com/2022/01/python-for.html

じゃあデフォルト引数を与えて即時評価してやろう以下のように変更すると、

for i in range(5):
 button = QPushButton(f'Button{i}')
 button.clicked.connect(lambda x=i: print(f'Button{x} clicked'))

今度は ButtonFalse clicked と出力されてしまいました。
QPushButton の clicked シグナルは、ボタンの状態を引数で渡してくるそうなので、デフォルト引数が bool 値で上書きされたためです。
かと言って、引数の数を増やすとエラーになります。

なので、この場合ラムダ式は使えず、functools.partial を使うしかありません。

for i in range(5):
 button = QPushButton(f'Button{i}')
 button.clicked.connect(partial(self.__clicked, i))

以下、動作確認用のコードです。

import sys
from functools import partial
from PySide6.QtWidgets import *

class MainWindow(QMainWindow):
 def __init__(self, parent=None):
 super(MainWindow, self).__init__(parent)

 vbox_layout = QVBoxLayout()
 for i in range(5):
 button = QPushButton(f'Button{i}')
 button.clicked.connect(partial(self.__clicked, i))
 vbox_layout.addWidget(button)
 widget = QWidget()
 widget.setLayout(vbox_layout)
 self.setCentralWidget(widget)

 def __clicked(self, i):
 print(f'Button{i} clicked')

if __name__ == '__main__':

 app = QApplication(sys.argv)
 main_window = MainWindow()
 main_window.show()
 sys.exit(app.exec())

[PySide] QChart のグラフに Tooltip を追加する

Fri, 28 Jan 2022 00:00:00 +0900

グラフにマウスオーバーしたときにツールチップを表示するサンプルです。

とりあえず QToolTip を使って簡単に実装してみました。

https://doc.qt.io/qtforpython/PySide6/QtWidgets/QToolTip.html

他には以下のサンプルとかも見つかりましたが、ちょっと複雑なので・・・。

https://doc.qt.io/qtforpython-6/examples/example_charts__callout.html

環境

PySide 6.2.2.1

サンプル

以前の記事をベースに作成してみました。

https://kuttsun.blogspot.com/2022/01/pyside-qchart.html

QBarSeries と QBarSet のどちらのマウスオーバーでツールチップを表示するかはお好みで。

import sys
from PySide6.QtWidgets import *
from PySide6.QtCore import Qt
from PySide6.QtCharts import *
from PySide6.QtGui import QPainter, QCursor

class BarChartSample(QChartView):
 __categories = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun']
 __samples = {
 'Hoge': [9, 7, 5, 3, 1, 2],
 'Piyo': [3, 5, 8, 13, 8, 5],
 'Fuga': [5, 0, 0, 4, 0, 7],
 'Foo': [1, 2, 3, 4, 5, 6],
 'Bar': [5, 6, 7, 3, 4, 5],
 }

 def __init__(self, parent = None):
 super().__init__(parent)

 series = QBarSeries()
 #series = QStackedBarSeries()
 for key, values in self.__samples.items():
 barset = QBarSet(key)
 #barset.hovered.connect(lambda state,index, x=key: self.__barset_hovered(x, index, state)) # 即時評価するため key を x に代入
 for value in values:
 barset.append(value)
 series.append(barset)
 series.hovered.connect(lambda state, index: self.__barseries_hovered(state, index))

 chart = QChart()
 chart.addSeries(series)
 chart.setTitle('Barchart example')
 chart.setAnimationOptions(QChart.SeriesAnimations)

 axis_x = QBarCategoryAxis()
 axis_x.append(self.__categories)
 chart.addAxis(axis_x, Qt.AlignBottom)
 series.attachAxis(axis_x)

 axis_y = QValueAxis()
 chart.addAxis(axis_y, Qt.AlignLeft)
 series.attachAxis(axis_y)

 chart.legend().setVisible(True)
 chart.legend().setAlignment(Qt.AlignBottom)

 self.setRenderHint(QPainter.Antialiasing)
 self.setChart(chart)

 self.__tooltip = QToolTip()
 
 def __barseries_hovered(self, state, index):
 print(f'barsetseries hovered, state={state}, index={index}')
 if state:
 texts = []
 for key, values in self.__samples.items():
 if values[index] > 0:
 texts.append( f'{key}: {values[index]}')
 self.__tooltip.showText(QCursor().pos(), '\n'.join(texts))
 else:
 self.__tooltip.hideText()

 def __barset_hovered(self, key, index, state):
 print(f'{key} hovered index={index}, category={self.__categories[index]}, state={state}')
 if state:
 self.__tooltip.showText(QCursor().pos(), f'{key}: {self.__samples[key][index]}')
 else:
 self.__tooltip.hideText()

class MainWindows(QMainWindow):
 def __init__(self):
 super().__init__()

 barchart = BarChartSample(self)
 self.setCentralWidget(barchart)

if __name__ == "__main__":
 app = QApplication(sys.argv)

 window = MainWindows()
 window.show()
 window.resize(720, 480)
 sys.exit(app.exec())

参考 URL

[PySide6] ui ファイルが読み込めないので、py ファイルにコンバートして読み込む

Thu, 27 Jan 2022 00:00:00 +0900

PySide2 では読み込めていた ui ファイルが、PySide6 に移行後読み込めなくなってしまいました。

PySide2 では以下のようなコードで ui ファイルを読み込んでいました。

self.ui = QUiLoader().load('./form.ui', self)

しかし、PySide6 で同じように ui ファイルを読み込もうとすると、以下のエラーが表示されます。

qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.

環境変数 PYSIDE_DESIGNER_PLUGINS を設定すれば良さそうですが、ググっても解決方法がわかりませんでした。

代わりに、ui ファイルを py ファイルにコンバートする方法がたくさん見つかったので、これで対応しました。
（一手間増えて面倒ですが・・・）

ui ファイルから py ファイルへのコンバート

以下のコマンドでコンバートできます。

$ pyside6-uic form.ui -o ui_form.py

コンバートした py ファイルの読み込み方法

class MainWindow(QMainWindow):
 def __init__(self):
 super(MainWindow, self).__init__()

 self.ui = UI_Form()
 self.ui.setupUi(self)

参考 URL

[PySide] QChart で棒グラフを作成

Wed, 26 Jan 2022 00:00:00 +0900

QChart を使って棒グラフを作成してみました。

公式のサンプルは以下です。

https://doc.qt.io/qtforpython/examples/example_charts__barchart.html

基本的な挙動は上記が理解しやすいと思いますが、実際にはループで処理することが多いと思うので、少し変更してみました。 pandas などと組み合わせれば大量のデータであっても効率的にグラフを作成できると思います。

環境

PySide 6.2.2.1

サンプル

import sys
from PySide6.QtWidgets import *
from PySide6.QtCore import Qt
from PySide6.QtCharts import *
from PySide6.QtGui import QPainter, QCursor

class BarChartSample(QChartView):
 __categories = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun']
 __samples = {
 'Hoge': [9, 7, 5, 3, 1, 2],
 'Piyo': [3, 5, 8, 13, 8, 5],
 'Fuga': [5, 0, 0, 4, 0, 7],
 'Foo': [1, 2, 3, 4, 5, 6],
 'Bar': [5, 6, 7, 3, 4, 5],
 }

 def __init__(self, parent = None):
 super().__init__(parent)

 series = QBarSeries()
 #series = QStackedBarSeries()
 for key, values in self.__samples.items():
 barset = QBarSet(key)
 for value in values:
 barset.append(value)
 series.append(barset)

 chart = QChart()
 chart.addSeries(series)
 chart.setTitle('Barchart example')
 chart.setAnimationOptions(QChart.SeriesAnimations)

 axis_x = QBarCategoryAxis()
 axis_x.append(self.__categories)
 chart.addAxis(axis_x, Qt.AlignBottom)
 series.attachAxis(axis_x)

 axis_y = QValueAxis()
 chart.addAxis(axis_y, Qt.AlignLeft)
 series.attachAxis(axis_y)

 chart.legend().setVisible(True)
 chart.legend().setAlignment(Qt.AlignBottom)

 self.setRenderHint(QPainter.Antialiasing)
 self.setChart(chart)

class MainWindows(QMainWindow):
 def __init__(self):
 super().__init__()

 barchart = BarChartSample(self)
 self.setCentralWidget(barchart)

if __name__ == "__main__":
 app = QApplication(sys.argv)

 window = MainWindows()
 window.show()
 window.resize(720, 480)
 sys.exit(app.exec())

QBarSeries を QStackedBarSeries に変更すれば積み上げグラフになります。

参考 URL

[Python] 時刻のみを扱う型

Mon, 24 Jan 2022 00:00:00 +0900

datetime.time 型が時刻を扱う型になります。

Python には time というモジュールがあるのでややこしいですが、time モジュールのことではなく、datetime モジュールに含まれる datetime.time という型です。

from datetime import time

t = time(23, 59, 59, 999)
print(type(t))
print(t)

<class 'datetime.time'>
23:59:59.000999

time モジュールを一緒にインポートしている場合は特にややこしいので、以下のようにエイリアスを設定しておいたほうがわかりやすいかもしれません。

import time
from datetime import time as datetime_time

t = datetime_time(23, 59, 59, 999)
print(type(t))
print(t)

datetime 型から時刻のみを取り出す

time() メソッドで取り出せます。

now = datetime.now()
print(now)

t = now.time()
print(type(t))
print(t)

2022-01-07 13:26:46.826983
<class 'datetime.time'>
13:26:46.826983

[Python] for文の中のラムダ式でループ変数を参照する場合は評価のタイミングに注意

Sun, 23 Jan 2022 00:00:00 +0900

Python に限らないと思いますが、知らないとハマることになるやつですね。

例えば、以下のように関数を登録して後から実行した場合、

def hoge(x):
 print(x)

funcs = []
for i in range(5):
 funcs.append(lambda: hoge(i))

for func in funcs:
 func()

期待する動作は 0～4 が順に出力されることですが、上記だと全て 4 が出力されます。

ここのラムダ式は遅延評価、関数が呼ばれたときに初めて評価されます。
従って、関数が実行されたときは既にループが終わった後であり、その時には i は 4 になっているため、常に 4 と出力されてしまいます。

解決方法として、私が知っている範囲では以下の２パターンがあります。

デフォルト引数で対応

以下のようにラムダ式にデフォルト引数を与えてやります。

def hoge(x):
 print(x)

funcs = []
for i in range(5):
 funcs.append(lambda x=i: hoge(x))

for func in funcs:
 func()

x=i とすることで即時評価され、期待した出力となります。

しかし、以下のように実行時に引数を与えると、与えられた引数で上書きされてしまいます。

def hoge(x):
 print(x)

funcs = []
for i in range(5):
 funcs.append(lambda x=i: hoge(x))

for func in funcs:
 func(4)

次の方法だとこの問題も回避できます。

functools.partial を使う

functools.partial() は引数を部分的に適用（固定化？）した関数を生成する関数です。
以下のように書くことで期待した出力となります。

from functools import partial

def hoge(x):
 print(x)

funcs = []
for i in range(5):
 funcs.append(partial(hoge, i))

for func in funcs:
 func()

この場合、実行時に引数を与えるとエラーになります。

参考 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

[Python] groupby の使い方

Wed, 19 Jan 2022 00:00:00 +0900

C# の Linq にある GroupBy と同じことを Python でやるにはどうしたらいいのかと思い調べたら、itertools モジュールに groupby というクラスがありました。

https://docs.python.org/ja/3/library/itertools.html#itertools.groupby

サンプル

import json
from itertools import groupby
 
# サンプルデータ
members = [
 {'country': 'Japan', 'sex': 'male', 'name': 'A'},
 {'country': 'America', 'sex': 'female', 'name': 'B'},
 {'country': 'China', 'sex': 'male', 'name': 'C'},
 {'country': 'Japan', 'sex': 'female', 'name': 'D'},
 {'country': 'America', 'sex': 'male', 'name': 'E'},
 {'country': 'China', 'sex': 'female', 'name': 'F'},
]
 
# groupby を使うには、まずはグルーピングしたいキーでソートしておく必要がある
members.sort(key=lambda m: m['country'])
# ソートした上で、キーを指定してグループ化
grouped = groupby(members, key=lambda x: x['country'])

# グループ化した内容を表示して確認
grouped_list = []
for key, group in grouped:
 member_list = list(group) # group はイテレーターなので、リストに変換
 grouped_list.append({
 'key': key,
 'members': member_list
 })
print(json.dumps(grouped_list, indent=4))

[
 {
 "key": "America",
 "members": [
 {
 "country": "America",
 "sex": "female",
 "name": "B"
 },
 {
 "country": "America",
 "sex": "male",
 "name": "E"
 }
 ]
 },
 {
 "key": "China",
 "members": [
 {
 "country": "China",
 "sex": "male",
 "name": "C"
 },
 {
 "country": "China",
 "sex": "female",
 "name": "F"
 }
 ]
 },
 {
 "key": "Japan",
 "members": [
 {
 "country": "Japan",
 "sex": "male",
 "name": "A"
 },
 {
 "country": "Japan",
 "sex": "female",
 "name": "D"
 }
 ]
 }
]

参考 URL

[Python] 月初日、月末日、翌月の月初日の取得

Tue, 18 Jan 2022 00:00:00 +0900

日時を扱っていると月初日や月末日を取得したいということもあるので、そのやり方です。

やり方はいろいろあるかもしれませんが、あくまで一例ということで。

月初日

from datetime import datetime

dt = datetime.now()
print(dt)

first_dt = dt.replace(day=1)
print(first_dt)

first_dt = datetime(dt.year, dt.month, 1)
print(first_dt)

2022-01-17 15:55:25.492664
2022-01-01 15:55:25.492664
2022-01-01 00:00:00

時刻を保持したい場合は replace で日だけ置き換えればOKです。
時刻をクリアしたい場合は年月日を指定して新たに datetime を作成すればOKです。

月末日

calendar モジュールを使えば簡単にできます。
monthrange は指定した年月の初日の曜日と日数を返してくれます。
これを使って月初日と同じように取得できます。

from datetime import datetime
import calendar

dt = datetime.now()
print(dt)
 
day_of_week, last_day = calendar.monthrange(dt.year, dt.month)

last_dt = dt.replace(day=last_day)
print(last_dt)

last_dt = datetime(dt.year, dt.month, last_day)
print(last_dt)

2022-01-17 16:04:31.007994
2022-01-31 16:04:31.008065
2022-01-31 00:00:00

翌月の月初日

やり方としては以下の２通りがあります。

calendar と timedelta を使う方法

calendar.monthrange を使えば前述した方法で月末日が取得できるので、ここから timedelta を使って一日足してやれば、翌月の月初日が取得できます。

from datetime import datetime, timedelta
import calendar

dt = datetime.now()
print(dt)

day_of_week, last_day = calendar.monthrange(dt.year, dt.month)

next_first_dt = dt.replace(day=last_day) + timedelta(days=1)
print(next_first_dt)

next_first_dt = datetime(dt.year, dt.month, last_day) + timedelta(days=1)
print(next_first_dt)

2022-01-17 16:37:09.969484
2022-02-01 16:37:09.969484
2022-02-01 00:00:00

dateutil.relativedelta を使う方法

まず python-dateutil をインストールする必要があります。

$ pip install python-dateutil

dateutil.relativedelta を使えば一ヶ月後の日時が取得できるので、そこから前述した方法と同じように月初日が取得できます。

from datetime import datetime
from dateutil.relativedelta import relativedelta

dt = datetime.now()
print(dt)

next_dt = dt + relativedelta(months=1)

next_first_dt = next_dt.replace(day=1)
print(next_first_dt)

next_first_dt = datetime(next_dt.year, next_dt.month, 1)
print(next_first_dt)

2022-01-17 16:42:25.298845
2022-02-01 16:42:25.298845
2022-02-01 00:00:00

所感

標準モジュールだけで実装したい場合は calendar と timedelta を使って実装すればいいですが、翌々月とか数ヶ月後とかも扱うのであれば dateutil.relativedelta を使ったほうが楽だと思いました。

参考 URL

[PySide] ダイアログの作成

Mon, 17 Jan 2022 00:00:00 +0900

QDialog を使ってダイアログを作るサンプルです。

環境

PySide 6.2.2.1

サンプルコード

ここでは、ボタンを押したときにダイアログを表示してみました。

import sys
from PySide2.QtWidgets import *

class MyDialog(QDialog):
 def __init__(self, parent=None):
 # ベース・クラスの初期化
 super(MyDialog, self).__init__(parent)
 
 # ウィンドウタイトルを設定
 self.setWindowTitle("My Dialog")
 
 # ラベルの作成
 label = QLabel("こんにちは。", self)

 # 縦方向レイアウトを使って配置
 layout = QVBoxLayout()
 layout.addWidget(label)
 self.setLayout(layout)

class MainWindow(QMainWindow):
 def __init__(self, parent=None):
 super(MainWindow, self).__init__(parent)

 # ボタンの作成
 button = QPushButton("Push!!", self)
 button.clicked.connect(self.__clicked)# ボタンが押された時の処理を設定
 self.setCentralWidget(button)
 
 def __clicked(self):
 dialog = MyDialog(self)
 dialog.show()

if __name__ == '__main__':
 app = QApplication(sys.argv)
 main_window = MainWindow() 
 main_window.show()
 sys.exit(app.exec())

参考 URL

https://www.programcreek.com/python/example/115469/PySide2.QtWidgets.QDialog

WSL2 で GUI を表示する

Sun, 16 Jan 2022 00:00:00 +0900

Windows に Xサーバーをインストールし、WSL2 上で実行した GUI アプリを表示できるようにする方法です。

環境

Windows 10
WSL2:Ubuntu 20.04

Xサーバーのインストール

Windows にXサーバーをインストールします。私は以下のページを参考に VcXsrv を入れました。

https://rin-ka.net/windows-x-server/

他には MobaXterm も良さそうですね。

あとは、ファイアウォールの設定も許可する必要があります。
設定完了後、VcXsrv 起動時に許可を求める画面が表示されるので、そこで全て許可しました。

WSL2 側の設定

Linux ではおなじみの export DISPLAY=:0 では駄目なようで、IPアドレスを指定する必要があるみたいです。

https://odaryo.hatenablog.com/entry/2020/01/08/114846

以下のようにすれば IP アドレスを読み込んで環境変数をセットしてくれるようです。

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

これを毎回入力するのも面倒なので、.bashrc に書いておけば、WSL2 起動時に自動でセットされるようです。

動作確認

VcXsrv を、Disable access control にチェックを入れて起動し、WSL2 上で以下のコマンドを実行して確認します。

$ xeyes

VSCode + Remote-Containers を使う場合

WSL2 上で VSCode を実行して Remote-Containers を使う場合、WSL2 の DISPLAY の値を Retemo-Containers 側にも引き継げば、Retemo-Containers でも GUI の表示が可能です。

https://qiita.com/y-na-biz/items/af0137532e6e22802f25#%E5%8F%82%E8%80%83devcontainerjson%E8%A8%AD%E5%AE%9A%E4%B8%80%E8%A6%A7

{
	"runArgs": [
		"-e", "DISPLAY=${env:DISPLAY}",
	],

	"mounts": [
		"source=/tmp/.X11-unix/,target=/tmp/.X11-unix/,type=bind",
	],
}

参考 URL

WSL2 のインストール

Sat, 15 Jan 2022 00:00:00 +0900

WSL2 をインストールし、WSL2 上で Ubuntu を動かす方法です。

環境

Windows 10 Pro OSビルド 19042.1466

WSL2 のインストール

公式ドキュメントは以下です。

WSL のインストール

PowerShell を起動し、以下のコマンドを入力します。

> wsl --install

WSL2 にアップデート

以下にアクセスし、wsl_update_x64.msiをダウンロードしてインストールします。

https://aka.ms/wsl2kernel

WSL2 をデフォルトにする

> wsl --set-default-version 2

Ubuntu のインストール

MS Store から Ubuntu で検索してインストールするだけです。

WSL2 で動作しているか確認

> wsl --list --verbose
 NAME STATE VERSION
* Ubuntu Running 2

* が付いているのがデフォルトのディストリビューションです。 VERSION が 2 になっているので、WSL2 で動作しています。

デフォルトのディストリビューションを変更する場合は、以下のように変更します。

> wsl --set-default Ubuntu

WSL のバージョンが2でない場合、以下のようにして設定します。

> wsl --set-version Ubuntu 2

参考 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

[Python] URL のエンコード・デコード

Fri, 07 Jan 2022 00:00:00 +0900

URL に使用できない文字を使用する場合、URL エンコードを行う必要があります。

例えば REST API の GET メソッドのクエリパラメーターで、日時を ISO8601 形式で渡す必要がある場合、+ や : が含まれるので、URL エンコード・デコードが必要になります。
エンコード・デコードには、urllib.parse を使います。

エンコード

from datetime import datetime
from urllib import parse

dt = datetime.now()
encoded = parse.quote(dt.isoformat())

print(dt.isoformat()) # エンコード前
print(encoded) # エンコード後

出力結果

2022-01-07T13:06:54.927884
2022-01-07T13%3A06%3A54.927884

デコード

decoded = parse.unquote('2022-01-07T13%3A06%3A54.927884')
print(decoded)

出力結果

2022-01-07T13:06:54.927884

[Python] 2つの日付を比較し、日付が変わったことを検知する

Thu, 06 Jan 2022 00:00:00 +0900

日次処理を行う場合など、日付が変わったことを検知したい場合は以下のようにして検知できます。

from datetime import date

d0 = date(2008, 8, 18)
d1 = date(2008, 9, 26)
delta = d1 - d0
if delta.days > 0:
 # do something

要点は

date や datetime の演算結果は timedelta 型
datetime 型の場合は date() を使用することで時刻を無視できる（日付のみを取得できる）
timedelta 型の days で総日数が取得できる

参考 URL

https://stackoverflow.com/questions/151199/how-to-calculate-number-of-days-between-two-given-dates

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

Telegraf で GPU の情報を取得し、Grafana で可視化する

Sun, 26 Dec 2021 00:00:00 +0900

Telegraf, InfluxDB, Grafana を使って GPU の情報を閲覧できるようにしました。

以前、Telegraf, InfluxDB, Grafana を使ってサーバーリソースの情報を閲覧できるようにしました。

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

これを前提としたうえで、今回 GPU の情報も見れるようにしました。

試したグラフィックボードは NVIDIA GeForce RTX 3080 です。
グラフィックドライバーのインストールなどは完了している前提です。

概要

Telegraf の nvidia_smi プラグインを使えば GPU の情報を取得できるようです。
nvidia_smi のプラグインについては以下に説明があります。

https://github.com/influxdata/telegraf/blob/master/plugins/inputs/nvidia_smi/README.md

上記の記事に書いてありますが、Docker で動作させている Telegraf で GPU の情報を取得するには、以下の２つの方法があるようです。

nvidia/cuda の Docker イメージをベースに Telegraf をインストールしたカスタムイメージを作成する
Volume のマウントバインディングを使用して nvidia-smi のバイナリを Docker コンテナに注入する

今回は後者でいきます。

Telegraf の設定

telegraf.conf に以下を追加しました。

[[inputs.nvidia_smi]]
 #bin_path = "/usr/bin/nvidia-smi"

inputs.nvidia_smi を追加するだけでプラグインが有効になるようです。
bin_path は nvidia-smi のある場所です。
以下のコマンドで調べられます。

$ which nvidia-smi
/usr/bin/nvidia-smi

Linux では通常 /usr/bin/nvidia-smi にあるそうで、その場合は指定しなくてもよいそうです。

docker-compose の設定

Telegraf を動作させている Docker コンテナから nvidia-smi と GPU にアクセスできるように設定します。
例えば、以下のような感じです。

version: '3.5'
services:
 telegraf:
 container_name: telegraf
 image: telegraf
 environment:
 - NVIDIA_VISIBLE_DEVICES=all
 - NVIDIA_DRIVER_CAPABILITIES=all
 deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
 volumes:
 - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
 - /usr/bin/nvidia-smi:/usr/bin/nvidia-smi:ro

ホストの /usr/bin/nvidia-smi をコンテナにマウントします。
Docker コンテナでの GPU の使用については以下の記事にも書いているので、参照してください。

https://kuttsun.blogspot.com/2021/11/docker-compose-gpu.html

Grafana の設定

Docker コンテナを起動したら、Grafana で以下のダッシュボードのテンプレートをインストールします。

https://grafana.com/grafana/dashboards/12225

これで閲覧できるようになると思ったのですが、Hostname に None しか表示されず、グラフに何も表示されない状態でした。
どうもこのテンプレートが Windows を前提としているようですので、ダッシュボードの設定をちょっと修正しました。

ダッシュボードの設定画面を開き Variables を選択します。
hostname の定義を以下のように変更します。

変更前

SHOW TAG VALUES FROM "win_system" WITH KEY = "host"

変更後

SHOW TAG VALUES FROM system WITH KEY=host

これで以下のようにグラフが表示されるようになりました。

他に CPU Usage と Memory Free のメーター表示も Windows 前提となっているようなので、必要なら修正してください。
私は CPU やメモリなどは他のダッシュボードで閲覧しており、ここでは GPU の情報だけで十分だったので、そこまで修正しませんでした。

参考 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

[Python] Flask (Werkzeug)のロギングの設定

Thu, 23 Dec 2021 00:00:00 +0900

Flask (というか Werkzeug？) が HTTP リクエストを受信するたびにログをレベル INFO で出力するので、ERROR 以上のログのみ出力するように設定を変更しました。

前提

ログに関する設定は yaml ファイルに切り出しています。

https://kuttsun.blogspot.com/2021/12/python_21.html

Flask (Werkzeug) のロギングの設定

Flask は Werkzeug という WSGI サーバーに依存しており、こちらがいろいろログを出力しているようなので、werkzeug のロギングの設定を追加します。
例えば、以下のように指定すれば ERROR レベル以上のログのみ出力されるようになります。

loggers:
 werkzeug:
 level: ERROR

rsyslog から Telegraf への送信に時々失敗する

Wed, 22 Dec 2021 00:00:00 +0900

rsyslog から Telegraf にログを TCP で転送するように設定してみましたが、Grafana で閲覧していると表示されないログがあり、送信に失敗しているようでした。

ググてみると以下のページを見つけました。

https://gist.github.com/froop/e3a1e7d14a8143f9951b85afff6b5469#file-rsyslog-bug4227-md

どうやら rsyslog の不具合のようで、バージョン 8.2010.0 で修正されているようです。
rsyslog のバージョンは以下で確認できます。

$ rsyslogd -v

私の環境 (Ubuntu 20.04) の rsyslog のバージョンは 8.2001.0 でした。なので、rsyslog をアップデートします。アップデート方法は以下に書いてありました。

https://www.rsyslog.com/ubuntu-repository/

$ sudo add-apt-repository ppa:adiscon/v8-stable
$ sudo apt-get update
$ sudo apt-get install rsyslog

現在の /etc/rsyslog.conf を最新のに差し替えるか残すかを聞かれますが、最新のに差し替えた後で再設定を行いました。再設定後は rsyslog を再起動します。尚、アップデート後のバージョンは 8.2021.0 でした。アップデート後は、ざっと見た感じきちんと転送されているように見えます。

参考 URL

[Python] コンソールに出力するログに色を付ける

Tue, 21 Dec 2021 00:00:00 +0900

ググればやり方はいろいろ見つかり、いろいろ試してみましたが、rich を使うのが一番簡単かつ見栄えがいいかもしれません。

前提

ログに関する設定は yaml ファイルに切り出しています。

https://kuttsun.blogspot.com/2021/12/python_21.html

coloredlogs を使う方法

pip install coloredlogs

 with open('./logging.yaml', encoding='utf-8') as f:
 logconfig = yaml.safe_load(f)
 config.dictConfig(logconfig)
 coloredlogs.install(level='DEBUG') # 追加

簡単にカラフルに出来ましたが、 logging.yaml の設定が上書きされてしまいました。
他にやり方があるのかもしれません。

colorlog を使う方法

pip install colorlog

logging.yaml で、colorlog を使うように指定し、{log_color} でレベルに合わせた色分けをしてくれます。

version: 1
root:
 level: DEBUG
 handlers: [console]
handlers:
 console:
 class: logging.StreamHandler
 stream: ext://sys.stderr
 formatter: myformatter
formatters:
 myformatter:
 '()': 'colorlog.ColoredFormatter'
 format: "{log_color}{asctime} [{levelname:.4}] {name}: {message}"
 style: "{"

各レベルの色を自分で定義

version: 1
root:
 level: DEBUG
 handlers: [console]
handlers:
 console:
 class: logging.StreamHandler
 stream: ext://sys.stderr
 formatter: myformatter
formatters:
 myformatter:
 '()': 'colorlog.ColoredFormatter'
 format: "{log_color}{asctime} [{levelname:.4}] {name}: {message}"
 style: "{"
 log_colors:
 DEBUG: 'bold_black'
 INFO: 'white'
 WARNING: 'yellow'
 ERROR: 'red'
 CRITICAL: 'bold_red'

一つのログ内で色分けしたい場合

format で以下のように記述すれば OK です。

format: "{cyan}{asctime} {blue}{name} L{lineno} {bold_black}{levelname}{reset} {log_color}{message}"

rich を使う方法

コンソールへの出力をリッチにしてくれる Rich というライブラリの RichHandler を使ってログを出力する方法です。

https://note.com/navitime_tech/n/n6d8cd7327466c

pip install rich

version: 1
root:
 level: INFO
 handlers: [rich]
handlers:
 rich:
 class: rich.logging.RichHandler
 rich_tracebacks: True

これだけで簡単にカラフルなログを出力してくれます。

参考 URL

[Python] ロギングの個人的ベストプラクティス

Mon, 20 Dec 2021 00:00:00 +0900

まぁベストかどうかはわかりませんが、現状の私にとっての最適解です。

Python 標準の logging モジュールを使用しますが、logging を直接使うのではなく、getLogger でロガーを取得して使用します。
これについては以下の記事にわかりやすく書いてありました。

https://qiita.com/amedama/items/b856b2f30c2f38665701

このように抽象化しておけば、ロガーハンドラを指定・変更するだけで、ファイルに出力したり、syslog に出力したり、どっかに送信したりと後から簡単に出力先を変更できます。

ロギングの設定をファイルに切り出す

ログに関する設定は logging.yaml というファイルに切り出すことにしました。
これについては以下の記事にわかりやすく書いてありました。

https://qiita.com/shinsa82/items/a0778fbd127012c93577

例えばこんな感じです。

from logging import config, getLogger
import yaml

if __name__ == '__main__':

 with open('./logging.yaml', encoding='utf-8') as f:
 logconfig = yaml.safe_load(f)
 config.dictConfig(logconfig)

 logger = getLogger(__name__)

 logger.critical('this is critical')
 logger.error('this is error')
 logger.warning('this is warning')
 logger.info('this is info')
 logger.debug('this is debug')

 try:
 hoge = 0/0
 except Exception as e:
 logger.exception('this is exception')

version: 1
root:
 level: DEBUG
 handlers: [console]
handlers:
 console:
 class: logging.StreamHandler
 stream: ext://sys.stderr
 formatter: myformatter
formatters:
 myformatter:
 format: "%(asctime) [%(levelname:.4)s] %(name)s: %(message)s"

こうしておけば、環境に応じて設定を丸ごと差し替えたりも簡単にできます。
フォーマッタで使える変数については以下を参照してください。

https://docs.python.org/3/library/logging.html#logrecord-attributes

設定いろいろ

ここらへんは環境や好みに応じて様々だと思うので、あくまでサンプルとして。
適宜追加していきます。

コンソール出力をカラフルにして見やすくする

rich を使うのが簡単かつわかりやすかったです。
例えば以下のような感じです。

root:
 level: DEBUG
 handlers: [rich]
handlers:
 rich:
 class: rich.logging.RichHandler
 rich_tracebacks: True

以下の記事も参考にしてください。

https://kuttsun.blogspot.com/2021/12/python_5.html

syslog に出力する

logging モジュールに SyslogHandler があるので、基本的にこれを指定するだけで OK です。
詳細は別記事にまとめているので、以下を参考にしてください。

https://kuttsun.blogspot.com/2021/12/python-syslog.html

flask の出力設定

Flask が HTTP リクエストを受信するたびにログをレベル INFO で出力するので、ERROR 以上のログのみ出力するように設定変更する方法を以下の記事に書いています。

https://kuttsun.blogspot.com/2021/12/python-flask.html

参考 URL

Syslog を Telegraf に送り、Grafana で閲覧できるようにする

Mon, 20 Dec 2021 00:00:00 +0900

以下に Syslog 用のテンプレートと解説があるので簡単にできるかと思ったんですが、結構苦労しました・・・。

https://grafana.com/grafana/dashboards/12433

概要

ホストの Syslog から Telegraf にログを送り、Telegraf が InfluxDB に保存し、Grafana が InfluxDB から読み込んで可視化します。

Telegraf、InfluxDB、Grafana は全て docker-compose で動かしています。
これについては以下の記事で書いているので省略します。

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

上記記事からの変更点を以下に記述します。

rsyslog の設定

まずは Syslog から Telegraf にログを送信するように設定します。
/etc/rsyslog.conf を編集します。

$ sudo gedit /etc/rsyslog.conf

以下の設定を追加します。

$WorkDirectory /var/spool/rsyslog 
$ActionQueueType LinkedList 
$ActionQueueFileName srvrfwd 
$ActionResumeRetryCount -1 
$ActionQueueSaveOnShutdown on 
$ModLoad imudp #loads the udp module 
$UDPServerAddress localhost 
$UDPServerRun 514
*.* @@(o)127.0.0.1:6514;RSYSLOG_SyslogProtocol23Format

rsyslog を再起動します。

$ sudo systemctl restart rsyslog

Telegraf の設定

telegraf.conf に以下の設定を追加します。

[[inputs.syslog]]
 server = "tcp://0.0.0.0:6514"

Syslog から TCP ポート 6514 で受信するように設定していますが、docker で動かしているので localhost を指定すると上手く動作しません。
とりあえず 0.0.0.0 を指定しましたが、もしかしたら host.docker.internal とかでもいけるのかもしれません（未確認）。

docker-compose.yaml の変更

ポート 6514 を使用できるようにします。

services:
 telegraf:
 container_name: telegraf
 image: telegraf
 ports:
 - 6514:6514

docker コンテナを再起動します。

Grafana の設定

以下のページからダッシュボードの JSON ファイルをダウンロードしてインポートするだけです。

https://grafana.com/grafana/dashboards/12433

これで以下のようなダッシュボードが完成します。

参考 URL

Telegraf + InfluxDB + Garafana でサーバーリソースを可視化する

Sat, 18 Dec 2021 00:00:00 +0900

CPUやメモリなどのリソースを収集して閲覧したいなと思い、ググってみるとこの組み合わせが良さそうでした。
Telegraf でデータを取得して InfluxDB に書き込み、Grafana で InfluxDB のデータを読み込んで可視化します。

個人的に InfluxDB と Grafana は使ったことありますが、Telegraf は今回初めて使いました。

尚、この３つの頭文字を取って TIG Stack と呼んでいるページもいくつか見かけました。

環境

Ubuntu 20.04
Docker 20.10.7
Telegraf 1.20.4
InfluxDB 1.8.6
Grafana 7.5.7

Telegraf と Grafana は現時点の最新のバージョンですが、InfluxDB は 2.0 系ではなく 1.8.6 を使いました。
InfluxDB 2.0 を使ったことがないのと、参考にした Telegraf の設定ファイルのサンプルが InfluxDB 2.0 ではないものばかりだったからです。

また、Telegraf, InfluxDB, Grafana は全て Docker (docker-compose) を使って動かします。

docker-compose.yaml のサンプル

以下のような docker-compose.yaml を作成しました。

version: '3.1'
services:
 telegraf:
 container_name: telegraf
 image: telegraf
 restart: always
 volumes:
 - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
 depends_on:
 - influxdb
 links:
 - influxdb
 networks:
 - common
 influxdb:
 container_name: influxdb
 image: influxdb:1.8.6
 restart: always
 ports:
 - 8086:8086
 volumes:
 - influxdb:/var/lib/influxdb
 networks:
 - common
 grafana:
 container_name: grafana
 image: grafana/grafana
 restart: always
 links:
 - influxdb
 ports:
 - 3000:3000
 volumes:
 - grafana:/var/lib/grafana
 networks:
 - common
networks:
 common:
 external: true
volumes:
 influxdb:
 grafana:

common というネットワークを共通で使っているので、あらかじめ docker network create で作成しておく必要があります。

Telegraf の設定

telegraf.conf を作成します。

以下のページにちょうど良いのがあるのでこれをそのまま使いました。

https://grafana.com/grafana/dashboards/928

後述しますが、Grafana のダッシュボードのテンプレートもこれを使いました。
上記の設定をコピーしたら最低限以下の設定だけ変更します。

[agent] > hostname にマシン名を設定
- 設定しないと自動で設定されますが、起動の度に変わるので設定しておいたほうがよいと思います。
- 環境変数が使えるので、hostname = "$HOSTNAME" のようにも書けます。
[[outputs.influxdb]] > urls を InfluxDB の URL に変更
- 上記の docker-compose.yaml の場合、URL は http://influxdb.common:8086 のようにコンテナ名とネットワーク名を使っても指定できます。

他は必要に応じて設定します。

起動

$ docker-compose up

デーモン化したい場合は -d を指定します。
起動すると InfluxDB に Telegraf 用のデータベースを自動で作成してくれます。
（データベース名は telegraf.conf で設定できます。）

Grafana の設定

Grafana にアクセスし、ログインします。

http://localhost:3000

初期 ID とパスワードはどちらも admin です。

DB の登録

Configuration > Data Sources > Add data source > InfluxDB を選択します。

URL と Database の２つを設定します。
今回の例では以下のように設定します。

URL に http://influxdb.common:8086 を設定
Database に telegraf_metrics を設定

ダッシュボードの作成

Telegraf 用のテンプレートがあるので、それをインポートするのが楽です。
テンプレートは以下のページで探せます。

https://grafana.com/grafana/dashboards/

今回は以下のテンプレートを使いました。

https://grafana.com/grafana/dashboards/928

上記から JSON ファイルをダウンロードし、Grafana の左メニューの + ボタンからインポートします。
インポートの際、データベースは telegraf_metrics を選択します。

ダッシュボードにアクセスすると以下のような画面が表示されます。

かっこいい画面が簡単に作成できました。

リテンションポリシーの設定

telegraf.conf の [[outputs.influxdb]] > retention_policy でリテンションポリシーを指定できますが、ここが未指定だとデフォルトの autogen が使用され、データが無期限に保存されることになるので指定します。
例えば、リテンションポリシー名に hoge と指定します。

この状態で動作させると、hoge というリテンションポリシーが存在しないというエラーが出るので、InfluxDB のコンテナに入ってリテンションポリシーを作成します。

$ docker exec -it influxdb bash

コンテナに入ったら以下のコマンドでリテンションポリシーを作成します。

# influx
> CREATE RETENTION POLICY "リテンションポリシー名" ON "データベース名" DURATION "期間" REPLICATION 1 DEFAULT

例えば、今回は以下のように指定します。

CREATE RETENTION POLICY "hoge" ON "telegraf_metrics" DURATION 1h REPLICATION 1 DEFAULT

上記のコマンドではデータの保存期間を１時間に設定しています。

参考 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

[Python] 指定したディレクトリ内の空ディレクトリを全て削除する

Tue, 14 Dec 2021 00:00:00 +0900

空のディレクトリを削除する方法自体はググればたくさん見つかりますが、指定したディレクトリ内を再帰的に検索して空のディレクトリを削除する方法が見つからなかったので実装してみました。

もっと他に良いやり方はあるかもしれせんが・・・。

サンプルコード

/hoge 内の空ディレクトリを削除するサンプルコードです。

target_dir = '/hoge'
dirs = glob.glob(f'{target_dir}/**/', recursive=True)
print(f'{len(dirs)} dirs exist')

cnt = 0
for dir in dirs:
 try:
 os.removedirs(dir)
 print(f'Removed dir: {dir}')
 cnt += 1
 except OSError:
 pass
if cnt > 0:
 print(f'Removed {cnt} dirs')

ディレクト一覧の取得は glob で行います。
再帰的に取得するため recursive=True を指定します。

ディレクトリの削除は os.removedirs で行います。
空のディレクトリを削除し、その結果親ディレクトリも空になればそちらも削除してくれます。
ディレクトリが空でなかった場合は OSError になります。

参考 URL

https://note.nkmk.me/python-os-remove-rmdir-removedirs-shutil-rmtree/

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

GitLab でリストア後に 500 エラーが表示される

Fri, 19 Nov 2021 00:00:00 +0900

GitLab でリストア自体は成功するのですが、特定のページにアクセスすると 500 エラーが表示されました。

原因は以下と同じでした。

https://kuttsun.blogspot.com/2020/01/gitlab-admin-runners-500.html

上記と同じ方法で解決もしました。

参考 URL

OpenCV + Gstreamer を使う

Wed, 17 Nov 2021 00:00:00 +0900

OpenCV で GStreamer を使うための Docker コンテナを作成したので、GStreamer を使ってカメラの画像を取得するところまで試してみました。

Docker コンテナの作成については以下の記事に書いています。

OpenCV + GStreamer の Docker コンテナを作成

GStreamer の基本

私は Gstreamer を今回初めて使いました。
最初、GStreamer のことが全然分からず困っていたのですが、以下の記事がとても参考になりました。

https://qiita.com/saxxos/items/e5b452502ad9aca3c997

GStreamer の動作確認

OpenCV を使う前に、まずは GStreamer が使えるかどうか単体で試します。

ネットワークカメラから RTSP で画像を取得して表示します。
今回は Panasonic のカメラを使いました。

Docker コンテナ内で以下のコマンドを実行するとウィンドウが立ち上がり、カメラの画像が表示されれば OK です。

gst-launch-1.0 rtspsrc location=rtsp://username:password@host/MediaInput/h265 ! decodebin ! autovideosink

decodebin でデコードし、autovideosink 自動表示（画面上にウィンドウで表示）する感じみたいです。

OpenCV を使う

上記を踏まえ、OpenCV で GStreamer のクエリを指定する場合は、以下のように記述します。

query = 'rtspsrc location=rtsp://username:password@host/MediaInput/h265 ! decodebin ! videoconvert ! appsink'
cap = cv2.VideoCapture(query, cv2.CAP_GSTREAMER)

autovideosink を videoconvert ! appsink に変更しています。
GStreamer の出力を OpenCV に入力するためには appsink が必要みたいです。
んで、appsink に送るためには videoconvert が必要みたいです。
これで cap.read() をコールすれば、フレームデータを取得できます。

ただし、このままだと遅延が酷かったので、latency=0 を追加しました。

query = 'rtspsrc location=rtsp://username:password@host/MediaInput/h265 latency=0 ! decodebin ! videoconvert ! appsink'
cap = cv2.VideoCapture(query, cv2.CAP_GSTREAMER)

とりあえずはこれで動作確認できました。

ちなみに、OpenCV を使わずにコンソールで gst-launch-1.0 で直接実行する際に latency=0 を指定すると、画像が乱れてまともに表示されませんでした。

参考 URL

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

Node.js で `Unexpected end of json input` のエラーがでた

Fri, 12 Nov 2021 00:00:00 +0900

Node.js でJSON データを受信してパースしようとしたら Unexpected end of json input のエラーが表示されました。

最初以下のように書いていたのですが、

response.on('data', (data) => {
 let json = JSON.parse(data);
 ...
});

データが大きい場合は分割されて送信されてくるようなので、以下のように処理すれば上手くいきました。

let chunks = [];

response.on('data', (data) => {
 chunks.push(data);
});

response.on('end', () => {
 let data = Buffer.concat(chunks);
 let json = JSON.parse(data);
 ...
});

参考 URL

https://stackoverflow.com/questions/45029826/unexpected-end-of-json-input-in-node-js

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

ffmpeg で mp4 ファイルを結合する

Thu, 28 Oct 2021 00:00:00 +0900

たくさんの mp4 ファイルを結合したかったので、ffmpeg を使って結合しました。

やり方としては、まず以下のように結合ファイルの一覧を記述したテキストファイルを用意します。
ここでは filelist.txt というファイル名で作成しました。

file '001.mp4'
file '002.mp4'
file '003.mp4'

そして、以下のようにコマンドを実行すれば結合できます。

ffmpeg -f concat -i filelist.txt -c copy sample.mp4

しかし、動画ファイルがたくさんある場合など、filelist.txt を手動で作るのが大変なことがあったので、以下のようなスクリプトを作成しました。
ディレクトリ内を再帰的に探索し、ファイル名順で結合します。

#!/bin/bash

cd `dirname $0`

DIR=hoge
FILELIST=filelist.txt
OUTPUT=sample.mp4

for pathfile in `\find $DIR -name '*.mp4' | sort`; do
 echo file \'$pathfile\' >> $FILELIST
done

ffmpeg -f concat -i $FILELIST -c copy $OUTPUT

rm $FILELIST

参考 URL

Windows 10 に XPS ビューワーをインストールする

Mon, 25 Oct 2021 00:00:00 +0900

以前は標準でインストールされていたような気がするんですが、いつの間にかなくなっていたのでインストールしました。
Windows の「アプリと機能」からインストールできます。

スタートメニュー > 設定 > アプリ > アプリと機能 > オプション機能 > 機能の追加 > XXPS ビューワー

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/

MongoDB でフィールド同士を比較したい

Mon, 27 Sep 2021 00:00:00 +0900

MongoDB の where 句には JavaScript のコードを記述できます。

コレクション内のフィールドを参照したい場合は、this または obj を使うそうで、これを使えばフィールド同士の比較もできます。

以下、pymongo での記述例です。

# sample1
ret =db[colname].find({'$where': 'this.hoge == this.fuga' })

# sample2
ret =db[colname].find({'$where': 'this["hoge"] == this["fuga"]' })

# sample3
ret =db[colname].find({'$where': 'obj.hoge == obj.fuga' })

# sample4
ret =db[colname].find({'$where': 'obj["hoge"] == obj["fuga"]' })

尚、Date 型のフィールドでは、同じ値かどうかを比較したい場合にそのまま比較しても一致しません。
例えば、以下のように getTime() で値型にしたうえで比較するなどの必要があります。

ret =db[colname].find({'$where': 'this.hoge.getTime() == this.fuga.getTime()' })

参考 URL

MongoDB で更新後のドキュメントを返したい

Fri, 24 Sep 2021 00:00:00 +0900

MongoDB の find_one_and_update などは、デフォルトでは更新前のドキュメントを返しますが、引数の return_document を指定することで更新後のドキュメントを返すようにもできます。

以下、pymongo を使った場合の例です。

環境

pymongo 3.12.0

サンプルコード

hoge = db['colname'].find_one_and_update(
 query,
 update,
 return_document=ReturnDocument.AFTER
)

参考 URL

[PowerShell] JSON の読み込み

Tue, 21 Sep 2021 00:00:00 +0900

古いスクリプトで設定ファイルを XML で作っていたのですが、JSON に移行したので、JSON の読み込み方法です。

ファイルの読み込みは Get-Content を使います。
改行が含まれていても大丈夫なように -Raw を付けます。
その後、JSON 文字列を ConvertFrom-Json でオブジェクトに変換します。

Get-Content sample.json -Raw | ConvertFrom-Json

または

ConvertFrom-Json -InputObject (Get-Content sample.json -Raw)

コメント付きの JSON (JSONC) を読み込みたい場合は、以下のサイトにあるように Where-Object でコメントを取り除けばいけました。

https://ascii.jp/elem/000/004/036/4036376/2/

参考 URL

[PowerShell] 文字列が null または空文字かどうか判定する

Mon, 20 Sep 2021 00:00:00 +0900

IsNullOrEmpty を使うのが簡単です。

if([string]::IsNullOrEmpty($str))
{
 # null または空文字の場合の処理
}

[Node.js] Windows で子プロセスを終了させる方法

Wed, 15 Sep 2021 00:00:00 +0900

ChileProcess で子プロセスを作成した場合、ChildProcess.kill() でプロセスを終了させることができますが、Windows では効きません。

じゃあ Windows ではどうやって子プロセスを終了させたらいいんだろうと調べてみたら、以下に解答がありました。

https://stackoverflow.com/questions/23706055/why-can-i-not-kill-my-child-process-in-nodejs-on-windows

var spawn = require('child_process').spawn; 
spawn("taskkill", ["/pid", child.pid, '/f', '/t']);

参考 URL

[Python] datetime とタイムゾーンについてのメモ

Mon, 13 Sep 2021 00:00:00 +0900

ちょっとはまったのでメモしておきます。

環境

python 3.8.10

navive と aware

まず、datetime 型にはタイムゾーンの情報を持たない naive と、タイムゾーンの情報を持つ aware な datetime 型があるようです。

naive な datetime 型

from datetime import datetime, date, timedelta, timezone

dt = datetime.now()
print(dt.isoformat())

出力結果

2021-09-13T15:11:50.968159

aware な datetime 型

from datetime import datetime, date, timedelta, timezone

JST = timezone(timedelta(hours=+9), 'JST')

dt = datetime.now(JST)
print(dt.isoformat())

出力結果

datetime.now で JST を指定しているので、文字列で出力したときに +09:00 が付与されています。

2021-09-13T15:12:28.720290+09:00

文字列から datetime への変換

str = '2021-09-13T15:11:50.968159'
dt = datetime.fromisoformat(str)
print(dt)

str = '2021-09-13T15:12:28.720290+09:00'
dt = datetime.fromisoformat(str)
print(dt)

出力結果

文字列にタイムゾーンに関する情報がなければ naive、あれば aware な datetime 型になっていることがわかります。

2021-09-13 15:11:50.968159
2021-09-13 15:12:28.720290+09:00

naive から aware への変換

naive に対して astimezone でタイムゾーンの情報を付与すると aware になります。

str = '2021-09-13T15:11:50.968159'
dt = datetime.fromisoformat(str) # naive
print(dt)

jst_dt = dt.replace(tzinfo=timezone.utc) # aware
print(jst_dt)

2021-09-13 15:11:50.968159
2021-09-13 15:11:50.968159+00:00

UTC から JST への変換

str = '2021-09-13T15:11:50.968159'

# タイムゾーンの情報がないので、naive な datetime になる
dt = datetime.fromisoformat(str) # naive
print(dt)

# 上記の dt は UTC として解釈する（タイムゾーンを付与する）
utc = dt.replace(tzinfo=timezone.utc) # aware(UTC)
print(utc)

# JST に変換する
jst = utc.astimezone(JST) # aware(JST)
print(jst)

出力結果

2021-09-13 15:11:50.968159
2021-09-13 15:11:50.968159+00:00
2021-09-14 00:11:50.968159+09:00

タイムゾーンのない文字列を JST として読み込む

上記の応用で、最初から JST を指定してやると OK です。

str = '2021-09-13T15:11:50.968159'

# タイムゾーンの情報がないので、naive な datetime になる
dt = datetime.fromisoformat(str) # naive
print(dt)

# 上記の dt は JST として解釈する（タイムゾーンを付与する）
JST = timezone(timedelta(hours=+9), 'JST')
jst = dt.replace(tzinfo=JST) # aware(JST)
print(jst)

出力結果

2021-09-13 15:11:50.968159
2021-09-13 15:11:50.968159+09:00

参考 URL

[JavaScript] JSON の内容を文字列で出力する

Tue, 07 Sep 2021 00:00:00 +0900

オブジェクト単体では何もしなくても文字列で出力されますが、テンプレートリテラルなどを使う場合は JSON.stringify で JSON 形式の文字列に変換してやる必要があります。

let hoge = { fuga: 1, piyo: 2 };

console.log(hoge)
console.log('hoge: ' + hoge)
console.log(`hoge: ${hoge}`)
console.log(`hoge: ${JSON.stringify(hoge)}`)

{ fuga: 1, piyo: 2 }
hoge: [object Object]
hoge: [object Object]
hoge: {"fuga":1,"piyo":2}

参考 URL

https://hdix.hatenablog.com/entry/2018/01/05/163935

[JavaScript] map で配列の値とインデックスを同時に取得する

Fri, 03 Sep 2021 00:00:00 +0900

ずっと C# で Linq を使っていたので、Linq の Select と同じ感覚で JavaScript の map を使うとちょっとはまります。

環境

Node.js v14.17.4

サンプルコード

ダメなパターン

JavaScript にはタプルがないので、Linq の Select と同じように書いてもダメです。

let array = ["hoge", "fuga", "piyo"]
let targets = array.map((v, i) => (v, i));
console.log(targets)

[ 0, 1, 2 ]

解決方法

以下のようにオブジェクトにして返せば OK です。

let array = ["hoge", "fuga", "piyo"]
let targets = array.map((v, i) => ({
 value: v,
 index: i
}));
console.log(targets)

[
 { value: 'hoge', index: 0 },
 { value: 'fuga', index: 1 },
 { value: 'piyo', index: 2 }
]

参考 URL

https://tkkm.tokyo/post-192/

[Python] http リクエストの送信

Thu, 02 Sep 2021 00:00:00 +0900

webapi をたたくときにどうやって書けばいいのか忘れることがあるので、メモしておきます。

GET

url = 'http://example.com/'
params = {
 'hoge': 2,
}
res = requests.get(url, params=params)

print(res.status_code)
print(res.json())

POST

import json
import requests

url = 'http://example.com/'
headers = {
 'content-type': 'application/json',
}
json_data = json.dumps({
 'hoge': 100,
})
res = requests.post(url, headers=headers, data=json_data)

print(res.status_code)
print(res.json())

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

[Node.js] SQLite + Sequelize で日時の範囲検索

Fri, 27 Aug 2021 00:00:00 +0900

DB が SQLite、ORM として Sequelize を使っていますが、日時の範囲検索をしようとしてどのように記述していいのか分からず、ちょっとはまりました。

環境

Node.js v14.17.4
sequelize@6.6.5
sqlite3@5.0.2

サンプルコード

where に指定できる条件として、$gte とか $lt とか $between とかで示している記事がありますが、そのように書いても正しく検索できませんでした。

最新の公式ドキュメントを見ると、上記のような記述は見当たらなかったので、Sequelize.Op を使って記述すると正しく検索できました。

let begin = new Date(2021, 0, 1, 1, 0, 0, 0);
let end = new Date(2021, 1, 1, 0, 0, 0, 0);

let users = await Users.findAll({
 where: {
 birthday: {
 [Sequelize.Op.gte]: begin,
 [Sequelize.Op.lt]: end
 }
 },
});

条件を動的に記述する場合は以下のようにしたら上手くいきました。

let filter = {}
if (begin || end) {
 filter['birthday'] = {}
 if (begin) {
 filter['birthday'][Sequelize.Op.gte] = begin
 }
 if (end) {
 filter['birthday'][Sequelize.Op.lt] = end
 }
}

let users = await Users.findAll({
 where: filter,
});

やっぱ公式のドキュメントは最初にチェックするようにしないとだめですね。
無駄にはまってしまいました。

参考 URL

[Node.js] Express で JSON のリクエストを取得する

Thu, 26 Aug 2021 00:00:00 +0900

クライアントから JSON でリクエストを送信しているのに、サーバー側で上手く受信できずちょっとはまりました。

Express の設定で、JSON のパーサーを指定する必要があるそうです。

const express = require('express')
const app = express()

app.use(express.json())
app.use(express.urlencoded({ extended: true }));

Content-Type に application/json を指定していても、上記の設定を行っていなければリクエストの body が空になって受信できません。

参考 URL

electron で HTTP リクエストを送る

Mon, 23 Aug 2021 00:00:00 +0900

Node.js の場合は request モジュールを使って HTTP リクエストを送っていましたが、electron のメインプロセスではどうやって送ればいいんだろうと思って調べてみたら、net モジュールというのがありました。

環境

electron v13.2.1

サンプル

const { net } = require('electron');

// リクエストの生成
let request = net.request({
 method: 'POST',
 url: 'https://example/',
 headers: {
 'Content-Type': 'application/json'
 },
});
let body = JSON.stringify({
 'sample': 'sample',
});
request.write(body);
// レスポンス受信時の処理
request.on('response', (response) => {
 console.log(`STATUS: ${response.statusCode}`)
 console.log(`HEADERS: ${JSON.stringify(response.headers)}`)
 response.on('data', (chunk) => {
 console.log(`BODY: ${chunk}`)
 })
 response.on('end', () => {
 console.log('No more data in response.')
 })
})
// リクエストの送信
request.end()

サーバー側が Node.js + Express の場合、Body の内容が受信できるようにするには以下の設定が必要です。

[Node.js] Express で JSON のリクエストを取得する

参考 URL

[Python] Tesseract で OCR を行ったら `UnicodeEncodeError: 'ascii' codec can't encode characters` のエラーが表示された

Sun, 22 Aug 2021 00:00:00 +0900

タイトルの通りです。

よくわかりませんが、UTF-8 の文字を Ascii で出力しようとしてエラーが発生している？

https://github.com/tesseract-ocr/tesstrain/issues/26

とりあえず以下の環境変数を設定したら解消しました。

$ export PYTHONIOENCODING=utf8

参考 URL

https://github.com/tesseract-ocr/tesstrain/issues/26

[Python] 文字列の判定で、None と空文字を同時に判定する

Fri, 20 Aug 2021 00:00:00 +0900

変数の値が、None または空文字 '' かどうかの判定を行う方法です。

if not str:
 # str が None または空文字の場合に実行される

if str:
 # str が None でも空文字でもない場合に実行される

参考 URL

https://stackoverflow.com/questions/9573244/how-to-check-if-the-string-is-empty

[JavaScript] コンストラクタで await したい

Thu, 19 Aug 2021 00:00:00 +0900

コンストラクタには async を指定できないため、通常はコンストラクタ内で await することができません。

ググってみるといろいろな対処法が出てきますが、とりあえず私の場合は以下のように無名関数を使って実装しました。
node.js v14.17.4 で確認しました。

class SampleClass {

 constructor() {
 (async () => {
 await this.init();
 })();
 }

 async init() {
 await hoge();
 }
}

参考 URL

[python] MongoDB を操作する

Tue, 10 Aug 2021 00:00:00 +0900

pymongo を使って MongoDB を操作します。

環境

python 3.8.10
pymongo 3.12.0

インストール

$ pip3 install pymongo

クライアントの作成

from pymongo import MongoClient

username = 'username'
password = 'password'
host = '192.168.0.1'
port = 27017
client= MongoClient(f'mongodb://{username}:{password}@{host}:{port}')

db = client['db_name']

col = db['collection_name']

書き込み

col.insert_one({
 'hoge' : 'fuga',
 'datetime': datetime.now(),
})

読み込み

find_one() で一番最初のデータ（一番古いデータ）が取得できます。

ret = col.fine_one()
print(ret)

{'_id': ObjectId('611209607654c9fcf3e8cf0b'), 'hoge': 'fuga', 'datetime': datetime.datetime(2021, 8, 10, 14, 6, 40, 659000)}

ID を指定して読み込み

from bson.objectid import ObjectId

id = '611209607654c9fcf3e8cf0b'
ret = col.find_one({ '_id': ObjectId(id) })
print(ret)

出力は上記と同じです。

削除

全ドキュメントの削除

col.delete_many({})

参考 URL

[python] ネットワークカメラの画像を RTSP で取得して表示・保存

Tue, 03 Aug 2021 00:00:00 +0900

やり方はいろいろあると思いますが、OpenCV を使えば簡単にできました。

画像を取得して表示

VideoCapture の引数に RTSP の URL を記述するだけで簡単に画像を取得できます。
URL はネットワークカメラの仕様を確認してください。
今回は Panasonic のカメラを使いました。

import cv2

user_id = "admin" 
user_pw = "password" 
host = "192.168.0.1" 
cap = cv2.VideoCapture(f"rtsp://{user_id}:{user_pw}@{host}/MediaInput/h264")

while(True):
 try:
 ret, frame = cap.read()
 if ret == True:
 cv2.imshow('VIDEO', frame)
 cv2.waitKey(1)
 except KeyboardInterrupt:
 print("KeyboardInterrupt")
 break

cap.release()
cv2.destroyAllWindows()

VideoCapture の引数を変更すれば、USB カメラや動画ファイルの読み込み、連番のJPGファイルも一括で読み込めたりするので便利です。

保存

今回 RTSP では H.264 で取得しましたが、フレームの処理は OpenCV 側で上手く処理してくれているので、キーフレームとか GOP とか何も考えずに保存できます。

JPG の保存

cv2.imwrite("sample.jpg", frame)

動画の保存

VideoWriter_fourcc でコーデックを指定します。
以下が参考になりました。

https://qiita.com/Gyutan/items/e279e8680b90ca891250

画像サイズはキャプチャから取得できる値をそのまま保存時にも使っていますが、フレームレートは取得できないので、直接指定しています。
これが合っていないと当然おかしなことになります（早送り再生やスロー再生したような状態になります）。

import cv2

user_id = "admin" 
user_pw = "password" 
host = "192.168.0.1" 
cap = cv2.VideoCapture(f"rtsp://{user_id}:{user_pw}@{host}/MediaInput/h264")

width = cap.get(cv2.CAP_PROP_FRAME_WIDTH)
height = cap.get(cv2.CAP_PROP_FRAME_HEIGHT)

fmt = cv2.VideoWriter_fourcc(*'MP4V')
frame_rate = 30.0
writer = cv2.VideoWriter("sample.mp4", fmt, frame_rate, (int(width), int(height)))

while(True):
 try:
 ret, frame = cap.read()
 if ret == True:
 writer.write(frame)
 cv2.imshow('VIDEO', frame)
 cv2.waitKey(1)
 except KeyboardInterrupt:
 print("KeyboardInterrupt")
 break

writer.release()
cap.release()
cv2.destroyAllWindows()

参考 URL

例外はいつ使うか？

Sun, 11 Jul 2021 00:00:00 +0900

今までなんとなくで例外を使っていましたが、達人プログラマーという書籍に一つの考え方があったのでメモ。

以下のような記述がありました。

「すべての例外ハンドラを除去しても、このプログラムは動作可能だろうか？」と自問してください。答えが「ノー」であれば、例外ではない状況下で例外が使われているはずです。

つまり、try-catch 文をなくしても基本的に動作可能であれば良し。
そうでないならば、普通に起こりえる状況に対しても例外で処理してしまっている（例外ではない状況で例外を使ってしまっている）。

具体的な例として、ファイルオープンの際にファイルが存在しなかった場合が挙げられています。

要約すると、

ファイルが存在しないという状況が通常起こりえないのであれば、それは例外として処理すべき
ファイルが存在しないという状況が普通に起こりえるのであれば、例外ではなくエラーとして処理しておくべき

というものです。

git-svn の使い方

Sat, 03 Jul 2021 00:00:00 +0900

社内で未だに SVN で開発しているプロダクトがあるので、git-svn を使ってみました。

環境

Ubuntu 20.04
git 2.25.1
svn 1.13.0

インストール

$ sudo apt install git-svn

クローン

SVN リポジトリを指定してクローンを行います。

$ git svn clone --prefix=svn/ <SVNリポジトリのURL>

--prefix は SVN のブランチに接頭辞をつけるオプションで、一般的に付けたほうがよいとされています。

SVN リポジトリが標準的な構成(trunk, branch, tag) になっている場合は -s オプションを付けます。
標準的な構成になっていない場合は --trunk branches --tags を使用する。
今回はルートが trunk になっており、ブランチも作成していなかったため、以下のように指定しました。

$ git svn clone --trunk=/ --prefix=svn/ <SVNリポジトリのURL>

試しにブランチを表示してみると、以下のようになっていました。

$ git branch -a
* master
 remotes/svn/trunk

コミット

コミットは普通に git を使ってやるのと同じです。

SVN リポジトリにコミットを反映する

git でのプッシュに該当する操作として、SVNにコミットを行います。
コミット前にリベースで git のコミットをまとめておいたほうがいいかもしれません。

$ git svn dcommit

SVN リポジトリから最新のデータを取得

リベースを行うことになるみたいです。

$ git svn rebase

尚、これを行うにはワークディレクトリ内の全ての変更がコミットされている必要があるみたいです。コミットしていない変更があった場合、以下のようなエラーが表示されます。

/workspace/hoge: needs update
update-index --refresh: command returned error: 1

参考 URL

git でコミットを一つにまとめる

Fri, 02 Jul 2021 00:00:00 +0900

Ｗindows 環境では TortoiseGit を使っているので GUI で出来るのですが、Ubuntu で使っている RabbitGit では出来なさそうだったので、コマンドでやりました。

TortoiseGit でのやり方は以下です。

https://kuttsun.blogspot.com/2018/09/tortoisegit.html

環境

Ubuntu 20.04

まずログを確認

$ git log --oneline

以下のように表示されます。

5418fe (HEAD -> master) fuga
f3896f7 piyo
af6639b hoge
b1da633 initial commit

ここで３つのコミット（hoge、piyo、fuga のメッセージのやつ）を一つにまとめてみます。

リベースの開始

まとめたいコミット群の一つ前のコミットに対してリベースを行います。

$ git rebase -i HEAD~3

HEAD~3 は HEAD~~~ やハッシュ値でも構いません。

すると、テキストエディタで編集画面が表示されます。
私の場合は nano で表示されました（vi じゃなくてよかった）。

pick af6639b hoge
pick f3896f7 piyo
pick c5418fe fuga

# Rebase b1da633..c5418fe onto b1da633 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

-i オプションを指定したので、この画面では Rebase を使って現在と過去の間に残ってるコミットをどう処理するかを聞かれています。

最新以外の pick の箇所を s または squash に変更します。

変更前

pick af6639b hoge
pick f3896f7 piyo
pick c5418fe fuga

変更後

pick af6639b hoge
s f3896f7 piyo
s c5418fe fuga

保存して終了すると、コミットメッセージの編集画面が開きます。
必要に応じて編集し、終了します。

参考 URL

RabbitVCS のインストール

Thu, 01 Jul 2021 00:00:00 +0900

Windows では TortoiseSVN と TortoiseGit を使っていたので、Linux でも GUI で良いのがないかなと探していたら、RabbitVCS というのが Tortoise に似た感じだったので、インストールしてみました。

環境

Ubuntu 20.04

インストール

以下に説明があります。

http://wiki.rabbitvcs.org/wiki/install/ubuntu

以下のコマンドを実行するだけでインストールできました。

$ sudo apt install rabbitvcs-nautilus

これ一つで RabbitVCS SVN RabbitVCS Git RabbitVCS Hg が使えるようになるっぽい。

あとはファイル比較用の Meld とかいうツールも勝手に入ってました。

再起動後には Tortoise と同じように、フォルダにアイコンが表示されるようになっていました。

所感

まだ全然使っていませんが、とりあえず最新のコードをプルしたりだとか、コミットログを見たりだとか、ファイルの差分を閲覧する分には困っていません。

参考 URL

[python] Tesseract を使った OCR

Tue, 29 Jun 2021 00:00:00 +0900

最も基本的なコードのメモです。

pyocr を使ったサンプル

from PIL import Image
import pyocr
 
# OCR エンジンの取得
tools = pyocr.get_available_tools()
tool = tools[0] # 今回は Tesseract しかないので、0番目に入っている

# ビルダーの作成
builder = pyocr.builders.TextBuilder(tesseract_layout=6) # デフォルト値は3

#OCR対象の画像ファイルを読み込む
img = Image.open("test.jpg")
 
#画像から文字を読み込む
result = tool.image_to_string(img, lang="jpn", builder=builder)
 
print(result)

pytesseract を使ったサンプル

from PIL import Image
import pytesseract

# pytesseract を使ったサンプル
 
#OCR対象の画像ファイルを読み込む
img = Image.open("test.jpg")
 
#画像から文字を読み込む
result = pytesseract.image_to_string(img, lang="jpn")
 
print(result)

参考 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 で "DeprecationWarning: 'inputs' property of IENetwork class is deprecated. To access DataPtrs user need to use 'input_data' property of InputInfoPtr objects which can be accessed by 'input_info' property." の警告が表示された

Fri, 25 Jun 2021 00:00:00 +0900

OpenVINO を使って推論を行うサンプルプログラムを動かしていると、以下の警告が表示されました。

DeprecationWarning: 'inputs' property of IENetwork class is deprecated. To access DataPtrs user need to use 'input_data' property of InputInfoPtr objects which can be accessed by 'input_info' property.

使用している OpenVINO のバージョンは 2021.2 ですが、IEPlugin が現在の OpenVINO からは削除されていることに関連している？

https://github.com/openvinotoolkit/cvat/issues/1830

とりあえず以下のように修正すれば動きました。

修正前

input_blob = next(iter(net.inputs))

修正後

input_blob = next(iter(net.input_info))

参考 URL

https://github.com/openvinotoolkit/cvat/issues/1830

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

[Python] InfluxDB への書き込みを行う

Thu, 17 Jun 2021 00:00:00 +0900

Python で InfluxDB へ書き込みを行う方法です。

環境

Windows 10
Python 3.8.1

ライブラリのインストール

pip でライブラリをインストールします。

> pip install influxdb

サンプルコード

まずは InfluxDBClient をインポートして、クライアントを作成します。

from influxdb import InfluxDBClient

# クライアントの作成
client = InfluxDBClient(host="127.0.0.1",
 port=8086,
 username="username",
 password="password",
 database="dbname")

DB の作成

client.create_database("dbname")

リテンションポリシーの作成

client.create_retention_policy("rpname", "30d", 1)

データの書き込み

client.write_points([
 {
 'fields': {
 'hoge': 'hoge',
 },
 'measurement': 'piyo',
 'time': time.time(),
 'tags': {
 'fuga': 'fuga',
 }
 },
 ],
	retention_policy="リテンションポリシー名")

参考 URL

Linux で USB メモリをマウントする

Wed, 16 Jun 2021 00:00:00 +0900

Ubuntu とかだと USB メモリを挿したら自動でマウントされるので何も意識しなくもいいのですが、いざ他の Linux で USB メモリを挿したときにマウントってどうやるんだっけ？となったのでメモしておきます。

環境

Wind River Linux

マウント方法

USB メモリを挿すと、/dev/sda とか /dev/sdb とかいうファイル名で認識されます。
これを /mnt/usb にマウントしてやります。

$ mkdir /mnt/usb
$ mount /dev/sdb /mnt/usb

アンマウント方法

$ umount /mnt/usb

Python で作成したアプリを単一の実行ファイルにする

Wed, 16 Jun 2021 00:00:00 +0900

python で作成したアプリを、他のマシン（ネットに繋がっていなかったり、python のバージョンが異なるマシン）で動作させたかったので、単一の実行ファイルを作成して配布することにしました。

環境

開発環境：Ubuntu
実行環境：Wind River Linux

要は、Ubuntu で作成したアプリを Wind River Linux で動作させたいだけです

単一実行ファイルの作成

pyinstaller をインストールします。

$ pip install pyinstaller

以下のコマンドで単一のファイルが作成できます。

$ pyinstaller sample.py --onefile

dist フォルダ内にバイナリファイルが作成されています。

動的リンクエラーを回避する

上記で作成したファイルを実行して動けば何の問題もないのですが、私の場合、実行環境で以下のようなエラーが表示されました。

[2841] Error loading Python lib '/tmp/_MEI1GKxS0/libpython3.8.so.1.0': dlopen: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/_MEI1GKxS0/libpython3.8.so.1.0)

これについて、以下の記事が参考になりました。

https://qiita.com/kenmaro/items/60438c1659b5598066df

今回は Ubuntu で作成したものを Wind River で動かしたので、動的リンクでエラーになったようなのですが、StaticX というツールを使えば静的リンクのみの実行ファイルが作成できるようです。

https://github.com/JonathonReinhart/staticx

StaticX のインストールと実行

$ pip install staticx

尚、環境によっては patchelf のインストールも必要みたいです。

$ pip install patchelf-wrapper

あとは、以下のようにして実行するだけです。

$ staticx <pyinstallerで作成したバイナリファイル> <出力ファイル名>

これで作成したファイルを使うと、無事に実行できました。

参考 URL

[python] ログを syslog に出力する

Tue, 15 Jun 2021 00:00:00 +0900

python でログをファイルに出力する記事を書きましたが、Linux には syslog があるので、アプリケーションのログも syslog に出力してみます。

ちなみに前回の記事はこちらです。

環境

Ubuntu 20.04
python 3.8.5

とりあえず簡単にやりたいなら

以下で OK です。

import syslog
syslog.syslog("This is a test message")
syslog.syslog(syslog.LOG_INFO, "Test message at INFO priority")

しかし、これだと syslog 固定なので、ログの出力先を変更したい場合に大変です。
なので、logger を使って抽象化したほうが良いと思います。

logger の出力先を syslog にする

from logging import handlers, basicConfig, getLogger, DEBUG

basicConfig(level=DEBUG, handlers=[handlers.SysLogHandler(address='/dev/log')])
#basicConfig(level=DEBUG, handlers=[handlers.SysLogHandler(address=("127.0.0.1",514))])

logger = getLogger('MyLogger')

logger.info('this is info')
logger.debug('this is debug')
logger.critical('this is critical')

標準出力にも出力したい

handlers に StreamHandler を追加すれば OK です。

basicConfig(level=DEBUG, handlers=[StreamHandler(), handlers.SysLogHandler(address = '/dev/log')])
#basicConfig(level=DEBUG, handlers=[StreamHandler(), handlers.SysLogHandler(address=("127.0.0.1",514))])

logger = getLogger('MyLogger')

logger.info('this is info')
logger.debug('this is debug')
logger.critical('this is critical')

Docker コンテナ内のアプリのログをホストの syslog に追加する

以下の記事で書いています。

https://kuttsun.blogspot.com/2021/12/python-syslog.html

参考 URL

[python] ログをファイルに出力する

Mon, 14 Jun 2021 00:00:00 +0900

logger を使ってログをファイルに出力します。

環境

python 3.8.5

logger によるログ出力

以下の記事を参考にさせていただきました。
logging ではなく logger を使う理由なども書かれています。

https://qiita.com/amedama/items/b856b2f30c2f38665701

from logging import basicConfig, getLogger, DEBUG

basicConfig(filename="test.log", level=DEBUG)

logger = getLogger(__name__)

logger.debug('hello')

参考 URL

https://qiita.com/amedama/items/b856b2f30c2f38665701

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 で確認できます。

参考 URL

git コマンドのメモ

Mon, 07 Jun 2021 00:00:00 +0900

普段は TortoiseGit を使っており、いざコマンドしか使えない環境のときに困るので、個人的によく使う基本的なコマンドについてメモしておきます。

適宜更新していきます。

設定

現在の設定を確認

$ git config --list

システム全体(system)、ユーザー全体(global)、対象リポジトリのみ(local)を確認したい場合はそれぞれ以下。

$ git config --system --list
$ git config --global --list
$ git config --local --list

ローカルのユーザーとメールアドレスを設定

$ git config --local user.name "My Name"
$ git config --local user.email myname@example.com

リモートリポジトリの情報

リモートリポジトリの名前を表示する

$ git remote

リモートリポジトリの名前と場所(URL）を表示する

$ git remote -v

指定したリモートリポジトリの詳しい情報を表示する

$ git remote show <リポジトリ名>

リモートリポジトリの追加・削除・変更

追加する

$ git remote add <リポジトリ名> <URL>

削除する

$ git remote rm <リポジトリ名>

URL の変更

$ git remote set-url <リポジトリ名> <変更先のURL>

開発中に使うコマンド

クローン

$ git clone <URL>

差分を表示

$ git status

-s を使えると簡略化して表示されます。

コミットの流れ

ステージング

$ git add ファイル名

コミット

$ git commit -m "コメント"

プッシュ

$ git push

最後のコミットのやり直し

$ git commit --amend -m "コミットメッセージ"

変更の破棄

$ git checkout <filename>

全て破棄したい場合は以下

$ git checkout .

参考 URL

AWS CLI のインストールと認証情報の設定

Sat, 05 Jun 2021 00:00:00 +0900

Windows と Ubuntu で設定しました。

インストール

Windows

インストーラーをダウンロードしてインストールします。

https://awscli.amazonaws.com/AWSCLIV2.msi

Ubuntu 20.04

$ sudo apt install awscli

認証情報の設定

アクセスキーの作成

AWS にログインし、IAM を選択します。
メニューより ユーザー を選択し、認証情報 タブより アクセスキーの作成 をクリックします。

アクセスキーが作成されたら、ローカルで以下のコマンドを実行します。

$ aws configure
AWS Access Key ID [None]: <Access Key>
AWS Secret Access Key [None]: <Secret Access Key>
Default region name [None]: ap-northeast-1
Default output format [None]: json

参考 URL

[python] 文字列から timedelta に変換

Thu, 03 Jun 2021 00:00:00 +0900

文字列から時差などを表す timedelta に変換する方法です。

コロンで分割して数値にし、timedelta 型に変換しています。
今回の例では microsecond まで含むので、数値は float 型にしています。

import datetime

str = "1:23:45.678900"
hours, minutes, seconds = map(float, str.split(":"))
td = datetime.timedelta(hours=hours, minutes=minutes, seconds=seconds)

print(td)

1:23:45.678900

参考 URL

Blogger の画像挿入タグが残念すぎるので、CSS で少しだけ対応する

Wed, 02 Jun 2021 00:00:00 +0900

Blogger の記事投稿画面で画像を挿入した場合、以下のようなタグで挿入されます。

※2021年6月現在の場合

<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgshA-sB1IOm4s0JYX1L5iFGbw7ifN15irj6WkGQ2PdJBW5-Ud1zN4YT1vBh7LBTmRhVAGg0ieitP8gUf9WJMDIM9oEN89NhBitkJS_s_zPTJm5FSLeCuSL9znJv6YlQIrEP9kDt7-8ZJs/s868/%25E7%2584%25A1%25E9%25A1%258C.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="320" data-original-height="240" data-original-width="868" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgshA-sB1IOm4s0JYX1L5iFGbw7ifN15irj6WkGQ2PdJBW5-Ud1zN4YT1vBh7LBTmRhVAGg0ieitP8gUf9WJMDIM9oEN89NhBitkJS_s_zPTJm5FSLeCuSL9znJv6YlQIrEP9kDt7-8ZJs/s320/%25E7%2584%25A1%25E9%25A1%258C.png"/></a></div>

とても残念です。
昔はこんな変なコードじゃなかったけどなぁ（過去の記事を見て確認）。

a タグに display: block; が追加されています。
このせいで、画像の横の余白もクリックできるようになってしまっています。

何もないところをクリックできてしまうことにすごい違和感があります。

さらに、Blogger はデフォルトでライトボックス機能が有効になっていますが、画像横の余白をクリックした場合はライトボックス機能が効きません。
画像の上をクリックしたときだけ効きます。

また、上記は配置を中央にしているのですが、これまた a タグに text-align: center; が追加されています。

従って、画像横の余白をクリックできないようにしようと display: block; を削除すると、text-align: center; が効かなくなるという残念さ。

なんで一つ上の div に設定してくれないんだろう？
というわけで、上記の display: block; text-align: center; を div タグに設定すれば解決します。

でも、画像挿入の度に手動で変更するのは面倒ですし、過去の記事全部を修正なんてやってられないので、以下の CSS を追加して対応しました。

div.separator {
 display: block;
 text-align: center;
}

.separator a {
 display: inline !important;
}

ただし、画像の配置位置は中央固定です。

きちんとやろうとすると、a タグ内の text-align の値を、親要素の div に適用させる処理が必要ですが、CSS だけではできないので、JavaScript を使う必要があります。
私はそこまでやりたくなかったので、これで妥協しました。

もしかしたら、CSS4 になったらできる？

参考 URL

https://teratail.com/questions/51614

Git で HTTPS を使う場合のアカウント情報を記憶させる

Tue, 01 Jun 2021 00:00:00 +0900

毎回打つのが面倒なので。

Windows の場合

クローンするときにユーザー名とパスワードが聞かれますが、一度入力すると資格情報マネージャーに登録されるので、２回目以降はユーザー名とパスワードの入力が不要になります。
もし入力間違いをしてしまった場合は、資格情報マネージャーで削除すれば OK です。

Linux の場合

Ubuntu 20.04 で確認しました。
libsecret をインストールして、credential.helper に設定してやります。

sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

これで、一度ユーザー名とパスワードを入力したら、次回以降は入力不要になります。

参考 URL

デザインを Materiapollo に変更しました

Tue, 01 Jun 2021 00:00:00 +0900

当ブログのテーマを Materiapollo というテーマに変更しました。

https://www.cottpic.com/2018/04/materiapollo-v0-9-1-release.html

このテーマについて、カスタマイズして点についてまとめておきます。

前準備

ソフトウェアエンジニアならばこういうテーマのカスタマイズも Git を使って管理しましょう。

ウィジェットのアイコンを追加

私はサイドバーに翻訳ウィジェットとかも表示しているので、それ用のアイコンを追加します。

変更前

.sidebar .widget.BlogArchive h2:before{content: "\e02f\00A0";}
.sidebar .widget.Label h2:before{content: "\e54e\00A0";}
.sidebar .widget.PopularPosts h2:before{content: "\e39f\00A0";}

変更後

BlogSearch Translate ContactForm を追加しました。

.sidebar .widget.Translate h2:before{content: "\e8e2\00A0";}
.sidebar .widget.BlogSearch h2:before{content: "\e8b6\00A0";}
.sidebar .widget.BlogArchive h2:before{content: "\e02f\00A0";}
.sidebar .widget.Label h2:before{content: "\e54e\00A0";}
.sidebar .widget.PopularPosts h2:before{content: "\e39f\00A0";}
.sidebar .widget.ContactForm h2:before{content: "\e0be\00A0";}

アイコンのコードは以下で調べられます。

https://fonts.google.com/icons

ボタンのテキストが大文字にならないようにする

Material-UI ではボタンのテキストは全て大文字になってしまうのですが、これを解除します。

READ MORE とラベルの二カ所について以下のように修正します。

変更前

<a class='btn col m12 right' expr:href='data:post.url' style='font-weight:600;'>Read more <i class='material-icons medium chevron_r'></i></a>

<a class='btn left post-per-page' expr:dir='data:blog.languageDirection' expr:href='data:label.url'><data:label.name/><b:if cond='data:showFreqNumbers'>

変更後

<a class='btn col m12 right' expr:href='data:post.url' style='font-weight:600;'>Read more <i class='material-icons medium chevron_r'></i></a>

<a class='btn left post-per-page' style='text-transform: none;' expr:dir='data:blog.languageDirection' expr:href='data:label.url'><data:label.name/><b:if cond='data:showFreqNumbers'>

テーマの色を変更

ヘッダーの色は #00acc1、ナビゲーションバーの色は #00bcd4 なので、これで検索したら修正箇所が見つかると思います。

ヘッダーの色とテキストの配置

変更前

header{height:200px;background-color: #00acc1; overflow: hidden; color: #fff; text-align: center;}
#headerleft{margin:0;}
.headerleft h1{padding-top: 85px;}

変更後

header{background-color: #212121; overflow: hidden; color: #fff;}
#headerleft{margin:0;}
.headerleft h1{padding-top: 15px;}

ナビゲーションバーの色

変更前

nav{background-color: #00bcd4;}

変更後

nav{background-color: #757575;}

ドロップダウンリストの色

変更前

nav.npin .dropdown-content li > a, .dropdown-content li > span {
 color: #00acc1;
}

変更後

nav.npin .dropdown-content li > a, .dropdown-content li > span {
 color: #212121;
}

パンくずリストの色

リンクの色と合わせました。

変更前

.breadcrumbs.card a {color: #00acc1;}

変更後

.breadcrumbs.card a {color: #2196f3;}
.breadcrumbs.card a:hover {color: #64b5f6;}

CSS の追加

見出しをはじめ、全体的にコンテンツ内のデザインが素っ気なかったり、一部デザインが崩れていたりしたので、以下の CSS を追加しました。

.marked は後述するマークダウンを適用している範囲を指定しています。

見出し

.marked h1, .marked h2, .marked h3, .marked h4, .marked h5, .marked h6 {
 margin: 1em 0;
 font-weight: bold;
 /* font-family: 'Material Icons' */
}

.marked h2 {
 padding: 0.4em;
 background: #eaf3ff;
 border-bottom: solid 3px #424242;
}

.marked h3 {
 padding-bottom: 0.4em;
 border-bottom: dotted 1px black;
}

.marked ul > li {
 list-style-type: disc;
}

.marked ul > li > ul > li {
 list-style-type: circle;
}

.marked ul > li > ul > li > ul > li {
 list-style-type: square;
}

.marked ul {
 padding: 0 0 0 40px;
}

.marked li {
 padding: 0px;
 margin: 0 0 4px 0;
}

.marked ol {
 padding: 0 2.5em;
 margin: .5em 0;
 line-height: 1.4;
 list-style-type: decimal;
}

デフォルト状態に戻したいだけなのに結構面倒です。
以下のページが参考になりました。

https://standard.shiftbrain.com/blog/reset-and-restore-list-item-marker

コードブロック

.marked pre {
 margin: 0.5em 0 1.5em 0;
 border-radius:10px;
}

.marked p > code {
 padding: 0.1em 0.3em;
 color: palevioletred;
 background: ghostwhite;
 border: 1px;
 border: solid 1px darkgray;
 border-radius: 5px;
}

テーブル

.marked table{
 border-collapse: collapse;
 width: 100%;
}

.marked table tr{
 border-top: solid 1px #d0d0d0;
 border-bottom: solid 1px #d0d0d0;
 cursor: pointer;
}

.marked table tr:hover{
 background-color: #eaf3ff;
}

.marked table th{
 padding: 15px;
 text-align: center;
 font-weight: bold;
}

.marked table td{
 padding: 15px;
}

デフォルトの画像を追加

記事中にある最初の画像がトップページに表示されますが、画像がない記事の場合は何も表示されず寂しいので、NO IMAGE と表示されるようにします。
ちなみに、画像ではなくマテリアルアイコンと文字列で作成しています。

ホーム画面の NO IMAGE

変更前

<b:if cond='data:post.firstImageUrl'><div class='md-thumb col s12 m5 l5' style='text-align: center;'><a expr:href='data:post.url'><img expr:src='data:post.firstImageUrl'/></a></div></b:if>

変更後

<div class='md-thumb col s12 m5 l5' style='text-align: center;'>
 <a expr:href='data:post.url'>
 <b:if cond='data:post.firstImageUrl'>
 <img expr:src='data:post.firstImageUrl'/>
 <b:else/>
 <div class="noimage">
 <i class="material-icons large">image</i><br/>
 <span>NO IMAGE</span>
 </div>
 </b:if>
 </a>
</div>

CSS

あとは上記に合わせて以下の CSS を追加します。

.noimage {
 color: #bdbdbd;
 font-size:30px;
 font-weight:bold;
}

.noimage-small {
 color: #bdbdbd;
 width: 42px;
 font-size:6px;
 font-weight:bold;
 text-align: center;
}

その他

その他、以下のことをやっています。

マークダウンで記事を書けるようにする

こちらの記事を参照してください。

シンタックスハイライトを設定する

こちらの記事を参照してください。

投稿日時と更新日時の表示

以下のページを参考にさせていただきました。

https://wrxsti-fan.blogspot.com/2020/06/blogger-materiapollo.html

テーマ適用後にやったこと

ウィジェットの追加（翻訳など）
フッターのウィジェットを削除
人気記事のスニペットを非表示にした
記事の作成者とコメント数を非表示にした

表示確認

以下、表示の確認です。

見出し１

見出し２

見出し３

見出し４

見出し５

リスト
- test
- test

インラインコードcodeだよ

赤文字はHTMLで

コードブロック

namespace hoge
{
 class hoge
 {
 int hoge = 0;
 }
}

テーブル

header	header	header
hoge	hoge テーブル内の改行は`<br>`で	hoge
hoge	hoge	hoge

記事一覧 on ポンコツ地方エンジニアの技術ブログ

Cloudflare Pages に Web Analytics を導入する

Cloudflare Web Analytics を導入する

Cloudflare Web Analytics にサイトを追加

VS Code での Git Worktree の使い方

環境

事前準備

ワークツリーの作成

ワークツリーを作業ツリーで開く

ワークツリーの削除

Ubuntu で Orca を使う

環境

ダウンロード

実行手順

エラーがでた場合

libfuse2 がない

chrome-sandbox の権限エラー

原因

Codex のレート制限リセット権の有効期限の確認方法

スクリプトの作成

実行手順

注意

Ollama で Gemma4 12B を動かして VS Code から使う

環境

Ollama のインストール

Gemma4 12B のインストールと起動

VS Code から使う

状態確認

GitHub Copilot Chat から使う

レスポンスでエラー

Continue から使う

モデルのロード・アンロードについて

VS Code で WSL 上の SSH の設定を使って Remote SSH で接続する

概要

設定手順

1. バッチファイル（ssh.bat）の作成

2. VS Code（Windows側）の settings.json の編集

3. リモート接続を実行する

OCI や AWS EC2 でセッション切断後も処理を止めないよう tmux を使う

先にまとめ

tmux のインストール

まずは 1 回動かしてみる

1. セッションを作る

2. プログラムを起動する

3. セッションを切り離す（detach）

4. 再接続する（attach）

セッションを終了して抜ける（プロセスを停止してセッションを閉じる）

今回の用途で最低限覚えるコマンド

キー操作の最小セット

よくあるハマりどころ

SSH を切ったら止まった

tmux attach で「no sessions」になる

セッション名を忘れる

OCI の Ubuntu インスタンスの初期設定

swap の設定

1. スワップファイルの作成

2. 適切な権限の設定

3. スワップ領域の初期化

4. スワップの有効化

5. 設定の確認

6. 再起動後も自動で有効化する設定

6-1. fstab のバックアップ（推奨）

6-2. 設定の追記

【おまけ】カーネルパラメータの最適化（推奨）

1. 現在の swappiness を確認

2. 一時的に 10 に変更

3. 永続的に反映

タイムゾーンの変更

nano のインストール

git のインストール

glab のインストールと認証

1. ダウンロード

2. GitLab でのアクセストークン（PAT）の発行

3. CLI の認証設定（ログイン）

tmux のインストール

docker のインストール

1. インストール

2. docker の権限を設定 (sudo を不要にする)

不要なサービスの停止

確実に停止・無効化して良いサービス

1. バッチファイル（`ssh.bat`）の作成

2. VS Code（Windows側）の `settings.json` の編集

`tmux attach` で「no sessions」になる

2. 一時的に `10` に変更

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）