DockerユーザーのためのPostgreSQL公式イメージ徹底解説

By /

DockerユーザーのためのPostgreSQL公式イメージ徹底解説

はじめに

今日のソフトウェア開発において、データベースはアプリケーションにとって不可欠な要素です。そして、データベースの中でもPostgreSQLは、その堅牢性、拡張性、そして豊富な機能を誇り、多くの開発者や企業に選ばれています。一方、アプリケーションの配布と実行環境の管理において、Dockerはデファクトスタンダードとなりつつあります。

Dockerを利用することで、アプリケーションとその依存関係をコンテナという軽量で移植性の高いパッケージにまとめることができます。これにより、「私の環境では動くのに！」といった問題を解消し、開発、テスト、本番環境間での一貫性を保つことが容易になります。

では、PostgreSQLをDocker環境で利用するにはどうすれば良いでしょうか？最も推奨される方法は、Docker Hubで公式に提供されているPostgreSQLイメージを利用することです。公式イメージは、PostgreSQL開発チーム自身やコミュニティによってメンテナンスされており、高い信頼性、セキュリティ、そして使いやすさを兼ね備えています。

しかし、Dockerユーザーの中には、単にdocker run postgresと実行する以上のことを知りたいと思っている方も多いでしょう。データ永続化、初期設定のカスタマイズ、パフォーマンスチューニング、セキュリティ設定など、本番環境や複雑な開発ワークフローでPostgreSQLを効果的に利用するためには、公式イメージが提供する様々な機能や設定オプションを深く理解することが不可欠です。

本記事では、Dockerユーザー向けに、PostgreSQL公式イメージを徹底的に解説します。基本的な使い方から始まり、環境変数による設定、データ永続化の方法、初期化スクリプトの活用、設定ファイルのカスタマイズ、そしてDocker Composeでの利用方法まで、PostgreSQL公式イメージを使いこなすために必要な知識を網羅します。さらに、バージョン管理、レプリケーション、セキュリティといった高度なトピックや、運用上のベストプラクティスとよくある落とし穴についても触れます。

この記事を読むことで、あなたはPostgreSQL公式イメージを自信を持って利用できるようになり、Docker環境でのデータベース運用スキルを向上させることができるでしょう。さあ、PostgreSQL公式イメージの世界へ深く潜り込んでいきましょう。

Dockerとは？ 簡単な復習

PostgreSQL公式イメージの解説に入る前に、まずはDockerの基本的な概念をおさらいしておきましょう。すでにDockerに慣れている方は、このセクションをスキップしても構いません。

Dockerは、アプリケーションをコンテナと呼ばれる隔離された環境で実行するためのプラットフォームです。コンテナ技術自体は以前から存在しましたが、Dockerはそれをより簡単に、そして広く利用できるようにしました。

コンテナ技術の概要

コンテナは、アプリケーション、そのライブラリ、フレームワーク、設定ファイルなど、実行に必要なすべてのものを一つのパッケージにまとめたものです。このパッケージはホストOSのカーネルを共有しますが、独自のファイルシステム、プロセス空間、ネットワークインターフェースを持ち、他のコンテナやホストシステムから隔離されています。仮想マシンと比較すると、OS全体をエミュレートする必要がないため、コンテナはより軽量で起動が速いという特徴があります。

Dockerのメリット

Dockerを利用する主なメリットは以下の通りです。

  • 可搬性 (Portability): コンテナは、どのDockerがインストールされている環境でも同じように実行できます。これにより、「開発環境では動くのに本番環境では動かない」といった問題を最小限に抑えることができます。
  • 再現性 (Reproducibility): 特定のDockerfileやDockerイメージから作成されたコンテナは、常に同じ環境を提供します。これにより、ビルドプロセスやデプロイメントが非常に予測可能になります。
  • 隔離性 (Isolation): 各コンテナは互いに隔離されています。これにより、あるコンテナで発生した問題が他のコンテナやホストシステムに影響を与えるリスクを減らすことができます。また、セキュリティの向上にもつながります。
  • 効率性 (Efficiency): コンテナは仮想マシンよりもリソース消費が少なく、起動が速いため、開発やテストのサイクルを高速化できます。
  • デプロイメントの容易さ: コンテナ化されたアプリケーションは、Dockerが動作する様々な環境（クラウド、オンプレミス、ローカルPCなど）に簡単にデプロイできます。

Dockerイメージとコンテナの関係

Dockerにおいて、イメージはコンテナを作成するための設計図、あるいはテンプレートのようなものです。イメージは複数の読み取り専用レイヤーで構成されており、アプリケーションとその依存関係、OSのファイルシステムの一部などが含まれます。一度イメージを作成すれば、何度でもそれからコンテナを作成できます。

一方、コンテナは、イメージを実行したインスタンスです。イメージは読み取り専用ですが、コンテナは起動時に読み書き可能なレイヤーが追加され、その中でアプリケーションが実行されます。コンテナの状態は、コンテナが停止または削除されると失われるのが基本です。

PostgreSQL公式イメージは、Docker Hubで公開されているイメージの一つであり、これを基にコンテナを起動してPostgreSQLサーバーとして利用します。

PostgreSQL公式イメージの概要

Docker Hubで提供されているPostgreSQL公式イメージは、Docker環境でPostgreSQLサーバーを実行するための標準的かつ最も信頼できる方法です。

なぜ公式イメージを使うべきか？

PostgreSQL公式イメージを利用することには、多くのメリットがあります。

  • 信頼性: 公式イメージは、PostgreSQL開発チームや活発なコミュニティによってメンテナンスされています。これにより、イメージが安定しており、PostgreSQLの動作が保証されます。
  • セキュリティ: セキュリティパッチが迅速に適用され、既知の脆弱性への対策が施されています。公式イメージは定期的にビルドされ、ベースOSイメージのセキュリティアップデートも取り込まれます。
  • メンテナンス: Dockerfileが公開されており、イメージがどのように構築されているか透明性があります。また、使い方のドキュメントが充実しています。
  • 標準化: 公式イメージは、DockerのエコシステムにおけるPostgreSQLの標準的な利用方法を提供します。これにより、他のツールやサービスとの連携が容易になります。
  • 利便性: 多くの設定が環境変数を通じて行えるようになっており、コンテナ起動時のカスタマイズが容易です。

