Docker 데몬 전역 설정으로 개발 환경 통일하기

Docker 데몬 전역 설정으로 팀 개발 환경 통일하기

로컬에서든 서버에서든 Docker를 쓰다 보면, 프로젝트마다 docker-compose.yml에 같은 설정을 계속 복붙하게 됩니다.

DNS를 항상 1.1.1.1, 8.8.8.8로 맞춘다거나
로그 드라이버를 json-file + max-size=10m으로 고정한다거나
프록시, insecure registry, 기본 네트워크 대역 등…

이런 것들은 컨테이너 개별 설정이 아니라 “호스트 전체 기본값” 으로 빼버리면 훨씬 관리가 쉽습니다. 그 역할을 하는 게 바로 Docker 데몬 전역 설정(daemon.json) 입니다.

아래에서:

어떤 파일을
어디에 만들고
어떻게 작성해야 하는지
어떤 상황에서 어떤 개발자/팀에게 유용한지

를 정리해보겠습니다.

1. Docker 데몬 설정 방식 두 가지

Docker 데몬(dockerd)은 크게 두 가지 방식으로 설정할 수 있습니다.

JSON 설정 파일(daemon.json) 사용 ← 권장
dockerd 실행 시 CLI 플래그로 옵션 전달

둘을 섞어 쓸 수는 있지만, 같은 옵션을 둘 다에서 지정하면 데몬이 아예 뜨지 않습니다. 예를 들어 --log-driver 플래그와 daemon.json 모두에 로그 드라이버를 넣어버리면 Docker가 시작 단계에서 에러를 내고 죽습니다.

팀/서버 환경 통일을 위해서는 보통:

“가능한 한 daemon.json에 다 모으고, 플래그는 최소한으로만”

하는 걸 추천합니다.

2. `daemon.json` 위치 정리

OS·설치 방식별 기본 위치를 한 번에 보기 좋게 표로 정리하면 다음과 같습니다:

환경	기본 경로	비고
Linux (일반 설치)	`/etc/docker/daemon.json`	가장 흔한 케이스
Linux (snap으로 설치한 Docker)	`/var/snap/docker/current/config/daemon.json`	Ubuntu snap 패키지
Windows Server / Docker Engine	`C:\ProgramData\Docker\config\daemon.json`	관리자 권한 필요할 수 있음
Docker Desktop (Mac / Windows)	`~/.docker/daemon.json`	Desktop 설정의 내부 실제 경로

이 파일은 기본으로 없을 수 있으므로, 없으면 직접 생성해서 사용하면 됩니다.
팀/서버 표준을 다룰 땐 보통 리눅스 서버의 /etc/docker/daemon.json 을 기준으로 설명하는 게 실무에 잘 맞습니다.

3. 기본 사용 패턴: “파일 만들고 → 데몬 재시작”

Linux 기준으로 가장 흔한 워크플로우는 이렇습니다.

daemon.json 작성/수정

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

설정 파일이 유효한지 미리 검증

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# configuration OK 가 나오면 정상 :contentReference[oaicite:7]{index=7}

Docker 데몬 재시작

sudo systemctl restart docker

이제부터 새로 뜨는 컨테이너는 별도 설정이 없는 한 이 전역 설정들을 기본값으로 상속 받습니다.

4. 예제 1 – DNS 서버를 전역으로 고정하기

4.1 왜 DNS를 전역으로?

컨테이너가 “이상하게 외부 API를 못 찾는다” “내부 도메인이 안 풀린다” 같은 문제를 자주 만난다면, 대부분 호스트의 DNS 설정/환경에 의존하고 있기 때문입니다.

예를 들어:

팀 전체가 Cloudflare DNS( 1.1.1.1 )를 쓰고 싶다
회사 내부 DNS 서버를 통해서만 열리는 엔드포인트가 있다

이런 경우 매 프로젝트마다 docker-compose.yml에 dns:를 넣기보다는, 아예 Docker 데몬 단계에서 통일하는 게 훨씬 편합니다.

