インフラ・ミドルウェア on ポンコツ地方エンジニアの技術ブログ

Cloudflare Pages に Web Analytics を導入する

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

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

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

これで OK です。

Cloudflare Web Analytics を導入する

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

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

Cloudflare Web Analytics にサイトを追加

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

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

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

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

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

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

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

swap の設定

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

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

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

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

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

sudo fallocate -l 2G /swapfile

⚠️ 警告

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

2. 適切な権限の設定

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

sudo chmod 600 /swapfile

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

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

sudo mkswap /swapfile

4. スワップの有効化

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

sudo swapon /swapfile

5. 設定の確認

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

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

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

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

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

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

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

6-2. 設定の追記

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

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

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

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

1. 現在の swappiness を確認

cat /proc/sys/vm/swappiness

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

sudo sysctl vm.swappiness=10

3. 永続的に反映

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

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

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

タイムゾーンの変更

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

nano のインストール

sudo apt update
sudo apt install -y nano

git のインストール

sudo apt update
sudo apt install -y git

glab のインストールと認証

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

1. ダウンロード

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

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

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

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

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

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

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

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

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

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

glab auth login

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

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

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

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

Token を選択します。

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

そのまま Enter を押します。

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

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

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

HTTPS を選択します。

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

glab auth status

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

tmux のインストール

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

sudo apt update
sudo apt install -y tmux

docker のインストール

1. インストール

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

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

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

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

不要なサービスの停止

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メモリ使用量の変化

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

サービス停止前

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

サービス停止後

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

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

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

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

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

前提

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

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

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

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

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

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

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

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

Ubuntu での Bastion セッション作成

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

Bastion セッションの設定

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

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

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

鍵のパーミッション

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

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

SSH での接続方法

方法１

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

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

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

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

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

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

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

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

📝 注記

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

方法２

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

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

方法３

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

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

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

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

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

ssh oci-ubuntu

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

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

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

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

ubuntu@<hostname>:~$

参考

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

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

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

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

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

仕組みとメリット

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

環境

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

📝 注記

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

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

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

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

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

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

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

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

Step2: インスタンスの作成

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

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

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

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

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

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

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

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

📝 注記

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

Step4: Bastionの作成

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

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

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

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

Step5: セッションの作成

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

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

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

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

Step6: SSH接続の実行

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

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

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

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

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

📝 注記

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

📝 注記

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

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

SSH キーについての補足

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考

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

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

OCI (Oracle Cloud Infrastructure)

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

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

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

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

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

どちらを選ぶべきか？

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

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

OCI への登録

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

参考

インスタンスの作成

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

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

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

基本情報

イメージ

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

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

シェイプ

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

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

VM.Standard.A1.Flex

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

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

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

VM.Standard.E2.1.Micro

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

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

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

セキュリティ

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

ネットワーキング

プライマリVNIC

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

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

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

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

SSHキーの追加

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

📝 注記

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

ストレージ

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

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

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

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

作成

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

API エラーが発生した場合

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

解決策は以下です。

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

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

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

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

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

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

インスタンスの起動

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

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

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

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

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

Cloud Shell の起動

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

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

ネットワークの変更

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

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

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

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

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

chmod 600 ssh-key-xxxx.key

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

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

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

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

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

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

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

とりあえずはここまで。

参考

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

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

前提・環境

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

GitLab 側で必要なこと

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

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

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

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

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

Cloudflare Pages 側のセットアップ

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

Create application を選択します。

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

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

Git プロバイダの接続

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

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

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

初回デプロイの確認

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

カスタムドメインの設定

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

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

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

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

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

SSL/TLS モードの変更

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

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

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

気をつけること

`NODE_VERSION` の明示

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

ビルド時間と無料枠

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

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

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

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

まとめ

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

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

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

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

全体の流れ

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

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

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

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

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

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

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

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

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

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

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

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

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

① CNAMEレコード（接続用）

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

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

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

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

① GitLabで検証する

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

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

② SSL証明書の発行を待つ

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

command: "redis-server":

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

command: sh -c "redis-server":

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

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

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

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

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

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

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

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

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

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

Dockerfile のサンプル

FROM python:3.11-windowsservercore-1809

CMD ["cmd.exe"]

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

コンテナ起動例

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

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

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

参考 URL

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

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

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

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

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

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

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

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

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

環境

Windows 10 Pro

Windows の機能の有効化

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

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

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

インストール方法

バイナリのダウンロード

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

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

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

ProgramFiles への展開

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

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

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

サービスへの登録

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

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

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

サービスの開始

> Start-Service docker

動作確認

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

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

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

環境変数へパスを通す

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

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

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

> docker run hello-world:nanoserver

プロキシ設定

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

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

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

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

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

> Restart-Service docker

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

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

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

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

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

エラーが発生した場合

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

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

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

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

アンインストール

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

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

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

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

アップデート

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

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

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

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

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

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

3.11-windowsservercore-ltsc2022
3.11-windowsservercore-1809

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

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

参考 URL

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

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

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

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

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

サンプル

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

version: '3'

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

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

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

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

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

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

# echo $(hostname)

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

$ docker stack rm my_stack

参考 URL

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 にアップグレードしました。以上で完了です。

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

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

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

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

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/

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

Grafana でアラートを設定する

Wed, 30 Nov 2022 00:00:00 +0900

Grafana で任意の値が閾値を超えたら（または下回ったら）アラートを発報するように設定します。

設定方法は Grafana のバージョンによって大きく異なるようですが、今回使用した Grafana 9.1.0 では、以下の３段階で設定を行うようです。

Alert rules: アラート条件の設定
Contact points：通知先の登録
Notification policy：アラート条件と通知先の関連付け

環境

Grafana 9.1.0

アラート条件の設定

左のサイドメニューより、Alerting > Alert rules をクリックします。
New alert rule をクリックします。
1. Set a query and alert condision で監視したい値や閾値を設定します。（具体的な設定例は後述します。）
2.Alert evaluation behavior でアラート保留状態となる時間を設定します。
デフォルトでは１分毎に評価し、アラートを検出した後５分が経過したら通知が行われるようになっています。
3. Add details for your alert でこのアラートの名前や説明を記載します。
4. Notifications で通知先のラベルを指定します（後述）。
指定しなかった場合はデフォルトの通知先が使用されます（後述）。
設定が完了したら画面右上の Save で保存します。

通知先の登録

左のサイドメニューより、Alerting > Contact points をクリックします。
New contact points をクリックします。
Name で適当な名前を付け、Contact point type で通知方法を選択します（後述）。
設定が完了したら Save contact point で保存します。

具体的な設定例

通知先によって異なるため、別記事にまとめます。

アラート条件と通知先の関連付け

左のサイドメニューより、Alerting > Notification policies をクリックします。
デフォルトの通知先の変更や、特定のラベルのアラートに対する通知先を設定します（後述）。
Save policy をクリックして保存します。

デフォルトの通知先を指定

Root policy の右側にある Edit をクリックします。
Default contact point でデフォルトの通知先を指定します。

特定のラベルに対する通知先を指定

New specific policy をクリックします。
Add matcher でラベルの条件を指定し、Contact point で通知先を指定します。

参考 URL

https://doc.cloud.global.fujitsu.com/lib/monitoringservice/jp/usersguide/capter02/alerting/alert_rule/

overlayroot の有効無効をシェルスクリプト化

Tue, 18 Oct 2022 00:00:00 +0900

overlayroot を使ってファイルシステムを読み取り専用にしましたが、現在読み取り専用になっているのかどうかのチェックと、有効無効を簡単に切り替えられるようなスクリプトを作成してみました。

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

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

overlayroot が有効か無効かをチェック

#!/bin/bash

mount | grep 'overlayroot on / type overlay' &> /dev/null
if [ $? == 0 ]; then
 echo "overlayroot enabled" 
else
 echo "overlayroot disabled"
fi

&> /dev/null は標準出力と標準エラー出力の破棄です。

https://qiita.com/ritukiii/items/b3d91e97b71ecd41d4ea

$? は直前に実行したコマンドの終了値です（0は成功、1は失敗）。

https://qiita.com/zayarwinttun/items/0dae4cb66d8f4bd2a337

overlayroot を無効にする

#!/bin/bash

sudo overlayroot-chroot rm /etc/overlayroot.local.conf

overlayroot-chroot で一時的に書き込み可能状態にして /etc/overlayroot.local.conf を削除しているだけです。

overlayroot を有効にする

#!/bin/bash

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

/etc/overlayroot.local.conf を作成して overlayroot="tmpfs:recurse=0" を記述しているだけです。

サンプル

以上を踏まえて作成してみたのが以下のスクリプトです。

#!/bin/bash
# ex: ./overlayroot.sh disable
# ex: ./overlayroot.sh enable
# ex: ./overlayroot.sh

timeout=3

# 現在の overlayroot の状態を取得
mount | grep 'overlayroot on / type overlay' &> /dev/null
if [ $? == 0 ]; then
 overlay=true
 echo "overlayroot enabled"
else
 overlay=false
 echo "overlayroot disabled"
fi

if [[ $1 = disable ]]; then
 # overlayroot を無効にする
 if [ $overlay = true ]; then
 echo "disable overlayroot..."
 sudo overlayroot-chroot rm /etc/overlayroot.local.conf
 echo -e "\nReboot after ${timeout} seconds"
 sleep ${timeout}
 sudo reboot
 else
 echo "overlayroot already disabled"
 fi
elif [[ $1 = enable ]]; then
 # overlayroot を有効にする
 if [ $overlay = true ]; then
 echo "overlayroot already enabled"
 else
 echo "enable overlayroot..."
 echo 'overlayroot="tmpfs:recurse=0"' | sudo tee /etc/overlayroot.local.conf
 echo -e "\nReboot after ${timeout} seconds"
 sleep ${timeout}
 sudo reboot
 fi
fi

echo -e "\nCloses after ${timeout} seconds"
sleep ${timeout}

参考 URL

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

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

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

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

参考 URL

NTP サーバー/クライアント chrony の設定

Thu, 29 Sep 2022 00:00:00 +0900

chrony を使って NTP サーバー、NTP クライアントのぞれぞれを設定してみました。

環境

Ubuntu 20.04
chrony 3.5

インストール

$ sudo apt install chrony

NTP サーバーとしての設定

/etc/chrony/chrony.conf をエディタで編集します。

$ sudo nano /etc/chrony/chrony.conf

上位サーバーの無効化

17行目〜20行目をコメントアウトします。

#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2

認証の無効化

24行目をコメントアウトします。

#keyfile /etc/chrony/chrony.keys

アクセス許可

特定のセグメントからのみアクセスを許可したい場合は以下のように追記します。

# Allow NTP client access from local network.
allow 192.168.4.0/24

全セグメントから許可シたい場合は allow とだけ記載するようです。

上位の NTP サーバーがいなくても同期を取れるようにする

以下を追記します。

# Serve time even if not synchronized to a time source.
local stratum 5

再起動

設定が完了したら chrony を再起動します。

$ sudo systemctl restart chrony

NTP クライアントとしての設定

/etc/chrony/chrony.conf をエディタで編集します。

$ sudo nano /etc/chrony/chrony.conf

