2020-03-02 게시 됨2020-03-02 업데이트 됨docker13분안에 읽기 (약 2000 단어)

복잡한 애플리케이션 설정을 위한 복수의 도커 파일 사용하기(번역)

대부분의 웹 기반의 앱은 실제 서비스에서 개발자가 높은 트래픽에서 증가하는 워크로드를 처리할 능력을 더할 수 있게 하는 여러 컨테이너들을 사용하게 된다. 여러 도커파일을 사용하는 것은 개발자에게 어떻게 하나의 애플리케이션을 분할할 것인지를 결정하는 것을 돕고, 그러므로서 기능적인(함수적인) 집계가 동작할 수 있게 하지만, 개발자는 결정을 내리는 과정 중에 반드시 먼저 스스로에게 몇가지 질문들을 해야 한다.

개발자는 아마도 복수의 도커파일을 로드밸런서 앞단에서 동작하는 프론트앤드에서 작동하는 노드를 유저의 요청에 맞추기 위해 사용할 것이다. 하지만 개발자는 어떤 앱이 도커파일을 통해 이득을 얻을 수 있을지, 얼마나 많은 도커파일들이 각 애플리케이션에 필요한지, 그리고 개발자가 도커파일을 추적하는 과정을 취할 수 있는지와 같은 반드시 몇 요인들을 결정해야 한다.

애플리케이션을 도커파일들로 설정하기 위한 고려사항들

분산 애플리케이션을 만들고 관리하는 것은 복잡한 과정이 될 수 있다. 하지만 도커파일과 Github과 같은 툴을 사용하면 최대한 간단한 설정을 유지할 수 있다. 도커파일을 사용하기 앞서, 아래 질문들을 확인해보자.

어떤 타입의 애플리케이션들이 복수의 도커파일이 이득일까?

어떤 유저와 마주하고 있는 프론트, 논리적 처리와 어떠한 종류의 스토리지를 가지고 있는 백앤드가 있는 어떤 종류의 앱이라면, 복수의 도커파일로 이익을 볼 수 있다. Github에서 이용가능한 도커 투표앱 샘플은 이러한 아키텍처의 한 예시이다. 이 앱은 파이썬, 노드, Redis, PostgreSQL, .NET 애플리케이션을 사용하고 있다. 만약 개발자가 이 앱을 로컬 환경에서 테스트하기로 결정했다면, 개발자는 반드시 도커로 세팅된 애플리케이션으로부터 드라이브릉 공유할 수 있게 해야 한다. (역주: 이 글을 읽으면서 직접 샘플을 테스트 하려면, drive sharing이 필요하다고 하는 것 같습니다.)

이 앱에서 각 노드들은 각각의 커스텀 설정 도커 파일로부터 온다. 어떤 경우에서는, 개발자는 특정한 태스크들을 처리할 수 있는 실행 선택지, 예를 들어 프론트앤드 웹 애플리케이션을 위한 파이썬 또는 ASP.NET Core과 같은 선택지를 갖게 될 것이다. 개발자는 샘플 애플리케이션을 실행할 다섯 가지 다양한 기능적인 노드들 전체와, 각 노드들이 동작 가능하게 하는 도커파일들을 갖는다. (역주: 아마 저 샘플 앱을 까봤을 때 어떤 구성인지 설명하는 건데, 해석을 하다보니 좀 딱딱합니다.)

개발자는 어떻게 한 서비스가 그 서비스만의 도커파일이 필요한지 알 수 있을까?

도커 투표앱 예시로부터, 개발자는 상글 노드가 될 수 잇는 두 프론트 앱과, 하나의 캐시, 하나의 데이터베이스 노드, 그리고 하나의 워커 노드를 갖게 된다. 애플리케이션을 기능적 영역까지 쪼개는 것은 각 노드에게 다양한 도커파일 옵션들을 제공하는 것을 쉽게 만든다. (역주: 즉, 기능적 단위까지 애플리케이션을 쪼개고, 기능적 단위마다 도커파일을 주는 것이 좋다고 말하는 듯)

하나의 애플리케이션당 얼마나 많은 도커파일들이 필요하게 될까?

개발자는 하나의 독립적인 서비스 또는 함수당 하나의 도커파일을 가지고 있어야 한다. 예를 들어서 도커 투표 앱에서 개발자는 각 5개의 기능적인 노드들에 대한 하나의 도커파일을 찾을 수 있다.

각 서비스들은 다양한 실행 방법을 위한 복수의 도커파일들을 가지고 있다. 워커 노드는 ASP.NET 버전, 그리고 자바 실행을 위한 구체적인 명령들과 함께 두 개의 도커파일이 있다. (역주: 노드가 ASP.NET에서 실행될 경우, JAVA에서 실행될 경우 두 가지로 구분된 명령어를 담고 있는 도커파일 두 개가 있다는 뜻) 두 개 모두 구체적인 서비스들에 집중된 최소의 명령어들만 담고 있다.

어떻게 개발자가 하나의 앱을 복수의 도커파일들로 컨테이너화 할 수 있을까?

도커 컴포즈는 다양한 도커파일들을 사용해 애플리케이션을 빌드하는 가장 일반적인 방법이다. 이것은 컨테이너를 만들기 위해 몇가지 명령어들에 기반한 YAML 파일을 요구한다. 도커 도큐맨트 사이트는 도커 투표 앱을 위한 컴포즈 파일의 리스트를 가지고 있다. 각 기능적 서비스들은 구분된 애플리케이션을 빌드하기 위해 반드시 필요한 모든 것을 갖추고 있는 섹션을 갖고있다. 도커 컴포즈에서 dockerfile 키워드는 개발자에게 다양한 파일 이름을 지명 하는 것을 가능하게 한다.

어떻게 과도한 리소스 소비를 피할 수 있을까?

리소스 제한 또는 할당량은 컨테이너 아키텍처에서 가장 최상위의 사용 리소스를 제한하는 방법이다. 도커와 함께, 개발자는 --memory-swap 그리고 kernel-memory와 같은 커멘드라인 옵션으로 물리적 메모리 한계를 강제할 수 있다. CPU 사용도 비슷한 방법으로 제한 가능하다.

쿠버네티스는 또한 몇몇 정의들과 limits 키워드를 가지고 있는 YAML 파일과 함께 리소스 소비의 제한을 이름공간 기반으로 서포트 하고 있다. 쿠버네티스에서 름공간(namespace)은 개발자가 개별 리소스들을 적절한 관리와 보안 통제들과 함께 프로비전 또는 인스턴스화 할 수 있는 프로그래밍 언어에서의 특징과 유사하다. 그리고 이것은 파이썬에서 가상 워크스페이스와도 어쩌면 유사할 수 있다.

번역 후기

주제가 굉장히 자극적인 주제라 언젠가는 읽어봐야지 하고 있던 글인데, 막상 읽어보니 구체적이지 않고 디테일한 부분이 없어서 많이 아쉬웠다. 마지막 문단과 마무리 글은 형식적이고, 무의미 한 내용이라고 생각 되어서 아예 빼버렸다. 그래도 내용 중에 한 두 문장으로 정리된 위에 내용들 중에서는 당연스럽게도 항상 고려해봐야 하는 내용들이 있었다고 생각한다. 그렇지만 결과적으로 이번 번역 주제는 잘 못 골랐다. 다음은 Best Practice, Bad Practice에 대한 글을 번역할 생각인데, 도커 블로그에 올라온 글이라 기대가 되는 바이다.