docker-compose WordPress 세팅 – 1부. mariadb 설정

서비스는 하나인데 사용해야 하는 컨테이너가 여러 개인 경우 매번 각종 도커 명령어를 사용하는 것은 말도 못하게 번거롭습니다. docker-compose WordPress 설정 방법을 알아보겠습니다. docker build, docker run, docker stop, docker rm, docker restart 등의 명령어를 docker-compose 하나로 조금 더 편하게 관리해 봅시다.

docker-compose WordPress 설정하기

WordPress를 이용하려면 Database도 필요하고, WordPress를 구동하는 웹 서버도 필요합니다. 웹서버는 php로 구동되어야 합니다. 여기에서는 php-fpm WordPress docker image와 mariadb docker image 그리고 nginx docker image를 활용할 것입니다. docker-compose WordPress 설정 과정을 보여드리겠습니다.

docker 개별 컨테이너로 이용할 때의 문제점

제가 처음에는 바로 쉘 스크립트로 docker 명령어들을 작성해서 보관하기 시작했는데, 컨테이너 개수가 늘어나면서 관리할 쉘 스크립트도 덩달아서 늘어나고, 스크립트 내에서 사용하는 환경 변수들에 대한 처리 문제도 덩달아 발생했습니다. 너무도 관리하기가 번거로워졌습니다. 조금 더 편하게 관리할 수 있는 도구는 없을까 하던 차에 docker-compose를 알게 됐습니다.

docker-compose 이용의 이점

docker-compose를 사용하면 build부터 컨테이너를 띄우는 순서까지 모두 결정할 수 있으며 docker-compose up -d 라는 명령어 한 줄이면 docker-compose.yml에 설정된 모든 컨테이너를 한 번에 바로 띄울 수 있습니다.

docker-compose 설정 파일은 YAML을 사용하여 서비스, 네트워크, 볼륨 등을 설정할 수 있습니다. 간단한 시나리오를 짠 후에 docker-compose 파일을 설정해 보겠습니다.

워드프레스로 웹 사이트를 운영할 것이고, 데이터 베이스는 mariadb를 사용하고, 웹 서버는 nginx를 사용할 것입니다. 본 포스팅에서는 우선 mariadb에 대한 docker-compose 파일 설정을 먼저 해 볼 것입니다.

docker 버전

그에 앞서 docker 버전 이야기를 먼저 하려고 합니다. docker-compose는 docker 엔진 버전에 따라 docker-compose 파일 버전을 맞추어 설정해야 합니다. 만일 도커 엔진 버전이 낮으면 해당 엔진 버전에 상응하는 docker-compose 파일 버전 이상을 사용할 수 없습니다. 따라서 docker-compose를 사용하려면 현재 자신이 사용하는 도커 엔진의 버전을 확인하고 적용할 수 있는 docker-compose 파일 버전을 확인한 후 사용해야 합니다.

도커 버전은 다음의 명령어로 확인할 수 있습니다.

docker --version
ShellScript

일례로 필자가 사용중인 도커 엔진은 1.12 버전입니다. 이 경우 docker-compose 파일 버전은 2.1까지 사용할 수 있습니다. 자신이 사용하는 도커 버전을 확인한 후, Docker 홈페이지의 Compose file versions and upgrading 페이지에서 자신이 사용할 수 있는 docker-compose 파일 버전을 확인한 후 활용하면 됩니다.

그림 1. docker compose 파일 버전과 docker engine 배포버전 호환성 표
그림 1. docker compose 파일 버전과 docker engine 배포버전 호환성 표

물론 버전에 따라 사용할 수 있는 문법의 지원 정도에 차이가 있는 것은 당연하며, 도커 엔진 버전에 상응하는 docker-compose 파일 버전보다 높은 버전으로 설정하면 오류가 발생합니다.

docker-compose.yml 파일에 다음과 같이 적어주면 docker-compose 파일의 버전 설정이 끝납니다.

version: '2.1'
YAML

docker-compose의 version은 deprecated(2023.1.21추가)

