Windows 컨테이너를 사용하여 기존 애플리케이션 "컨테이너화"

  • 아티클

적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016

Windows 컨테이너는 기존 또는 레거시 애플리케이션을 현대화하는 훌륭한 메커니즘을 제공합니다. "컨테이너로 리프트 앤 시프트"라고 하는 이 접근 방식에 대해 들어 보신 분도 있겠지만, 리프트 앤 시프트라는 은유는 워크로드를 물리적 머신에서 가상 머신으로 이동하는 것을 지칭하는 뜻으로 시작되었으며 최근에는 워크로드를 있는 그대로 클라우드(프라이빗 또는 퍼블릭 상관없이)로 이동하는 것을 언급할 때 사용되고 있습니다. 현재 이 용어는 VM(가상 머신) 마이그레이션에 더 적합한 용어입니다. 그러나 컨테이너는 VM이 아닙니다. VM으로 생각할 경우 애플리케이션을 컨테이너화할 수 있는 방법 또는 애플리케이션을 컨테이너화할 수 있는지(또는 해야 하는지) 여부를 착각하게 될 수 있습니다.

이 토픽에서는 기존 애플리케이션을 Windows 컨테이너로 이동하는 방법에 대한 실용적인 지침을 제공합니다. 특별한 고려 사항을 미리 설명하여 컨테이너화해야 하는 애플리케이션의 우선 순위를 지정하는 데 도움을 주는 것이 목적입니다.

소개

Windows 컨테이너인 것과 Windows 컨테이너가 아닌 것

일반 용어인 컨테이너는 운영 체제(OS)를 가상화하는 기술을 나타냅니다. 이 가상화는 서버/호스트 자체의 OS에서 격리 수준을 제공하므로, 애플리케이션 개발자 및 운영 팀의 민첩성이 향상됩니다.

Windows 컨테이너는 컨테이너 기술을 구현한 것입니다. Windows OS에서 격리된 가상 운영 체제 인스턴스를 제공합니다. 그러나 컨테이너와 호스트가 전체적으로 상호 종속되는 것은 불가능합니다. Windows 컨테이너는 리소스 및 함수 수요를 Windows OS와 조율해야 하기 때문입니다. 이 기능이 왜 중요할까요? Windows 컨테이너는 전체 가상화된 서버가 아니므로 애플리케이션에서 수행하려는 작업 중 일부는 가상화된 OS만으로는 수행할 수 없습니다.

이 토픽에 대한 자세한 내용은 컨테이너와 가상 머신 비교에서 확인할 수 있습니다. 그러나 컨테이너와 VM을 구분하는 데 도움이 되는 몇 가지 사항이 있습니다.

  • 컨테이너는 데스크톱 애플리케이션 가상화와 동일한 솔루션이 아닙니다. 컨테이너는 대화형 세션이 필요 없는 서버 쪽 애플리케이션만 지원합니다. 컨테이너는 특수 컨테이너 이미지에서 실행되므로 그래픽 프런트 엔드가 필요 없는 애플리케이션만 지원합니다.
  • 컨테이너는 본질적으로 사용 후 삭제됩니다. 즉, 기본적으로 컨테이너 인스턴스의 상태를 저장하는 메커니즘이 없습니다. 인스턴스가 실패하면 다른 인스턴스가 그 위치를 차지합니다.

컨테이너 기술은 Linux에서 시작되었으며, Docker가 표준으로 부상하고 있습니다. 컨테이너 기능이 Windows에서도 최대한 동일하게 작동하도록 Microsoft는 Docker와 긴밀히 협력해 왔습니다. Linux와 Windows의 내재적 차이점은, 사실은 Linux와 Windows의 차이점일 뿐인데 Windows 컨테이너의 제한인 것처럼 보이는 형태로 나타날 수 있습니다. 반면 Windows 컨테이너는 Hyper-V 격리와 같은 몇 가지 고유한 구현을 제공하며, 이에 대한 내용은 나중에 설명하겠습니다. 이 토픽은 이러한 차이점 및 수용 방법을 이해하는 데 도움이 됩니다.

컨테이너 사용의 이점

단일 물리적 호스트에서 여러 VM을 실행하는 것과 매우 유사하게 단일 물리적 또는 가상 호스트에서 여러 컨테이너를 실행할 수 있습니다. 그러나 VM과 달리, 컨테이너의 OS를 관리할 필요가 없으므로 애플리케이션 개발 및 기본 인프라에 유연하게 집중할 수 있습니다. 또한 OS에서 지원하는 다른 프로세스의 영향을 받지 않도록 애플리케이션을 격리할 수 있습니다.

컨테이너는 작동하는 애플리케이션에 필요한 리소스를 만들고 동적으로 중지하는 간단한 방법을 제공합니다. 애플리케이션 수요가 증가함에 따라 VM을 만들고 배포할 수 있지만, 컨테이너를 스케일 아웃에 사용하는 것이 더 빠릅니다. 뿐만 아니라 컨테이너를 사용하면 크래시 또는 하드웨어 중단 시 신속하게 다시 시작할 수 있습니다. 컨테이너는 모든 환경에서 작동하도록 애플리케이션 종속성을 "포함"하고 있으므로, 코드를 거의 또는 전혀 변경하지 않고 개발 환경에서 프로덕션 환경으로 앱을 가져올 수 있습니다. Microsoft 개발자 도구에 Docker가 통합되어 최소한의 코드 변경으로 기존 애플리케이션을 컨테이너화할 수 있는 기능도 애플리케이션 개발 및 유지 관리의 강력한 요소입니다.

마지막으로, 컨테이너 사용 시 가장 중요한 이점 중 하나는 리소스 충돌 없이 동일한 호스트에서 실행되는 앱의 여러 버전을 운영할 수 있으므로 민첩한 앱 개발이 가능합니다.

Microsoft의 기존 애플리케이션에 컨테이너를 사용할 때 얻을 수 있는 이점 목록은 .NET 설명서 페이지에서 찾을 수 있습니다.

중요한 격리 수준 개념

Windows 컨테이너는 Windows OS로부터 격리를 제공하며, 이러한 격리는 앱을 빌드 및 테스트하고 프로덕션으로 승격할 때 이점이 있습니다. 그러나 애플리케이션 컨테이너화에 대해 생각할 때 격리를 달성하는 방법을 이해하는 것이 중요합니다.

Windows 컨테이너는 두 가지 고유한 런타임 격리 모드인 프로세스와 Hyper-V를 제공합니다. 두 격리의 컨테이너는 동일하게 생성 및 관리되고 동일하게 작동합니다. 그래서 차이점은 무엇이며 왜 차이점을 알아야 할까요? 프로세스 격리에서는 네임스페이스, 리소스 제어 및 기타 기능을 통해 제공되는 격리를 사용하여 여러 컨테이너가 단일 호스트에서 동시에 실행됩니다. 프로세스 격리 모드의 컨테이너는 동일한 커널을 서로 공유하고 호스트와도 공유합니다. 이는 Linux 컨테이너의 실행 방식과 대체로 동일합니다.

