컨테이너를 다루는 명령줄 도구는 여럿이고 대부분 Docker 의 하위 명령 이름을 그대로 따른다. 어느 도구가 어느 계층을 담당하는지 알면 환경에 맞는 것을 고를 수 있다.
| 계층 | 도구 |
|---|---|
| 사용자 CLI | docker · podman · nerdctl |
| 이미지 빌드 전용 | buildah · BuildKit |
| 고수준 런타임 | dockerd · containerd · CRI-O |
| 저수준 런타임(OCI) | runc · crun |
| Kubernetes 노드 디버깅 | crictl · ctr |
docker · podman · nerdctl 은 결국 아래에서 runc 나 crun 을 부른다. 같은 OCI 이미지를 서로 주고받을 수 있다.
run · ps · images · build · pull · push · exec · logs · tag · inspect · rm · rmi 는 Docker · Podman · nerdctl 에서 이름과 옵션이 거의 같다. 스크립트를 옮길 때는 대개 명령 이름만 바꾸면 된다.
docker run -d --name web nginx
podman run -d --name web nginx
nerdctl run -d --name web nginx
| 항목 | Docker | Podman |
|---|---|---|
| 데몬 | dockerd 상주 |
없음. 명령이 곧 프로세스 |
| rootless | 별도 구성 필요 | 기본 동작 |
| 소켓 | /var/run/docker.sock |
없음. 필요하면 podman.socket 을 따로 켠다 |
| systemd 연동 | 직접 유닛 작성 | Quadlet(.container 파일)으로 생성 |
| Compose | docker compose (v2, 플러그인) |
podman-compose 또는 Podman 소켓 + Docker Compose |
| Pod 개념 | 없음 | 있음. podman generate kube 로 매니페스트 출력 |
Podman 의 generate systemd 는 4.x 에서 비권장으로 바뀌었고 Quadlet 이 권장 방식이다. 옛 문서의 podman generate systemd --files 예제를 그대로 쓰면 경고가 뜬다.
nerdctl 은 containerd 를 직접 쓰는 환경에서 Docker 와 가장 비슷한 사용감을 준다. Kubernetes 노드에서 containerd 를 쓸 때 crictl 보다 손에 익다. 다만 crictl 은 CRI 규격을 통해 kubelet 이 보는 것과 같은 상태를 보여 주므로 파드 문제를 볼 때는 crictl 을 쓴다.
LXC·LXD 는 애플리케이션 컨테이너가 아니라 시스템 컨테이너(하나의 OS 처럼 쓰는 것)를 다루므로 명령 체계도 목적도 다르다.