17行目〜20行目をコメントアウトし、pool <NTPサーバーのIPアドレス> iburst> を追記します。

#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2
pool 192.168.0.10 iburst

時刻同期について

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

chrony は iburst オプションの付いた NTP サーバーに対して、起動直後に短い間隔で4回問い合わせをするそうです。また、デフォルトでは makestep 1 3 の設定がありますが、これは chrony の起動時に、1.0 秒以上時刻ずれが 3 回続いた場合、step モードで一気に時刻補正をするという意味だそうです。そうでない場合は slew モードで少しずつ時刻補正を行うそうです。

再起動

設定が完了したら chrony を再起動します。

$ sudo systemctl restart chrony

確認

chronyc sources を実行し、サーバー名の最初に * と表示されていれば同期が取れています。

$ chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample 
===============================================================================
^* 192.168.0.10 5 6 377 34 -7277ns[-2447ns] +/- 41us

ちょっとはまったところ

きちんと同期がとれているか確認するために、サーバー側の日時を Ubuntu の GUI で変更し、クライアントの PC を再起動してみましたが、同期されませんでした。
何でだろうと思っていたら、日時を GUI で変更したときに chrony のサービスが停止していました。

chrony が動いているかどうかは以下のコマンドで確認できます。

$ sudo systemctl status chrony

もし chrony が停止していた場合は、以下のコマンドで起動します。

$ sudo systemctl start chrony

この状態でクライアントの PC を再起動したら、起動時に日時が同期されました。

もし PC 再起動後に chrony が停止していた場合は有効化されていないので、以下のコマンドを実行します。

$ sudo systemctl enable chrony

参考 URL

InfluxDB のコマンド (InfluxQL)

Thu, 22 Sep 2022 00:00:00 +0900

ちょっと何かしたいというときに毎回コマンドを調べているので、個人的によく使うコマンドをまとめてみました。

環境

Ubuntu 20.04
InfluxDB 1.8.0

事前知識

influx コマンドで DB との対話モードとなります。
この状態でコマンドを実行していきます。
尚、対話モードに入らずに以下のようにしてコマンドを実行することもできます。

$ influx -execute "コマンド"

以下、対話モードになっている前提でコマンドのみ記載します。

データベースの作成

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#create-database

create database <データベース名> を実行します。

> create database sampledb

データベースの表示

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#show-databases

show databases を実行します。

> show databases
name: databases
name
----
sampledb
_internal

リテンションポリシーの作成

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#create-retention-policy

create retention policy <リテンションポリシー名> on <データベース名> を実行します。

> create retention policy samplerp on sampledb duration 30d replication 1 default

duration : 保存期間を指定
- https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#durations
replication : でレプリケーション数を指定
default : このリテンションポリシーをデフォルトにする

リテンションポリシーの表示

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#show-retention-policies

use <データベース名> でデータベースを選択し、show retention policies で表示します。

> use sampledb
Using database sampledb
> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------
autogen 0s 168h0m0s 1 false
samplerp 720h0m0s 24h0m0s 1 true

リテンションポリシーの保存期間を変更

https://docs.influxdata.com/influxdb/v1.8/query_language/spec/#alter-retention-policy

alter retention policy <リテンションポリシー名> on <データベース名> duration <保存期間> を実行します。

> alter retention policy samplerp on sampledb duration 180d

show retention policies で変わったことを確認します。

> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------
autogen 0s 168h0m0s 1 false
samplerp 4320h0m0s 24h0m0s 1 true

TIG Stack を動かしてみる

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

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

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

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

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

予備知識

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

環境

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

Ubuntu 20.04
Docker 20.10.12
Telegraf 1.23.0
InfluxDB 1.8.10
Grafana 9.1.0

各ツールの役割

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

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

Telegraf の設定

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

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

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

docker-compose.yml

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

$ docker network create tigstack

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

Telegraf について

GPU の情報取得について

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

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

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

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

Docker の情報取得について

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

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

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

ホスト名の指定

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

hostname: ${HOSTNAME:?}

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

InfluxDB について

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

environment:
 DOCKER_INFLUXDB_INIT_MODE: setup
 DOCKER_INFLUXDB_INIT_RETENTION: 10d

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

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

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

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

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

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

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

参考 URL

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

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

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

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

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

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

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

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

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

参考 URL

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

Telegraf で CPU の温度を取得する

Wed, 24 Aug 2022 00:00:00 +0900

タイトルの通りです。

環境

Ubuntu 20.04

CPU の温度観測プローブを調べる

以下の記事が参考になりました。

https://qiita.com/koara-local/items/1fac13704123717f5cc8

/sys/class/thermal に thermal_zone0 〜 thermal_zone3 の４つのディレクトリがあり、このうちのどれかが CPU の温度観測用のファイルのようです。
これらの中にある type ファイルを見ることで、何の温度を表しているかが分かるようです。

$ cat /sys/class/thermal/thermal_zone0/type
acpitz
$ cat /sys/class/thermal/thermal_zone1/type
acpitz
$ cat /sys/class/thermal/thermal_zone2/type
pch_skylake
$ cat /sys/class/thermal/thermal_zone3/type
x86_pkg_temp

どうやら私の環境では thermal_zone3 が CPU の温度のようです。
なので、/sys/class/thermal/thermal_zone3/temp を見ることで CPU の温度が取得できます。

$ cat /sys/class/thermal/thermal_zone3/temp
35000

1000 倍された値が表示されるので、上記の場合 35℃ です。

Telegraf の設定

上記のファイルを監視するように、telegraf.conf に以下を記述するだけです。

[[inputs.file]]
 files = ["/sys/class/thermal/thermal_zone3/temp"]
 name_override = "cpu_temperature"
 data_format = "value"
 data_type = "integer"

参考 URL

overlayroot 環境内で docker を使う方法

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

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

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

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

問題点

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

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

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

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

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

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

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

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

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

対処方法

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

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

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

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

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

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

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

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

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

参考 URL

Rocket.Chat の REST API でダイレクトメッセージを送る

Wed, 17 Aug 2022 00:00:00 +0900

アプリケーションから Rocket.Chat のユーザーに対してダイレクトメッセージを送りたかったので、調べてみたら、REST API を使うことでできました。

使用した API の仕様は以下です。

https://developer.rocket.chat/reference/api/rest-api/endpoints/core-endpoints/chat-endpoints/postmessage

例えば Windows の場合、以下のようなコマンドで動作を確認できました。
（ユーザー名の部分だけ変更してください。）

curl.exe -X POST^
 -H "X-Auth-Token: <Token>"^
 -H "X-User-Id: <User-Id>"^
 -H "Content-type:application/json"^
 http://rocketchat-url/api/v1/chat.postMessage^
 -d "{\"channel\": \"@ユーザー名\", \"msg\": \"This is a direct message!\" }"

Token と User-Id は、マイアカウント > パーソナルアクセストークンから作成できます。
REST API の実行権限のあるアカウントで作成する必要があります。

メッセージの内容については上記の API 仕様を参照してください。
例えば、以下のようにして通知者名とアイコンを変更することができます。

curl.exe -X POST^
 -H "X-Auth-Token: <Token>"^
 -H "X-User-Id: <User-Id>"^
 -H "Content-type:application/json"^
 http://rocketchat-url/api/v1/chat.postMessage^
 -d "{\"channel\": \"@ユーザー名\", \"msg\": \"This is a direct message!\", \"alias\": \"ほげ\", \"emoji\": \":thumbsup:\" }"

参考 URL

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

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

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

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

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

環境

InfluxDB: 1.8.10

作成方法

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

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

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

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

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

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

確認方法

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

$ docker exec -it influxdb bash

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

# influx
> show databases

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

# influx
> use dbname
> show retention policies

参考 URL

Ubuntu に nginx を入れてリバースプロキシとして使用する

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

環境

Ubuntu 20.04

インストール

$ sudo apt install nginx

http://localhost にアクセスして nginx が起動していることを確認します。

設定

nginx の設定ファイルは /etc/nginx/nginx.conf ですが、この中を見ると、http ディレクティブの中に以下の記述があります。

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

conf.d と sites-enabled の中に置いた設定ファイルが読み込まれるようになっています。
２つの使い分けについては以下のページが参考になりました。

https://qiita.com/tomokon/items/e782636c1e5ec6b5dfdc

というわけで、sites-available に設定ファイルを作成して、sites-enabled にシンボリックリンクを作成します。

conf ファイルの追加

$ sudo nano /etc/nginx/sites-available/sample.conf

以下を追記します。

