Användning av docker multi-stage för att bygga Windows bilder

Hej alla! Jag heter Andrey och arbetar som DevOps-ingenjör på Exness i utvecklingsteamet. Min huvudsakliga verksamhet handlar om att bygga, distribuera och stödja applikationer i Docker under operativsystemet Linux (hädanefter — OS). Nyligen fick jag en uppgift med samma aktiviteter, men där den angivna OS för projektet blev Windows Server och en uppsättning projekt i C++. Det var första gången jag arbetade intensivt med Docker-containrar under Windows OS och generellt med applikationer i C++. Genom detta fick jag en intressant erfarenhet och lärde mig om vissa nyanser av containerisering av applikationer i Windows OS.

I den här artikeln vill jag berätta om de svårigheter jag stötte på och hur jag kunde lösa dem. Jag hoppas att detta kommer att vara användbart för att lösa dina aktuella och framtida uppgifter. Trevlig läsning!

Varför containrar?

Företaget har en befintlig infrastruktur för containerorkestrering med Hashicorp Nomad och relaterade komponenter — Consul och Vault. Därför valdes containerisering av applikationer som en enhetlig metod för leverans av en färdig lösning. Eftersom infrastrukturen för projektet har Docker-värdar med versioner av Windows Server Core 1803 och 1809, är det nödvändigt att samla in separata versioner av Docker-bilder för 1803 och 1809. I version 1803 är det viktigt att kompilatorns revisionsnummer för Docker-värden matchar revisionsnumret för den grundläggande Docker-bilden och värden där containern från denna bild ska startas. Version 1809 saknar denna brist. Mer information kan läsas. här.

Varför multi-stage?

Utvecklingsingenjörer har begränsad eller ingen tillgång till byggvärdar, vilket gör det svårt att snabbt administrera uppsättningen av komponenter för att bygga applikationen på dessa värdar, till exempel att installera ytterligare verktyg eller arbetsbelastningar för Visual Studio. Därför beslutade vi att installera alla nödvändiga komponenter för att bygga applikationen i Docker-bilden. Vid behov kan vi snabbt ändra endast Dockerfile och köra pipeline för att skapa denna bild.

Från teori till praktik

I en ideal docker multi-stage bildningsprocess för en bild förbereds miljön för att bygga applikationen i samma dockerfile-skript som själva applikationsbygget. Men i vårt fall har vi lagt till ett mellanled, nämligen ett steg för att förhands skapa docker-bilden med allt nödvändigt för att bygga applikationen. Detta har gjorts för att utnyttja docker-cache för att minska tiden för installation av alla beroenden.

Låt oss gå igenom de viktigaste punkterna i dockerfile-skriptet för att skapa denna bild.

För att skapa bilder av olika versioner av operativsystemet i dockerfile kan man definiera en parameter, genom vilken versionsnumret skickas vid bygget, och vilket är också taggen för basbilden.

En fullständig lista över taggar för Microsoft Windows Server-bilder kan hittas här.

ARG WINDOWS_OS_VERSION=1809
FROM mcr.microsoft.com/windows/servercore:$WINDOWS_OS_VERSION

Som standard körs kommandon i instruktionen RUN inuti dockerfile i Windows-operativsystemet i cmd.exe-konsolen. För att förenkla skrivandet av skript och utöka funktionaliteten hos de använda kommandona kommer vi att omdefiniera kommandokonsolen till Powershell via instruktionen SHELL.

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"]

Nästa steg är att installera paketförvaltaren chocolatey och de nödvändiga paketen:

COPY chocolatey.pkg.config .
RUN Set-ExecutionPolicy Bypass -Scope Process -Force ;
    [System.Net.ServicePointManager]::SecurityProtocol = 
    [System.Net.ServicePointManager]::SecurityProtocol -bor 3072 ;
    $env:chocolateyUseWindowsCompression = 'true' ;
    iex ((New-Object System.Net.WebClient).DownloadString( 
      'https://chocolatey.org/install.ps1')) ;
    choco install chocolatey.pkg.config -y --ignore-detected-reboot ;
    if ( @(0, 1605, 1614, 1641, 3010) -contains $LASTEXITCODE ) { 
      refreshenv; } else { exit $LASTEXITCODE; } ;
    Remove-Item 'chocolatey.pkg.config'

För att installera paket med chocolatey kan man enkelt skicka dem som en lista eller installera dem en i taget om det behövs att skicka unika parametrar för varje paket. I vårt fall använde vi en manifestfil i XML-format som innehåller en lista över nödvändiga paket och deras parametrar. Innehållet ser ut så här:

Därefter installerar vi byggmiljön för applikationen, nämligen MS Build Tools 2019 — en lättad version av Visual Studio 2019 som innehåller ett minimalt nödvändigt set av komponenter för att kompilera koden.
För att kunna arbeta fullständigt med vårt C++-projekt behöver vi ytterligare komponenter, nämligen:

• Arbetsbelastning C++ verktyg
• Verktygsvit v141
• Windows 10 SDK (10.0.17134.0)

Det utökade verktygssetet kan installation utföras automatiskt med hjälp av en konfigurationsfil i JSON-format. Innehållet i konfigurationsfilen:

Den fullständiga listan över tillgängliga komponenter finns på dokumentationssidan Microsoft Visual Studio.

{
  "version": "1.0",
  "components": [
    "Microsoft.Component.MSBuild",
    "Microsoft.VisualStudio.Workload.VCTools;includeRecommended",
    "Microsoft.VisualStudio.Component.VC.v141.x86.x64",
    "Microsoft.VisualStudio.Component.Windows10SDK.17134"
  ]
}

I dockerfilen körs installationsskriptet och för bekvämlighetens skull läggs sökvägen till körbara filer för byggverktyg i miljövariabeln. PATH. Det är dessutom önskvärt att ta bort onödiga filer och kataloger för att minska bildens storlek.

COPY buildtools.config.json .
RUN Invoke-WebRequest 'https://aka.ms/vs/16/release/vs_BuildTools.exe' 
      -OutFile '.vs_buildtools.exe' -UseBasicParsing ;
    Start-Process -FilePath '.vs_buildtools.exe' -Wait -ArgumentList 
      '--quiet --norestart --nocache --config C:buildtools.config.json' ;
    Remove-Item '.vs_buildtools.exe' ;
    Remove-Item '.buildtools.config.json' ;
    Remove-Item -Force -Recurse 
      'C:Program Files (x86)Microsoft Visual StudioInstaller' ;
    $env:PATH = 'C:Program Files (x86)Microsoft Visual Studio2019BuildToolsMSBuildCurrentBin;' + $env:PATH; 
    [Environment]::SetEnvironmentVariable('PATH', $env:PATH, 
      [EnvironmentVariableTarget]::Machine)

I detta steg är vår bild för att kompilera C++ applikationen redo, och vi kan gå vidare med att skapa docker multi-stage byggnaden av applikationen.

Multi-stage i aktion

Vi kommer att använda den skapade bilden som byggbild med alla verktyg ombord. Som i det tidigare dockerfilen, lägger vi till möjligheten att dynamiskt ange versionnummer/tag för att underlätta återanvändning av koden. Det är viktigt att lägga till en etikett as builder till byggbilden i instruktionen FRÅN.

ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builder

Nu är det dags att bygga applikationen. Här är allt ganska enkelt: kopiera källkoden och allt som hör till det, och påbörja kompilationsprocessen.

COPY myapp .
RUN nuget restore myapp.sln ;
    msbuild myapp.sln /t:myapp /p:Configuration=Release

Avslutande steg i att skapa den slutliga bilden — ange basbilden för applikationen, där alla kompilationsartefakter och konfigurationsfiler kommer att placeras. För att kopiera de kompilerade filerna från den mellanlagrade byggbilden måste du ange parametern --from=builder i instruktionen COPY.

FROM mcr.microsoft.com/windows/servercore:$WINDOWS_OS_VERSION

COPY --from=builder C:/x64/Release/myapp/ ./
COPY ./configs ./

Nu är det bara att lägga till de nödvändiga beroendena för att köra vår applikation och ange startkommandot via instruktionerna ENTRYPOINT eller CMD.

Slutsats

I den här artikeln beskriver jag hur man skapar en komplett kompilermiljö för C++-applikationer inuti en container på Windows och hur man utnyttjar docker multi-stage byggmöjligheter för att skapa fullständiga bilder av vår applikation.

Källa: habr.com