Używanie kontenerów systemu Windows do "konteneryzowania" istniejących aplikacji

Dotyczy: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Kontenery systemu Windows zapewniają doskonały mechanizm modernizacji tradycyjnych lub starszych aplikacji. Chociaż można usłyszeć to podejście nazywane "lift and shift to containers", metafora lift-and-shift pochodzi z przenoszenia obciążeń z fizycznych na maszyny wirtualne i jest używana podczas odwoływania się do przenoszenia obciążeń do chmury. Obecnie ten termin jest bardziej odpowiedni do migrowania maszyn wirtualnych. Kontenery nie są jednak maszynami wirtualnymi i myślenie o nich jak o maszynach wirtualnych może prowadzić do nieporozumień na temat tego, jak aplikacja jest konteneryzowana, czy w ogóle może, lub powinna być konteneryzowana.

Ten temat zawiera praktyczne wskazówki dotyczące przenoszenia tradycyjnych aplikacji do kontenerów systemu Windows. Ma to na celu ułatwienie określania priorytetów, które aplikacje powinny być konteneryzowane, wyjaśniając specjalne zagadnienia z góry.

Wprowadzenie

Czym są kontenery systemu Windows i czym nie są

Ogólny termin kontener odnosi się do technologii, która wirtualizuje system operacyjny. Ta wirtualizacja zapewnia poziom izolacji od systemu operacyjnego samego serwera/hosta, co z kolei zapewnia większą elastyczność dla deweloperów aplikacji i zespołów operacyjnych.

Kontenery systemu Windows to konkretna implementacja technologii kontenerów. Zapewniają one instancje zwirtualizowanych systemów operacyjnych, które są odizolowane od systemu operacyjnego Windows. Jednak całkowita współzależność między kontenerem a hostem jest niemożliwa: kontener systemu Windows musi koordynować zapotrzebowanie na zasoby i funkcje przy użyciu systemu operacyjnego Windows. Dlaczego jest to ważne? Ponieważ kontener systemu Windows nie jest pełnym zwirtualizowanym serwerem, niektóre zadania, które można by chcieć wykonać z aplikacją, nie mogą być zrealizowane tylko na podstawie zwirtualizowanego systemu operacyjnego.

Więcej informacji na ten temat można znaleźć w sekcji Kontenery vs. maszyny wirtualne. Kilka dobrych punktów, które pomagają zapamiętać różnicę między kontenerem a maszyną wirtualną, to:

• Kontenery nie są rozwiązaniem równoważnym z wirtualizacją aplikacji klasycznych. Obsługują one tylko aplikacje po stronie serwera, które nie wymagają sesji interakcyjnej. Ponieważ są one uruchamiane na wyspecjalizowanych obrazach kontenerów, obsługują tylko te aplikacje, które nie potrzebują frontonu graficznego.
• Kontenery są efemeryczne z natury. Oznacza to, że domyślnie nie ma mechanizmu zapisywania stanu instancji kontenera. Jeśli wystąpienie zakończy się niepowodzeniem, zostanie zastąpione innym wystąpieniem.

Technologia kontenerów rozpoczęła się w systemie Linux, a platforma Docker pojawiała się jako standard. Firma Microsoft ściśle współpracowała z platformą Docker, aby upewnić się, że funkcjonalność kontenera jest taka sama w systemie Windows, jak to możliwe. Nieodłączne różnice między systemami Linux i Windows mogą pojawiać się w sposób, który wydaje się być ograniczeniami kontenerów systemu Windows, gdy w rzeczywistości są to tylko różnice w systemie Linux i Windows. Z drugiej strony kontenery systemu Windows oferują wyjątkowe implementacje, takie jak izolacja Hyper-V, o czym będzie mowa później. Ten temat pomaga zrozumieć te różnice i sposób ich uwzględnienia.

Korzyści wynikające z używania kontenerów

Podobnie jak uruchamianie wielu maszyn wirtualnych na jednym hoście fizycznym, można uruchomić wiele kontenerów na jednym hoście fizycznym lub wirtualnym. Jednak w przeciwieństwie do maszyn wirtualnych nie trzeba zarządzać systemem operacyjnym dla kontenera, co zapewnia elastyczność skupienia się na tworzeniu aplikacji i podstawowej infrastrukturze. Oznacza to również, że można odizolować aplikację tak, aby nie miała to wpływu na inne procesy obsługiwane przez system operacyjny.

Kontenery zapewniają uproszczoną metodę tworzenia i dynamicznego zatrzymywania zasobów wymaganych dla działającej aplikacji. Chociaż istnieje możliwość tworzenia i wdrażania maszyn wirtualnych w miarę zwiększania zapotrzebowania na aplikacje, szybsze jest używanie kontenerów do skalowania w górę. Dzięki kontenerom można również szybko uruchomić ponownie w przypadku awarii lub przerwy w sprzęcie. Kontenery umożliwiają pobieranie dowolnej aplikacji z programowania do środowiska produkcyjnego z niewielką zmianami lub bez zmian w kodzie, ponieważ "zawierają" zależności aplikacji, tak aby działały w różnych środowiskach. Możliwość konteneryzowania istniejącej aplikacji z minimalnymi zmianami kodu ze względu na integrację platformy Docker z narzędziami deweloperskich firmy Microsoft jest również zaawansowanym czynnikiem w zakresie tworzenia i konserwacji aplikacji.

Na koniec jedną z najważniejszych zalet korzystania z kontenerów jest elastyczność uzyskana na potrzeby tworzenia aplikacji, ponieważ możesz mieć różne wersje aplikacji działającej na tym samym hoście bez starcia zasobów.

Pełną listę korzyści dotyczących używania kontenerów dla istniejących aplikacji można znaleźć na stronie dokumentacji platformy Microsoft .NET.

Ważna koncepcja poziomu izolacji

Kontenery systemu Windows zapewniają izolację od systemu operacyjnego Windows, izolację, która jest korzystna podczas kompilowania, testowania i promowania aplikacji do środowiska produkcyjnego. Jednak sposób osiągnięcia izolacji jest ważny, aby zrozumieć, kiedy myślisz o konteneryzowaniu aplikacji.

Kontenery systemu Windows oferują dwa różne tryby izolacji środowiska uruchomieniowego: proces i Hyper-V. Kontenery w obu trybach są tworzone i zarządzane identycznie i działają identycznie. Więc jakie są różnice i dlaczego powinno cię to obchodzić?

W izolacji procesówwiele kontenerów działa równocześnie na jednym hoście z izolacją zapewnianą przez przestrzeń nazw (namespace), kontrolę zasobów i inne cechy. Kontenery w trybie izolacji procesów dzielą to samo jądro z hostem i między sobą. Jest to mniej więcej takie samo, jak w przypadku uruchamiania kontenerów systemu Linux.