4.2 설정 예제 (`daemon.json`)

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

기존 daemon.json이 있다면, 루트 { ... } 안에 "dns": [...] 항목을 추가하면 됩니다. (쉼표 위치만 주의)

⚠️ 주의: DNS 설정은 컨테이너 안에서 /etc/resolv.conf에 반영됩니다. 이미 떠 있는 컨테이너에는 바로 적용되지 않고, 새로 띄우는 컨테이너부터 적용됩니다.

4.3 어떤 사람에게 유용한가?

사내 프록시·내부 DNS가 있는 회사 개발자
멀티 클라우드 환경에서 특정 DNS를 강제해야 하는 플랫폼 팀
로컬에서 여러 VPN을 오가며 개발하는 개인 개발자

5. 예제 2 – 로깅 드라이버 & 옵션 전역 설정

컨테이너 로그는 기본적으로 json-file 드라이버를 통해 /var/lib/docker/containers/... 아래에 쌓입니다. 이를 전역에서 바꾸면:

로그 포맷
로그 저장 위치
로그 로테이션 정책

을 컨테이너 전체에 일괄 적용할 수 있습니다.

5.1 기본 json-file 드라이버 + 로테이션

가장 흔한 패턴은 “그냥 json-file 쓰되, 디스크 안 터지게 로테이션 설정”입니다.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

이렇게 해두면:

컨테이너당 로그 파일 크기가 최대 10MB이고
최대 5개까지만 유지되고
초과분은 자동 삭제됩니다.

5.2 중앙 로그 수집용 드라이버 (fluentd, journald 등)

플랫폼 팀/인프라 팀이라면, 모든 컨테이너의 로그를 중앙 로깅 시스템에 보내고 싶을 때가 많습니다.

예를 들어 Fluentd를 사용한다면:

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

이렇게 해두면, 별도의 docker run --log-driver=... 없이도 모든 컨테이너의 로그가 자동으로 Fluentd로 전송됩니다.

개인적으로는 journald 드라이버도 꽤 좋아합니다. systemd 기반 리눅스 환경이라면 애플리케이션 로그와 Docker 컨테이너 로그를 모두 journald 한 군데로 모아서, journalctl만으로 조회·필터링·보존 정책을 통일할 수 있기 때문입니다.

journald를 전역 로그 드라이버로 쓰고 싶다면 예를 들어 이렇게 설정할 수 있습니다:

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

여기서 tag를 컨테이너 이름으로 쓰고 있기 때문에:

journalctl -f | grep {container_name} 형태로 실시간 로그를 빠르게 훑어볼 수 있고
--since "10m ago" 같은 옵션을 조합해서 특정 시점 이후 로그만 볼 수도 있으며
journalctl -f -t {container_name}처럼 -t 옵션(태그/식별자 기준)을 써서 특정 컨테이너 로그만 딱 집어서 볼 수도 있습니다.

물론 journalctl -u docker.service 같이 유닛 단위로 보는 것도 가능하지만, 컨테이너 이름 기준으로 필터링하는 게 더 직관적이고, 타이핑도 짧아서 실무에선 훨씬 자주 쓰게 됩니다.

5.3 Compose / `docker run`과의 관계

전역 log-driver + log-opts 는 “기본값” 역할
개별 컨테이너에서 logging: (Compose) 혹은 --log-driver, --log-opt(CLI)를 지정하면 그 컨테이너만 override

전략적으로:

공통값은 daemon.json에
특수한 서비스만 개별 override

하는 구성을 추천합니다.

6. 예제 3 – 프록시, insecure registry 등 전역 네트워크 설정

전역 설정에서 자주 쓰이는 또 다른 옵션들이 있습니다.

6.1 프록시 설정

사내 프록시를 통해서만 외부에 나갈 수 있는 경우, 매번 환경변수를 넣기보다 데몬 수준에서 프록시를 설정할 수 있습니다.

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

