Windows Container on Fargate 를 제대로 준비할 준비가 되어 있지 않습니다.

이 기고문은 AWS Contaainers Advent Calendar 2021의 16일차 기사다.기고시간은 16일 34시 남짓입니까?
9일뉴스.에 적힌 내용으로 Windows on Farget Windows 컨테이너 가동 준비 완료!그렇게 말하고 싶지만 지난번 내용에 큰 문제가 남아있어요.
네, 저것은 일지입니다.
로그가 출력되지 않음
이상의 샘플을 기반으로 Windows 용기를 시작하면 docker container logs에서 로그를 확인할 수 없습니다.표준 IIS 액세스 로그의 출력 대상은 파일 출력이고 Windows의 기본 로그 출력 대상은 EventLog입니다.stdOUT/stdERR에 로그를 출력할 수 있다면 리눅스 컨테이너 흐름을 통해 로그를 얻을 수 있습니다.
또한 Windows Container on Fargate는 logging driver로서 awslogs를 지원하기 때문에 stdOUT/stdERR로 출력할 수 있다면 Cloudwatch Logs에서 로그를 출력할 수도 있습니다.
그렇다면 어떻게 된 일인지 조사하던 중 MS는 컨테이너용 로그 도구블로그 보도를 공개했다.Logging 도구인 Windows Container LogMonitor의 소스 코드Giithub에서를 확인할 수 있습니다.
Log Monitor는 Windows 환경에서도 Linux 컨테이너의 주요 로그 출력 방법을 실현할 수 있는 도구다.
방금 블로그 보도의 구성도를 볼 수 있다면 어떤 분위기가 더 이해가 될 것 같습니까?
Log Monitor는 다음 로그를 지원합니다. IIS 주위라면 당분간 이걸로 하는 것이 좋습니다

ETW (Event Tracing for Windows)

Event Logs

Log files

그럼, 우리 바로 해 봅시다.
Log Monitor 가져오기
실행 파일은 GiitHub의 release에서 다운로드됩니다.다운로드한 실행 파일과 설정 파일만 준비하면 된다.지난번 견본 Docker file을 토대로 다음과 같은 형식을 수정해 보았습니다.
기본적으로 모두 오리지널 샘플이지만 이번에는 Docker file을 모두 올려 보겠습니다.

# escape=`

# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:6.0.100-windowsservercore-ltsc2019 AS build
WORKDIR /source

# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore

# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore

# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:6.0.0-windowsservercore-ltsc2019

# Only needed for this sample because the sample project is targeting .NET 5
ENV DOTNET_ROLL_FORWARD=LatestMajor

RUN powershell -Command `
        $ErrorActionPreference = 'Stop'; `
        $ProgressPreference = 'SilentlyContinue'; `
        `
        # Install IIS
        Add-WindowsFeature Web-Server; `
        Remove-Item -Recurse C:\inetpub\wwwroot\*; `
        `
        # Acquire ServiceMonitor
        Invoke-WebRequest -OutFile C:\ServiceMonitor.exe -Uri https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.10/ServiceMonitor.exe; `
        `
        # Install the ASP.NET Core Module
        Invoke-WebRequest -OutFile c:\dotnet-hosting-win.exe https://aka.ms/dotnet/6.0/preview/dotnet-hosting-win.exe; `
        $process = Start-Process -Filepath C:\dotnet-hosting-win.exe -ArgumentList  @('/install', '/q', '/norestart', 'OPT_NO_RUNTIME=1', 'OPT_NO_X86=1', 'OPT_NO_SHAREDFX=1') -Wait -PassThru ; `
        if ($process.ExitCode -ne 0) { `
            exit $process.ExitCode; `
        } `
        Remove-Item -Force C:\dotnet-hosting-win.exe; `
        Remove-Item -Force -Recurse $Env:Temp\*;`
        `
        Import-Module -Name WebAdministration;`
        Set-ItemProperty -Path 'IIS:\Sites\Default Web Site' -Name logfile.logTargetW3C -Value 'File,ETW';