独自にDockerfileを作成してPostgreSQLイメージをビルドすることも可能ですが、公式イメージを利用する方が、メンテナンスの手間やセキュリティリスクを大幅に削減できます。

イメージ名とタグ

Docker Hub上のPostgreSQL公式イメージは、postgresという名前で公開されています。このイメージを使う際には、バージョンを指定するための「タグ」を付けて指定するのが一般的です。タグを指定しない場合は、デフォルトでlatestタグが使われますが、これは本番環境などでの利用には推奨されません（理由は後述）。

主要なタグのパターンは以下の通りです。

  • メジャーバージョン: postgres:15, postgres:14, postgres:13 など。特定のPostgreSQLメジャーバージョンを指定します。このタグは、そのメジャーバージョンの最新のパッチバージョンに更新されます。例えば、postgres:15はPostgreSQL 15.0, 15.1, 15.2… と更新されるにつれて、最新の15.xバージョンを指すようになります。
  • メジャー.マイナーバージョン: postgres:15.3, postgres:14.7 など。特定のPostgreSQLのマイナーバージョンを指定します。通常、このタグは一度リリースされると変更されません。再現性を重視する場合に適しています。
  • メジャーバージョン (alpine): postgres:15-alpine, postgres:14-alpine など。Alpine LinuxをベースOSとして使用した軽量なイメージです。イメージサイズが小さく、セキュリティ面で有利な場合がありますが、含まれるライブラリが少ないため、特定のツールが必要な場合は注意が必要です。
  • latest: postgres:latest または単に postgres。常にその時点で利用可能な最新バージョンのPostgreSQLを指します。PostgreSQLのメジャーバージョンアップを含むため、非互換性が生じる可能性があり、本番環境での利用は避けるべきです。開発や簡単な試用には便利です。

利用目的に応じて、適切なタグを選択することが重要です。本番環境やチームでの開発では、特定のメジャーバージョン、あるいはメジャー.マイナーバージョンタグを使用し、意図しないアップグレードを防ぐことが推奨されます。

Docker Hubでの公式イメージの探し方

Docker Hub (hub.docker.com) にアクセスし、「postgres」と検索すると、公式イメージが表示されます。公式イメージには「Docker Official Image」というマークが付いています。イメージページでは、利用可能なタグの一覧や、イメージのビルド方法、使い方のドキュメント（通常はGitHubリポジトリのREADMEへのリンク）を参照できます。これらのドキュメントは、公式イメージを深く理解する上で非常に役立ちます。

基本的な使い方

それでは、実際にPostgreSQL公式イメージを使ったコンテナの起動方法を見ていきましょう。

イメージのプル

まず、ローカルのDocker環境にPostgreSQLイメージをダウンロード（プル）します。

bash
docker pull postgres:15

このコマンドは、PostgreSQL 15の最新パッチバージョンのイメージをDocker Hubからダウンロードします。特定のマイナーバージョンが必要な場合は、docker pull postgres:15.3のように指定します。latestタグを使いたい場合は、タグを省略してdocker pull postgresとすることも可能ですが、推奨しません。

プルが完了したら、docker imagesコマンドでローカルにあるイメージを確認できます。

bash
docker images

コンテナの実行（簡単な例）

ダウンロードしたイメージを使って、コンテナを起動します。PostgreSQLコンテナを実行する際には、いくつかの重要な設定が必要です。最も重要なのは、スーパーユーザー（通常はpostgresユーザー）のパスワード設定です。これは、環境変数POSTGRES_PASSWORDで行います。この環境変数を設定しないと、コンテナは起動に失敗します。

bash
docker run \
--name some-postgres \
-e POSTGRES_PASSWORD=mysecretpassword \
-d \
postgres:15

このコマンドを解説します。

  • docker run: 新しいコンテナを作成して実行するコマンドです。
  • --name some-postgres: コンテナにsome-postgresという名前を付けます。名前を付けると、コンテナIDの代わりに名前で操作できるようになり便利です。
  • -e POSTGRES_PASSWORD=mysecretpassword: コンテナ内の環境変数POSTGRES_PASSWORDにmysecretpasswordという値を設定します。これがPostgreSQLのスーパーユーザーのパスワードとなります。
  • -d: コンテナをデタッチドモード（バックグラウンド）で実行します。これを付けないと、コンテナの標準出力が現在のターミナルに表示され続け、ターミナルがブロックされます。
  • postgres:15: 使用するDockerイメージの名前とタグです。

コンテナが正常に起動すると、コンテナIDが表示されます。docker psコマンドで実行中のコンテナ一覧を確認できます。

bash
docker ps

some-postgresという名前のコンテナが表示されていれば成功です。StatusがUp ...となっていれば実行中です。

コンテナへの接続（psqlクライアント）

コンテナ内で実行されているPostgreSQLサーバーに接続するには、様々な方法があります。最も簡単なのは、コンテナ内でPostgreSQLのコマンドラインクライアントであるpsqlを実行する方法です。

bash
docker exec -it some-postgres psql -U postgres

  • docker exec: 実行中のコンテナ内でコマンドを実行するためのコマンドです。
  • -it: 擬似端末 (pseudo-TTY) を割り当て、標準入出力を対話的に使用できるようにします。psqlのように対話的に操作する際に必要です。
  • some-postgres: コマンドを実行したいコンテナの名前です。
  • psql -U postgres: コンテナ内で実行するコマンドです。psqlクライアントを起動し、-U postgresでユーザー名としてpostgresを指定しています。

このコマンドを実行すると、パスワードの入力を求められます。docker runコマンドで設定したmysecretpasswordを入力してください。

“`
Password for user postgres:
psql (15.3 (Debian 15.3-1.pgdg120+1))
Type “help” for help.

postgres=#
“`

postgres=#というプロンプトが表示されれば、PostgreSQLサーバーへの接続に成功です。ここでSQLコマンドを実行できます。終了するには\qと入力します。

ローカルPCにpsqlクライアントがインストールされている場合は、コンテナのポートをホストに公開（ポートマッピング）して、ホストから接続することも一般的です。デフォルトではPostgreSQLは5432ポートを使用します。

bash
docker run \
--name some-postgres-with-port \
-e POSTGRES_PASSWORD=mysecretpassword \
-p 5432:5432 \
-d \
postgres:15

-p 5432:5432: ホストの5432ポートを、コンテナの5432ポートにマッピングします。これでホストからlocalhost:5432でコンテナ内のPostgreSQLにアクセスできます。