server {
 listen 80 default_server;
 server_name _;
 location / {
 proxy_pass http://localhost:5000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

server_name の _; は catch-all の意味らしく、任意の URL に対して有効になります。

http://nginx.org/en/docs/http/server_names.html

proxy_pass が遷移先の URL です。
その他の設定については以下を参考にさせてもらいました。

https://lh182051.hateblo.jp/entry/2019/11/22/010641

デフォルトの設定の削除

sites-enabled の中には最初から default という設定へのシンボリックリンクがあります。
設定内容次第ではこの default の設定が邪魔になることもあるので、そのような場合は削除しておきます。

今回の場合は default_server と server_name _; が重複しているので、削除しておかないと上手くルーティングできません。

$ sudo rm /etc/nginx/sites-enabled/default

シンボリックリンクの作成

$ sudo ln -s /etc/nginx/sites-available/sample.conf /etc/nginx/sites-enabled/sample

nginx を再起動します。

$ sudo systemctl restart nginx

以上で完了です。

参考 URL

Rocket.Chat の読み取りチャンネルで絵文字の追加を許可する

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

デフォルトだと読み込み専用チャンネルでは絵文字（リアクション）の追加ができませんが、設定を変更すればできるようになります。

チャンネルの設定画面で「反応を許可する」を ON にすればいいだけですが、これを設定できるのはデフォルトだと Admin または Owner 権限を持つユーザーのみです。

他のロールにもこの権限を付与したい場合は、root でログインし、「管理 > 権限」を選択し、「ReadOnly時の反応を設定する」にチェックを入れます。

参考 URL

https://martinschoeler.github.io/docs/administrator-guides/permissions/

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

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

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

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

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

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

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

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

docker-compose の場合

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

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

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

user: ${TELEGRAF_UID_GID}

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

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

参考 URL

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

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

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

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

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

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

環境変数の参照

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

補間 (interpolation)

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

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

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

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

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

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

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

参考 URL

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

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

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

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

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

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

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

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

$ export HOSTNAME && docker-compose up

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

参考 URL

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

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

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

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

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

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

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

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

環境

Docker 20.10.12
Portainer 2.13.1
Python 3.8.10
aiohttp 3.8.1

サンプルコード

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

import asyncio
import aiohttp

PORTAINER_URL="http://portainer_url"

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

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

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

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

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

トークンの取得

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

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

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

前者の場合は

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

後者の場合は

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

のように記述します。

Environment(endpoint) ID の取得

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

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

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

コンテナの一覧を取得

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

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

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

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

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

参考 URL

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

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

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

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

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

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

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

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

参考 URL

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

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

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

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

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

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

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

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

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

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

余談

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

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

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

参考 URL

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

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

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

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

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

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

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

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

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

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

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

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

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

# Stage1: build
FROM ubuntu:20.04 as build

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

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

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


# Stage2: release
FROM ubuntu:20.04

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

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

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

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

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

参考 URL

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

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

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

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

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

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

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

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

参考 URL

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

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

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

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

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

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

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

環境

Docker 20.10.12
Traefik v2.7

イメージ図

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

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

サンプル

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

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

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

参考 URL

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

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

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

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

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

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

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

環境

Docker 20.10.12
Traefik v2.7

イメージ図

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

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

サンプル

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

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

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

参考 URL

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

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

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

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

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

環境

Docker: 20.10.12
Traefik: v2.7

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

docker network の作成

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

$ docker network create sample-network

Traefik の設定

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

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

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

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

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

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

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

docker-compose.yml で設定する例

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

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

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

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

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

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

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

docker-compose での例

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

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

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

参考 URL

Portainer を Docker Swarm で動かす

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

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

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

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

環境

Docker 20.10.12
Portainer 2.13.1

Docker Swarm の有効化

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

$ docker swarm init

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

Portainer の起動

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

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

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

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

中身はこんな感じです。

version: '3.2'

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

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

networks:
 agent_network:
 driver: overlay
 attachable: true

volumes:
 portainer_data:

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

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

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

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

$ docker stack rm portainer

参考 URL

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

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

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

環境

Docker 20.10.12

DinD と DooD

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

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

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

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

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

DooD サンプル

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

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

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

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

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

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

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

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

というわけで、DooD では

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

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

参考 URL

Ubuntu の IP アドレスを固定化する

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

いつもは GUI で設定するのですが、あるとき IP アドレスを変更しても再起動後に元に戻ってしまうという現象が発生して悩んでいました。
調べたら他の人が IP アドレスを固定化してたのが原因だとわかったので、ついでにそのやり方をメモしておきます。

環境

Ubuntu 20.04

設定方法

/etc/netplan/ に yaml ファイルを作成します。

ここに作成したファイルが名前順に読み込まれ、後に読み込まれた内容のほうが優先されるようです。

Ubuntu Desktop の場合、デフォルトで 01-network-manager-all.yaml があり、ネットワークマネージャーでの設定が反映されるようになっています。

IP アドレスを固定化したい場合は、/etc/netplan/99_config.yaml など、後に読み込まれるようなファイル名でファイルを作成し、設定を上書きしてやるそうです。
yaml ファイルの書き方なども含め、公式ドキュメントは以下になります。

https://ubuntu.com/server/docs/network-configuration

例えば以下のような感じです。

network:
 version: 2
 ethernets:
 eth0:
 addresses:
 - 192.168.1.10/24
 gateway4: 192.168.1.1
 optional: true

参考 URL

Jetson Xavier NX を触ってみた

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nvidia-smi がない？

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

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

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

ストレージ容量が少ない

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

CUDA バージョン

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

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

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

結構古かったです。

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

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

CPU が arm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考 URL

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

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

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

環境

Ubuntu 20.04
Docker 20.7

動かし方

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

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

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

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

参考 URL

https://github.com/swarmpit/swarmpit

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

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

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

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

概念図

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

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

Docker イメージ

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

Docker コンテナ

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

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

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

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

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

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

データボリューム

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

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

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

docker-compose

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

Swarm モード

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

ノード

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

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

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

サービスとタスク

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

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

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

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

スタック

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

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

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

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

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

参考 URL

Jetson Xavier NX でルートファイルシステムを overlayroot で読み込み専用に設定する

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

以前、Ubuntu で overlayroot を使ってルートファイルシステムを読み込み専用にしてみたのですが、Jetson Xavier NX で同じように試してみたところ、それだけではだめでした。

恐らくですが、ブートローダーが EXTLINUX であることが原因のような気がしています。

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/uboot_guide.html#wwpID0E0YD0HA

Jetson Xavier NX ではどうやってやればいいのかググってみると、NVIDIA のフォーラムで議論されているのが見つかりました。

その中で、解決策として提示されていたのが以下です。

https://github.com/negachov/overlayroot-jetpack

環境

Jetson Xavior NX
Ubuntu 18.04
JetPack 4.5.1

overlayroot のインストールと有効化

以下の記事を参考にしてください。

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

Jetson Xavier NX ではこれに加え、次のことが必要でした。

/boot/initrd の置き換え

GitHub にスクリプトが公開されているので、まずこれをクローンします。

$ git clone https://github.com/negachov/overlayroot-jetpack

あとは以下を実行するだけです。

$ cd overlayroot-jetpack
$ sudo ./update-initramfs-jetpack
$ reboot

これで、再起動後に overlayroot が有効になっていました。

参考 URL

Ubuntu のファイルシステムを overlayroot で読み込み専用にする

Mon, 25 Apr 2022 00:00:00 +0900

電源ブチ切り対策の一環として、overlayroot で Ubuntu の rootfs を read only にしてみました。

やり方はいろいろググってみましたが、以下のサイトがとても参考になりました。

環境

Ubuntu 20.04 (デスクトップ版)

現在の状態を確認

mount コマンドで確認してみます。

$ mount

抜粋ですが、以下の状態が確認できます。

/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)

overlayroot のインストール

サーバー版には最初からインストールされているそうですが、デスクトップ版にはインストールされていないので、apt でインストールします。

$ sudo apt install overlayroot

overlayroot の有効化

overlayroot を有効化するには、以下のいずれかの対応が必要だそうです。

カーネルパラメーターに overlayroot=XXX を指定する
/etc/overlayroot.local.conf に overlayroot="XXX" を指定する
/etc/overlayroot.conf に overlayroot="XXX" を指定する

設定内容は上位のほうが優先されるそうです。
今回は /etc/overlayroot.local.conf に設定を追加します。
まずはエディタで開きます。

$ sudo gedit /etc/overlayroot.local.conf

以下を追記します。

overlayroot="tmpfs"

コマンド一発でやるなら以下です。

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

tmpfs はメモリ上に作成ファイルシステムで、一時的にデータを格納するために使われます。

https://linuc.org/study/knowledge/441/

Linux ではマウントするファイルシステムの情報が /etc/fstab に書かれていますが、ここが overlayroot における下位レイヤーとなり、読み込み専用レイヤーとなります。
そして、先ほど追記した tempfs が上位レイヤーとなり、書き込み可能レイヤーとなります。
ここらへんは後述するように mount コマンドで確認可能です。

ただし、tmpfs はメモリ上に作成されたファイルシステムなので、再起動時にはデータは消えます。

ルートファイルシステムのみを読み取り専用にする

パーティションを分けている場合などで、ルートファイルシステムのみを読み取り専用にするためには、/etc/overlayroot.local.conf に tmpfs:recurse=0 を指定するらしいです。
コマンド一発でやる場合は以下。

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

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

これで再起動すれば、ルートファイルシステムのみが読み取り専用となり、他のパーティションは読み書き可能な状態となります。

確認

先ほどと同じように mount コマンドで確認してみます。

$ mount

抜粋ですが、以下の状態が確認できました。

/dev/sda2 on /media/root-ro type ext4 (ro,relatime)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime,inode64)
overlayroot on / type overlay (rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_)

ルートファイルシステムが /media/root-ro に読み込み専用(ro)の下位レイヤー(lowerdir) として設定され、tmpfs が /media/root-rw/overlay に書き込み可能(rw)な上位レイヤー(upperdir) して設定されているのが確認できます。

ファイルが消えることを確認

ついでに、ホームディレクトリに適当にファイルを作成し、再起動時にファイルが消えていることを確認します。

overlayroot の無効化

/etc/overlayroot.local.conf を削除するか、/etc/overlayroot.local.conf を編集して中身を overlayroot="" に変更すれば、overlayroot の無効化されます。

しかし、現在は overlayroot が有効化になっている状況なので、このまま変更しても再起動後にはまた元に戻ってしまいます。
そのため、この変更は一時的に書き込みを許可した状態で行う必要があります。
一時的に書き込み可能な状態にするには以下のコマンドを実行します。

$ sudo overlayroot-chroot

そして、/etc/overlayroot.local.conf を削除するか、/etc/overlayroot.local.conf を編集して中身を overlayroot="" に変更します。

# rm /etc/overlayroot.local.conf

exit でシェルから抜ければ書き込み可能状態は終了します。

# exit

再起動後、overlayroot が無効状態になっています。

GRUB メニューで時間がかかることの対策

overlayroot を有効にした状態で再起動すると、GRUB メニューが表示され、30秒ほど待たされるようになります。
詳細は以下をご参照ください。

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

起動が30秒も遅くなるのは困るので、以下を参考にして GRUB の設定を変更しました。

※以下は overlayroot を無効にした状態で行う必要があります！

/etc/default/grub をエディタで開きます。

$ sudo nano /etc/default/grub

以下を追記します。

GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT

設定を反映するために以下のコマンドを実行します。

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

これで overlayroot を有効にしても起動時間は変わらなくなりました。

参考 URL

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

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

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

前回の記事は以下。

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

準備

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

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

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

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

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

確認

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

$ docker service inspect --pretty redis

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

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

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

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

アップデート

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

$ docker service update --image redis:3.0.7 redis

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

確認

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

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

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

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

$ docker service inspect --pretty redis

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

$ docker service update redis

参考 URL

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

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

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

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

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

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

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

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

https://circleci.com/ja/blog/docker-swarm-vs-kubernetes/

環境

Ubuntu 20.04
- Docker 20.10.7
Ubuntu 20.04 on WSL2 on Windows10
- Docker 20.10.10

Docker はインストール済みの前提です。
Docker がインストールされていれば Swarm モードも使えます。

チュートリアルでは Docker ホストは３つありますが、用意できなかったので Ubuntu と WSL2 上の Ubuntu の２つでやりました。

概要

Docker Swarm モードは manager ノードと worker ノードから構成されます。
ノードというのは Docker のホスト（Docker エンジンが動作している環境）の単位になります。

manager ノードはクラスタを管理するノード
worker ノードはコンテナを稼働させるノード
manager ノードは worker ノードを兼ねることもできる

Swarm モードの有効化

Swarm モードを有効化するには docker swarm init を実行します。
このコマンドを実行すると manager ノードが作成されるので、manager ノードを作成したいマシン上で実行します。

$ docker swarm init
Swarm initialized: current node (z9voajpw84i4jk2fomqwsmnc7) is now a manager.

To add a worker to this swarm, run the following command:

 docker swarm join --token SWMTKN-1-23t6ldii7xxyyol2ulu0qddlqgwp3i1xpckiij2yjpintebbjq-bw598idhl229sykrhyiykviiw 192.168.1.10:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

出力結果には worker ノードを manager ノードに登録するためのコマンドが表示されます（後述）。

また、１つのマシンに複数のIPアドレスが割り当てられている場合、以下のように --advertise-addr オプションで他のノードとの通信に使用するIPアドレスを指定することもできます。

$ docker swarm init --advertise-addr 192.168.1.10

確認

Swarm モードが有効になっているかどうかは docker info で確認できます。

$ docker info

抜粋ですが、以下のような出力が確認できます。

Swarm: active
 NodeID: z9voajpw84i4jk2fomqwsmnc7
 Is Manager: true
 ClusterID: 61lmt9ptc8jyphn725cj96vxj
 Managers: 1
 Nodes: 1