#Install LogMonitor
WORKDIR /LogMonitor
RUN powershell -Command `
        Invoke-WebRequest -OutFile LogMonitor.exe -Uri https://github.com/microsoft/windows-container-tools/releases/download/v1.1/LogMonitor.exe;
COPY LogMonitorConfig.json .

WORKDIR /inetpub/wwwroot
COPY --from=build /app ./

EXPOSE 80

SHELL ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe"]
CMD ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe","C:\\ServiceMonitor.exe", "w3svc"]

LogMonitor를 가져온 부분은 다음과 같습니다.

#Install LogMonitor
WORKDIR /LogMonitor
RUN powershell -Command `
        Invoke-WebRequest -OutFile LogMonitor.exe -Uri https://github.com/microsoft/windows-container-tools/releases/download/v1.1/LogMonitor.exe;
COPY LogMonitorConfig.json .

실행 파일을 설정 파일의 Logimonitor Config으로 다운로드합니다.json이 설정되어 있습니다.
설정 파일이 C:\LogMonitor\LogMonitorConfig.json에 설정되어 있기 때문에

C:\LogMonitor
    |- LogMonitor.exe
    |- LogMonitorConfig.json

이러한 구성.설정 파일의 LogiMonitor Config입니다.제이슨은 다음과 같은 내용으로 정의를 시도했다.
WindowsContainer on Fargate에서 어떤 로그를 확인할 수 있는지 시험해 보고 싶기 때문에 광범위하게 얻으려고 합니다.
IIS에 대한 설정, 접근 로그, 파일 출력, ETW는 모두 가능하지만 출력 접근 로그는 버퍼링되어 출력되며 접근 후 로그가 나타나지 않습니다.
ETW의 수출이 비교적 이르기 때문에 이번에는 두 개 모두 시도해 보았다.
IIS 측의 설정도 File, ETW 쌍방Set-ItemProperty의 부분을 지정했다.
이벤트로그를 원본 파일로 "startAtOldestRecord": false 사용하면 실행 용기에서 출력된 이벤트로그 출력 로그입니다.

{
    "LogConfig": {
      "sources": [
        {
          "type": "EventLog",
          "startAtOldestRecord": false,
          "eventFormatMultiLine": false,
          "channels": [
            {
              "name": "system",
              "level": "Information"
            },
            {
              "name": "application",
              "level": "Error"
            }
          ]
        },
        {
          "type": "File",
          "directory": "c:\\inetpub\\logs",
          "filter": "*.log",
          "includeSubdirectories": true
        },
        {
          "type": "ETW",
          "eventFormatMultiLine": false,
          "providers": [
            {
              "providerName": "IIS: WWW Server",
              "providerGuid": "3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83",
              "level": "Information"
            },
            {
              "providerName": "Microsoft-Windows-IIS-Logging",
              "providerGuid": "7E8AD27F-B271-4EA2-A783-A47BDE29143B",
              "level": "Information"
            }
          ]
        }
      ]
    }
  }

IIS를 시작하는 부분은 다음과 같습니다.여기 갑자기 나타났다ServiceMonitor.exe.이것은 Windows 컨테이너에서 IIS를 사용하는 경우의 공구다.ServiceMonitor.exe 랩처럼 사용LogMonitor.exe.

SHELL ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe"]
CMD ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe","C:\\ServiceMonitor.exe", "w3svc"]

시작됨
CloudWatch Logs에서도 로그를 재생했는데 느낌이 좋네요.필요 없는 로그가 있다면 설정을 다시 수정했으면 좋겠어요<Source>EtwEvent</Source>곳은 ETW를 통한 방문 로그입니다.그나저나 <Source>EventLog</Source>이것은 이벤트 로그를 소스로 하는 로그 항목입니다.

Container Insights도 측정할 수 있네요.

그럼 지금부터 다양한 시도를 해보자!