메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

한빛랩스 - 지식에 가능성을 머지하다 / 강의 콘텐츠 무료로 수강하시고 피드백을 남겨주세요. ▶︎

IT/모바일

팀 개발 속도 향상을 위한 3가지 Docker compose 기능들

한빛미디어

|

2019-02-26

|

by Bret Fisher

18,999

고급 Docker Compose 기능을 사용해 대규모 프로젝트 및 팀 환경에서 발생하는 문제를 해결하자

 

요즘엔 개발자가 한번 쯤은 만날 법한 문제들을 해결하는 소프트웨어 도구가 쏟아지고 있습니다. 하지만, 무슨 도구를 사용할 지 선택하는건 또 다른 문제입니다. 심지어 컨테이너의 영역에서도 우린 도구의 바다를 헤엄치는 중이지만, 대부분은 몇 년 전에 존재하지도 않았던 것들입니다.

 

이런 상황에 도움이 되고자 필자가 왔습니다. 필자는 기업이 서버에 코드를 개발, 테스팅, 패키징, 전달하는 업무를 보다 빠르고 효율적으로 할 수 있도록 돕는 일을 하고 있습니다. 오늘날엔 이것은 컨테이너를 의미합니다만, 그저 단순히 중요한 개발 도구인 것만은 아닙니다. 컨테이너는 사용 방식이자 팀에서 확장하는 방법입니다.

 

우선, Docker Compose에 집중해봅시다. Docker compose는 모든 주요 OS에서 컨테이너 기반 개발 환경을 관리하기 위한 실질적인 표준입니다. 몇 년간, 저는 팀들이 Docker Compose로 대체되는 도구와 스크립트들을 교체했다는 얘기를 꾸준히 들어왔습니다. 사람들은 Docker Compose가 어디서나 작동하고, 시간을 절약하고 이해하기 쉽기 때문에 채택합니다.

 

하지만, 한 팀에서 개발/테스트/프로덕션 환경 전체에 적용하는 건 좀 까다로울 수 있습니다. 여기 Docker compose 작업 흐름을 모두에게 적용하기 위해 알아둬야 할 3가지 주요 영역이 있습니다.

 

환경 변수

 

결국 유연하게 바뀔 수 있는 compose 파일이 필요한 것과 compose 파일 내부에서 환경변수를 사용할 수 있는 것을 알게 될 것입니다. 참고로, 지금 말하고자 하는 환경 변수가 컨테이너를 시작시에 보내는 YAML 객체에 쓰는 "environment" 와는 관계 없습니다. ${VARNAME} 표기를 사용하면, YAML 파일을 처리하는 동안에 Compose에서 이 변수를 동적으로 읽을 수 있습니다. 가장 일반적인 예시로는 컨테이너 이미지 태그나 포트를 설정하는 경우입니다. 예를 들어, 사용하고자 하는 docker-compose.yml 파일이 아래와 같을 때:

 

version: '2'

services:

  ghost:

    image: ghost:${GHOST_VERSION}

 

CLI에서 다음과 같이 사용 중인 이미지 버전을 조절 할 수 있습니다.

 

GHOST_VERSION=2 docker-compose up

 

또한, .env파일에 값을 저장하거나 export로 CLI에서 설정하거나 YAML 안에 ${GHOST_VERSION:-2} 등의 방식으로 변수를 설정 가능합니다. 도커 문서에서 변수값 대체여러 방식들을 더 읽어볼 수 있습니다.

 

템플릿화

 

비교적 새롭고 덜 알려져 있는 기능은 파일 전체에서 재사용되는 compose 파일의 문단을 정의할 수 있게 해주는 Extension 필드 입니다. Extension 필드는 마이크로서비스 집합에 같은 환경변수를 공유하고 같은 내용을 여러번 반복해서 작성하고 싶지 않을 때 주로 씁니다. 최근에 필자는 Compose 파일에서 각 서비스에 대해 동일한 로깅 옵션을 설정하기 위해 아래와 같은 설정을 사용했습니다:

 

version: '3.4'

 

x-logging:

  &my-logging

  options:

  max-size: '1m'

  max-file: '5'

 

services:

  ghost:

  image: ghost

  logging: *my-logging

  nginx:

  image: nginx

  logging: *my-logging

 

템플릿을 선언 하기위해 쓴 "x-"로 시작하는 새 영역이 보이실 겁니다. 다음으로 & 와 함께 이름을 정하고 이를 호출하기 위해서는 compose 파일 어디서건 * 와 이름을 붙여쓰면 됩니다. 당신이 마이크로서비스를 사용하고 compose파일이 수백 줄로 작성되어있다면, 템플릿은 상당한 시간 절약과 전역에 걸친 옵션 일관성을 보장합니다. 도커 문서에서 자세한 내용을 확인하세요.

 