ノードに関する情報は docker node ls で確認できます。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

worker ノードの作成

worker ノードの作成には docker swarm init を実行したときの出力結果に表示されたコマンドを使います。
manager ノードを作成したマシンとは別のマシンで以下のコマンドを実行します。

$ docker swarm join --token SWMTKN-1-23t6ldii7xxyyol2ulu0qddlqgwp3i1xpckiij2yjpintebbjq-bw598idhl229sykrhyiykviiw 192.168.1.10:2377
This node joined a swarm as a worker.

もし上記のコマンドが分からない場合は、docker swarm join-token worker で確認できます。

$ docker swarm join-token worker
To add a worker to this swarm, run the following command:

 docker swarm join --token SWMTKN-1-23t6ldii7xxyyol2ulu0qddlqgwp3i1xpckiij2yjpintebbjq-bw598idhl229sykrhyiykviiw 192.168.1.10:2377

尚、既に worker ノードを作成済みであったり、manager ノードを作成しているマシンで docker swarm join を実行した場合、以下のエラーが表示されます。

Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.

確認

先ほどと同じように docker node ls で確認できます。
尚、このような Swarm を管理するコマンドは manager ノードが動作しているマシンでのみ実行可能です。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
hqi4gtcdh4a7ya8myg0x0my37 worker1 Ready Active 20.10.12
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

サービスのデプロイ

ノードを作成したので、そこにサービスを追加していきます。
まずは manager ノードにサービスを追加します。
上述したように、manager ノードは worker ノードも兼ねることができるので、サービスを動かすこともできます。

manager ノードが動作しているマシンで docker service create を実行します。

$ docker service create --replicas 1 --name helloworld alpine ping docker.com
84aq1iszx44xq2f3cmohfl2tu
verall progress: 1 out of 1 tasks 
1/1: running [==================================================>] 
verify: Service converged

ここでは、alpine のベースイメージで helloworld という名前のコンテナを作成し、コンテナ内で ping docker.com というコマンドを実行しています。
--replicas 1 はコンテナの数です。

確認

docker service ls で実行中のサービスを確認できます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
84aq1iszx44x helloworld replicated 1/1 alpine:latest

サービスの詳細を調べる

別記事に書きました。

https://kuttsun.blogspot.com/2022/04/docker-swarm.html

サービスのスケール

Swarm で実行しているサービスをスケールするには、docker service scale <サービスID>=<タスク数> を実行します。
尚、サービス内で実行中のコンテナを「タスク」（task）と呼ぶそうです。

$ docker service scale helloworld=5
helloworld scaled to 5
overall progress: 5 out of 5 tasks 
1/5: running [==================================================>] 
2/5: running [==================================================>] 
3/5: running [==================================================>] 
4/5: running [==================================================>] 
5/5: running [==================================================>] 
verify: Service converged

確認

docker service ps <サービスID> で確認すると、インスタンスが合計５つになったのが分かります。
タスク（コンテナ）は Swarm のノード間で分散されています。

また、各ノードで docker ps を実行することでコンテナの情報が確認できます。

サービスの削除

$ docker service rm helloworld
helloworld

確認

docker service ls で helloworld サービスが削除されたのを確認できます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS

docker service inspect で調べようとしてもそんなサービスはないと言われます。

$ docker service inspect helloworld
[]
Status: Error: no such service: helloworld, Code: 1

docker ps でタスク（コンテナ）も削除されたことを確認できます。

ノードの削除

とりあえずここまでやってみました。
チュートリアルでは次はローリングアップデートとなっていますが、そこはまた今度にします。

尚、上記サービスは削除しましたが、ノードは残ったままです。
ノードの削除方法（Swarm モードの停止方法）を別記事に書きました。

https://kuttsun.blogspot.com/2022/04/docker-swarm_21.html

参考 URL

[Docker] Swarm モードの停止

Thu, 21 Apr 2022 00:00:00 +0900

Docker Swarm モードを停止するには、Worker ノードと Manager ノードを削除します。

Worker ノードの削除

ノードの切り離し

Worker ノードで docker swarm leave を実行すると、Worker ノードが Swarm から切り離されます。

$ docker swarm leave
Node left the swarm.

確認

Manager ノードで docker node ls を実行すると、Worker ノードの STATUS が Down になったのが確認できます。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
hqi4gtcdh4a7ya8myg0x0my37 worker1 Down Active 20.10.12
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

ノードの削除

次に Manager ノードで以下のコマンドを実行すれば、Manager ノードの管理上から Worker ノードが削除されます。

$ docker node rm <ノードID or ホスト名>

確認

docker node ls を実行すると、Worker ノードが削除されたのが確認できます。

$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
z9voajpw84i4jk2fomqwsmnc7 * manager1 Ready Active Leader 20.10.7

Manager ノードの削除

Manager ノードの削除でも docker swarm leave を実行しますが、そのまま実行すると以下のようなメッセージが出力されます。

$ docker swarm leave
Error response from daemon: You are attempting to leave the swarm on a node that is participating as a manager. Removing the last manager erases all current state of the swarm. Use `--force` to ignore this message.

Manager ノードを削除するとSwarm の現在の状態がすべて消去されるために警告が表示されていますが、--force を指定すれば削除できます。

$ docker swarm leave --force
Node left the swarm.

一応以下の公式ドキュメントを見ると、もう少し詳しく書いてあります。

https://matsuand.github.io/docs.docker.jp.onthefly/engine/reference/commandline/swarm_leave/

要約すると、Manager ノードが複数いる環境では、Manager ノードを Worker ノードに降格させてから削除するのが安全で、最後の Manager ノードの削除、つまり Manager ノード削除後にその Swarm をもう利用しない場合のみ --force をつけて削除しろ、という感じでしょうか。

Swarm が無効になったこを確認

docker info を実行すると、出力の中に Swarm: inactive となっているのが確認できるかと思います。

参考 URL

Portainer を docker-compose で動かす

Tue, 19 Apr 2022 00:00:00 +0900

Docker の GUI 管理ツールである Portainer を docker-compose で動かしてみました。

環境

Docker 20.10.7
portainer-ce 2.11

docker-compose.yml

Docker での動かし方は公式ドキュメントに記載されています。

https://docs.portainer.io/v/ce-2.11/start/install/server/docker/linux

これを docker-compose に落とし込んだのが以下です。

version: '3'
services:
 portainer:
 image: portainer/portainer-ce
 container_name: portainer
 restart: unless-stopped
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - portainer_data:/data
 ports:
 - 8000:8000
 - 9000:9000
 - 9443:9443
volumes:
 portainer_data:

通常 HTTPS で 9443 番ポートでアクセスしますが、HTTP でアクセスしたい場合は 9000 番ポートを使用します。
8000 番ポートは Edge コンピュート機能を使用する場合にのみ必要とありますが、使っていないので詳細はわかりません。それ以外には特筆すべき点はないかと思います。

これで http://localhost:9000 にアクセスすれば画面が表示されます。

Portainer Agent を追加する

以上で Portainer が使えるようになったのですが、Docker Volume の中が閲覧出来ませんでした。
これを有効化するには、Docker Swarm または Portainer Agent を追加する必要があるようです。

https://docs.portainer.io/user/docker/volumes/browse

Docker Swarm はまた別記事にするとして、ここでは Portainer Agent を追加します。
やり方については以下の記事が参考になりました。

https://stackoverflow.com/questions/64735377/install-portainer-portainer-agent-using-docker-compose

version: '3.2'
services:
 agent:
 image: portainer/agent
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 - /var/lib/docker/volumes:/var/lib/docker/volumes
 portainer:
 image: portainer/portainer-ce
 command: -H tcp://agent:9001 --tlsskipverify
 ports:
 - "9000:9000"
 volumes:
 - portainer_data:/data
volumes:
 portainer_data:

これで Docker Volume の中を閲覧できるようになりました。

Docker Swarm での動かし方は別記事に書きました。

https://kuttsun.blogspot.com/2022/05/portainer-docker-swarm.html

参考 URL

[Docker] Swarm モードで動作中のサービスについて調べる

Fri, 15 Apr 2022 00:00:00 +0900

Docker Swarm モードで動作中のサービスについて調べる方法です。
尚、Swarm の管理に関するコマンドは、manager ノード上でのみ実行可能です。

サービスの一覧を調べる

docker service ls で取得できます。

$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
sgwdtal1gqc7 helloworld replicated 1/1 alpine:latest

サービスの詳細を調べる

docker service inspect <サービスID or NAME> で調べられます。

しかし、このままだと出力が JSON 形式で見づらいので、--pretty を付けて見やすくしたほうが良いです。

$ docker service inspect helloworld --pretty

ID:		sgwdtal1gqc7j0ht0pgl6ehh6
Name:		helloworld
Service Mode:	Replicated
 Replicas:	1
Placement:
UpdateConfig:
 Parallelism:	1
 On failure:	pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Update order: stop-first
RollbackConfig:
 Parallelism:	1
 On failure:	pause
 Monitoring Period: 5s
 Max failure ratio: 0
 Rollback order: stop-first
ContainerSpec:
 Image:		alpine:latest@sha256:4edbd2beb5f78b1014028f4fbb99f3237d9561100b6881aabbf5acce2c4f9454
 Args:		ping 192.168.4.1 
 Init:		false
Resources:
Endpoint Mode:	vip

サービスがどのノードで動作しているか調べる

docker service ps <サービスID or NAME> で調べられます。

$ docker service ps helloworld 
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
aeg3t0tj1emt helloworld.1 alpine:latest manager1 Running Running about a minute ago

例えば、１つのサービスが２つのノード上で５タスク動作している場合は以下のような出力になります。

$ docker service ps helloworld 
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
aeg3t0tj1emt helloworld.1 alpine:latest manager1 Running Running 13 minutes ago 
rmf7xhyljero helloworld.2 alpine:latest worker1 Running Running 10 minutes ago 
yfezzc46q7ua helloworld.3 alpine:latest worker1 Running Running 10 minutes ago 
c3kc1qowfj72 helloworld.4 alpine:latest worker1 Running Running 10 minutes ago 
wudt0zzznt1d helloworld.5 alpine:latest manager1 Running Running 9 minutes ago

helloworld というサービスが５つ動作しており、それが２つのノードに均等に割り振られているのが確認できます。

参考 URL

http://docs.docker.jp/engine/swarm/swarm-tutorial/inspect-service.html

Ubuntu に GitLab-Runner を直接インストールする

Thu, 14 Apr 2022 00:00:00 +0900

docker で GitLab-Runner を動かしたことはありましたが、今回初めてホストに直接インストールしました。

公式ドキュメントは以下です。

https://docs.gitlab.com/runner/install/

インストール

apt でインストール

まずはリポジトリを追加します。

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

apt でインストールします。

$ sudo apt-get install gitlab-runner

しかし、この方法でインストールしたら結構古いバージョン (11.2.0) がインストールされてしまいました。
最新のバージョンは 14.9.1 のはずなんですが・・・。

今動かしている GitLab と互換性がなく上手く動かなったので、最終的には次に示すように deb パッケージからインストールしました。

deb パッケージからインストール

https://docs.gitlab.com/runner/install/linux-manually.html

