prune 후에도 로컬과 서버 상태가 다를 때

docker system prune을 실행했는데도 여전히 문제가 있다면, 뭔가 깔끔하게 삭제되지 않은 것이다.

prune이 정말 실행되었나

먼저 prune 명령이 뭘 삭제했는지 확인한다. 예상보다 적은 용량만 삭제되었다면 뭔가 놓친 게 있다는 뜻이다.

docker system prune -a

-a 플래그를 붙이면 사용 중이지 않은 모든 이미지를 삭제한다 (태그 없는 이미지 포함). 이게 없으면 일부 이미지는 살아있을 수 있다.

로컬과 서버의 다른 정리 상태

로컬에서는 작은 이미지들만 있지만, 서버에는 몇 개월간 쌓인 오래된 빌드들이 있을 수 있다. 로컬과 서버의 Docker 저장소 상태를 비교해봐야 한다.

docker images | wc -l
docker ps -a | wc -l

로컬에는 이미지가 30개, 서버에는 300개라면, 서버에 cleanup이 오래 동안 안 된 것이다.

컨테이너 이름 충돌

prune 후에도 같은 이름의 컨테이너가 자꾸 안 지워질 수 있다. 이건 보통 실행 중인 컨테이너 때문이다.

docker ps -a --filter "status=exited" --filter "name=myservice"

특정 이름의 모든 컨테이너를 본다. 종료된 컨테이너 중에 원하는 이름이 있으면 직접 삭제해야 할 수도 있다.

docker rm <container-id>

볼륨도 정리

prune 후에도 경고가 나온다면 고아 볼륨 때문일 수 있다. 이건 별도로 삭제해야 한다.

docker volume prune

이 명령으로 어떤 볼륨들이 삭제되는지 본다. 실제 필요한 데이터가 있는 볼륨은 보존되고, 어떤 컨테이너도 사용하지 않는 볼륨만 삭제된다.

빌드 캐시도 확인

최신 버전의 Docker에서는 빌드 캐시가 상당한 용량을 차지한다.

docker builder prune

이전 빌드의 캐시를 정리한다. 로컬과 서버 간에 Docker 버전이 다르면 캐시 관리 방식도 다를 수 있다.

정기적인 정리 습관

서버에서는 매주 정리하는 스크립트를 cron으로 돌리는 게 좋다.

#!/bin/bash
docker system prune -af --volumes
docker builder prune -af

lokalhost에서는 필요할 때만 하고, 서버에서는 자동화된다면 로컬과 서버의 상태 차이를 줄일 수 있다.