Compose 명령 범위를 제어하기

 

docker-compose CLI는 범위 내에 있는 하나 이상의 컨테이너, 볼륨, 네트워크 등을 제어합니다. 범위를 생성하는 방법에는 두가지가 있습니다. 첫째, docker compose의 YAML 설정 파일 (기본값은 docker-compose.yml) 둘째, 프로젝트 이름 (기본값은 YAML 설정 파일을 갖고있는 디렉토리 이름) 입니다. 일반적으로 단일 docker-compose.yml로 프로젝트를 시작하고 compose YAML 파일이 있는 디렉토리에서 docker-compose up과 같은 명령어를 실행합니다. 하지만 여기엔 복잡성이 커지면서 동시에 유연성도 커집니다. 

 

상황이 더 복잡해지면, 각각 다른 설정을 위해 여러 YAML 설정 파일을 가질 수도 있고 docker-compose -f custom-compose.yml up과 같이 CLI로 제어하길 원할 것 입니다. 이 명령어는 기본 YAML 파일인 docker-compose.yml을 무시하고 사용자가 -f옵션으로 명시한 단 하나의 파일 만을 사용합니다.

 

계층적으로 다시 정의하는 방식으로 다수의 compose 파일을 결합할 수 있습니다. CLI에 나열된 각각의 항목은 이전의 설정보다 우선시 됩니다. (왼쪽에서 오른쪽으로 처리) 

예) docker-compose -f docker-compose.yml -r docker-override.yml

 

만약, 수동으로 프로젝트 이름을 바꾸면 여러 범위에서 동일한 compose 파일을 사용할 수 있으므로 충돌하지 않습니다. 충돌은 compose가 이미 동일한 이름으로 실행 중 인 컨테이너를 제어하려고 할 때 발생합니다. Compose가 생성하는 컨테이너, 네트워크 및 기타 객체들이 명명 표준이 있다는 것을 눈치채셨을 것입니다. 이 표준은 3가지로 구성되어 있습니다: projectname_servicename_index. 프로젝트 이름은 기본값인 compose 설정 파일이 있는 디렉토리 이름에서 커맨드 라인에서 -p 옵션을 지정해 프로젝트 이름을 바꿀 수 있습니다. 

만약 docker-compose.yml 파일이 아래와 같이 설정되어 있다면:

 

version: '2'

 

services:

  ghost:

  image: ghost:${GHOST_VERSION}

  ports:

    - ${GHOST_PORT}:2368

 

이 파일을 "app1" 디렉토리 안에 저장하고 아래와 같은 인라인 환경 변수로 ghost 앱을 시작합니다.

 

app1> GHOST_VERSION=2 GHOST_PORT=8080 docker-compose up

 

그러면 다음과 같은 이름으로 실행되는 컨테이너를 볼 수 있습니다.

 

app1_ghost_1  

 

이제, 동시에 ghost 앱의 이전 버전을 실행하고자 할 떄, 두가지를 변경하면 같은 compose 파일을 사용해 동시 실행할 수 있습니다. 먼저, 처음에 실행된 컨테이너 이름과 충돌하지 않도록 프로젝트 이름을 변경해야 합니다. 둘째, 실행 중인 다른 컨테이너들과 충돌하지 않도록 포트를 변경해야 합니다.

 

app1> GHOST_VERSION=1 GHOST_PORT=9090 docker-compose -p app2 up

 

위의 상황에서  docker container ls 명령어로 실행 중인 컨테이너를 확인해보면, 아래와 같은 메시지를 확인할 수 있습니다.

 

app1_ghost_1 running ghost:2 on port 8080

app2_ghost_1 running ghost:1 on port 9090

 

이제 두개의 브라우저를 열어서 8080포트와 9090포트를 나란히 실행해 다른 두 버전의 ghost 앱(혹은 데이터베이스)을 탐색 할 수 있습니다.

 

필자가 고급 compose 작업흐름에 대해 배운 대부분은 도커 문서에서 필자가 배운 것과 개발, 테스트 및 배포를 보다 쉽게 하기 위해 함께 일한 팀에서 배운 것을 시도해보면서 얻은 결과입니다. 필자는 가능한 한 모든 곳에서 이런 배움을 공유하고 따라하길 권장합니다. Docker Compose에서 당신이 찾은 유용한 기능이나 팀 표준은 무엇입니까?

 

*****

 

Bret Fisher는 DevOps 컨설턴트이자 Docker 캡틴이며 런던과 뉴욕의 Velocity에서 2일간 진행되는 Docker and Swarm 워크샵을 이끌고 있습니다.

 

원문 : 3 Docker Compose features for improving team development workflow

번역 : 공민서

댓글 입력
자료실

최근 본 상품0