도커_실행 중인 Docker 컨테이너의 구성을 수정하는 방법

출처: https://ko.linux-console.net/?p=7811#gsc.tab=0

Docker 컨테이너는 일단 실행되기 시작하면 일반적으로 변경할 수 없는 것으로 취급됩니다. 그러나 컨테이너 이름 및 하드웨어 리소스 제한과 같은 일부 구성 매개변수를 동적으로 업데이트할 수 있습니다.

이 가이드에서는 기본 제공 Docker 명령을 사용하여 실행 중인 컨테이너의 선택된 매개변수를 수정하는 방법을 보여줍니다. 또한 변경해서는 안 되는 항목과 변경해야 한다고 생각되는 경우 사용할 수 있는 해결 방법도 살펴봅니다.

컨테이너 이름 바꾸기

가장 간단한 수정은 생성된 컨테이너의 이름을 바꾸는 것입니다. 이름은 docker run에 대한 --name 플래그를 통해 할당됩니다. 이름이 제공되지 않으면 Docker 데몬이 임의의 이름을 할당합니다. 이름을 사용하여 Docker CLI 명령에서 컨테이너를 참조할 수 있습니다. 적절하고 기억하기 쉬운 것을 선택하면 컨테이너의 자동 할당 이름 또는 ID를 찾기 위해 docker ps를 실행하지 않아도 됩니다.

docker rename 명령은 생성 후 컨테이너 이름을 변경하는 데 사용됩니다. 대상 컨테이너의 ID 또는 현재 이름과 할당할 새 이름의 두 가지 인수를 사용합니다.

# docker rename <target ID or name> <new name>
docker rename old_name new_name

재시작 정책 변경

다시 시작 정책은 호스트가 재부팅된 후 또는 Docker 데몬이 시작된 후 컨테이너가 자동으로 시작되어야 하는지 여부를 결정합니다. 사용 가능한 네 가지 정책을 사용하면 컨테이너를 강제로 시작하거나 중지된 상태로 유지하거나 컨테이너의 이전 종료 코드 또는 실행 상태를 기반으로 조건부로 시작할 수 있습니다.

 

Docker는 즉시 재시작 정책 변경을 지원합니다. 이는 호스트 또는 Docker 데몬을 재부팅할 계획이고 특정 이벤트 후에 특정 컨테이너를 중지된 상태로 유지하거나 자동으로 시작하려는 경우에 유용합니다.

docker update --restart unless-stopped demo_container

위의 예는 demo_container의 재시작 정책을 unless-stopped로 변경합니다. 이 정책은 데몬이 마지막으로 종료되기 전에 수동으로 중지되지 않은 경우 컨테이너가 데몬과 함께 시작되도록 합니다.

하드웨어 리소스 제한 변경

docker update 명령을 사용하여 컨테이너에 적용되는 리소스 제한을 변경할 수도 있습니다. 해당 컨테이너에 설정할 제한을 정의하는 플래그 목록과 함께 하나 이상의 컨테이너 ID 또는 이름을 전달해야 합니다.

플래그는 docker run에서 지원하는 모든 리소스 제한에 사용할 수 있습니다. 사용할 수 있는 옵션의 요약 목록은 다음과 같습니다.

• --blkio-weight – 컨테이너의 블록 IO 상대 가중치를 변경합니다.
• --cpus – 컨테이너에서 사용할 수 있는 CPU 수를 설정합니다.
• --cpu-shares – CPU 공유 상대적 가중치를 설정합니다.
• --memory – 컨테이너의 메모리 제한을 변경합니다(예: 1024M).
• --memory-swap – 컨테이너가 디스크로 스왑할 수 있는 메모리 양을 구성합니다. 1024M과 같은 크기를 사용하여 특정 제한을 설정하거나 -1을 무제한 스왑에 사용하십시오.
• --kernel-memory – 컨테이너의 커널 메모리 제한을 변경합니다. 커널 메모리가 부족한 컨테이너는 호스트 시스템의 다른 워크로드에 부정적인 영향을 미칠 수 있습니다.
• --pids-limit – 컨테이너 내에서 허용되는 최대 프로세스 ID 수를 구성하여 시작할 수 있는 프로세스 수를 제한합니다.

다음은 docker update를 사용하여 두 컨테이너의 메모리 제한 및 CPU 수를 변경하는 예입니다.

docker update --cpus 4 --memory 1024M first_container second_container

--kernel-memory를 제외한 사용 가능한 모든 플래그는 Linux 컨테이너를 실행하는 데 사용할 수 있습니다. 커널 메모리 제한을 변경하려면 먼저 docker stop으로 컨테이너를 중지해야 합니다.

이러한 플래그는 현재 Windows 기반 컨테이너에서 지원되지 않습니다. 하지만 Windows 호스트 시스템에서 실행되는 Linux 컨테이너와 함께 작동합니다.

이 명령을 사용하지 않는 경우는 언제입니까?

docker update 및 docker rename 명령은 docker run을 통해 수동으로 만든 컨테이너와 함께 사용해야 합니다. docker-compose와 같은 다른 도구에서 비롯된 컨테이너와 함께 사용하는 것에 주의하세요.

