🥇Docker multi-stage izmantošana Windows attēlu veidošanai

Sveiki visiem! Mani sauc Andrejs, un es esmu DevOps inženier uzņēmumā Exness izstrādes komandā. Mana galvenā darbība ir saistīta ar lietotņu izveidi, izvietošanu un atbalstu docker vidē operētājsistēmā Linux. Ne tik sen man radās uzdevums ar tām pašām darbībām, bet projekta mērķa operētājsistēma ir kļuvusi par Windows Server un kopums projektu C++. Man tā bija pirmā cieša mijiedarbība ar docker konteineriem operētājsistēmā Windows un vispār ar lietotnēm C++. Pateicoties tam, es ieguvu interesantu pieredzi un uzzināju par dažām niansēm lietotņu konteinerizācijā operētājsistēmā Windows.

Šajā rakstā vēlos pastāstīt, ar kādām grūtībām man nācās saskarties un kādā veidā tās izdevās atrisināt. Ceru, ka tas noderēs jūsu pašreizējām un nākotnes uzdevumiem. Patīkamu lasīšanu!

Kāpēc konteineri?

Uzņēmumā ir esošā konteineru orķestratora Hashicorp Nomad infrastruktūra un saistītie komponenti — Consul un Vault. Tāpēc lietotņu konteinerizācija tika izvēlēta kā vienots risinājums gatavo risinājumu piegādei. Tā kā projekta infrastruktūrā ir docker hosti ar operētājsistēmu Windows Server Core 1803 un 1809, ir nepieciešams neatkarīgi izveidot docker attēlu versijas 1803 un 1809. Versijā 1803 ir svarīgi atcerēties, ka docker hosta būvniecības numuram jāatbilst pamatdocker attēla un hosta revīzijas numuriem, kur tiks palaists konteiners no šī attēla. Versija 1809 šādas trūkuma nav. Sīkāk var izlasīt šeit.

Kāpēc multi-stage?

Izstrādātāju komandas inženieriem piekļuve būvniecības hostiem ir ierobežota vai ļoti ierobežota, nav iespēju operatīvi pārvaldīt komponentu kopumu, lai izveidotu lietotni šajos hostos, piemēram, instalēt papildu rīku komplektu vai slodzi Visual Studio. Tāpēc mēs pieņēmām lēmumu — visu nepieciešamo komponentu, kas nepieciešami lietotnes būvei, instalēt būvniecības docker attēlā. Ja nepieciešams, var diezgan ātri mainīt tikai dockerfile un palaist šo attēlu izveides pipelines.

No teorijas uz praksi

Ideālā docker multi-stage attēla būvē videi aplikācijas būvēšanai izmanto pašu dockerfile skriptu, kurā notiek arī aplikācijas būvēšana. Bet mūsu gadījumā tika pievienots starpposms, proti, solis priekšlaicīgas docker attēla veidošanas ar visu nepieciešamo aplikācijas būvēšanai. Tas tika izdarīts, jo vēlējāmies izmantot docker kešatmiņas iespēju, lai samazinātu atkarību instalēšanas laiku.

Apskatīsim galvenos punktus dockerfile skriptā šī attēla veidošanai.

Lai izveidotu dažādu OS versiju attēlus dockerfile, var definēt argumentu, caur kuru būves laikā tiek nodots versijas numurs, un tas ir pamatattēla tags.

Pilnu Microsoft Windows Server attēlu tagu sarakstu var atrast šeit.

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

Pēc noklusējuma komandas instrukcijās RUN iekš dockerfile Windows OS izpilda cmd.exe konsolē. Ērtības labad skriptu rakstīšanai un izmantoto komandu funkcionalitātes paplašināšanai pārrakstīsim komandu izpildes konsoli uz PowerShell, izmantojot instrukciju SHELL.

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

Nākamajā solī instalējam pakotņu pārvaldnieku chocolatey un nepieciešamās pakas:

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'

Lai instalētu pakas, izmantojot chocolatey, varam vienkārši nodot tās sarakstā vai arī instalēt pa vienai, ja nepieciešams nodot unikālus parametrus katrai pakai. Mūsu gadījumā izmantojām XML formāta manifestu, kurā norādīts nepieciešamo paka un to parametru saraksts. Tās saturs izskatās šādi:

Tālāk mēs instalējam aplikācijas būvēšanas vidi, proti, MS Build Tools 2019 — tas ir viegls Visual Studio 2019 versija, kas satur minimāli nepieciešamo komponentu komplektu koda kompilēšanai.
Lai pilnvērtīgi darbotos ar mūsu C++ projektu, mums būs nepieciešamas papildu komponentes, proti,

Workload C++ tools
Rīku komplekts v141
Windows 10 SDK (10.0.17134.0)

Paplašināto rīku komplektu automātiski var instalēt, izmantojot konfigurācijas failu JSON formātā. Konfigurācijas faila saturs:

Pilnu pieejamo komponentu sarakstu var atrast dokumentācijas vietnē 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"
  ]
}

Dockerfailā tiek izpildīts uzstādīšanas skripts, un ērtības labad tiek pievienota ceļa mainīgā norāde uz izpildfailiem build tools. PATH. Tāpat ir ieteicams noņemt nevajadzīgās failus un katalogus, lai samazinātu attēla izmēru.

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)

Šajā posmā mūsu attēls C++ aplikācijas kompilēšanai ir gatavs, un varam turpināt ar docker multi-stage aplikācijas veidošanu.

Multi-stage darbībā

Kā būvniecības attēlu izmantojam iepriekšējo attēlu ar visiem rīkiem iekšpusē. Tāpat kā iepriekšējā dockerfaila skriptā, pievienosim iespēju dinamiski norādīt attēla versijas numuru/tagu, lai atvieglotu koda atkārtotu izmantošanu. Ir svarīgi pievienot marķējumu as builder būvniecības attēlam instrukcijā FROM.

ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builder

Nākusi kārta aplikācijas būvēšanai. Šeit viss ir pietiekami vienkārši: jānokopē izejas kods un viss, kas ar to saistīts, un jāsāk kompilācijas process.

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

Noslēdzošais posms gala attēla izveidē ir bāzes attēla norādīšana, kurā atradīsies visas kompilācijas artefakti un konfigurācijas faili. Lai nokopētu kompilētus failus no starpsējo būvniecības attēla, jānorāda parametrs --from=builder instrukcijā COPY.

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

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

Tagad atlikusi tikai nepieciešamo atkarību pievienošana mūsu aplikācijas darbībai un palaišanas komandas norādīšana caur instrukcijām ENTRYPOINT vai CMD.

Secinājums

Šajā rakstā es pastāstīju, kā izveidot pilnvērtīgu C++ lietojumprogrammu kompilācijas vidi konteinerā operētājsistēmā Windows un kā izmantot docker multi-stage veidošanas iespējas, lai izveidotu mūsu lietojumprogrammas pilnvērtīgus attēlus.

Avots: habr.com