Hyper-V 격리에서는 여러 컨테이너가 단일 호스트에서 동시에 실행되는 것은 같지만, 고도로 최적화된 가상 머신 내에서 컨테이너 실행되며 각 컨테이너는 효과적으로 자체 커널을 가져옵니다. 이 가상 머신(사실상 "유틸리티" VM)이 있으면 각 컨테이너와 컨테이너 호스트 간에 하드웨어 수준 격리가 제공됩니다.

어떤 면에서 Hyper-V 격리 모드는 VM과 컨테이너의 하이브리드와 거의 비슷하며, 앱에 다중 테넌시가 필요할 때 특히 유용한 추가 보안 계층을 제공합니다. 그러나 Hyper-V 격리 모드를 사용하면 다음과 같은 단점이 있습니다.

  • 컨테이너의 시작 시간이 길수록 전체적인 앱 성능에 영향을 미칠 가능성이 높습니다.
  • 모든 도구가 Hyper-V 격리에서 기본적으로 작동하는 것은 아닙니다.
  • 현재 AKS(Azure Kubernetes Service)뿐 아니라 Azure Stack HCI의 AKS도 Hyper-V 격리를 지원하지 않습니다.

두 격리 모드가 구현되는 방법에 대한 자세한 내용은 격리 모드에서 확인할 수 있습니다. 앱을 처음으로 컨테이너화할 때에는 두 모드 중에 선택해야 합니다. 다행히 애플리케이션 또는 컨테이너를 변경할 필요가 없으므로 나중에 한 모드에서 다른 모드로 쉽게 변경할 수 있습니다. 그러나 앱을 컨테이너화할 때, 두 모드 중에서 선택하는 것이 가장 먼저 해야 할 일 중 하나입니다.

컨테이너 오케스트레이션

OS 관리에 대한 걱정 없이 단일 호스트 또는 여러 호스트에서 여러 컨테이너를 실행하는 기능은 뛰어난 유연성을 제공하므로, 마이크로 서비스 기반 아키텍처로 전환하는 데 도움이 됩니다. 하지만 이러한 유연성을 얻는 대신 컨테이너 및 마이크로 서비스 기반 환경의 무빙 파츠가 빠르게 증가하여 너무 많은 무빙 파츠를 추적해야 할 수 있습니다. 다행히 부하 분산, 고가용성, 컨테이너 예약, 리소스 관리 등을 관리하는 것은 컨테이너 오케스트레이터의 역할입니다.

오케스트레이터라는 이름이 적절하지 않을 수도 있습니다. 오케스트레이터는 음악을 계속 연주하도록 여러 컨테이너의 활동을 조율한다는 측면에서 오케스트라의 지휘자와 더 비슷합니다. 한편 오케스트레이터는 OS의 기능과 유사한 방식으로 컨테이너의 예약 및 리소스 할당을 처리합니다. 따라서 애플리케이션을 컨테이너화하도록 전환할 때 Windows 컨테이너를 지원하는 오케스트레이터 중에서 선택해야 합니다. 가장 일반적인 오케스트레이터는 Kubernetes 및 Docker Swarm입니다.

Windows 컨테이너로 이동할 수 없는 것

앱을 컨테이너화할 수 있는지 여부를 고민할 때, Windows 컨테이너를 옵션으로 사용할 수 없게 만드는 요소 목록부터 시작하는 것이 가장 쉬울 것입니다.

다음 표에는 Windows 컨테이너로 이동할 수 없는 앱 유형과 그 이유가 요약되어 있습니다. 테이블 아래의 하위 섹션에 모든 이유가 자세히 설명되어 있습니다. 이러한 제한의 이유를 이해하면 VM과 어떻게 다른지를 포함하여 컨테이너가 실제로 무엇인지 명확하게 이해할 수 있습니다. 그러면 컨테이너화 가능한 기존 앱에 활용할 수 있는 Windows 컨테이너의 기능을 보다 정확하게 평가할 수 있습니다.

참고: 아래 목록은 전체 목록이 아닙니다. 고객이 컨테이너화를 시도하는 것을 Microsoft에서 목격한 앱 목록입니다.

지원되지 않는 애플리케이션/기능 지원되지 않는 이유 해결 가능 여부
데스크톱이 필요한 애플리케이션 컨테이너는 GUI(그래픽 사용자 인터페이스)를 지원하지 않습니다. 애플리케이션에 GUI만 설치하면 되는 경우에는 자동 설치로 변경하면 문제가 해결될 수도 있습니다.
RDP(원격 데스크톱 프로토콜)를 사용하는 애플리케이션 RDP는 대화형 세션용이므로 위의 원칙이 여기에도 적용됩니다. 원격 관리의 대안으로 WAC(Windows Admin Center) 또는 원격 PowerShell을 사용 가능할 수도 있습니다.
상태 저장 애플리케이션 컨테이너는 사용 후 삭제됩니다. 예, 최소한의 변경만 필요한 일부 애플리케이션은 컨테이너 내에 데이터 또는 상태를 저장하지 않습니다.
데이터베이스 애플리케이션 컨테이너는 사용 후 삭제됩니다. 예, 최소한의 변경만 필요한 일부 애플리케이션은 컨테이너 내에 데이터 또는 상태를 저장하지 않습니다.
Active Directory Active Directory의 디자인 및 목적에 따라 컨테이너에서 실행할 수 없습니다. 아니요. 그러나 Active Directory에 종속된 앱은 gMSA(그룹 관리 서비스 계정)를 사용할 수 있습니다. gMSA에 대한 자세한 내용은 아래에 나와 있습니다.
이전 버전의 Windows Server Windows Server 2016 이상만 지원됩니다. 아니요. 그러나 애플리케이션 호환성은 옵션일 수 있습니다. 대부분의 Windows Server 2008/R2 이하 앱은 최신 버전의 Windows Server에서 실행됩니다.
.NET Framework 버전 2.0 이하를 사용하는 앱 .NET Framework를 지원하려면 특정 컨테이너 이미지가 필요하며, 최신 버전만 지원됩니다. 2.0 미만 버전은 전혀 지원되지 않습니다. 2.0 이상 버전에 필요한 컨테이너 이미지는 아래를 참조하세요.
타사 프레임워크를 사용하는 앱 Microsoft는 Windows 컨테이너에서 타사 프레임워크의 사용을 구체적으로 인증하거나 지원하지 않습니다. 프레임워크 또는 앱 공급업체에 문의하여 Windows 컨테이너에 대한 지원 정책을 확인하세요. 자세한 내용은 아래를 참조하세요.

