현재 상황

docker compose 파일을 이용해 프로젝트 팀원들간 개발환경을 통일하여 개발중었다.

docker-compose.yml 과 개발환경에서만 사용중인 docker-compose-dev.yml 파일을 이용해

컨테이너 실행시

dev 파일이 docker-compose.yml 파일을 재정의(override) 하게끔 (의도했지만 실제로 바뀌는것은 없게 설계했다 판단했다.) 설정했다.

docker-compose.yml

version: '3'

services:
  django:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: dp
    networks:
      - dp

    restart:
      on-failure
    depends_on:
      - mysql
      - neo4j

  neo4j:
    container_name: neo4j
    image: neo4j:latest
    networks:
      - dp

  mysql:
    container_name: mysql
    image: mysql
    volumes:
      - ./vol:/var/lib/mysql
    networks:
      - dp
    command:
      - --character-set-server=utf8
      - --collation-server=utf8_general_ci

networks:
  dp:
    driver: bridge

docker-compose-dev.yml

services:
  django:
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    environment:
      - NEO4j_PASSWORD=neo4j1234
      - MYSQL_DATABASE=dp
      - MYSQL_HOST=mysql
      - MYSQL_PASSWORD=1234
      - JWT_SECRET=secret
    env_file:
      - .env-s3
    command:
      - /bin/bash
      - -c
      - |
        dos2unix /app/wait-for-services.sh
        ./wait-for-services.sh python3 manage.py makemigrations
        python3 manage.py migrate 
        python3 manage.py runserver 0.0.0.0:8000
  

  neo4j:
    ports:
      - "7474:7474"
      - "7473:7473"
      - "7687:7687"
    volumes:
      - ./neo4j-volume/data:/data
      - ./neo4j-volume/logs:/logs
    environment:
      NEO4J_AUTH: neo4j/neo4j1234

  mysql:
    volumes:
      - ./mysql-volume/mysql:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=1234
      - MYSQL_DATABASE=dp
    ports:
      - "3306:3306"

문제 발생

팀원이 docker-compose 를 실행하면서 내가 의도한

# 1번
docker-compose -f docker-compose.yml -f docker-compose-dev.yml up -d --build

를 사용하지 않고

# 2번
docker-compose -f docker-compose-dev.yml -f docker-compose.yml up -d --build

를 이용하여 개발을 진행 해왔고

내가 팀원의 환경에서 docker-compose를 실행하고 (1번 방법) 데이터베이스를 보니

원래 있어야 할 데이터가 존재하지 않고 다른 데이터 베이스가 잡히는 것이다…

심지어 릴레이션 구조 까지 달라서 많이 당황했다

우리는 django를 사용중이기 때문에 데이터베이스와 model이 다르다면 릴레이션을 바로 마이그레이션 해주게 코드를 작성했었다.

command:
  - /bin/bash
  - -c
  - |
    dos2unix /app/wait-for-services.sh
    ./wait-for-services.sh python3 manage.py makemigrations // <- 요부분
    python3 manage.py migrate 
    python3 manage.py runserver 0.0.0.0:8000

하지만 실제 테이블 구조가 모델과 다른데도 마이그레이션이 안먹었다.

팀원도 이런적은 처음이라 당황해서 해결방법을 찾지 못했다.

문제 해결

첫번째 : 다른 데이터 베이스 조사

처음엔 다른 데이터 베이스 (예를 들면 같은 도커 네트워크 데이터 베이스가 아닌 로컬 데이터 베이스) 에 연결된줄 알고 다른 데이터 베이스의 유무를 조사 했다.

하지만 다른 데이터베이스는 우리가 잘못 잡은 데이터베이스에 존재 하지 않았다…

두번째(해결) : 볼륨 삭제후 재 빌드

아무래도 -f 옵션을 사용하며 볼륨같은게 꼬였는지 싶어서 볼륨을 삭제 하고 모든 데이터 베이스를 날리고 다시 빌드 했다.

그러니 잘됐다?!

근본 적인 원인

나중에 알고 보니 근본적인 원인은 -f 옵션을 사용한 속성 재정의 기능 때문에 그런 것이었다.

물론 내가 1번 방법으로 빌드해야한다 팀원들에게 고지 했지만

이미 개발을 막힘없이 진행중이던 팀원은 2번 방법으로 개발을 진행했고 docker-compose.yml 로 재정의 된 속성중 volume 속성이

# docker-compose.yml 속 mysql volumes 

volumes:
  - ./vol:/var/lib/mysql

위와같이 재정의 되어 내가 팀원의 환경에서

-f docker-compose.yml -f docker-compose-dev.yml 로 컨테이너를 실행시켜

# docker-compose-dev.yml 속 mysql volumes

volumes:
  - ./mysql-volume/mysql:/var/lib/mysql

위 속성이 사용되어 볼륨이 꼬였던 것이다…