Docker Compose를 사용하여 MySQL, PostgreSQL, MongoDB, Redis 및 Kafka용 개발 환경을 빠르게 시작하세요.

Docker Compose와 bitnami 이미지를 사용하여 MySQL, PostgreSQL, MongoDB, Redis 및 Kafka로 개발 환경을 빠르게 설정하는 방법은 다음과 같습니다. , 환경 변수 및 각 데이터베이스에 대한 UI 도구입니다. 프로세스를 단계별로 살펴보겠습니다.

비트나미 이미지를 사용하는 이유는 무엇입니까?

1. 사전 구성 및 최적화: Bitnami 이미지는 모범 사례로 사전 구성되어 제공되므로 일반적인 사용 사례에 맞게 설정하고 최적화하기가 더 쉽습니다.

2. 보안: Bitnami는 취약점을 해결하기 위해 정기적으로 이미지를 업데이트하여 자주 업데이트되지 않을 수 있는 일부 커뮤니티 유지 이미지에 비해 더 안전한 옵션을 제공합니다.

3. 환경 간 일관성: Bitnami는 이미지가 다양한 환경에서 일관되게 작동하도록 보장하여 테스트, 개발 및 생산 설정에 적합한 선택이 됩니다.

4. 사용 편의성: 배포를 단순화하는 스크립트와 기본값이 포함되어 있어 수동 구성 및 설정의 필요성이 줄어드는 경우가 많습니다.

5. 문서 및 지원: Bitnami는 모회사인 VMware를 통해 자세한 문서와 때로는 지원을 제공하며 이는 문제 해결 및 기업 사용에 유용할 수 있습니다.

또 다른 가져오기 참고 사항은 라이선스에 관한 것으로, 다를 수 있지만 bitnami 소프트웨어는 일반적으로 무료로 사용할 수 있으며 해당 컨테이너와 패키지는 오픈 소스 소프트웨어를 기반으로 하며 MIT, Apache 2.0 또는 GPL과 같은 라이선스를 사용합니다... 자세히 보기 오픈소스 라이선스 정보

1단계: Docker 및 Docker Compose 설치

1. Docker 설치: 공식 Docker 설명서에서 해당 OS에 대한 지침을 따르세요.
2. Docker Compose 설치: Docker Compose 설치 가이드의 지침을 따르세요.

2단계: 프로젝트 구조

다음과 같은 프로젝트 구조를 만듭니다.

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

3단계: (.env) 파일

다음 콘텐츠로 .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=./

4단계: (docker-compose.yml) 파일

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

5단계: 스크립트

scripts 폴더에 필요한 스크립트를 생성하세요.

1. 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
         }
       }
     }
   

2. 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."
   

3. 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
   

4. 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;
   

5. 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;
   

6단계: Docker Compose 실행

터미널에서 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

이 명령은 정의된 대로 자체 컨테이너, 포트 및 환경 구성을 사용하여 모든 서비스를 시작합니다.

7단계: UI 도구를 사용하여 데이터베이스에 액세스

• phpMyAdmin: http://localhost:280을 통해 액세스
• Mongo Express: http://localhost:28081을 통해 액세스
• pgAdmin 4: http://localhost:281을 통해 액세스
• Redis Commander: http://localhost:28082를 통해 액세스
• Kafka UI: http://localhost:28080을 통해 액세스

각 UI 도구는 해당 데이터베이스 컨테이너에 연결되도록 이미 구성되어 있습니다.

8단계: CLI를 통해 액세스

우선 .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=./

• grep -v '^#' .env: .env 파일에서 주석(#으로 시작하는 줄)을 필터링합니다.
• xargs: 각 줄을 키=값 쌍으로 변환합니다.
• 내보내기: 변수를 현재 환경에 로드하여 세션에서 사용할 수 있도록 합니다.

1. MySQL CLI 접속

   • dev-mysql 컨테이너 내부의 MySQL 데이터베이스에 액세스하려면:

   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
   
   

2. PostgreSQL CLI에 액세스

   • dev-postgresql 컨테이너 내부의 PostgreSQL 데이터베이스에 액세스하려면:

       {
       "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
         }
       }
     }
   

3. MongoDB CLI 접속

   • dev-mongodb 컨테이너 내부의 MongoDB 셸에 액세스하려면:

   # 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."
   

4. Redis CLI 접속

   • dev-redis 컨테이너 내부의 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
   

5. Kafka CLI 접속

   • dev-kafka 컨테이너 내부에서 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를 사용하여 재현 가능한 개발 환경을 만듭니다. docker-compose up -d를 사용하면 docker-compose down으로 전체 환경을 신속하게 스핀업하거나 해체할 수 있어 로컬 개발 및 테스트에 적합합니다.

위 내용은 Docker Compose를 사용하여 MySQL, PostgreSQL, MongoDB, Redis 및 Kafka용 개발 환경을 빠르게 시작하세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!