이러한 제한이 있다고 가정하겠습니다.

데스크톱이 필요한 애플리케이션

컨테이너는 사용자 상호 작용이 가능한 애플리케이션을 포함하여 다른 애플리케이션에서 호출되는 임시 함수에 적합합니다. 그러나 GUI 자체가 있는 애플리케이션에는 사용할 수 없습니다. 이는 애플리케이션 자체에는 GUI가 없지만 GUI를 사용하는 설치 관리자가 있는 경우에도 마찬가지입니다. 일반적으로 PowerShell을 사용하여 Windows Installer를 호출할 수 있지만, 애플리케이션에서 GUI를 통해 설치해야 하는 경우에는 해당 요구 사항 때문에 컨테이너화 후보에서 제외됩니다.

이는 Windows 컨테이너의 구현 방식과 관련된 문제가 아니라 컨테이너가 작동하는 방식에 대한 기본 개념입니다.

앱에 GUI API가 필요한 경우에는 문제가 다릅니다. API에서 제공하는 GUI가 지원되지 않더라도 해당 API는 지원됩니다. Nano Server x Server Core x Server - 적합한 기본 이미지는 무엇인가요? 토픽에 더 자세히 설명되어 있습니다.

RDP를 사용하는 애플리케이션

RDP(원격 데스크톱 프로토콜)의 전체 목적은 대화형 시각적 세션을 설정하는 것이므로, 방금 설명한 GUI 제한 사항도 적용됩니다. RDP를 사용하는 애플리케이션은 있는 그대로 컨테이너화할 수 없습니다.

하지만 좋은 대안으로 Windows Admin Center 같은 원격 관리 도구가 있습니다. Windows Admin Center를 사용하여 Windows 컨테이너 호스트 및 컨테이너 자체를 RDP 없이 관리할 수 있습니다. 호스트 및/또는 컨테이너에 대한 원격 PowerShell 세션을 열어 관리할 수도 있습니다.

상태 저장 애플리케이션

상태 데이터를 보존해야 하는 애플리케이션은 필요한 데이터를 한 세션에서 다음 세션으로 격리하고 영구 스토리지에 저장하는 경우에만 컨테이너화할 수 있습니다. 이렇게 하려면 사소할 수도 있고 그렇지 않을 수도 있는 일부 "재설계"가 필요하지만 재설계를 진행하면 컨테이너화에 대한 이 장벽이 제거됩니다.

상태의 예로는 이미지 또는 음악 파일을 로컬 폴더에 저장하는 웹 애플리케이션이 있습니다. 기존 Windows 환경에서는 쓰기 작업이 종료되는 시점에 파일이 디스크에 저장되므로, 인스턴스(여기서는 VM)가 실패할 경우 파일을 다시 가져오면 파일이 그 자리에 계속 있습니다. 반면 쓰기 작업을 수행하는 컨테이너 인스턴스가 실패하면 새 컨테이너 인스턴스에는 해당 파일이 포함되지 않습니다. 따라서 모든 컨테이너 인스턴스가 중앙 집중식 지속형 위치에 상태 데이터 또는 파일을 저장할 수 있도록 영구 스토리지를 사용해야 합니다. 이러한 유형의 재설계에서는 애플리케이션의 코드를 변경할 필요가 없고 Windows 인스턴스에서 사용하는 스토리지 유형만 변경하면 됩니다. 자세한 내용은 스토리지에 대한 Windows 컨테이너 설명서를 확인하세요.

그러나 이는 또 다른 관련 토픽을 야기합니다.

데이터베이스 애플리케이션

일반적으로 데이터베이스 애플리케이션은 컨테이너화에 적합한 후보가 아닙니다. 컨테이너 내에서 데이터베이스를 실행할 수 있지만, 일반적으로 두 가지 이유로 기존 데이터베이스를 컨테이너화하는 것은 바람직하지 않습니다.

첫째, 데이터베이스에 필요한 성능과 관련하여 호스트에 하드웨어 리소스 전체가 필요할 수 있으며, 이는 통합의 가치를 저해합니다. 둘째, 단일 데이터베이스 계층의 여러 인스턴스가 수행하는 쓰기 작업을 조정해야 합니다. 컨테이너 오케스트레이션으로 이 문제를 해결할 수 있지만, 기존 데이터베이스의 경우 오케스트레이션이 오버헤드가 될 수 있습니다. Microsoft SQL Server 같은 대부분의 데이터베이스는 기본 제공 부하 분산 및 고가용성 메커니즘을 갖고 있습니다.

Windows Server의 인프라 역할

Windows Server 인프라 역할은 주로 운영 체제(예: AD, DHCP 및 파일 서버)에 가까운 함수를 처리합니다. 따라서 실행 중인 컨테이너에는 사용할 수 없습니다. 그러므로 이러한 역할이 필요한 애플리케이션은 항상 컨테이너화하기가 어렵습니다.

일부 애매한 영역이 있습니다. 예를 들어 DNS와 같은 일부 기능은 컨테이너에서 실제로 사용되지 않더라도 Windows 컨테이너에서 작동할 수 있습니다. 다른 인프라 역할은 단순히 기본 컨테이너 이미지에서 제거되며 Active Directory, DHCP 등에 설치할 수 없습니다.

AD(Active Directory)

Active Directory는 20여 년 전에 Windows 2000 Server와 함께 릴리스되었습니다. 데이터베이스에 저장된 개체로 각 디바이스 또는 사용자를 표시되는 메커니즘을 사용합니다. 이 관계는 밀접하게 결합되어 있으며, 실제 사용자 또는 디바이스가 더 이상 작동하지 않더라도 개체가 데이터베이스에 유지됩니다. Active Directory에 대한 이러한 접근 방식은 해제되면 수명이 짧아지거나 삭제될 것으로 예상되는 컨테이너의 사용 후 삭제 특성과 정면으로 배치됩니다. Active Directory와 이 일대일 관계를 유지하는 것은 이러한 시나리오에 적합하지 않습니다.

이러한 이유로 Windows 컨테이너는 도메인에 가입할 수 없습니다. 따라서 Windows 컨테이너에서 Active Directory Domain Services를 인프라 역할로 실행할 수 없습니다. PowerShell 모듈을 실행하여 Windows 컨테이너 내에서 원격으로 도메인 컨트롤러를 관리할 수 있습니다.

Active Directory에 종속된 Windows 컨테이너에서 실행되는 애플리케이션의 경우 gMSA(그룹 관리 서비스 계정)를 사용할 수 있으며, 이 내용은 뒤에서 자세히 설명하겠습니다.

.NET Framework 버전 2.0 이하를 사용하는 앱

애플리케이션에 .NET이 필요한 경우 컨테이너화 기능은 전적으로 애플리케이션에서 사용하는 .NET Framework 버전에 달렸습니다. .NET Framework 2.0 미만 버전은 전혀 지원되지 않습니다. 나중에 설명하겠지만, 2.0 이상 버전에서는 특정 이미지를 사용해야 합니다.

Microsoft가 아닌 타사 아닌 프레임워크를 사용하는 앱

일반적으로 Microsoft는 타사 프레임워크 또는 애플리케이션을 인증하거나 Windows 컨테이너(또는 해당 용도로 사용되는 물리적 머신 및 가상 머신)에서 실행되도록 지원할 수 없습니다. 그러나 Microsoft는 Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat 등 여러 타사 프레임워크 및 도구의 유용성을 위해 자체 내부 테스트를 수행합니다.

타사 프레임워크 또는 소프트웨어의 경우 Windows 컨테이너에서 해당 공급업체와 함께 지원 여부를 확인하세요.

컨테이너화에 적합한 후보

앱 컨테이너화의 어려운 제한 사항을 알아보았으므로, Windows 컨테이너에 더 적합한 앱 유형을 쉽게 확인할 수 있습니다. Windows 컨테이너에 적합한 후보와 컨테이너화 시에 생각해야 할 특별 고려 사항이 다음 표에 정리되어 있습니다.

애플리케이션 유형 좋은 후보인 이유 특별 고려 사항
콘솔 애플리케이션 GUI 제한이 없는 콘솔 앱은 컨테이너에 적합한 후보입니다. 애플리케이션의 요구 사항에 따라 적절한 기본 컨테이너 이미지를 사용해야 합니다.
Windows 서비스 직접 사용자 상호 작용이 필요 없는 백그라운드 프로세스이기 때문입니다. 애플리케이션의 요구 사항에 따라 적절한 기본 컨테이너 이미지를 사용해야 합니다. 컨테이너화된 백그라운드 프로세스를 계속 실행하려면 포그라운드 프로세스를 만들어야 합니다. 아래의 백그라운드 서비스에 대한 섹션을 참조하세요.
WCF(Windows Communication Foundation) 서비스 백그라운드에서도 실행할 수 있는 서비스 지향 앱이기 때문입니다. 애플리케이션의 요구 사항에 따라 적절한 기본 컨테이너 이미지를 사용해야 합니다. 컨테이너화된 백그라운드 프로세스를 계속 실행하려면 포그라운드 프로세스를 만들어야 할 수도 있습니다. 아래의 백그라운드 서비스에 대한 섹션을 참조하세요.
웹앱 웹 애플리케이션은 기본적으로 특정 포트에서 수신 대기하는 백그라운드 서비스이므로 컨테이너에서 제공하는 확장성을 활용할 수 있습니다. 따라서 컨테이너화에 적합한 후보입니다. 애플리케이션의 요구 사항에 따라 적절한 기본 컨테이너 이미지를 사용해야 합니다.

참고: 이러한 적절한 컨테이너화 후보조차도 Windows 컨테이너에서 다르게 처리해야 하는 핵심 Windows 기능 및 구성 요소에 사용할 수 있습니다. 이러한 실질적인 고려 사항에 대해 자세히 살펴보는 다음 섹션에서는 Windows 컨테이너의 기능을 보다 잘 활용할 수 있는 방법을 알아봅니다.

컨테이너화할 수 있는 애플리케이션에 대한 실질적인 고려 사항

앱 리노베이션 프로젝트는 일반적으로 앱의 비즈니스 기능 관점에서 특정 앱을 컨테이너화할 수 있는지 여부를 고려합니다. 그러나 비즈니스 기능은 기술적으로 컨테이너화 가능 여부를 결정하는 요인이 아닙니다. 중요한 것은 앱의 아키텍처, 즉 앱이 사용하는 기술 구성 요소입니다. 따라서 "내 HR 애플리케이션을 컨테이너화할 수 있나요?"와 같은 질문은 애플리케이션이 수행하는 작업이 아닌 차이점(및 애플리케이션이 사용하는 Windows 구성 요소/서비스)을 묻는 것이므로 쉽게 대답할 수 없습니다.

애플리케이션이 마이크로 서비스 아키텍처로 빌드되지 않은 경우에는 컨테이너화가 더 어려울 가능성이 높으므로 이는 중요한 차이점입니다. 컨테이너화를 진행하는 동안 특정 기능은 특별한 처리가 필요할 수 있습니다. 어떤 기능은 앱이 Windows 컨테이너에서 지원되지 않는 핵심 Windows 구성 요소 및 프레임워크를 사용하기 때문이고, 이벤트 로깅 및 모니터링과 같은 기능은 앱을 컨테이너화할 때만 명백해지는 Linux와 Windows 간의 고유한 차이 때문입니다. 하지만 예약된 작업 및 백그라운드 서비스와 같은 작업은 컨테이너가 VM이 아니라 사용 후 삭제되므로 특별한 처리가 필요하다는 관점에서 이해해야 합니다.

다음 표에는 컨테이너화에 대해 생각할 때 특별히 고려해야 하는 애플리케이션의 구성 요소/기능이 간략하게 요약되어 있습니다. 이어지는 하위 섹션에서는 각 시나리오를 처리하는 기술을 보여주는 예제를 포함하여 자세한 정보를 제공합니다. 아래 목록에서는 Windows 컨테이너에서 지원되는 시나리오를 다루지만, 이러한 시나리오는 이전 챕터의 지침을 준수해야 합니다. 예를 들어 백그라운드 서비스가 지원되지만 .NET Framework 1.1에서 백그라운드 서비스를 실행하는 것은 지원되지 않습니다.

특별한 처리가 필요한 Windows 기능/구성 요소 이유
MSMQ(Microsoft Messaging Queueing) MSMQ는 오래 전에 컨테이너에서 시작되었으며 메시지 큐에 대한 모든 배포 모델이 컨테이너 아키텍처와 호환되는 것은 아닙니다.
MSDTC(Microsoft Distributed Transaction Coordinator) MSDTC와 컨테이너 간의 이름 확인에는 특별한 고려 사항이 필요합니다.
IIS IIS는 VM과 동일하지만 컨테이너 환경에서 실행할 때 인증서 관리, 데이터베이스 연결 문자열 등과 같은 중요한 고려 사항이 있습니다.
예약형 작업 Windows 컨테이너는 모든 Windows 인스턴스와 마찬가지로 예약된 작업을 실행할 수 있습니다. 그러나 컨테이너 인스턴스를 계속 실행하려면 포그라운드 작업을 실행해야 할 수도 있습니다. 애플리케이션에 따라 이벤트 기반 접근 방식을 고려할 수 있습니다.
백그라운드 서비스 컨테이너는 임시 프로세스로 실행되므로, 컨테이너를 계속 실행하려면 추가 처리가 필요합니다.
.NET Framework 및 .NET(이전에는 .Net Core) 아래 하위 섹션에서 설명하는 대로 적절한 이미지를 사용하여 호환성을 보장해야 합니다.