ホストから接続する際のコマンド例（パスワード入力を求められます）：

bash
psql -h localhost -U postgres -p 5432

コンテナの停止と削除

コンテナを使い終わったら、停止して削除することができます。

“`bash

コンテナの停止

docker stop some-postgres

コンテナの削除

docker rm some-postgres
“`

停止したコンテナはdocker ps -aで確認できます。削除すると完全にコンテナインスタンスがなくなります。

注意: 上記の基本的な使い方では、データベースのデータはコンテナのファイルシステム内に保存されます。コンテナを削除すると、データも一緒に失われます！ 開発やテスト目的で一時的に利用する場合以外は、データ永続化の設定が必須です。これについては次のセクションで詳しく解説します。

PostgreSQL公式イメージのカスタマイズ

PostgreSQL公式イメージは、デフォルト設定のままでも利用できますが、より実用的に使うためには様々なカスタマイズが必要です。公式イメージは、そのカスタマイズを容易にするために、豊富な環境変数、データ永続化のためのメカニズム、そして初期化スクリプトの実行機能を提供しています。

環境変数による設定

PostgreSQL公式イメージは、コンテナ起動時に特定の環境変数を読み取り、PostgreSQLサーバーの初期設定や動作を調整します。これにより、Dockerfileをカスタマイズすることなく、docker runコマンドやDocker Composeファイルで手軽に設定を変更できます。

主要な環境変数とその役割を以下に示します。

  • POSTGRES_PASSWORD (必須):

    • PostgreSQLのスーパーユーザー（デフォルトではpostgresユーザー）のパスワードを設定します。
    • この環境変数を設定しないと、コンテナは初期化に失敗し起動できません。
    • セキュリティ上の理由から、コマンドラインで直接指定するのではなく、.envファイルやDocker Secretsのようなより安全な方法で管理することが強く推奨されます。
    • 例: -e POSTGRES_PASSWORD=your_strong_password

  • POSTGRES_USER:

    • スーパーユーザーとして使用するユーザー名を指定します。デフォルトはpostgresです。
    • POSTGRES_DBで指定したデータベースのオーナーにもなります（POSTGRES_DBが指定されている場合）。
    • 例: -e POSTGRES_USER=myuser

  • POSTGRES_DB:

    • コンテナの初回起動時に自動的に作成されるデータベース名を指定します。デフォルトはPOSTGRES_USERで指定したユーザー名と同じ名前のデータベースです（POSTGRES_USERが指定されていない場合はpostgres）。
    • この環境変数を設定すると、指定した名前のデータベースが作成され、POSTGRES_USERで指定したユーザーがそのオーナーとなります。
    • 例: -e POSTGRES_DB=mydatabase

  • POSTGRES_INITDB_ARGS:

    • PostgreSQLのデータベースクラスター初期化コマンドであるinitdbに追加の引数を渡すために使用します。
    • 文字セットやロケールの設定など、initdbの高度なオプションを指定したい場合に利用します。
    • 例: -e POSTGRES_INITDB_ARGS="--encoding=UTF-8 --locale=en_US.UTF-8"

  • POSTGRES_INITDB_WALDIR:

    • Write-Ahead Log (WAL) のディレクトリをデフォルトのPGDATAディレクトリ内ではなく、別の場所に指定します。
    • これは、例えば高速なストレージにWALを配置したい場合などに便利です。指定されたディレクトリはコンテナ起動時に自動的に作成されます。
    • 例: -e POSTGRES_INITDB_WALDIR=/var/lib/postgresql/wal (この場合、/var/lib/postgresql/walをボリューム等で永続化する必要がある)

  • PGDATA:

    • データベースクラスターのデータディレクトリの場所を指定します。
    • デフォルトは/var/lib/postgresql/dataです。
    • このパスは、データ永続化のためにボリュームなどをマウントする際に非常に重要です。通常、明示的に変更する必要はありませんが、他の場所に変更したい場合に利用します。
    • 例: -e PGDATA=/var/lib/postgresql/mydata (この場合、/var/lib/postgresql/mydataをボリューム等で永続化する必要がある)

  • PGOPTIONS, PGCLIENTENCODING, PGHOST, PGPORT, PGDATABASE, PGUSER, PGPASSWORD:

    • これらはPostgreSQLクライアントやサーバーの標準的な環境変数です。コンテナ内のpsqlなどのクライアントコマンドや、場合によってはサーバーの挙動に影響を与えます。
    • 例えば、PGOPTIONSを使って、サーバー起動時の追加オプションを指定できます。
    • 例: -e PGOPTIONS="-c fsync=off" (テスト目的などでfsyncを無効にする場合。本番環境では危険なので避ける)

これらの環境変数を組み合わせることで、コンテナの初回起動時にデータベースユーザー、データベース、パスワード、エンコーディングなどを柔軟に設定できます。

環境変数の設定方法:

  1. docker runコマンドの-eオプション: 上記の例のように、コマンドラインで直接指定します。シンプルですが、パスワードなどの機密情報がコマンド履歴に残る可能性があるため注意が必要です。
  2. .envファイル: 環境変数を定義したファイルを-env-fileオプションで指定します。機密情報をコマンド履歴に残さない点で優れていますが、ファイル自体へのアクセス権限管理が必要です。
    bash
    # .env ファイルの内容例
    POSTGRES_PASSWORD=your_strong_password
    POSTGRES_USER=myuser
    POSTGRES_DB=mydatabase
    bash
    # コンテナ実行コマンド
    docker run \
    --name some-postgres \
    --env-file .env \
    -d \
    postgres:15
  3. Docker Secrets: 本番環境など、より高いセキュリティが求められる場合は、Docker Secretsを利用するのが最も安全です。これはDocker SwarmやKubernetesのようなオーケストレーションツールで利用可能な機能です。

データ永続化

前述のように、デフォルトではコンテナ内のデータはコンテナのライフサイクルと同期しており、コンテナが削除されるとデータも失われます。データベースのデータは通常、永続的に保存する必要があります。PostgreSQL公式イメージでは、Dockerのボリュームまたはバインドマウントを使用してデータを永続化します。

PostgreSQLのデータディレクトリは、デフォルトではコンテナ内の/var/lib/postgresql/dataにあります。このディレクトリをホスト上の永続的な場所にマウントすることで、コンテナが削除されてもデータが保持されるようになります。

