도커 개요와 개발 방법론

Docker Overview

• 지난 시간까지 우리는 도커를 사용하여 기본적인 사용법과 문법을 익혔습니다.

• 지금부터는 도커의 동작원리와 내부 기술이 어떻게 구성되어 있는지 차근차근 알아가보도록 하겠습니다.

• 도커는 응용 프로그램을 개발, 배포, 실행하기 위한 개방형 플랫폼입니다. 도커를 사용하면 인프라에서 응용 프로그램을 분리하여 신속하게 소프트웨어를 제공할 수 있습니다.

• 도커를 사용하면 응용 프로그램을 관리하는 것과 같은 방법으로 인프라를 관리할 수 있으며, 코드를 신속하게 개발하고 테스트하는 방법을 도커를 통해 실제 운영환경과 개발환경의 차이를 크게 줄일 수 있습니다.

• 도커는 Go언어를 기반으로 개발되었습니다.

Docker 플랫폼

• 도커는 컨테이너라고 하는 환경에서 응용 프로그램을 패키지화 하고, 실행할 수 있는 기능을 제공합니다.

• 격리 및 보안을 통해 주어진 호스트에서 여러 컨테이너를 동시에 실행할 수 있으며, 추가적인 하이퍼바이저 환경에서 구동하지 않기 때문에 경략적으로 시스템 커널에서 실행한다는 장점을 가지고 있습니다.

• 물론 하이퍼바이저 환경에서 도커환경을 구축하여 실행하는 것도 가능하며, 도커는 컨테이너의 수명주기를 관리할 수 있는 기능을 제공합니다.

  • 컨테이너를 사용하여 애플리케이션 및 자원 구성 요소를 개발할 수 있습니다.

  • 컨테이너는 응용 프로그램을 배포하고 테스트하는 단위가 됩니다.

  • 모든 준비가 완료되면 응용 프로그램을 컨테이너, 혹은 통합 서비스로 실제 서비스 환경에서 배포할 수 있습니다. 이러한 환경은 클라우드 환경, 로컬 서버, 하이브리드 서버 등의 여부와 상관없이 동일하게 동작합니다.

    

하이브리드 서버와 일반 가상화 서버 환경과 동일하다고 생각하면 안됩니다. 기본적으로 가상화 머신에서는 vCPU라는 기술을 사용하는데 이는 물리코어에 비해서 많은 가상 프로세스를 할당할 수 있지만 물리적으로 이런한 vCPU는 실제 코어에 1:1로 맵핑되는 관계가 아닌 타임슬라이스에 따라서 논리적으로 많은 프로세스가 동작하는 것 처럼 보이기 때문에 많은 vCPU가 할당되게 되면 많은 오버헤드가 발생하여 성능을 떨어진다는 단점을 가지고 있습니다.

하이퍼바이저를 사용할 때는 이러한 점을 충분히 숙지하고 사용해야 합니다. 몇몇 하이퍼바이저는 최대 할당 CPU 코어수를 제한함으로서 발생할 수 있는 문제를 미연에 방지 하고 있으며 이러한 환경에서 VM환경을 구축하고자 할 때는 하드웨어 사양과 하이퍼바이저의 특성을 충분히 숙지하고 운영하는 것을 추천합니다.

Docker Engine

• 도커 엔진은 기본적으로 클라이언트 - 서버 응용 프로그램입니다.

  

• CLI는 도커 REST API를 사용하여 스크립트 또는 CLI 명령을 통해 도커 데몬을 제어하고 상호작용 합니다.

• 많은 도커 응용 프로그램이 기본 CLI 명령어를 사용합니다.

  도커는 Apache 2.0 오픈소스 라이센스를 사용합니다.

What can I use Docker for?

애플리케이션의 신속한 개발과 일관성