기타 지원 구성 요소

특수 처리가 필요한 구성 요소 이유 대안
이벤트 로깅/모니터링 Windows가 이벤트 및 로그를 작성하는 방식은 본질적으로 Linux stdout과 다르기 때문입니다. 새 로그 모니터 도구를 사용하여 Linux와 Windows의 데이터를 모두 정규화하고 결합합니다.
Windows 컨테이너 보안 많은 보안 관행이 동일하게 유지되지만, 컨테이너에는 추가 보안 조치가 필요합니다. 용도에 맞게 빌드된 레지스트리 및 이미지 스캔 도구를 사용합니다. 자세한 내용은 나중에 설명합니다.
Windows 컨테이너 백업 컨테이너에 데이터 또는 상태가 없어야 합니다. 컨테이너 이미지뿐만 아니라 컨테이너에서 사용하는 영구 스토리지를 백업합니다.

Windows 구성 요소/기능

이번에는 컨테이너화할 수 있지만 추가 처리가 필요한 애플리케이션 및 구성 요소를 자세히 살펴보겠습니다.

MSMQ

애플리케이션이 MSMQ에 종속된 경우 컨테이너화 가능 여부는 MSMQ 배포 시나리오에 따라 달라집니다. MSMQ에는 여러 배포 옵션이 포함됩니다. 개인 큐 vs 공개 큐, 트랜잭션 여부 및 인증 유형이라는 요소에 따라 MSMQ가 원래 지원하도록 설계된 시나리오가 결정됩니다. 이 모든 것들을 Windows 컨테이너로 쉽게 이동할 수 있는 것은 아닙니다. 다음 표에는 지원되는 시나리오가 나열되어 있습니다.

Scope 트랜잭션인가요? 큐 위치 인증 유형 보내고 받나요?
프라이빗 예 동일한 컨테이너(단일 컨테이너) 익명 Yes
프라이빗 예 영구 볼륨 익명 Yes
프라이빗 예 도메인 컨트롤러 익명 Yes
프라이빗 예 단일 호스트(컨테이너 2개) 익명 Yes
공용 No 호스트 2개 익명 Yes
공용 Yes 호스트 2개 익명 Yes

Microsoft 내부 개발 팀에서 검증한 이러한 지원되는 시나리오와 관련하여 다음과 같은 몇 가지 참고 사항이 있습니다.

  • 격리 모드: 격리를 위한 프로세스 모드와 Hyper-V 모드 둘 다 위에 나열된 시나리오에서 작동합니다.
  • 최소 OS 및 컨테이너 이미지: MSMQ와 함께 사용할 것을 권장하는 최소 OS 버전은 Windows Server 2019입니다.
  • 영구 볼륨: 위의 시나리오는 영구 스토리지에 Azure 파일을 사용하여 AKS(Azure Kubernetes Service)에서 MSMQ를 실행하는 것으로 확인되었습니다.

위의 표와 함께 이러한 고려 사항을 검토하면, 지원되지 않는 유일한 시나리오는 Active Directory 인증이 필요한 큐라는 것을 알 수 있습니다. MSMQ는 아직 사용되지 않는 Active Directory에 종속되어 있으므로 현재는 gMSA(그룹 관리 서비스 계정)를 MSMQ와 통합할 수 없습니다.

MSMQ 대신 Azure Service Bus를 사용하세요. Azure Service Bus는 메시지 큐와 게시-구독 토픽(네임스페이스에 있음)이 있는 완전 관리형 엔터프라이즈 메시지 broker입니다. MSMQ에서 Azure Service Bus로 전환하려면 코드를 변경하고 애플리케이션을 재설계해야 하지만, 이렇게 하면 최신 플랫폼으로 이동할 수 있는 민첩성을 얻게 됩니다.

MSDTC

MSDTC(Microsoft Distributed Transaction Coordinator)는 대기업 간의 Windows 레거시 애플리케이션에서 많이 사용됩니다. MSDTC는 Windows 컨테이너에 설치할 수 있지만 작동하지 않고 Windows 컨테이너에서 재현할 수 없는 특정 시나리오가 있습니다.

  • 컨테이너를 만들 때 --name 매개 변수를 docker run 명령에 전달해야 합니다. 이 이름 매개 변수는 컨테이너가 Docker 네트워크를 통해 통신할 수 있도록 하는 매개 변수입니다. gMSA를 사용하는 경우 이름은 gMSA 계정 이름과 일치해야 하는 호스트 이름과 일치해야 합니다.
    • 다음은 gMSA를 사용하는 실행 명령의 예입니다.
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
  • 컨테이너는 NETBIOS 이름을 사용하여 서로를 확인할 수 있어야 합니다. 이 문제가 있는 경우 resolve 가장 좋은 방법은 컨테이너의 이름과 ip를 다른 호스트 파일에 추가하는 것입니다.
  • 두 컨테이너의 msdtc에 대한 uuid는 고유해야 합니다. 컨테이너의 PowerShell에서 "Get-Dtc"를 실행하여 uuid를 찾을 수 있습니다. 고유하지 않은 경우 resolve 한 가지 방법은 컨테이너 중 하나에서 msdtc를 제거하고 다시 설치하는 것입니다. "uninstall-dtc", "install-dtc"와 같은 powershelll 명령을 사용할 수 있습니다.
  • 현재 MSDTC는 Azure Kubernetes Services에서 지원되지 않습니다. AKS에서 MSDTC를 실행해야 하는 경우 GitHub의 Windows 컨테이너 리포지토리 에서 am 이슈를 열어 Windows 컨테이너 팀에 알려주세요.

IIS가 컨테이너와 VM에서 작동하는 방식의 차이점

