記事一覧 on heppoko blog

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

GitHub に gh があるように、GitLab には glab があります。ブラウザを開かずに 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 で正常にインストールされたか確認しましょう。

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

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

記事一覧 on heppoko blog

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

きっかけ

ゴール構成

手順

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

2. gh をインストール

3. gh auth login で認証

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

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

devcontainer での認証共有

補足: SSH 鍵にしないのか

まとめ

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

1. インストール方法

2. 初期設定（認証）

3. devcontainer での認証情報共有

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

■ Merge Request (MR) を操作する

■ Issue (課題) を管理する

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

4. gh と glab の主な対応表

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

まとめ

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

gh でできること

インストール

Windows にインストールする

Ubuntu にインストールする

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

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

よく使う基本コマンド

リポジトリ操作

Issue 操作

Pull Request 操作

GitHub Actions 操作

便利な使い方

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

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

エイリアスを作る

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

ターミナルを開き直す

Git の認証方式をそろえる

GitHub Enterprise Server を使う場合

まとめ

参考 URL

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

テーマの適用

その他の設定

スキンを変更する

記事内の目次を作成する

記事を広げる

ページの作成

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

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

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

サイドバーを作成する

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

記事に投稿日を表示

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

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

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

パンくずリストの作成

参考 URL

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

参考 URL

Stable Diffusion web UI を動かしてみた

環境

手順

SDXLモデルの設定

参考 URL

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

参考 URL

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

参考 URL

Jekyll で Asciidoc を使用する

Gemfile の変更

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

参考 URL

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

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

3. `gh auth login` で認証

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