なぜデータ永続化が必要か？

  • データの保持: コンテナの停止、再起動、削除に関わらず、データベースのデータを安全に保存するため。
  • コンテナのアップグレード/交換: データベースのデータを保持したまま、PostgreSQLコンテナのバージョンをアップグレードしたり、別の新しいコンテナに置き換えたりするため。
  • 設定の永続化: postgresql.confなどの設定ファイルをカスタマイズし、それをコンテナの再起動後も維持するため（これはデータディレクトリとは別に設定ファイル自体をバインドマウントする方法もありますが、データディレクトリ内に設定を置くことも可能です）。

データ永続化の方法:

  1. ボリューム (docker volume) の使用 (推奨):

    • Dockerによって管理される専用のストレージ領域です。ホストOS上の特定のディレクトリに保存されますが、その場所を意識する必要はありません。
    • docker volume createコマンドでボリュームを作成できます。
    • コンテナ実行時に-v <ボリューム名>:<コンテナ内のパス>の形式でマウントします。

    • 例:
      “`bash
      # ボリュームを作成（初めて使う場合）
      docker volume create postgres_data

      コンテナを実行し、作成したボリュームをデータディレクトリにマウント

      docker run \
      –name some-postgres \
      -e POSTGRES_PASSWORD=mysecretpassword \
      -v postgres_data:/var/lib/postgresql/data \
      -d \
      postgres:15
      ``
      * **利点**:
      * Docker CLIやAPIで簡単に管理できる。
      * Linux上では、ボリュームのパーミッションはDockerによって適切に管理されるため、パーミッションの問題が起きにくい。
      * リモートホストやクラウドプロバイダーによっては、ボリュームプラグインを使ってネットワークストレージなどを利用できる。
      * コンテナのライフサイクルから独立して存在する。
      * **欠点**:
      * ボリュームの中身をホストOSから直接簡単に確認・編集しにくい（      docker volume inspect,docker run –rm -v <ボリューム名>:/data alpine ls /data`などのコマンドを使う必要あり）。

  2. バインドマウントの使用:

    • ホストOS上の特定のディレクトリやファイルを、コンテナ内のパスに直接マウントします。
    • コンテナ実行時に-v <ホストのパス>:<コンテナ内のパス>の形式でマウントします。

    • 例:
      “`bash
      # ホスト上のカレントディレクトリに ‘pgdata’ ディレクトリを作成
      mkdir pgdata

      コンテナを実行し、ホストの ‘./pgdata’ ディレクトリをデータディレクトリにバインドマウント

      docker run \
      –name some-postgres \
      -e POSTGRES_PASSWORD=mysecretpassword \
      -v ./pgdata:/var/lib/postgresql/data \
      -d \
      postgres:15
      ``
      * **利点**:
      * ホスト上のファイルシステムに直接アクセスできるため、データの確認や編集が容易。
      * 開発時などに、ホスト上のコードや設定ファイルをコンテナにマウントするのに便利。
      * **欠点**:
      * **パーミッションの問題に注意が必要**。ホスト側のマウント元のディレクトリの所有者/グループやパーミッションが、コンテナ内の      postgres`ユーザー（デフォルトUID/GID: 999）が書き込めるように設定されている必要がある。これは特にWindowsやmacOSで問題になることがある。
      * ホストOSに強く依存する（パスの指定など）。
      * ボリュームに比べて管理機能が少ない。

どちらを使うべきか？

一般的には、PostgreSQLのデータディレクトリの永続化にはボリュームを使用することが推奨されます。特にLinuxホスト上で実行する場合、パーミッションの問題をDockerが適切に処理してくれるため、最も手間がかからず安全です。バインドマウントは、開発中にホスト上の特定のディレクトリをコンテナから参照したい場合や、設定ファイルをホスト側で管理したい場合などに適しています。

初期化スクリプト

PostgreSQLコンテナの初回起動時、つまりデータディレクトリ(/var/lib/postgresql/data)が空の場合に限り、公式イメージは特定の場所にあるスクリプトを自動的に実行します。この機能を利用することで、コンテナ起動時にデータベースの初期設定（スキーマ作成、ユーザー作成、初期データの投入など）を自動化できます。

スクリプトが配置される場所は、コンテナ内の/docker-entrypoint-initdb.d/ディレクトリです。このディレクトリ内のスクリプトは、ファイル名の辞書順に実行されます。

サポートされるファイルの種類は以下の通りです。

  • .sql: 標準的なSQLスクリプトです。psqlコマンドによって実行されます。
  • .sql.gz: Gzipで圧縮されたSQLスクリプトです。解凍してから実行されます。
  • .sh: 標準的なシェルスクリプトです。/bin/shによって実行されます。

初期化スクリプトの利用方法:

最も一般的な利用方法は、カスタムのDockerfileを作成し、COPY命令を使ってこれらのスクリプトを/docker-entrypoint-initdb.d/ディレクトリに配置することです。

例: スキーマ作成と初期データ投入

  1. init.sql という名前で以下のファイルを作成します。
    “`sql
    — init.sql
    CREATE TABLE my_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL
    );

    INSERT INTO my_table (name) VALUES (‘Initial Data 1’), (‘Initial Data 2’);

    CREATE USER myappuser WITH PASSWORD ‘mypassword’;
    GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myappuser; — mydatabase は POSTGRES_DB で指定
    GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO myappuser;
    GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO myappuser;
    “`

  2. 同じディレクトリに Dockerfile を作成します。
    “`dockerfile
    FROM postgres:15

    COPY init.sql /docker-entrypoint-initdb.d/
    “`

  3. このDockerfileを使ってカスタムイメージをビルドします。
    bash
    docker build -t my-postgres-image .

  4. ビルドしたカスタムイメージを使ってコンテナを実行します。この際、初めてコンテナを起動し、データディレクトリが空である必要があります。
    bash
    docker run \
    --name some-postgres \
    -e POSTGRES_PASSWORD=mysecretpassword \
    -e POSTGRES_DB=mydatabase \
    -v postgres_data:/var/lib/postgresql/data \
    -d \
    my-postgres-image

このコンテナが初めて起動されると、init.sqlスクリプトが実行され、my_tableテーブルが作成されデータが投入され、myappuserユーザーが作成されます。データディレクトリが既に存在する場合は、初期化スクリプトはスキップされます。

シェルスクリプト(.sh)を利用すると、SQLスクリプトの実行前に必要なファイルを用意したり、外部サービスと連携したりといったより複雑な初期化処理を行うことができます。