• 도커는 개발자가 응용 프로그램 및 서비스를 제공하는 로컬 컨테이너를 사용하여 표준화된 사용자 환경에서 작업할 수 있기 때문에 개발 수명 주기를 간소화 할 수 있습니다.

  • 실제로 개발을 하게 되면 서로 다른 개발 환경으로 인해 환경 셋팅을 하는 시간이 많이 소요됩니다.

  • 도커는 일관성있고 동일한 개발환경을 제공하기 때문에 이러한 시간을 단축시켜 줍니다.

• 컨테이너는 통합 및 전달과 같은 작업 환경에서 매우 유용하게 사용될 수 있습니다.

• 다음 도커를 사용하는 시나리오를 살펴보세요.

  • 개발자는 코드를 로컬에서 작성하고 도커 컨테이너를 사용하여 동료와 작업을 공유할 수 있습니다.

  • 도커를 사용하여 응용 프로그램을 테스트 환경에서 적용하여 자동화 또는 수동적으로 테스트를 진행할 수 있습니다.

  • 개발자가 버그를 발견하면 개발 환경에서 버그를 수정하고, 검증을 위해 테스트 환경에서 재배포 할 수 있습니다.

  • 모든 테스트가 완료되고 실제환경에서 배포할 때는 아주 간단하게 사용할 수 있습니다.

응답성 있는 배포 및 확장

• 도커 컨테이너의 기반 플랫폼은 이동성이 뛰어나기 때문에 개발자의 PC, 로컬 서버, 클라우드 서버에 상관없이 일관성 있게 여러 환경에서 실행할 수 있습니다.

• 도커의 이식성과 가벼운 특성 덕분에 비즈니스 로직을 신속하게 반영할 수 있기 때문에 시스템의 확장과 축소가 용의합니다.

동일한 하드웨어에서 더 많은 작업 실행

• 도커는 가볍고 빠르다는 것이 가장 큰 장점입니다. 하이퍼바이저 시스템 대신에 실용적이고 비용을 줄일 수 있는 대안을 제공합니다.

• 도커는 고밀도 환경과 적은 리소스로 많은 작업을 수행해야 하는 중소 규모 배포환경에 이상적이라고 할 수 있습니다.

  • 도커가 이러한 장점을 가지고 있다고 하여, 하이퍼바이저 시스템이 단점만 가지고 있는 것은 아닙니다.

  • 인프라 관리자는 구성하고자 하는 환경에 따라 여러가지 플랫폼의 도입을 검토할 수 있으며, 그에 따른 환경에 따라 배포 환경을 달라질 수 있음을 반드시 숙지하고 있어야 합니다.

  • 이러한 인프라적인 특성은 관리자의 지식과 기술, 경험에 따라 좌우 될 수 있다는 점을 기억하세요.

Docker Architecture

• 도커는 클라이언트 - 서버 아키텍처를 사용합니다. 도커 클라이언트는 도커 데몬과 데이터를 주고 받습니다.

• 도커 데몬은 도커 컨테이너를 빌드하고, 실행, 배포하는 작업을 담당합니다.

• 도커 클라이언트와 데몬은 동일한 시스템 환경 또는 도커 클라이언트가 원격으로 도커 데몬과 연결 할 수 있습니다.

• 도커 클라이언트와 데몬은 UNIX 소켓 또는 네트워크 인터페이스를 통해 REST API를 사용하여 통신합니다.

  

Docker 데몬

• 도커 데몬 (dockerd)은 도커 API 요청을 수신하고 이미지, 컨테이너, 네트워크 및 볼륨과 같은 도커 객체를 관리합니다.

• 데몬은 도커 서비스를 관리하기 위해 다른 데몬과 통신할 수도 있습니다.

Docker Client

• 도커 레지스트리는 도커의 이미지를 저장하는 역할을 담당합니다. 도커 허브 및 도커 클라우드는 누구나 사용할 수 있는 공용 레지스트리이며, 도커는 기본적으로 도커 허브에서 이미지를 찾도록 구성되어 있습니다.