이렇게 하면 Docker 데몬이 이미지를 풀 때나, 빌드 시 네트워크를 사용할 때 이 프록시 설정을 따라갑니다.

6.2 insecure registry

TLS가 없는 레지스트리를 꼭 써야 하는 상황이라면(내부 개발용 등):

{
  "insecure-registries": ["my-registry.local:5000"]
}

보안상 위험할 수 있으니, 내부 테스트 환경에서만 사용하도록 주의해야 합니다.

7. 예제 4 – 기본 네트워크 대역, 스토리지 드라이버 등

조금 더 인프라스러운 옵션들:

7.1 기본 bridge 네트워크 대역 커스터마이징

VPN이나 사내 네트워크와 IP가 겹치는 것을 피하고 싶을 때:

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

이렇게 하면 Docker가 새 bridge 네트워크를 만들 때 10.20.x.0/24 대역을 사용합니다.

7.2 스토리지 드라이버 강제

리눅스 배포판에 따라 기본 스토리지 드라이버가 달라질 수 있습니다. 팀에서 overlay2만 쓰기로 했다면:

{
  "storage-driver": "overlay2"
}

실제 지원 가능한 스토리지 드라이버는 OS/커널에 따라 다르므로, dockerd 문서와 배포판 가이드를 꼭 확인해야 합니다.

8. 언제, 누구에게 특히 유용한가?

8.1 개인 개발자

여러 사이드 프로젝트에서 항상 비슷한 Docker 옵션을 쓰는 사람
VPN, 사내 프록시 등 네트워크 환경이 자주 바뀌는 상황
로그/디스크 관리가 번거로운 로컬 개발 머신

→ daemon.json 하나로 환경 통일 + 반복 설정 제거를 할 수 있습니다.

8.2 작은/중간 규모 개발팀

팀원들마다 다른 로컬 Docker 설정 때문에 “내 PC에선 되는데?”가 자주 터질 때
CI 서버와 개발자 로컬 환경의 네트워크/로그 설정을 최대한 맞추고 싶을 때
사내 표준 DNS·프록시·레지스트리 사용을 강제하고 싶을 때

→ “우리 팀의 Docker 기본값은 이거다”라는 팀 규약을 daemon.json으로 정의해두면 좋습니다. (Ansible, Chef, Terraform, Cloud-Init 등으로 이 파일을 배포하면 더 깔끔합니다.)

8.3 플랫폼 팀 / DevOps / SRE

수십~수백 개 컨테이너를 돌리는 노드에서
로그, 스토리지, 네트워크 정책을 일관되게 관리해야 할 때
로그 수집, 모니터링, 보안 규칙 등을 호스트 기준으로 표준화해야 할 때

→ daemon.json은 사실상 “Docker Node의 정책 파일” 역할을 하게 됩니다.

9. 디버깅 팁

플래그와 중복 설정 - systemd unit 파일 (/lib/systemd/system/docker.service 등)에 이미 --log-driver 같은 플래그가 있는지 확인 - 같은 옵션이 플래그와 daemon.json에 함께 있으면 데몬이 실패합니다.
Docker Desktop에서는 GUI가 우선 - Desktop에서는 Settings(UI)에서 바꾸면 내부적으로 ~/.docker/daemon.json이 수정됩니다. - 직접 파일을 수정했다가 UI에서 다시 덮어쓸 수 있으니, 한쪽으로 통일하는 게 좋습니다.

정리

Docker의 전역 기본값은 daemon.json 에서 관리한다.
위치는 보통:
Linux: /etc/docker/daemon.json
Windows: C:\ProgramData\Docker\config\daemon.json
Docker Desktop: ~/.docker/daemon.json
대표적인 전역 설정 예:
DNS: "dns": ["1.1.1.1", "8.8.8.8"]
로그 드라이버: "log-driver": "json-file", "log-opts": {...}
프록시, insecure registry, 기본 네트워크 대역, 스토리지 드라이버…
전역 설정은:
개인 개발자에겐 “매번 설정 안 해도 되는 편리함”
팀/조직에겐 “환경 표준화와 장애 줄이기”를 가져다 줍니다.

