컨테이너가 중요한 이유는 무엇인가요?

이 단원에서는 Tailspin 팀을 따라 DevOps 프로세스에 필요한 몇 가지 개선 사항을 설명합니다. 이 시나리오에서 팀은 Docker를 사용하여 웹 애플리케이션을 컨테이너화합니다. 그런 다음 팀은 CI/CD 파이프라인을 업데이트하여 지원합니다.

힘든 몇 주였다

지난 몇 주 동안 Tailspin에서 어려운 시기였습니다. 팀들은 여러 가지 이유 때문에 마감일을 맞추는 데 어려움을 겪고 있고, 회사 전체의 생산성에 대한 우려가 제기되었습니다. Andy는 Space Game 웹 사이트 팀의 일부 주요 이해 관계자를 함께 호출하여 경영진에게 예정된 프레젠테이션에 대한 피드백을 수집했습니다.

앤디: 들러 주셔서 감사합니다. 지난 몇 주가 모두에게 어려웠다는 것을 알고 있습니다만, 좋은 소식이 있습니다. 경영진은 내일 오프사이트에서 성과를 개선하기 위해 할 수 있는 변경에 대한 제안을 듣고 있습니다. 그들은 DevOps 성공에 대한 사례 연구를 발표하도록 저를 초대했으며 우리가 가질 수있는 다른 아이디어에도 열려 있다고 말했습니다. 저는 이 모임을 브레인스토밍의 기회로 사용할 수 있기를 바랐습니다. 누가 먼저 가고 싶어?

모두가 아미타를 본다. 그녀는 최근에 특히 좌절했습니다.

Amita: 내가 먼저 갈거야. 아시다시피 여러 팀을 테스트하고 각 팀이 자체 기술 스택을 사용하기 때문에 어려울 수 있습니다. .NET 또는 Java와 같은 동일한 기본 플랫폼을 사용하는 경우에도 종종 다른 버전을 대상으로 합니다. 테스트해야 하는 코드를 실행할 수 있는 상태에서 테스트 환경을 가져오는 데 하루의 절반을 보내는 경우가 있습니다. 문제가 해결되지 않으면 코드에 버그가 있는지 또는 실수로 4.3.2 대신 버전 4.2.3을 구성했는지 여부를 알기 어렵습니다.

Andy는 화이트보드에 "QA에 대한 종속성 버전 관리 과제"를 씁니다.

팀: 나는 그 좌절에 운영 작업을 추가하고 싶습니다. 고유한 버전 요구 사항이 있는 팀이 몇 명 있으므로 해당 버전 및 구성 요소 요구 사항이 다른 앱과 충돌하지 않도록 하기 위해 자체 가상 머신에 앱을 게시해야 합니다. 추가 VM 집합 유지 관리와 관련된 오버헤드 외에도 해당 앱이 나란히 실행될 수 있는 경우보다 비용이 많이 듭니다.

Andy는 화이트보드에 "VM을 사용하여 앱 격리를 해결하는 데 따른 오버헤드"라고 씁니다.

마라: 나는 개발 측에서 뭔가를 가지고있다. 몇 주 전에 피어 투 피어 업데이트 시스템에서 작업하고 있었고 모든 것이 내 컴퓨터에서 작동했지만 배포를 위해 전달했을 때 프로덕션에서 작동하지 않았습니다. 서비스의 일환으로 포트 315를 열어야 한다는 사실을 잊어버렸습니다. 문제를 해결하는 데 하루가 넘게 걸렸고 무슨 일이 일어나고 있는지 깨달았습니다. 프로덕션에서 해당 포트를 연 후에야 모든 것이 예상대로 작동했습니다.

Andy는 화이트보드에 "배포 단계 간의 구성 불일치"를 씁니다.

앤디: 나는이 대화가 좋은 시작이라고 생각합니다. 이러한 문제를 연구하고 내가 내놓을 수있는 것을 보자. 제가 들은 우려 사항은 다음과 같습니다.

• QA에 대한 종속성 버전 관리 문제
• VM을 사용하여 앱 격리를 해결하여 발생하는 오버헤드
• 배포 단계 간의 구성 불일치

이 모든 것을 하나의 컨테이너에 배치

다음날 아침, Andy는 모임을 소집하여 팀에 새로운 아이디어를 제시합니다.

앤디: 어제 몇몇 동료들과 우리가 직면하고 있는 어려움에 대해 이야기했고, 그들은 몇 가지 흥미로운 제안을 했습니다. 제가 시도해 볼 수 있는 것은 Docker입니다. 전체 애플리케이션을 컨테이너로 패키징하는 기술입니다.

Amita: 컨테이너란? .zip 파일과 같은가요?

