Docker-Compose를 사용하는 경우 및 Docker-Swarm을 사용하는 경우
D-Compose 와 D-Swarm 의 차이점이나 유사점을 이해하려고합니다 .
문서를 읽음으로써 docker-compose가 단일 서비스로 서로 다른 컨테이너를 함께 바인딩하고 공동 작업하는 메커니즘을 제공한다는 것을 이해했습니다 ( 두 컨테이너를 연결하는 데 사용되는 --link 명령 과 동일한 기능을 사용하고 있다고 생각합니다 ).
또한 docker-swarm에 대한 나의 이해는 각기 일부 docker-images의 여러 컨테이너 인스턴스를 실행하는 서로 다른 docker-hosts 클러스터를 관리 할 수 있다는 것 입니다. 떼에있는 서로 다른 컨테이너 간의 오버레이 네트워크 로 연결을 정의 하여 (스웜의 두 도커 호스트를 가로 지르더라도)이를 하나의 단위로 연결할 수 있습니다.
내가 이해하려는 것은 docker-swarm이 docker-compose에 성공했으며 오버레이 네트워크는 컨테이너를 연결하는 새로운 (권장) 방법입니까?
또는 docker-compose는 여전히 전체 docker 제품군의 필수 부분이며 컨테이너를 연결하여 협업하는 데 사용하는 것이 예상되고 권장됩니다. 그렇다면 docker-compose는 떼의 여러 노드에서 컨테이너와 함께 작동합니까 ??
아니면 오버레이 네트워크가 떼의 여러 호스트에 걸쳐 컨테이너를 연결하기위한 것이고 docker-compose는 내부 링크를 생성하기위한 것입니까 ??
게다가 도커 문서에서 --links 는 더 이상 권장되지 않으며 곧 폐기 될 것이라고 언급되어 있습니다.
좀 헷갈 리나요 ???
고마워요!
몇 가지 정의부터 시작하는 것이 도움이 될 것입니다.
- docker-compose : 관련 컨테이너 그룹을 구성하고 관리하는 데 사용되는 명령입니다. docker cli에서 사용하는 것과 동일한 API에 대한 프런트 엔드이므로
docker run. - docker-compose.yml : docker-compose 및 이제 swarm 모드에서 사용되는 컨테이너 그룹에 대한 정의 파일입니다.
- swarm 모드 : Docker 엔진 그룹을 단일 엔티티로 관리하고 오케스트레이션을 제공하는 데 사용됩니다 (현재 상태와 대상 상태 간의 차이를 지속적으로 수정하려고 시도 함).
- 서비스 : 스웜 내에서 동일한 이미지 및 구성에 대한 하나 이상의 컨테이너, 여러 컨테이너가 확장 성을 제공합니다.
- stack : 스웜 내의 하나 이상의 서비스. DAB 또는 docker-compose.yml 파일을 사용하여 정의 할 수 있습니다.
- 브리지 네트워크 : 여러 컨테이너가 서로 통신 할 수있는 단일 도커 엔진으로 관리되는 네트워크입니다. 엔진에 의해 관리되는 여러 네트워크가있을 수 있으며 컨테이너는 0 개 이상의 네트워크에 연결될 수 있습니다.
- 오버레이 네트워크 : 브리지 네트워크와 유사하지만 여러 도커 엔진에 걸쳐 있습니다. 상태를 유지하려면 키 / 값 저장소가 필요합니다. Swarm 모드는이를 제공하지만 swarm 모드가 비활성화 된 경우 etcd, consul 또는 zookeeper를 사용할 수도 있습니다.
- links : 브리지 된 네트워크보다 먼저 컨테이너를 연결하는 방법입니다. 더 이상 사용하지 않는 것이 좋습니다.
- 클래식 스웜 : 컨테이너로 실행되는 통합 스웜 모드의 이전 버전으로 여러 엔진을 하나로 표시 할 수 있지만 오케스트레이션을 제공하지 않거나 자체 k / v 저장소를 포함하지 않습니다.
질문에 답하려면 :
docker-swarm이 docker-compose에 성공했으며 오버레이 네트워크는 컨테이너를 연결하는 새로운 (권장) 방법입니까?
또는 docker-compose는 여전히 전체 docker 제품군의 필수 부분이며 컨테이너를 연결하여 협업하는 데 사용하는 것이 예상되고 권장됩니다. 그렇다면 docker-compose는 떼의 여러 노드에서 컨테이너와 함께 작동합니까 ??
그들은 다른 기능을 제공하며 둘 다 계속해서 목적을 제공 할 것입니다. docker-compose는 swarm 모드 내에서 컨테이너를 시작할 수 없지만 docker-compose 자체를 사용하지 않고 swarm 모드에서 직접 스택을 정의하는 데 최신 버전의 docker-compose.yml 파일 (버전 3)을 사용할 수 있습니다. docker-compose는 스웜 모드 외부, 단일 도커 엔진 또는 클래식 스웜으로 컨테이너를 관리하는 데 필요합니다.
아니면 오버레이 네트워크가 떼의 여러 호스트에 걸쳐 컨테이너를 연결하기위한 것이고 docker-compose는 내부 링크를 생성하기위한 것입니까 ??
게다가 도커 문서에서 --links는 더 이상 권장되지 않으며 곧 폐기 될 것이라고 언급되어 있습니다.
yml 파일의 버전 2부터 시작하는 docker-compose는 기본적으로 프로젝트 당 새로운 브리지 네트워크를 사용하여 여러 컨테이너를 함께 연결합니다 (프로젝트의 기본값은 디렉토리 이름입니다). 클래식 스웜의 경우 기본적으로 외부 k / v 저장소를 사용하는 오버레이 네트워크로 설정됩니다. 스웜 모드 스택을 사용하면 오버레이 네트워크가됩니다.
Docker 네트워크를 사용하는 것이 컨테이너가 서로 통신하도록하는 데 선호되는 방법입니다. 나머지 Docker 환경에서 격리하려는 컨테이너 그룹당 네트워크가 필요합니다. docker-compose는이 네트워크 생성을 자동화하지만 명령 줄에서 docker networks create.
연결은 DNS 검색이 내장 된 도커 네트워크로 대체되었습니다. docker-compose.yml에서 링크를 제거 할 때 depends_on컨테이너 시작 순서를 적용하기 위해 해당 링크를 섹션으로 바꿔야 할 수 있습니다 . 그렇지 않으면 링크가 의미있는 시나리오가 거의 없으며 내가 본 모든 사용법은 오래된 문서를 따르는 사람의 것입니다.
오버레이 네트워크를 구성하거나 무리를 짓거나 무리를 짓습니다
랩톱에서 데모 이외의 작업을 수행하는 경우 위의 모든 것을 사용해야한다는 것을 알게 될 것입니다.
두 가지를 모두 사용할 필요가 없기 때문에 의도적으로 스웜 및 스웜 오버레이 네트워크를 분리했지만 그 아래에 스웜이 없으면 오버레이 네트워크를 얻을 수 없습니다.
Compose는 여러 컨테이너를 함께 가져 오기위한 것입니다. 이제는 서로 관련이 있지만 그렇지 않을 수도 있습니다. 그러나 컨테이너가 서로 관련된 서비스를위한 일반적인 경우를 가정 해 보겠습니다. 그러면 컨테이너가 어떤 방식 으로든 서로 대화하되 네트워크를 사용하여 서로 대화하는 방법을 제어 할 수 있습니다. 예를 들어 웹 서버, appserver 및 db가있는 3 계층 앱을 사용합니다. 세 가지 구성 요소가 모두 고정되어 있고 compose를 사용하여 실행하는 대신 함께 가져오고 있다고 가정 해 보겠습니다.docker run..다른 매개 변수 등으로 세 번. 세 가지 모두 표시되지만 서로 연결하는 방식을 제어하고 싶을 것입니다. 웹 서버가 appserver와 통신 할 수 있도록하고 db와는 직접 통신하지 않기를 원합니다. 그리고 appserver가 db 서버 컨테이너와 통신 (ping)하고 웹 서버도 ping하도록 할 수 있습니다. 모든 연결은 양방향이지만 서로 통신 할 수있는 서비스로만 제한됩니다. 이러한 배열의 경우 일반적으로 frontend및 backend. 웹 및 앱 컨테이너는 프런트 엔드 네트워크에 연결됩니다. 앱 및 db 컨테이너는 백엔드 네트워크에 연결됩니다. db와 웹 컨테이너 사이에는 공통 네트워크가 없기 때문에 서로 접촉 (ping) 할 수 없습니다.
이제이 세 가지 서비스가 100 대의 머신 클러스터에서 실행될 수 있도록하고 이들을 통해 확장하려면 여러 호스트에 걸쳐있는 네트워크가 필요합니다. 이것이 바로 오버레이 네트워킹 (군집)이 등장하는 곳입니다. 오버레이 네트워킹은 VxLAN 기술을 기반으로 구축 된 멀티 호스트 네트워킹에 불과합니다. 거의 모든 최신 네트워킹 인프라에서 지원되는 표준 네트워크 토폴로지라는 점을 제외하고는 VxLAN에 대해 알 필요가 없습니다.
나는 그것이 명확하기를 바랍니다.
편집 : 나는 당신이 이미 대답을 얻지 못했다!
나는 당신이 각각에 대해 정확한 이해를 가지고 있다고 생각하지만 약간의 조정이 필요합니다.
당신은 올바른 docker-compose는 다중 컨테이너 응용 프로그램을 불러오는 것입니다. 이전에는 docker run ..모든 컨테이너를 시작 하는 데 사용했습니다 . 일반적으로 마이크로 서비스 패러다임을 수용하는 최신 애플리케이션은 수십 개의 서비스로 구성 될 수 있으며 사용 docker run ..은 곧 매우 지루해질 것입니다. 따라서 docker-compose를 사용하면 모든 컨테이너와 해당 속성 및 서로 연결하는 방법을 yaml또는 json파일로 표현할 수 있으므로 쉽게 관리 할 수 있습니다.
따라서 docker-compose는 docker 생태계의 컨테이너 오케스트레이션 부분입니다.
링크 그들은 단지 고정 표시기-작성하거나의 일부, 다른 docker run명령과 찬성되지 않습니다 software defined networks그 중 overlay networks입니다 그들 중 하나.
Swarm is the scheduling component in docker. What is scheduling - it is nothing but figuring out where to "place" your containers in your cluster of docker hosts. You can have a cluster of hundreds of servers, and you may have hundreds of containers, each encapsulating a service for a dozen different applications. Now how should these containers be distributed across your cluster of hundreds of servers, should some containers be placed only on certain hosts because they satisfy a particular criteria or maybe they should be closer to (or not) other containers which are somehow related... all these are part of the scheduling component which is performed by docker Swarm.
I suggest you go through the getting started documentation on docker.com here: https://docs.docker.com/engine/getstarted-voting-app/
ReferenceURL : https://stackoverflow.com/questions/42545431/when-to-use-docker-compose-and-when-to-use-docker-swarm
'Development Tip' 카테고리의 다른 글
| translate3d 대 번역 성능 (0) | 2020.12.30 |
|---|---|
| Windows에서 PostgreSQL을 시작하는 방법 (0) | 2020.12.30 |
| 브랜치가없는 태그에 대한 Git 커밋 (0) | 2020.12.30 |
| 블랙 박스 또는 화이트 박스 테스트가 테스터에게 강조되어야합니까? (0) | 2020.12.30 |
| 자바의 바코드 이미지 생성기 (0) | 2020.12.30 |