2026년 11월 13일 금요일

apt upgrade 로 Docker 가 올라가면 컨테이너는 전부 재시작된다 — live-restore 확인하기

"우리 서버는 live-restore 가 켜져 있어서 Docker 를 업그레이드해도 컨테이너는 안 죽는다"고 운영 메모에 적어 두었는데, 틀린 기록이었다. 다음 정비 때 실제로 확인해 보니 꺼져 있었고, 패키지 갱신과 함께 컨테이너 전부가 재시작됐다.

무슨 일이 있었나

정기 정비로 apt upgrade 를 돌리면 docker-ce 와 containerd 가 함께 올라가는 날이 있다. 패키지 설치 스크립트는 데몬을 재시작하고, 기본 설정에서는 데몬이 내려갈 때 컨테이너도 함께 내려간다. restart 정책이 걸린 컨테이너는 데몬이 올라오며 다시 뜨지만, 그 사이 수십 초는 서비스가 끊긴다.

이전 정비 때 눈에 띄는 중단이 없었던 것을 "live-restore 덕분"이라고 추측해서 적어 둔 것이 화근이었다. 확인하지 않은 추측이 메모에 들어가면 다음부터는 사실처럼 읽힌다.

확인하는 법

docker info --format '{{.LiveRestoreEnabled}}'

false 면 데몬 재시작 = 전 컨테이너 재시작이다.

켜려면

# /etc/docker/daemon.json
{
  "live-restore": true
}
sudo systemctl reload docker

다만 만능은 아니다. 공식 문서 기준으로 패치 릴리스 사이의 업그레이드에서만 지원되고, Swarm 모드와는 함께 쓸 수 없다. 메이저·마이너 버전이 바뀌는 업그레이드라면 재시작을 전제로 계획하는 편이 안전하다.

정비 절차에 넣은 것

재시작을 피할 수 없다면, 끝난 뒤 전부 돌아왔는지를 기계적으로 확인한다.

# 정비 전
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Status}}' | sort > ~/pre-upgrade.txt

# 정비 후
docker ps --format '{{.Names}}\t{{.Image}}' | sort > /tmp/after.txt
cut -f1,2 ~/pre-upgrade.txt | diff - /tmp/after.txt && echo "전부 복귀"
  • 긴 업그레이드는 ssh 가 끊겨도 계속되도록 systemd-run --unit=apt-upgrade ... 로 돌리고 로그를 파일로 남긴다.
  • 서로 의존하는 컨테이너는 기동 순서 때문에 처음 몇 번 재시작할 수 있다. 내 경우 채팅 서버에 붙는 봇이 서버가 뜨기 전 502 를 받고 몇 차례 재시작한 뒤 자동으로 연결됐다. 이런 것은 "정상"이라고 메모해 두면 다음 정비 때 놀라지 않는다.
  • 이름만 바꿔 둔 예전 컨테이너에 restart=always 가 남아 있으면 데몬 재시작 때 같이 살아난다. 롤백용으로 남기더라도 재시작 정책은 꺼 두거나, 이미지와 백업만 남기고 컨테이너는 지운다.

정리

운영 메모에는 "실측"과 "추측"을 구분해서 적는다. 그리고 패키지 업그레이드에 Docker 가 끼어 있으면 컨테이너 재시작을 기본으로 가정하고, 전후 상태를 diff 로 비교한다.

댓글 없음:

댓글 쓰기

반도체 주식을 보기 전에 그려 두는 지도 — 설계, 파운드리, 메모리, 장비, 소재, 후공정

"반도체주"라고 한 묶음으로 부르지만, 그 안의 회사들은 하는 일도 돈 버는 방식도 전혀 다르다. 같은 뉴스에 어떤 회사는 오르고 어떤 회사는 내리는 이유가 여기에 있다. 종목을 들여다보기 전에 머릿속에 그려 두면 좋은 지도를 정리한...