NetBox Docker構築：4.6のバージョン固定・セキュリティ・バックアップ・更新

EdwardMoon

NetBox Dockerの公式コミュニティプロジェクトを使うと、アプリケーション、worker、PostgreSQL、キャッシュをComposeで一貫して配布できます。ただし例をそのまま公開し、latest、admin/admin、ALLOWED_HOSTS=*を使うと、再現性と安全性が大きく損なわれます。

2026年7月時点のNetBox Docker 5.0.1とNetBox 4.6系を例にします。本番では検証済みのリポジトリtagとイメージを一緒に固定し、TLSリバースプロキシ、secret管理、PostgreSQLとメディアのバックアップ、復元試験、段階的更新を一連の手順にします。

構成要素とデータ境界

NetBox DockerはNetBox Community本体の公式インストーラーではなく、コミュニティ管理の別プロジェクトです。運用チームがDocker、Compose、PostgreSQL復旧、リリースノートを管理できる場合に選びます。

バージョン互換性と固定

5.0.1はNetBox 4.6.x以降との互換性を明記しています。リポジトリの支援ファイルとイメージのtagを合わせる必要があり、リポジトリだけ更新したり、イメージだけlatestにしたりしないでください。公式プロジェクトも、本番ではNetBox版と支援ファイル版を含むtagを推奨します。

ホストツールのバージョン

docker --version
docker compose version
git --version
openssl version

検証対象リリースを固定する

sudo install -d -o "$USER" -g "$USER" -m 0750 /opt/netbox
cd /opt/netbox
git clone --branch 5.0.1 --depth 1   https://github.com/netbox-community/netbox-docker.git netbox-docker-5.0.1
cd netbox-docker-5.0.1
git describe --tags --always
git status --short

導入時に公式リリースページでtagと対応範囲を再確認します。長期運用では検証したNetBoxパッチ版を含むtagまたはdigestへ固定し、変更管理に記録してください。

配布前の安全設計

• EOLのCentOS 7を新規本番の土台にしない。
• DBとキャッシュのポートをホストや外部へpublishしない。
• 最初は127.0.0.1だけへbindし、HTTPSプロキシで提供する。
• ALLOWED_HOSTSには実FQDNを指定し、ワイルドカードを使わない。
• 管理者を対話的に作成し、パスワードをComposeやGitへ置かない。
• DBとmediaを同じ時点へ戻せるバックアップ・復元runbookを先に作る。

配布ディレクトリの権限

cd /opt/netbox/netbox-docker-5.0.1
umask 077
cp docker-compose.override.yml.example docker-compose.override.yml
chmod 0600 docker-compose.override.yml
find env -type f -exec chmod 0600 {} \;

強固なsecretを生成する

サンプルのDB・キャッシュパスワードとSECRET_KEYは公開値です。初回起動前にenv/netbox.envのDB_PASSWORD、SECRET_KEY、API_TOKEN_PEPPER_1、REDIS_PASSWORD、REDIS_CACHE_PASSWORDを変更します。env/postgres.envのPOSTGRES_PASSWORDはDB_PASSWORDに、env/redis.envとenv/redis-cache.envのREDIS_PASSWORDはそれぞれキュー・キャッシュの値に合わせます。既存DB volumeのパスワードは環境ファイルだけでは変わらないため、別手順が必要です。

chmod 0700 env
${EDITOR:-vi} env/netbox.env env/postgres.env env/redis.env env/redis-cache.env

NetBox環境ファイルでは、実サービス名に合わせてALLOWED_HOSTS=netbox.example.internal localhost 127.0.0.1とSKIP_SUPERUSER=trueを設定します。管理者は後述の対話コマンドで作成します。

umask 077
openssl rand -base64 48
openssl rand -base64 32

# 出力値は承認済みの秘密情報保管庫またはCompose secretsファイルへ保存し、
# シェル履歴、Git、チケット本文には残しません。

