ProHoster > Blogi > Haldamine > Dockeri kasutamine mitmeastmelisena Windowsi kujutiste loomiseks

Dockeri kasutamine mitmeastmelisena Windowsi kujutiste loomiseks

Tere kõigile! Minu nimi on Andrey ja töötan DevOpsi insenerina Exnessis arendusmeeskonnas. Minu põhitegevus on seotud rakenduste ehitamise, juurutamise ja toetamisega dockeris Linuxi operatsioonisüsteemi (edaspidi OS) all. Mitte kaua aega tagasi oli mul samade tegevustega ülesanne, kuid projekti siht-OS oli Windows Server ja C++ projektide komplekt. Minu jaoks oli see esimene tihe suhtlemine dockeri konteineritega Windows OS-i all ja üldiselt C++ rakendustega. Tänu sellele sain huvitava kogemuse ja õppisin Windowsi rakenduste konteinerisse paigutamise mõningaid keerukusi.

Dockeri kasutamine mitmeastmelisena Windowsi kujutiste loomiseks

Selles artiklis tahan teile rääkida, milliste raskustega ma silmitsi seisin ja kuidas mul õnnestus need lahendada. Loodan, et see on teie praeguste ja tulevaste väljakutsete jaoks abiks. Nautige lugemist!

Miks konteinerid?

Ettevõttel on olemasolev infrastruktuur Hashicorp Nomad konteineriorkestri ja sellega seotud komponentide - Consul ja Vault - jaoks. Seetõttu valiti rakenduste konteineriseerimine tervikliku lahenduse tarnimise ühtseks meetodiks. Kuna projekti infrastruktuur sisaldab dokkimishoste Windows Server Core OS-i versioonidega 1803 ja 1809, tuleb 1803 ja 1809 jaoks luua eraldi versioonid dockeri kujutistest. Versioonis 1803 on oluline meeles pidada, et dokkimisseadme versiooni number peab vastama dokkeri põhikujutise versiooninumbrile ja hostile, kus selle pildi konteiner käivitatakse. Versioonil 1809 sellist puudust pole. Saate rohkem lugeda siin.

Miks mitmeastmeline?

Arendusmeeskonna inseneridel puudub juurdepääs hostide loomiseks või see on väga piiratud; puudub võimalus kiiresti hallata komponentide komplekti nendel hostidel rakenduse koostamiseks, näiteks installida Visual Studio jaoks täiendav tööriistakomplekt või töökoormus. Seetõttu otsustasime installida kõik rakenduse ehitamiseks vajalikud komponendid Dockeri pilti. Vajadusel saate kiiresti muuta ainult dockeri faili ja käivitada selle pildi loomise konveieri.

Teooriast tegudeni

Ideaalses Dockeri mitmeastmelises pildiehituses valmistatakse rakenduse koostamise keskkond ette samas Dockerfile'i skriptis, millega rakendus ise on ehitatud. Kuid meie puhul lisati vahelink, nimelt dokipildi eelnev loomise samm koos kõige vajalikuga rakenduse ehitamiseks. Seda tehti seetõttu, et soovisin kasutada dockeri vahemälu funktsiooni, et vähendada kõigi sõltuvuste installiaega.

Vaatame selle pildi loomise dockerfile'i skripti põhipunkte.

Erinevate OS-i versioonide piltide loomiseks saate dockeri failis määratleda argumendi, mille kaudu versiooninumber ehitamise ajal edastatakse, ja see on ka baaspildi silt.

Microsoft Windows Serveri pildimärgendite täieliku loendi leiate siin.

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

Vaikimisi juhiste käsud RUN Windows OS-i dockerfile'is käivitatakse need konsoolis cmd.exe. Skriptide kirjutamise mugavuse ja kasutatavate käskude funktsionaalsuse laiendamise huvides määratleme käsu abil Powershelli käsutäitmiskonsooli ümber. SHELL.

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

Järgmine samm on šokolaadipakendihalduri ja vajalike pakettide installimine:

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'

Šokolaadipakettide installimiseks saate need lihtsalt loendina edastada või installida ükshaaval, kui peate edastama iga paketi kordumatud parameetrid. Meie olukorras kasutasime XML-vormingus manifesti faili, mis sisaldab vajalike pakettide ja nende parameetrite loendit. Selle sisu näeb välja selline:

<?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>

Järgmisena installime rakenduse ehituskeskkonna, nimelt MS Build Tools 2019 - see on Visual Studio 2019 kerge versioon, mis sisaldab minimaalselt vajalikku komponentide komplekti koodi koostamiseks.
C++ projektiga täielikuks töötamiseks vajame lisakomponente, nimelt:

  • Töökoormus C++ tööriistad
  • Tööriistakomplekt v141
  • Windows 10 SDK (10.0.17134.0)

Saate installida laiendatud tööriistade komplekti automaatselt, kasutades JSON-vormingus konfiguratsioonifaili. Konfiguratsioonifaili sisu:

Saadaolevate komponentide täieliku loendi leiate dokumentatsiooni saidilt 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"
  ]
}

Dockeri fail käivitab installiskripti ja mugavuse huvides lisab keskkonnamuutujasse ehitustööriistade käivitatavate failide tee PATH. Samuti on pildi suuruse vähendamiseks soovitatav eemaldada mittevajalikud failid ja kataloogid.

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)

Selles etapis on meie pilt C++ rakenduse kompileerimiseks valmis ja saame otse edasi minna rakenduse mitmeastmelise Dockeri ehituse loomisega.

Mitmeastmeline tegevuses

Kasutame loodud pilti koos kõigi pardal olevate tööriistadega ehituspildina. Nagu ka eelmises dockerfile-skriptis, lisame koodi taaskasutamise hõlbustamiseks võimaluse dünaamiliselt määrata versiooninumbri/pildimärgendi. Oluline on lisada silt as builder juhendis olevale koostepildile FROM.

ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builder

Nüüd on aeg rakendust luua. Siin on kõik üsna lihtne: kopeerige lähtekood ja kõik sellega seonduv ning alustage kompileerimisprotsessi.

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

Lõpliku pildi loomise viimane etapp on rakenduse baaspildi määramine, kus asuvad kõik koostamise artefaktid ja konfiguratsioonifailid. Kompileeritud failide kopeerimiseks vahepealsest koostepildist peate määrama parameetri --from=builder juhistes COPY.

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

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

Nüüd jääb üle vaid lisada meie rakenduse töötamiseks vajalikud sõltuvused ja määrata juhiste kaudu käivituskäsk ENTRYPOINT või CMD.

Järeldus

Selles artiklis rääkisin sellest, kuidas luua Windowsi konteineris täisväärtuslikku kompileerimiskeskkonda C++ rakenduste jaoks ja kuidas kasutada dockeri mitmeastmeliste ehituste võimalusi, et luua meie rakendusest täisväärtuslikke pilte.

Allikas: www.habr.com

Lisa kommentaar