Sziasztok! Andrey vagyok, és DevOps mérnökként dolgozom az Exness fejlesztőcsapatában. Fő feladatom az operációs rendszeren futó Docker alkalmazások fejlesztése, telepítése és karbantartása. Linux (a továbbiakban OS). Nemrég volt egy feladatom ugyanazokkal a tevékenységekkel, de a projekt cél OS-e lett Windows Server és egy sor C++ projektet. Számomra ez volt az első szoros interakció Docker konténerekkel operációs rendszer alatt. Windows és általában a C++ alkalmazásokról. Ez érdekes tapasztalatot adott nekem, és megtanított az operációs rendszerben az alkalmazások konténerizálásának néhány bonyolultságára. Windows.
Ebben a cikkben szeretném elmondani, milyen nehézségekkel kellett szembenéznem, és hogyan sikerült megoldanom azokat. Remélem, hogy ez hasznos lesz a jelenlegi és jövőbeli kihívásaiban. Élvezd az olvasást!
Miért konténerek?
A vállalat rendelkezik a Hashicorp Nomad konténer-vezérlő és a kapcsolódó komponensek – Consul és Vault – meglévő infrastruktúrájával. Ezért az alkalmazáskonténerizálást választották egységes módszerként a kész megoldás leszállításához. Mivel a projekt infrastruktúrája Docker hosztokat tartalmaz operációs rendszer verziókkal Windows Server Ha Core 1803-as és 1809-es verziót használ, akkor külön Docker-képverziókat kell létrehoznia a 1803-as és 1809-es verziókhoz. A 1803-as verzióban fontos megjegyezni, hogy a Docker build hoszt verziószámának meg kell egyeznie az alap Docker-kép és a hoszt verziószámával, amelyen a képből származó konténer elindul. A 1809-es verzió kiküszöböli ezt a problémát. További információ erről itt olvasható. .
Miért többlépcsős?
A fejlesztőcsapat mérnökei nem vagy csak nagyon korlátozottan férnek hozzá a gazdagépek létrehozásához; nincs mód arra, hogy gyorsan felügyeljék az alkalmazást ezeken a gazdagépeken az összetevőkészletet, például további eszközkészletet vagy munkaterhelést telepítsenek a Visual Studio számára. Ezért úgy döntöttünk, hogy az alkalmazás építéséhez szükséges összes összetevőt telepítjük a Buil Docker lemezképbe. Ha szükséges, gyorsan módosíthatja csak a dockerfájlt, és elindíthatja a folyamatot a kép létrehozásához.
Az elmélettől a cselekvésig
Egy ideális Docker többlépcsős képfelépítésben az alkalmazás létrehozásának környezete ugyanabban a Dockerfile-szkriptben készül, mint maga az alkalmazás. De a mi esetünkben egy köztes hivatkozás került hozzáadásra, nevezetesen az a lépés, hogy előzetesen létrehozunk egy docker-képet, amelyben minden szükséges az alkalmazás elkészítéséhez. Erre azért került sor, mert a docker gyorsítótár funkcióját akartam használni az összes függőség telepítési idejének csökkentésére.
Nézzük meg a dockerfile szkript főbb pontjait a kép létrehozásához.
Különböző operációs rendszer-verziók képeinek létrehozásához a dockerfájlban megadhat egy argumentumot, amelyen keresztül a verziószám átkerül az összeállítás során, és ez egyben az alapkép címkéje is.
A Microsoft képcímkék teljes listája Windows Server megtalálja .
ARG WINDOWS_OS_VERSION=1809
FROM mcr.microsoft.com/windows/servercore:$WINDOWS_OS_VERSIONAlapértelmezés szerint az utasításokban szereplő parancsok RUN az operációs rendszer dockerfile-jában Windows a cmd.exe konzolon futnak. A szkriptírás megkönnyítése és a használt parancsok kibővített funkcionalitása érdekében a parancsfuttató konzolt Powershellre fogjuk átdefiniálni a következő utasítással: SHELL.
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"]A következő lépés a csokis csomagkezelő és a szükséges csomagok telepítése:
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'A csokoládé csomagok telepítéséhez egyszerűen átadhatja őket listaként, vagy egyenként telepítheti őket, ha minden csomaghoz egyedi paramétereket kell átadnia. A mi helyzetünkben egy XML formátumú manifest fájlt használtunk, amely tartalmazza a szükséges csomagok listáját és azok paramétereit. A tartalma így néz ki:
<?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>Ezután telepítjük az alkalmazásépítési környezetet, nevezetesen az MS Build Tools 2019-et - ez a Visual Studio 2019 könnyű verziója, amely tartalmazza a kódfordításhoz szükséges minimális összetevőkészletet.
A C++ projektünk teljes körű használatához további összetevőkre lesz szükségünk, nevezetesen:
- Munkaterhelés C++ eszközök
- Eszközkészlet v141
- Windows 10 SDK (10.0.17134.0)
Az eszközök bővített készletét automatikusan telepítheti egy JSON formátumú konfigurációs fájl használatával. A konfigurációs fájl tartalma:
Az elérhető összetevők teljes listája a dokumentációs oldalon található .
{
"version": "1.0",
"components": [
"Microsoft.Component.MSBuild",
"Microsoft.VisualStudio.Workload.VCTools;includeRecommended",
"Microsoft.VisualStudio.Component.VC.v141.x86.x64",
"Microsoft.VisualStudio.Component.Windows10SDK.17134"
]
}A dockerfile futtatja a telepítő szkriptet, és a kényelem kedvéért hozzáadja a Build Tool futtatható fájlok elérési útját a környezeti változóhoz PATH. A kép méretének csökkentése érdekében a szükségtelen fájlokat és könyvtárakat is célszerű eltávolítani.
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)Ebben a szakaszban elkészült a C++ alkalmazás fordítására szolgáló képünk, és közvetlenül folytathatjuk az alkalmazás többlépcsős docker buildjének létrehozását.
Többlépcsős működés közben
A létrehozott képet a fedélzeten lévő összes eszközzel együtt build képként fogjuk használni. Az előző dockerfile szkripthez hasonlóan a kód újrafelhasználásának megkönnyítése érdekében hozzáadjuk a verziószám/képcímke dinamikus megadásának lehetőségét. Fontos a címke hozzáadása as builder az útmutatóban található összeállítási képre FROM.
ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builderMost itt az ideje az alkalmazás elkészítésének. Itt minden nagyon egyszerű: másolja ki a forráskódot és mindent, ami hozzá tartozik, és indítsa el a fordítási folyamatot.
COPY myapp .
RUN nuget restore myapp.sln ;
msbuild myapp.sln /t:myapp /p:Configuration=ReleaseA végső kép létrehozásának utolsó szakasza az alkalmazás alapképének megadása, ahol az összes összeállítási műtermék és konfigurációs fájl található. A lefordított fájlok közbülső összeállítási lemezképről történő másolásához meg kell adnia a paramétert --from=builder az utasításokban COPY.
FROM mcr.microsoft.com/windows/servercore:$WINDOWS_OS_VERSION
COPY --from=builder C:/x64/Release/myapp/ ./
COPY ./configs ./Most már nincs más hátra, mint hozzáadni az alkalmazásunk működéséhez szükséges függőségeket, és az utasításokon keresztül megadni az indítási parancsot ENTRYPOINT vagy CMD.
Következtetés
Ebben a cikkben kifejtettem, hogyan hozhatok létre teljes értékű fordítási környezetet C++ alkalmazásokhoz egy konténeren belül a következő címen: Windows és hogyan használhatjuk a Docker többlépcsős build képességeit az alkalmazásunk teljes értékű képeinek létrehozásához.
Forrás: will.com