ドキュメントだと curl を使うようになっていますが、上手くダウンロードできなかったのと、環境変数 arch が空だったので、以下のコマンドでダウンロードしました。

$ wget "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"

次のコマンドでインストールします。

$ dpkg -i gitlab-runner_amd64.deb

GitLab への登録

インストールが完了したら Gitlab-Runner を GitLab に登録します。

https://docs.gitlab.com/runner/register/index.html#linux

$ sudo gitlab-runner register

対話形式で入力していきます。

まず、GitLab の URL を指定します。

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.example

次にトークンを入力します。
トークンは GitLab に管理者でログインし、Menu > Admin > Runner で確認できます。

Please enter the gitlab-ci token for this runner:
U6YYzWyiQYzzfCdDH1dv

ランナーの詳細を入力します。

Please enter the gitlab-ci description for this runner:

ランナーを識別するためのタグを指定します。

Please enter the gitlab-ci tags for this runner (comma separated):

次はオプションなので何も入力せず進みました。

Enter optional maintenance note for the runner:

最後にスクリプトの実行方法を指定します。
今回はホスト上で直接実行させたかったので、shell を指定します。

Please enter the executor: virtualbox, docker+machine, docker, docker-ssh, parallels, kubernetes, shell, ssh, docker-ssh+machine:

GitLab の Menu > Admin > Runner で登録されたことが確認できます。

参考 URL

Docker イメージの保存先を変更

Fri, 08 Apr 2022 00:00:00 +0900

ストレージの容量が少ない場合など、新たに SSD を接続し、そちらに Docker イメージを保存する方法です。

以下のページが参考になりました。

https://github.com/atinfinity/lab/wiki/change_docker_image_directory

環境

Ubuntu 18.04

手順

Docker サービスの停止

$ sudo service docker stop

既存データの退避

既存のデータは /var/lib/docker にあるので、これを外部ストレージに移動します。
SSD は /mnt/ssd にマウントしており、そこに docker というディレクトリを作成してデータを移動します。

$ sudo mkdir /mnt/ssd/docker
$ sudo rsync -aXS /var/lib/docker/. /mnt/ssd/docker/

設定変更

/etc/docker/daemon.json を開きます。

$ sudo nano /etc/docker/daemon.json

以下を記述して、保存先を /mnt/ssd/docker に設定します．

{
 "graph": "/mnt/ssd/docker"
}

設定の反映

$ sudo systemctl daemon-reload
$ sudo service docker start

動作確認

$ docker info | grep "Docker Root Dir"
Docker Root Dir: /mnt/ssd/docker

古いデータを削除

/var/lib/docker を削除します。

$ sudo rm -rf /var/lib/docker

`error creating overlay mount to` というエラーが表示される

Docker コンテナを作成しようとした際に、error creating overlay mount to みたいなエラーが表示されました。
私の場合はファイルシステムが NTFS だったことが原因でした。
EXT4 でフォーマットすれば正常にできました。

参考 URL

https://github.com/atinfinity/lab/wiki/change_docker_image_directory

GitLab の root の初期パスワードを調べる

Thu, 07 Apr 2022 00:00:00 +0900

久しぶりに新規に GitLab を構築したら仕様が変わっていて困ったのでメモ。

以前は初回アクセス時にパスワード変更の画面が表示されていたと思うのですが、GitLab 14.9 では表示されませんでした。

環境

Docker で GitLab を動かしています。

gitlab-ce:14.9.2-ce

root の初期パスワードの確認

root でログインするための初期パスワードは /etc/gitlab/initial_root_password に記載されているそうです。

今回 Docker で GitLab を動かしているので、以下のようにコンテナに入ってから確認します。

$ docker exec -it gitlab bash
# cat /etc/gitlab/initial_root_password

gitlab はコンテナ名です。

root の初期パスワードの変更

初期パスワードは24時間経ったら削除されるとあるので、ログインできたらパスワードを変更しておきます。

右上のユーザーメニューから「Edit Profile」を選択
サイドメニューより「Password」を選択

参考 URL

https://qiita.com/masa2223/items/78aaf76329637e6ca12d

nvidia-docker2 (nvidia-container-toolkit) のインストール

Thu, 31 Mar 2022 00:00:00 +0900

Docker コンテナ内で GPU を使うためには NVIDIA Container Toolkit をインストールする必要があります。

公式ドキュメントは以下です。

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

インストール方法

上記のページにインストール手順も書いてあります。
（以下は見やすくするためにコマンドを分割しています。）

$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
$ curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add -
$ curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
$ sudo apt update
$ sudo apt install -y nvidia-docker2

nvidia-docker2 がトップレベルのパッケージらしいので、インストールするときは nvidia-container-toolkit ではなく nvidia-docker2 を指定するようです。
ここらへん以下のページが参考になりました。

https://qiita.com/tkusumi/items/f275f0737fb5b261a868

まぁ公式ドキュメントが nvidia-docker2 をインストールするようになっていますし、それに従えばよいかと。

また、古い記事では nvidia-docker と書いてあったりしますが、ここらへんの変遷は以下が参考になりました。

https://qiita.com/ksasaki/items/b20a785e1a0f610efa08

動作確認

nvidia-container-cli で確認できます。

$ nvidia-container-cli --version
cli-version: 1.8.1
lib-version: 1.8.1
build date: 2022-02-14T12:02+00:00
build revision: abd4e14d8cb923e2a70b7dcfee55fbc16bffa353
build compiler: x86_64-linux-gnu-gcc-7 7.5.0
build platform: x86_64
build flags: -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -DNDEBUG -std=gnu11 -O2 -g -fdata-sections -ffunction-sections -fplan9-extensions -fstack-protector -fno-strict-aliasing -fvisibility=hidden -Wall -Wextra -Wcast-align -Wpointer-arith -Wmissing-prototypes -Wnonnull -Wwrite-strings -Wlogical-op -Wformat=2 -Wmissing-format-attribute -Winit-self -Wshadow -Wstrict-prototypes -Wunreachable-code -Wconversion -Wsign-conversion -Wno-unknown-warning-option -Wno-format-extra-args -Wno-gnu-alignof-expression -Wl,-zrelro -Wl,-znow -Wl,-zdefs -Wl,--gc-sections

$ nvidia-container-cli info
NVRM version: 470.103.01
CUDA version: 11.4

Device Index: 0
Device Minor: 0
Model: NVIDIA GeForce RTX 3080
Brand: GeForce
GPU UUID: GPU-565ac97c-fe71-f49b-1ac0-7ac93c7dab8d
Bus Location: 00000000:01:00.0
Architecture: 8.6

参考 URL

docker イメージのファイル保存、読み込み

Tue, 29 Mar 2022 00:00:00 +0900

ネットに繋がらない環境で docker コンテナを動かすために docker イメージをファイルから読み込むことがあったので、そのメモです。

イメージをファイルに保存

$ docker save イメージ名:タグ > filename.tar

ファイルをロードしてイメージを作成

$ docker load -i filename.tar

または

$ docker load < filename.tar

イメージ名とタグ名はもとのものと同じで読み込まれました。

参考 URL

https://uxmilk.jp/55512

Windows PC から NAS に接続できなくなった

Sat, 19 Mar 2022 00:00:00 +0900

ちょっと古めの NAS を持っているのですが、Windows 10 の PC からアクセスできなくなりました。

以前はアクセスできていたはずなのですが、いつの間にかアクセスできなくなっていました。スマホからはアクセスできているので機器の故障ではなく、またネットワークに問題がないことも確認済みです。

んで、いろいろ調べていたのですが、どうやらその NAS には SMB1 のプロトコルでアクセスする必要があるみたいで、Windows 10 では機能を有効化しないといけないようです。

上述したように以前はアクセスできていたはずなんですけど・・・、Windows Update かなんかで設定が変わったんですかね？

[スタート]-[Windows システムツール]-[コントロールパネル] を開く
[プログラム]-[プログラムと機能] を開く
[Windows の機能の有効化または無効化] をクリック
「SMB 1.0/CIFS ファイル共有のサポート」の「SMB 1.0/CIFS クライアント」にチェックを入れて [OK] をクリック

1. [今すぐ再起動]をクリックする。

再起動後にアクセスできるようになりました。

参考 URL

WSL2 の Ubuntu で Docker を動かす

Thu, 20 Jan 2022 00:00:00 +0900

DockerDesktop が有償になったので、WSL2 の Ubuntu に Docker をインストールして動かすようにしてみました、

環境

Windows 10
Ubuntu 20.04

WSL2 および Ubuntu はインストール済みの前提です。
以下のページに書いてあるので、まだの場合は参考にしてください。

https://kuttsun.blogspot.com/2022/01/wsl2.html

プロキシ設定

環境に応じてプロキシの設定を行っておきます。

.bashrc をエディタで開き、最後に以下を追記します。

export http_proxy=http://example.com:8080
export https_proxy=http://example.com:8080
export no_proxy=任意のIPアドレス

apt のプロキシ設定

/etc/apt/apt.conf を作成して以下のように記述します。

Acquire::http::proxy "http://example.com:8080/";
Acquire::https::proxy "https://example.com:8080/";

再起動します。

$ exit

Docker のインストール

公式ドキュメントに沿ってインストールします。

$ sudo apt-get remove docker docker-engine docker.io containerd runc
$ sudo apt-get update
$ sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose

ユーザーを docker グループに追加

$ sudo gpasswd -a $(whoami) docker

これで docker コマンド実行時に sudo が不要になります。

docker のプロキシ設定

/etc/default/docker をエディタで開いて以下を追加します。

export http_proxy=http://example.com:8080
export https_proxy=http://example.com:8080

また、~/.docker/config.json に以下を記述します。

{
 "proxies": {
 "default": {
 "httpProxy": "http://example.com:8080",
 "httpsProxy": "http://example.com:8080"
 }
 }
}

再起動します。

$ exit

docker デーモンの起動

$ sudo service docker start

動作確認

$ docker info
$ docker run hello-world

すると、私の場合以下のエラーが表示されました。

docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.

docker デーモンが起動しているか確認します。

$ sudo service docker status
* Docker is not running

原因がわからず悩んでいたところ、以下の記事を見つけました。

https://qiita.com/neight0903/items/ef0e2170b712b194c3fc

私の場合、既に DockerDesktop はアンインストールしていました。
もともとは DockerDesktop と WSL2 を使って動かしていたのですが、今回 DockerDesktop なしで動くようにしようとしているところで、 DockerDesktop だけでなく WSL2 も一度アンインストールして最初からやり直すと上手く行きました。

docker デーモンの自動起動

このままでは WSL を起動する度に docker デーモンを手動で起動する必要がありますが、以下のページに自動起動させる方法があります。

まずは sudo service docker start をパスワードなしで実行できるように設定します。

$ sudo visudo

以下を追記します。

ユーザー名 ALL=(ALL:ALL) NOPASSWD: /usr/sbin/service docker start

あとは .bashrc に以下を追記します。

$ nano .bashrc

if [ $(service docker status | awk '{print $4}') = "not" ]; then
 sudo service docker start > /dev/null
fi

Windows と WSL2 のポートフォワーディングの設定