初期化スクリプトは、データベース環境のセットアップを自動化する非常に強力な機能であり、特に開発環境の構築やテストの自動化において威力を発揮します。

設定ファイルのカスタマイズ

PostgreSQLの詳細な設定は、主にpostgresql.confファイルで行います。公式イメージでは、この設定ファイルをカスタマイズするための推奨される方法がいくつかあります。

直接コンテナ内のpostgresql.confファイルを編集することは、コンテナの再起動や再作成によって変更が失われるため推奨されません。データを永続化していても、設定ファイルはデータディレクトリの外にあることが多いからです。

設定ファイルをカスタマイズする推奨方法:

  1. /etc/postgresql/postgresql.conf.d/ ディレクトリへの追加設定ファイル配置 (推奨):

    • PostgreSQLは、postgresql.confファイル内で他の設定ファイルをインクルードする機能を持っています。公式イメージは、この機能を利用して/etc/postgresql/postgresql.conf.d/ディレクトリ内のすべての.confファイルを自動的にインクルードするように設定されています。
    • したがって、カスタマイズしたい設定は、このディレクトリ内に新しい.confファイル（例: custom.conf）を作成し、その中に記述するのが最もクリーンな方法です。
    • 例: custom.conf ファイルを作成
      conf
      # custom.conf
      listen_addresses = '*' # 全てのネットワークインターフェースからの接続を許可 (注意: セキュリティリスクあり)
      max_connections = 200 # 最大接続数を増やす
      shared_buffers = 512MB # 共有バッファサイズを設定
    • Dockerでの利用方法:
      • カスタムのDockerfileでファイルをコピーする:
        dockerfile
        FROM postgres:15
        COPY custom.conf /etc/postgresql/postgresql.conf.d/
        このDockerfileでビルドしたイメージを実行します。

      • バインドマウントでファイルを提供する方法:
        “`bash
        # ホスト上の custom.conf ファイルを作成
        echo “listen_addresses = ‘*'” > custom.conf

        コンテナを実行し、custom.conf をマウント

        docker run \
        –name some-postgres \
        -e POSTGRES_PASSWORD=mysecretpassword \
        -v postgres_data:/var/lib/postgresql/data \
        -v ./custom.conf:/etc/postgresql/postgresql.conf.d/custom.conf \
        -d \
        postgres:15
        “`
        バインドマウントの場合、ホスト側のファイルへの変更がコンテナに即座に反映されますが、PostgreSQLサーバーがその変更を読み込むには通常リロードや再起動が必要です。

  2. バインドマウントによる postgresql.conf ファイル自体の置き換え:

    • 非推奨ですが、ホスト上のpostgresql.confファイルをコンテナ内の/etc/postgresql/postgresql.confにバインドマウントすることで、設定全体を制御する方法です。
    • 注意: この方法は、公式イメージが提供するデフォルトのpostgresql.confファイルを完全に上書きします。公式イメージは、起動時の環境変数や初期化スクリプトの実行を制御するために、このデフォルト設定に依存している部分があります（例: include_dir = 'conf.d'の設定など）。そのため、公式イメージのアップデートによって予期せぬ問題が発生する可能性があります。
    • 特別な理由がない限り、/etc/postgresql/postgresql.conf.d/ ディレクトリへの追加設定ファイルの配置を強く推奨します。

pg_hba.conf のカスタマイズ:

pg_hba.confファイルは、クライアント認証と接続許可を制御する非常に重要なファイルです。デフォルトでは、公式イメージは最も基本的な設定（postgresユーザーがローカルソケットやホストからの認証なし/md5認証で接続可能など）を持っています。

pg_hba.confも/etc/postgresql/ディレクトリにありますが、postgresql.confのようにインクルードディレクトリはありません。pg_hba.confをカスタマイズしたい場合は、以下のいずれかの方法をとる必要があります。

  1. カスタムDockerfileでファイルを置き換える:
    dockerfile
    FROM postgres:15
    COPY pg_hba.conf /etc/postgresql/pg_hba.conf
    ホスト上に独自のpg_hba.confファイルを用意し、それをコンテナにコピーします。この方法では、公式イメージのデフォルト設定を完全に置き換えるため、注意が必要です。元の公式イメージのpg_hba.confをベースに、必要な変更を加えたファイルを作成する必要があります。

  2. バインドマウントでファイルを置き換える:
    “`bash
    # ホスト上の pg_hba.conf ファイルを作成
    # 例: 全てのホストからの接続を md5 認証で許可 (注意: セキュリティリスクあり)
    echo “host all all 0.0.0.0/0 md5” > pg_hba.conf

    コンテナを実行し、pg_hba.conf をマウント

    docker run \
    –name some-postgres \
    -e POSTGRES_PASSWORD=mysecretpassword \
    -v postgres_data:/var/lib/postgresql/data \
    -v ./pg_hba.conf:/etc/postgresql/pg_hba.conf \
    -d \
    postgres:15
    “`
    この方法も、公式イメージのデフォルト設定を完全に置き換える点に注意が必要です。

セキュリティ上の観点から、pg_hba.confのカスタマイズは非常に重要です。デフォルト設定では、セキュリティが十分でない場合があります（例: ホストからの認証なし接続など）。必要な接続元IPアドレスや認証方式のみを許可するように設定してください。

Docker Composeでの利用

複数のコンテナ（例えば、Webアプリケーションとデータベース）を連携させて動かす場合、docker runコマンドを複数実行するのは管理が煩雑です。Docker Composeは、複数のコンテナで構成されるアプリケーションを定義し、一元的に管理するためのツールです。docker-compose.ymlというYAMLファイルにサービス（コンテナ）の設定を記述します。

PostgreSQL公式イメージは、Docker Composeと組み合わせて利用されることが非常に多いです。

docker-compose.yml の基本的な構造:

“`yaml
version: ‘3.8’ # Composeファイルのバージョン

services: # サービス（コンテナ）を定義
db: # データベースサービスの名前
image: postgres:15 # 使用するイメージ
ports:
– “5432:5432” # ホストポート:コンテナポートのマッピング
volumes:
– postgres_data:/var/lib/postgresql/data # ボリュームマウント
environment: # 環境変数
POSTGRES_PASSWORD: mysecretpassword
POSTGRES_USER: myuser
POSTGRES_DB: mydatabase
restart: unless-stopped # コンテナが停止した場合の再起動ポリシー
healthcheck: # ヘルスチェックの設定
test: [ “CMD-SHELL”, “pg_isready -U postgres” ]
interval: 10s
timeout: 5s
retries: 5
start_period: 10s

app: # アプリケーションサービスの名前
build: . # Dockerfileがあるディレクトリを指定 (ビルドする場合)
# または image: my-app-image # 既存のイメージを使用する場合
ports:
– “8000:8000”
environment:
DATABASE_URL: postgres://myuser:mysecretpassword@db:5432/mydatabase # データベース接続文字列
depends_on: # dbサービスに依存
db:
condition: service_healthy # dbサービスがhealthcheckに成功するまで待つ

volumes: # ボリュームを定義
postgres_data:
“`

この例では、dbという名前のサービスとしてPostgreSQLコンテナを定義しています。

  • image: postgres:15: PostgreSQL公式イメージのバージョン15を使用します。
  • ports: - "5432:5432": ホストの5432ポートをコンテナの5432ポートにマッピングします。
  • volumes: - postgres_data:/var/lib/postgresql/data: postgres_dataという名前のボリュームをコンテナのデータディレクトリにマウントします。
  • environment: 環境変数を設定します。POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DBを設定しています。
  • restart: unless-stopped: コンテナが予期せず停止した場合に自動的に再起動する設定です。
  • healthcheck: コンテナが正常に動作しているかを確認するためのヘルスチェックを設定します。ここではpg_isreadyコマンドを使用しています。これは他のサービス（例: appサービス）がデータベースに接続する準備ができているかを判断するのに役立ちます。
  • volumes: postgres_data:: 使用するボリュームを定義します。Docker Composeによって自動的に作成・管理されます。

appサービスは、depends_on: dbを指定することで、dbサービスが起動し、さらにcondition: service_healthyによってヘルスチェックに成功するまで待機します。データベース接続文字列DATABASE_URLでは、ホスト名としてサービスの名前であるdbを指定できるのがポイントです。Docker Composeはサービス名解決のための内部DNSを提供します。

このdocker-compose.ymlファイルがあるディレクトリで以下のコマンドを実行すると、dbサービスとappサービスを含むアプリケーション全体を起動できます。

bash
docker compose up -d # または docker-compose up -d (v1の場合)

コンテナを停止・削除するには：

bash
docker compose down # または docker-compose down

Docker Composeを使うことで、複数のコンテナを一括で管理できるようになり、開発環境の構築やテストが非常に効率的になります。データ永続化、環境変数、ポートマッピングといった設定もYAMLファイルに記述できるため、構成が分かりやすく、チーム内での共有も容易です。

初期化スクリプトや設定ファイルのカスタマイズも、Docker Composeファイルの中でボリュームマウントやDockerfileのビルド (build: .) を組み合わせて実現できます。

高度なトピック

PostgreSQL公式イメージは、基本的な使い方やカスタマイズ機能に加え、より高度なユースケースにも対応するための基盤を提供しています。

バージョン管理とアップグレード

Dockerイメージのタグは、PostgreSQLのバージョンと密接に関連しています。新しいバージョンのPostgreSQLがリリースされると、対応するタグ（例: 15.4, 16, 16-alpineなど）を持つ公式イメージが公開されます。

PostgreSQLのメジャーバージョンアップグレードの注意点:

PostgreSQLは、新しいメジャーバージョンがリリースされると、データベースの内部データ形式が変更されることがあります。このため、例えばPostgreSQL 14のデータディレクトリをそのままPostgreSQL 15のコンテナにマウントしても、通常は起動できません。メジャーバージョン間のアップグレードには、特別な移行プロセスが必要です。

PostgreSQL公式イメージは、自動的なメジャーバージョンアップグレード機能を提供していません。これは意図的な設計です。データの破損や予期しない挙動を防ぐため、メジャーバージョンアップグレードはユーザーが明示的に、かつ慎重に行う必要があるためです。

メジャーバージョンアップグレードの方法 (手動):

公式イメージを使ってPostgreSQLのメジャーバージョンをアップグレードする場合、以下のいずれかの標準的なPostgreSQLの手法を、Dockerコンテナ内で実行する必要があります。

  1. pg_dumpallとpg_restore: 古いバージョンのデータベースから全てのデータをpg_dumpallコマンドでダンプし、新しいバージョンの空のデータベースにpg_restoreまたはpsqlでリストアする方法です。

    • 手順の概要:
      • 古いバージョンのコンテナでpg_dumpallを実行し、データをファイルにダンプする。
      • 新しいバージョンのコンテナ（データディレクトリは空）を起動する。
      • ダンプファイルを新しいコンテナにコピーまたはマウントする。
      • 新しいコンテナでpsqlまたはpg_restoreを実行し、データをロードする。
    • この方法は最も安全ですが、データベースのサイズが大きい場合は時間がかかります。

  2. pg_upgrade: PostgreSQLが提供するツールで、既存のデータディレクトリを新しいバージョンの形式に直接変換する方法です。

    • 手順の概要:
      • 古いバージョンのPostgreSQLバイナリと新しいバージョンのPostgreSQLバイナリ、そして古いデータディレクトリと新しいデータディレクトリを用意する。
      • 古いサーバーと新しいサーバーを停止した状態で、新しいバージョンのバイナリを使ってpg_upgradeコマンドを実行する。
      • 問題がなければ、古いデータディレクトリを削除する。
    • Docker環境でpg_upgradeを実行するには、少し工夫が必要です。両方のバージョンのPostgreSQLバイナリを持つコンテナイメージを作成するか、異なるコンテナ間でデータディレクトリを共有して一時的にマウントするといった方法が考えられます。公式ドキュメントには、pg_upgradeを実行するための特別なイメージやスクリプトは提供されていませんが、コミュニティによるツールが存在する場合があります。

公式イメージのドキュメントでも、メジャーバージョンアップグレードに関する詳細な手順は提供されていません。これは、アップグレードの手順が個々の環境や要件に依存するためです。アップグレードを行う際は、必ずPostgreSQLの公式ドキュメントを参照し、本番環境への適用前には十分なテストを行ってください。

マイナーバージョン（パッチバージョン）のアップグレードは通常、データ形式の変更を伴わないため、新しいマイナーバージョンのイメージを使って既存のボリュームをマウントしてコンテナを起動し直すだけで問題ありません。ただし、念のため公式ドキュメントのリリースノートを確認することをお勧めします。

