Taking Docker to Production: What You Need to Know and Decide 발표자료 정리

2019-07-17 컨테이너 소모임에서 진행한 내용입니다. 어떤 피드백도 환영합니다.

오늘의 자료

• 동영상 제목: Taking Docker to Production: What You Need to Know and Decide
  (도커를 프로덕션에 도입하기: 알아야할 것과 결정해야할 것)
• 스피커: Bret Fisher (DevOps Consultant, Docker Captain)
• 링크: https://www.youtube.com/watch?v=6jT83lT6TU8
• 발표자료: https://www.slideshare.net/Docker/taking-docker-to-production-what-you-need-to-know-and-decide

도커 프로덕션에 도입하기

우리가 여기에 모인 이유

• 도커를 운영 환경에 도입하고 싶어서
• 컨테이너를 오케스트레이션 하고 싶어서
• 프로젝트에 대한 의사결정을 내릴 필요가 있어서
• 어떤 요구사항이 선택적인 것인지 배우기 위해서

도커를 도입하는데 겪었던 어려움은?

동시 혁신을 제한

• 처음부터 많은 서비스를 컨테이너화 하는 것은 너무 힘들다.
• 처음부터 고려할 필요 없는 것
  • 완전 자동화 CI/CD
  • 동적 성능 스케일링
  • 모든것을 컨테이너화하는 것
  • 영속 데이터들을 다루는 것 (스테이트풀)

도커 혹은 컨테이너 도입 시에 MVP는 무엇일까요?

컨테이너에서 레거시 앱도 동작한다!

• 마이크로서비스 변환은 불필요하다.
• 12 Factor는 우리가 끊임없이 쫓아가야할 수평선...
• 이상이 컨테이너화를 지연시키지 않도록 하자!

복잡한 레거시 코드를 도커로 마이그레이션 해본 적 있으신가요?

첫번째 집중할 것: Dockerfile

• fancy한 오케스트레이션 보다 더 중요하다!
• Dockerfile은 빌드와 환경에 대한 문서
• 도커 허브 오피셜 이미지를 통해 Dockerfile과 ENTRYPOINT에 대해서 공부해보자.
• 자기에게 친숙한 리눅스 배포판을 기본 이미지로 사용하는 것을 추천

도커파일 성숙도

• Make it start 실행 되느냐
• Make it log all things to stdout/stderr 모든 로깅을 표준 출력/표준 에러로 하느냐
• Make it documented in file 파일로 문서화 되었느냐
• Make it work for others 다른 사람이 사용가능한가
• Make it lean 린(?)한가 (가벼움)
• Make it scale 스케일링(크기 또는 규모 조정)이 가능한가

도커 로깅에 대한 노하우가 있나요?

도커파일 안티 패턴

Trapping Data

• 문제: (깜빡하고) 특정 데이터를 컨테이너에 저장. 컨테이너가 삭제되면 저장된 데이터 모두 휘발됨.

• 해결책: 볼륨 마운트

  VOLUME ["/data/mysql", "/var/lib/mysql"]
  ENTRYPOINT ["docker-entrypoint.sh"]
  CMD ["mysqld"]

Using Latest

• 문제1: "latest" 태그의 이미지를 사용. "latest" 태그의 이미지는 메이저 버전이 크게 바뀔 수도 있어서 위험함.
• 해결책1: 특정 태그의 이미지 사용
• 문제2: 이미지 빌드시에 최신 패키지 설치. 이 또한 내무 패키지들의 버전 호환 이슈가 있을 수 있다.
• 해결책2: apt/yum/apk 패키지의 버전을 명시한다.

Leaving Default Config

• 문제: 앱의 기본 설정을 바꾸지 않고 암묵적으로 설정파일을 카피.
  • eg: php.ini, mysql.conf.d, java memory
• 해결책: ENV, RUN, ENTRYPOINT로 기본 설정을 업데이트하도록 수정.
  Dockerfile이 이러한 설정과 환경에 대한 명세를 하는 역할!

entrypoint script 작성 경험이 있나요?
예시) entrypoint script을 통해서 애플리케이션 초기화 작업을 수행하고, 그 다음 애플리케이션 실행.

Environment Specific

• 문제: 특정 설정을 이미지 빌드시에 카피. 다양한 환경을 도커파일을 수정해가며 매번 이미지를 생성.
• 해결책: ENV를 통해서 기본 환경변수를 설정하고, 각 환경 별로 ENTRYPOINT 스크립트를 이용하여 덮어쓴다. 런타임 시에 환경을 바꿀 수 있도록하며, 설정은 최대한 도커파일에 표현한다.

ENTRYPOINT와 CMD의 차이를 아시나요?
자신만의 도커 꿀팁이 있다면?

https://blog.docker.com/2019/07/intro-guide-to-dockerfile-best-practices/

Containers-on-VM or Containers-on-Bare-Metal