docker-compose의 version 정보는 이제 사용하지 않는다고 합니다. 아직 예전 docker를 사용하는 분들은 version을 이용하셔야겠지만, Docker 홈페이지의 Compose Spec 문서를 확인했더니 아래와 같이 이제 docker compose의 version은 deprecated이며 legacy라고 나옵니다. 정말 유물이 되어 버렸네요. 심지어 이젠 설정파일도 compose.yaml이나 compose.yml을 이용하라고 합니다. 하핫! docker- 치기 귀찮은 개발자의 마음이 느껴집니다.

그림 2. Docker compose의 version은 deprecated
그림 2. Docker compose의 version은 deprecated

Version and name top-level element 페이지 변경(2025.5.18 추가)

2024년 5월 18일에 확인한 바에 의하면 문서에 변화가 생겼습니다. Version and name top-level element 페이지에서는 version은 정보 제공용으로만 사용되며 더 이상 사용하지 않는다고 알려줍니다. version을 이용한다면 docker 컨테이너를 구동할 때 아래와 같이 `version` is obsolete이라는 문구를 만나게 됩니다.

그림 3. version is obsolete 메시지
그림 3. version is obsolete 메시지

MariaDB 서비스 설정

이제 mariadb 컨테이너에 대한 설정을 해보겠습니다. services는 띄울 컨테이너 서비스들을 모아서 설정하는 곳입니다. 자신이 띄울 서비스의 이름을 적어주면 됩니다. 저는 mariadb라고 적어주었습니다.

version: '2.1'
services:
  mariadb:
YAML

image

아래의 설정은 mariadb:10.2.10이라는 docker image를 사용해서 컨테이너를 만들 것이라고 알려주는 겁니다.

version: '2.1'
services:
  mariadb:
    image: mariadb:10.2.10    # <- 컨테이너 만들 이미지 지정
YAML

container_name

식별하기 쉬운 컨테이너 이름을 지정해 줍니다. 지정해 주지 않으면 임의의 컨테이너 이름이 생성됩니다. 여기에서는 mydb라고 컨테이너 이름을 지어 보겠습니다.

version: '2.1'
services:
  mariadb:
    image: mariadb:10.2.10
    container_name: mydb       # <- 컨테이너 이름 지정
YAML

restart

그리고 docker container 재시작 옵션을 always로 하겠다는 것은 컨테이너 종료 상태와 상관없이 항상 재시작하겠다는 것입니다. 이 옵션을 설정해 두면, PC을 껐다 켠 후에도 컨테이너가 자동으로 뜨는 것을 확인할 수 있습니다. 그리고 컨테이너가 죽었을 때에도 계속 컨테이너를 구동하기 위해 시도합니다.

version: '2.1'
services:
  mariadb:
    image: mariadb:10.2.10
    container_name: mydb
    restart: always       # <- 컨테이너 재시작 설정
YAML

environment

그 다음은 enviroment 옵션입니다. environment에서 설정한 값은 컨테이너에서 환경변수로 사용하게 됩니다. 아래의 예제에서는 MYSQL_ROOT_PASSWORD를 mypassword로 설정해 주었습니다.

version: '2.1'
services:
  mariadb:
    image: mariadb:10.2.10
    container_name: mydb
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=mypassword   # <- 비밀번호 설정
YAML

여기에서 잠깐! 위에서 사용한 MYSQL_ROOT_PASSWORD는 생성될 컨테이너에서 사용하게 되는 환경변수입니다. git과 같은 버전관리 도구를 사용하면서 docker-compose.yml 파일을 커밋하고 푸시하면, DB의 root 패스워드가 노출되는 문제가 생깁니다. 따라서 위와 같이 비밀번호를 docker-compose.yml 파일에 직접 입력하는 것은 위험할 수 있으며, 별도의 환경변수 설정 파일인 .env 파일에 설정을 해 주시는 편이 안전합니다.