• 설정을 변경하여 개인 레지스트리를 참고하도록 할 수 있으며, Dock (Docker Datacenter)을 사용하는 경우 Dock (Docker Trust Registy)이 포함됩니다.

• dockr pull 또는 docker run 명령어를 사용하면 구성된 레지스트리에서 필요한 이미지를 가져올 수 있습니다. 또한 docker push 명령을 통해 이미지가 구성된 레지스트리로 푸시될 수 있습니다.

  • 이러한 환경은 우리가 소스코드를 관리하기 위해 사용되는 Git과 상당히 흡사하다고 할 수 있습니다.

• Docker 스토어를 통해서 도커 이미지를 사고 팔거나, 무료로 배포할 수 있습니다.

  • 예를 들어 한 회사가 응용 프로그램이나 서비스가 포함된 도커 이미지를 구입하고, 그 이미지를 사용하여 개발, 테스트 및 실제 운영환경에 배포할 수 있습니다.

  • 이미지를 새로 가져와서 컨테이너를 다시 배포하는 작업을 통해 응용 프로그램을 업그레이드 할 수 있습니다.

Docker object

• 도커를 사용한다는 것은 이미지, 컨테이너, 네트워크, 스토리지, 플로그인 및 기타 객체를 만들고 사용하고 있는 것입니다.

  • 이미지

    • 도커 컨테이너를 만들기 위해 사용되는 읽기 전용 템플릿이라고 생각하면 쉽습니다.

    • 이미지는 다른 이미지를 기반으로 하여, 몇 가지 사용자 정의사항을 추가할 수 있습니다. 예를 들어 우분투 이미지 기반위에 아파치 응용프로그램을 실행하는데 필요한 세부 정보와 의존성 파일 등을 셋팅할 수 있습니다.

    • 나만의 이미지를 만들거나 다른 사람들이 레지스트리에 푸시한 이미지만 사용할 수 있으며, 본인만의 이미지를 만들기 위해서는 Dockerfile 를 통해 이미지를 만들고 필요한 단계를 정의하여 만들 수 있습니다.

    • Dockerfile 의 각 명령은 이미지에 레이어를 생성하기 때문에, Dockerfile 을 수정하고 이미지를 다시 작성되면 변경되는 레이어만 재구성 됩니다. 이러한 도커의 특성은 다른 가상화 기술과 비교할 때 이미지를 매우 가볍고 빠르게 만드는 요소의 일부가 됩니다.

  • 컨테이너

    • 이미지의 실행 가능한 인스턴스입니다. 도커 API 또는 CLI를 사용하여 컨테이너를 생성, 시작, 중지, 이동, 삭제할 수 있습니다.

    • 컨테이너를 하나 이상의 네트워크에 연결하거나 새로운 저장소에 연결할 수 있으며, 현재 상태를 기반으로 새 이미지를 만들 수도 있습니다.

    • 기본적으로 컨테이너는 다른 컨테이너 호스트 시스템과 격리되어 있습니다.

    • 컨테이너 네트워크, 저장소 또는 다른 하위 시스템이 다른 컨테이너 혹은 호스트 시스템에서 분리된 상태를 제어할 수 있습니다.

      • 오해하면 안되는 점은 컨테이너는 논리적으로 분리되어 있기 때문에 설정을 해주지 않으면 호스트 시스템에서 컨테이너 시스템으로 접근할 수 없다는 점입니다.

      • 이는 리눅스 컨테이너의 프로세스 격리방식의 특성으로서, 만약 본인의 어떤한 응용 프로그램이 외부와의 통신을 하기 위해서는 사전에 이미지를 만들 때, 통신을 위한 구문을 정의해야 합니다.

      • 위의 설명은 이러한 환경이 구축이 되어있다는 가정하에 다른 컨테이너 혹은 호스트 시스템과 통신할 수 있다는 것을 설명하고 있습니다.

    • A 컨테이너가 있다고 가정합니다. 이 컨테이너는 이미지를 작성하거나 시작할 때 사용자가 제공하는 구성 옵션으로 만들어 집니다. 컨테이너를 제거하면 영구 저장소에 저장되지 않은 상태 변경사항은 사라지게 됩니다.

  • Example docker run command

    • 다음과 같은 명령이 실행한다고 가정하고 내부적으로 어떻게 동작하는지 알아보도록 합시다.

      $ dcker run -i -t ubuntu /bin/bash

    • 기본 레지스트리 구성을 사용 중이라고 가정하겠습니다.

      1. 우분투 이미지가 로컬에 존재하지 않으면, 도커는 docker pull ubuntu 명령을 수동으로 실행 한 것 처럼 동작하여 이지지를 다운로드 합니다.

      2. 도커는 docker container crearte 명령을 수동으로 실행 한 것 처럼 새 컨테이너를 생성하게 됩니다.

      3. 도커는 읽기/쓰기 파일 시스템을 최종 레이어로 컨테이너에 할당합니다. 이를 통해 실행중인 컨테이너는 로컬 파일 시스템의 파일과 디렉토리를 작성하거나 수정할 수 있습니다.

      4. 네트워킹 옵션을 지정하지 않았기 때문에 컨테이너를 기본 네트워크에 연결하는 네트워크 인터페이스를 생성합니다. 여기에는 컨테이너의 IP가 할당되며, 기본적으로 컨테이너 호스트는 시스템의 네트워크 연결을 사용하여 외부 네트워크에 연결할 수 있습니다.

      5. 도커가 컨테이너를 /bin/bash 환경에서 실행합니다. 컨테이너가 대화형 방식으로 실행 중인데 이는 -i 옵션과 -t 옵션을 사용했기 때문입니다. 터미널에 연결되어 있기 때문에 출력이 터미널에 기록되는 동안 키보드를 통해 입력을 제공받습니다.

      6. exit 명령을 입력하면 /bin/bash 컨테이너는 중지되지만 제거되지는 않기 때문에 언제든지 다시 시작하거나 제거할 수 있습니다.

  • 서비스

    • 서비스를 확장하기 위해서 사용되는 swarm은 매니저와 워커를 가지고 있는 도커 데몬이 되며, 모든 도커 API를 통해 통신할 수 있습니다.

    • 서비스를 사용하면 특정 시간에 많이 수행되는 프로그램에 대해서 복제본의 수를 정의할 수 있습니다.

    • 기본적으로 서비스는 모든 워커 노드에 로드밸런싱됩니다. 이러한 내부적인 동작 방식 덕분에 사용자는 단일 애플리케이션을 사용하는 것 처럼 보이게 됩니다.

    • 도커 엔진은 Docker 1.12이상에서 스웜모드를 공식 지원합니다.