レプリケーションとクラスタリング

PostgreSQLは、可用性や読み取り性能向上のためにレプリケーション機能を備えています。Docker環境、特に公式イメージでもレプリケーションを設定することが可能です。最も一般的なのは、ストリーミングレプリケーションです。

ストリーミングレプリケーションの設定概要:

ストリーミングレプリケーションを設定するには、マスターサーバーとレプリカサーバー（複数可）が必要です。

  • マスターサーバー:

    • WAL (wal_level) の設定をreplicaまたはlogicalにする必要があります。
    • レプリカからの接続を受け付けるための認証設定をpg_hba.confに追加する必要があります（replicationデータベースに対する接続許可）。
    • 必要に応じて、max_wal_sendersやwal_keep_sizeなどのパラメータを調整します。
    • 公式イメージでは、これらの設定を/etc/postgresql/postgresql.conf.d/に.confファイルを追加したり、pg_hba.confをバインドマウントまたはカスタムイメージで置き換えたりすることで実現できます。

  • レプリカサーバー:

    • データディレクトリは空の状態で起動する必要があります。
    • マスターサーバーから初期データをコピーするためにpg_basebackupなどのツールを使用します。
    • レプリケーションの接続情報（マスターのホスト、ポート、ユーザー、パスワード）を設定します。これは、standby.signalファイルとpostgresql.auto.confまたはpostgresql.confファイルで行います。
    • 公式イメージでレプリカを起動する際には、データディレクトリを空にしてボリュームなどをマウントし、初期化スクリプトやバインドマウントを使ってレプリケーション設定ファイル（standby.signalなど）やマスター接続情報を含んだ設定（primary_conninfoなど）を配置する必要があります。

Docker Composeを使ってマスターとレプリカのサービスを定義し、depends_onや独自の起動スクリプトを組み合わせてレプリケーション構成を自動化する例が、公式イメージのドキュメントや様々なチュートリアルで紹介されています。

より高度なクラスタリング構成（フェイルオーバー、自動プロモートなど）を実現したい場合は、PostgreSQL公式イメージを基盤として、Patroni, repmgr, Stolonといった専用のクラスタリングツールと組み合わせることが一般的です。これらのツールは、コンテナ環境での運用を考慮して設計されているものが多く、高い可用性を提供します。

パフォーマンスチューニング

PostgreSQLのパフォーマンスは、サーバーの設定パラメータに大きく依存します。Dockerコンテナ内で実行されるPostgreSQLも同様です。

主要なパフォーマンス関連パラメータ（例: shared_buffers, work_mem, maintenance_work_mem, wal_buffers, checkpoint_segments/max_wal_size, random_page_costなど）は、通常postgresql.confで設定します。公式イメージでは、前述の/etc/postgresql/postgresql.conf.d/ディレクトリに.confファイルを追加する方法でこれらのパラメータを設定するのが最も推奨される方法です。

例えば、メモリリソースが豊富な環境でshared_buffersを増やす設定は以下のようになります (custom-perf.confというファイルを作成し、/etc/postgresql/postgresql.conf.d/にマウントまたはコピー)。

“`conf

custom-perf.conf

shared_buffers = 1GB # 利用可能なメモリの約 25% を目安に設定
“`

また、Docker自体が提供するリソース制限機能もパフォーマンスに影響します。

  • --cpus <数値>: コンテナが使用できるCPUリソースを制限します（例: --cpus 1.5で1.5コア分）。
  • --memory <サイズ>: コンテナが使用できるメモリ量を制限します（例: --memory 2gで2GB）。

これらのリソース制限は、ホスト上の他のサービスへの影響を抑えたり、コンテナごとに割り当てるリソースを制御したりするのに役立ちます。PostgreSQLのパフォーマンスチューニングは複雑なトピックであり、ワークロードや利用可能なリソースに依存します。PostgreSQLの公式ドキュメントや専門的な情報を参照し、十分なテストを行って最適な設定を見つける必要があります。

セキュリティ

データベースセキュリティは非常に重要です。PostgreSQL公式イメージを利用する際のセキュリティに関する考慮事項をいくつか挙げます。

  • POSTGRES_PASSWORD の管理: 前述の通り、このパスワードは非常に重要です。コマンドラインで直接指定するのではなく、.envファイルやDocker Secretsなどの安全な方法で管理してください。
  • pg_hba.conf の設定: 誰が、どのホストから、どのような認証方法で接続できるかを厳密に制御してください。デフォルト設定はセキュリティが緩やかな場合があります。必要なネットワークからの接続のみを許可し、可能な限り安全な認証方式（例: scram-sha-256, SSL/TLSとクライアント証明書認証）を使用してください。/etc/postgresql/pg_hba.confを適切にカスタマイズすることが不可欠です。
  • ポートの公開: PostgreSQLのデフォルトポートである5432番ポートをホストに公開する場合 (-p 5432:5432)、そのポートが外部からアクセス可能になっていないか注意してください。ファイアウォールを設定したり、信頼できるネットワークからのアクセスのみに限定したりする必要があります。可能であれば、同じDockerネットワーク内のアプリケーションコンテナからのみアクセスできるようにし、ホストへのポート公開は避けるのが最も安全です。
  • イメージのアップデート: 公式イメージはセキュリティ修正を含むパッチバージョンがリリースされます。常に最新のパッチバージョンのイメージを使用することで、既知の脆弱性から保護されます。使用するタグ（例: postgres:15やpostgres:15.3）を定期的に更新し、コンテナを再作成して適用してください。
  • 非rootユーザーでの実行: Docker公式イメージは、特別な理由がない限りコンテナ内でroot権限を使用しないように設計されています。PostgreSQL公式イメージも、データベースプロセスはコンテナ内のpostgresユーザー（UID/GID: 999）として実行されます。これにより、仮にPostgreSQLサーバーに脆弱性が見つかっても、コンテナ内での攻撃の影響範囲を限定できます。データ永続化のためにボリュームを使用する場合、Dockerがこのpostgresユーザーのパーミッションを適切に管理してくれるため、手動でパーミッションを設定する手間が省けます。バインドマウントを使用する場合は、ホスト側のディレクトリのパーミッションをpostgresユーザーが書き込めるように設定する必要があります。

異なるアーキテクチャ