W Hyper-V izolacjiwiele kontenerów działa również współbieżnie na jednym hoście, ale te działają wewnątrz wysoce zoptymalizowanych maszyn wirtualnych, z których każdy skutecznie otrzymuje własne jądro. Obecność tej maszyny wirtualnej – w rzeczywistości maszyny wirtualnej typu "utility" – zapewnia izolację sprzętową pomiędzy każdym kontenerem a hostem kontenera.

W pewnym sensie tryb izolacji Hyper-V jest niemal jak hybryda maszyny wirtualnej i kontenera, zapewniając dodatkową warstwę zabezpieczeń, która jest szczególnie przydatna, jeśli aplikacja wymaga wielodostępności. Jednak możliwe kompromisy dotyczące używania trybu izolacji Hyper-V obejmują:

• Dłuższy czas uruchamiania kontenera i prawdopodobny wpływ na ogólną wydajność aplikacji.
• Nie wszystkie narzędzia działają natywnie z izolacją Hyper-V.
• W tej chwili ani usługa Azure Kubernetes Service (AKS) ani usługa AKS w usłudze Azure Stack HCI nie obsługują izolacji Hyper-V.

Więcej informacji o tym, jak dwa tryby izolacji są implementowane w temacie Tryby izolacji. Podczas pierwszego konteneryzowania aplikacji należy wybrać między dwoma trybami. Na szczęście bardzo łatwo jest zmienić tryb z jednego na inny później, ponieważ nie wymaga żadnych zmian w aplikacji ani w kontenerze. Należy jednak pamiętać, że podczas konteneryzowania aplikacji wybór między dwoma trybami jest jedną z pierwszych czynności, które należy wykonać.

Orkiestracja kontenerów

Możliwość uruchamiania wielu kontenerów na jednym lub wielu hostach bez obaw dotyczących zarządzania systemem operacyjnym zapewnia dużą elastyczność, co ułatwia przejście do architektury opartej na mikrousługach. Jednym z kompromisów w tej elastyczności jest jednak to, że środowisko oparte na kontenerach i mikrousługach może szybko rozrastać się do wielu ruchomych części — zbyt wielu, aby można je było śledzić. Na szczęście zarządzanie równoważeniem obciążenia, wysoką dostępnością, planowaniem kontenerów, zarządzaniem zasobami i nie tylko jest rolą orkiestratora kontenerów.

Orkiestratorzy są prawdopodobnie błędnie nazwani; bardziej przypominają dyrygentów orkiestry, ponieważ koordynują aktywność wielu kontenerów, aby muzyka nie przestawała grać. W sensie obsługują planowanie i alokację zasobów dla kontenerów w sposób podobny do działania systemu operacyjnego. W miarę przechodzenia do konteneryzacji aplikacji, należy wybrać spośród orchestratorów obsługujących kontenery systemu Windows. Niektóre z najczęstszych to Kubernetes i Docker Swarm.

Czego nie można przenieść do kontenerów systemu Windows

Jeśli rozważysz, czy aplikacja może być konteneryzowana, czy nie, prawdopodobnie najłatwiej jest rozpocząć od listy czynników, które całkowicie wykluczają kontenery systemu Windows jako opcję.

W poniższej tabeli podsumowano typy aplikacji, których nie można przenieść do kontenerów systemu Windows, i dlaczego nie. Przyczyny są bardziej szczegółowo wyjaśnione w podsekcjach po tabeli. Zrozumienie przyczyn tych ograniczeń może dać jaśniejszy obraz tego, czym naprawdę są kontenery, w tym w jaki sposób różnią się od maszyn wirtualnych. Pomoże to z kolei lepiej ocenić możliwości kontenerów systemu Windows, których można używać z istniejącymi aplikacjami, które można konteneryzować.

Uwaga: Poniższa lista nie jest kompletną listą. Zamiast tego jest to kompilacja aplikacji, które firma Microsoft widziała, że klienci próbują konteneryzować.

Aplikacje/funkcje nie są obsługiwane	Dlaczego to nie jest obsługiwane?	Czy możesz to obejść?
Aplikacje wymagające pulpitu	Kontenery nie obsługują graficznego interfejsu użytkownika (GUI)	Jeśli aplikacja wymaga tylko graficznego interfejsu użytkownika do zainstalowania, zmiana go na dyskretną instalację może być rozwiązaniem
Aplikacje korzystające z protokołu RDP (Remote Desktop Protocol)	Protokół RDP jest przeznaczony dla sesji interakcyjnych, więc zasada powyżej ma zastosowanie również w tym miejscu	Możesz użyć programu Windows Admin Center (WAC) lub zdalnego programu PowerShell jako alternatywy dla zdalnego zarządzania
Aplikacje stanowe	Kontenery są efemeryczne	Tak, niektóre aplikacje mogą wymagać minimalnej zmiany, więc nie przechowują danych ani stanu wewnątrz kontenera
Aplikacje bazy danych	Kontenery są efemeryczne	Tak, niektóre aplikacje mogą wymagać minimalnej zmiany, więc nie przechowują danych ani stanu wewnątrz kontenera
Active Directory	Projekt i cel usługi Active Directory uniemożliwiają uruchomienie w kontenerze	Nie. Jednak aplikacje zależne od usługi Active Directory mogą używać kont usług zarządzanych przez grupę (gMSA). Więcej informacji o gMSA znajduje się poniżej
Starsze wersje systemu Windows Server	Obsługiwany jest tylko system Windows Server 2016 lub nowszy	Nie. Jednak zgodność aplikacji może być opcją — większość aplikacji z systemem Windows Server 2008/R2 i starszych działa w nowszych wersjach systemu Windows Server
Aplikacje korzystające z programu .NET Framework w wersji 2.0 lub starszej	Określone obrazy kontenerów są wymagane do obsługi programu .NET Framework, a tylko nowsze wersje są obsługiwane	Wersje starsze niż 2.0 nie są w ogóle obsługiwane, ale zapoznaj się z poniższymi obrazami kontenerów wymaganymi w przypadku nowszych wersji
Aplikacje korzystające z innych platform innych firm	Firma Microsoft nie certyfikuje ani nie obsługuje korzystania z frameworków innych niż te firmy Microsoft w kontenerach systemu Windows.	Zapoznaj się z dostawcą określonej platformy lub aplikacji, aby uzyskać zasady pomocy technicznej dla kontenerów systemu Windows. Zobacz poniżej, aby uzyskać więcej informacji

Rozważmy z kolei każde z tych ograniczeń.

Aplikacje wymagające pulpitu

