ProHoster > Blog > Uprava > Uporaba večstopenjskega dockerja za izdelavo slik oken

Uporaba večstopenjskega dockerja za izdelavo slik oken

Pozdravljeni vsi skupaj! Moje ime je Andrey in delam kot inženir DevOps pri Exnessu v razvojni ekipi. Moja glavna dejavnost je povezana z gradnjo, uvajanjem in podporo aplikacijam v dockerju pod operacijskim sistemom Linux (v nadaljevanju OS). Nedolgo nazaj sem imel nalogo z enakimi aktivnostmi, vendar je bil ciljni OS projekta Windows Server in niz projektov C++. Zame je bila to prva tesna interakcija z docker kontejnerji pod Windows OS in na splošno z aplikacijami C++. Zahvaljujoč temu sem imel zanimivo izkušnjo in izvedel sem nekaj zapletenosti aplikacij v kontejnerjih v sistemu Windows.

Uporaba večstopenjskega dockerja za izdelavo slik oken

V tem članku vam želim povedati, s kakšnimi težavami sem se moral soočiti in kako sem jih rešil. Upam, da vam bo to pomagalo pri trenutnih in prihodnjih izzivih. Uživajte v branju!

Zakaj kontejnerji?

Podjetje ima obstoječo infrastrukturo za Hashicorp Nomad kontejnerski orkestrator in povezane komponente - Consul in Vault. Zato je bila kontejnerizacija aplikacij izbrana kot enotna metoda za zagotavljanje celovite rešitve. Ker projektna infrastruktura vsebuje gostitelje priklopnih postaj z različicama OS Windows Server Core 1803 in 1809, je treba zgraditi ločeni različici slik priklopnih postaj za 1803 in 1809. Pri različici 1803 je pomembno zapomniti, da je številka revizije gostitelja priklopnih postaj za gradnjo se mora ujemati s številko revizije osnovne slike dockerja in gostiteljem, kjer bo zagnan vsebnik iz te slike. Različica 1809 nima te pomanjkljivosti. Lahko preberete več tukaj.

Zakaj večstopenjski?

Inženirji razvojne skupine nimajo ali imajo zelo omejen dostop do gradnje gostiteljev; ni načina za hitro upravljanje nabora komponent za gradnjo aplikacije na teh gostiteljih, na primer namestitev dodatnega nabora orodij ali delovne obremenitve za Visual Studio. Zato smo se odločili, da vse potrebne komponente za gradnjo aplikacije namestimo v gradbeno sliko Docker. Po potrebi lahko hitro spremenite samo datoteko docker in zaženete cevovod za ustvarjanje te slike.

Od teorije k akciji

V idealni večstopenjski gradnji slike Docker je okolje za gradnjo aplikacije pripravljeno v istem skriptu Dockerfile, kot je zgrajena sama aplikacija. Toda v našem primeru je bil dodan vmesni člen, in sicer korak predhodne izdelave docker slike z vsem, kar je potrebno za izdelavo aplikacije. To je bilo storjeno, ker sem želel uporabiti funkcijo predpomnilnika dockerja za skrajšanje časa namestitve vseh odvisnosti.

Oglejmo si glavne točke skripta dockerfile za ustvarjanje te slike.

Če želite ustvariti slike različnih različic operacijskega sistema, lahko v datoteki docker definirate argument, skozi katerega se med gradnjo posreduje številka različice, in je tudi oznaka osnovne slike.

Najdete lahko celoten seznam slikovnih oznak Microsoft Windows Server tukaj.

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

Privzeti ukazi v navodilih RUN znotraj datoteke docker v OS Windows se izvajajo v konzoli cmd.exe. Za udobje pisanja skriptov in razširitev funkcionalnosti uporabljenih ukazov bomo na novo definirali konzolo za izvajanje ukazov v programu Powershell z navodili SHELL.

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

Naslednji korak je namestitev upravitelja čokoladnih paketov in potrebnih paketov:

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'

Če želite namestiti pakete z uporabo chocolatey, jih lahko preprosto posredujete kot seznam ali pa namestite enega za drugim, če morate posredovati edinstvene parametre za vsak paket. V naši situaciji smo uporabili datoteko manifesta v formatu XML, ki vsebuje seznam zahtevanih paketov in njihovih parametrov. Njegova vsebina je videti takole:

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

Nato namestimo okolje za gradnjo aplikacije, in sicer MS Build Tools 2019 - to je lahka različica Visual Studio 2019, ki vsebuje minimalni zahtevani nabor komponent za prevajanje kode.
Za popolno delo z našim projektom C++ bomo potrebovali dodatne komponente, in sicer:

  • Delovna obremenitev orodij C++
  • Komplet orodij v141
  • SDK za Windows 10 (10.0.17134.0)

Razširjen nabor orodij lahko samodejno namestite s konfiguracijsko datoteko v formatu JSON. Vsebina konfiguracijske datoteke:

Celoten seznam razpoložljivih komponent je na voljo na dokumentacijskem mestu 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"
  ]
}

Dockerfile zažene namestitveni skript in za udobje doda pot do izvedljivih datotek orodij za gradnjo v spremenljivko okolja PATH. Priporočljivo je tudi, da odstranite nepotrebne datoteke in imenike, da zmanjšate velikost slike.

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)

Na tej stopnji je naša slika za prevajanje aplikacije C++ pripravljena in lahko nadaljujemo neposredno z ustvarjanjem docker večstopenjske gradnje aplikacije.

Večstopenjsko delovanje

Ustvarjeno sliko bomo uporabili z vsemi orodji na krovu kot gradbeno sliko. Kot v prejšnjem skriptu dockerfile bomo dodali možnost dinamičnega določanja številke različice/oznake slike za lažjo ponovno uporabo kode. Pomembno je dodati oznako as builder na sliko sestavljanja v navodilih FROM.

ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builder

Zdaj je čas za izdelavo aplikacije. Tukaj je vse precej preprosto: kopirajte izvorno kodo in vse, kar je povezano z njo, in zaženite postopek prevajanja.

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

Zadnja faza ustvarjanja končne slike je določitev osnovne slike aplikacije, kjer se bodo nahajali vsi artefakti kompilacije in konfiguracijske datoteke. Če želite kopirati prevedene datoteke iz slike vmesnega sestava, morate podati parameter --from=builder v navodilih COPY.

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

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

Zdaj ostane le še, da dodamo potrebne odvisnosti za delovanje naše aplikacije in v navodilih določimo ukaz za zagon ENTRYPOINT ali CMD.

Zaključek

V tem članku sem govoril o tem, kako ustvariti polno kompilacijsko okolje za aplikacije C++ znotraj vsebnika v sistemu Windows in kako uporabiti zmogljivosti večstopenjskih gradenj dockerja za ustvarjanje popolnih slik naše aplikacije.

Vir: www.habr.com

Dodaj komentar