이름이 비슷해서 같은 것으로 보이지만 별개다.
| 호출 | 정체 |
|---|---|
docker-compose |
하이픈이 붙은 독립 실행 파일. 파이썬으로 만든 v1 계열, 또는 Go 로 만든 v2 의 standalone 바이너리 |
docker compose |
Docker CLI 플러그인. /usr/libexec/docker/cli-plugins/docker-compose 등에 설치된다 |
v1 은 수명이 끝났고 현재는 v2 만 유지된다. 그런데 오프라인 설치 스크립트나 제품 설치 관리자 중에는 여전히 하이픈 형태(docker-compose)를 호출하는 것이 많아, 두 가지가 섞여 들어오게 된다.
which -a docker-compose
docker-compose version
docker compose version
docker version --format '{{.Client.APIVersion}} {{.Server.APIVersion}}'
ls -l /usr/libexec/docker/cli-plugins/ /usr/local/lib/docker/cli-plugins/ 2>/dev/null
which -a 로 여러 개가 나오면 PATH 앞에 있는 것이 실행된다. 스크립트가 기대하는 것과 다른 바이너리가 앞에 있으면 원인을 알기 어려운 오류가 난다.
두 구현이 섞이면 API 버전 불일치 메시지를 보게 된다.
Error response from daemon: client version 1.42 is too old.
Minimum supported API version is ...
이 메시지는 클라이언트가 쓰는 Docker Engine API 버전이 데몬이 허용하는 범위를 벗어났다 는 뜻이다. 어느 조합에서 나오는지는 엔진과 compose 버전에 따라 다르므로 위 docker version 출력으로 실제 값을 확인한다. 임시로 맞춰 볼 때는 환경변수로 고정할 수 있다.
DOCKER_API_VERSION=1.41 docker-compose version
이건 진단용이고 항구적인 해결책은 아니다 (확인 필요 - 메시지 원인은 환경마다 다르다).
권장 방향이다. 플러그인을 설치하고, 하이픈 형태를 요구하는 스크립트를 위해 심볼릭 링크만 남긴다.
mkdir -p /usr/local/lib/docker/cli-plugins
install -m 0755 docker-compose /usr/local/lib/docker/cli-plugins/docker-compose
ln -sf /usr/local/lib/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose
docker compose version
docker-compose version
두 명령의 버전 출력이 같아야 정리가 끝난 것이다.
which -a docker-compose
rm -f /usr/local/bin/docker-compose # 옛 파이썬 v1 인 경우
pip3 uninstall docker-compose # pip 로 깔았던 경우
dnf remove docker-compose # 배포판 패키지로 깔았던 경우
Harbor 같은 오프라인 설치 관리자는 install.sh 안에서 compose 를 호출한다. 스크립트가 어느 형태를 부르는지 먼저 본다.
grep -n 'docker[- ]compose' <installer-dir>/install.sh <installer-dir>/prepare
설치 자산에 compose 바이너리를 함께 담아 갈 때는 실행 권한과 경로를 스크립트와 맞춘다.
install -m 0755 <packages>/docker-compose /usr/local/bin/docker-compose
가져온 compose 바이너리의 버전이 지나치게 오래됐으면(예: v2 초기 릴리스) 새로 받아 두는 편이 낫다. 폐쇄망에서는 반입 전에 버전을 확정하고 목록에 기록해 둔다.