컨테이너의 이름을 변경하면 소스 도구에서 감지할 수 없게 되어 스택의 다른 구성 요소가 손상될 수 있습니다. 또한 docker-compose.yml 파일에서 리소스 제한을 선언적으로 정의하는 경우 docker-compose up 명령을 다시 실행하면 해당 원래 제한이 다음에 다시 적용됩니다. 당신의 컨테이너.

 

따라서 기존 컨테이너 관리 솔루션을 사용하는 경우 이를 고수해야 합니다. Compose의 경우 이는 docker-compose.yml 파일에서 컨테이너 이름과 리소스 제한을 변경한 다음 docker-compose up -d를 실행하여 변경 사항을 자동으로 적용하는 것을 의미합니다. 이렇게 하면 의도치 않게 컨테이너를 분리하거나 의도하지 않은 부작용을 일으키지 않습니다.

다른 속성(이미지/포트/볼륨)은 어떻습니까?

하드웨어 제한, 리소스 정책 및 컨테이너 이름은 Docker CLI에서 변경할 수 있는 유일한 구성 매개 변수입니다. 실행 중인 컨테이너의 이미지는 수정할 수 없습니다. 포트 바인딩 및 볼륨과 같은 다른 옵션도 쉽게 변경할 수 없습니다.

이러한 값이 오래되면 다른 컨테이너를 만들어야 합니다. 현재 인스턴스를 삭제하고 docker run을 사용하여 새 이미지와 수정된 설정으로 대체를 시작합니다.

컨테이너는 상태 비저장 및 휘발성이므로 언제든지 교체할 수 있어야 합니다. 볼륨을 사용하여 영구 컨테이너 데이터를 저장합니다. 이 메커니즘을 사용하면 원래 docker run 명령에 전달된 -v 플래그를 반복하여 상태 저장 파일을 새 컨테이너에 다시 연결할 수 있습니다.

docker run -v config-volume:/usr/lib/config --name demo example-image:v1

docker rm demo

# Existing data in /usr/lib/config retained
docker run -v config-volume:/usr/lib/config --name demo2 example-image:v2

위험 구역: 기타 컨테이너 속성 변경

가능한 한 컨테이너를 교체하는 것을 목표로 해야 하지만 Docker의 구성 파일을 직접 편집하여 기존 컨테이너의 속성을 수정할 수 있습니다. 이 방법을 사용할 때는 주의하세요. 완전히 지원되지 않으며 잘못 배치된 변경으로 인해 컨테이너가 손상될 수 있습니다.

이 옵션은 기존 컨테이너를 임의로 편집하는 방법을 제공하지만 실행 중에는 작동하지 않습니다. docker stop my-container 명령을 사용하여 편집하려는 컨테이너를 중지한 다음 계속 변경합니다.

컨테이너 구성 파일의 호스트 경로는 다음과 같습니다.

/var/lib/docker/containers/<container id>/config.v2.json

docker ps에 표시된 잘린 버전이 아니라 컨테이너의 전체 ID를 알아야 합니다. docker inspect 명령을 사용하여 다음을 얻을 수 있습니다.

docker inspect <short id or name> | jq | grep Id

컨테이너의 config.v2.json에 도달하면 텍스트 편집기에서 컨테이너를 열어 필요한 변경을 수행할 수 있습니다. JSON은 docker run을 실행할 때 생성된 컨테이너 구성을 저장합니다. 내용을 수정하여 포트 바인딩, 환경 변수, 볼륨, 컨테이너 진입점 및 명령과 같은 속성을 변경할 수 있습니다.

포트 바인딩을 추가하려면 파일에서 PortBindings 키를 찾은 다음 개체에 새 항목을 삽입합니다.

{
    "PortBindings": {
        "80/tcp": {
            "HostIp": "",
            "HostPort": "8080"
        }
    }
}

 

여기서 컨테이너의 포트 80은 호스트의 포트 8080에 바인딩됩니다. 환경 변수를 추가하는 것도 마찬가지로 간단합니다. Env 키를 찾은 다음 배열에 새 항목을 삽입합니다.

{
    "Env": [
        "FOO=bar",
        "CUSTOM_VARIABLE=example"
    ]
}

편집을 마치면 Docker 서비스와 컨테이너를 다시 시작합니다.

sudo service docker restart

docker start my-container

이제 컨테이너가 업데이트된 구성으로 실행됩니다.

결론

Docker 컨테이너는 구성이 오래되었을 때 교체하는 임시 단위입니다. 이러한 의도에도 불구하고 기존 컨테이너를 수정해야 하는 시나리오가 있습니다. Docker는 docker update와 같은 내장 CLI 명령을 통해 가장 일반적인 사용 사례(이름 변경 및 실시간 리소스 제한 조정)를 처리합니다.

다른 속성을 변경하려는 경우 항상 첫 번째 조치로 컨테이너를 교체하십시오. 이는 파손 위험을 최소화하고 Docker의 불변성 모델과 일치합니다. 기존 컨테이너를 편집해야 하는 상황이 발생하면 위에 설명된 대로 Docker의 내부 구성 파일을 수동으로 변경할 수 있습니다.

마지막으로 Docker Compose와 같은 다른 생태계 도구에서 관리하는 컨테이너는 이러한 메커니즘을 사용하여 수정해야 한다는 점을 기억하십시오. 그렇지 않으면 도구가 변경 사항을 인식하지 못하는 경우 컨테이너가 예기치 않게 분리되거나 덮어쓰여질 수 있습니다.