Docker Compose と bitnami イメージを使用して、MySQL、PostgreSQL、MongoDB、Redis、Kafka を使用した開発環境をすばやくセットアップする方法を示します。 、環境変数、各データベースの UI ツール。このプロセスを段階的に説明します:
事前構成および最適化: Bitnami イメージはベスト プラクティスに従って事前構成されているため、一般的な使用例に合わせてセットアップと最適化が容易になります。
セキュリティ: Bitnami は、脆弱性に対処するためにイメージを定期的に更新し、頻繁に更新されない可能性のあるコミュニティによって管理される一部のイメージと比較して、より安全なオプションを提供します。
環境全体の一貫性: Bitnami は、イメージが異なる環境間で一貫して動作することを保証し、テスト、開発、実稼働セットアップに適した選択肢となります。
使いやすさ: 多くの場合、展開を簡素化するスクリプトとデフォルトが含まれており、手動による構成とセットアップの必要性が減ります。
ドキュメントとサポート: Bitnami は詳細なドキュメントを提供し、場合によっては親会社である VMware を通じてサポートを提供します。これはトラブルシューティングや企業での使用に役立ちます。
もう 1 つのインポートに関する注意事項はライセンスに関するもので、内容は異なる場合がありますが、bitnami ソフトウェアは通常無料で使用でき、そのコンテナとパッケージはオープンソース ソフトウェアに基づいており、MIT、Apache 2.0、または GPL などのライセンスを使用します。オープンソースのライセンスについて
次のプロジェクト構造を作成します:
dev-environment/ ├── components # for mounting container volumes ├── scripts/ │ ├── pgadmin │ │ ├──servers.json # for pgadmin automatically load postgreDB │ ├── create-topics.sh # for creating kafka topics │ ├── mongo-init.sh # init script for mongodb │ ├── mysql-init.sql # init script for mysql │ ├── postgres-init.sql # init script for postgre ├── .env ├── docker-compose.yml
次の内容を含む .env ファイルを作成します:
# MySQL Configuration MYSQL_PORT=23306 MYSQL_USERNAME=dev-user MYSQL_PASSWORD=dev-password MYSQL_DATABASE=dev_database # PostgreSQL Configuration POSTGRES_PORT=25432 POSTGRES_USERNAME=dev-user POSTGRES_PASSWORD=dev-password POSTGRES_DATABASE=dev_database # MongoDB Configuration MONGO_PORT=27017 MONGO_USERNAME=dev-user MONGO_PASSWORD=dev-password MONGO_DATABASE=dev_database # Redis Configuration REDIS_PORT=26379 REDIS_PASSWORD=dev-password # Kafka Configuration KAFKA_PORT=29092 KAFKA_USERNAME=dev-user KAFKA_PASSWORD=dev-password # UI Tools Configuration PHPMYADMIN_PORT=280 PGADMIN_PORT=281 MONGOEXPRESS_PORT=28081 REDIS_COMMANDER_PORT=28082 KAFKA_UI_PORT=28080 # Data Directory for Volumes DATA_DIR=./
docker-compose.yml ファイルを作成します:
version: '3.8'
services:
dev-mysql:
image: bitnami/mysql:latest
# This container_name can be used for internal connections between containers (running on the same docker virtual network)
container_name: dev-mysql
ports:
# This mapping means that requests sent to the ${MYSQL_PORT} on the host machine will be forwarded to port 3306 in the dev-mysql container. This setup allows users to access the MySQL database from outside the container, such as from a local machine or another service.
- '${MYSQL_PORT}:3306'
environment:
# Setup environment variables for container
- MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_USER=${MYSQL_USERNAME}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
volumes:
# Syncs msyql data from inside container to host machine, to keep them accross container restarts
- '${DATA_DIR}/components/mysql/data:/bitnami/mysql/data'
# Add custom script to init db
- './scripts/mysql-init.sql:/docker-entrypoint-initdb.d/init.sql'
phpmyadmin:
image: phpmyadmin/phpmyadmin:latest
container_name: dev-phpmyadmin
# The depends_on option in Docker specifies that a container should be started only after the specified dependent container (e.g., dev-mysql) has been started (but not ensuring that it is ready)
depends_on:
- dev-mysql
ports:
- '${PHPMYADMIN_PORT}:80'
environment:
- PMA_HOST=dev-mysql
# use internal port for internal connections, not exposed port ${MYSQL_PORT}
- PMA_PORT=3306
- PMA_USER=${MYSQL_USERNAME}
- PMA_PASSWORD=${MYSQL_PASSWORD}
#=======
dev-postgresql:
image: bitnami/postgresql:latest
container_name: dev-postgresql
ports:
- '${POSTGRES_PORT}:5432'
environment:
- POSTGRESQL_USERNAME=${POSTGRES_USERNAME}
- POSTGRESQL_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRESQL_DATABASE=${POSTGRES_DATABASE}
volumes:
# This setup will ensure that PostgreSQL data from inside container is synced to host machine, enabling persistence across container restarts.
- '${DATA_DIR}/components/postgresql/data:/bitnami/postgresql/data'
# Most relational databases support a special docker-entrypoint-initdb.d folder. This folder is used to initialise the database automatically when the container is first created.
# We can put .sql or .sh scripts there, and Docker will automatically, here ./scripts/postgres-init.sql from host machine be automatically copied to the Docker container during the build and then run it
- ./scripts/postgres-init.sql:/docker-entrypoint-initdb.d/init.sql:ro
pgadmin:
image: dpage/pgadmin4:latest
container_name: dev-pgadmin
depends_on:
- dev-postgresql
ports:
- '${PGADMIN_PORT}:80'
# user: root used to ensure that the container has full administrative privileges,
# necessary when performing actions that require elevated permissions, such as mounting volumes (properly read or write to the mounted volumes), executing certain entrypoint commands, or accessing specific directories from host machine
user: root
environment:
# PGADMIN_DEFAULT_EMAIL and PGADMIN_DEFAULT_PASSWORD - Sets the default credentials for the pgAdmin user
- PGADMIN_DEFAULT_EMAIL=admin@dev.com
- PGADMIN_DEFAULT_PASSWORD=${POSTGRES_PASSWORD}
# PGADMIN_CONFIG_SERVER_MODE - determines whether pgAdmin runs in server mode (multi-user) or desktop mode (single-user). We’re setting it to false, so we won’t be prompted for login credentials
- PGADMIN_CONFIG_SERVER_MODE=False
# PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED - controls whether a master password is required to access saved server definitions and other sensitive information
- PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED=False
volumes:
# This setup will ensure that PGAdmin data from inside container is synced to host machine, enabling persistence across container restarts.
- '${DATA_DIR}/components/pgadmin:/var/lib/pgadmin'
# This setup to make PGAdmin automatically detect and connect to PostgreSQL when it starts (following the config being set in servers.json)
- ./scripts/pgadmin/servers.json:/pgadmin4/servers.json:ro
#=======
dev-mongodb:
image: bitnami/mongodb:latest
container_name: dev-mongodb
ports:
- '${MONGO_PORT}:27017'
environment:
- MONGO_INITDB_ROOT_USERNAME=${MONGO_USERNAME}
- MONGO_INITDB_ROOT_PASSWORD=${MONGO_PASSWORD}
- MONGO_INITDB_DATABASE=${MONGO_DATABASE}
- MONGODB_ROOT_USER=${MONGO_USERNAME}
- MONGODB_ROOT_PASSWORD=${MONGO_PASSWORD}
- MONGODB_DATABASE=${MONGO_DATABASE}
volumes:
- '${DATA_DIR}/components/mongodb/data:/bitnami/mongodb'
# This line maps ./scripts/mongo-init.sh from host machine to /docker-entrypoint-initdb.d/mongo-init.sh inside container with 'ro' mode (read only mode) which means container can't modify the mounted file
- ./scripts/mongo-init.sh:/docker-entrypoint-initdb.d/mongo-init.sh:ro
# - ./scripts/mongo-init.sh:/bitnami/scripts/mongo-init.sh:ro
mongo-express:
image: mongo-express:latest
container_name: dev-mongoexpress
depends_on:
- dev-mongodb
ports:
- '${MONGOEXPRESS_PORT}:8081'
environment:
- ME_CONFIG_MONGODB_ENABLE_ADMIN=true
- ME_CONFIG_MONGODB_ADMINUSERNAME=${MONGO_USERNAME}
- ME_CONFIG_MONGODB_ADMINPASSWORD=${MONGO_PASSWORD}
# - ME_CONFIG_MONGODB_SERVER=dev-mongodb
# - ME_CONFIG_MONGODB_PORT=${MONGO_PORT}
- ME_CONFIG_MONGODB_URL=mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@dev-mongodb:${MONGO_PORT}/${MONGO_DATABASE}?authSource=admin&ssl=false&directConnection=true
restart: unless-stopped
# 'restart: unless-stopped' restarts a container automatically unless it is explicitly stopped by the user.
# some others: 1. 'no': (Default option if not specified) meaning the container won't automatically restart if it stops or crashes.
# 2. 'always': The container will restart regardless of the reason it stopped, including if Docker is restarted.
# 3. 'on-failure': The container will restart only if it exits with a non-zero status indicating an error. (and won't restart if it stops when completing as short running task and return 0 status).
#=======
dev-redis:
image: bitnami/redis:latest
container_name: dev-redis
ports:
- '${REDIS_PORT}:6379'
environment:
- REDIS_PASSWORD=${REDIS_PASSWORD}
volumes:
- '${DATA_DIR}/components/redis:/bitnami/redis'
networks:
- dev-network
redis-commander:
image: rediscommander/redis-commander:latest
container_name: dev-redis-commander
depends_on:
- dev-redis
ports:
- '${REDIS_COMMANDER_PORT}:8081'
environment:
- REDIS_HOST=dev-redis
# While exposed port ${REDIS_PORT} being bind to host network, redis-commander still using internal port 6379 (being use internally inside docker virtual network) to connect to redis
- REDIS_PORT=6379
- REDIS_PASSWORD=${REDIS_PASSWORD}
networks:
- dev-network
# This networks setup is optional, in case not being set, both redis-commader and redis will both be assigned to default docker network (usually named bridge) and still being able to connect each other
#=======
dev-kafka:
image: 'bitnami/kafka:latest'
container_name: dev-kafka
ports:
- '${KAFKA_PORT}:9094'
environment:
# Sets the timezone for the container to "Asia/Shanghai". This ensures that logs and timestamps inside the Kafka container align with the Shanghai timezone.
- TZ=Asia/Shanghai
# KAFKA_CFG_NODE_ID=0: Identifies the Kafka node with ID 0. This is crucial for multi-node Kafka clusters to distinguish each node uniquely.
- KAFKA_CFG_NODE_ID=0
# KAFKA_CFG_PROCESS_ROLES=controller,broker: Specifies the roles the Kafka node will perform, in this case, both as a controller (managing cluster metadata) and a broker (handling messages).
- KAFKA_CFG_PROCESS_ROLES=controller,broker
# KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@<your_host>:9093: Defines the quorum voters for the Kafka controllers. It indicates that node 0 (the current node) acts as a voter for controller decisions and will be accessible at 9093 on <your_host>.
- KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@<your_host>:9093
# The following lists different listeners for Kafka. Each listener binds a protocol to a specific port:
# PLAINTEXT for client connections (:9092). CONTROLLER for internal controller communication (:9093). EXTERNAL for external client access (:9094).SASL_PLAINTEXT for SASL-authenticated clients (:9095).
- KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094,SASL_PLAINTEXT://:9095
# KAFKA_CFG_ADVERTISED_LISTENERS specifies how clients should connect to Kafka externally:
# PLAINTEXT at dev-kafka:9092 for internal communication. EXTERNAL at 127.0.0.1:${KAFKA_PORT} (host access). SASL_PLAINTEXT for SASL connections (kafka:9095).
- KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://dev-kafka:9092,EXTERNAL://127.0.0.1:${KAFKA_PORT},SASL_PLAINTEXT://kafka:9095
# The following maps security protocols to each listener. For example, CONTROLLER uses PLAINTEXT, and EXTERNAL uses SASL_PLAINTEXT.
- KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:SASL_PLAINTEXT,PLAINTEXT:PLAINTEXT,SASL_PLAINTEXT:SASL_PLAINTEXT
# Indicates that the CONTROLLER role should use the CONTROLLER listener for communications.
- KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
# Specifies users with relevant passwords that can connect to Kafka using SASL authentication
- KAFKA_CLIENT_USERS=${KAFKA_USERNAME}
- KAFKA_CLIENT_PASSWORDS=${KAFKA_PASSWORD}
volumes:
- '${DATA_DIR}/components/kafka/data:/bitnami/kafka/data'
# Maps a local file create-topics.sh from the ./scripts directory to the path /opt/bitnami/kafka/create_topic.sh inside the Kafka container
# This script can be used to automatically create Kafka topics when the container starts
- ./scripts/create-topics.sh:/opt/bitnami/kafka/create_topic.sh:ro
# Following command starts the Kafka server in the background using /opt/bitnami/scripts/kafka/run.sh. then sleep 5 to ensure that the Kafka server is fully up and running.
# Executes the create_topic.sh script, which is used to create Kafka topics. Uses 'wait' to keep the script running until all background processes (like the Kafka server) finish,
command: >
bash -c "
/opt/bitnami/scripts/kafka/run.sh & sleep 5; /opt/bitnami/kafka/create_topic.sh; wait
"
kafka-ui:
image: provectuslabs/kafka-ui:latest
container_name: dev-kafka-ui
ports:
- '${KAFKA_UI_PORT}:8080'
environment:
# Sets the name of the Kafka cluster displayed in the UI as "local."
- KAFKA_CLUSTERS_0_NAME=local
# Specifies the address (dev-kafka:9092) for the Kafka broker that the UI should connect to.
- KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=dev-kafka:9092
# Uses the provided ${KAFKA_USERNAME} for SASL (Simple Authentication and Security Layer) authentication with the Kafka cluster.
- KAFKA_CLUSTERS_0_SASL_USER=${KAFKA_USERNAME}
# Uses the ${KAFKA_PASSWORD} for authentication with the Kafka broker.
- KAFKA_CLUSTERS_0_SASL_PASSWORD=${KAFKA_PASSWORD}
# Sets the SASL mechanism as 'PLAIN', which is a simple username-password-based authentication method.
- KAFKA_CLUSTERS_0_SASL_MECHANISM=PLAIN
# Configures the communication protocol as SASL_PLAINTEXT, which means it uses SASL for authentication without encryption over plaintext communication.
- KAFKA_CLUSTERS_0_SECURITY_PROTOCOL=SASL_PLAINTEXT
depends_on:
- dev-kafka
networks:
dev-network:
driver: bridge
必要なスクリプトを scripts フォルダーに作成します。
pgadmin/servers.json:
{
"Servers": {
"1": {
"Name": "Local PostgreSQL",
"Group": "Servers",
"Host": "dev-postgresql",
"Port": 5432,
"MaintenanceDB": "dev_database",
"Username": "dev-user",
"Password": "dev-password",
"SSLMode": "prefer",
"Favorite": true
}
}
}
create-topics.sh:
# Wait for Kafka to be ready until /opt/bitnami/kafka/bin/kafka-topics.sh --list --bootstrap-server localhost:9092; do echo "Waiting for Kafka to be ready..." sleep 2 done # Create topics /opt/bitnami/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 8 --topic latestMsgToRedis /opt/bitnami/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 8 --topic msgToPush /opt/bitnami/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 8 --topic offlineMsgToMongoMysql echo "Topics created."
mongo-init.sh:
# mongosh --: Launches the MongoDB shell, connecting to the default MongoDB instance.
# "$MONGO_INITDB_DATABASE": Specifies the database to connect to (using the value from the environment variable).
# <<EOF: Indicates the start of a multi-line input block. Everything between <<EOF and EOF is treated as MongoDB shell commands to be executed.
# db.getSiblingDB('admin'): Switches to the admin database, which is the default administrative database in MongoDB. It allows you to perform administrative tasks like user creation, where the user dev-user will be created.
# db.auth('$MONGO_INITDB_ROOT_USERNAME', '$MONGO_INITDB_ROOT_PASSWORD') (commented out): This line, if executed, would authenticate the user with the given credentials against the "admin" database. It’s necessary if the following operations require authentication.
# The user dev-user is created in the admin database with the specified username and password.
# { role: 'root', db: 'admin' }: Allows full access to the admin database.
# { role: 'readWrite', db: '$MONGO_INITDB_DATABASE' }: Grants read and write permissions specifically for dev_database.
mongosh -- "$MONGO_INITDB_DATABASE" <<EOF
db = db.getSiblingDB('admin')
db.auth('$MONGO_INITDB_ROOT_USERNAME', '$MONGO_INITDB_ROOT_PASSWORD')
db.createUser({
user: "$MONGODB_ROOT_USER",
pwd: "$MONGODB_ROOT_PASSWORD",
roles: [
{ role: 'root', db: 'admin' },
{ role: 'root', db: '$MONGO_INITDB_DATABASE' }
]
})
db = db.getSiblingDB('$MONGO_INITDB_DATABASE');
db.createCollection('users');
db.users.insertMany([
{ username: 'user1', email: 'user1@example.com' },
{ username: 'user2', email: 'user2@example.com' }
]);
EOF
mysql-init.sql:
-- CREATE TABLE IF NOT EXISTS test (id SERIAL PRIMARY KEY, name VARCHAR(50));
BEGIN;
-- structure setup
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(50) NOT NULL,
email VARCHAR(100) NOT NULL
);
-- data setup
INSERT INTO users (username, email)
VALUES ('user1', 'user1@example.com');
INSERT INTO users (username, email)
VALUES ('user2', 'user2@example.com');
COMMIT;
postgres-init.sql:
-- CREATE TABLE IF NOT EXISTS test (id SERIAL PRIMARY KEY, name VARCHAR(50));
BEGIN;
-- structure setup
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(50) NOT NULL,
email VARCHAR(100) NOT NULL
);
-- data setup
INSERT INTO users (username, email)
VALUES ('user1', 'user1@example.com');
INSERT INTO users (username, email)
VALUES ('user2', 'user2@example.com');
COMMIT;
ターミナルで、dev-environment フォルダーに移動し、次のコマンドを実行します。
dev-environment/ ├── components # for mounting container volumes ├── scripts/ │ ├── pgadmin │ │ ├──servers.json # for pgadmin automatically load postgreDB │ ├── create-topics.sh # for creating kafka topics │ ├── mongo-init.sh # init script for mongodb │ ├── mysql-init.sql # init script for mysql │ ├── postgres-init.sql # init script for postgre ├── .env ├── docker-compose.yml
このコマンドは、定義された独自のコンテナー、ポート、環境構成を持つすべてのサービスを開始します。
各 UI ツールは、それぞれのデータベース コンテナに接続するようにすでに構成されています。
まず最初に、.env ファイルから現在動作している CLI セッションにすべての環境変数をロードする必要があります。これを行うには、次のコマンドを使用できます:
# MySQL Configuration MYSQL_PORT=23306 MYSQL_USERNAME=dev-user MYSQL_PASSWORD=dev-password MYSQL_DATABASE=dev_database # PostgreSQL Configuration POSTGRES_PORT=25432 POSTGRES_USERNAME=dev-user POSTGRES_PASSWORD=dev-password POSTGRES_DATABASE=dev_database # MongoDB Configuration MONGO_PORT=27017 MONGO_USERNAME=dev-user MONGO_PASSWORD=dev-password MONGO_DATABASE=dev_database # Redis Configuration REDIS_PORT=26379 REDIS_PASSWORD=dev-password # Kafka Configuration KAFKA_PORT=29092 KAFKA_USERNAME=dev-user KAFKA_PASSWORD=dev-password # UI Tools Configuration PHPMYADMIN_PORT=280 PGADMIN_PORT=281 MONGOEXPRESS_PORT=28081 REDIS_COMMANDER_PORT=28082 KAFKA_UI_PORT=28080 # Data Directory for Volumes DATA_DIR=./
MySQL CLI へのアクセス
version: '3.8'
services:
dev-mysql:
image: bitnami/mysql:latest
# This container_name can be used for internal connections between containers (running on the same docker virtual network)
container_name: dev-mysql
ports:
# This mapping means that requests sent to the ${MYSQL_PORT} on the host machine will be forwarded to port 3306 in the dev-mysql container. This setup allows users to access the MySQL database from outside the container, such as from a local machine or another service.
- '${MYSQL_PORT}:3306'
environment:
# Setup environment variables for container
- MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_USER=${MYSQL_USERNAME}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
volumes:
# Syncs msyql data from inside container to host machine, to keep them accross container restarts
- '${DATA_DIR}/components/mysql/data:/bitnami/mysql/data'
# Add custom script to init db
- './scripts/mysql-init.sql:/docker-entrypoint-initdb.d/init.sql'
phpmyadmin:
image: phpmyadmin/phpmyadmin:latest
container_name: dev-phpmyadmin
# The depends_on option in Docker specifies that a container should be started only after the specified dependent container (e.g., dev-mysql) has been started (but not ensuring that it is ready)
depends_on:
- dev-mysql
ports:
- '${PHPMYADMIN_PORT}:80'
environment:
- PMA_HOST=dev-mysql
# use internal port for internal connections, not exposed port ${MYSQL_PORT}
- PMA_PORT=3306
- PMA_USER=${MYSQL_USERNAME}
- PMA_PASSWORD=${MYSQL_PASSWORD}
#=======
dev-postgresql:
image: bitnami/postgresql:latest
container_name: dev-postgresql
ports:
- '${POSTGRES_PORT}:5432'
environment:
- POSTGRESQL_USERNAME=${POSTGRES_USERNAME}
- POSTGRESQL_PASSWORD=${POSTGRES_PASSWORD}
- POSTGRESQL_DATABASE=${POSTGRES_DATABASE}
volumes:
# This setup will ensure that PostgreSQL data from inside container is synced to host machine, enabling persistence across container restarts.
- '${DATA_DIR}/components/postgresql/data:/bitnami/postgresql/data'
# Most relational databases support a special docker-entrypoint-initdb.d folder. This folder is used to initialise the database automatically when the container is first created.
# We can put .sql or .sh scripts there, and Docker will automatically, here ./scripts/postgres-init.sql from host machine be automatically copied to the Docker container during the build and then run it
- ./scripts/postgres-init.sql:/docker-entrypoint-initdb.d/init.sql:ro
pgadmin:
image: dpage/pgadmin4:latest
container_name: dev-pgadmin
depends_on:
- dev-postgresql
ports:
- '${PGADMIN_PORT}:80'
# user: root used to ensure that the container has full administrative privileges,
# necessary when performing actions that require elevated permissions, such as mounting volumes (properly read or write to the mounted volumes), executing certain entrypoint commands, or accessing specific directories from host machine
user: root
environment:
# PGADMIN_DEFAULT_EMAIL and PGADMIN_DEFAULT_PASSWORD - Sets the default credentials for the pgAdmin user
- PGADMIN_DEFAULT_EMAIL=admin@dev.com
- PGADMIN_DEFAULT_PASSWORD=${POSTGRES_PASSWORD}
# PGADMIN_CONFIG_SERVER_MODE - determines whether pgAdmin runs in server mode (multi-user) or desktop mode (single-user). We’re setting it to false, so we won’t be prompted for login credentials
- PGADMIN_CONFIG_SERVER_MODE=False
# PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED - controls whether a master password is required to access saved server definitions and other sensitive information
- PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED=False
volumes:
# This setup will ensure that PGAdmin data from inside container is synced to host machine, enabling persistence across container restarts.
- '${DATA_DIR}/components/pgadmin:/var/lib/pgadmin'
# This setup to make PGAdmin automatically detect and connect to PostgreSQL when it starts (following the config being set in servers.json)
- ./scripts/pgadmin/servers.json:/pgadmin4/servers.json:ro
#=======
dev-mongodb:
image: bitnami/mongodb:latest
container_name: dev-mongodb
ports:
- '${MONGO_PORT}:27017'
environment:
- MONGO_INITDB_ROOT_USERNAME=${MONGO_USERNAME}
- MONGO_INITDB_ROOT_PASSWORD=${MONGO_PASSWORD}
- MONGO_INITDB_DATABASE=${MONGO_DATABASE}
- MONGODB_ROOT_USER=${MONGO_USERNAME}
- MONGODB_ROOT_PASSWORD=${MONGO_PASSWORD}
- MONGODB_DATABASE=${MONGO_DATABASE}
volumes:
- '${DATA_DIR}/components/mongodb/data:/bitnami/mongodb'
# This line maps ./scripts/mongo-init.sh from host machine to /docker-entrypoint-initdb.d/mongo-init.sh inside container with 'ro' mode (read only mode) which means container can't modify the mounted file
- ./scripts/mongo-init.sh:/docker-entrypoint-initdb.d/mongo-init.sh:ro
# - ./scripts/mongo-init.sh:/bitnami/scripts/mongo-init.sh:ro
mongo-express:
image: mongo-express:latest
container_name: dev-mongoexpress
depends_on:
- dev-mongodb
ports:
- '${MONGOEXPRESS_PORT}:8081'
environment:
- ME_CONFIG_MONGODB_ENABLE_ADMIN=true
- ME_CONFIG_MONGODB_ADMINUSERNAME=${MONGO_USERNAME}
- ME_CONFIG_MONGODB_ADMINPASSWORD=${MONGO_PASSWORD}
# - ME_CONFIG_MONGODB_SERVER=dev-mongodb
# - ME_CONFIG_MONGODB_PORT=${MONGO_PORT}
- ME_CONFIG_MONGODB_URL=mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@dev-mongodb:${MONGO_PORT}/${MONGO_DATABASE}?authSource=admin&ssl=false&directConnection=true
restart: unless-stopped
# 'restart: unless-stopped' restarts a container automatically unless it is explicitly stopped by the user.
# some others: 1. 'no': (Default option if not specified) meaning the container won't automatically restart if it stops or crashes.
# 2. 'always': The container will restart regardless of the reason it stopped, including if Docker is restarted.
# 3. 'on-failure': The container will restart only if it exits with a non-zero status indicating an error. (and won't restart if it stops when completing as short running task and return 0 status).
#=======
dev-redis:
image: bitnami/redis:latest
container_name: dev-redis
ports:
- '${REDIS_PORT}:6379'
environment:
- REDIS_PASSWORD=${REDIS_PASSWORD}
volumes:
- '${DATA_DIR}/components/redis:/bitnami/redis'
networks:
- dev-network
redis-commander:
image: rediscommander/redis-commander:latest
container_name: dev-redis-commander
depends_on:
- dev-redis
ports:
- '${REDIS_COMMANDER_PORT}:8081'
environment:
- REDIS_HOST=dev-redis
# While exposed port ${REDIS_PORT} being bind to host network, redis-commander still using internal port 6379 (being use internally inside docker virtual network) to connect to redis
- REDIS_PORT=6379
- REDIS_PASSWORD=${REDIS_PASSWORD}
networks:
- dev-network
# This networks setup is optional, in case not being set, both redis-commader and redis will both be assigned to default docker network (usually named bridge) and still being able to connect each other
#=======
dev-kafka:
image: 'bitnami/kafka:latest'
container_name: dev-kafka
ports:
- '${KAFKA_PORT}:9094'
environment:
# Sets the timezone for the container to "Asia/Shanghai". This ensures that logs and timestamps inside the Kafka container align with the Shanghai timezone.
- TZ=Asia/Shanghai
# KAFKA_CFG_NODE_ID=0: Identifies the Kafka node with ID 0. This is crucial for multi-node Kafka clusters to distinguish each node uniquely.
- KAFKA_CFG_NODE_ID=0
# KAFKA_CFG_PROCESS_ROLES=controller,broker: Specifies the roles the Kafka node will perform, in this case, both as a controller (managing cluster metadata) and a broker (handling messages).
- KAFKA_CFG_PROCESS_ROLES=controller,broker
# KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@<your_host>:9093: Defines the quorum voters for the Kafka controllers. It indicates that node 0 (the current node) acts as a voter for controller decisions and will be accessible at 9093 on <your_host>.
- KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@<your_host>:9093
# The following lists different listeners for Kafka. Each listener binds a protocol to a specific port:
# PLAINTEXT for client connections (:9092). CONTROLLER for internal controller communication (:9093). EXTERNAL for external client access (:9094).SASL_PLAINTEXT for SASL-authenticated clients (:9095).
- KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094,SASL_PLAINTEXT://:9095
# KAFKA_CFG_ADVERTISED_LISTENERS specifies how clients should connect to Kafka externally:
# PLAINTEXT at dev-kafka:9092 for internal communication. EXTERNAL at 127.0.0.1:${KAFKA_PORT} (host access). SASL_PLAINTEXT for SASL connections (kafka:9095).
- KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://dev-kafka:9092,EXTERNAL://127.0.0.1:${KAFKA_PORT},SASL_PLAINTEXT://kafka:9095
# The following maps security protocols to each listener. For example, CONTROLLER uses PLAINTEXT, and EXTERNAL uses SASL_PLAINTEXT.
- KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:SASL_PLAINTEXT,PLAINTEXT:PLAINTEXT,SASL_PLAINTEXT:SASL_PLAINTEXT
# Indicates that the CONTROLLER role should use the CONTROLLER listener for communications.
- KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
# Specifies users with relevant passwords that can connect to Kafka using SASL authentication
- KAFKA_CLIENT_USERS=${KAFKA_USERNAME}
- KAFKA_CLIENT_PASSWORDS=${KAFKA_PASSWORD}
volumes:
- '${DATA_DIR}/components/kafka/data:/bitnami/kafka/data'
# Maps a local file create-topics.sh from the ./scripts directory to the path /opt/bitnami/kafka/create_topic.sh inside the Kafka container
# This script can be used to automatically create Kafka topics when the container starts
- ./scripts/create-topics.sh:/opt/bitnami/kafka/create_topic.sh:ro
# Following command starts the Kafka server in the background using /opt/bitnami/scripts/kafka/run.sh. then sleep 5 to ensure that the Kafka server is fully up and running.
# Executes the create_topic.sh script, which is used to create Kafka topics. Uses 'wait' to keep the script running until all background processes (like the Kafka server) finish,
command: >
bash -c "
/opt/bitnami/scripts/kafka/run.sh & sleep 5; /opt/bitnami/kafka/create_topic.sh; wait
"
kafka-ui:
image: provectuslabs/kafka-ui:latest
container_name: dev-kafka-ui
ports:
- '${KAFKA_UI_PORT}:8080'
environment:
# Sets the name of the Kafka cluster displayed in the UI as "local."
- KAFKA_CLUSTERS_0_NAME=local
# Specifies the address (dev-kafka:9092) for the Kafka broker that the UI should connect to.
- KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=dev-kafka:9092
# Uses the provided ${KAFKA_USERNAME} for SASL (Simple Authentication and Security Layer) authentication with the Kafka cluster.
- KAFKA_CLUSTERS_0_SASL_USER=${KAFKA_USERNAME}
# Uses the ${KAFKA_PASSWORD} for authentication with the Kafka broker.
- KAFKA_CLUSTERS_0_SASL_PASSWORD=${KAFKA_PASSWORD}
# Sets the SASL mechanism as 'PLAIN', which is a simple username-password-based authentication method.
- KAFKA_CLUSTERS_0_SASL_MECHANISM=PLAIN
# Configures the communication protocol as SASL_PLAINTEXT, which means it uses SASL for authentication without encryption over plaintext communication.
- KAFKA_CLUSTERS_0_SECURITY_PROTOCOL=SASL_PLAINTEXT
depends_on:
- dev-kafka
networks:
dev-network:
driver: bridge
PostgreSQL CLI へのアクセス
{
"Servers": {
"1": {
"Name": "Local PostgreSQL",
"Group": "Servers",
"Host": "dev-postgresql",
"Port": 5432,
"MaintenanceDB": "dev_database",
"Username": "dev-user",
"Password": "dev-password",
"SSLMode": "prefer",
"Favorite": true
}
}
}
MongoDB CLI へのアクセス
# Wait for Kafka to be ready until /opt/bitnami/kafka/bin/kafka-topics.sh --list --bootstrap-server localhost:9092; do echo "Waiting for Kafka to be ready..." sleep 2 done # Create topics /opt/bitnami/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 8 --topic latestMsgToRedis /opt/bitnami/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 8 --topic msgToPush /opt/bitnami/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 8 --topic offlineMsgToMongoMysql echo "Topics created."
Redis CLI にアクセスします
# mongosh --: Launches the MongoDB shell, connecting to the default MongoDB instance.
# "$MONGO_INITDB_DATABASE": Specifies the database to connect to (using the value from the environment variable).
# <<EOF: Indicates the start of a multi-line input block. Everything between <<EOF and EOF is treated as MongoDB shell commands to be executed.
# db.getSiblingDB('admin'): Switches to the admin database, which is the default administrative database in MongoDB. It allows you to perform administrative tasks like user creation, where the user dev-user will be created.
# db.auth('$MONGO_INITDB_ROOT_USERNAME', '$MONGO_INITDB_ROOT_PASSWORD') (commented out): This line, if executed, would authenticate the user with the given credentials against the "admin" database. It’s necessary if the following operations require authentication.
# The user dev-user is created in the admin database with the specified username and password.
# { role: 'root', db: 'admin' }: Allows full access to the admin database.
# { role: 'readWrite', db: '$MONGO_INITDB_DATABASE' }: Grants read and write permissions specifically for dev_database.
mongosh -- "$MONGO_INITDB_DATABASE" <<EOF
db = db.getSiblingDB('admin')
db.auth('$MONGO_INITDB_ROOT_USERNAME', '$MONGO_INITDB_ROOT_PASSWORD')
db.createUser({
user: "$MONGODB_ROOT_USER",
pwd: "$MONGODB_ROOT_PASSWORD",
roles: [
{ role: 'root', db: 'admin' },
{ role: 'root', db: '$MONGO_INITDB_DATABASE' }
]
})
db = db.getSiblingDB('$MONGO_INITDB_DATABASE');
db.createCollection('users');
db.users.insertMany([
{ username: 'user1', email: 'user1@example.com' },
{ username: 'user2', email: 'user2@example.com' }
]);
EOF
Kafka CLI にアクセスする
-- CREATE TABLE IF NOT EXISTS test (id SERIAL PRIMARY KEY, name VARCHAR(50));
BEGIN;
-- structure setup
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(50) NOT NULL,
email VARCHAR(100) NOT NULL
);
-- data setup
INSERT INTO users (username, email)
VALUES ('user1', 'user1@example.com');
INSERT INTO users (username, email)
VALUES ('user2', 'user2@example.com');
COMMIT;
このセットアップでは、Docker Compose と環境変数、bitnami イメージ、およびボリューム マッピングを使用して、再現可能な開発環境を作成します。 docker-compose up -d を使用すると、docker-compose down で環境全体をすばやくスピンアップまたは破棄できるため、ローカルの開発とテストに適しています。
以上がDocker Compose を使用して MySQL、PostgreSQL、MongoDB、Redis、Kafka の開発環境を迅速に開始するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
