Paggamit ng docker multi-stage upang bumuo ng mga larawan sa windows

Kamusta kayong lahat! Ang pangalan ko ay Andrey, at nagtatrabaho ako bilang isang DevOps engineer sa Exness sa development team. Ang aking pangunahing aktibidad ay nauugnay sa pagbuo, pag-deploy at pagsuporta sa mga application sa docker sa ilalim ng operating system ng Linux (mula rito ay tinutukoy bilang OS). Hindi pa matagal na ang nakalipas nagkaroon ako ng gawain na may parehong mga aktibidad, ngunit ang target na OS ng proyekto ay Windows Server at isang set ng mga proyektong C++. Para sa akin, ito ang unang malapit na pakikipag-ugnayan sa mga docker container sa ilalim ng Windows OS at, sa pangkalahatan, sa mga C++ na application. Salamat dito, nagkaroon ako ng isang kawili-wiling karanasan at natutunan ko ang tungkol sa ilan sa mga intricacies ng containerizing application sa Windows.

Paggamit ng docker multi-stage upang bumuo ng mga larawan sa windows

Sa artikulong ito gusto kong sabihin sa iyo kung anong mga paghihirap ang kinailangan kong harapin at kung paano ko nalutas ang mga ito. Umaasa ako na ito ay kapaki-pakinabang para sa iyong kasalukuyan at hinaharap na mga hamon. Enjoy reading!

Bakit lalagyan?

Ang kumpanya ay may umiiral na imprastraktura para sa Hashicorp Nomad container orchestrator at mga kaugnay na bahagi - Consul at Vault. Samakatuwid, ang application containerization ay pinili bilang isang pinag-isang paraan para sa paghahatid ng kumpletong solusyon. Dahil ang imprastraktura ng proyekto ay naglalaman ng mga host ng docker na may mga bersyon ng Windows Server Core OS na 1803 at 1809, kinakailangan na bumuo ng mga hiwalay na bersyon ng mga larawan ng docker para sa 1803 at 1809. Sa bersyon 1803, mahalagang tandaan na ang numero ng rebisyon ng build docker host dapat tumugma sa revision number ng base docker image at sa host kung saan ilulunsad ang container mula sa larawang ito. Ang bersyon 1809 ay walang ganoong disbentaha. Maaari mong basahin ang higit pa dito.

Bakit multi-stage?

Ang mga inhinyero ng development team ay walang o napakalimitadong access upang bumuo ng mga host; walang paraan upang mabilis na pamahalaan ang hanay ng mga bahagi para sa pagbuo ng isang application sa mga host na ito, halimbawa, mag-install ng karagdagang toolset o workload para sa Visual Studio. Samakatuwid, ginawa namin ang desisyon na i-install ang lahat ng mga sangkap na kinakailangan upang mabuo ang application sa imahe ng build Docker. Kung kinakailangan, maaari mong mabilis na baguhin ang dockerfile lamang at ilunsad ang pipeline para sa paglikha ng larawang ito.

Mula sa teorya hanggang sa aksyon

Sa isang perpektong Docker multi-stage image build, ang kapaligiran para sa pagbuo ng application ay inihanda sa parehong Dockerfile script bilang ang application mismo ay binuo. Ngunit sa aming kaso, ang isang intermediate na link ay idinagdag, ibig sabihin, ang hakbang ng paunang paglikha ng isang docker na imahe kasama ang lahat ng kailangan upang mabuo ang application. Ginawa ito dahil gusto kong gamitin ang tampok na docker cache upang bawasan ang oras ng pag-install ng lahat ng dependencies.

Tingnan natin ang mga pangunahing punto ng dockerfile script para sa paglikha ng larawang ito.

Upang lumikha ng mga larawan ng iba't ibang mga bersyon ng OS, maaari mong tukuyin ang isang argumento sa dockerfile kung saan ipinapasa ang numero ng bersyon sa panahon ng pagbuo, at ito rin ang tag ng batayang larawan.

Ang isang kumpletong listahan ng mga tag ng imahe ng Microsoft Windows Server ay matatagpuan dito.

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