Kontenery są idealne dla funkcji efemerycznych wywoływanych z innych aplikacji, w tym tych z interakcjami użytkowników. Nie można ich jednak używać w przypadku aplikacji, które same w sobie mają interfejsy użytkownika. Jest to prawdą, nawet jeśli sama aplikacja nie ma graficznego interfejsu użytkownika, ale ma instalatora, który opiera się na graficznym interfejsie użytkownika. Ogólnie rzecz biorąc, Instalator Windows może być wywoływany przy użyciu programu PowerShell, ale jeśli aplikacja wymaga instalacji za pomocą graficznego interfejsu użytkownika, to wymaganie eliminuje go jako kandydata do konteneryzacji.

Nie jest to problem ze sposobem implementacji kontenerów systemu Windows, ale raczej podstawową koncepcją działania kontenerów.

Jest to inna kwestia, jeśli aplikacja potrzebuje API graficznego interfejsu użytkownika. Interfejsy API są obsługiwane, mimo że interfejs GUI obsługiwany przez te interfejsy API nie jest. Jest to bardziej szczegółowo opisane w temacie Nano Server x Server Core x Server - Który obraz podstawowy jest odpowiedni dla Ciebie?

Aplikacje korzystające z protokołu RDP

Ponieważ cały cel protokołu RDP (Remote Desktop Protocol) polega na ustanowieniu interaktywnej sesji wizualnej, właśnie opisane ograniczenie graficznego interfejsu użytkownika ma zastosowanie. Nie można konteneryzować aplikacji korzystającej z protokołu RDP as-is.

Jednak dobrą alternatywą jest zdalne zarządzanie, takie jak Windows Admin Center. Centrum administracyjne systemu Windows umożliwia zarządzanie hostami kontenerów systemu Windows i samymi kontenerami bez konieczności korzystania z protokołu RDP. Możesz również otworzyć zdalną sesję programu PowerShell na hoście i/lub kontenerach, aby nimi zarządzać.

Aplikacje stanowe

Aplikacje, które muszą zachować dane stanu, mogą być konteneryzowane tylko wtedy, gdy odizolowasz dane wymagane od jednej sesji do następnej i zapiszesz je w magazynie trwałym. Może to wymagać pewnego "przeprojektowania", które mogą być trywialne lub nie, ale kontynuacja tego wyeliminuje tę barierę dla konteneryzacji.

Przykładem stanu jest aplikacja internetowa, która przechowuje obrazy lub pliki muzyczne do folderu lokalnego. W tradycyjnym środowisku systemu Windows plik jest zapisywany na dysku w momencie zakończenia operacji zapisu, więc jeśli wystąpienie (maszyna wirtualna w tym przypadku) zakończy się niepowodzeniem, po prostu przywrócisz go i plik będzie nadal dostępny. Natomiast jeśli wystąpienie kontenera wykonujące operację zapisu zakończy się niepowodzeniem, nowe wystąpienie kontenera nie będzie zawierać tego pliku. Z tego powodu należy rozważyć użycie trwałej pamięci masowej, aby wszystkie wystąpienia kontenerów mogły przechowywać dane stanu lub pliki w scentralizowanej lokalizacji. Ten rodzaj przearanżowania nie wymaga zmiany kodu aplikacji, a jedynie rodzaju pamięci używanej przez instancję systemu Windows. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją kontenera systemu Windows dotyczącą magazynu.

Jednak spowoduje to wprowadzenie innego powiązanego tematu...

Aplikacje bazy danych

Ogólnie rzecz biorąc, aplikacje bazy danych nie są doskonałymi kandydatami do konteneryzacji. Chociaż można uruchomić bazę danych wewnątrz kontenera, konteneryzowanie istniejącej bazy danych zwykle nie jest idealne, z dwóch powodów.

Po pierwsze, wydajność wymagana dla bazy danych może wymagać całych zasobów sprzętowych dostępnych dla hosta — co powoduje dewaluację korzyści z konsolidacji. Po drugie, wiele wystąpień pojedynczej warstwy bazy danych wymaga koordynacji operacji zapisu. Orkiestracja kontenerów może rozwiązać ten problem, ale przy istniejących bazach danych orkiestracja może stanowić dodatkowe obciążenie. Większość baz danych, takich jak microsoft SQL Server, ma wbudowany mechanizm równoważenia obciążenia i wysokiej dostępności.

Role infrastruktury w systemie Windows Server

Role infrastruktury systemu Windows Server obsługują przede wszystkim funkcje bliżej systemu operacyjnego (na przykład usługi AD, DHCP i serwera plików). W związku z tym nie są one dostępne dla uruchomionych kontenerów. W związku z tym aplikacje, które potrzebują tych ról, zawsze będą trudne do konteneryzowania.

Istnieją szare obszary. Na przykład niektóre funkcje, takie jak DNS, mogą działać w kontenerach systemu Windows, mimo że nie są one naprawdę przeznaczone do użycia w kontenerach. Inne role infrastruktury są po prostu usuwane z obrazu kontenera podstawowego i nie można ich zainstalować, takich jak Active Directory, DHCP i inne.

Active Directory (AD)

Usługa Active Directory została wydana ponad dwadzieścia lat temu w systemie Windows 2000 Server. Używa on mechanizmu, w którym każde urządzenie lub użytkownik jest reprezentowane przez obiekt przechowywany w bazie danych. Ta relacja jest ściśle połączona, a obiekty są przechowywane w bazie danych, nawet jeśli rzeczywisty użytkownik lub urządzenie nie jest już w grze. Takie podejście do Active Directory jest bezpośrednio sprzeczne z efemerycznym charakterem kontenerów, od których oczekuje się, że będą krótkotrwałe lub usuwane po wyłączeniu. Utrzymywanie tej relacji jeden do jednego z usługą Active Directory nie jest idealne w przypadku tych scenariuszy.

Z tego powodu kontenery systemu Windows nie mogą być przyłączone do domeny. W związku z tym nie można uruchamiać usług Active Directory Domain Services jako roli infrastruktury w kontenerach systemu Windows. Moduł programu PowerShell można uruchomić do zdalnego zarządzania kontrolerami domeny wewnątrz kontenera systemu Windows.

W przypadku aplikacji działających w kontenerach systemu Windows, które są zależne od usługi Active Directory, użyj kont usług zarządzanych przez grupę (gMSA), które zostaną dokładniej wyjaśnione.

Aplikacje korzystające z programu .NET Framework w wersji 2.0 lub starszej

Jeśli aplikacja wymaga platformy .NET, możliwość konteneryzowania zależy całkowicie od używanej wersji programu .NET Framework. Żadna wersja przed programem .NET Framework 2.0 nie jest w ogóle obsługiwana; wyższe wersje wymagają użycia określonych obrazów zgodnie z opisem w dalszej części.

Aplikacje korzystające ze struktur innych firm (innych niż Microsoft)

