Uzante docker plurstadian por konstrui fenestrojn bildojn

Saluton al ĉiuj! Mi nomiĝas Andrey, kaj mi laboras kiel DevOps-inĝeniero ĉe Exness en la evolua teamo. Mia ĉefa agado rilatas al konstruado, deplojado kaj subteno de aplikaĵoj en docker sub la Linukso operaciumo (ĉi-poste nomata OS). Antaŭ nelonge mi havis taskon kun la samaj agadoj, sed la cela OS de la projekto estis Windows Server kaj aro da C++-projektoj. Por mi, ĉi tio estis la unua proksima interago kun docker-ujoj sub Windows OS kaj, ĝenerale, kun C++-aplikoj. Dank' al ĉi tio, mi havis interesan sperton kaj lernis pri kelkaj el la komplikaĵoj de kontenerigo de aplikaĵoj en Vindozo.

En ĉi tiu artikolo mi volas diri al vi, kiajn malfacilaĵojn mi devis alfronti kaj kiel mi sukcesis solvi ilin. Mi esperas, ke ĉi tio estas helpema por viaj nunaj kaj estontaj defioj. Ĝuu legadon!

Kial ujoj?

La firmao havas ekzistantan infrastrukturon por la Hashicorp Nomad kontenerorkestro kaj rilataj komponentoj - Konsulo kaj Trezorejo. Tial, aplikaĵujo estis elektita kiel unuigita metodo por liveri kompletan solvon. Ĉar la projekta infrastrukturo enhavas docker-gastigojn kun Windows Server Core OS-versioj 1803 kaj 1809, necesas konstrui apartajn versiojn de docker-bildoj por 1803 kaj 1809. En versio 1803, estas grave memori, ke la revizia numero de la konstrua docker-gastiganto. devas kongrui kun la revizia numero de la baza docker-bildo kaj la gastiganto kie la ujo de ĉi tiu bildo estos lanĉita. Versio 1809 ne havas tian malavantaĝon. Vi povas legi pli tie.

Kial plurstadia?

Inĝenieroj pri evoluigaj teamoj havas neniun aŭ tre limigitan aliron por konstrui gastigantojn; ne estas maniero rapide administri la aron da komponantoj por konstrui aplikaĵon sur ĉi tiuj gastigantoj, ekzemple, instali plian ilaron aŭ laborŝarĝon por Visual Studio. Tial ni faris la decidon instali ĉiujn komponantojn necesajn por konstrui la aplikaĵon en la konstruan bildon de Docker. Se necese, vi povas rapide ŝanĝi nur la dockerfile kaj lanĉi la dukton por krei ĉi tiun bildon.

De teorio al ago

En ideala plurŝtupa bildkonstruaĵo de Docker, la medio por konstrui la aplikaĵon estas preparita en la sama Dockerfile-skripto kiel la aplikaĵo mem estas konstruita. Sed en nia kazo, meza ligo estis aldonita, nome, la paŝo de prepara kreado de docker-bildo kun ĉio necesa por konstrui la aplikaĵon. Ĉi tio estis farita ĉar mi volis uzi la funkcion de docker kaŝmemoro por redukti la instaltempon de ĉiuj dependecoj.

Ni rigardu la ĉefajn punktojn de la dockerfile-skripto por krei ĉi tiun bildon.

Por krei bildojn de malsamaj OS-versioj, vi povas difini argumenton en la dockerfile tra kiu la versio-numero estas pasita dum la konstruo, kaj ĝi ankaŭ estas la etikedo de la baza bildo.

Kompleta listo de bildaj etikedoj de Microsoft Windows Server troviĝas tie.

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

Defaŭlte la komandoj en la instrukcioj RUN ene de la dockerfile sur Windows OS ili estas ekzekutitaj en la cmd.exe konzolo. Por la komforto verki skriptojn kaj vastigi la funkciecon de la uzataj komandoj, ni redifinos la komandan ekzekutkonzolon en Powershell per la instrukcio. SHELL.

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

La sekva paŝo estas instali la ĉokoladan pakaĵadministrilon kaj la necesajn pakaĵojn:

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'

Por instali pakaĵojn uzante chocolatey, vi povas simple pasi ilin kiel liston, aŭ instali ilin unuope se vi bezonas pasi unikajn parametrojn por ĉiu pako. En nia situacio, ni uzis manifest-dosieron en XML-formato, kiu enhavas liston de postulataj pakaĵoj kaj iliaj parametroj. Ĝia enhavo aspektas jene:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="python" version="3.8.2"/>
  <package id="nuget.commandline" version="5.5.1"/>
  <package id="git" version="2.26.2"/>
</packages>

Poste ni instalas la aplikaĵan konstruan medion, nome MS Build Tools 2019 - ĉi tio estas malpeza versio de Visual Studio 2019, kiu enhavas la minimuman bezonatan aron da komponantoj por kompili kodon.
Por plene labori kun nia C++-projekto, ni bezonos pliajn komponantojn, nome:

• Laborŝarĝo C++-iloj
• Ilaro v141
• Windows 10 SDK (10.0.17134.0)

Vi povas instali plilongigitan aron da iloj aŭtomate uzante agordan dosieron en formato JSON. Enhavo de agorda dosiero:

Kompleta listo de disponeblaj komponantoj troveblas sur la dokumenta retejo Microsoft Vida 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"
  ]
}

La dockerfile rulas la instalan skripton, kaj por komforto, aldonas la vojon al la plenumeblaj dosieroj de konstruiloj al la mediovariablo. PATH. Ankaŭ estas konsilinde forigi nenecesajn dosierojn kaj dosierujojn por redukti la grandecon de la bildo.

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)

En ĉi tiu etapo, nia bildo por kompili la C++-aplikaĵon estas preta, kaj ni povas rekte iri al kreado de docker plurŝtupa konstruo de la aplikaĵo.

Plurstadia en ago

Ni uzos la kreitan bildon kun ĉiuj iloj surŝipe kiel konstruan bildon. Kiel en la antaŭa dockerfile-skripto, ni aldonos la kapablon dinamike specifi la versinumeron/bildan etikedon por facileco de reuzo de kodo. Gravas aldoni etikedon as builder al la kunigbildo en la instrukcioj FROM.

ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builder

Nun estas tempo konstrui la aplikaĵon. Ĉio ĉi tie estas sufiĉe simpla: kopiu la fontkodon kaj ĉion rilatan al ĝi, kaj komencu la kompilan procezon.

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

La fina etapo de kreado de la fina bildo estas specifi la bazan bildon de la aplikaĵo, kie troviĝos ĉiuj kompilaj artefaktoj kaj agordaj dosieroj. Por kopii kompilitajn dosierojn el la meza asemblea bildo, vi devas specifi la parametron --from=builder en la instrukcioj COPY.

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

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

Nun restas nur aldoni la necesajn dependecojn por ke nia aplikaĵo funkciu kaj specifi la lanĉan komandon per la instrukcioj ENTRYPOINT aŭ CMD.

konkludo

En ĉi tiu artikolo, mi parolis pri kiel krei plentaŭgan kompilan medion por C++-aplikoj ene de ujo sub Vindozo kaj kiel uzi la kapablojn de docker plurŝtupaj konstruoj por krei plenajn bildojn de nia aplikaĵo.

fonto: www.habr.com