앤디: 그렇지도 않아. 호스트 운영 체제에서 직접 실행되도록 설계된 경량 가상 머신과 비슷합니다. 프로젝트를 빌드할 때 출력은 소프트웨어 및 해당 종속성을 포함하는 컨테이너입니다. 그러나 완전한 가상화된 시스템이 아니므로 1초 이내에 스핀업할 수 있습니다.

팀: 보안 및 격리를 어떻게 처리하나요?

앤디: 보안 및 격리는 호스트 운영 체제에서 처리됩니다. 컨테이너가 호스트 프로세스에서 실행되면 컨테이너는 동일한 호스트 머신의 다른 프로세스와 격리됩니다. 이 격리를 통해 컨테이너는 다른 컨테이너가 수행하는 작업과 관계없이 필요한 구성 요소의 버전을 로드할 수 있습니다. 또한 동일한 호스트에서 동시에 여러 컨테이너를 쉽게 실행할 수 있습니다.

Amita: 이는 프로덕션 환경에 적합하지만 파이프라인의 앞부분에서 직면한 문제를 해결하나요?

앤디: 절대로! 소스 코드 또는 이진 파일 집합을 전달하는 대신 전체 컨테이너가 아티팩트가 됩니다. 즉, Mara가 개발 중일 때 디버깅 세션은 컴퓨터에서 호스트되는 컨테이너에 대해 로컬로 실행됩니다. Amita는 테스트할 때 해당 종속성의 모든 필수 버전을 이미 포함하는 동일한 컨테이너의 복사본에 대해 테스트합니다. Tim이 프로덕션 환경을 관리할 때 모니터링하는 컨테이너는 Mara가 개발하고 Amita에서 테스트한 동일한 컨테이너의 독립 실행형 복사본입니다.

마라: 컨테이너 애플리케이션을 개발하는 것은 얼마나 어려운가요? 기존 코드를 크게 변경해야 합니까?

앤디: 컨테이너는 더 많은 패키징 및 배포 기술입니다. 이러한 소프트웨어는 우리가 작성하는 기본 소프트웨어에 영향을 주지 않습니다. 빌드가 끝날 때 Docker 컨테이너를 생성하도록 도구에 지시할 수 있습니다. 그런 다음 디버그할 때 애플리케이션이 로컬 웹 서버 대신 해당 로컬 컨테이너에서 실행됩니다. 실제로 Visual Studio와 같은 도구를 사용하면 Docker 및 IIS Express와 같은 디버그 환경 간에 전환하여 필요한 유연성을 제공할 수 있습니다. 실제로 어젯밤에 웹 사이트 프로젝트를 포크하고 프로세스를 테스트하기 위해 Docker 컨테이너로 빌드하도록 변환했습니다. 몇 가지 기본 컨테이너 구성을 추가하기만 하면 됩니다. 기존 코드를 변경할 필요가 없었습니다.

마라: 그것을 알게 되어 기뻐요. Azure Pipelines의 릴리스 파이프라인을 포크에서 업데이트하여 Docker 버전을 빌드하고 배포할 수도 있습니다.

앤디: 당신은 내 마음을 읽습니다.

Docker란?

Docker는 이식 가능한 자급자족 컨테이너의 패키징 및 배포를 자동화하는 기술입니다. Docker 컨테이너는 개발 머신, 부서 서버, 엔터프라이즈 데이터 센터 또는 클라우드에서 Docker 호스트를 찾을 수 있는 모든 위치에서 실행할 수 있습니다. Azure는 App Service를 포함하거나 Kubernetes와 같은 오케스트레이션 기술로 관리되는 클러스터의 일부로 컨테이너 기반 애플리케이션을 실행하는 여러 가지 방법을 제공합니다.

Tailspin 팀은 모든 요구 사항을 충족하므로 이 시나리오에 대한 Docker 컨테이너를 선택했습니다.

• QA에 대한 종속성 버전 관리 문제: 애플리케이션은 올바른 버전의 종속성을 가져오는 컨테이너로 패키지됩니다.

• VM을 사용한 앱 격리 해결로 인한 오버헤드: 많은 격리된 컨테이너는 리소스 효율성을 높이기 위해 더 빠른 시작 시간을 포함하여 가상 머신에 대한 이점을 통해 동일한 호스트에서 실행할 수 있습니다.

• DevOps 단계 간의 구성 불일치: 컨테이너는 노출해야 하는 포트와 같은 구성 요구 사항을 자동화하는 매니페스트와 함께 제공됩니다.

Docker 컨테이너를 채택하는 것은 마이크로 서비스 아키텍처를 향한 중요한 단계일 수 있습니다. 나중에 자세히 살펴보겠습니다.