01
먼저 구조 오류를 해결하세요
YAML 유효성 검사에서 줄과 열을 확인하고, 명세 오류에서는 필드 경로를 따라가세요. 구조가 잘못된 상태의 관계 뷰를 완전한 결과로 사용하지 마세요. version 값은 과거 명세를 선택하는 스위치가 아닙니다.
Docker 및 컨테이너
Docker Compose 검증
Compose 문서 하나의 선언, 연결 관계, 아직 결정되지 않은 참조를 확인합니다.
Docker Compose 검증
Compose YAML 입력
분석 결과
YAML은 현재 브라우저에서 처리합니다. Docker 실행, 환경 파일 읽기, 네트워크 요청은 없습니다.
검토 옵션
입력은 보입니다. 출력을 표시하면 비밀값을 포함한 원래 값으로 YAML을 내보낼 수 있습니다.
정적 검사: Compose 스키마 fee041b (2026-09-01). 보간, 파일 읽기, profile 활성화, 컨테이너 실행은 하지 않습니다.
최대 200,000 UTF-16 단위, 서비스 100개, 관계 레코드 500개. 50개씩 표시합니다.
입력이나 옵션이 바뀌었습니다. 내보내기 전에 다시 분석하세요.
여러 서비스의 설정을 합칠 때 들여쓰기가 맞아도 같은 호스트 포트를 사용하거나 볼륨 선언을 빠뜨릴 수 있습니다. Docker Compose 검증은 이런 문제를 원문의 경로와 연결합니다. 입력을 그대로 두고 정리된 출력과 비교하면서 검토할 수 있으며, 결과는 실행 중인 컨테이너의 상태가 아니라 문서에 적힌 선언을 설명합니다.
Docker Compose 검증이 필요한 순간
설정 사이의 연결을 따라가기
Docker Compose 검증은 의존하는 서비스에서 의존 대상 서비스로 화살표를 표시합니다. depends_on의 긴 형식에 적힌 condition도 확인할 수 있습니다. 볼륨과 네임스페이스 관계를 함께 보되, 연결선만으로 데이터베이스가 준비되었다고 판단하지 않습니다.
충돌과 불확실성을 구분하기
컨테이너 포트가 달라도 고정 호스트 포트를 공유하면 충돌할 수 있습니다. TCP와 UDP는 분리하고 호스트 주소를 비교합니다. 범위 할당, 서로 다른 IP 계열의 와일드카드, profile에 따른 중첩은 실행 조건이 정해지지 않았으므로 가능성 경고로 남깁니다.
진단을 읽고 결과를 저장하는 순서
02
호스트 포트 매핑을 비교하세요
각 컨테이너가 내부에서 80을 쓰는 것은 문제가 아닙니다. 호스트 주소, published 포트와 프로토콜이 겹치는지 확인하세요. 변수나 자동 할당 포트는 임의의 숫자로 바꾸지 않고 미확정으로 표시합니다.
03
구성 값을 확인한 뒤 내보내세요
입력 원문은 보이지만 전체 출력은 처음에 숨겨집니다. 값 표시를 켜면 원래 값이 포함된 YAML을 복사할 수 있습니다. 자동 분석을 끄면 버튼이나 Ctrl/Cmd + Enter를 사용합니다. 수정 직후에는 이전 결과의 내보내기가 중지됩니다.
선언을 여러 관점에서 검토하기
고정 명세와 추가 관계 검사
2026-09-01 공식 스키마로 구조를 검사하고 누락된 서비스, 미선언 자원, 순환 의존성 및 포트 문법을 확인합니다. 알 수 없는 필드를 삭제하지 않고 표시합니다. 서식 정리는 주석과 앵커를 보존하며 서비스 순서나 입력을 덮어쓰지 않습니다.
서비스와 볼륨의 연결 표시
depends_on의 두 형식, 서비스 네임스페이스, links와 volumes_from 관계를 표시합니다. 명명된 볼륨은 최상위 선언과 비교합니다. bind 경로는 화면에 표시만 하며 실제 파일이 있는지 읽지 않습니다. 익명 볼륨은 별도로 구분합니다.
환경 변수는 참조 이름만 추출
문자열 값의 $VAR와 중괄호 표현식, 중첩 대체값을 읽고 $$ 이스케이프를 존중합니다. 값 없는 environment 항목은 셸 전달로 구분합니다. 템플릿은 중복 이름을 정렬해 NAME=만 출력하며 기본값이나 비밀번호를 복사하지 않습니다.
검토 목적에 맞는 출력
YAML에는 원래 값과 보간식이 남습니다. JSON 보고서는 전체 YAML과 변수 기본값을 제외하고 진단 경로와 관계를 보관합니다. 긴 결과는 50개씩 펼쳐 볼 수 있으며, 내보내기에는 문서화된 제한 안의 전체 결과가 포함됩니다.
실행 환경에서 별도로 확인할 사항
- 컨테이너를 실행하지 않습니다
- 이미지를 받거나 서비스를 시작하지 않고 포트나 상태 검사를 실행하지 않습니다. 구조가 유효해도 권한, 네트워크, 실제 Docker 버전에 따라 실패할 수 있습니다. 마지막 확인은 배포 환경에서 진행해야 합니다.
- 외부 파일을 해석하지 않습니다
- 단일 YAML 1.2 문서만 받습니다. 중복 키, 순환 별칭, 미지원 태그는 거부합니다. include와 extends는 외부 문맥이 필요하므로 구성 내보내기를 차단합니다. .env, env_file, 여러 override 파일의 병합은 처리하지 않습니다.
- 모든 profile을 함께 봅니다
- 현재 어떤 profile을 실행할지 선택하지 않습니다. 실제로 동시에 실행하지 않는 서비스도 중첩 경고를 받을 수 있습니다. 범위 포트와 미해결 변수는 확정된 호스트 점유로 해석하지 않으며, 다른 프로그램의 점유 상태도 조사하지 않습니다.
- 숨김은 파일 익명화가 아닙니다
- 원문은 입력 영역에 남습니다. 값 표시 후 저장하는 YAML에는 민감한 값도 그대로 들어가며 오류가 없어야 저장할 수 있습니다. ENV 템플릿의 값은 항상 비어 있습니다. 오류 보고서를 저장할 수 있다는 사실이 설정 승인을 의미하지 않습니다.
- 크기와 명세 버전이 고정됩니다
- 최대 200,000 UTF-16 단위, 100개 서비스, 500개 관계 레코드를 처리합니다. 앵커와 merge 확장은 20,000개 노드와 깊이 40으로 제한합니다. 명세 커밋은 fee041b로 시작하며 이후 추가된 필드는 스냅샷 갱신이 필요합니다.
- 선언 이상의 동작을 추측하지 않습니다
- bind, 명명된 볼륨, tmpfs를 주로 확인합니다. 다른 마운트 형식은 수동 검토를 안내합니다. 호스트 경로 존재 여부, 운영체제 권한, 서비스의 실제 준비 완료 시간은 계산하지 않습니다. 관계도는 실행 시뮬레이터가 아닙니다.
Docker Compose 검증 질문
docker-compose.yml 문법은 어디서 확인하나요?
이 작업대는 포함된 공식 스키마와 비교해 필드와 자료형 문제를 표시합니다. 서비스별 필드 의미는 Docker의 Compose 명세에서 확인하세요. 이 페이지가 사용하는 스냅샷과 설치된 Compose 버전은 다를 수 있으므로 최종 설정도 로컬에서 확인해야 합니다.
depends_on을 지정하면 준비될 때까지 기다리나요?
짧은 형식은 시작 의존성을 나타내며 애플리케이션이 요청을 받을 준비가 되었다는 뜻은 아닙니다. 긴 형식에는 service_healthy 같은 조건이 있습니다. 여기서는 그 선언만 보여 주며 실제 healthcheck를 실행하지 않습니다.
명명된 볼륨은 어디에 선언하나요?
서비스의 volumes 항목에서 사용하는 이름을 최상위 volumes에 선언합니다. 본 도구는 선언 여부를 비교하고 서비스에서 볼륨으로 향하는 관계를 보여 줍니다. 실제 엔진에 외부 볼륨이 존재하는지는 알 수 없습니다.
경로가 같은데 bind mount가 안 되는 이유를 알 수 있나요?
이 페이지는 경로 표기와 컨테이너 대상 경로를 확인할 뿐, 실제 호스트 디렉터리나 권한을 읽지 않습니다. 상대 경로 기준, 운영체제별 경로, Docker의 파일 공유 설정은 실행 환경에서 확인해야 합니다.
운영 환경 변수는 어떻게 관리하나요?
실제 비밀값은 운영 환경에 맞는 안전한 설정 공급원으로 관리하세요. 이 도구는 필요한 참조 이름을 모으고 빈 템플릿을 만드는 역할입니다. 기본값과 비밀번호를 템플릿에 복사하지 않지만, 전체 YAML 내보내기는 원래 값을 유지합니다.
더 정확한 진단이 필요한 선언이 있나요?
실행 전에 선언을 다시 확인하세요
Docker Compose 검증으로 돌아가 진단 경로와 호스트 바인딩을 점검하고 필요한 구성 값만 확인한 뒤 결과를 저장하세요.