IIS는 VM에서 작동할 때와 동일한 방식으로 Windows 컨테이너에서 작동합니다. 그러나 컨테이너 환경에서 실행할 때 다음과 같은 IIS 인스턴스 실행 측면을 고려해야 합니다.

  • 로컬 데이터용 영구 스토리지: 앱이 파일을 쓰거나 읽는 폴더는 IIS 인스턴스를 위해 VM에 보관하는 대표적인 예입니다. 컨테이너를 사용하는 경우 데이터가 컨테이너에 직접 기록되지 않도록 하는 것이 좋습니다. 컨테이너는 로컬 스토리지에 "스크래치 공간"을 사용하며, 새 컨테이너가 동일한 애플리케이션에 대해 제공되면 이전 컨테이너에서 해당 영역에 액세스할 수 없습니다. 따라서 컨테이너 인스턴스가 해당 스토리지에 액세스할 수 있도록 웹 애플리케이션에 액세스할 수 있어야 하는 데이터에 영구 스토리지를 사용해야 합니다.
  • 인증서: 컨테이너 인스턴스에 로컬 인증서를 사용할 수는 있지만 인증서를 업데이트해야 하는 경우 컨테이너 이미지를 다시 빌드해야 하므로 사용하지 말아야 합니다. 또는 수신 제어에 컨테이너 오케스트레이터를 사용할 수 있습니다. 수신 컨트롤러는 네트워크 정책을 적용하고 그 뒤에 호스트되는 웹 사이트의 인증서 관리를 처리할 수도 있습니다. 웹 사이트 관리에서 인증서 수명 주기 관리를 분리한다는 긍정적인 측면이 있습니다.
  • 데이터베이스 연결 문자열: 기존 IIS 배포의 경우 애플리케이션 배포의 일부로 DB 연결 문자열을 전달할 수 있습니다. Windows 컨테이너를 사용하면 해당 모델을 따를 수 있지만, DB컨테이너의 연결 문자열을 애플리케이션이 읽을 수 있는 컨테이너 오케스트레이터에서 제공하는 중앙 집중식 구성으로 분리하는 것이 좋습니다. 이렇게 하면 애플리케이션과 독립적으로 DB 연결 문자열을 관리하고 업데이트할 수 있습니다. DB가 변경되면(예: 클라우드로 리프트 앤 시프트) 컨테이너 이미지를 다시 빌드하지 않고도 연결 문자열을 쉽게 변경할 수 있습니다. 또한 이 방법을 사용하면 비밀 저장소에 비밀(예: DB에 연결하기 위한 사용자 이름 및 암호)을 유지할 수 있습니다.
  • 수평 자동 크기 조정: 부하가 증가하면 컴퓨팅 시스템은 동시 요청을 처리하는 동안 인식된 성능을 낮추는 경향이 있습니다. 일반적으로 성능 영향을 방지하는 두 가지 방법으로 수직 또는 수평 스케일링이 있습니다. 수직 스케일링은 기존 컴퓨팅 인스턴스에 사용할 수 있는 리소스를 늘립니다(더 많은 CPU, 메모리 등). 수평 스케일링은 요청을 지원하는 인스턴스 수를 늘립니다(더 많은 물리적 호스트, VM 또는 컨테이너). IIS와 같은 웹 계층의 경우 수평 스케일링이 수직 스케일링보다 더 효율적인 경향이 있지만, 온-프레미스 환경에서는 리소스 제한 및 부하 분산 문제가 발생할 수 있습니다. 클라우드 환경에서는 리소스를 쉽게 사용할 수 있고(추가 비용 발생) 클라우드 공급자가 일반적으로 수평 스케일링을 염두에 두고 부하 분산 메커니즘을 설계하므로 수평 스케일링이 훨씬 쉽습니다. Windows 컨테이너는 IIS에 수평 스케일링을 활용할 수 있지만, 사용 후 삭제되는 컨테이너의 특성이 중요한 역할을 합니다. 웹 애플리케이션을 지원하는 인스턴스 수를 스케일 업 또는 다운할 수 있도록 컨테이너를 동일하게 구성하고 상태 또는 데이터를 저장하지 않도록 하는 것이 중요합니다.

예약형 작업

예약된 작업은 Windows 환경에서 언제든지 프로그램, 서비스 또는 스크립트를 호출하는 데 사용됩니다. 기존 방식에서는 Windows 인스턴스가 항상 실행되고 트리거가 충족되면 작업이 실행됩니다. Windows 컨테이너도 이렇게 할 수 있으며, Azure PowerShell 통해 예약된 작업을 구성하고 관리해야 한다는 것을 제외하면 정확히 동일하게 작동합니다.

그러나 마이크로 서비스 접근 방식을 사용하면 트리거가 충족될 때까지 컨테이너를 계속 실행하지 않아도 되는 몇 가지 옵션이 있습니다.

  • Azure Function과 같은 이벤트 기반 PaaS(Platform as a Service)를 사용하여 코드를 저장하고 해당 앱에 대한 트리거를 정의합니다. Azure Functions는 트리거가 충족될 때 실행되는 Windows 컨테이너 이미지까지도 지원합니다.
  • Windows 컨테이너를 컨테이너 오케스트레이터와 함께 사용합니다. 컨테이너는 트리거가 충족되고 애플리케이션의 다른 부분에서 호출되는 경우에만 실행할 수 있습니다. 이 경우 컨테이너 오케스트레이터는 애플리케이션의 예약 및 트리거를 처리합니다.
  • 마지막으로, Windows 컨테이너를 계속 실행하여 예약된 작업을 실행합니다. 컨테이너를 계속 실행하려면 포그라운드 서비스(예: ServiceMonitor)가 필요합니다.

백그라운드 서비스

컨테이너는 일반적으로 임시 프로세스용이지만, 애플리케이션을 시작하고 계속 실행하는 포그라운드 프로세스를 만드는 경우 백그라운드 장기 실행 애플리케이션을 컨테이너화할 수 있습니다.

컨테이너에서 IIS를 실행할 때 진입점 프로세스로 사용하도록 설계된 Windows 실행 파일인 ServiceMonitor가 대표적인 예입니다. 이 서비스는 IIS용으로 개발되었지만, ServiceMonitor 도구는 다른 서비스를 모니터링하는 데 사용할 수 있는 모델을 제공하며 몇 가지 제한이 있습니다.

ServiceMonitor에 대한 자세한 내용은 Github의 설명서를 확인하세요.

.NET Framework 및 .NET

Windows 컨테이너는 .NET Framework와 .NET(이전에는 .NET Core)을 모두 지원합니다. .NET 팀은 Windows 기본 컨테이너 이미지를 기반으로 두 프레임워크에 모두 사용할 수 있는 자체적인 고유한 공식 이미지를 만듭니다. 호환성을 보장하려면 적절한 이미지를 선택해야 합니다. .NET 팀은 Server Core 기본 컨테이너 이미지 기반의 .Net Framework 이미지와 Server Core 및 Nano Server 기본 컨테이너 이미지 기반의 .NET 이미지를 제공합니다. Server Core는 Nano Server보다 큰 API 세트를 갖고 있어서 호환성이 더 우수하지만 이미지 크기도 더 큽니다. Nano Server는 API 표면이 매우 축소되었지만 이미지 크기가 훨씬 작습니다.