기본기술

• 도커 namespace라는 격리된 작업 영역을 제공하기 위해 컨테이너라는 기술을 사용합니다.

• 컨테이너를 실행하게 되면, 도커는 해당 컨테이너에 대한 네임스페이스 집합을 만들게 됩니다.

• 이러한 네임스페이스는 격리 계층 구조를 가지게 되는데, 컨테이너 각 계층은 별도의 네임스페이스에서 실행되고 실제 접근은 해당 네임스페이스로 제한되는 구조를 가지고 있습니다.

• 도커 엔진은 리눅스에서 다음과 같은 네임스페이스를 가지고 있습니다.

  • pid : 프로세스 격리

  • net : 네트워크 관리 인터페이스

  • ipc : ipc 자원에 대한 접근 관리

  • mnt : 파일 시스템을 마운트하는 부분을 관리

  • uts : 격리된 커널공간과, 버전의 식별합니다. (UTS : Unix Timesharing System)

Control Groups

• 리눅스의 도커 엔진은 컨트롤 그룹이라는 기술을 사용합니다. (cgroup)

• cgroup은 응용 프로그램을 자원 사용량을 제한하며, 이러한 그룹을 통해 도커 엔진은 사용 가능한 하드웨어 리소스를 컨테이너에 공유하고 선택적으로 성능 제약 조건을 적용할 수 있습니다.

