본문 바로가기
빌드노트 검색

빌드노트

Docker·컨테이너

Docker·컨테이너 카테고리의 글입니다.

글 검색

글 목록

총 47개의 글

  1. FROM 위 ARG는 이미지 태그에 쓰이는데 RUN에서는 비어 있다

    Dockerfile의 첫 FROM 위 ARG는 이미지 선택에 쓰여도 RUN에 자동 전달되지 않는다. 단계 안에 ARG 이름을 다시 선언하는 전후 결과와 독립 단계의 범위를 비교하고, --build-arg와 ENV가 맡는 역할을 구별한다.

  2. 앱이 cd해도 docker exec의 기본 경로는 그대로다

    앱의 현재 디렉터리와 컨테이너의 Config.WorkingDir는 다른 값일 수 있다. 이미지 설정, 실제 /proc/1/cwd, 기본 exec와 exec -w의 출력을 비교해 점검 명령의 시작 경로를 정한다.

  3. Docker cache mount에 만든 파일은 실행 이미지에 남지 않는다

    Docker 빌드 중에는 읽힌 파일이 실행 이미지에 없다면 RUN cache mount의 target과 산출물 경로를 대조한다. 필요한 파일을 같은 RUN에서 마운트 밖으로 복사하고, 완성한 이미지에서 두 경로를 확인하는 방법을 설명한다.

  4. 빌드 단계에서는 있던 명령이 최종 Docker 이미지에는 없다

    멀티스테이지 빌드가 성공해도 이전 단계의 도구와 ENV가 최종 이미지에 자동으로 남지는 않는다. 별도 FROM으로 시작한 두 단계에서 도구·산출물·환경 변수를 비교하고, 런타임에 필요한 파일과 설정을 명시하는 기준을 설명한다.

  5. Dockerfile을 바꾸니 같은 빌드 컨텍스트의 파일이 COPY에서 빠진다

    같은 빌드 컨텍스트에서도 선택한 Dockerfile의 전용 ignore가 있으면 루트 .dockerignore의 제외 목록은 합쳐지지 않는다. 합성 파일의 포함 목록과 COPY 성공·실패를 비교해 실제 적용 파일을 찾고 필요한 경로를 맞춘다.

  6. 프로필을 켜지 않았는데 지정한 Compose 서비스가 실행된다

    Compose 서비스에 profiles: [tools]를 넣었는데 docker compose up job-a로 실행하니 컨테이너가 생겼다면, 서비스 이름을 직접 지정했는지부터 본다. 프로필을 활성화하지 않아도 명시한 서비스는 실행된다.

  7. 이미지를 v2로 바꿨는데 볼륨의 기본 파일은 v1이다

    빈 볼륨의 초기 복사와 내용이 있는 볼륨의 재사용을 v1·v2 파일로 비교한다. 새 이미지의 파일 추가가 기존 볼륨에 반영되지 않는 조건과 volume-nocopy의 역할을 확인하고, 이미지 배포와 데이터 이관을 분리할 기준을 설명한다.

  8. USER를 바꿨는데 COPY한 파일은 여전히 root 소유다

    USER는 실행 사용자를 바꾸지만 COPY 파일의 소유권을 바꾸지는 않는다. UID/GID와 모드를 따로 조회하고, 비root 읽기·쓰기 비교를 통해 COPY --chown과 최소 권한을 적용할 위치를 확인한다.

  9. docker stop에서 종료 훅이 안 보이면 PID 1부터 확인한다

    docker stop 때 종료 훅이 보이지 않는 원인을 PID 1과 신호 경로로 좁힌다. 같은 SIGTERM 처리 프로그램의 shell-form·exec-form·exec 시작 스크립트에서 PID, 수신 로그, 정지 시간과 종료 코드를 실제 비교하고 자기 앱의 진입점을 확인하는 명령을 설명한다.

  10. docker exec에서 export했는데 앱 설정은 그대로다

    실행 중인 컨테이너에서 일반 exec, exec -e, 셸의 export를 비교한다. 새 진단 프로세스의 환경과 기존 앱의 설정을 구분하고, 시작 시 읽는 값은 배포 정의에 넣어야 하는 이유를 실제 관찰로 설명한다.

  11. 같은 Compose 파일인데 컨테이너가 하나 더 생겼다

    같은 Compose 파일로 실행해도 프로젝트 이름이 다르면 기존 서비스 대신 별도 컨테이너가 생긴다. 프로젝트·서비스 라벨과 현재 명령의 name을 비교하고, 기존 프로젝트에 맞는 -p로 관리 대상을 고정하는 방법을 실제 격리 실행 결과로 설명한다.

  12. docker run 이미지 뒤의 /bin/sh가 셸을 띄우지 않는 이유

    docker run 이미지 뒤에 /bin/sh를 붙였는데 기존 프로그램의 인자 오류가 난다면 컨테이너의 Path/Args와 실제 이미지의 Entrypoint/Cmd를 비교한다. 보존된 격리 관찰로 CMD 전체 대체와 --entrypoint 교체·기본 CMD 제거를 구분하고, 실행 파일을 바꿀 최소 명령을 설명한다.