Bilang default, ang mga utos sa mga tagubilin RUN sa loob ng dockerfile sa Windows OS sila ay pinaandar sa cmd.exe console. Para sa kaginhawahan ng pagsusulat ng mga script at pagpapalawak ng functionality ng mga command na ginamit, muling tutukuyin namin ang command execution console sa Powershell sa pamamagitan ng pagtuturo. SHELL.

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

Ang susunod na hakbang ay i-install ang chocolatey package manager at ang mga kinakailangang package:

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'

Upang mag-install ng mga pakete gamit ang chocolatey, maaari mo lamang ipasa ang mga ito bilang isang listahan, o i-install ang mga ito nang paisa-isa kung kailangan mong ipasa ang mga natatanging parameter para sa bawat pakete. Sa aming sitwasyon, gumamit kami ng isang manifest file sa XML na format, na naglalaman ng isang listahan ng mga kinakailangang pakete at ang kanilang mga parameter. Ang mga nilalaman nito ay ganito ang hitsura:

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

Susunod, ini-install namin ang application build environment, ibig sabihin, MS Build Tools 2019 - ito ay isang magaan na bersyon ng Visual Studio 2019, na naglalaman ng minimum na kinakailangang hanay ng mga bahagi para sa pag-compile ng code.
Upang ganap na gumana sa aming proyekto sa C++, kakailanganin namin ng mga karagdagang bahagi, katulad ng:

  • Mga tool sa Workload C++
  • Toolset v141
  • Windows 10 SDK (10.0.17134.0)

Maaari kang awtomatikong mag-install ng pinahabang hanay ng mga tool gamit ang configuration file sa JSON na format. Mga nilalaman ng file ng configuration:

Ang isang kumpletong listahan ng mga magagamit na bahagi ay matatagpuan sa site ng dokumentasyon 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"
  ]
}

Pinapatakbo ng dockerfile ang script ng pag-install, at para sa kaginhawahan, idinaragdag ang path sa mga build tool na maipapatupad na mga file sa variable ng kapaligiran PATH. Maipapayo rin na tanggalin ang mga hindi kinakailangang file at direktoryo upang mabawasan ang laki ng imahe.

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)

Sa yugtong ito, handa na ang aming imahe para sa pag-compile ng C++ application, at maaari kaming magpatuloy nang direkta sa paggawa ng docker multi-stage build ng application.

Multi-stage sa pagkilos

Gagamitin namin ang nilikha na imahe kasama ang lahat ng mga tool sa board bilang isang build na imahe. Tulad ng sa nakaraang dockerfile script, magdaragdag kami ng kakayahang dynamic na tukuyin ang numero ng bersyon/tag ng larawan para sa kadalian ng muling paggamit ng code. Mahalagang magdagdag ng label as builder sa imahe ng pagpupulong sa mga tagubilin FROM.

ARG WINDOWS_OS_VERSION=1809
FROM buildtools:$WINDOWS_OS_VERSION as builder

Ngayon ay oras na upang buuin ang application. Ang lahat dito ay medyo simple: kopyahin ang source code at lahat ng nauugnay dito, at simulan ang proseso ng compilation.

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

Ang huling yugto ng paglikha ng panghuling larawan ay ang tukuyin ang batayang larawan ng application, kung saan matatagpuan ang lahat ng mga artifact ng compilation at configuration file. Upang kopyahin ang mga pinagsama-samang file mula sa intermediate assembly na imahe, dapat mong tukuyin ang parameter --from=builder sa mga tagubilin COPY.

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

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

Ngayon ang natitira na lang ay magdagdag ng mga kinakailangang dependency para gumana ang aming application at tukuyin ang utos ng paglulunsad sa pamamagitan ng mga tagubilin ENTRYPOINT o CMD.

Konklusyon

Sa artikulong ito, pinag-usapan ko kung paano lumikha ng ganap na compilation environment para sa mga C++ na application sa loob ng container sa ilalim ng Windows at kung paano gamitin ang mga kakayahan ng docker multi-stage build upang lumikha ng ganap na mga larawan ng aming application.

Pinagmulan: www.habr.com

Magdagdag ng komento