Union file system

• 유니온 파일 시스템 (UnionFS)은 레이어를 생성하여 동작하는 파일 시스템으로 매우 가볍고 빠릅니다.

  • UnionFS는 Linux, FreeBSD, NetBSD를 위한 파일시스템 서비스로, 다른 파일 시스템을 위한 union mount를 구현합니다.

  • 분기라는 별도의 파일 시스템의 파일 및 디렉토리를 마치 하나처럼 겹처서 하나의 일관된 파일 시스템으로 만든다는 특징을 가지고 있습니다. 병합된 분기 내에서 동일한 경로를 가지는 디렉토리 내용은 새로운 가상 파일 시스템 내의 단일 병합된 디렉토리에서 함께 볼 수 있으며, 브렌치를 마운트 할 때 한 브랜치의 우선순위가 지정되게 됩니다. 따라서 같은 이름의 파일을 포함할 때 다른 브렌치보다 우선순위가 높아집니다.

  • 다른 브렌치는 COW 파일 시스템 일 수 있기 때문에 병합된 복사본에 대한 쓰기 부분은 실제 파일 시스템으로 지정될 수 있는데 이렇게 하면 파일 시스템이 쓰기 가능한 것으로 표시되지만 실제로는 시스템을 변경할 수 없습니다. 이는 COW의 특성이라고 할 수 있으며, Live CD와 같은 읽기 전용 미디어에서 유용하게 사용될 수 있습니다.

• 도커 엔진은 UnionFS를 사용하여 컨테이너에 대한 블록을 제공하고, 도커 엔진은 AUFS, btrfs, vfs 및 DeviceMapper를 비롯한 여러 UnionFS 변형을 사용할 수 있습니다.

  AUFS (Advanced multi unification filesystem) 리눅스 파일 시스템의 union mount를 구현하기 위해서 시작한 프로젝트 입니다. 2006년에 개발이 시작하여, UnionFS를 완전히 새롭게 만들게 되었습니다.

  안전성과 성능을 향상시키는 장점 이외에도 writable branch balancing 같은 새로운 기능도 포함하고 있습니다.

  

  도커의 파일 시스템 구조를 활용하고 있는데, 이 도커이미지는 읽기 전용으로만 사용하는데 이 덕분에 어떤 사용자가 접근하더라도 동일한 버전의 컨테이너를 사용할 수가 있다. 컨테이너의 작업내용은 각 유저에 '쓰기전용' 브렌치에 따로 저장되기 때문에 다른 사용자와 겹치지 않는 격리된 공간에서 사용할 수 있는데 이 상태에서 컨테이너를 종료하게 되면 작업한 내용이 모두 사라지게 되기 때문에 이러한 변경 사항을 적용하기 위해서는 '쓰기전용' 브렌치의 내용과 도커 이미지의 내용을 merge해서 새로운 버전의 도커 이미지를 만들어야 합니다.

  출처: https://www.joinc.co.kr/w/man/12/docker/aufs

Container format

• 도커 엔진은 네임스페이스, 컨트롤 그룹, UninoFS를 wrapper라고 부르는 컨테이너 형식에 포함되어 있습니다.

• 기본 컨테이너 형식은 libcontainer 이며, 앞으로 도커는 BSD Jails 또는 Solaris Zones과 같은 기술과 통합하여 다른 컨테이너 형식을 지원할 수 있습니다.

Develop with Docker

• 본장에서는 도커를 활용한 어플리케이션을 개발하는 방법과 유의사항에 대해서 기술합니다.