WSL2 上の Docker コンテナに外部からアクセスしたい場合、Windows と WSL2 のポートフォワーディングの設定が必要です。
詳細は以下の記事を参照してください。

https://kuttsun.blogspot.com/2022/07/wsl2-docker.html

参考 URL

Docker コンテナの内容を変更して、既存のイメージに上書きする

Thu, 13 Jan 2022 00:00:00 +0900

docker commit を行う際に忘れがちなのでメモです。

$ docker commit コンテナ名 使用中のイメージ名:タグ

例

$ docker commit hoge piyo:latest

hoge というコンテナを piyo:latest というイメージで保存します。
そのイメージが既に存在する場合は上書きされます。

参考 URL

https://qiita.com/mats16/items/712575dc50513dfdf0a2

GPU を複数積んでいるマシンで、GPU を指定して Docker コンテナを動かす

Wed, 12 Jan 2022 00:00:00 +0900

タイトルの通りです。docker run での指定方法と、docker-compose での指定方法です。

docker run での指定方法

以下のページが参考になりました。

https://cocoinit23.com/docker-run-multi-gpu/

全ての GPU を指定する場合は --gpus all を指定します。

特定の GPU を指定する場合は --gpus '"device=0"' のように指定します。

docker-compose での指定方法

--gpus all に相当する書き方は以下です。

deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]

--gpus '"device=0"' に相当する書き方は以下です。

deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
 device_ids: ['0']

詳細は公式のドキュメントに書いてあります。

https://docs.docker.com/compose/gpu-support/

docker-compose のアップデート

私の環境では docker-compose のバージョンは 1.25.0 でしたが、docker-compose で GPU を使えるようにするためには 1.28.0 以上でなければならないようなので、そのような場合にはアップデートが必要です。
docker-compose のアップデート方法については以下を参考にしてください。

https://kuttsun.blogspot.com/2022/09/docker-compose.html

参考 URL

Telegraf で Docker の情報を取得して Grafana で可視化する

Mon, 27 Dec 2021 00:00:00 +0900

サーバーリソースの可視化は以前やったので、今度は Docker の情報を可視化してみました。

Grafana のダッシュボードは以下を使いました。

https://grafana.com/grafana/dashboards/10585

これに書いてあることをやっただけですが・・・。

telegraf.conf の設定

以下を追加します。

[[inputs.docker]]
 endpoint = "unix:///var/run/docker.sock"
 
 gather_services = false

 container_name_include = []
 container_name_exclude = []

 timeout = "5s"

 docker_label_include = []
 docker_label_exclude = []

 perdevice = true

 total = false

docker-compose.yaml の設定

Telegraf の volume に /var/run/docker.sock を追加します。
また、/var/run/docker.sock にアクセスするためには Telegraf の実行ユーザーを Docker と同じにする必要があります。

https://www.influxdata.com/blog/docker-run-telegraf-as-non-root/

volumes:
 - /var/run/docker.sock:/var/run/docker.sock
users: 1000:133 # UID:GID

さらに、情報を習得したい全サービスに以下を追加してグループ化します。

labels:
 - "docker.group=<some_name>"

ラベルの名前は何でもいいようです。
ラベルを設定しなかったサービスの情報は取得されませんでした。

Grafana の設定

以下から JSON ファイルをダウンロードし、Grafana でインポートします。

https://grafana.com/grafana/dashboards/10585

以上で以下のようなダッシュボードが表示されます。

参考 URL

Telegraf で GPU の情報を取得し、Grafana で可視化する

Sun, 26 Dec 2021 00:00:00 +0900

Telegraf, InfluxDB, Grafana を使って GPU の情報を閲覧できるようにしました。

以前、Telegraf, InfluxDB, Grafana を使ってサーバーリソースの情報を閲覧できるようにしました。

https://kuttsun.blogspot.com/2021/12/telegraf-influxdb-garafana.html

これを前提としたうえで、今回 GPU の情報も見れるようにしました。

試したグラフィックボードは NVIDIA GeForce RTX 3080 です。
グラフィックドライバーのインストールなどは完了している前提です。

概要

Telegraf の nvidia_smi プラグインを使えば GPU の情報を取得できるようです。
nvidia_smi のプラグインについては以下に説明があります。

https://github.com/influxdata/telegraf/blob/master/plugins/inputs/nvidia_smi/README.md

上記の記事に書いてありますが、Docker で動作させている Telegraf で GPU の情報を取得するには、以下の２つの方法があるようです。

nvidia/cuda の Docker イメージをベースに Telegraf をインストールしたカスタムイメージを作成する
Volume のマウントバインディングを使用して nvidia-smi のバイナリを Docker コンテナに注入する

今回は後者でいきます。

Telegraf の設定

telegraf.conf に以下を追加しました。

[[inputs.nvidia_smi]]
 #bin_path = "/usr/bin/nvidia-smi"

inputs.nvidia_smi を追加するだけでプラグインが有効になるようです。
bin_path は nvidia-smi のある場所です。
以下のコマンドで調べられます。

$ which nvidia-smi
/usr/bin/nvidia-smi

Linux では通常 /usr/bin/nvidia-smi にあるそうで、その場合は指定しなくてもよいそうです。

docker-compose の設定

Telegraf を動作させている Docker コンテナから nvidia-smi と GPU にアクセスできるように設定します。
例えば、以下のような感じです。

version: '3.5'
services:
 telegraf:
 container_name: telegraf
 image: telegraf
 environment:
 - NVIDIA_VISIBLE_DEVICES=all
 - NVIDIA_DRIVER_CAPABILITIES=all
 deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
 volumes:
 - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
 - /usr/bin/nvidia-smi:/usr/bin/nvidia-smi:ro

ホストの /usr/bin/nvidia-smi をコンテナにマウントします。
Docker コンテナでの GPU の使用については以下の記事にも書いているので、参照してください。

https://kuttsun.blogspot.com/2021/11/docker-compose-gpu.html

Grafana の設定

Docker コンテナを起動したら、Grafana で以下のダッシュボードのテンプレートをインストールします。

https://grafana.com/grafana/dashboards/12225

これで閲覧できるようになると思ったのですが、Hostname に None しか表示されず、グラフに何も表示されない状態でした。
どうもこのテンプレートが Windows を前提としているようですので、ダッシュボードの設定をちょっと修正しました。

ダッシュボードの設定画面を開き Variables を選択します。
hostname の定義を以下のように変更します。

変更前

SHOW TAG VALUES FROM "win_system" WITH KEY = "host"

変更後

SHOW TAG VALUES FROM system WITH KEY=host

これで以下のようにグラフが表示されるようになりました。

他に CPU Usage と Memory Free のメーター表示も Windows 前提となっているようなので、必要なら修正してください。
私は CPU やメモリなどは他のダッシュボードで閲覧しており、ここでは GPU の情報だけで十分だったので、そこまで修正しませんでした。

参考 URL

[Python] Docker コンテナ内のアプリのログをホストの Syslog に追加する

Fri, 24 Dec 2021 00:00:00 +0900

docker コンテナ内で動作している python アプリのログをホストの syslog に追加します。

Ubuntu 20.04 で作業しましたが、rsyslog は最初からインストールされていました。

概要

Python 標準の logging モジュールに syslog 出力用のハンドラ SysLogHandler があるので、アプリ側ではそれを指定するだけで OK です。

Syslog はホストに対して UDP でログを送信して追加します。
理由は以下です。

docker コンテナ内でアプリを動かしているので、今後コンテナが増えたときコンテナごとに rsyslog を設定してやるのが面倒そう
各コンテナのログを一箇所に集約したい
syslog の記録には TCP or UDP のポート 514 が使用されるらしいが、SysLogHandler では UDP しか対応していないよう

rsyslog の設定変更

UDP のポート514 でログを待ち受けるように設定を変更します。

/etc/rsyslog.conf を編集します。

$ sudo gedit /etc/rsyslog.conf

以下の２行のコメントを外します。

module(load="imudp")
input(type="imudp" port="514")

変更後は再起動します。

$ sudo systemctl restart rsyslog

アプリ側の実装

ログに関する設定を logging.yaml に切り出しています。

https://kuttsun.blogspot.com/2021/12/python_21.html

その前提のうえで、以下のように指定するだけでログが UDP で送信されるようになります。

root:
 level: DEBUG
 handlers: [syslog]
handlers:
 syslog:
 class: logging.handlers.SysLogHandler
 formatter: syslog_format
 address: ['host.docker.internal', 514]
 #address: '/dev/log'
 level: INFO
formatters:
 syslog_format:
 format: 'appname: %(module)s %(message)s'

IPアドレスについては、docker コンテナからホストのIPアドレスを参照する必要があるので host.docker.internal を指定します。
（localhost はコンテナ自身を指すので使えない)
ちなみに host.docker.internal はもともと Windows と Mac でしか使えませんでしたが、最近 Linux でも使えるようになったそうです。

https://qiita.com/skobaken/items/03a8b9d0e443745862ac

これ使えなかったら直接IPアドレスを指定しないといけなくなり、ホストのIPアドレスが変わるたびに修正しないといけなくてマジ困ります。ってかこれを知るまでずっと困ってました。

参考 URL

rsyslog から Telegraf への送信に時々失敗する

Wed, 22 Dec 2021 00:00:00 +0900

rsyslog から Telegraf にログを TCP で転送するように設定してみましたが、Grafana で閲覧していると表示されないログがあり、送信に失敗しているようでした。

ググてみると以下のページを見つけました。

https://gist.github.com/froop/e3a1e7d14a8143f9951b85afff6b5469#file-rsyslog-bug4227-md

どうやら rsyslog の不具合のようで、バージョン 8.2010.0 で修正されているようです。
rsyslog のバージョンは以下で確認できます。

$ rsyslogd -v

私の環境 (Ubuntu 20.04) の rsyslog のバージョンは 8.2001.0 でした。なので、rsyslog をアップデートします。アップデート方法は以下に書いてありました。

https://www.rsyslog.com/ubuntu-repository/

$ sudo add-apt-repository ppa:adiscon/v8-stable
$ sudo apt-get update
$ sudo apt-get install rsyslog

現在の /etc/rsyslog.conf を最新のに差し替えるか残すかを聞かれますが、最新のに差し替えた後で再設定を行いました。再設定後は rsyslog を再起動します。尚、アップデート後のバージョンは 8.2021.0 でした。アップデート後は、ざっと見た感じきちんと転送されているように見えます。

参考 URL

Syslog を Telegraf に送り、Grafana で閲覧できるようにする

Mon, 20 Dec 2021 00:00:00 +0900

以下に Syslog 用のテンプレートと解説があるので簡単にできるかと思ったんですが、結構苦労しました・・・。

https://grafana.com/grafana/dashboards/12433

概要

ホストの Syslog から Telegraf にログを送り、Telegraf が InfluxDB に保存し、Grafana が InfluxDB から読み込んで可視化します。

Telegraf、InfluxDB、Grafana は全て docker-compose で動かしています。
これについては以下の記事で書いているので省略します。

https://kuttsun.blogspot.com/2021/12/telegraf-influxdb-garafana.html

上記記事からの変更点を以下に記述します。

rsyslog の設定

まずは Syslog から Telegraf にログを送信するように設定します。
/etc/rsyslog.conf を編集します。