Dockerは、x86-64（amd64）アーキテクチャだけでなく、ARM64などの異なるアーキテクチャでも動作します。PostgreSQL公式イメージは、マルチアーキテクチャイメージとして提供されています。これは、同じイメージ名とタグ（例: postgres:15）で、プルを実行した環境のCPUアーキテクチャに適したイメージが自動的にダウンロードされることを意味します。

例えば、Raspberry PiのようなARM64デバイスでdocker pull postgres:15を実行すると、自動的にARM64用のイメージがプルされます。これにより、異なるアーキテクチャのデバイスでも同じコマンド、同じComposeファイルを使ってPostgreSQLコンテナを起動できます。これは、組み込みシステムやエッジコンピューティング環境でのPostgreSQL利用において非常に便利です。

ベストプラクティスとよくある落とし穴

PostgreSQL公式イメージを本番環境や長期的に利用する際に考慮すべきベストプラクティスと、陥りやすい落とし穴についてまとめます。

  • データ永続化は必須

    • これは最も重要です。開発や簡単な試用を除き、必ずボリュームまたはバインドマウントを使用してデータベースのデータを永続化してください。コンテナは使い捨て可能なものとして扱い、データはコンテナの外部に分離するのがDockerの基本的な思想です。
    • 推奨: ボリュームの使用 (-v postgres_data:/var/lib/postgresql/data)。

  • latest タグは使用しない

    • postgres:latestタグは、常に利用可能な最新のメジャーバージョンを指します。これにより、意図しないメジャーバージョンアップグレードが発生し、データベースのデータが互換性を失う可能性があります。
    • 使用するPostgreSQLのバージョンを固定するために、特定のメジャーバージョンタグ（例: postgres:15）またはメジャー.マイナーバージョンタグ（例: postgres:15.3）を使用してください。これにより、環境の再現性が保たれます。

  • 機密情報は安全に管理する

    • POSTGRES_PASSWORDやその他の認証情報は、コマンドライン引数で渡すのではなく、.envファイル、Docker Secrets、またはKubernetes Secretsのような安全な方法で管理してください。

  • ヘルスチェックを追加する

    • Docker Composeやオーケストレーションツールを使用する場合、データベースサービスのヘルスチェックを設定することを強く推奨します。これにより、PostgreSQLサーバーが実際にリクエストを受け付けられる状態にあるかを確認できます。
    • 例: Docker Composeのhealthcheck設定でpg_isreadyコマンドを使用する。アプリケーションコンテナがデータベースに依存している場合、ヘルスチェックが成功するまでアプリケーションの起動を待機させることで、起動順序の問題を回避できます。

  • ログの扱いを考慮する

    • PostgreSQL公式イメージは、デフォルトでログをコンテナの標準出力（stdout）と標準エラー出力（stderr）に出力します。これはDockerのログ収集のベストプラクティスに沿っています。
    • docker logs <コンテナ名>コマンドでログを確認できます。
    • 本番環境では、ログドライバー（json-file, syslog, fluentd, awslogsなど）を設定して、ログを集中ログ管理システム（Splunk, Elasticsearch/Kibana, CloudWatch Logsなど）に転送することを検討してください。

  • Graceful Shutdown を理解する

    • docker stop <コンテナ名>コマンドは、コンテナのメインプロセスにSIGTERMシグナルを送信します。PostgreSQL公式イメージの起動スクリプトは、このシグナルを受け取るとPostgreSQLサーバーを正常にシャットダウンする処理を行います。これにより、データの破損を防ぎます。
    • SIGTERMを受信してからPostgreSQLがシャットダウンを完了するまでの時間は、データベースのアクティビティによって異なります。デフォルトの停止タイムアウト（通常10秒）で不十分な場合は、docker stopコマンドの-tオプションやDocker Composeのstop_grace_periodオプションでタイムアウト時間を長く設定できます。

  • コンテナ内のファイル編集は避ける

    • 実行中のコンテナに入って（docker exec -it ...）ファイルを直接編集することは、デバッグ目的以外では避けるべきです。これらの変更はコンテナのライフサイクルと同期するため永続化されません。
    • 設定変更などは、環境変数、初期化スクリプト、または設定ファイルのバインドマウント/COPYといった、イメージやコンテナ定義レベルでの変更として行うべきです。

  • リソース制限を設定する

    • 特に本番環境では、PostgreSQLコンテナが消費できるCPUやメモリのリソースに上限を設定することを検討してください。これにより、リソース枯渇によってホストや他のサービスに影響が出るのを防ぐことができます。

まとめ

本記事では、Dockerユーザーのために、PostgreSQL公式イメージについて徹底的に解説しました。基本的なコンテナの起動から始まり、環境変数による設定、ボリュームやバインドマウントを使ったデータ永続化、初期化スクリプトによる自動セットアップ、設定ファイルのカスタマイズ、そしてDocker Composeによる複数コンテナでの利用方法まで、PostgreSQL公式イメージを効果的に使いこなすために必要な主要な機能と設定オプションを網羅しました。

さらに、バージョンアップグレードの注意点、レプリケーション構成、パフォーマンスチューニング、そしてセキュリティといった高度なトピックにも触れ、本番環境での運用を見据えた考慮事項や、Docker環境ならではのベストプラクティスとよくある落とし穴についても解説しました。

PostgreSQL公式イメージは、その信頼性、メンテナンス性、そしてDockerネイティブな機能との親和性の高さから、Docker環境でPostgreSQLを利用する際の第一選択肢となるべきものです。本記事で紹介した様々なカスタマイズ機能や設定オプションを理解することで、開発、テスト、そして本番環境において、あなたの要件に合ったPostgreSQLコンテナ環境を柔軟かつ安全に構築できるようになるでしょう。

ただし、データベースシステムは非常に重要であり、特に本番環境においては慎重な設計と運用が求められます。本記事で触れた各トピック（特にバージョンアップグレードやレプリケーション、セキュリティ、パフォーマンスチューニング）について、さらに深く掘り下げたい場合は、PostgreSQL自体の公式ドキュメントや、Docker、Docker Composeの公式ドキュメントを参照することを強くお勧めします。

DockerとPostgreSQL公式イメージを組み合わせることで、データベース環境の構築・管理はかつてなく容易かつ効率的になります。ぜひこれらの知識を活かして、あなたのプロジェクトに安定したデータベース基盤を構築してください。

Happy Dockering with PostgreSQL!

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール