권장 사항은 운영 체제 수준 가상화 의 목표와 디자인에서 비롯됩니다.
컨테이너는 자체 사용자 공간 과 파일 시스템 을 제공하여 다른 프로세스를 분리하도록 설계되었습니다 .
이것은 논리적으로 진화 chroot된 파일 시스템으로, 다음 단계는 메모리 덮어 쓰기를 피하고 충돌없이 여러 프로세스에서 동일한 리소스 (예 : TCP 포트 8080)를 사용할 수 있도록 프로세스를 다른 프로세스와 격리하는 것입니다.
컨테이너에 대한 주요 관심은 버전 충돌에 대해 걱정하지 않고 프로세스에 필요한 라이브러리를 패키지화하는 것입니다. 동일한 사용자 공간과 파일 시스템에서 동일한 라이브러리의 두 가지 버전이 필요한 다중 프로세스를 실행하는 경우 각 프로세스에 대해 최소한 LDPATH를 조정하여 적절한 라이브러리를 먼저 찾아야하며 일부 라이브러리는이 방법으로 조정할 수 없습니다. 컴파일 타임에 실행 파일에 경로가 하드 코딩되어 있기 때문에 자세한 내용 은 이 SO 질문 을 참조하십시오.
네트워크 수준에서는 동일한 포트를 사용하지 않도록 각 프로세스를 구성해야합니다.
동일한 컨테이너에서 여러 프로세스를 실행하려면 약간의 조정이 필요하며 하루가 끝나면 동일한 사용자 공간 내에서 여러 프로세스를 실행하고 동일한 파일 시스템 및 네트워크 리소스를 공유하는 것이 좋습니다. 호스트 자체에서?
내가 생각할 수있는 무거운 조정 / 함정에 대한 철저한 목록은 다음과 같습니다.
로그 처리
볼륨이 마운트되어 있거나 표준 출력에 인터리브되어 있으면 어느 정도 관리 할 수 있습니다. 탑재 된 볼륨을 사용하는 경우 컨테이너에 호스트에 자체 "장소"가 있어야하거나 동일한 컨테이너 두 개가 동일한 리소스를 놓고 싸울 것입니다. stdout에 인터리빙 할 때 docker logs소스를 쉽게 식별 할 수 없다면 분석을 위해 악몽이 될 수 있습니다.
좀비 프로세스주의
컨테이너가 충돌하는 프로세스 중 하나 인 경우 감독자는 자식을 좀비 상태로 정리하지 못할 수 있으며 호스트 초기화는 절대로 자식을 상속하지 않습니다. 사용 가능한 pid 수 (2 ^ 22이므로 약 4 백만 개)를 다 사용하면 많은 문제가 발생합니다.
우려의 분리
동일한 컨테이너 내에서 Apache 서버 및 logstash와 같이 분리 된 두 가지를 실행하면 로그 처리가 쉬워 지지만 logstash를 업데이트하려면 Apache를 종료해야합니다. (실제로 Docker의 로깅 드라이버를 사용해야합니다) 현재 세션이 종료되기를 기다리는 것이 정상적입니까? 정상적으로 멈 추면 새 버전을 출시하는 데 시간이 오래 걸리고 시간이 오래 걸릴 수 있습니다. 강제 종료하면 로그 발송자에게 영향을 미치며 IMHO는 피해야합니다.
마지막으로 여러 프로세스가있는 경우 OS를 재생하는 것이며,이 경우 하드웨어 가상화를 사용하면 이러한 요구에 더 잘 맞습니다.