Docker 컨테이너는 Linux 커널의 기능을 사용한다. Linux가 아닌 macOS에서는 Docker Engine을 그대로 실행할 수 없기 때문에, 어디선가는 Linux 가상 머신을 하나 띄워야 한다. Docker Desktop은 이 가상 머신과 Docker Engine, 파일 공유, 네트워크, 업데이트, GUI를 하나의 애플리케이션으로 묶어 제공한다.
이 구성이 편한 것은 사실이지만, 모든 사람이 그 기능을 전부 필요로 하지는 않는다. 터미널에서 docker compose up -d를 실행하고 백그라운드 서비스 몇 개만 유지하려는 사람에게는 Docker daemon을 실행할 작은 Linux 환경이면 충분하다.
이 지점에서 먼저 등장한 프로젝트가 Lima다. Linux Machines의 줄임말이며, macOS에서 Linux 가상 머신을 CLI로 만들고 실행하는 도구다. Lima 프로젝트는 2021년 5월에 시작했고, 처음에는 Mac 사용자에게 containerd와 nerdctl을 제공하는 것이 주된 목적이었다. 이후 2022년 CNCF Sandbox 프로젝트가 되었고, 2025년에는 Incubating 단계로 올라갔다.
Colima는 이 Lima 위에 컨테이너 실행에 필요한 설정을 얹은 도구다. 이름도 Containers on Lima에서 왔다. 직접 Lima 가상 머신을 만들고 Docker daemon을 설치한 뒤 소켓과 네트워크를 연결하는 과정을 Colima가 대신 처리한다.
Docker Desktop의 구독 정책이 개편된 것도 2021년이었다. 이 시기에 Docker와 Docker Desktop이 같은 것이 아니라는 점, 그리고 Docker CLI와 Engine은 유지하면서 Desktop만 다른 도구로 교체할 수 있다는 사실이 더 많이 알려졌다. Colima는 Docker를 새로 구현한 제품이나 Docker Desktop의 포크가 아니다. --runtime docker로 시작하면 Lima 가상 머신 안에서 여전히 Docker Engine을 실행하고, macOS의 Docker CLI가 그 daemon에 연결된다.
결국 관계는 다음처럼 정리할 수 있다.
- colima start: Colima -> Lima Linux VM -> Docker Engine
- docker ps: Docker CLI -------------> Docker Engine -> Containers
Colima는 VM과 Docker Engine을 준비하고 관리하지만, 컨테이너 명령을 대신 실행하는 중간 서버는 아니다. 준비가 끝나면 Docker CLI는 context에 등록된 Docker Engine으로 직접 요청을 보낸다. 그래서 Colima로 옮긴 뒤에도 평소의 docker 명령은 거의 달라지지 않는다. 달라지는 것은 Docker Engine을 준비하고 관리하는 주체가 Docker Desktop에서 Colima로 바뀐다는 점이다.
Colima와 Docker CLI 설치
Docker Desktop을 계속 사용할 생각이라면 이 과정은 필요 없다. Docker Desktop을 대신해 Colima를 사용할 경우 Homebrew로 Colima, Docker CLI, Docker Compose를 설치한다.
brew install colima docker docker-compose설치했는데 셸에서 docker 명령을 찾지 못한다면 Homebrew 링크와 셸의 명령 캐시를 확인한다.
brew link docker || brew link --overwrite dockerrehash 2>/dev/null || trueDocker Compose는 Docker CLI 플러그인으로 동작한다. docker compose version이 실패한다면 Homebrew의 플러그인 경로를 ~/.docker/config.json에 추가한다. 아래 스크립트는 기존 설정을 유지하면서 경로만 덧붙인다.
mkdir -p ~/.dockerpython3 - <<'PY'import jsonimport subprocessfrom pathlib import Pathprefix = subprocess.check_output(["brew", "--prefix"], text=True).strip()plugin_dir = f"{prefix}/lib/docker/cli-plugins"path = Path.home() / ".docker" / "config.json"data = {}if path.exists() and path.read_text().strip(): data = json.loads(path.read_text())dirs = data.setdefault("cliPluginsExtraDirs", [])if plugin_dir not in dirs: dirs.append(plugin_dir)path.write_text(json.dumps(data, indent=2) + "\n")print(f"configured: {plugin_dir}")PY세 도구의 버전이 모두 출력되는지 확인한다.
colima versiondocker --versiondocker compose versionColima 시작하기
아래 설정은 Colima 가상 머신에 CPU 4개, 메모리 8GB, 디스크 60GB를 할당한다. 숫자는 Mac 사양과 실행할 컨테이너 규모에 맞게 조정하면 된다. 가벼운 서비스 하나가 목적이라면 처음부터 더 작은 값으로 시작해도 된다.
colima start --runtime docker --cpu 4 --memory 8 --disk 60docker context use colimaColima는 시작할 때 Docker context를 자동으로 설정한다. 그래도 Docker Desktop과 함께 설치되어 있거나 연결할 daemon을 확실히 지정하고 싶다면 docker context use colima로 다시 선택할 수 있다. 현재 context는 다음 명령으로 확인한다.
docker context showdocker context ls마지막으로 Docker daemon에 연결되는지 확인한다.
docker ps오류 없이 컨테이너 목록이 출력되면 준비가 끝난 것이다. 아직 실행 중인 컨테이너가 없다면 헤더만 있는 빈 목록이 보인다. Cannot connect to the Docker daemon 오류가 나온다면 colima status와 docker context show를 차례로 확인한다.
자주 쓰는 명령어
평소에는 시작, 상태 확인, 중지 정도만 기억하면 된다.
colima startcolima statuscolima stopcolima restart가상 머신과 그 안의 컨테이너 데이터를 모두 지울 때는 colima delete를 사용한다. 단순히 Colima를 잠시 끄고 싶은 경우에는 stop이면 충분하다.
colima deleteColima를 쓴다고 Docker 사용법이 달라지는 것은 아니다. Docker daemon을 띄우는 역할만 Docker Desktop에서 Colima로 바뀐다. GUI가 필요하지 않고 몇 개의 컨테이너를 조용히 돌리는 용도라면, 메모리와 디스크를 필요한 범위 안에서 통제할 수 있다는 점만으로도 충분히 선택할 이유가 있다.
댓글
댓글을 불러오는 중...