컨테이너·Docker와 데이터 지속성

01namespace와 cgroup은 서로 다른 질문에 답한다

• Namespace별 분리 대상mount namespace는 프로세스가 보는 마운트 트리를, PID namespace는 프로세스 번호 공간을, network namespace는 인터페이스·경로·포트 공간을 분리한다.

  • 따라서 컨테이너 안의 PID 1과 호스트의 PID 1은 같은 프로세스가 아닐 수 있다.
• namespace·컨테이너user namespace는 컨테이너의 UID를 호스트의 다른 UID 범위에 매핑할 수 있다.

  • 이 격리는 무엇을 보고 어떤 이름으로 접근하는지를 제한한다.
• cgroupcgroup은 CPU·메모리·프로세스 수 등의 사용을 집계하고 제한한다.
• 격리와 자원 제한namespace만 분리한 프로세스가 호스트 자원을 무제한 사용하는 문제는 별도 자원 제어 없이는 남는다.
• capabilitycapability는 세분화된 관리자 권능, seccomp는 시스템 호출 제한, SELinux/AppArmor는 객체 접근 정책을 제공한다.
• 컨테이너·호스트 커널컨테이너는 호스트 커널을 공유하므로 VM처럼 독립 커널을 부팅한 환경과 격리의 방식이 다르다.
• 격리 기능격리 기능이 있다는 사실만으로 모든 공격이 차단되지는 않는다.

  • 과도한 권한, 호스트 디렉터리 공유, 런타임 제어 소켓 노출은 호스트에 큰 영향을 줄 수 있다.

02이미지 계층과 컨테이너 쓰기 계층의 상태 변화

• 이미지의 구성이미지는 사용자 공간 파일과 실행 메타데이터를 재사용 가능한 계층으로 담는다.
• 컨테이너·이미지컨테이너를 만들면 읽기 전용 이미지 위에 해당 컨테이너의 쓰기 계층이 생긴다.
• copy-up과 삭제 표시OverlayFS 같은 구현에서는 lowerdir의 기존 파일을 수정할 때 upperdir 쪽으로 복사한 뒤 변경을 적용할 수 있고, 삭제 표시를 통해 아래 파일이 보이지 않게 한다.
• 저장 드라이버와 계층실제 저장 드라이버에 따라 구현은 다르지만 이미지와 인스턴스의 변경을 분리한다는 관계는 같다.
• 이미지·컨테이너같은 이미지로 새 컨테이너를 만들면 기존 컨테이너의 쓰기 계층이 자동으로 복제되지 않는다.
• 컨테이너stop은 프로세스를 중지할 뿐 해당 컨테이너의 계층을 제거하지 않지만 rm으로 컨테이너를 없애면 그 인스턴스의 쓰기 계층도 사라진다.

  • 따라서 DB 데이터·사용자 업로드 같은 지속 자료는 볼륨이나 의도한 외부 저장소로 분리한다.

docker image ls
docker ps -a
docker inspect demo
docker diff demo
# 이미지, 인스턴스 상태, 인스턴스 파일 변경은 서로 다른 조회다.

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

03ENTRYPOINT·CMD와 PID 1의 종료

• ENTRYPOINTENTRYPOINT는 실행할 기본 프로그램을 정하고 CMD는 기본 인자 또는 기본 명령 역할을 한다.
• 이미지·docker run실제 조합은 이미지 설정과 docker run 인자의 형태에 따라 결정된다.
• exec 형식JSON 배열의 exec 형식은 불필요한 셸을 거치지 않고 인자를 전달한다.
• shell 형식shell 형식은 중간 셸이 생겨 신호 전달과 변수 확장의 의미가 달라질 수 있다.

  • 컨테이너 초기 프로세스가 종료되면 컨테이너 실행도 끝난다.
• docker rundocker run -d는 클라이언트를 분리하는 것이지 애플리케이션을 전통적 데몬으로 바꾸는 옵션이 아니다.
• 컨테이너docker exec는 이미 실행 중인 컨테이너 안에 추가 프로세스를 만든다.
• PID 1·컨테이너그 exec 셸에서 exit해도 원래 PID 1이 살아 있으면 컨테이너는 계속 실행한다.
• 초기 프로세스초기 프로세스는 종료 신호 처리와 고아 자식 회수에 적절히 대응해야 하며 필요한 경우 init 역할을 따로 둔다.

FROM python:3.12-slim
WORKDIR /app
COPY app.py /app/app.py
USER 10001:10001
ENTRYPOINT ["python", "/app/app.py"]
CMD ["--port", "8000"]

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

04컨테이너 포트와 호스트 공개 포트

• namespace·포트각 network namespace는 자체 포트 공간을 가질 수 있으므로 서로 다른 컨테이너에서 같은 8000번 포트를 사용할 수 있다.
• 컨테이너bridge 네트워크에서는 veth와 브리지를 통해 컨테이너를 연결하고 호스트 공개 포트에서 컨테이너 주소로 전달하는 규칙을 구성할 수 있다.
• docker rundocker run -p 127.0.0.1:8080:8000은 호스트 loopback의 8080을 컨테이너의 8000에 연결하는 예다.
• 이미지·EXPOSE이미지의 EXPOSE 메타데이터는 앱이 사용하는 포트를 설명하지만 그것만으로 호스트 외부에 포트가 공개되지는 않는다.

  • 반대로 포트를 공개했어도 컨테이너 앱이 그 namespace의 127.0.0.1에만 bind하면 외부 인터페이스로 들어온 전달 요청을 받지 못할 수 있다.
• 호스트의 패킷 경로호스트 방화벽에서 INPUT만 보아서는 브리지·DNAT·FORWARD가 관여하는 전체 경로를 설명하지 못한다.