Ogólnie rzecz biorąc, firma Microsoft nie może certyfikować struktur lub aplikacji innych firm ani obsługiwać ich działających w kontenerach systemu Windows — lub maszynach fizycznych i wirtualnych. Firma Microsoft wykonuje jednak własne wewnętrzne testy pod kątem użyteczności wielu platform i narzędzi innych firm, w tym Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat i wiele innych.

W przypadku dowolnej struktury lub oprogramowania innej firmy zweryfikuj jego obsługę w kontenerach systemu Windows z dostawcą, który go dostarcza.

Idealni kandydaci do konteneryzacji

Teraz, gdy rozważaliśmy twarde ograniczenia dotyczące konteneryzowania aplikacji, łatwiej jest zobaczyć, jakie typy aplikacji bardziej łatwo nadają się do kontenerów systemu Windows. Idealni kandydaci dla kontenerów systemu Windows oraz wszelkie szczególne rozważania dotyczące ich konteneryzacji znajdują się w poniższej tabeli.

Typ aplikacji	Dlaczego są to dobrzy kandydaci	Uwagi specjalne
Aplikacje konsolowe	Bez ograniczeń graficznego interfejsu użytkownika aplikacje konsolowe są idealnymi kandydatami do kontenerów.	Użyj odpowiedniego obrazu kontenera podstawowego w zależności od potrzeb aplikacji.
Usługi systemu Windows	Ponieważ są to procesy w tle, które nie wymagają bezpośredniej interakcji z użytkownikiem	Użyj odpowiedniego obrazu kontenera podstawowego w zależności od potrzeb aplikacji. Aby utrzymać uruchomiony dowolny konteneryzowany proces w tle, należy utworzyć proces pierwszego planu. Zobacz sekcję dotyczącą usług w tle poniżej.
Usługi Windows Communication Foundation (WCF)	Ponieważ są to aplikacje zorientowane na usługi, które są również uruchamiane w tle	Użyj odpowiedniego obrazu kontenera podstawowego w zależności od potrzeb aplikacji. Może być konieczne utworzenie procesu pierwszego planu, aby zachować uruchomiony konteneryzowany proces w tle. Zobacz sekcję dotyczącą usług w tle poniżej.
Aplikacje internetowe	Aplikacje internetowe to w istocie usługi w tle nasłuchujące na określonym porcie i dlatego doskonale nadają się do konteneryzacji, gdyż wykorzystują skalowalność, jaką oferują kontenery.	Użyj odpowiedniego obrazu kontenera podstawowego w zależności od potrzeb aplikacji.

Uwaga: nawet te idealne kandydaty do konteneryzacji mogą polegać na podstawowych funkcjach i składnikach systemu Windows, które muszą być obsługiwane inaczej w kontenerach systemu Windows. Następna sekcja, która zawiera więcej szczegółowych informacji na temat takich praktycznych zagadnień, lepiej przygotuje Cię do korzystania z funkcji kontenerów systemu Windows.

Praktyczne zagadnienia dotyczące aplikacji, które mogą być konteneryzowane

Projekty renowacji aplikacji zwykle uwzględniają, czy konkretna aplikacja może być konteneryzowana z perspektywy funkcji biznesowej aplikacji. Jednak funkcjonalność biznesowa nie jest czynnikiem, który określa, czy jest technicznie możliwy. Co jest ważne, to architektura aplikacji, tj. składniki techniczne, na których polega. W związku z tym nie ma łatwej odpowiedzi na pytanie takie jak "Czy mogę konteneryzować moją aplikację HR?", ponieważ nie jest to, co robi aplikacja, to jak (i jakie składniki/usługi systemu Windows używa), które robią różnicę.

Jest to ważne rozróżnienie, ponieważ jeśli aplikacja nie została skompilowana przy użyciu architektury mikrousług, na początek może być trudniejsza do konteneryzowania. Podczas jego konteneryzowania niektóre funkcje mogą wymagać specjalnej obsługi. Niektóre mogą być spowodowane użyciem podstawowych składników i struktur systemu Windows, które nie są obsługiwane w kontenerach systemu Windows. Inne, takie jak rejestrowanie zdarzeń i monitorowanie, są spowodowane nieodłącznymi różnicami między systemami Linux i Windows, które stają się widoczne tylko wtedy, gdy konteneryzujesz aplikację. Jednak inne, takie jak zaplanowane zadania i usługi w tle, muszą być zrozumiałe z perspektywy, że kontener nie jest maszyną wirtualną, ale jest efemeryczny, a zatem wymaga specjalnej obsługi.

W poniższej tabeli przedstawiono krótkie podsumowanie składników/funkcji aplikacji, które wymagają szczególnej uwagi podczas myślenia o konteneryzowaniu. Poniższe podsekcje przedstawiają więcej szczegółów, w tym przykłady ilustrujące techniki obsługi każdego scenariusza. Poniższa lista obejmuje scenariusze obsługiwane w kontenerach systemu Windows, jednak te scenariusze nadal muszą uwzględniać wskazówki z poprzedniego rozdziału. Na przykład, gdy usługi w tle są obsługiwane, uruchamianie usługi w tle na platformie .NET Framework 1.1 nie jest obsługiwane.

Funkcja/składnik systemu Windows wymagający specjalnej obsługi	Powód
Microsoft Message Queuing (MSMQ)	Usługa MSMQ powstała na długo przed kontenerami, a nie wszystkie jej modele wdrażania kolejek komunikatów są zgodne z architekturą kontenera.
Koordynator transakcji rozproszonych firmy Microsoft (MSDTC)	Rozpoznawanie nazw między MSDTC a kontenerem wymaga szczególnej uwagi.
IIS	IIS działa tak samo jak na maszynie wirtualnej, ale istnieją ważne aspekty, które trzeba wziąć pod uwagę przy uruchamianiu go w środowisku kontenera, takie jak zarządzanie certyfikatami, parametry połączeń do baz danych i wiele innych.
Zaplanowane zadania	Kontenery systemu Windows mogą uruchamiać zaplanowane zadania, podobnie jak każde wystąpienie systemu Windows. Jednak może być konieczne uruchomienie zadania w trybie pierwszoplanowym, aby utrzymać uruchomione wystąpienie kontenera. W zależności od aplikacji warto rozważyć podejście oparte na zdarzeniach.
Usługi w tle	Ponieważ kontenery są uruchamiane jako procesy efemeryczne, potrzebna będzie dodatkowa obsługa, aby kontener działał.
.NET Framework i .NET (dawniej .Net Core)	Upewnij się, że używasz odpowiedniego obrazu, aby zapewnić zgodność, jak wyjaśniono w poniższej podsekcji.

Inne składniki pomocnicze