• 둘 중 하나를 하거나 둘 다 하거나 다 괜찮다.
• 각각 많은 장단점이 있다.
• 처음에는 자기가 잘 알고 편한 것을 하면 된다.
• 기본적인 성능 테스트를 해보면 공부가 많이 될것이다.
• 2017 Docker Inc. and HPE whitepaper on MySQL benchmark
  (https://d.pr/f/Zjv65z/1BuMbZ8p)

현재 도커를 VM에서 사용하시나요? 아니면 베어메탈에서 사용하시나요?
현재 환경의 장단점이 있나요?

리눅스 배포판과 커널의 중요성

• 도커는 커널과 스토리지 드라이버에 매우 종속적
• 끊임없이 혁신하고 고쳐지고 있음
• Minimum version ≠ Best version
• 별 생각 없으면 우분투 16.04 (현재는 18.04)
  • 유명하고, 도커에 대한 테스트가 잘 되었음
  • 4.x 버전의 커널과 다양한 Storage driver를 지원
• InfraKit과 LinuxKit도 추천: OS 프로비저닝 도구?

HOST OS 또는 커널 관련된 장애 상황을 겪어 보신 적 있으신가요?

컨테이너 기본 배포판: 뭐가 좋을까?

• 이미지 사이즈로 결정하지 말아라.
• 우선은 기존의 배포 프로세스와 잘 맞는 것을 사용
• (꽤) 나중에 알파인 이미지 고려

어떤 리눅스 이미지를 기본 이미지로 쓰고 계신가요?
어떤 장단점이 있나요?

스웜 구축하기

시작하기에 앞서 스웜을 이미 사용하거나 도입할 계획이 있으신가요?

• 기본적인 사이즈 가이드라인 제공

Baby Swarm: 1-Node

• docker swarm init
• docker run 이상의 기능을 제공

HA Swarm: 3-Nodes

• HA를 위한 최소 노드 갯수
• 모든 노드가 매니저
• 하나의 노드가 fail 가능
• 토이 프로젝트 또는 테스트 환경

BIZ Swarm: 5-Nodes

• 좀 더 나아진 HA
• 모든 노드가 매니저
• 두개의 노드가 fail 가능

Flexy Swarm: 10+ Nodes

• 5개의 매니저 노드
• 워커 노드는 DMZ에서 실행
• 매니저 노드는 5개를 유지하고 나머지는 워커 노드
• 제약사항(Constraint)와 레이블을 이용해서 컨트롤 컨테이너 배치

Swole Swarm: 100+ Nodes

• 5개의 매니저 노드
• 성장에 따라 매니저 개수를 조절
• DMZ 또는 Private 네트워크 상에서 여러 워커 서브넷 사용
• 제약사항(Constraint)와 레이블을 이용해서 컨트롤 컨테이너 배치

가축을 애완동물로 바꾸지 마라!

• 모든 노드는 재배치될 수 있다.
• 모든 컨테이너는 다시 생성 및 실행될 수 있다.

잘 만들어진 것 가져다 쓰기

• "Not Implemented Here" 증후군을 주의하라
• 이미지 레지스트리
• 로깅
• 모니터링과 알림

https://github.com/cncf/landscape

기술 스택 (도커 스웜)

with OpenFaas : https://github.com/openfaas/faas

오케스트레이터가 있어야할까?

• 도커 마이그레이션을 더욱 가속화하자!
• 이미 멋진 인프라 자동화가 있는가?
• 훌륭한 VM 오토 스케일을 가지고 있는가?
• VM OS의 보안 경계와 비슷합니까?
• 그럼 굳!

VM당 하나의 컨테이너?

• 충분히 괜찮다!
• 최소한의 인프라의 변경!
• Puppet 보다는 Dockerfile이 낫다.
• 당신의 도커 운영 스킬을 향상시켜줄 수 있다.
• VM OS 빌드를 단순화 할 수 있다. (도커만 설치)

복잡한 모노리틱 서비스를 오케스트레이션 없이 실행만 도커로 바꿔서 운영해본 경험이 있으신가요?
충분히 장점을 느끼셨나요?

요약

• 처음에는 요구사항을 다듬는다.
• Dockerfile, docker-compose.yml에 집중하여 서비스를 명세한다.
• Dockerfile 안티패턴에 주의한다.
• 친숙한 OS와 FROM 이미지를 사용한다.
• 당신의 성장에 따라 Swarm을 성장시켜라.
• 좋은 도구는 사서 쓰거나 가져다 써라.
• 변할 수 있는 기술스택의 부분을 인지하고, 유연함을 유지하자.

기타 토론 거리

• 컨테이너를 도입하면서 생기는 직무적 변화
  • 시스템 엔지니어와 개발자, 그리고 데브옵스 엔지니어
• ECS, k8s, 도커 스웜 비교
  • 과연 어떤 도구가 현재 상황에 적절할까?
• InfraKit으로 커널 버전 관리하기
• VM과 베어메탈의 장단점 비교
• Elastic Beanstalk과 ECS 비교