dev.to

Docker Compose 5.6's jobs type only starts through docker compose run

Docker Compose 5.6의 jobs는 docker compose run으로만 실행됩니다

Docker Compose 5.6.0의 jobs는 수동 실행만 지원하며, docker compose run으로만 시작할 수 있습니다. 예약 실행을 설정하면 관련 없는 서비스까지 docker compose up이 중단되고, manual: false인 작업은 실행 경로가 없습니다.

에디터 노트

현재 가장 큰 제약은 예약 작업을 선언하는 순간 기존 스택의 up까지 실패한다는 점입니다. 수동 작업은 경고 후 건너뛰므로 영향이 다릅니다. 댓글 작성자는 config 검증이 예약 작업을 통과하는지 물었고, 글쓴이도 확인하지 않았다고 밝혔습니다. 따라서 배포 시점에만 실패하는 CI 공백은 가능성으로 제기됐을 뿐 확인된 동작은 아닙니다. 실행 시간 비교는 db가 이미 떠 있는 경우와 새로 시작하는 경우를 각각 세 번 측정한 결과이며, 약 230밀리초 차이를 모든 의존 서비스에 적용할 수는 없습니다. 반면 종료 코드 전달과 동시 실행 시 별도 컨테이너 생성은 시험으로 확인했습니다. jobs를 기존 일회성 작업의 대체재로 쓸 때는 실행 명령과 예약 트리거의 현재 제약을 구분해야 합니다.

AI 요약

Docker Compose 5.6.0은 10월 2일 compose 파일에 services와 나란히 jobs 섹션을 추가했습니다. 글쓴이는 새 기능의 실제 동작을 Alpine 컨테이너와 db 서비스로 시험했습니다. jobs 항목에는 triggers 블록이 필요하며, 이를 빼면 docker compose config 단계에서 파일 검증이 실패합니다.

시작 명령과 트리거

수동 작업에 triggers: {manual: true}를 설정하면 docker compose up -d는 경고를 출력하고 작업을 건너뜁니다. docker compose ps -a에도 작업이 나타나지 않습니다. docker compose create와 docker compose start는 작업을 거부하며, 안내하는 실행 명령은 docker compose run입니다. 작업은 run으로 실행할 때 의존 서비스를 먼저 시작합니다. 작업에 지정한 profiles도 별도 --profile 옵션 없이 활성화됩니다.

예약 트리거는 서비스 시작에 더 큰 영향을 줍니다. triggers.schedule에 cron을 지정한 작업이 있으면 docker compose up -d 전체가 실패하고 같은 파일의 db 서비스도 시작하지 않습니다. 글쓴이가 처음 시도한 단순 문자열 형식은 스키마 검증에서 거부됐습니다. schedule은 cron 키를 담은 객체 목록이어야 합니다. 예약 작업도 docker compose run으로 직접 실행할 수 있지만, triggers.manual: false를 지정하면 수동 실행도 거부됩니다. 5.6.0에서는 이런 작업을 시작할 경로가 없습니다.

실행 시간과 컨테이너 동작

db가 이미 실행 중일 때와 중지 상태에서 시작할 때 각각 세 번 측정한 결과, docker compose run의 평균 시간은 1.487초와 1.717초였습니다. 글쓴이는 약 230밀리초 차이를 의존 컨테이너 생성과 시작에 드는 시간으로 설명합니다. 실제 환경에서는 의존 이미지의 시작 절차와 depends_on 항목 수에 따라 달라집니다.

작업 컨테이너의 종료 코드는 셸로 그대로 전달됩니다. 종료 코드 17인 작업을 실행하자 docker compose run도 17을 반환했습니다. 같은 작업을 동시에 두 번 실행한 시험에서는 각기 다른 컨테이너가 생성되어 모두 완료됐습니다. Compose가 작업을 직렬화하거나 대기열에 넣지 않으므로 동시 실행 제어가 필요하면 별도로 구현해야 합니다.

--rm 없이 실행한 뒤 남은 컨테이너는 docker compose down과 docker compose rm -f로 정리되지 않았습니다. 글쓴이는 profiles로 제한한 일반 서비스에서도 같은 현상을 확인해 jobs만의 문제로 보기는 어렵다고 구분합니다. jobs는 docker compose config --services 출력에도 나타나지 않으므로, 이 명령으로 서비스 목록을 순회하는 스크립트는 작업을 따로 다뤄야 합니다. 글쓴이는 당분간 manual: true를 쓰고 docker compose run --rm으로 실행하라고 권합니다.

dev.to 반응

  • @mno_tao_236ab4649edf4cf9f — 예약 트리거 결과는 기존 스택에 jobs를 추가하는 사람에게 꼭 짚어줘야 할 부분입니다. 수동 작업은 경고 후 건너뛰지만 예약 작업은 관련 없는 db 서비스까지 포함해 전체 up을 중단합니다. nightly 작업이 있는 파일을 docker compose config가 받아들였나요? 그렇다면 compose 파일 검증만 하는 CI 단계는 통과하고 배포 시점에야 실패할 수 있습니다. 컨테이너 누출을 jobs 탓으로 돌리기 전에 profiles로 제한한 서비스를 다시 시험한 것도 좋았습니다.
    • @alexgeorgiev17 — 맞습니다. 이런 비대칭이 문제를 일으킬 수 있습니다. 시작할 수 없는 수동 작업은 경고로 끝나지만 시작할 수 없는 예약 작업은 db까지 중단합니다. config에 관한 질문은 좋은 지적이고, 솔직히 nightly 파일은 확인하지 않았습니다. config가 거부한 것은 스키마 오류인 bare-string schedule뿐이었습니다. 'scheduled jobs are not supported in this version' 오류는 up에서 나왔으니 config는 통과하고 up 단계에서만 거부될 것 같습니다. CI에서 놓칠 수 있다는 지적과 맞닿아 있지만 추측입니다. 여기서 config를 실행해 결과를 댓글로 남기겠습니다. 통과한다면 시작 없이 같은 검사를 하는 저렴한 CI 대안은 docker compose up --dry-run -d일 수 있습니다. 5.6에서 둘 다 시험해보지는 않았습니다. profiles로 다시 시험한 덕에 Compose가 오래전부터 가진 문제를 jobs 탓으로 돌리지 않게 됐습니다.

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