Składnik wymagający specjalnej obsługi	Powód	Alternatywne podejście
Rejestrowanie/monitorowanie zdarzeń	Ponieważ sposób zapisywania zdarzeń i dzienników systemu Windows jest z natury inny niż stdout systemu Linux	Użyj nowego narzędzia Monitor dzienników, aby znormalizować dane i połączyć je zarówno z systemów Linux, jak i Windows.
Zabezpieczenia kontenerów systemu Windows	Chociaż wiele rozwiązań w zakresie zabezpieczeń pozostaje takie same, kontenery wymagają dodatkowych środków zabezpieczeń.	Zastosuj specjalnie utworzone narzędzie do skanowania rejestru i obrazów — więcej szczegółów można znaleźć później.
Tworzenie kopii zapasowych kontenerów systemu Windows	Kontenery nie powinny mieć w nim danych ani stanu	Utwórz kopię zapasową dowolnego magazynu trwałego używanego przez kontenery, a także obrazy kontenerów.

Składniki/funkcje systemu Windows

Teraz przyjrzyjmy się szczegółom aplikacji i składników, które mogą być konteneryzowane, ale wymagają dodatkowej obsługi.

MSMQ

Jeśli aplikacja jest zależna od msMQ, czy można ją konteneryzować, zależy od scenariusza wdrażania MSMQ. Usługa MSMQ zawiera wiele opcji wdrażania. Czynniki takie jak prywatne i publiczne kolejki, czy są transakcyjne, oraz typ uwierzytelniania tworzą macierz scenariuszy, które MSMQ pierwotnie zaprojektowano do obsługi. Nie wszystkie z nich można łatwo przenieść do kontenerów systemu Windows. W poniższej tabeli wymieniono obsługiwane scenariusze:

Zakres	Transakcyjne?	Lokalizacja kolejki	Typ uwierzytelniania	Wysyłaj i odbieraj?
Prywatny	Tak	Ten sam kontener (pojedynczy kontener)	Anonimowy	Tak
Prywatny	Tak	Wolumin trwały	Anonimowy	Tak
Prywatny	Tak	Kontroler domeny	Anonimowy	Tak
Prywatny	Tak	Pojedynczy host (dwa kontenery)	Anonimowy	Tak
Publiczny	Nie	Dwa gospodarze	Anonimowy	Tak
Publiczny	Tak	Dwa hosty	Anonimowy	Tak

Kilka uwag dotyczących tych obsługiwanych scenariuszy, które zostały zweryfikowane przez wewnętrzne zespoły programistyczne firmy Microsoft:

• Tryb izolacji: zarówno tryb przetwarzania, jak i tryb Hyper-V działają w izolacji w ramach scenariuszy wymienionych powyżej.
• Minimalny system operacyjny i obraz kontenera: Minimalna wersja systemu operacyjnego zalecana do używania z programem MSMQ to Windows Server 2019.
• Woluminy trwałe: Powyższe scenariusze zostały zweryfikowane przy uruchomieniu MSMQ w Azure Kubernetes Service (AKS) z użyciem Azure Files na potrzeby trwałego magazynu.

Po zestawieniu tych rozważań z powyższą tabelą widać, że jedynym scenariuszem, który nie jest obsługiwany, jest ten dotyczący kolejki wymagającej uwierzytelniania w usłudze Active Directory. Integracja grupowych kont usług (kont usług zarządzanych przez grupę) z usługą MSMQ nie jest obecnie obsługiwana, ponieważ usługa MSMQ ma zależności od usługi Active Directory, które nie zostały jeszcze wprowadzone.

Alternatywnie użyj usługi Azure Service Bus zamiast msMQ. Usługa Azure Service Bus to w pełni zarządzany broker komunikatów dla przedsiębiorstw z kolejkami komunikatów i kanałami publikacji-subskrypcji (w przestrzeni nazw). Przejście z msMQ do usługi Azure Service Bus wymaga zmian kodu i ponownej architektury aplikacji, ale zapewni elastyczność przechodzenia do nowoczesnej platformy.

MSDTC

Koordynator transakcji rozproszonych firmy Microsoft (MSDTC) jest intensywnie używany w starszych aplikacjach systemu Windows wśród dużych przedsiębiorstw. MsdTC można zainstalować w kontenerach systemu Windows, ale istnieją pewne scenariusze, które nie działają i nie mogą być odtwarzane w kontenerach systemu Windows.

• Podczas tworzenia kontenera pamiętaj, aby przekazać parametr --name do polecenia docker run. Ten parametr nazwy umożliwia kontenerom komunikowanie się za pośrednictwem sieci platformy Docker. Jeśli używasz konta gMSA, nazwa musi być zgodna z nazwą hosta, która musi być zgodna z nazwą konta gMSA.
  • Oto przykład polecenia run z gMSA:

docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022

• Kontenery muszą mieć możliwość rozpoznawania siebie nawzajem przy użyciu nazwy NETBIOS. Jeśli istnieją trudności z tym, najlepszym sposobem rozwiązania jest dodanie nazwy i adresu IP kontenerów do odpowiednich plików hosta.
• Identyfikator UUID dla MSDTC w obu kontenerach musi być unikatowy. Identyfikator UUID można znaleźć, uruchamiając polecenie "Get-Dtc" w PowerShell na kontenerach. Jeśli nie są one unikatowe, jednym ze sposobów rozwiązania problemu jest odinstalowanie i ponowne zainstalowanie msdtc w jednym z kontenerów. Tych poleceń programu PowerShell można użyć: "uninstall-dtc", "install-dtc".
• Obecnie usługa MSDTC nie jest obsługiwana w usługach Azure Kubernetes Services. Jeśli masz określoną potrzebę uruchomienia usługi MSDTC w usłudze AKS, poinformuj zespół kontenerów Windows, zgłaszając problem w repozytorium Windows containers na GitHub.

Jak działa usługa IIS w kontenerze a maszyna wirtualna

Usługi IIS działają tak samo w kontenerze systemu Windows, jak na maszynie wirtualnej. Istnieją jednak pewne aspekty uruchamiania instancji serwera IIS, które należy wziąć pod uwagę podczas uruchamiania w środowisku kontenera:

• Pamięć trwała dla danych lokalnych: foldery, do których aplikacja zapisuje i z których odczytuje pliki, są doskonałym przykładem zasobu, który można przechowywać na maszynie wirtualnej jako część instancji usług IIS. W przypadku kontenerów nie chcesz zapisywać żadnych danych bezpośrednio w kontenerze. Kontenery używają "miejsca tymczasowego" dla przechowywania lokalnego, i gdy nowy kontener zostanie uruchomiony dla tej samej aplikacji, nie ma dostępu do tego obszaru z poprzedniego kontenera. W związku z tym wykorzystaj trwałą pamięć do przechowywania danych, które muszą być dostępne dla aplikacji internetowej, tak aby każde wystąpienie kontenera mogło mieć do nich dostęp.
• Certyfikaty: Chociaż można posiadać lokalne certyfikaty na wystąpieniach kontenerów, należy tego unikać, ponieważ jeśli certyfikat wymaga aktualizacji, trzeba ponownie zbudować obraz kontenera. Alternatywnie, możesz użyć orkiestratora kontenerów z kontrolerem Ingress. Kontrolery ruchu przychodzącego mogą stosować zasady sieciowe, a także obsługiwać zarządzanie certyfikatami dla hostowanej za nią witryny internetowej. Plusem jest oddzielenie zarządzania cyklem życia certyfikatów od zarządzania witryną internetową.
• Parametry połączenia bazy danych: w przypadku tradycyjnego wdrożenia usług IIS można przekazać parametry połączenia bazy danych w ramach wdrożenia aplikacji. Chociaż kontenery systemu Windows umożliwiają obserwowanie tego modelu, warto rozważyć oddzielenie parametrów połączenia bazy danych z kontenera do scentralizowanej konfiguracji udostępnionej przez koordynatora kontenerów, z którego aplikacja może odczytywać. Umożliwia to zarządzanie parametrami połączenia bazy danych i aktualizowanie ich niezależnie od aplikacji. Jeśli baza danych zmieni się (na przykład w przypadku migracji metodą Lift and Shift do chmury), możesz łatwo zmienić parametry połączenia bez ponownego kompilowania obrazu kontenera. Takie podejście umożliwia również przechowywanie danych poufnych (takich jak nazwa użytkownika i hasło do nawiązywania połączenia z bazą danych) w repozytorium tajnych danych.
• Automatyczne skalowanie w poziomie: w przypadku wzrostu obciążenia systemy obliczeniowe mają tendencję do spowolnienia postrzeganej wydajności podczas próby przetwarzania równoczesnych żądań. Istnieją zazwyczaj dwa sposoby na uniknięcie negatywnego wpływu na wydajność — skalowanie pionowe lub poziome. Skalowanie w pionie zwiększa zasoby dostępne dla istniejących wystąpień obliczeniowych (więcej procesora CPU, pamięci itp.). Skalowanie w poziomie zwiększa liczbę wystąpień obsługujących żądania (więcej hostów fizycznych lub maszyn wirtualnych lub kontenerów). W przypadku warstw internetowych, takich jak usługi IIS, skalowanie w poziomie zwykle jest bardziej wydajne niż w pionie, ale środowiska lokalne mogą napotkać ograniczenia zasobów i problemy z równoważeniem obciążenia. W przypadku środowisk w chmurze skalowanie w poziomie jest znacznie łatwiejsze, ponieważ zasoby są łatwo dostępne (w przypadku dodatkowych kosztów), a dostawca usług w chmurze zwykle projektuje mechanizm równoważenia obciążenia z myślą o skali poziomej. Kontenery systemu Windows mogą wykorzystywać skalowanie w poziomie dla usług IIS, ale efemeryczny aspekt kontenerów odgrywa ważną rolę. Konieczne jest, aby kontenery miały taką samą konfigurację i że żaden stan lub dane nie są przechowywane w celu umożliwienia skalowania w górę lub w dół liczby wystąpień obsługujących aplikację internetową.

Zaplanowane zadania

Zaplanowane zadania są używane do wywoływania programu, usługi lub skryptu w dowolnym momencie w środowisku systemu Windows. Tradycyjnie masz maszynę wirtualną z systemem Windows, która jest uruchomiona i działa bez przerwy, a kiedy zostanie spełniony warunek wyzwalający, zadanie zostaje wykonane. Jest to możliwe w przypadku kontenerów systemu Windows i — oprócz faktu, że należy skonfigurować zaplanowane zadania i zarządzać nimi za pośrednictwem programu Azure PowerShell — działają dokładnie tak samo.

Jednak w przypadku podejścia mikrousług istnieje kilka opcji, aby uniknąć utrzymania uruchomionego kontenera w celu oczekiwania na wyzwalacz:

• Użyj usługi PaaS opartej na zdarzeniach (platforma jako usługa), takiej jak funkcja platformy Azure, do przechowywania kodu i definiowania wyzwalacza dla tej aplikacji. Usługa Azure Functions obsługuje nawet obrazy kontenerów systemu Windows, które mają być uruchamiane po spełnieniu wyzwalacza.
• Używaj kontenerów systemu Windows w połączeniu z koordynatorem kontenerów. Kontener może działać tylko wtedy, gdy zostanie spełniony określony warunek i wywołany z innych części aplikacji. W takim przypadku orkiestrator kontenerów będzie obsługiwał planowanie i uruchamianie aplikacji.
• Na koniec zachowaj uruchomiony kontener systemu Windows, aby uruchomić zaplanowane zadanie. Aby zachować działanie kontenera, potrzebna będzie usługa pierwszego planu (na przykład Service Monitor).

Usługi w tle

Chociaż kontenery są zwykle przeznaczone dla procesów efemerycznych, można skonteneryzować długotrwałą aplikację działającą w tle, pod warunkiem że utworzysz proces pierwszego planu, który zarówno ją uruchomi, jak i utrzyma działanie.

Doskonałym przykładem jest ServiceMonitor, który jest plikiem wykonywalnym systemu Windows przeznaczonym do użycia jako proces punktu wejścia podczas uruchamiania usług IIS w kontenerach. Mimo że został utworzony dla usług IIS, narzędzie ServiceMonitor oferuje model, który może być również używany do monitorowania innych usług, z pewnymi ograniczeniami.

Aby uzyskać więcej informacji na temat usługi ServiceMonitor, zapoznaj się z dokumentacją w witrynie GitHub.

.NET Framework i .NET

Kontenery systemu Windows obsługują zarówno programy .NET Framework, jak i .NET (dawniej .NET Core). Zespół platformy .NET tworzy własne oficjalne obrazy dla obu platform na podstawie podstawowych obrazów kontenerów systemu Windows. Wybranie odpowiedniego obrazu ma kluczowe znaczenie dla zapewnienia zgodności. Zespół platformy .NET udostępnia obrazy .NET Framework zbudowane na bazowym obrazie kontenera Server Core oraz obrazy .NET zbudowane na bazowych obrazach kontenerów Server Core i Nano Server. Server Core ma większy zestaw interfejsów API niż Nano Server, co zapewnia większą zgodność, ale także większy rozmiar obrazu. Serwer Nano Server ma znacznie zmniejszoną powierzchnię interfejsu API, ale znacznie mniejszy rozmiar obrazu.