경우에 따라 Windows 또는 서버 기본 컨테이너 이미지 위에 고유한 .NET Framework 또는 .NET 이미지를 빌드해야 할 수도 있습니다. 애플리케이션에 프레임워크뿐 아니라 OS에도 종속된 경우 이 작업이 필요할 수 있습니다. 특정 기본 컨테이너 이미지로 애플리케이션을 테스트하여 이러한 종속성을 탐지할 수 있습니다.

예를 들어 Server Core 및 Nano Server 기본 컨테이너 이미지는 이미지 크기를 줄이기 위해 한 가지 글꼴만 사용합니다. 애플리케이션에 다른 글꼴이 필요한 경우 해당 글꼴을 설치하거나 더 큰 API 세트가 있고 모든 기본 Windows 글꼴을 포함하고 있는 Server 또는 Windows 이미지를 사용해야 합니다. 호환성의 관점에서 볼 때, 이렇게 하면 거의 모든 앱(GUI 없음과 같은 컨테이너의 특성을 따르는 한)을 컨테이너화할 수 있습니다. 대신 크기가 훨씬 커져서 성능에 영향을 미칠 수도 있다는 단점이 있습니다.

컨테이너화할 애플리케이션이 Windows 컨테이너에서 작동하는지 확인할 때 다음과 같은 권장 사항을 따르는 것이 좋습니다.

프레임워크 먼저 이 컨테이너 이미지로 테스트 첫 번째 방법이 작동하지 않으면 이 컨테이너 이미지로 대체 Base image
.NET Framework 버전 2.X 및 3.X .NET Framework 4.x .NET Framework 3.5 Windows Server Core
.NET Framework 4.x 버전 .NET Framework 4.x Server 또는 Windows 이미지를 사용하여 .NET Framework 컨테이너 이미지 빌드 Windows Server Core
.NET 6 또는 7 각각 .NET 6 또는 7 Windows 또는 Server 기본 이미지를 사용하여 .NET 컨테이너 이미지 빌드 Windows Nano Server 또는 Server Core

기타 지원 구성 요소

아래 구성 요소와 토픽은 Windows 컨테이너에서 함께 작동하거나 더욱 명확해지는 항목에 대한 추가 지침을 제공합니다.

이벤트 로깅

Windows 및 Linux는 다양한 방법을 사용하여 로그와 이벤트를 저장하고 사용자에게 표시합니다. 전통적으로 Windows는 이벤트 뷰어에서 구조화된 방식으로 볼 수 있는 EVT 형식을 사용해 왔습니다. 반면 Linux는 Docker와 같은 다른 도구가 사용하는 표준 출력(stdout)을 통해 간소화된 접근 방식을 제공해 왔습니다.

Docker에는 항상 Linux 컨테이너에서 로그를 추출하는 메커니즘이 있습니다. 기본 stdout 구성과 함께 "docker logs" 명령을 사용하면 Docker는 컨테이너를 대화형으로 열지 않고도 컨테이너에서 애플리케이션 로그를 가져옵니다. 하지만 Windows에서는 로그 모니터 도구가 시작될 때까지 동일한 기술이 작동하지 않았습니다.

로그 모니터 도구는 Windows 로그를 stdout 형식으로 표시하므로, Docker와 같은 다른 도구가 이를 표시하는 데 필요한 정보를 수집할 수 있습니다. 로그 모니터를 사용하면 다음과 같은 추가 이점이 있습니다.

  • stdout에 노출하려는 이벤트/로그 유형을 필터링할 수 있습니다. 예를 들어 "정보" 이벤트에 관심이 없는 경우 애플리케이션 로그의 "오류" 및 "경고" 메시지만 필터링할 수 있습니다.
  • 이벤트 로그, 사용자 지정 로그 파일 또는 ETW(Windows용 이벤트 추적) 중에서 선택할 수 있습니다. 이 기능은 애플리케이션이 다른 로그 원본에 쓰는 경우에 특히 유용합니다. "C:\inetpub" 폴더에 있는 IIS 로그를 예로 들 수 있습니다.
  • 로그 모니터를 사용하면 Windows 컨테이너가 Linux 컨테이너처럼 동작하므로, stdout을 찾아서 컨테이너 런타임과 상호 작용하는 도구가 예상대로 작동합니다. 예를 들어 컨테이너 런타임으로 Docker에서 ContainerD로 이동하는 경우 컨테이너 호스트에서 (예를 들어) "crictl logs"를 통해 로그를 계속 볼 수 있습니다.

Log Monitor 도구에 대한 자세한 내용은 이 블로그 게시물을 참조하세요.

Windows 컨테이너 보안

Windows 컨테이너는 물리적 머신 또는 가상 머신에서 실행되는 Windows 인스턴스와 동일한 기반으로 빌드됩니다. 컨테이너가 구현되는 방식, 특히 공유 커널 특성을 자세히 이해하면 컨테이너화된 애플리케이션을 보호하는 데 도움이 됩니다.

  • 공유 구성 요소. Windows 컨테이너는 보안을 위해 호스트의 일부 구성 요소를 공유합니다. 여기에는 Windows 방화벽, Windows Defender(바이러스 백신) 및 기타 리소스 액세스 제한이 포함됩니다. 컨테이너 호스트가 컨테이너 워크로드에 따라 필요한 조정을 수행하므로 컨테이너에서 이러한 구성 요소를 직접 구성할 필요가 없습니다. 예를 들어 컨테이너에서 웹 요청을 만들면 컨테이너 호스트는 컨테이너가 웹에 액세스할 수 있도록 방화벽을 통해 필요한 트래픽을 전달합니다.
  • 격리 모드. 앞에서 설명한 것처럼 프로세스 또는 Hyper-V 격리 모드에서 Windows 컨테이너를 배포할 수 있으며, Hyper-V가 가장 안전한 격리를 제공합니다. 프로세스 격리에서는 컨테이너가 커널, 파일 시스템 및 레지스트리를 호스트와 공유하므로 상승된(관리자) 프로세스가 컨테이너 프로세스 및 서비스와 상호 작용할 수 있습니다. 적절한 보안 모델을 확보하려면 애플리케이션에 적합한 격리 모드를 선택하는 것이 중요합니다.
  • Windows 업데이트 서비스 스택이 Windows 컨테이너에 없으므로, Windows 컨테이너는 일반 Windows 인스턴스와 같은 업데이트를 수신하지 않습니다. 대신 사용 가능한 최신 기본 컨테이너 이미지를 사용하여 Windows 컨테이너를 다시 빌드해야 합니다. 고객은 이러한 목적을 위해 DevOps 파이프라인을 활용할 수 있습니다. Microsoft는 Patch Tuesday 주기에 따라 매월 모든 공식 이미지의 기본 컨테이너 이미지를 업데이트합니다.
  • 컨테이너 사용자 계정. 기본적으로 Windows 컨테이너 내의 애플리케이션은 ContainerAdmin 사용자 계정에서 상승된 권한으로 실행됩니다. 이는 컨테이너 이미지 내에서 필요한 구성 요소를 설치하고 구성하는 데 유용합니다. 그러나 상승된 권한이 필요 없는 애플리케이션을 실행할 때에는 사용자 계정을 ContainerUser로 변경하는 것이 좋습니다. 특정 시나리오의 경우 적절한 권한으로 새 계정을 만들 수도 있습니다.
  • 이미지 및 런타임 검사. 컨테이너는 리포지토리 및 컨테이너 인스턴스의 이미지가 안전해야 합니다. 이미지 검사 및 런타임 검사에 컨테이너용 Microsoft Defender를 사용하는 것이 좋습니다. 컨테이너용 Defender는 위협 탐지를 통해 레지스트리 검사 및 런타임 보호를 사용하여 취약성을 평가할 수 있도록 Windows 컨테이너를 지원합니다.