docker-compose는 기본적으로 .env 파일을 환경변수 파일로 인식합니다. 필요한 변수를 .env에 설정해 주고, compose.yml 파일에서는 ${환경변수명}과 같은 형식으로 사용할 수 있습니다. 그리고 git 저장소를 사용하는 경우 .gitignore에 .env 파일을 추가해서 저장소에 들어가지 않게 해 주어야 합니다. 또한 보안상 위험할 수 있으니 .env 파일은 저장소에 커밋하지 않으시길 바랍니다.

아래의 .env 파일에는 MYSQL_PW라는 환경변수에 mypassword라는 비밀번호를 설정한 내용입니다. MYSQL_PW라는 환경변수는 컨테이너에서 사용하는 것이 아니라, compose.yaml에서 사용하는 환경변수입니다.

MYSQL_PW=mypassword
.env

아래에는 위에서 설정했던 compose.yaml을 환경변수 ${MYSQL_PW}를 사용하도록 변경한 내용은 아래와 같습니다.

version: '2.1'
services:
  mariadb:
    container_name: mydb
    image: mariadb:10.2.10
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_PW}   # <-환경변수 사용
YAML

이제 docker-compose.yml 파일을 안심하고 커밋해도 됩니다.

volumes

그리고 구동중인 도커 컨테이너를 정지하고 삭제하면 당연히 컨테이너의 내용은 모두 사라집니다. DB을 보존하기 위해서는 호스트 경로로 저장되도록 설정해야 합니다. volumes 옵션을 통해서 Host 경로를 Container 경로로 마운팅할 수 있습니다. 콜론(:)을 중심으로 왼쪽은 호스트 경로, 오른쪽은 컨테이너 경로입니다.

version: '2.1'
services:
  mariadb:
    image: mariadb:10.2.10
    container_name: mydb
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_PW}
    volumes:   # <- 볼륨 설정
      - /Users/aaaa/con_volumes/mariadb/data:/var/lib/mysql
      - /Users/aaaa/con_volumes/mariadb/conf.d:/etc/mysql/conf.d
YAML

컨네이너 내의 /var/lib/mysql 경로는 DB가 저장되는 경로이고, /etc/mysql/conf.d는 mysql 환경설정을 별도로 오버라이딩 하기 위한 경로이다.

도커를 띄우기 전에 /Users/aaaa/con_volumes 디렉토리를 생성해 줘야 합니다. /Users/aaaa는 MacOS의 사용자 디렉토리를 의미합니다. Host의 con_volumes 디렉토리 하위의 mariadb 이후 경로는 도커가 알아서 생성해 줍니다.

con_volumes 대신에 컨테이너에 연결시킬 볼륨 디렉토리를 자신이 원하는 이름으로 지정해 주면 됩니다. 저는 con_volumes로 만들어 보겠습니다.

mkdir con_volumes
ShellScript

추가로 환경변수로 추출할 부분을 찾으셨을까요? 바로 volumes에서 호스트의 경로 설정 부분입니다. 컨테이너는 동일한 환경으로 구축해야 하지만, 로컬의 호스트는 사용자마다 다를 수 있습니다. 각자가 원하는 환경에서 도커를 구동하기 원하겠죠? 그래서 다음과 같이 환경 변수들을 추출하고, 설정파일 .env와 docker-compose.yml을 각각 다음과 같이 변경하였습니다.

MYSQL_PW=mypassword
MYSQL_DATA_PATH=/Users/aaaa/con_volumes/mariadb/data
MYSQL_CONFIG_PATH=/Users/aaaa/con_volumes/mariadb/conf.d
.env
version: '2.1'
services:
  mariadb:
    container_name: mydb
    image: mariadb:10.2.10
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_PW}
    volumes:
      - ${MYSQL_DATA_PATH}:/var/lib/mysql
      - ${MYSQL_CONFIG_PATH}:/etc/mysql/conf.d
YAML

이제 어느 개발자의 머신에서든 서버에서든 각자의 경로에 맞게 설정할 수 있습니다.

컨테이너 구동

docker-compose wordpress 컨테이너 구동

이제 docker compose 명령어로 컨테이너를 띄워보겠습니다.

docker compose up -d
ShellScript

