Docker 1.12의 첫 번째 릴리스 후보 를 통해 발표되었습니다. 2주 전. 몇 가지 새로운 기능은 다음과 같습니다.
이번 릴리스에서 계획된 것입니다.
이 블로그에서는 분산 애플리케이션 Docker Compose에서 번들을 생성하고 다음에서 Docker Stack으로 배포합니다. 도커 스웜 모드. 많은 분들께 감사드립니다. 프리즘 이러한 개념을 이해하는 데 도움을 주셨습니다.
먼저 기능을 살펴보겠습니다:
- 기본 제공 오케스트레이션: 일반적인 애플리케이션은 Docker Compose 파일을 사용하여 정의됩니다. 이 정의는 여러 컨테이너로 구성되며 여러 호스트에 배포됩니다. 이렇게 하면 단일 장애 지점(SPOF)을 방지하고 애플리케이션을 안정적으로 유지할 수 있습니다.
복원력. Docker Swarm, Kubernetes 및 Mesos와 같은 여러 오케스트레이션 프레임워크를 통해 이러한 애플리케이션을 오케스트레이션할 수 있습니다. 그러나 애플리케이션의 중요한 특성인 오케스트레이션을 위해 이제 Docker Engine에 오케스트레이션이 기본 제공됩니다.
이 주제에 대한 자세한 내용은 추후 블로그에서 확인할 수 있습니다. - 서비스: 다음을 사용하여 복제, 분산 및 로드 밸런싱된 서비스를 쉽게 만들 수 있습니다.
도커 서비스 생성명령을 실행합니다. 카우치베이스 컨테이너 3개 실행과 같은 애플리케이션의 '원하는 상태'가 제공되고
자가 복구 Docker 엔진은 클러스터에서 많은 컨테이너가 실행되도록 보장합니다. 컨테이너가 다운되면 다른 컨테이너가 시작됩니다. 노드가 다운되면 해당 노드의 컨테이너는 다른 노드에서 시작됩니다. 이에 대한 자세한 내용은 나중에
블로그. - 설정이 필요 없는 보안: Docker 1.12는 기본적으로 스웜에 참여하는 모든 노드의 통신에 인증, 권한 부여 및 암호화를 제공하는 상호 인증된 TLS와 함께 제공됩니다. 이에 대한 자세한 내용은
나중에 블로그에서 확인할 수 있습니다. - 도커 스택 및 분산 애플리케이션 번들: 분산 애플리케이션 번들(DAB)은 여러 서비스에 배포할 수 있는 이미지 형식입니다. 자세한 내용은 자세히 읽어보세요.
지금까지는 도커파일 를 사용하여 이미지를 만들고 도커 빌드 명령을 사용합니다. 컨테이너는 다음을 사용하여 시작할 수 있습니다. 도커 실행 명령어를 사용하세요. 여러 개의 컨테이너를 쉽게 시작할 수 있습니다.
명령을 여러 번 실행하세요. 또는 Docker Compose 파일을 사용하여 컨테이너를 확장할 수도 있습니다. 도커-컴포즈 스케일 명령을 사용합니다.
이미지는 단일 컨테이너의 이동 가능한 형식입니다. 분산 애플리케이션 번들또는 DAB는 Docker 1.12에 도입된 새로운 개념으로, 여러 컨테이너를 위한 이식 가능한 형식입니다. 각 번들은 다음과 같이 배포할 수 있습니다.
a 스택 런타임에.
DAB에 대해 자세히 알아보기 docker.com/dab. 간단히 설명하기 위해 비유를 들어보겠습니다:
도커파일 -> 이미지 -> 컨테이너
도커 컴포즈 -> 분산 애플리케이션 번들 -> 도커 스택
Docker Compose 파일을 사용하여 DAB를 생성하고, 이를 Docker Stack으로 배포해 보겠습니다.
이 기능은 1.12-RC2의 실험적 기능이라는 점에 유의하세요.
Docker Compose에서 분산 애플리케이션 번들 만들기
도커 컴포즈 CLI에 새로운 번들 명령어를 사용하세요. 자세한 내용은 여기에서 확인할 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 |
도커-작성 번들 --도움말 생성 a Docker 번들 에서 의 작성 파일. 로컬 이미지 will be 푸시 에 a Docker 레지스트리, 그리고 원격 이미지 will be 당겨짐 에 fetch an 이미지 다이제스트. 사용법: 번들 [옵션] 옵션: -o, --출력 PATH 경로 에 쓰기 의 번들 파일 에. 기본값 에 ".dsb". |
이제 Docker Compose 정의를 가져와서 DAB를 만들어 보겠습니다. 다음은 Docker Compose 정의입니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
버전: "2" 서비스: db: 컨테이너_이름: "db" 이미지: arungupta/oreilly-카우치베이스:최신 포트: - 8091:8091 - 8092:8092 - 8093:8093 - 11210:11210 웹: 이미지: arungupta/oreilly-wildfly:최신 depends_on: - db 환경: - COUCHBASE_URI=db 포트: - 8080:8080 |
이 Compose 파일은 WildFly와 Couchbase 서버를 시작합니다. WildFly 서버에 미리 배포된 Java EE 애플리케이션이 Couchbase 서버에 연결되고 REST API를 사용하여 CRUD 작업을 수행할 수 있습니다. 이 파일의 소스는 다음 위치에 있습니다:
github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml. 이를 사용하여 애플리케이션 번들을 생성합니다:
|
1 2 3 4 |
도커-작성 번들 경고: 지원되지 않음 키 'depends_on' in 서비스.웹 - 무시 경고: 지원되지 않음 키 '컨테이너_이름' in 서비스.db - 무시 작성 번들 에 헬로자비.dsb |
depends_on 는 두 서비스 간에 종속성만 생성하고 특정 순서로 시작하도록 합니다. 이렇게 하면 Docker 컨테이너만 시작되지만 컨테이너 내의 애플리케이션은 시작하는 데 시간이 더 오래 걸릴 수 있습니다. 따라서 이 속성은
를 사용하면 문제가 부분적으로 해결됩니다. 컨테이너_이름 는 컨테이너에 특정 이름을 부여합니다. 특정 컨테이너 이름에 의존하는 것은 긴밀한 결합이며 컨테이너를 확장할 수 없습니다. 따라서 두 경고를 모두 무시할 수 있습니다,
를 사용하세요. 이 명령은 디렉토리 이름인 Compose 프로젝트 이름을 사용하여 파일을 생성합니다. 따라서 우리의 경우 hellojavaee.dsb 파일이 생성됩니다. 이 파일 확장자는 다음과 같이 이름이 변경되었습니다. .dab 를 생성합니다. 생성된
애플리케이션 번들의 모습입니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
{ "서비스": { "db": { "이미지": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c", "네트워크": [ "default" ], "포트": [ { "Port": 8091, "프로토콜": "tcp" }, { "Port": 8092, "프로토콜": "tcp" }, { "Port": 8093, "프로토콜": "tcp" }, { "Port": 11210, "프로토콜": "tcp" } ] }, "웹": { "Env": [ "COUCHBASE_URI=db" ], "이미지": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914", "네트워크": [ "default" ], "포트": [ { "Port": 8080, "프로토콜": "tcp" } ] } }, "버전": "0.1" } |
이 파일은 애플리케이션에 포함된 서비스에 대한 전체 설명을 제공합니다. 분산 애플리케이션 번들이 가장 적절한 이름인지 잘 모르겠습니다. #24250. It
에서 Rkt나 VM과 같은 다른 컨테이너 형식도 지원할 수 있다면 좋을 것 같습니다. 하지만 현재로서는 Docker만이 지원되는 유일한 형식입니다.
도커에서 스웜 모드 초기화하기
위에서 언급했듯이, 이제 "원하는 상태"는 Docker Swarm에 의해 유지됩니다. 그리고 이것은 이제 이미 Docker 엔진에 베이크되어 있습니다. 도커 스웜 개념도 발전했으며 다음에서 확인할 수 있습니다. 스웜 모드 주요 개념. A
이에 대한 자세한 내용은 추후 블로그에서 확인할 수 있습니다. 하지만 이 블로그에서는 새로운 명령어 도커 스웜 가 추가되었습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
도커 swarm --도움말 사용법: 도커 swarm COMMAND 관리 Docker 스웜 옵션: --도움말 인쇄 사용법 명령: init 초기화 a 스웜 join 가입 a 스웜 as a 노드 그리고/또는 관리자 업데이트 업데이트 의 스웜 leave Leave a 스웜 검사 검사 의 스웜 실행 '도커 스웜 커맨드 --헬프' 에 대한 더 보기 정보 on a 명령. |
도커 엔진에서 스웜 노드(관리자로)를 초기화합니다:
|
1 2 |
도커 swarm init 스웜 초기화: 현재 노드 (ek9p1k8r8ox7iiua5c247skci) 는 지금 a 관리자. |
이 노드에 대한 자세한 내용은 다음을 사용하여 확인할 수 있습니다. 도커 노드 검사 자체 명령.
자세한 출력 내용은 장황하지만 관련 섹션은 다음과 같습니다:
|
1 2 3 4 5 |
"Spec": { "역할": "관리자", "멤버십": "accepted", "가용성": "active" }, |
출력은 노드가 매니저임을 보여줍니다. 단일 노드 클러스터의 경우 이 노드는 작업자 역할도 합니다.
클러스터에 대한 자세한 내용은 다음을 사용하여 얻을 수 있습니다. 도커 스웜 검사 명령을 사용합니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
도커 swarm 검사 [ { "ID": "1rcvu7m9mv2c8hiaijr7an9zk", "버전": { "색인": 1895 }, "CreatedAt": "2016-07-01T23:52:38.074748177Z", "UpdatedAt": "2016-07-02T04:54:32.79093117Z", "Spec": { "이름": "default", "수락 정책": { "정책": [ { "역할": "worker", "자동 수락": true }, { "역할": "관리자", "자동 수락": false } ] }, "오케스트레이션": { "작업 이력 유지 제한": 10 }, "Raft": { "스냅샷 간격": 10000, "LogEntriesForSlowFollowers": 500, "하트비트틱": 1, "ElectionTick": 3 }, "Dispatcher": { "하트비트 기간": 5000000000 }, "CAConfig": { "NodeCertExpiry": 7776000000000000 } } } ] |
수락 정책 는 다른 worker 노드는 이 클러스터에 참여할 수 있지만 관리자의 명시적인 승인이 필요합니다.
도커 스택 배포
다음을 사용하여 스택을 만듭니다. 도커 배포 명령을 사용합니다:
|
1 2 3 4 5 |
도커 배포 -f 헬로자비.dsb 헬로자비 로드 중 번들 에서 헬로자비.dsb 만들기 네트워크 헬로자바에_기본값 만들기 서비스 hellojavaee_db 만들기 서비스 헬로자바예_웹 |
명령 사용법은 다음에서 설명하는 것처럼 확실히 단순화할 수 있습니다. #24249. 서비스 목록을 참조하세요:
|
1 2 3 4 |
도커 서비스 ls ID 이름 복제 이미지 COMMAND 2G8KRIMZTE 헬로자비_웹 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 46XHLB15CC60 헬로자비_db 1/1 arungupta/oreilly-카우치베이스@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c |
출력에는 두 개의 서비스, 즉 WildFly와 Couchbase가 실행되고 있음을 보여줍니다. 서비스 도 도커 1.12에 도입된 새로운 개념입니다. 이 개념은
"원하는 상태"를 설정하면 Docker 엔진이 이를 제공합니다. 도커 PS 는 실행 중인 컨테이너 목록을 표시합니다:
|
1 2 3 |
컨테이너 ID 이미지 COMMAND 생성됨 상태 포트 이름 622756277f40 arungupta/oreilly-카우치베이스@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 초 전 Up 1 초 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29 abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 초 전 Up 1 초 8080/tcp 헬로자바예_웹.1.70piloz6j4zt06co8htzisgyl |
WildFly 컨테이너가 Couchbase 컨테이너가 실행되기 전에 시작됩니다. 즉, Java EE 애플리케이션이 Couchbase 서버에 연결을 시도하다가 실패합니다. 따라서 애플리케이션이 성공적으로 부팅되지 않습니다.
자가 치유 도커 서비스
Docker 서비스는 애플리케이션의 "원하는 상태"를 유지합니다. 이 경우 원하는 상태는 서비스에 대한 컨테이너가 하나만 실행되도록 하는 것입니다. 서비스가 아닌 컨테이너를 제거하면 서비스는 다음과 같이 됩니다.
컨테이너를 자동으로 다시 시작합니다. 컨테이너를 다음과 같이 제거합니다:
|
1 |
도커 rm -f abf8703ed713 |
참고, 다음 사항을 제공해야 합니다. -f 컨테이너가 이미 실행 중이기 때문입니다. Docker 1.12의 자가 복구 메커니즘이 시작되어 컨테이너가 자동으로 다시 시작됩니다. 이제 컨테이너를 다시 나열하면
|
1 2 3 |
컨테이너 ID 이미지 COMMAND 생성됨 상태 포트 이름 DB483AC27E41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 초 전 Up Less 보다 a second 8080/tcp 헬로자바예_웹.1.ddvwdmojjysf46d4n3x4g8uv4 622756277f40 arungupta/oreilly-카우치베이스@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 초 전 Up 25 초 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29 |
새 컨테이너가 시작되었음을 보여줍니다. WildFly 서비스를 검사합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 |
도커 서비스 검사 헬로자바예_웹 [ { "ID": "54otfi6dc9bis7z6gc6ubynwc", "버전": { "색인": 328 }, "CreatedAt": "2016-07-02T01:36:35.735767569Z", "UpdatedAt": "2016-07-02T01:36:35.739240775Z", "Spec": { "이름": "hellojavaee_web", "레이블": { "com.docker.stack.namespace": "hellojavaee" }, "작업 템플릿": { "ContainerSpec": { "이미지": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914", "Env": [ "COUCHBASE_URI=db" ] } }, "모드": { "복제": { "복제본": 1 } }, "네트워크": [ { "Target": "EPW57LZ7TXTTFCHMBF6U0CIMIS", "별칭": [ "웹" ] } ], "EndpointSpec": { "모드": "vip", "포트": [ { "프로토콜": "tcp", "TargetPort": 8080 } ] } }, "엔드포인트": { "Spec": {}, "포트": [ { "프로토콜": "tcp", "TargetPort": 8080, "게시된 포트": 30004 } ], "VirtualIPs": [ { "NetworkID": "9lpz688ir3pzexubkcb828ikg", "Addr": "10.255.0.5/16" }, { "NetworkID": "EPW57LZ7TXTTFCHMBF6U0CIMIS", "Addr": "10.0.0.4/24" } ] } } ] |
스웜은 서비스에 임의의 포트를 할당하거나 다음을 사용하여 수동으로 업데이트할 수 있습니다. 도커 서비스 업데이트 명령을 사용합니다. 이 경우 포트 8080 에 매핑된 컨테이너의 30004 포트에 연결합니다.
애플리케이션 확인
애플리케이션이 성공적으로 배포되었는지 확인합니다:
|
1 2 |
curl http://localhost:30004/books/resources/book [{"books":0}] |
애플리케이션에 새 책을 추가합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
curl -v > -H "콘텐츠 유형: 애플리케이션/json" > -X POST -d '{ > "isbn": "978-1-4919-1889-0", > "이름": "Forge로 마인크래프트 모딩", > "비용": 29.99 > }' > http://localhost:30004/books/resources/book * 시도 중 ::1... * 연결됨 에 localhost (::1) 포트 30004 (#0) > POST /책/리소스/책 HTTP/1.1 > 호스트: localhost:30004 > 사용자-에이전트: curl/7.43.0 > 수락: */* > 콘텐츠-유형: 애플리케이션/json > 콘텐츠-길이: 92 > * 업로드 완전히 보낸 꺼짐: 92 out 의 92 바이트 < HTTP/1.1 200 확인 < 연결: keep-살아있음 < X-전원-으로: 언더로우/1 < 서버: WildFly/10 < 콘텐츠-유형: 애플리케이션/옥텟-스트림 < 콘텐츠-길이: 88 < 날짜: Sat, 02 7월 2016 01:39:49 GMT < * 연결 로컬호스트를 호스트하는 #0은 그대로 유지됨 {"name":"Minecraft Mhttp://localhost:30004/books/resources/book-1-4919-1889-0"} |
장부를 다시 확인합니다:
|
1 2 |
curl http://localhost:30004/books/resources/book [{"books":{"name":"포지로 마인크래프트 모드 만들기","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}] |
이 Java EE 애플리케이션에 대한 자세한 내용은 다음에서 확인하세요. github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee.
이 블로그에서는 도커 컴포즈에서 분산 애플리케이션 번들을 생성하고 이를 도커 스웜 모드에서 도커 스택으로 배포하는 방법을 보여드렸습니다.
Docker 서비스 및 스택 참조
- 도커 서비스 만들기
- 오라일리에서 무료로 예약하세요: Java 개발자를 위한 Docker
- 컨테이너의 카우치베이스
- 카우치베이스 개발자 포털
- 다음에 대해 질문하세요. @couchbasedev 또는 스택오버플로우
