Jost Do It!

1. 개요도커 컴포즈를 통해 컨테이너를 실행하는 환경에서 일부 서비스의 스크립트 내용이 변경돼 컨테이너를 재실행하였다.docker compose downdocker compose up하지만 변경된 스크립트 내용들이 컨테이너에 반영되지 않고, 여전히 이전 스크립트 내용으로 실행되는걸 확인하였다. 아래 명령어로 이미지를 재빌드를 해도 변경된 스크립트 내용은 반영되지 않았다.docker compose build --no-cache 2. 원인도커는 이미지를 생성하고, 그 이미지를 통해 컨테이너를 실행한다.그리고 컨테이너를 재실행하면 기존 이미지를 재사용해 컨테이너를 다시 생성한다.도커의 이미지 목록은 다음 명령어로 확인할 수 있다.docker image ls  만약 기존 서비스 내용들에서 변경이 생긴다면 doc..

문제상황 nvidia-docker2를 설치하고 컨테이너 내부에서 GPU접근을 가능하게 하였다. 그런데 데스크톱을 재부팅해서 torch 모듈을 실행하니 다음 에러가 발생했다. RuntimeError: No CUDA GPUs are available 컨테이너 내부에서 nvidia-smi 명령을 해보니 다음과 같은 에러도 발생한다. nvidia-smi >>> Failed to initialize NVML: Unknown Error 문제 원인 호스트가 systemd를 사용해 container의 cgroup을 관리하는 경우, Nvidia GPU를 참조하는 유닛파일들이 reload될 수 있다. 여기서 유닛파일들이 reload되면 컨테이너는 reload 된 유닛파일에 대한 접근권한이 없기 때문에 발생하는 에러이다. ..

문제 상황 파이썬 컨테이너를 띄우고 내부에 패키지를 설치하던 중 아래 에러가 발생하였다. pip install -r requirements.txt [...] Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 165, in exc_logging_wrapper status = run_func(*args) File "/usr/lib/python3/dist-packages/pip/_internal/cli/req_command.py", line 205, in wrapper return func(self, options, args) File "/usr/lib/pyt..

개요 루트 계정이 아니면 특정 도커 명령어를 사용할 때마다 sudo를 적어줘야된다. 아래 방법으로 유저에게 도커 권한을 주면 sudo 명령어를 적지 않아도 된다. 방법 도커를 설치하면 호스트 내 도커 그룹이 생성된다. 아래 명령어를 통해 도커 그룹에 사용자를 추가하면 된다. sudo usermod -aG docker {유저명} 여기서 {유저명} 부분에 추가할 사용자명을 입력하면 된다. 나는 heenj라는 유저명을 입력했다. 제대로 적용됐는지 확인하기 위해 다음 명령어를 실행한다. cat /etc/group 그럼 아래와 같이 group명 docker에 heenj 유저가 할당된 것을 확인할 수 있다. Reference https://seulcode.tistory.com/557

OS 요구 사항 64bit의 우분투 운영체제가 설치돼야 하며, 아래 버전 중 하나여야 한다. Ubuntu Mantic 23.10 Ubuntu Lunar 23.04 Ubuntu Jammy 22.04 (LTS) Ubuntu Focal 20.04 (LTS) 도커 관련 패키지 삭제 설치된 도커 관련 패키지들이 있으면 충돌을 일으킬 수 있으므로 아래 명령어로 삭제를 먼저 진행한다. for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done 참고> 위 명령어는 설치된 관련 패키지들만 제거하므로 기존 도커 엔진 자체를 제거하고 싶으면 이 링크를 ..

문제 상황 카프카 환경을 구축하면서 confluent 가이드에서 제공하는 `docker-compose.yml` 파일을 이용하게 되었다. 해당 파일은 카프카와 관련된 여러 컴포넌트 이미지들을 포함하는데, 각 이미지들의 세부 사항들을 확인하기 어려웠다. 특히 컨테이너를 띄우면 컨테이너 내부의 파일들을 디스크에 마운트하고 싶었는데, 어떤 내부 파일들을 마운트해야 하는지, 이미지에서 기본적으로 마운트하는 폴더들은 무엇인지 확인하기 어려웠다. confluent에서 제공하는 docker-compose.yml 파일 version: '2' services: zookeeper: image: confluentinc/cp-zookeeper:6.2.1 hostname: zookeeper container_name: zooke..

도커 이미지를 생성하는데 사용된 명령어들을 확인하고 싶을 때 docker history를 사용할 수 있다. 명령어는 아래와 같다. docker history 여기서 {:버전명}은 생략 가능하고, 생략 시 가장 최신의 repository의 image history를 가져온다. 옵션 리스트는 아래와 같다. --quite or -q: 이미지의 ID만을 출력한다. --no-trunc: 생략된 부분들을 모두 출력한다. 옵션에서 확인할 수 있듯이 default로 너무 긴 경우는 생략해서 출력한다. 출력 결과 1. 기본 명령을 사용해 출력한 결과 아래와 같다. IMAGE ID, 생성 시간, 생성 이유, 크기, Comment를 출력한다. 생성 이유에서 명령어 (or 이미지) 내용을 확인할 수 있다. 각 명령어들은 하나..

도커 이미지 ID를 이용해 a252344b0747 이미지(A)를 제거하려고 할 때, docker rmi a252344b0747 다음 에러가 발생했다. 즉, 다른 이미지가 A 이미지를 사용해서 이미지가 생성되었기 때문에 제거가 어렵다는 에러이다. 이를 해결하기 위해서 먼저 A 이미지를 부모로 두고 있는 자식 이미지를 확인해야 한다. 아래 명령어를 통해 A 이미지를 포함해 A 이미지 이후 생성된 모든 이미지들의 이미지 ID와 부모 ID를 출력할 수 있다. # a252344b0747 이미지(A)에 대해서 출력 docker inspect --format='{{.Id}} {{.Parent}}' $(docker images --filter since=a252344b0747 -q) 결과는 아래처럼 출력된다. 여기서 ..

docker의 이미지를 생성하다보면 Repository명과 Tag 값이 으로 기재된 dangling image가 생성된다. dangling image는 도커 이미지 생성 과정 중에서 에러가 발생하거나 중간에 중단되게 되면 생기는 이미지로 쓸모없는 부산물이다. 이미지 리스팅 시 보기 불편하기 때문에 정리를 해줄 필요가 있다. none image를 모두 제거하는 코드는 아래와 같다. docker rmi $(docker images -f "dangling=true" -q) 참조 https://web-front-end.tistory.com/102

도커 컨테이너를 detached mode (-d 옵션) 로 실행시킨 경우 백그라운드에서 실행되기 때문에 컨테이너 로그를 확인할 수 없다. 이 경우 아래의 명령어를 사용해 실행된 컨테이너의 지금까지 log 기록을 확인할 수 있다. docker container logs 컨테이너가 실행되었으면 아래와 같이 정상적으로 로그기록이 출력된다.