컨테이너 '혁명'으로 앱은 단순한 데이터베이스 및 프론트엔드 그 이상으로 성장했습니다. 애플리케이션은 다양한 마이크로서비스로 분할되며 일반적으로 REST API(일반적으로 HTTP를 통한 JSON 형식 페이로드)를 통해 서로 통신합니다. Docker 컨테이너는 이러한 종류의 아키텍처에 이상적입니다. 프론트엔드 '마이크로서비스'를 Docker 컨테이너에 패키징할 수 있으며, 데이터베이스는 다른 컨테이너로 이동하는 식입니다. 각 서비스는 단일 소프트웨어로 작성된 모놀리스가 아니라 사전 정의된 REST API를 통해 다른 서비스와 통신합니다.
예를 들어 분석 엔진과 같은 새로운 기능을 구현해야 하는 경우 이를 위한 새로운 마이크로 서비스를 작성하면 됩니다. 그러면 웹 앱의 다양한 마이크로 서비스에서 노출되는 REST API를 통해 데이터를 소비하게 됩니다. 그리고 시간이 지남에 따라 기능이 성장함에 따라 이 마이크로서비스 목록도 함께 증가할 것입니다.
각 개별 컨테이너를 배포하고 구성한 다음 다른 모든 컨테이너와 통신하도록 구성하고 싶지는 않습니다. 컨테이너가 세 개라도 지루할 것입니다. Docker-Compose를 사용하면 여러 컨테이너의 배포를 자동화할 수 있습니다.
Docker-Compose는 마이크로서비스의 추상적인 아이디어를 Docker 컨테이너의 기능적 세트로 변환하는 데 도움이 되는 가장 간단한 도구 중 하나입니다.
분산 시스템
이제 웹 앱을 여러 컨테이너로 분할했기 때문에 Docker Swarm 및 Kubernetes와 같은 서비스가 작동하는 단일 서버에 모두 보관하는 것은 의미가 없습니다.
Docker Swarm을 사용하면 여러 서버에서 애플리케이션의 여러 복제본을 실행할 수 있습니다. 마이크로 서비스가 '수평적으로' 확장할 수 있는 방식으로 작성된 경우 Docker Swarm을 사용하여 여러 데이터 센터와 여러 지역에 웹 앱을 배포할 수 있습니다. 이것은 하나 이상의 데이터 센터 또는 네트워크 링크의 장애에 대한 복원력을 제공합니다. 이는 일반적으로 Docker의 하위 명령, 즉 Docker Stack을 사용하여 수행됩니다.
NS 도커 스택 하위 명령은 Docker-Compose 명령과 훨씬 유사하게 작동하므로 두 기술 중 하나를 사용하는 사람이 오해할 수 있습니다.
혼란의 근원
사용 및 워크플로 측면에서 두 기술은 서로 매우 유사하게 작동하며 이로 인해 혼란이 발생합니다. Docker Swarm 또는 Docker-Compose를 사용하여 앱을 배포하는 방법은 매우 유사합니다. YAML 파일에서 애플리케이션을 정의하면 이 파일에는 이미지 이름, 각 이미지에 대한 구성 및 각 마이크로서비스가 배포 시 충족해야 하는 규모(복제본 수)가 포함됩니다.
차이점은 대부분 백엔드에 있습니다. docker-compose는 단일 Docker 호스트에 컨테이너를 배포하고 Docker Swarm은 여러 노드에 컨테이너를 배포합니다. 느슨하게 말하면 여전히 docker-compose가 할 수 있는 대부분의 작업을 수행할 수 있지만 여러 Docker 호스트에 걸쳐 확장합니다.
유사점
Docker Swarm과 Docker-Compose는 모두 다음과 같은 유사점이 있습니다.
- 둘 다 애플리케이션 스택의 YAML 형식 정의를 사용합니다.
- 둘 다 다중 컨테이너 애플리케이션(마이크로서비스)을 처리하기 위한 것입니다.
- 둘 다 동일한 이미지의 여러 컨테이너를 실행하여 마이크로서비스를 수평으로 확장할 수 있는 확장 매개변수가 있습니다.
- 둘 다 동일한 회사(예: Docker, Inc.)에서 유지 관리합니다.
차이점
Docker Swarm과 Docker-Compose의 몇 가지 차이점은 다음과 같습니다.
- Docker Swarm은 하나 이상의 서버에서 웹 앱을 확장하는 데 사용됩니다. Docker-compose는 단순히 단일 Docker 호스트에서 웹 앱을 실행합니다.
- 웹 앱 확장 Docker Swarm은 심각한 고가용성과 내결함성을 제공합니다. 단일 호스트에서 Docker-Compose를 사용하여 웹 앱을 확장하는 것은 테스트 및 개발에만 유용합니다.
- Docker Swarm 및 Docker Swarm 및 Docker Stack과 같은 관련 하위 명령은 Docker CLI 자체에 내장되어 있습니다. 그것들은 모두 터미널을 통해 호출하는 Docker 바이너리의 일부입니다. Docker-Compose는 그 자체로 독립 실행형 바이너리입니다.
Docker-Compose 사용 사례
위에서 설명한 것처럼 둘 다 완전히 다른 도구이며 각각 완전히 다른 문제를 해결하므로 하나가 다른 하나의 대안이 아닌 것 같습니다. 그러나 새로운 사용자에게 내가 말하는 내용을 이해할 수 있도록 Docker Compose의 사용 사례가 있습니다.
단일 서버에서 WordPress 블로그를 자체 호스팅한다고 가정합니다. 수동으로 설정하거나 유지 관리하고 싶지 않은 작업이므로 VPS에 Docker 및 Docker-compose를 설치하고 아래와 같이 WordPress 스택의 모든 다양한 측면을 정의하는 간단한 YAML 파일을 만듭니다. :
참고: 아래를 사용하여 WordPress 사이트를 배포하는 경우 모든 비밀번호를 안전한 것으로 변경하십시오. 더 나은 방법은 Docker Secrets를 사용하여 일반 텍스트 파일에 저장하는 대신 암호와 같은 민감한 데이터를 저장하는 것입니다.
버전:'삼'서비스:
데이터베이스:
이미지: mysql:5.7
볼륨:
- db_data:/어디/라이브러리/mysql
다시 시작: 항상
환경:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: 워드프레스
MYSQL_USER: 워드프레스
MYSQL_PASSWORD: 워드프레스
워드프레스:
의존:
- DB
이미지: 워드프레스:최신
포트:
-'8000: 80'
다시 시작: 항상
환경:
워드프레스_DB_호스트: DB:3306
WORDPRESS_DB_USER: 워드프레스
WORDPRESS_DB_PASSWORD: 워드프레스 비밀번호
WORDPRESS_DB_NAME: 워드프레스
볼륨:
데이터베이스 데이터:{}
파일이 생성되고 Docker와 Docker-compose가 모두 설치되면 다음을 실행하기만 하면 됩니다.
$도커 구성-NS그리고 귀하의 사이트는 가동될 것입니다. 업데이트가 있는 경우 다음을 실행합니다.
$도커 작성 다운그런 다음 이전 Docker 이미지를 버리고 docker-compose up -d 명령을 실행하면 새 이미지가 자동으로 가져옵니다. Docker 볼륨에 영구 데이터가 저장되어 있으므로 웹사이트의 콘텐츠가 손실되지 않습니다.
Docker Swarm을 사용하는 경우
Docker-compose는 자동화 도구에 가깝지만 Docker Swarm은 더 까다로운 애플리케이션을 위한 것입니다. 수백 또는 수천 명의 사용자가 있는 웹 앱 또는 병렬로 확장해야 하는 워크로드. 대규모 사용자 기반과 엄격한 SLA 요구 사항이 있는 회사는 Docker Swarm과 같은 분산 시스템을 사용하기를 원할 것입니다. 앱이 여러 서버와 여러 데이터 센터에서 실행 중인 경우 영향을 받는 DC 또는 네트워크 링크로 인한 다운타임 가능성이 크게 줄어듭니다.
하지만 Kubernetes와 같은 경쟁 기술이 이 작업에 더 적합하기 때문에 프로덕션 사용 사례에 Docker Swarm을 권장하는 것을 주저합니다. Kubernetes는 많은 클라우드 제공업체에서 기본적으로 지원되며 Docker 컨테이너와 매우 잘 작동하므로 Kubernetes를 활용하기 위해 앱을 다시 빌드할 필요도 없습니다.
결론
Docker 및 해당 위성 프로젝트에 대한 이 횡설수설이 유익한 정보가 되었기를 바랍니다.