Docker Compose — 메모리 제한

애플리케이션의 다양한 워크로드를 처리하기 위해 다양한 컨테이너를 가동하고 이를 쉽게 수행하기 위해 Docker Compose를 사용합니다. 논리적으로 다른 각각의 워크로드는 서로 다른 워크로드로 나열됩니다. 서비스 . 예를 들어 프론트엔드 http 서버는 Apache 또는 Nginx 이미지를 컨테이너로 실행하는 프론트엔드 서비스로 나열됩니다.

모든 서비스, 네트워킹 요구 사항, 스토리지 요구 사항 등은 docker-compose.yml 파일에 지정할 수 있습니다. 여기서는 메모리 사용률을 지정하는 데 중점을 둘 것입니다.

따라가려면 무기고에 다음 도구가 필요합니다.

1. Docker에 대한 기본 이해
2. Windows 또는 Mac용 Docker 또는 Linux를 실행하는 경우 Linux용 DockerCE
3. Docker Compose 바이너리 y (Windows 및 Mac 사용자는 이미 설치되어 있을 것입니다)

Docker Engine 버전 17.12 이상을 지원하므로 docker-compose.yml 파일에 대해 버전 2.4를 고수할 것입니다. 우리는 최신 버전 3을 사용할 수 있었지만 이전 메모리 제한 구문을 지원하지 않습니다. 새로운 구문을 사용하려고 하면 대신 Swarm 모드에서 Docker를 사용하도록 주장합니다. 따라서 일반 Docker 사용자를 위해 문제를 간단하게 유지하기 위해 버전 2.4를 고수하겠습니다.

대부분의 코드는 버전 3에서 동일하게 작동하며 차이점이 있는 경우 Docker Swarm 사용자를 위한 최신 구문을 언급하겠습니다.

샘플 애플리케이션

먼저 CLI를 사용한 다음 간단한 docker-compose.yml을 사용하여 포트 80에서 간단한 Nginx 서비스를 실행해 보겠습니다. 다음 섹션에서는 메모리 제한과 활용도를 살펴보고 docker-compose.yml을 수정하여 사용자 지정 제한이 적용되는 방식을 확인합니다.

Docker-CLI를 사용하여 간단한 nginx 서버를 시작하겠습니다.

방문하면 nginx 서버가 작동하는 것을 볼 수 있습니다. http://localhost 또는 lcoalhost 교체

Docker 호스트의 IP 주소로. 이 컨테이너는 잠재적으로 Docker 호스트에서 사용 가능한 전체 메모리를 활용할 수 있습니다(이 경우 약 2GB). 무엇보다도 메모리 사용률을 확인하기 위해 다음 명령을 사용할 수 있습니다.

MEM USAGE/LIMIT는 총 1.934GiB 중 2.133MiB입니다. 이 컨테이너를 제거하고 docker-compose 스크립트 작성을 시작하겠습니다.

동등한 ym 파일

다음 단계를 따르면 위와 같은 정확한 컨테이너를 생성할 수 있습니다.

비어 있는 새 디렉토리를 만들고 그 안에 docker-compose.yml 파일을 만듭니다. 이 디렉토리에서 docker-compose up을 실행하면 이 특정 파일을 찾고(다른 모든 것은 무시) 그에 따라 배포를 생성합니다. 이 .yml 파일 안에 다음 내용을 추가합니다.

새로 생성된 컨테이너가 백그라운드에서 실행되도록 -d 플래그가 추가됩니다. 그렇지 않으면 터미널이 컨테이너에 연결되어 보고서 인쇄를 시작합니다. 이제 새로 생성된 컨테이너의 통계를 볼 수 있습니다.

비슷한 메모리 제한과 사용률로 이전과 유사한 컨테이너가 생성되었음을 알 수 있습니다. yml 파일이 포함된 동일한 디렉토리에서. 생성된 고객 브리지 네트워크와 함께 새로 생성된 컨테이너를 삭제하려면 다음 명령을 실행합니다.

이것은 생성된 볼륨을 제외하고 도커를 깨끗한 상태로 되돌립니다(우리는 생성하지 않았으므로 문제가 되지 않습니다).

메모리 제한 및 메모리 예약