• 도커를 통해서 새로운 어플리케이션을 제공하기 위해서는 개발자들이 사용하거나, 권장하는 일반적인 패턴에 대해서 알아야 합니다.

  • 도커 파일을 통해서 이미지를 빌드하는 방법

  • 현재 이미지를 multistage 빌드하기

  • 볼륨과 bind mounts를 사용하여 어플리케이션 데이터 관리하기

  • swarm 서비스를 사용하여 응용프로그램의 스케일 조정하기

  • compose 파일을 사용하여 어플리케이션 스택 정의하기

  • 도커를 사용하여 애플리케이션을 개발하기 위한 방법론

• 또한 특정 언어에 대한 애플리케이션을 도커로 개발하는 방법에 대해서도 알아야 합니다.

  • JAVA

  • node.js

  • Ruby on Rails

  • .net Core Application

  • ASP.NET Core Application with SQL Server on Linux

• Dockerfiles를 작성하고 Docker CLI를 사용하여 응용 프로그램을 개발하는데 익숙한 경우 Go, 또는 도커 엔진 SDK를 사용하거나 HTTP API를 사용할 수 있습니다.

• 우리는 도커 초보 개발자라는 가정하에 기술을 설명할 것이며, 이론적인 충분한 이해와 다양한 실습 또한 부가적인 기술 습득을 통해서 도커개발을 본격적으로 시작하도록 하겠습니다.

Docker development best practices

• 다음 개발 패턴은 도커를 사용하여 응용 프로그램을 개발하는 사람들에게 도움이 되는 것으로 알려진 패턴입니다.

How to keep your images small

• 작은 이미지를 유지하는 것은 서비스를 빠르게 메모리에 로드되어 실행할 수 있는 중요한 방법입니다.

• 이미지를 작게 유지하는 것은 다음과 같은 몇가지 법칙이 존재합니다.

  • 적절한 기본 이미지로 시작해야 합니다.

    • JDK가 필요한 경우 일반적으로 우분투 이미지에 JDK 설치를 Dockerfile에 작성하는 것이 아닌 공식 이미지에 있는 JDK이미지에 배치하는 것이 효율적입니다.

  • multistage 빌드를 활용합니다.

    • 예를들어 maven 이미지를 자바 어플리케이션에서 빌드하고 그 파일을 Tomcat 이미지에 정확한 곳에 위치하여 어플리케이션을 배포할 수 있습니다.

    • 이런한 환경에서도 모든 설정파일은 Dockerfile에 있지만 최종 이미지에는 빌드에서 가져온 라이브러리 및 종속성 파일이 모두 포함되지는 않고 실행하는데 필요한 일부 환경만이 포함됩니다.

      • multistage를 포함하지 않는 도커를 사용하는 경우 RUN Dockerfile에서 별도의 명령 수를 최소화 하여 이미지의 레이어 수를 줄이는 것이 핵심입니다.

        RUN apt-get update
        RUN apt-get install python -y 

        RUN apt-get update && apt-get install python -y 

    • 공통점이 많은 이미지가 여러개가 있는 경우 공유 구성 요소를 사용하여 자신의 기본 이미지를 만들고, 거기에 고유 이미지를 적용하는 것이 가장 좋은 방법입니다.

    • 도커는 공통 레이어를 한번만 로드되기 때문에 도커 호스트의 메모리를 보다 효율적으로 사용하고, 빠르게 로드 될 수 있게 합니다.

    • 실제 배포하여 운영되는 프로덕션 이미지의 경우 간결하게 유지하면서 디버깅을 허용하기 위해서는 프로덕션 이미지를 기본 이미지로 활용하는 것이 가장 좋은 방법입니다. 이렇게하면 기본 이미지 위에 추가 테스트 또는 디버깅 도구를 쉽게 추가할 수 있습니다.

    • 이미지를 구축할 때, 항상 버전정보를 안전성이나 기타 여러 이유로 인하여 자동으로 생성되는 latest 태그에 의존하면 안됩니다.

Where and how to persist application data

• storage drivers를 사용하여 컨테이너의 쓰기 가능한 계층에 응용 프로그램 데이터를 저장하지 마세요.

  • 이경우 볼륨이나 바인드 마운트를 사용하는 것 보다 I/O 관점에서 볼 때 컨테이너의 크기가 커지고 효휼성이 떨어집니다.