W niektórych przypadkach może być konieczne utworzenie własnego obrazu .NET Framework lub .NET na podstawie obrazów kontenera systemu Windows lub serwera podstawowego. Może to być konieczne, jeśli aplikacja ma nie tylko zależność platformy, ale zależność systemu operacyjnego. Będzie można wykryć wszelkie takie zależności, testując aplikację przy użyciu określonego obrazu kontenera podstawowego.

Na przykład podstawowe obrazy kontenerów Server Core i Nano Server mają tylko jedną czcionkę, aby zmniejszyć rozmiar obrazu. Jeśli aplikacja wymaga innej czcionki, musisz zainstalować tę czcionkę lub użyć obrazów serwera lub systemu Windows, które mają większy zestaw interfejsów API i zawierają wszystkie domyślne czcionki systemu Windows. Z punktu widzenia zgodności pozwala to na konteneryzację praktycznie dowolnej aplikacji (o ile szanują one charakter kontenerów, takich jak brak graficznego interfejsu użytkownika). Minusem jest to, że będą znacznie większe, co może mieć wpływ na wydajność.

Podczas sprawdzania poprawności, czy aplikacja do konteneryzowania działa w kontenerach systemu Windows, firma Microsoft zaleca:

Dla tej platformy	Najpierw przetestuj przy użyciu tego obrazu kontenera	Powrót do tego obrazu kontenera, jeśli pierwszy nie działa	Obraz podstawowy
.NET Framework w wersjach 2.X i 3.X	.NET Framework 4.x	.NET Framework 3.5	Windows Server Core
Wersje programu .NET Framework 4.x	.NET Framework 4.x	Kompilowanie obrazu kontenera programu .NET Framework przy użyciu obrazów serwera lub systemu Windows	Windows Server Core
.NET 6 lub 7	.NET 6 lub 7, odpowiednio	Budowanie obrazu kontenera .NET przy użyciu obrazów bazowych Windows lub Servera	Windows Nano Server lub Server Core

Inne składniki pomocnicze

Poniższe składniki i tematy zawierają dodatkowe wskazówki dotyczące elementów, które idą obok lub które zapewniają lepszą przejrzystość w kontenerach systemu Windows.

Rejestrowanie zdarzeń

Systemy Windows i Linux używają różnych metod do przechowywania i prezentowania dzienników i zdarzeń użytkownikom. Tradycyjnie system Windows używał formatu EVT, który można wyświetlić w sposób ustrukturyzowany w Podglądzie zdarzeń. Z kolei system Linux zapewnia usprawnione podejście ze standardowymi danymi wyjściowymi (stdout), na których polegają inne narzędzia, takie jak Platforma Docker.

Platforma Docker zawsze miała mechanizm wyodrębniania dzienników z kontenerów systemu Linux. Za pomocą polecenia "dzienniki platformy Docker" z domyślną konfiguracją stdout platforma Docker umożliwia wylogowywanie aplikacji z kontenera bez interaktywnego otwierania kontenera. Jednak do momentu uruchomienia narzędzia Monitor dzienników ta sama technika nie zadziałała w systemie Windows.

Narzędzie Monitor dzienników przedstawia dzienniki systemu Windows w formacie stdout, aby inne narzędzia, takie jak Docker, mogły zbierać informacje niezbędne do jego wyświetlenia. Dodatkowe korzyści wynikające z korzystania z Log Monitora obejmują następujące:

• Możliwość filtrowania typów zdarzeń/dzienników, które mają być widoczne w stdout. Możesz na przykład filtrować dziennik aplikacji pod kątem komunikatów „błąd” i „ostrzeżenie” tylko wtedy, gdy nie interesują Cię zdarzenia „informacyjne”.
• Możliwość wyboru z dzienników zdarzeń, niestandardowych plików dziennika lub śledzenia zdarzeń dla systemu Windows (ETW). Jest to szczególnie przydatne, jeśli aplikacja zapisuje dane w innym źródle logu. Przykładem są dzienniki usług IIS znajdujące się w folderze "C:\inetpub".
• Fakt, że monitor dzienników sprawia, że kontenery systemu Windows zachowują się podobnie jak kontenery systemu Linux, a tym samym narzędzia, które szukają stdout i współdziałają z funkcją środowiska uruchomieniowego kontenera zgodnie z oczekiwaniami. Na przykład, jeśli przeniesiesz się z platformy Docker do ContainerD jako środowiska uruchomieniowego kontenerów, dzienniki powinny być nadal widoczne z hosta kontenera na przykład za pomocą komendy "crictl logs".

Więcej informacji na temat narzędzia do monitorowania dzienników można przeczytać w tym wpisie w blogu.

Zabezpieczenia kontenerów systemu Windows

Kontenery systemu Windows są oparte na tej samej bazie co wystąpienia systemu Windows uruchomione na maszynach fizycznych lub wirtualnych. Zrozumienie specyfiki implementacji kontenerów, zwłaszcza ich współużytkowanego jądra, pomaga zabezpieczyć konteneryzowaną aplikację:

• Wspólne komponenty Kontenery systemu Windows udostępniają niektóre składniki hosta na potrzeby zabezpieczeń. Obejmuje to zaporę systemu Windows, usługę Windows Defender (program antywirusowy) i inne ograniczenia dostępu do zasobów. Nie trzeba konfigurować tych składników bezpośrednio w kontenerze, ponieważ host kontenera wprowadza niezbędne korekty na podstawie obciążenia kontenera. Jeśli na przykład kontener wysyła żądanie internetowe, host kontenera przekaże niezbędny ruch przez zaporę, aby kontener mógł uzyskać dostęp do internetu.
• Tryb izolacji. Jak wspomniano, kontenery systemu Windows można wdrażać w trybie izolacji procesu lub Hyper-V, a Hyper-V zapewnia najbezpieczniejszą izolację. W izolacji procesów kontener dzieli się jądrem, systemem plików i rejestrem z hostem, co pozwala procesowi z podwyższonymi uprawnieniami (administrator) wejść w interakcję z procesami i usługami kontenera. Wybranie prawidłowego trybu izolacji dla aplikacji jest ważne, aby zapewnić odpowiedni model zabezpieczeń.
• Aktualizacje systemu Windows. Ponieważ stos obsługi nie jest obecny w kontenerach systemu Windows, kontenery te nie otrzymują aktualizacji jak ogólne instancje Windows. Zamiast tego należy ponownie skompilować kontenery systemu Windows przy użyciu najnowszego dostępnego podstawowego obrazu kontenera. Klienci mogą korzystać z potoków DevOps w tym celu. Microsoft aktualizuje bazowe obrazy kontenerów dla wszystkich swoich oficjalnych obrazów każdego miesiąca zgodnie z cyklem Patch Tuesday.
• Konto użytkownika kontenera. Domyślnie aplikacje wewnątrz kontenerów systemu Windows są uruchamiane z podwyższonym poziomem uprawnień w ramach konta użytkownika ContainerAdmin. Jest to przydatne w przypadku instalowania i konfigurowania niezbędnych składników wewnątrz obrazu kontenera. Należy jednak rozważyć zmianę konta użytkownika na ContainerUser podczas uruchamiania aplikacji, która nie wymaga podniesionych uprawnień. W przypadku określonych scenariuszy można również utworzyć nowe konto z odpowiednimi uprawnieniami.
• Skanowanie obrazów i środowiska uruchomieniowego. Kontenery wymagają, aby obrazy w repozytoriach i instancje kontenerów były bezpieczne. Firma Microsoft zaleca używanie usługi Microsoft Defender for Containers do skanowania obrazów i do skanowania w czasie wykonywania. Usługa Defender for Containers obsługuje kontenery systemu Windows do oceny luk w zabezpieczeniach z funkcją skanowania rejestru i ochrony środowiska uruchomieniowego z wykrywaniem zagrożeń.