메모리 제한 및 메모리 예약은 애플리케이션과 실행 중인 Docker 호스트의 원활한 기능을 보장하기 위한 두 가지 측면입니다.

일반적으로 메모리 제한은 Docker 컨테이너에서 잠재적으로 사용할 수 있는 메모리 양에 대한 상한을 부과합니다. 기본적으로 Docker 컨테이너는 다른 시스템 프로세스와 마찬가지로 Docker 호스트의 사용 가능한 전체 메모리를 사용할 수 있습니다. 이로 인해 메모리 부족 예외가 발생할 수 있으며 시스템이 충돌할 수 있습니다. 그렇게 하지 않더라도 다른 프로세스(다른 컨테이너 포함)를 귀중한 리소스에서 굶주리게 하여 다시 성능을 저하시킬 수 있습니다. 메모리 제한은 리소스가 부족한 컨테이너가 특정 제한을 초과하지 않도록 합니다. 이것은 잘못 작성된 애플리케이션의 폭발 반경을 전체 호스트가 아닌 몇 개의 컨테이너로 제한합니다.

반면에 메모리 예약은 덜 엄격합니다. 시스템이 메모리 부족으로 실행 중이고 일부를 회수하려고 할 때. 컨테이너의 메모리 사용량을 예약 제한 이하로 가져오려고 합니다. 그러나 메모리가 충분하면 애플리케이션이 하드 설정된 메모리 제한까지 확장될 수 있습니다.

요약:

1. 메모리 제한: 컨테이너에서 사용할 수 있는 메모리 양에 대한 엄격한 상한입니다.
2. 메모리 예약: 애플리케이션이 제대로 실행되는 데 필요한 최소 메모리 양으로 설정해야 합니다. 따라서 시스템이 일부 메모리를 회수하려고 할 때 충돌하거나 오작동하지 않습니다.

메모리 예약이 메모리 제한보다 크면 메모리 제한이 우선합니다.

메모리 제한 및 예약 지정

버전 2

이전에 작성한 docker-compose.yml로 돌아가서 메모리 제한을 추가해 보겠습니다. 전제 조건 섹션에서 설명한 이유로 버전을 2.4로 변경하십시오.

마지막 줄은 my-nginx 서비스에 대한 제한을 300MiB로 설정합니다. KiB에는 k를, GiB에는 g를, 바이트 단위에는 b를 사용할 수 있습니다. 그러나 그 앞의 숫자는 정수여야 합니다. 2.4m와 같은 값을 사용할 수 없으며 대신 2400k를 사용해야 합니다. 이제 다음을 실행하면:

메모리 제한이 300MiB로 설정되어 있음을 알 수 있습니다. 메모리 예약을 설정하는 것도 마찬가지로 쉽습니다. 끝에 mem_reservation: xxx 행을 추가하기만 하면 됩니다.

버전 3(선택 사항)

버전 3을 사용하려면 Swarm 모드에서 Docker를 실행해야 합니다. Windows 및 Mac의 경우 Docker 설정 메뉴를 사용하여 활성화할 수 있습니다. Linux 사용자는 docker swarm init를 실행해야 합니다. 그것에 대한 자세한 정보는 찾을 수 있습니다 여기 . 그러나 필요한 단계는 아니며 활성화하지 않은 경우에도 괜찮습니다. 이 섹션은 사람들을 위한 것입니다. 이미 Swarm 모드에서 실행되며 최신 버전을 사용할 수 있습니다.

리소스 옵션에서 이 모든 것을 정의합니다. 제한 및 예약은 자체의 기본 키가 되며 메모리는 여기에서 관리되는 많은 리소스 중 하나에 불과합니다. CPU는 또 다른 중요한 매개변수입니다.

추가 정보

공식 문서에서 docker-compose에 대해 자세히 알아볼 수 있습니다. 여기에 링크 . 작성 파일을 작성하는 방법에 대한 요점을 알게 되면 문서에서 다양한 매개변수에 대한 구체적인 정보를 얻을 수 있습니다.

모든 것을 알 필요는 없습니다. 애플리케이션에 필요한 것을 검색하기만 하면 참조가 이를 구현하는 데 도움이 됩니다.