Container Deployment¶
pgAdminは、次のイメージを使用してコンテナにデプロイできます。
Dockerを使用している場合は、次のようなコマンドを使用して、必要なpgAdminのバージョンを取得するために選択できるさまざまなタグがあります。
docker pull dpage/pgadmin4:<tag name>
ここで、 <tagname> は次のいずれかです。
タグ名 |
説明 |
|---|---|
最新の |
最新のリリース。 |
6.14 |
特定のバージョン（この場合は6.14）。 |
6 |
特定のメジャーバージョン（この場合はメジャーバージョン6）の最新リリース。 |
スナップショット |
最新のナイトリーテストビルド。 |
PostgreSQLユーティリティ¶
PostgreSQLユーティリティ pg_dump 、 pg_dumpall 、 pg_restore および psql がコンテナに含まれており、バックアップの作成と復元、およびその他のメンテナンス機能を実行できます。さまざまなバージョンのデータベースサーバで使用できるように、複数のバージョンが次のディレクトリに含まれています。
PostgreSQL10： /usr/local/pgsql-10
PostgreSQL11： /usr/local/pgsql-11
PostgreSQL12： /usr/local/pgsql-12
PostgreSQL13： /usr/local/pgsql-13
PostgreSQL14： /usr/local/pgsql-14
コンテナに設定されているデフォルトのバイナリパスは次のとおりです。
DEFAULT_BINARY_PATHS = {
'pg-15': '/usr/local/pgsql-15',
'pg-14': '/usr/local/pgsql-14',
'pg-13': '/usr/local/pgsql-13',
'pg-12': '/usr/local/pgsql-12',
'pg-11': '/usr/local/pgsql-11',
'pg-10': '/usr/local/pgsql-10'
}
これは Preferences Dialog で変更される場合があります。
環境変数¶
コンテナは起動時に次の変数を受け入れます。
PGADMIN_DEFAULT_EMAIL
これは、pgAdminにログインするための初期管理者アカウントを設定するときに使用されるメールアドレスです。この変数は必須であり、起動時に設定する必要があります。
PGADMIN_DEFAULT_PASSWORD
これは、pgAdminにログインするための初期管理者アカウントを設定するときに使用されるパスワードです。この変数は必須であり、起動時に設定する必要があります。
PGADMIN_DEFAULT_PASSWORD_FILE
これは、pgAdminにログインするための初期管理者アカウントを設定するときに使用されるパスワードです。パスワードを設定するには、この値を dockersecret に設定する必要があります。この変数は、dockerswarm環境で、またはdockercomposeでコンテナを作成中にサポートされます。PGADMIN_DEFAULT_PASSWORDまたはPGADMIN_DEFAULT_PASSWORD_FILE変数は必須であり、起動時に設定する必要があります。
PGADMIN_DISABLE_POSTFIX
デフォルト：<null>
設定しない場合、Postfixサーバーが起動してパスワードリセットメールを配信します。
任意の値に設定されている場合、Postfixサーバーは起動されず、以下の PGADMIN_CONFIG_ オプションを使用して外部メールサーバーを使用するようにpgAdminを構成する必要があります。
このオプションは、sudoを使用してPostfixを起動できない環境で実行している場合、または外部のメールサーバーを使用したい場合に役立ちます。
PGADMIN_ENABLE_TLS
デフォルト：<null>
設定しない場合、コンテナはポート80でプレーンテキストの接続を監視します。任意の値に設定すると、コンテナはポート443でTLS接続を監視します。
TLSが有効になっている場合、証明書とキーを提供する必要があります。通常、これらはホストファイルシステムに保存し、コンテナからマウントする必要があります。予想されるパスは/certs/server.certおよび/certs/server.key
PGADMIN_LISTEN_ADDRESS
デフォルト：[::]
サーバーがリッスンするローカルアドレスを指定します。デフォルトはほとんどのユーザーにとって機能するはずです。IPv4のみの環境では、これを0.0.0.0に設定する必要がある場合があります。
PGADMIN_LISTEN_PORT
デフォルト：80または443（TLSが有効な場合）
サーバーがリッスンするポートをデフォルトを使用するのではなく特定の値に設定できるようにします。
PGADMIN_SERVER_JSON_FILE
デフォルト：/pgadmin4/servers.json
サーバー定義リストのデフォルトのファイルパスをオーバーライドします。詳細については、以下の/pgadmin4/servers.jsonマッピングされたファイルを参照してください。 JSON file のフォーマットを参照してください。
GUNICORN_ACCESS_LOGFILE
デフォルト：- （stdout）
Gunicornアクセスログをstdoutに送信する代わりに、出力ファイルを指定します。
GUNICORN_LIMIT_REQUEST_LINE
デフォルト：8190
HTTPリクエスト行の最大サイズをバイト単位で設定します。デフォルトでは、一部の要求は非常に大きくなる可能性があるため、pgAdminコンテナはGunicornが提供する最大制限サイズを使用します。例外的に、この値を0（ゼロ）に設定して「無制限」を指定できますが、これによりサービス拒否の危険が発生します。
GUNICORN_THREADS
デフォルト：25
Gunicornサーバーが着信要求を処理するために使用するスレッドの数を調整します。これは、増加する可能性のある高負荷のシステムを除き、通常はそのままにしておく必要があります。
PGADMIN_CONFIG_ *
これは、pgAdminの config.py ファイルの構成オプションをオーバーライドするために使用できる変数プレフィックスです。 config.py の変数名に PGADMIN_CONFIG_ プレフィックスを追加し、文字列の場合は「文字列値」、ブール値の場合はTrue/False、数値の場合は123の形式で値を指定します。例については、以下を参照してください。
設定は、コンテナ内の /pgadmin4/config_distro.py に書き込まれ、 /pgadmin4/config.py の後、 /pgadmin4/config_local.py の前に読み取られます。したがって、指定された設定はconfig.pyのすべてをオーバーライドしますが、config_local.pyの設定でオーバーライドできます。
設定は、通常、コンテナの最初の起動時に1回のみ /pgadmin4/config_distro.py に書き込まれます。 /pgadmin4/config_distro.py に1つ以上の行が含まれている場合、変更は行われません。たとえば、コンテナインスタンスが再起動された場合、または /pgadmin4/config_distro.py が永続ストレージ上のファイルにマップされている場合（非推奨-代わりに /pgadmin4/config_local.py を使用してください）！
使用可能な構成設定の詳細については、 The config.py File を参照してください。
マップされたファイルとディレクトリ¶
次のファイルまたはディレクトリをコンテナからホストマシンにマッピングして、構成をカスタマイズしてインスタンス間で共有できます。
警告
警告：pgAdminは、コンテナの pgadmin グループ（GID：5050）の pgadmin ユーザー（UID：5050）として実行されます。すべてのファイルがホストマシンでこのユーザーに対して読み取り可能であり、必要な場合（作業/セッションディレクトリなど）に書き込み可能であることを確認する必要があります。例：
sudo chown -R 5050:5050 <host_directory>
拡張属性をサポートしていない一部のファイルシステムでは、 PGADMIN_LISTEN_PORT に1024より大きい値を指定せずにpgAdminを実行できない場合があります。そのような場合、環境変数を追加してコンテナを起動するときに代替ポートを指定し、例：
-e 'PGADMIN_LISTEN_PORT=5050'
それに応じてホストコンテナポートマッピングを調整することを忘れないでください。
/var/lib/pgadmin
これは、pgAdminがセッションデータ、ユーザファイル、構成ファイル、および構成データベースを保存する作業ディレクトリです。このディレクトリをホストマシンにマッピングすると、コンテナの呼び出し間で構成を簡単に維持できます。
/pgadmin4/config_local.py
このファイルを使用して、pgAdminの構成設定をオーバーライドできます。config.pyにある設定は、必要に応じて展開固有の値でオーバーライドできます。config_local.pyの設定は、 PGADMIN_CONFIG_ プレフィックス付き変数を介してコンテナ環境で指定されたものもオーバーライドします。
/pgadmin4/servers.json
このファイルがマップされている場合、その中にあるサーバー定義が起動時にロードされます。これにより、接続情報をコンテナ内のpgAdminのインスタンスにプリロードできます。サーバー定義は、最初の起動、つまり構成データベースの作成時にのみロードされ、同じ構成データベースを使用した後続の起動ではロードされないことに注意してください。
/certs/server.cert
TLSが有効になっている場合、このファイルはサーバーのTLS証明書として使用されます。
/certs/server.key
TLSが有効になっている場合、このファイルはサーバーのTLS証明書のキーファイルとして使用されます。
例¶
ポート80で単純なコンテナーを実行します。
docker pull dpage/pgadmin4
docker run -p 80:80 \
-e 'PGADMIN_DEFAULT_EMAIL=user@domain.com' \
-e 'PGADMIN_DEFAULT_PASSWORD=SuperSecret' \
-d dpage/pgadmin4
いくつかの構成オプションを設定して、ポート80で単純なコンテナーを実行します。
docker pull dpage/pgadmin4
docker run -p 80:80 \
-e 'PGADMIN_DEFAULT_EMAIL=user@domain.com' \
-e 'PGADMIN_DEFAULT_PASSWORD=SuperSecret' \
-e 'PGADMIN_CONFIG_ENHANCED_COOKIE_PROTECTION=True' \
-e 'PGADMIN_CONFIG_LOGIN_BANNER="Authorised users only!"' \
-e 'PGADMIN_CONFIG_CONSOLE_LOG_LEVEL=10' \
-d dpage/pgadmin4
ホスト上の/private/var/lib/pgadmin、およびホスト上の/tmp/servers.jsonからプリロードされたサーバーを使用して、TLSで保護されたコンテナを実行します。
docker pull dpage/pgadmin4
docker run -p 443:443 \
-v /private/var/lib/pgadmin:/var/lib/pgadmin \
-v /path/to/certificate.cert:/certs/server.cert \
-v /path/to/certificate.key:/certs/server.key \
-v /tmp/servers.json:/pgadmin4/servers.json \
-e 'PGADMIN_DEFAULT_EMAIL=user@domain.com' \
-e 'PGADMIN_DEFAULT_PASSWORD=SuperSecret' \
-e 'PGADMIN_ENABLE_TLS=True' \
-d dpage/pgadmin4
リバースプロキシ¶
場合によっては、ユーザーが実行されているコンテナに直接ではなく、リバースプロキシを介してpgAdminに接続することが望ましいです。次の例は、これを実現する方法を示しています。 Nginx などの従来のリバースプロキシサーバーでは、pgAdminは同じホスト上のコンテナで実行されており、ホストのポート5050はコンテナのポート80にマッピングされています。
docker pull dpage/pgadmin4
docker run -p 5050:80 \
-e "PGADMIN_DEFAULT_EMAIL=user@domain.com" \
-e "PGADMIN_DEFAULT_PASSWORD=SuperSecret" \
-d dpage/pgadmin4
pgAdminX-Forwarded-*構成¶
pgAdminは、どの値を信頼するかを知るために、各ヘッダーを設定するプロキシの数を理解する必要があります。この目的に使用されるX-Forwarded-*オプションの構成パラメーターをデフォルト値とともに示します。
pgAdminは、非標準ポートでもリバースプロキシの背後で実行できるように構成されており、通常、これらの構成オプションを変更する必要はありません。通常とは異なる構成（複数のリバースプロキシなど）を実行している場合は、適合するように構成を調整できます。
# Number of values to trust for X-Forwarded-For
PROXY_X_FOR_COUNT = 1
# Number of values to trust for X-Forwarded-Proto.
PROXY_X_PROTO_COUNT = 0
# Number of values to trust for X-Forwarded-Host.
PROXY_X_HOST_COUNT = 0
# Number of values to trust for X-Forwarded-Port.
PROXY_X_PORT_COUNT = 1
# Number of values to trust for X-Forwarded-Prefix.
PROXY_X_PREFIX_COUNT = 0
Nginxを介したHTTP¶
次のような構成を使用して、 Nginx ですべてのホスト名をリッスンする単純なHTTPリバースプロキシを作成できます。
server {
listen 80;
server_name _;
location / {
proxy_set_header Host $host;
proxy_pass http://localhost:5050/;
proxy_redirect off;
}
}
サーバーのルートではなくサブディレクトリの下でpgAdminをホストする場合は、場所を指定し、パスを書き換える方法をpgAdminコンテナに指示する X-Script-Name ヘッダーを設定する必要があります。
server {
listen 80;
server_name _;
location /pgadmin4/ {
proxy_set_header X-Script-Name /pgadmin4;
proxy_set_header Host $host;
proxy_pass http://localhost:5050/;
proxy_redirect off;
}
}
Nginxもコンテナで実行されている場合、2つのコンテナが同じDockerネットワークで実行されている限り、pgAdminポートをホストにマッピングする必要はありません。このような構成では、 proxy_pass オプションは、Dockerネットワーク内のpgAdminコンテナを指すように変更されます。
Nginxを介したHTTPS¶
次の構成を使用して、バックエンドコンテナがプロキシサーバーにプレーンHTTPを提供しているときに、HTTPSを介してpgAdminをユーザーに提供できます。この構成では、 X-Script-Name を設定するだけでなく、 X-Scheme も設定して、正しいスキームを使用してURLを生成するようにpgAdminサーバーに指示します。HTTPからHTTPSへのリダイレクトも含まれています。証明書とキーのパスは、特定の展開に合わせて調整する必要がある場合があります。
server {
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443;
server_name _;
ssl_certificate /etc/nginx/server.cert;
ssl_certificate_key /etc/nginx/server.key;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
location /pgadmin4/ {
proxy_set_header X-Script-Name /pgadmin4;
proxy_set_header X-Scheme $scheme;
proxy_set_header Host $host;
proxy_pass http://localhost:5050/;
proxy_redirect off;
}
}
トラフィク¶
Traefik の構成は、ローカルマシンで実行されているコンテナからコンテンツを提供するように自動的に構成され、 <container_name>.<domain_name> でそれらをホストするため、HTTPまたはHTTPSのいずれかで簡単ドメイン名は、Traefik構成で指定されたものです。コンテナは通常、以下の例に従って起動されます。
docker pull dpage/pgadmin4
docker run --name "pgadmin4" \
-e "PGADMIN_DEFAULT_EMAIL=user@domain.com" \
-e "PGADMIN_DEFAULT_PASSWORD=SuperSecret" \
-d dpage/pgadmin4
Nginxの例のようにTCP/IPポートはホストにマップされておらず、コンテナ名はホスト名として使用され、DNSに追加する必要があるため、既知の値に設定されていることに注意してくださいゾーンファイル。
次の構成は、Traefikに同梱されているデフォルトの証明書を使用して、ポート80と443でリッスンし、80を443にリダイレクトします。LetsEncryptまたは他の発行者からの証明書を使用するオプションについては、Traefikのドキュメントを参照してください。
defaultEntryPoints = ["http", "https"]
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
[docker]
domain = "domain_name"
watch = true
Traefikを使用してサブディレクトリでpgAdminをホストする場合、構成の変更は通常、Traefik自分自身ではなくコンテナの起動方法に対して行われます。たとえば、ルートディレクトリではなく /pgadmin4/ でpgAdminをホストするには、Traefikのバージョンv1の使用中にコンテナが次のように起動された場合、上記のTraefik構成を使用できます。
docker pull dpage/pgadmin4
docker run --name "pgadmin4" \
-e "PGADMIN_DEFAULT_EMAIL=user@domain.com" \
-e "PGADMIN_DEFAULT_PASSWORD=SuperSecret" \
-e "SCRIPT_NAME=/pgadmin4" \
-l "traefik.frontend.rule=PathPrefix:/pgadmin4" \
-d dpage/pgadmin4
SCRIPT_NAME 環境変数は、サブディレクトリでホストされていることをコンテナに通知するように設定されており（ X-Script-Name ヘッダーがNginxで使用されるのと同じ方法で）、Traefikに伝えるラベルが追加されましたサブディレクトリの下のリクエストをこのコンテナにルーティングします。
サブディレクトリの下でpgAdminをホストするためにバージョンv2のTraefik構成を使用している場合、コンテナは通常、以下の例に従って起動されます。
docker pull dpage/pgadmin4
docker run --name "pgadmin4" \
-e "PGADMIN_DEFAULT_EMAIL=user@domain.com" \
-e "PGADMIN_DEFAULT_PASSWORD=SuperSecret" \
-e "SCRIPT_NAME=/pgadmin4" \
-l "traefik.frontend.pgadmin4.rule=Host(`host.example.com`) && PathPrefix(`/pgadmin4`)" \
-d dpage/pgadmin4