docker compose문을 이용해서 구동하면 아래와 같이 구동 결과가 나옵니다.

그림 4. docker-compose wordpress 설정을 위한 mariadb 구동
그림 4. docker-compose wordpress 설정을 위한 mariadb 구동

docker-compose 플러그인 도입으로 docker compose 명령 사용(2023.1.21추가)

docker engine 설치 문서를 확인해 보니 docker engine 설치시에 플러그인으로 함께 설치할 수 있게 되어 있습니다. 플러그인 통합 설치하신 분들은 docker-compose 명령 대신에 docker compose 명령을 이용하시면 됩니다.

현재 제가 사용하는 장비에서도 docker-compose를 입력하면 command not found: docker-compose가 뜹니다. 하지만 운영 중인 서버에서는 아직도 docker-compose를 사용하는 것도 있습니다. 그러니 모두 알아둘 필요가 있겠죠.

컨테이너 구동 과정

docker compose up -d 명령을 사용하면, 기본적으로 .env 파일에서 환경변수를 읽어들이고, docker-compose.yml 파일을 찾아서 컨테이너를 띄우게 됩니다. 만약 docker-compose.yml 파일을 사용하지 않고 파일이름을 특정하고 싶다면 자신이 원하는 파일이름으로 저장한 후,  docker-compose -f FILENAME.yml up -d이라고 해 주면 됩니다.

docker-compose의 up 명령어는 컨테이너를 새로 생성하고 띄우라는 것이며, -d는 background 모드로 실행하겠다는 것입니다. 이제 컨테이너가 작동하는지 확인해 보겠습니다.

docker-compose ps
ShellScript

docker compose ps 명령을 실행하면 아래와 같이 컨테이너 mydb가 잘 떠있는 것을 확인할 수 있습니다. 컨테이너 내에 3306번 포트로 mariadb 10.2.10이 잘 구동되고 있는 것을 볼 수 있습니다.

그림 5. 구동된 mariadb 컨테이너 mydb 확인
그림 5. 구동된 mariadb 컨테이너 mydb 확인

일단 docker-compose WordPress 설정하기의 첫 포스팅은 mariadb 설정으로 마치겠습니다.

docker-compose 사용하기 – 2부. wordpress, nginx 설정에서 본편에 이어서 wordpress와 nginx 설정을 차례로 진행해 보겠습니다.

같이 읽으면 좋은 글

2 thoughts on “docker-compose WordPress 세팅 – 1부. mariadb 설정”

  1. 안녕하세요,도움이 되는 글을 작성해주셔서 감사합니다

    일단 저는 시놀로지를 사용하고있고 코드 따라하는 수준으로 컨테이너(도커)를 이용해 compose파일을 업로드하여 구동하려합니다만,이해가 되지 않는 부분이 있어,괜찮으시다면 질문 좀 드려도 될까요? 설명6.2/6.3부분에서 “비밀번호를 env에 설정해주고 .gitignore에 추가”하라하셨는데 이 부분을 yml에서 어찌 설정해줘야하나,좀 어렵네요,이 부분을 초보자가 따라 할 수 있는 글이나,설명을 좀 받을 수 있을까요?

    응답
    • 6.2에서 설명해 드린 바와 같이 예를 들어 .env 파일에 설정한 환경변수 MYSQL_PW는 compose.yml에서 ${MYSQL_PW}와 같이 사용할 수 있습니다. .gitignore에 .env 파일을 추가해야 한다고 이야기한 부분은 개별 환경변수에 중요한 비밀번호나 API KEY 같은 게 들어가는 경우 .env파일이 git 저장소에 올라가면 보안상 안전하지 않기 때문에 .env 파일을 .gitignore에 추가해 주라고 설명한 것입니다. 혹여나 버전관리를 별도로 하지 않으신다면, .gitignore 설정 부분은 무시하셔도 됩니다. 일단 6.2 파트의 본문을 조금 더 이해하기 쉽게 고쳐보겠습니다. 혹시 본 답변으로도 이해가 안 되시면 추가 질문해 주세요.

      응답

Leave a Comment