같은 태그로 다시 빌드했는데 Docker restart 뒤에도 옛 코드다
같은 태그로 이미지를 다시 빌드한 뒤 restart해도 옛 코드가 보이면, 태그의 현재 이미지 ID와 기존 컨테이너의 이미지 ID를 비교한다. v1/v2 HTTP 본문을 실제로 대조해 재시작과 새 컨테이너 생성의 차이, 재생성을 선택할 조건을 설명한다.
빌드노트
Docker·컨테이너
Docker·컨테이너 카테고리의 글입니다.
글 검색
글 목록
총 47개의 글
-
-
Docker COPY가 config.txt를 /sample이라는 파일로 만들었다
Docker COPY가 단일 파일을 존재하지 않는 /sample에 복사하면 /sample 자체가 파일이 될 수 있다. 목적지 끝의 /와 기존 디렉터리 유무를 세 조건으로 비교하고, 이미지에서 경로 종류를 조회해 복사 의도를 명확히 하는 방법을 설명한다.
-
--build-arg로 넘긴 값이 docker run에서는 없는 이유
Docker 빌드 로그에는 있던 값이 실행한 컨테이너에서는 없을 때 ARG와 ENV를 구분한다. 합성 값으로 이미지의 Config.Env, 컨테이너 출력, 이미지 이력을 비교하고 실행 시 -e로 주입할 값과 이미지에 남길 기본값을 고르는 기준을 설명한다.
-
컨테이너는 실패했는데 docker wait는 성공했다
docker wait의 stdout에는 컨테이너 종료 코드가 나오지만 CLI 종료 상태는 0일 수 있다. exit 7·0과 없는 컨테이너를 실제 비교하고, PowerShell 자동화에서 CLI 오류를 먼저 확인한 뒤 stdout으로 작업 성공을 판정하는 코드를 설명한다.
-
서버는 응답하는데 HEALTHCHECK는 curl을 찾지 못한다
HTTP 서버가 응답해도 검사에 쓰는 curl을 컨테이너 안에서 찾지 못하면 unhealthy가 된다. 적용된 Test와 State.Health.Log의 ExitCode·Output을 읽고, 실제 제공된 BusyBox wget으로 같은 내부 URL을 확인해 검사 실행 실패를 구분한다.
-
ENV가 있어도 JSON CMD의 $APP_MODE는 그대로 전달된다
Docker의 JSON CMD는 셸을 자동 실행하지 않아 $APP_MODE를 인자로 그대로 전달한다. inspect로 환경과 인자를 나눠 보고, -e 변경·환경 직접 조회·명시적 셸 실행의 실제 출력을 비교한다.
-
start-period가 남았는데 HEALTHCHECK 실패가 쌓이는 이유
Docker HEALTHCHECK는 시작 유예 중 한 번 성공하면 이후 연속 실패를 집계한다. 90초 유예를 둔 두 컨테이너를 비교하고, inspect의 첫 성공 기록과 FailingStreak로 실패가 세어지는 이유를 확인한다.
-
ADD로 넣은 tar 파일이 이미지 안에서는 풀려 있다
로컬 tar를 ADD하면 아카이브 대신 내용물이 생긴다. 같은 바이트의 .tar·.bin과 일반 텍스트 .tar의 경로·바이트 비교를 바탕으로, 파일 자체가 필요할 때 COPY로 바꾸고 최종 경로를 확인하는 방법을 설명한다.
-
Docker export/import 뒤 파일은 남고 CMD·ENV는 사라지는 이유
Docker export/import 뒤 파일은 남았는데 기본 명령과 환경변수가 사라졌다면 이미지 Config를 비교한다. 합성 이미지의 CMD·ENV·WORKDIR와 컨테이너 추가 파일을 save/load 결과와 대조해 파일 추출과 이미지 보존 중 필요한 방식을 고르는 기준을 설명한다.
-
touch했는데 Docker COPY가 CACHED로 나오는 이유
touch 뒤 COPY가 CACHED여도 mtime만 바뀌었다면 정상적인 캐시 재사용이다. 동일 입력·시간만 변경·내용·권한 변경을 실제 빌드 로그와 이미지 안 해시로 비교하고, 크기와 mtime을 함께 보존한 로컬 입력의 예외 관찰도 구분한다.
-
Dockerfile의 cd는 다음 RUN까지 이어지지 않는다
Dockerfile의 cd가 다음 RUN에 이어지지 않아 파일을 못 찾을 때, pwd와 절대 경로 조회로 원인을 좁힌다. 한 RUN 안에서 이동할 경우와 이후 명령에 WORKDIR를 선언할 경우를 실제 빌드 결과로 구분한다.
-
기본 bridge에서 컨테이너 IP는 되는데 이름은 안 풀릴 때
Docker 기본 bridge의 IP 통신과 컨테이너 이름 해석은 별개다. 같은 두 컨테이너의 IP 요청·이름 조회를 비교하고, 사용자 정의 bridge를 추가했을 때 이름으로 HTTP 응답을 받은 결과와 적용 명령을 설명한다.