Więcej informacji na temat powyższych tematów można znaleźć na stronie dokumentacji kontenerów systemu Windows .

Tworzenie kopii zapasowych kontenerów systemu Windows

Podczas korzystania z kontenerów należy inaczej myśleć o kopiach zapasowych. Jak wspomniano wcześniej, kontener nie powinien być używany do przechowywania stanu ani danych ze względu na jego efemeryczny charakter. Jeśli oddzielisz stan i dane od wystąpienia kontenera, zagadnienia dotyczące kopii zapasowych będą znajdować się poza czasem działania kontenera, które można zastąpić nowym wystąpieniem, do którego to nowego wystąpienia będzie nadal dostępny cały wymagany magazyn trwały.

Istnieją jednak składniki, które są odpowiedzialne za tworzenie kopii zapasowych; w tym aplikację, obraz kontenera i plik dockerfile, który kompiluje obraz kontenera. Większość tych operacji jest obsługiwana przez platformę, na której są uruchamiane obciążenia produkcyjne i programistyczne. Podczas wdrażania metodyki DevOps należy wziąć pod uwagę najczęstsze przypadki:

• Aplikacja: Aplikacja prawdopodobnie znajduje się w repozytorium źródłowym, takim jak GitHub lub Azure DevOps. Te repozytoria zapewniają kontrolę wersji, która umożliwia powrót do określonej wersji aplikacji. Jeśli jesteś właścicielem repozytorium źródłowego, postępuj zgodnie z zaleceniami dotyczącymi tworzenia kopii zapasowych i zarządzania.
• Obraz kontenera: w przypadku środowisk produkcyjnych obraz kontenera powinien znajdować się w scentralizowanym repozytorium obrazów, takim jak usługa Azure Container Registry (ACR). Można wypchnąć obrazy kontenerów do usługi ACR, co umożliwia innym hostom ich pobranie. Usługa ACR obsługuje dostępność obrazów kontenerów i służy jako opcja tworzenia kopii zapasowej — należy jednak pamiętać, że usługa ACR obsługuje dostępność obrazu, nie uniemożliwia usunięcia ani zastąpienia obrazu. W przypadku dowolnego innego lokalnego lub lokalnego repozytorium obrazów postępuj zgodnie z zaleceniem dostawcy dotyczącymi tworzenia kopii zapasowych istniejących rejestrów.
• Dockerfile: Pliki Dockerfile tworzą nowe obrazy kontenerów i są zwykle przechowywane wraz ze źródłem aplikacji. Ponieważ plik dockerfile mógł nie zostać utworzony za pomocą aplikacji, zwłaszcza jeśli jest to istniejąca aplikacja konteneryzowana, odpowiadasz za zapewnienie, że plik dockerfile jest przechowywany w bezpiecznej i kopii zapasowej. Należy również upewnić się, że są tworzone kopie zapasowe wszystkich innych zasobów niezbędnych do pracy aplikacji w kontenerze; na przykład: pliki YAML i JSON dla platform Kubernetes, Docker Swarm i Azure ARM są zgodne z tymi samymi wytycznymi co powyżej.

Planowanie procesu "lift-and-shift"

Po dokonaniu oceny gotowości aplikacji do konteneryzacji skorzystaj z poniższych ogólnych wskazówek, aby zaplanować proces:

1. Określ potrzebny obraz podstawowy systemu operacyjnego Windows: Windows Server Core, Nano Server, Windowslub Server images.
2. Określ typ trybu izolacji dla kontenera: wybierz między trybem procesu a trybem izolacji Hyper-V. Uwaga: Obecnie AKS i AKS na Azure Stack HCI obsługują tylko kontenery z izolacją procesów. W przyszłej aktualizacji zarówno AKS, jak i AKS w Azure Stack HCI będzie także obsługiwać kontenery izolowane przez Hyper-V. Aby uzyskać więcej informacji, zobacz Tryby izolacji.
3. Wybierz odpowiednią wersję systemu Windows Server dla aplikacji na potrzeby zgodności aplikacji. Minimalna wersja systemu Windows Server dla kontenerów to Windows Server 2016, ale Systemy Windows Server 2019 i Windows Server 2022 są jedynymi systemami operacyjnymi hosta kontenera obsługiwanymi w usługach AKS i AKS w usłudze Azure Stack HCI.
4. Upewnij się, że zasady zabezpieczeń firmy są spełnione w środowisku kontenera. Obejmuje to dostosowanie do wymagań specyficznych dla kontenera, takich jak skanowanie rejestru i wykrywanie zagrożeń.
5. Rozważ potrzeby równoważenia obciążenia. Same kontenery nie są przenoszone; Zamiast tego możesz użyć orkiestratora, aby automatycznie uruchamiać lub zatrzymywać kontenery w węzłach klastra lub zarządzać zmianami obciążenia i dostępności za pomocą automatycznego skalowania w poziomie.
6. Rozważ potrzeby orkiestracji. Po konteneryzowanym środowisku aplikacja prawdopodobnie wymaga zautomatyzowanego zarządzania dostępnego za pomocą narzędzi, takich jak Kubernetes, AKS lub AKS w usłudze Azure Stack HCI. Zobacz Omówienie orkiestracji kontenerów Windows, aby uzyskać pełne omówienie i przewodnik dotyczący wyboru spośród dostępnych narzędzi.
7. Konteneryzowanie aplikacji.
8. Wypchnij aplikację do repozytorium obrazów. Umożliwi to hostom kontenerów pobieranie obrazu w dowolnym środowisku, w tym tworzenie, testowanie i produkcja.

Usługa Azure Migrate może zapewnić proces z przewodnikiem umożliwiający odnajdywanie, ocenianie i migrowanie istniejącej aplikacji systemu Windows do usługi Azure Kubernetes Service. Aby uzyskać więcej informacji, zapoznaj się ze stroną dokumentacji Azure Migrate.