$ sudo gedit /etc/rsyslog.conf

以下の設定を追加します。

$WorkDirectory /var/spool/rsyslog 
$ActionQueueType LinkedList 
$ActionQueueFileName srvrfwd 
$ActionResumeRetryCount -1 
$ActionQueueSaveOnShutdown on 
$ModLoad imudp #loads the udp module 
$UDPServerAddress localhost 
$UDPServerRun 514
*.* @@(o)127.0.0.1:6514;RSYSLOG_SyslogProtocol23Format

rsyslog を再起動します。

$ sudo systemctl restart rsyslog

Telegraf の設定

telegraf.conf に以下の設定を追加します。

[[inputs.syslog]]
 server = "tcp://0.0.0.0:6514"

Syslog から TCP ポート 6514 で受信するように設定していますが、docker で動かしているので localhost を指定すると上手く動作しません。
とりあえず 0.0.0.0 を指定しましたが、もしかしたら host.docker.internal とかでもいけるのかもしれません（未確認）。

docker-compose.yaml の変更

ポート 6514 を使用できるようにします。

services:
 telegraf:
 container_name: telegraf
 image: telegraf
 ports:
 - 6514:6514

docker コンテナを再起動します。

Grafana の設定

以下のページからダッシュボードの JSON ファイルをダウンロードしてインポートするだけです。

https://grafana.com/grafana/dashboards/12433

これで以下のようなダッシュボードが完成します。

参考 URL

Telegraf + InfluxDB + Garafana でサーバーリソースを可視化する

Sat, 18 Dec 2021 00:00:00 +0900

CPUやメモリなどのリソースを収集して閲覧したいなと思い、ググってみるとこの組み合わせが良さそうでした。
Telegraf でデータを取得して InfluxDB に書き込み、Grafana で InfluxDB のデータを読み込んで可視化します。

個人的に InfluxDB と Grafana は使ったことありますが、Telegraf は今回初めて使いました。

尚、この３つの頭文字を取って TIG Stack と呼んでいるページもいくつか見かけました。

環境

Ubuntu 20.04
Docker 20.10.7
Telegraf 1.20.4
InfluxDB 1.8.6
Grafana 7.5.7

Telegraf と Grafana は現時点の最新のバージョンですが、InfluxDB は 2.0 系ではなく 1.8.6 を使いました。
InfluxDB 2.0 を使ったことがないのと、参考にした Telegraf の設定ファイルのサンプルが InfluxDB 2.0 ではないものばかりだったからです。

また、Telegraf, InfluxDB, Grafana は全て Docker (docker-compose) を使って動かします。

docker-compose.yaml のサンプル

以下のような docker-compose.yaml を作成しました。

version: '3.1'
services:
 telegraf:
 container_name: telegraf
 image: telegraf
 restart: always
 volumes:
 - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
 depends_on:
 - influxdb
 links:
 - influxdb
 networks:
 - common
 influxdb:
 container_name: influxdb
 image: influxdb:1.8.6
 restart: always
 ports:
 - 8086:8086
 volumes:
 - influxdb:/var/lib/influxdb
 networks:
 - common
 grafana:
 container_name: grafana
 image: grafana/grafana
 restart: always
 links:
 - influxdb
 ports:
 - 3000:3000
 volumes:
 - grafana:/var/lib/grafana
 networks:
 - common
networks:
 common:
 external: true
volumes:
 influxdb:
 grafana:

common というネットワークを共通で使っているので、あらかじめ docker network create で作成しておく必要があります。

Telegraf の設定

telegraf.conf を作成します。

以下のページにちょうど良いのがあるのでこれをそのまま使いました。

https://grafana.com/grafana/dashboards/928

後述しますが、Grafana のダッシュボードのテンプレートもこれを使いました。
上記の設定をコピーしたら最低限以下の設定だけ変更します。

[agent] > hostname にマシン名を設定
- 設定しないと自動で設定されますが、起動の度に変わるので設定しておいたほうがよいと思います。
- 環境変数が使えるので、hostname = "$HOSTNAME" のようにも書けます。
[[outputs.influxdb]] > urls を InfluxDB の URL に変更
- 上記の docker-compose.yaml の場合、URL は http://influxdb.common:8086 のようにコンテナ名とネットワーク名を使っても指定できます。

他は必要に応じて設定します。

起動

$ docker-compose up

デーモン化したい場合は -d を指定します。
起動すると InfluxDB に Telegraf 用のデータベースを自動で作成してくれます。
（データベース名は telegraf.conf で設定できます。）

Grafana の設定

Grafana にアクセスし、ログインします。

http://localhost:3000

初期 ID とパスワードはどちらも admin です。

DB の登録

Configuration > Data Sources > Add data source > InfluxDB を選択します。

URL と Database の２つを設定します。
今回の例では以下のように設定します。

URL に http://influxdb.common:8086 を設定
Database に telegraf_metrics を設定

ダッシュボードの作成

Telegraf 用のテンプレートがあるので、それをインポートするのが楽です。
テンプレートは以下のページで探せます。

https://grafana.com/grafana/dashboards/

今回は以下のテンプレートを使いました。

https://grafana.com/grafana/dashboards/928

上記から JSON ファイルをダウンロードし、Grafana の左メニューの + ボタンからインポートします。
インポートの際、データベースは telegraf_metrics を選択します。

ダッシュボードにアクセスすると以下のような画面が表示されます。

かっこいい画面が簡単に作成できました。

リテンションポリシーの設定

telegraf.conf の [[outputs.influxdb]] > retention_policy でリテンションポリシーを指定できますが、ここが未指定だとデフォルトの autogen が使用され、データが無期限に保存されることになるので指定します。
例えば、リテンションポリシー名に hoge と指定します。

この状態で動作させると、hoge というリテンションポリシーが存在しないというエラーが出るので、InfluxDB のコンテナに入ってリテンションポリシーを作成します。

$ docker exec -it influxdb bash

コンテナに入ったら以下のコマンドでリテンションポリシーを作成します。

# influx
> CREATE RETENTION POLICY "リテンションポリシー名" ON "データベース名" DURATION "期間" REPLICATION 1 DEFAULT

例えば、今回は以下のように指定します。

CREATE RETENTION POLICY "hoge" ON "telegraf_metrics" DURATION 1h REPLICATION 1 DEFAULT

上記のコマンドではデータの保存期間を１時間に設定しています。

参考 URL

docker デーモンが勝手に再起動する原因の調査と対策

Fri, 17 Dec 2021 00:00:00 +0900

docker コンテナをずっと動作させていたのですが、次の日の朝に止まっていたことがありました。
その原因の調査と対策方法についてのメモです。

環境

Ubuntu 20.04
Docker 20.10.7

原因の調査

まずは docker のログを調べてみます。 syslog から docker に関するログを表示します。

$ grep 'dockerd' /var/log/syslog

Dec 17 07:02:17 hostname dockerd[1880]: time="2021-12-17T07:02:17.017091451+09:00" level=info msg="Processing signal 'terminated'" 

中略

Dec 17 07:02:27 hostname dockerd[1880]: time="2021-12-17T07:02:27.985252607+09:00" level=info msg="Daemon shutdown complete" 
Dec 17 07:02:27 hostname systemd[1]: docker.service: Succeeded.
Dec 17 07:02:28 hostname dockerd[327103]: time="2021-12-17T07:02:28.012481765+09:00" level=info msg="Starting up" 

中略

Dec 17 07:02:28 hostname dockerd[327297]: time="2021-12-17T07:02:28.618499702+09:00" level=info msg="Daemon has completed initialization" 
Dec 17 07:02:28 hostname dockerd[327297]: time="2021-12-17T07:02:28.627472728+09:00" level=info msg="API listen on /run/docker.sock"

docker としては、終了指示を受けたから停止して、その後正しく再起動しているようです。

じゃあ何で（誰が）終了したのかということで、今度はログ全部を表示して docker 再起動の少し前をログを見てみました。

$ cat /var/log/syslog

怪しいログとして以下がありました。

Dec 17 07:02:06 hostname systemd[1]: Starting Daily apt download activities...

中略

Dec 17 07:02:17 hostname systemd[1]: Stopping Docker Application Container Engine...

日次処理が走った後に docker を再起動している？
また、ググってみたら以下のページが見つかりました。

https://stackoverflow.com/questions/65090971/docker-daemon-unexpectedly-exits

というわけで、ソフトウェアの自動アップデートが走った結果 docker が再起動したのが原因のようです。
実際、ソフトウェアのアップデートの設定を確認したら、たしかに自動アップデートするようになっていました。
自動アップデートを無効にしてもいいですが、とりあえずこれはこのままにしておきました。

docker コンテナの restart フラグ

今までも docker コンテナをサービス化するときには restart フラグを設定していました。
restart については以下に記述があります。

https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/start-containers-automatically/#use-a-restart-policy

今回はエラーで Docker デーモンが再起動したわけではないので、今回のような場合でも Docker コンテナを再起動させるためには unless-stopped ではなく always を指定しないといけないっぽいですね。

ちなみに、GUI アプリで restart を unless-stopped or always に指定してサービス化した場合、 ×ボタンなどでアプリを終了してもすぐ再起動して GUI が立ち上がるようになるので、そこは注意が必要です。
まぁ GUI アプリをサービス化なんてしませんね。

参考 URL

Docker のディスク使用量を調べる

Thu, 02 Dec 2021 00:00:00 +0900

Docker イメージ、コンテナ、ボリュームのサイズを調べる方法です。

以下のコマンドでわかります。

$ docker system df

出力結果

TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 35 4 26.48GB 24.36GB (92%)
Containers 4 4 125.5MB 0B (0%)
Local Volumes 3 3 320.1MB 0B (0%)
Build Cache 0 0 0B 0B

より詳細に（個別に）知りたい場合は -v をつけます。

$ docker system df -v

参考 URL

https://stackoverflow.com/questions/57430694/is-there-a-way-to-determine-the-size-of-a-docker-volume-on-my-macos-machine

GitLab でリストア後に 500 エラーが表示される

Fri, 19 Nov 2021 00:00:00 +0900

GitLab でリストア自体は成功するのですが、特定のページにアクセスすると 500 エラーが表示されました。

原因は以下と同じでした。

https://kuttsun.blogspot.com/2020/01/gitlab-admin-runners-500.html

上記と同じ方法で解決もしました。

参考 URL

docker-compose でアプリの起動を遅らせる

Mon, 08 Nov 2021 00:00:00 +0900

docker-compose.yml の depends_on はあくまでコンテナの依存関係だけであり、アプリの起動や初期化までは待ってくれません。

現在の docker-compose には condition というのがあり、コンテナの状態をチェックして起動を制御することが可能なようです。

ただ、そのために healthcheck の方法を定義しないといけないなどちょっと面倒だったので、今回は sleep を入れて無理やり起動を遅らせる方法をとりました。

sleep の入れ方ですが、以下の２つの方法を思いつきました。

command で指定する例

docker-compose.yml の command で以下のように記述します。

command: bash -c "sleep 5 && python3 sample.py"

entrypoint で指定

docker-compose.yml の entrypoint で起動時に実行するスクリプトファイルを指定し、そのスクリプトファイルの中で sleep を実行します。

