다음을 통해 공유

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

  • 아티클

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

Windows 컨테이너는 기존 또는 레거시 애플리케이션을 현대화하기 위한 훌륭한 메커니즘을 제공합니다. "컨테이너로 리프트 앤 시프트"라고 하는 이 방법을 들을 수 있지만 리프트 앤 시프트 은유는 워크로드를 실제 컴퓨터에서 가상 머신으로 이동하는 것에서 비롯되며 워크로드를 클라우드로 이동하는 것을 참조할 때 사용됩니다. 현재 이 용어는 VM(가상 머신) 마이그레이션에 더 적합하게 적용됩니다. 그러나 컨테이너는 VM이 아니며 VM으로 생각하면 애플리케이션이 컨테이너화되는 방법 또는 컨테이너화할 수 있는지 여부에 대한 혼동을 초래할 수 있습니다.

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

소개

Windows 컨테이너란 무엇이며 그렇지 않은 항목

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

Windows 컨테이너는 컨테이너 기술의 특정 구현입니다. Windows OS에서 격리된 가상화된 운영 체제의 인스턴스를 제공합니다. 그러나 컨테이너와 호스트 간의 총 상호 종속성은 불가능합니다. Windows 컨테이너는 Windows OS를 사용하여 리소스 및 함수에 대한 수요를 조정해야 합니다. 이것이 중요한 이유는 무엇인가요? Windows 컨테이너는 전체 가상화된 서버가 아니므로 애플리케이션으로 수행할 수 있는 작업 중 일부는 가상화된 OS로만 수행할 수 없습니다.

컨테이너 및 가상 머신이 항목에 대해 자세히 알아보세요. 그러나 컨테이너와 VM 구분을 기억하는 데 도움이 되는 몇 가지 좋은 점은 다음과 같습니다.

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

컨테이너 기술은 Linux에서 시작했으며 Docker가 표준으로 부상했습니다. Microsoft는 Docker와 긴밀히 협력하여 컨테이너 기능이 Windows에서 합리적으로 가능한 한 동일한지 확인했습니다. 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 이전 버전은 전혀 지원되지 않지만 이후 버전에 필요한 컨테이너 이미지는 아래를 참조하세요.
다른 타사 프레임워크를 사용하는 앱 Microsoft는 Windows 컨테이너에서 타사 프레임워크의 사용을 구체적으로 인증하거나 지원하지 않습니다. 특정 프레임워크 또는 앱의 공급업체에 Windows 컨테이너에 대한 지원 정책을 확인합니다. 자세한 내용은 아래를 참조하세요.

이러한 각 제한 사항을 차례로 살펴보겠습니다.

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

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

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

앱에 GUI API가 필요한 경우 다른 문제입니다. API는 해당 API에서 제공하는 GUI가 지원되지 않더라도 지원됩니다. Nano Server x Server Core x Server에 대한 더 자세한 설명은 항목, '어떤 기본 이미지가 적합한가요?'에서 확인할 수 있습니다.

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

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

그러나 좋은 대안은 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는 Windows 2000 Server를 따라 20여 년 전에 릴리스되었습니다. 각 디바이스 또는 사용자가 데이터베이스에 저장된 개체로 표시되는 메커니즘을 사용합니다. 이 관계는 긴밀하게 결합되며 실제 사용자 또는 디바이스가 더 이상 재생되지 않더라도 개체가 데이터베이스에 유지됩니다. Active Directory에 대한 이러한 접근 방식은 수명이 짧거나 해제될 때 삭제될 것으로 예상되는 컨테이너의 임시 특성과 직접적으로 모순됩니다. Active Directory와 이 일대일 관계를 유지하는 것은 이러한 시나리오에 적합하지 않습니다.

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

Active Directory에 종속된 Windows 컨테이너에서 실행되는 애플리케이션의 경우 gMSA(그룹 관리 서비스 계정)를 사용합니다. 이 계정은 자세히 설명합니다.

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

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

타사(비-마이크로소프트) 프레임워크를 사용하는 앱

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

타사 프레임워크 또는 소프트웨어의 경우 Windows 컨테이너를 제공하는 공급업체와 함께 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에는 여러 배포 옵션이 포함되어 있습니다. 프라이빗 큐와 공용 큐, 트랜잭션 여부 및 인증 유형의 요소는 MSMQ가 원래 지원하도록 디자인된 시나리오의 행렬을 형성합니다. 이러한 모든 항목을 Windows 컨테이너로 쉽게 이동할 수 있는 것은 아닙니다. 다음 표에서는 지원되는 시나리오를 나열합니다.

범위 거래? 큐 위치 인증 유형 보내고 받으시겠습니까?
민간의 예 동일한 컨테이너(단일 컨테이너) 익명의 예
민간의 예 영구 볼륨 익명의 예
비공개 예 도메인 컨트롤러 익명의 예
비공개 예 단일 호스트(두 개의 컨테이너) 익명의 예
공공의 아니요 두 명의 진행자 익명의 예
공공의 예 두 개의 호스트 익명의 예

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는 메시지 큐 및 게시-구독 토픽(네임스페이스)이 있는 완전 관리형 엔터프라이즈 메시지 브로커입니다. 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 이름을 사용하여 서로를 확인할 수 있어야 합니다. 이 문제를 해결하는 가장 좋은 방법은 컨테이너의 이름과 IP를 다른 호스트 파일에 추가하는 것입니다.
  • 두 컨테이너의 msdtc에 대한 uuid는 고유해야 합니다. 컨테이너의 PowerShell에서 "Get-Dtc"를 실행하여 uuid를 찾을 수 있습니다. 고유하지 않은 경우 한 가지 해결 방법은 컨테이너 중 하나에 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 컨테이너를 계속 실행하여 예약된 작업을 실행합니다. 컨테이너를 계속 실행하려면 포그라운드 서비스(예: 서비스 모니터)가 필요합니다.

백그라운드 서비스

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

이 예제의 좋은 예는 컨테이너에서 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 서버보다 더 큰 API 집합이 있으므로 호환성이 향상되지만 이미지 크기도 더 큽니다. Nano 서버에는 API 표면이 크게 감소하지만 이미지 크기는 훨씬 작습니다.

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

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

컨테이너화할 애플리케이션이 Windows 컨테이너에서 작동하는지 확인할 때 Microsoft는 다음을 권장합니다.

이 프레임워크의 경우 먼저 이 컨테이너 이미지로 테스트 첫 번째가 작동하지 않을 경우 이 컨테이너 이미지로 대체하십시오. 기본 이미지
.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 서버 또는 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 로그"를 통해 컨테이너 호스트에서 로그가 계속 표시됩니다.

이 블로그 게시물 에서 로그 모니터 도구에 대해 자세히 알아볼 수 있습니다.

Windows 컨테이너 보안

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

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

위의 항목에 대한 자세한 내용은 Windows 컨테이너 설명서 페이지.

Windows 컨테이너 백업

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

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

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

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

컨테이너화에 대한 애플리케이션의 준비 상태를 평가한 후 다음 일반 지침을 사용하여 프로세스를 계획합니다.

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

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