docker port demo
docker network inspect bridge
# 예시 전달 관계: host 127.0.0.1:8080 -> container:8000

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

05volume·bind mount·secret의 소유권

• volumenamed volume은 Docker가 관리하는 저장 단위이고 bind mount는 지정한 호스트 경로를 컨테이너 경로에 연결한다.
• 마운트로 가려진 파일마운트 지점에 이미지 파일이 있었다면 연결된 저장소가 그것을 가릴 수 있다.
• 읽기 전용·SELinux 레이블:ro는 컨테이너 쪽 쓰기를 제한하며 SELinux 환경의 :z/:Z는 레이블에 영향을 준다.
• 호스트 경로 노출특히 호스트의 중요한 디렉터리를 넓게 마운트하면 이미지 격리와 별도로 그 자원에 접근하게 된다.
• 컨테이너·호스트 UID컨테이너 안의 UID 10001이 호스트에서 어떤 UID로 해석되는지에 따라 파일 소유권 결과가 달라진다.
• namespacerootless/user namespace와 일반 실행을 같은 숫자로 단정할 수 없다.
• 이미지에 남는 비밀비밀값을 이미지의 RUN이나 ENV에 넣으면 계층·메타데이터·inspect 결과 등에 남을 수 있으므로 접근이 제한된 파일이나 외부 비밀 관리 방식으로 전달하고 수명을 관리한다.
• 볼륨볼륨 복사도 DB가 쓰는 중이면 일관되지 않을 수 있어 애플리케이션 백업 절차와 연결해야 한다.

09실행 상태와 정상 동작

• 로그프로세스 종료, 로그, 자원 제한, 헬스 체크를 함께 관찰한다.
• 컨테이너·PID 1컨테이너의 PID 1은 종료 신호 처리와 자식 프로세스 정리에서 주의가 필요하며, 실행 중이라는 표시만으로 요청을 정상 처리한다고 단정할 수 없다.

  • Docker 제어 권한은 단순한 조회 권한보다 강할 수 있다.
• 컨테이너운영 계정과 자동화 계정이 컨테이너 실행·마운트·권한 옵션을 어디까지 바꿀 수 있는지 확인한다.

docker ps
docker image ls
docker volume ls

현재 Docker 환경의 실행 컨테이너·이미지·볼륨 목록만 조회한다.

10같은 경로에 써도 저장 위치가 달라지는 이유

• 컨테이너 쓰기 계층이미지에서 컨테이너를 만들면 읽기 전용 이미지 계층 위에 해당 컨테이너의 쓰기 계층이 연결된다.
• 쓰기 계층일반 경로에 새 파일을 쓰면 보통 쓰기 계층에 변화가 기록되고, 그 컨테이너를 삭제하면 해당 계층의 데이터도 제거된다.

  • 그러나 그 경로가 볼륨이나 bind mount로 연결돼 있으면 데이터는 그 마운트가 가리키는 별도 저장 위치에 기록된다.
• 컨테이너·쓰기 계층경로 문자열이 같다고 컨테이너 내부 쓰기 계층에 들어간다고 가정하면 안 된다.
• 이미지웹 애플리케이션의 실행 파일은 이미지에서 공급하고 업로드 자료는 볼륨에 두는 구성을 생각한다.
• 교체와 볼륨 재사용새 이미지로 컨테이너를 교체해도 같은 볼륨을 연결하면 업로드 자료를 이어 사용할 수 있다.

  • 반대로 새 컨테이너에 다른 빈 볼륨을 붙이면 기존 자료가 사라진 것처럼 보인다.
• 볼륨볼륨 이름·실제 연결 경로·애플리케이션 설정을 함께 대조해야 한다. 볼륨을 유지하는 것은 수명 분리이며 삭제·오염에 대비한 과거 백업을 자동으로 생성하는 기능은 아니다.

1. 생성이미지 기반으로 실행 인스턴스와 쓰기 계층이 만들어진다.
2. 업로드마운트된 경로의 데이터는 볼륨으로 기록된다.
3. 기존 인스턴스 제거해당 컨테이너의 쓰기 계층은 함께 사라진다. 볼륨 제거는 별도 작업이다.
4. 새 인스턴스 연결같은 데이터 볼륨을 연결해 자료를 다시 읽는다.

11컨테이너 장애를 계층별로 관찰하기

• Running과 서비스 정상컨테이너 상태가 running이면 주 프로세스가 살아 있다는 단서지만 HTTP 응답, DB 연결, 파일 저장까지 정상임을 의미하지 않는다.
• 로그종료 코드와 로그를 확인하고 헬스 체크가 무엇을 검사하는지 읽는다.
• 루프백 바인딩서비스가 컨테이너 내부 루프백에만 바인딩돼 있으면 포트를 공개해도 기대한 인터페이스로 응답하지 않을 수 있다.
• 포트·컨테이너호스트의 공개 주소·포트와 컨테이너의 실제 리스닝 포트는 한 쌍으로 기록한다.
• 실행 계정의 파일 접근호스트에서 파일을 볼 수 있어도 컨테이너 실행 계정이 읽지 못할 수 있다.
• bind mountbind mount의 소유권, SELinux 레이블과 읽기 전용 옵션을 따로 확인한다.

  • 메모리 제한으로 종료된 경우와 애플리케이션 예외 종료도 구분해야 한다.
• 런타임 제어 권한Docker 제어 소켓이나 높은 권한을 주는 방식으로 모든 오류를 피하면 격리 경계가 크게 약해질 수 있다.
• 재생성과 데이터 보존재생성 실습에서는 코드 버전, 환경 변수, 마운트, 네트워크와 종료 후 데이터가 무엇인지 각기 확인한다.