entrypoint: "/hoge/entrypoint.sh"

参考 URL

docker-compose で GPU を使う

Tue, 02 Nov 2021 00:00:00 +0900

docker run では --gpus all としていたのですが、docker-compose ではどう指定すればいいのかわからなかったので調べてみました。

基本的には以下に書かれている通りです。

https://docs.docker.com/compose/gpu-support/

docker-compose では例えば以下のように記述します。

deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]
environment: 
 - NVIDIA_VISIBLE_DEVICES=all
 - NVIDIA_DRIVER_CAPABILITIES=all

参考 URL

docker-compose での環境変数の参照方法

Fri, 29 Oct 2021 00:00:00 +0900

docker コンテナ内でホストと同じユーザーIDを指定するために、ホストの環境変数を参照していました。

例えば、docker コンテナ内でホストと同じユーザーIDを指定するために以下のように記述していましたが、

docker run -it \
 -e LOCAL_UID=$(id -u $USER) \
 -e LOCAL_GID=$(id -g $USER) \
 hoge:0 bash

これを docker-compose.yml ではどう書けばいいのか？結果的には以下のように記述することで上手くいきました。

environment: 
 - LOCAL_UID=${id:-u ${USER}}
 - LOCAL_GID=${id:-g ${USER}}

参考 URL

https://qiita.com/reflet/items/a96752b4cd3838ea6932

Rocket.Chat で使用している MongoDB をアップグレードする

Wed, 20 Oct 2021 00:00:00 +0900

Rocket.Chat をアップグレードしたら、MongoDB をアップグレードするように警告が表示されるようになったので、MongoDB もアップグレードしました。

アップグレードについては、以下の記事が参考になりました。

https://linuxhandbook.com/mongodb-upgrade-rocket-chat/

環境

アップグレード前

Rocket.Chat 3.10.4
MongoDB 4.0.22

アップグレード後

Rocket.Chat 4.0.3
MongoDB 5.0.3

やったこと

Rocket.Chat を 4.0.3 にアップグレード

3.10.4 から 4.0.3 へのアップグレードはバージョンを変更するだけでいけました。

docker コンテナ停止
docker-compose.yml の Rocket.Chat のバージョンを 4.0.3 に変更
docker コンテナ起動

この時点で Rocket.Chat 4.0.3、MongoDB 4.0.22 の組み合わせとなりましたが、以下のメッセージが表示されるようになりました。

rocketchat_1 | +----------------------------------------------+
rocketchat_1 | | SERVER RUNNING |
rocketchat_1 | +----------------------------------------------+
rocketchat_1 | | |
rocketchat_1 | | Rocket.Chat Version: 4.0.3 |
rocketchat_1 | | NodeJS Version: 12.22.1 - x64 |
rocketchat_1 | | MongoDB Version: 4.0.27 |
rocketchat_1 | | MongoDB Engine: wiredTiger |
rocketchat_1 | | Platform: linux |
rocketchat_1 | | Process Port: 3000 |
rocketchat_1 | | Site URL: http://localhost:3000 |
rocketchat_1 | | ReplicaSet OpLog: Enabled |
rocketchat_1 | | Commit Hash: 6e49fc9466 |
rocketchat_1 | | Commit Branch: HEAD |
rocketchat_1 | | |
rocketchat_1 | +----------------------------------------------+
rocketchat_1 | +----------------------------------------------------------------------+
rocketchat_1 | | DEPRECATION |
rocketchat_1 | +----------------------------------------------------------------------+
rocketchat_1 | | |
rocketchat_1 | | YOUR CURRENT MONGODB VERSION (4.0.22) IS DEPRECATED. |
rocketchat_1 | | IT WILL NOT BE SUPPORTED ON ROCKET.CHAT VERSION 5.0.0 AND GREATER, |
rocketchat_1 | | PLEASE UPGRADE MONGODB TO VERSION 4.2 OR GREATER |
rocketchat_1 | | |
rocketchat_1 | +----------------------------------------------------------------------+

MongoDB version 4.0.22 is deprecated, please upgrade your installation.

MongoDB 4.0 は非推奨なので、4.2 以上へアップグレードするよう促されます。
なので、ついでに最新の 5.0 までアップグレードします。

MongoDB を 4.2 にアップグレード

4.0 から 4.2 へのアップグレードは docker-compose.yml を修正して再起動するだけでいけました。

docker コンテナ停止
docker-compose.yml の MongoDB のバージョンを 4.0 に変更
docker コンテナ起動

MongoDB を 4.4 にアップグレード

4.2 から 4.4 へのアップグレードは docker-compose.yml を修正して再起動するだけではだめでした。
先に以下のコマンドを実行する必要があります。

$ docker exec mongo bash -c 'mongo --eval "db.adminCommand( { setFeatureCompatibilityVersion: \"4.2\" } )"'`

流れとしては以下です。

上記のコマンドを実行
docker コンテナ停止
docker-compose.yml の MongoDB のバージョンを 4.4 に変更
docker コンテナ起動

MongoDB を 5.0 にアップグレード

先ほどと同じです。
上記のコマンドのバージョンを 4.4 に変更して実行します

$ docker exec mongo bash -c 'mongo --eval "db.adminCommand( { setFeatureCompatibilityVersion: \"4.4\" } )"'`

流れとしては以下です。

上記のコマンドを実行
docker コンテナ停止
docker-compose.yml の MongoDB のバージョンを 5.0 に変更
docker コンテナ起動

参考 URL

https://linuxhandbook.com/mongodb-upgrade-rocket-chat/

Linux で USB メモリをマウントする

Wed, 16 Jun 2021 00:00:00 +0900

Ubuntu とかだと USB メモリを挿したら自動でマウントされるので何も意識しなくもいいのですが、いざ他の Linux で USB メモリを挿したときにマウントってどうやるんだっけ？となったのでメモしておきます。

環境

Wind River Linux

マウント方法

USB メモリを挿すと、/dev/sda とか /dev/sdb とかいうファイル名で認識されます。
これを /mnt/usb にマウントしてやります。

$ mkdir /mnt/usb
$ mount /dev/sdb /mnt/usb

アンマウント方法

$ umount /mnt/usb

Grafana のダッシュボードをログインなしで閲覧できるようにする

Fri, 11 Jun 2021 00:00:00 +0900

タイトルの通りです。

Grafana には一応 Snapshot という機能がありますが、日時の範囲が固定で、範囲を変えても範囲外のデータは閲覧できなかったりと、その名の通りあくまでスナップショットです。

なので、ログインしなくてもダッシュボードの閲覧だけは出来るように設定します。

環境

docker および docker-compose を使って構築しています。

Grafana v7.5.7

設定

設定方法は grafana.ini を編集するか、環境変数を設定するかのどちらかで行います。

今回は docker-compose.yml で環境変数を設定しました。

GF_AUTH_ANONYMOUS_ENABLED を true に設定すれば、ログインなしでもダッシュボードの閲覧ができるようになります。

以下、設定例です。

version: '3.1'
services:
 influxdb:
 container_name: influxdb
 image: influxdb:1.8.6
 ports:
 - "8086:8086"
 volumes:
 - influxdb:/var/lib/influxdb
 grafana:
 container_name: grafana
 image: grafana/grafana
 links:
 - influxdb
 ports:
 - "3000:3000"
 environment:
 - GF_AUTH_ANONYMOUS_ENABLED=true
 volumes:
 - grafana:/var/lib/grafana
volumes:
 influxdb:
 grafana:

尚、環境変数の一覧は Grafana の Server Admin > Settings で確認できます。

参考 URL

AWS CLI のインストールと認証情報の設定

Sat, 05 Jun 2021 00:00:00 +0900

Windows と Ubuntu で設定しました。

インストール

Windows

インストーラーをダウンロードしてインストールします。

https://awscli.amazonaws.com/AWSCLIV2.msi

Ubuntu 20.04

$ sudo apt install awscli

認証情報の設定

アクセスキーの作成

AWS にログインし、IAM を選択します。
メニューより ユーザー を選択し、認証情報 タブより アクセスキーの作成 をクリックします。

アクセスキーが作成されたら、ローカルで以下のコマンドを実行します。

$ aws configure
AWS Access Key ID [None]: <Access Key>
AWS Secret Access Key [None]: <Secret Access Key>
Default region name [None]: ap-northeast-1
Default output format [None]: json

インフラ・ミドルウェア on ポンコツ地方エンジニアの技術ブログ

Cloudflare Pages に Web Analytics を導入する

Cloudflare Web Analytics を導入する

Cloudflare Web Analytics にサイトを追加

OCI の Ubuntu インスタンスの初期設定

swap の設定

1. スワップファイルの作成

2. 適切な権限の設定

3. スワップ領域の初期化

4. スワップの有効化

5. 設定の確認

6. 再起動後も自動で有効化する設定

6-1. fstab のバックアップ（推奨）

6-2. 設定の追記

【おまけ】カーネルパラメータの最適化（推奨）

1. 現在の swappiness を確認

2. 一時的に 10 に変更

3. 永続的に反映

タイムゾーンの変更

nano のインストール

git のインストール

glab のインストールと認証

1. ダウンロード

2. GitLab でのアクセストークン（PAT）の発行

3. CLI の認証設定（ログイン）

tmux のインストール

docker のインストール

1. インストール

2. docker の権限を設定 (sudo を不要にする)

不要なサービスの停止

確実に停止・無効化して良いサービス

条件付きで停止・削除できるサービス（効果大）

snapd.service / snap.oracle-cloud-agent... （メモリ節約効果：大）

メモリ使用量の変化

OCI Bastion 経由でプライベート・サブネット内の Ubuntu インスタンスに SSH で接続

前提

Ubuntu でのインスタンス作成時のポイント

1. イメージに Ubuntu を選択する

2. ネットワーキング設定

Ubuntu での Bastion セッション作成

Bastion セッションの設定

鍵のパーミッション

SSH での接続方法

方法１

方法２

方法３

Ubuntu へのログイン後に確認すること

参考

OCI Bastion 経由でプライベート・サブネット内のインスタンスに SSH で接続

仕組みとメリット

環境

Step1: VCN とサブネットの作成

Step2: インスタンスの作成

Stes3: Bastion プラグインの有効化 (Oracle Linux の場合のみ)

Step4: Bastionの作成

Step5: セッションの作成

Step6: SSH接続の実行

SSH キーについての補足

① 同じ鍵を使った場合（一番シンプル）

② 別の鍵を使った場合（それぞれ指定が必要）

セキュリティ的な問題は？

1. 鍵が漏洩した際の影響範囲（爆発半径）が広がる

2. 「誰が・どこに」アクセスしたかの監査（ログ）が曖昧になる

参考

OCI (Oracle Cloud Infrastructure) で VM インスタンスを作成する

OCI (Oracle Cloud Infrastructure)

OCI のコンピュート環境：VM とコンテナインスタンスの違い

どちらを選ぶべきか？

OCI への登録

インスタンスの作成

基本情報

イメージ

シェイプ

セキュリティ

ネットワーキング

プライマリVNIC

パブリックIPv4アドレス割当て

SSHキーの追加

ストレージ

作成

2. 一時的に `10` に変更

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）

`NODE_VERSION` の明示