컨테이너가 중요한 이유가 무엇인가요?
이 단원에서는 Tailspin 팀을 따라 DevOps 프로세스에 필요한 몇 가지 개선 사항을 설명합니다. 이 시나리오에서 팀은 Docker를 사용하여 웹 애플리케이션을 컨테이너화합니다. 그런 다음 팀은 CI/CD 파이프라인을 업데이트하여 이를 지원합니다.
고단한 몇 주가 흘렀습니다.
지난 몇 주는 Tailspin 팀에게 어려운 시간이었습니다. Teams는 여러 가지 이유로 마감일을 맞추기 위해 애쓰고 있으며 회사 전체의 생산성에 대한 우려가 있었습니다. Andy 님은 경영진을 대상으로 예정된 프레젠테이션을 위한 피드백을 수집하고자 Space Game 웹 사이트 팀의 주요 관련자를 불러 모았습니다.
Andy: 방문해 주셔서 감사합니다. 지난 몇 주간 고생하셨는데 몇 가지 좋은 소식을 전해 드리고자 합니다. 경영진에서 성과 개선을 위해 바꿔야 할 점에 대한 제안을 듣고자 내일 간담회를 개최합니다. 경영진에서는 저를 초대하여 DevOps 성공에 대한 사례 연구를 발표하도록 했고 우리가 가진 아이디어를 청취하겠다고 했습니다. 이 모임을 브레인스토밍의 기회로 활용할 수 있으면 좋겠습니다. 누구부터 시작하시겠어요?
모두 Amita 님을 쳐다봅니다. 그녀는 최근에 특별히 많은 어려움을 겪었습니다.
Amita: 제가 먼저 말씀드리죠. 아시다시피 여러 팀을 테스트하고 각 팀이 자체 기술 스택을 사용하기 때문에 어려울 수 있습니다. .NET 또는 Java와 같은 동일한 기본 플랫폼을 사용하는 경우에도 종종 다른 버전을 대상으로 합니다. 때로는 제가 테스트해야 하는 코드를 해당 팀에서 실행할 수 있는 상황에서 하루의 절반을 단지 테스트 환경을 준비하는 데 쓰는 것 같습니다. 뭔가 제대로 되지 않는 경우, 코드에 버그가 있는 것인지 제가 실수로 4.3.2 버전 대신 4.2.3 버전을 구성한 것인지 구별하기 어렵습니다.
‘Andy 님은 화이트보드에 “QA를 위한 종속성 버전 관리 문제”라고 적습니다.’
Tim: 저는 이 문제에 더하여 운영 문제를 언급하고 싶습니다. 고유한 버전 요구 사항을 가진 몇 개의 팀이 있으므로, 각 팀의 앱 버전 및 구성 요소 요구 사항이 우리의 다른 앱과 충돌하지 않도록 하려면 각 팀의 앱을 자체적인 가상 머신에 게시해야 합니다. 이 경우 추가적인 VM 세트를 유지 관리하는 데 소요되는 오버헤드 외에도 해당 앱이 함께 실행될 수 있는 경우보다 큰 비용이 듭니다.
‘Andy 님은 화이트보드에 “VM으로 앱 격리를 해결하는 데 따른 오버헤드”라고 적습니다.’
Mara: 개발 측면에서 드릴 말씀이 있습니다. 몇 주 전에 저는 피어 투 피어 업데이트 시스템 작업을 하고 있었고 시스템 모두가 제 머신에서 작동 중이었습니다. 그러나 제가 배포를 위해 시스템을 핸드오프했을 때 시스템이 프로덕션에서 작동하지 않았습니다. 서비스의 일부로 포트 315를 열어야 한다는 것을 잊고 있었던 것입니다. 원인을 깨닫고 문제를 해결하는 데 하루 이상이 걸렸습니다. 프로덕션에서 해당 포트를 연 후에야 모든 것이 예상대로 작동했습니다.
‘Andy 님은 화이트 보드에 “배포 단계 간 구성 불일치”라고 적습니다.’
Andy: 이 대화가 좋은 시작점이 된다고 생각합니다. 이슈를 조사하고 어떤 해결 방안을 찾을 수 있는지 살펴봅시다. 오늘 제기된 문제점은 다음과 같습니다.
- QA에 대한 종속성 버전 관리 문제
- VM을 사용하여 앱 격리를 해결하여 발생하는 오버헤드
- 배포 단계 간의 구성 불일치
모든 것을 하나의 컨테이너에 결합하기
다음 날 아침 Andy 님은 회의를 소집하여 팀에게 새로운 아이디어를 제시합니다.
Andy: 어제 우리가 직면한 과제에 대한 몇몇 동료와 이야기를 나눴는데 그들은 몇 가지 흥미로운 제안을 했습니다. 제가 시도해 보고 싶은 것은 Docker입니다. Docker는 전체 애플리케이션을 컨테이너로 패키징하는 기술입니다.
Amita: 컨테이너가 뭔가요? .zip 파일 같은 것인가요?
Andy: 꼭 그렇지는 않습니다. 호스트 운영 체제에서 직접 실행되도록 설계된 경량 가상 머신에 보다 가깝습니다. 프로젝트를 빌드할 때 출력은 소프트웨어와 해당 종속성을 포함한 컨테이너입니다. 그러나 이것은 완전히 가상화된 시스템이 아니므로 실행되는 데 채 1초도 걸리지 않습니다.
Tim: 보안 및 격리는 어떻게 처리되나요?
Andy: 보안 및 격리는 호스트 운영 체제에 의해 처리됩니다. 컨테이너가 호스트 프로세스에서 실행되면 컨테이너가 동일 호스트 머신의 다른 프로세스에서 격리됩니다. 격리는 컨테이너가 다른 컨테이너가 수행 중인 작업에 관계 없이 필요한 모든 버전의 구성 요소를 로드할 수 있게 해 줍니다. 이는 여러 컨테이너를 동일한 호스트에서 동시에 실행할 수 있음을 의미하기도 합니다.
Amita: 프로덕션 환경에 매우 적합한 기술이네요. 하지만 우리가 파이프라인의 초기 단계에 직면하는 문제를 Docker로 해결할 수 있을까요?
Andy: 물론이죠! 소스 코드 또는 이진 파일 세트를 전달하는 대신 전체 컨테이너가 아티팩트가 됩니다. 즉, Mara 님이 개발 작업을 할 때 디버깅 세션이 그녀의 머신에 호스트된 컨테이너에 대해 로컬로 실행됩니다. Amita 님은 테스트를 수행할 때 동일한 컨테이너의 복사본으로서 필요한 모든 버전의 종속성이 이미 포함된 복사본에 대해 테스트를 수행하게 됩니다. Tim 님은 프로덕션 환경을 관리할 때 Mara 님과 Amita 님이 개발한 동일한 컨테이너의 독립 실행형 복사본을 모니터링하게 됩니다.
Mara: 컨테이너 애플리케이션 개발의 난이도는 얼마나 되나요? 기존 코드를 대폭 변경해야 하나요?
Andy: 컨테이너는 패키징 및 배포 기술에 가깝습니다. 우리가 작성하는 기본 소프트웨어에는 영향을 주지 않습니다. 빌드 마지막 단계에서 Docker 컨테이너를 생성하도록 도구에 지시하기만 하면 됩니다. 그런 다음 디버그할 때 애플리케이션이 로컬 웹 서버 대신 해당 로컬 컨테이너에서 실행됩니다. 실제로 Visual Studio와 같은 도구조차도 Docker 및 IIS Express 같은 디버그 환경 간에 전환하여 필요한 유연성을 발휘할 수 있도록 해 줍니다. 실제로 저는 지난 밤에 프로세스를 테스트하기 위해 우리 회사의 웹 사이트 프로젝트를 포크하고 이를 변환하여 Docker 컨테이너로 빌드했습니다. 필요한 것은 몇 가지 기본 컨테이너 구성을 추가하는 것뿐이었습니다. 기존 코드를 변경할 필요가 없었습니다.
Mara: 반가운 소식이네요. Azure Pipelines에서 Andy 님의 포크에서 가져온 릴리스 파이프라인을 업데이트하여 Docker 버전을 빌드하고 배포할 수도 있겠네요.
Andy: 제 마음을 읽고 계시네요.
Docker란 무엇인가요?
Docker는 이식 및 자급 자족이 가능한 컨테이너의 패키징 및 배포를 자동화하는 기술입니다. Docker 컨테이너는 개발 머신, 부서 서버, 엔터프라이즈 데이터 센터 또는 클라우드에서 Docker 호스트를 찾을 수 있는 모든 위치에서 실행할 수 있습니다. Azure는 컨테이너 기반 애플리케이션을 실행하는 여러 가지 방법을 App Service에 담아 또는 Kubernetes 같은 오케스트레이션 기술로 관리되는 클러스터의 일부로 제공합니다.
Tailspin 팀은 이 시나리오에서 Docker 컨테이너를 선택했습니다. Docker 컨테이너가 팀의 모든 필요를 충족했기 때문이었습니다.
QA에 대한 종속성 버전 관리 문제: 애플리케이션은 올바른 버전의 종속성을 가져오는 컨테이너로 패키지됩니다.
VM을 사용한 앱 격리 해결로 인한 오버헤드: 많은 격리된 컨테이너는 리소스 효율성을 높이기 위해 더 빠른 시작 시간을 포함하여 가상 머신에 대한 이점을 통해 동일한 호스트에서 실행할 수 있습니다.
DevOps 단계 간의 구성 불일치: 컨테이너는 노출해야 하는 포트와 같은 구성 요구 사항을 자동화하는 매니페스트와 함께 제공됩니다.
Docker 컨테이너 도입은 마이크로 서비스 아키텍처를 위한 핵심 단계일 수 있습니다. 이에 관한 자세한 내용은 나중에 논의하겠습니다.