変数名とsecrets対応方式は、そのリリースの資料で確認します。SECRET_KEY、PostgreSQL、キャッシュなど用途の異なる秘密情報を使い回さないでください。

Compose overrideと公開範囲

初期検証ではWebをloopbackだけへbindします。次は概念例なので、5.0.1のexampleファイルとマージ結果を比較して使ってください。DBとキャッシュへportsを追加しません。

services:
  netbox:
    ports:
      - "127.0.0.1:8000:8080"
    restart: unless-stopped

マージ結果とイメージを確認する

既定のNetBoxイメージは4.6系の移動可能なtagです。公式registryで正確なパッチと支援ファイルの組み合わせを確認し、プロジェクトの.envへVERSIONを指定します。これは各サービスのenv/*.envとは別のCompose置換用ファイルです。

# 公式registryで存在と互換性を確認したtagを入力します。
# 例：v4.6.<PATCH>-5.0.1形式です。<PATCH>をそのまま保存しないでください。
${EDITOR:-vi} .env
# .envの内容：VERSION=<確認したNetBoxパッチ・支援ファイルのtag>

docker compose config --images
docker compose pull

同じビット列で再配布するなら、pull後のdocker image inspectのRepoDigestsを記録し、各imageを検証済みimage@sha256:...へ固定します。リポジトリtagだけでは全イメージのdigestまでは固定されません。

docker compose config --quiet
docker compose config --images
docker compose config > /tmp/netbox-compose.rendered.yml

# 出力にlatest、0.0.0.0の公開ポート、DB・キャッシュのポートがないか確認
grep -nE 'latest|0\.0\.0\.0|5432:|6379:' /tmp/netbox-compose.rendered.yml

レンダリングしたComposeにはsecretが含まれる場合があります。確認ファイルを0600で作り、確認後に安全に削除し、CIログやissueへ添付しないでください。

イメージの取得と初回起動

先に取得してdigestを記録する

docker compose pull
docker compose images
docker image ls --digests | grep -E 'netbox|postgres|valkey'
docker compose config --images > deployed-images.txt
chmod 0600 deployed-images.txt

起動と状態確認

docker compose up -d
docker compose ps
docker compose logs --tail=200 netbox
docker compose logs --tail=100 netbox-worker
curl -fsS http://127.0.0.1:8000/ >/dev/null

runningだけで準備完了と判断しません。マイグレーション完了、DB接続、worker起動、HTTP応答、ログイン、代表的なAPI照会を確認します。

初期管理者とALLOWED_HOSTS

SUPERUSER_PASSWORD=adminのような値を環境ファイルに保存すると、inspect、バックアップ、Git履歴、ログから漏れる可能性があります。初回起動後に公式管理コマンドで対話的に作成し、一時的なSUPERUSER_*を使った場合は直ちに除きます。

docker compose exec netbox   /opt/netbox/netbox/manage.py createsuperuser

実FQDNを明示し、TLSプロキシのHostヘッダーと一致させます。公開前にHTTPS、信頼するproxyヘッダー、アクセス制御、セッションCookie方針、管理者MFA・SSOを検討してください。

PostgreSQLとmediaのバックアップ

正本はPostgreSQLですが、アップロードはmedia volumeです。DBだけでは画像・添付が欠け、volumeのスナップショットだけではDB整合性を保証しにくくなります。同じ変更時間帯に両方と設定・イメージ一覧をまとめて暗号化保存します。

PostgreSQLの論理バックアップ

BACKUP_DIR="/var/backups/netbox/$(date +%F-%H%M%S)"
sudo install -d -m 0700 "$BACKUP_DIR"
sudo chown "$USER":"$USER" "$BACKUP_DIR"

docker compose exec -T postgres   pg_dump -U netbox -d netbox -Fc   > "$BACKUP_DIR/netbox.pgdump"

docker compose exec -T postgres pg_restore --list < "$BACKUP_DIR/netbox.pgdump" | head

実volume名とマウント先

docker compose config --volumes
docker volume ls
docker inspect "$(docker compose ps -q netbox)"   --format '{{json .Mounts}}' | jq .

mediaはストレージドライバーに合うスナップショットか承認済みツールで保存します。ファイルコピーなら書き込み中の変更を制御し、権限、所有権、シンボリックリンクを保持してください。別ホストへ暗号化転送し、チェックサムを記録します。

完全性確認用ファイルを作る

cp docker-compose.override.yml "$BACKUP_DIR/"
cp deployed-images.txt "$BACKUP_DIR/"
# 秘密値を含む.envとenv/はアクセスを制限し、別途暗号化バックアップにも含めます。
(
  set -euo pipefail
  cd "$BACKUP_DIR"
  find . -type f ! -name SHA256SUMS -print0 | sort -z | xargs -0 sha256sum > SHA256SUMS
  sha256sum -c SHA256SUMS
)

終了コード0だけでは成功を証明できません。隔離したステージングComposeへDBとmediaを復元し、ログイン、オブジェクト数、添付、APIまで定期的に確認します。

安全なアップグレード

更新はgit pullとlatestへの交換ではありません。NetBox、NetBox Docker、PostgreSQL、Valkeyの対応と中間版の要件をリリースノートで確認します。特にNetBox Docker 4.0.0はアプリケーションサーバーをGranian、DBをPostgreSQL 18、キャッシュをValkey 9へ変更した大きな更新なので、古い環境から単純再起動で移行してはいけません。

1. 現リポジトリtag、digest、NetBox版、DB版を記録する。
2. DB、media、設定をバックアップし、隔離環境へ復元する。
3. 目標リリースと更新資料で対応経路を確認する。
4. 別ディレクトリに目標tagを準備し、ローカルoverrideだけを確認して移す。
5. Compose、イメージ、secret、ポートを検証し、ステージングでマイグレーションする。
6. 本番の変更時間帯に配布し、UI、API、worker、ログ、データを確認する。

現在の版とDBを記録する

git describe --tags --always
docker compose images
docker compose exec -T netbox   /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py version
docker compose exec -T postgres psql -U netbox -d netbox   -Atc 'select version();'

新リリースの変更前検証

docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --since=10m | grep -Ei 'error|traceback|failed'

スキーマ変更後、旧イメージだけへ戻すのは安全でない場合があります。公式の逆方向手順がない限り、変更前のDB、media、設定を一緒に復元します。

障害診断の順序

docker compose ps --all
docker compose logs --tail=300
docker compose config --images
docker compose exec -T netbox   /opt/netbox/netbox/manage.py check
docker stats --no-stream

運用チェックリスト

• リポジトリtagと全イメージ版・digestを記録して固定した。
• ALLOWED_HOSTSに実FQDNを指定し、DB・キャッシュを公開していない。
• 管理者パスワードとSECRET_KEYをGit、レンダリングファイル、ログの外で管理する。
• TLS、アクセス制御、時刻同期、定期セキュリティ更新を運用する。
• PostgreSQL、media、設定、イメージ一覧を同じ復旧セットにする。
• 隔離環境の復元とログイン、API、添付を定期検証する。
• 更新前にリリースノート、中間版、DB・Valkey・プラグイン対応を確認する。

公式資料と関連記事

• NetBox Docker公式コミュニティリポジトリ
• リリースと互換性情報
• 運用Wiki
• NetBox公式アップグレード
• Docker Engine公式インストール
• 閉域向けNetBox Podmanバンドル

まとめ

成功の基準は起動だけではなく、同じ版を再現し、データを復旧できることです。リポジトリとイメージを固定し、最小公開、secret分離、対話的管理者作成、TLS、DBとmediaの統合バックアップを整えます。更新は復元試験とリリースごとの互換性検証を通してから実施してください。