docker-compose.yml이나 docker run에 똑같은 옵션을 계속 쓰고 있다면, 이제 한 번쯤은 daemon.json으로 끌어올릴 타이밍일지도 모릅니다.

image of docker daemon json setting

Docker 데몬 전역 설정으로 개발 환경 통일하기

1. Docker 데몬 설정 방식 두 가지

2. `daemon.json` 위치 정리

3. 기본 사용 패턴: “파일 만들고 → 데몬 재시작”

4. 예제 1 – DNS 서버를 전역으로 고정하기

4.1 왜 DNS를 전역으로?

4.2 설정 예제 (`daemon.json`)

4.3 어떤 사람에게 유용한가?

5. 예제 2 – 로깅 드라이버 & 옵션 전역 설정

5.1 기본 json-file 드라이버 + 로테이션

5.2 중앙 로그 수집용 드라이버 (fluentd, journald 등)

5.3 Compose / `docker run`과의 관계

6. 예제 3 – 프록시, insecure registry 등 전역 네트워크 설정

6.1 프록시 설정

6.2 insecure registry

7. 예제 4 – 기본 네트워크 대역, 스토리지 드라이버 등

7.1 기본 bridge 네트워크 대역 커스터마이징

7.2 스토리지 드라이버 강제

8. 언제, 누구에게 특히 유용한가?

8.1 개인 개발자

8.2 작은/중간 규모 개발팀

8.3 플랫폼 팀 / DevOps / SRE

9. 디버깅 팁

정리

유사한 게시물

Docker 대신 systemd.service? 리눅스에서 웹 애플리케이션 배포 전략 다시 보기

Django와 Tailwind CSS로 Docker 이미지 경량화: 멀티 스테이지 빌드 전략

Docker 빌드 속도를 높이는 Python Wheel의 이해와 활용

도커 볼륨(Volume) 복사, ‘왜’ 그렇게 해야 할까?

댓글 남기기

새 댓글 추가

1. Docker 데몬 설정 방식 두 가지

2. daemon.json 위치 정리

3. 기본 사용 패턴: “파일 만들고 → 데몬 재시작”

4. 예제 1 – DNS 서버를 전역으로 고정하기

4.1 왜 DNS를 전역으로?

4.2 설정 예제 (daemon.json)

4.3 어떤 사람에게 유용한가?

5. 예제 2 – 로깅 드라이버 & 옵션 전역 설정

5.1 기본 json-file 드라이버 + 로테이션

5.2 중앙 로그 수집용 드라이버 (fluentd, journald 등)

5.3 Compose / docker run과의 관계

6. 예제 3 – 프록시, insecure registry 등 전역 네트워크 설정

6.1 프록시 설정

6.2 insecure registry

7. 예제 4 – 기본 네트워크 대역, 스토리지 드라이버 등

7.1 기본 bridge 네트워크 대역 커스터마이징

7.2 스토리지 드라이버 강제

8. 언제, 누구에게 특히 유용한가?

8.1 개인 개발자

8.2 작은/중간 규모 개발팀

8.3 플랫폼 팀 / DevOps / SRE

9. 디버깅 팁

정리

유사한 게시물

Docker 대신 systemd.service? 리눅스에서 웹 애플리케이션 배포 전략 다시 보기

Django와 Tailwind CSS로 Docker 이미지 경량화: 멀티 스테이지 빌드 전략

Docker 빌드 속도를 높이는 Python Wheel의 이해와 활용

도커 볼륨(Volume) 복사, ‘왜’ 그렇게 해야 할까?

댓글 남기기

새 댓글 추가

2. `daemon.json` 위치 정리

4.2 설정 예제 (`daemon.json`)

5.3 Compose / `docker run`과의 관계