インフラ・ミドルウェア on heppoko blog

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,
 }]
 }
 };
 }
}