• 볼륨을 사용하여 데이터를 저장합니다.

• 바인드 마운트를 사용하는 경우는 개발 디렉토리, 컨테이너를 빌드한 바이너리를 마운트 하는 경우입니다.

  

  • 볼륨을 사용하여 개발한 프로덕션 이미지의 경우 개발 중에 사용한 바인드 마운트와 똑같은 위치에 마운트합니다.

• 프로덕션의 경우 기밀정보를 관리하는 방법으로 데이터를 관리해야 합니다. 이러한 데이터의 종류에는 사용자 ID, PW, TLS 인증서와 및 키, SSH 키, 기타 외부 노출이 되면 안되는 파일(database server, 내부 서버) 등 입니다. 이 부분은 심화과정에 속하기 때문에 다음에 다시 설명하도록 하겠습니다.

• 구성 파일과 중요하지 않은 파일의 경우 config를 사용하여 데이터를 저장합니다.

Use swarm services when possible

• 가능하면 swarm을 사용하여 확장 가능한 서비스를 만들 수 있도록 설계해야 합니다.

• 응용 프로그램이 단일 인스턴스만 실행해도 상관이 없는 경우라도, swarm 서비스는 독립형 컨테이너에 비해 여러 이점을 제공하기 때문입니다.

• 네트워크 및 볼륨은 swarm 서비스와 연결하거나 해제할 수 있으며, 도커는 무중단 방식으로 재배포 합니다. 독립형으로 변경사항을 수정하기 위해서는 수동으로 정지 혹은 제거 및 재작성하고 다시 배포해야 합니다.

• docker stack deploy 을 사용할때는 docker pull 대신에 이미지 풀방식을 사용해야 합니다. 이렇게 하면 배포시 노드가 다운되지 않고, 새로운 노드가 swarm에 추가되면 이미지가 자동으로 pull되어집니다.

swarm 서비스를 활용하여 노드간의 데이터를 공유하는 데는 한계가 있습니다. 만약 Docker for AWS, Docker for Azure를 사용하면 Cloudstar 플러그인을 사용하여 swarm 서비스 노드 사이에 데이터를 공유할 수 있습니다. 또한 동시 업데이트를 지원하는 별도의 데이터베이스에 응용 프로그램 데이터를 작성할 수 있습니다.

Use CI/CD for testing and deployment

• 소스의 변경사항을 확인하거나 pull 요청을 할 때 Docker Cloud 또는 다른 CI/CD 파이프 라인을 사용하여 도커 이미지를 자동으로 완성하고 태그를 지정하여 테스트 합니다. Docker Cloud는 테스트를 거친 응용 프로그램을 곧바로 프로덕션 환경으로 배포할 수 있습니다.

• Docker EE를 사용하게 되면 개발, 테스트, 및 보안 팀에서 프로덕션 환경에 배포하기 전에 이미지에 서명하도록 요구함으로써 각 팀에서 테스트를 거쳐 승인을 받았는지 바로 확인할 수 있습니다.

Differences in development and production environments

• 개발 환경

  • 바인드 마운트를 사용하여 컨테이너에 소스 코드에 대한 접근 권한을 부여합니다.

  • 시간 동기화에 신경을 쓰지 않아도 됩니다.

• 프로덕션 환경

  • 볼륨을 사용하여 데이터를 저장해야 합니다.

  • 가능한 경우 도커 프로세스를 호스트 프로세스보다 효과적으로 사용하기 위해 Docker EE를 사용할 것을 권장합니다.

  • 항상 도커 호스트가 각 컨테이너 프로세스에서 NTP 클라이언트를 실행하여 모두 동일한 NTP 서버에 동기화 되어 있어야 합니다. swarm을 사용하는 경우 컨테이너에 소스가 동일한 NTP 서버와 동기화 되는지 확인해야 합니다.