위의 토픽에 대한 자세한 내용은 Windows 컨테이너 설명서 페이지에서 확인할 수 있습니다.

Windows 컨테이너 백업

컨테이너를 사용할 때 백업에 대해 다르게 생각해야 합니다. 앞에서 설명한 것처럼 컨테이너는 사용 후 삭제되는 특성이 있으므로 상태 또는 데이터를 저장하는 데 사용해서는 안 됩니다. 상태 및 데이터를 컨테이너 인스턴스와 분리하면 백업 문제가 컨테이너 인스턴스의 런타임 외부에 있게 되며, 필요한 모든 영구 스토리지를 계속 사용할 수 있는 새 인스턴스로 대체할 수 있습니다.

그러나 애플리케이션, 컨테이너 이미지 및 컨테이너 이미지를 빌드하는 dockerfile을 포함하여 사용자가 백업해야 하는 구성 요소가 여전히 남아 있습니다. 이러한 작업의 대부분은 프로덕션 및 개발 워크로드를 실행하는 플랫폼에서 처리됩니다. DevOps 접근 방식을 채택할 때 다음과 같이 가장 일반적인 사례를 고려해야 합니다.

  • 애플리케이션: 애플리케이션은 아마도 GitHub 또는 Azure DevOps와 같은 원본 리포지토리에 있을 것입니다. 이러한 리포지토리는 버전 제어를 제공하므로, 애플리케이션의 특정 버전으로 되돌릴 수 있습니다. 원본 리포지토리를 소유하고 있는 경우 백업 및 관리 권장 사항을 따라야 합니다.
  • 컨테이너 이미지: 프로덕션 환경의 경우 컨테이너 이미지는 ACR(Azure Container Registry)과 같은 중앙 집중식 이미지 리포지토리에 있어야 합니다. 다른 호스트에서 풀링할 수 있도록 컨테이너 이미지를 ACR에 푸시할 수 있습니다. ACR은 컨테이너 이미지의 가용성을 처리하고 백업 옵션으로 사용됩니다. 하지만 ACR은 이미지의 가용성을 처리하지만 이미지 삭제 또는 덮어쓰기를 방지하지는 않는다는 점을 염두에 두어야 합니다. 다른 로컬 또는 온-프레미스 이미지 리포지토리의 경우 기존 레지스트리 백업에 대한 공급업체의 권장 사항을 따릅니다.
  • Dockerfile: Dockerfile은 새 컨테이너 이미지를 빌드하며 일반적으로 애플리케이션 원본과 함께 저장됩니다. dockerfile이 애플리케이션에서 만들어지지 않았을 수 있으므로, 특히 컨테이너화 중인 기존 애플리케이션인 경우 dockerfile이 안전하고 백업되는 위치에 저장되도록 해야 합니다. 또한 애플리케이션이 컨테이너에서 작동하는 데 필요한 다른 자산이 백업되도록 해야 합니다. 예를 들어 Kubernetes, Docker Swarm 및 Azure ARM 템플릿에 대한 YAML 및 JSON 파일은 위와 동일한 지침을 따릅니다.

리프트 앤 시프트 프로세스 계획

애플리케이션의 컨테이너화 준비 상태를 평가한 후에는 다음과 같은 일반 지침에 따라 프로세스를 계획합니다.

  1. 필요한 Windows 운영 체제 기본 이미지(Windows Server Core, Nano Server, Windows 또는 Server 이미지)를 결정합니다.
  2. 컨테이너의 격리 모드를 프로세스 격리 또는 Hyper-V 격리 모드 중에서 선택합니다. 참고: 현재 AKS 및 Azure Stack HCI의 AKS는 프로세스 격리 컨테이너만 지원합니다. 향후 릴리스에서는 AKS 및 Azure Stack HCI의 AKS 둘 다 Hyper-V 격리 컨테이너를 지원할 예정입니다. 자세한 내용은 격리 모드를 참조하세요.
  3. 앱 호환을 위해 애플리케이션에 적합한 Windows Server 버전을 선택합니다. 컨테이너에 필요한 최소 Windows Server 버전은 Windows Server 2016이지만 Windows Server 2019 및 Windows Server 2022는 AKS 및 Azure Stack HCI의 AKS에서 지원되는 유일한 컨테이너 호스트 운영 체제입니다.
  4. 컨테이너 환경에 대한 회사의 보안 정책이 마련되어 있는지 확인합니다. 여기에는 레지스트리 검사 및 위협 탐지와 같은 컨테이너 관련 요구 사항에 맞게 조정하는 것이 포함됩니다.
  5. 부하 분산 요구 사항을 고려합니다. 컨테이너 자체는 이동하지 않습니다. 대신 오케스트레이터를 사용하여 클러스터 노드에서 컨테이너를 자동으로 시작 또는 중지하거나, 자동 수평 스케일링을 사용하여 부하 및 가용성 변경을 관리할 수 있습니다.
  6. 오케스트레이션 요구 사항을 고려합니다. 컨테이너화된 애플리케이션은 Kubernetes, AKS 또는 Azure Stack HCI의 AKS와 같은 도구에서 사용할 수 있는 자동화된 관리가 필요할 것입니다. 여러 도구 중에 적절한 도구를 선택하는 방법에 대한 전체 설명과 가이드는 Windows 컨테이너 오케스트레이션 개요를 참조하세요.
  7. 앱을 컨테이너화합니다.
  8. 이미지 리포지토리에 앱을 푸시합니다. 이렇게 하면 컨테이너 호스트가 개발, 테스트 및 프로덕션을 비롯한 모든 환경에서 이미지를 다운로드할 수 있습니다.

Azure Migrate는 기존 Windows 애플리케이션을 검색, 평가 및 마이그레이션하여 Azure Kubernetes Service 위한 단계별 프로세스를 제공할 수 있습니다. 자세한 내용은 Azure Migrate 설명서 페이지를 검사.