Riot Games

i denne første tutorial i Docker-serien lærer du:

• hvad vi forsøger at opnå på Riot

• grundlæggende opsætning til Docker

• grundlæggende Docker Pull kommandoer

• Sådan køres Docker-containere som dæmoner

• grundlæggende Jenkins konfigurationsindstillinger

da jeg først begyndte at lære om Docker for et år siden og udforske brugen af det, havde jeg problemer med at finde god dokumentation og eksempler – selv i dag beskriver mange enkle brugssager, der i sidste ende ikke er produktionsklare. Produktion af applikationer med Docker-containere kræver tilpasning til deres flygtige karakter og fokus på en enkelt proces. Dette giver udfordringer for applikationer med data persistens behov eller multi-proces arkitekturer.

som jeg nævnte i mit sidste indlæg, bruger vi Jenkins som et grundlæggende stykke open source-program, hvorpå vi bygger vores automatisering. Jenkins er også en fantastisk applikation til at demonstrere en måde at tænke på at “Dockerisere” dine applikationer. Vi implementerer Jenkins med disse arkitektoniske komponenter i tankerne:

• Jenkins master server (Java-proces)

• Jenkins stamdata (Plugins, Jobdefinitioner osv)

• vi bruger SSL certs osv., med NGINK er et nemt valg her)

• Byg slaveagenter (maskiner, der enten er SSH ‘ d i, eller JNLP forbinder til, Jenkins Master)

dette er et godt sted at starte. I løbet af denne serie af blogindlæg vil jeg dække måder at tænke på alt det ovenstående som containere og afslutte med et avanceret kig på måder at bruge Docker-containere som byg slaver. Til at begynde med opretter vi en Jenkins master-server i en Docker-container. Så vil vi gå videre til at håndtere data persistens og tilføje en internet fuldmægtig med .

hele denne blog serie vil dække følgende Docker begreber:

• gør dine egne Dockerfiles

• minimering af billedafhængigheder på offentlige billeder

• oprettelse og brug af datamængder, herunder sikkerhedskopier

• oprettelse af containeriserede “Byg miljøer” ved hjælp af containere

• håndtering af “hemmelige” data med billeder og Jenkins

hvis du ikke har kigget på Cloudbees Jenkins Docker-billedet, skal du starte der, da det virkelig er ret godt. Dette var mit referencepunkt, da jeg først tænkte på at køre Jenkins i en Docker-container, og for mange mennesker kan dette være tilstrækkeligt. Du kan finde deres dokumentation her og deres Git repo/Dockerfile her.

denne første blog er opdelt i to lektionsplaner. Hver er dimensioneret til at tage omkring 30 minutter at fuldføre. Først op, første del er at få dit udviklingsmiljø klar og lære at arbejde med standard Jenkins Docker container, Cloudbees tilbyder. Del to handler om at lægge grunden til at pakke dette billede i din egen Dockerfile og tage mere elegant kontrol over billedet. Sammen er de designet til at komme i gang, især hvis du aldrig har arbejdet med Docker før eller er relativt ny hos Docker—selvom de antager, at du allerede ved og forstår, hvordan du arbejder med Jenkins. Hvis du har erfaring med Docker, vil noget af materialet i Lektion 1 være lidt af et opkog af ting, du sikkert allerede ved.

Lektion 1: Opsæt og kør dit første billede

lad os få dig klar til at rulle. Her hos Riot arbejder vi med Docker (og Jenkins) på . Jeg foretrækker at arbejde med Docker, selvom det er perfekt funktionelt på vinduer siden Docker 1.6. Disse dage er der fremragende installatører til begge operativsystemer. Jeg vil arbejde ud fra et OSK-perspektiv, men de samme værktøjer findes for vinduer.

FORUDKRAV:

1. Du skal bruge Vinduer 10 Pro eller Mac Yosemite 10.10.3 (eller nyere)

2. Hvis du bruger vinduer, skal du sørge for, at du har vinduer virtualisering aktiveret (se dokumentationen Docker giver)

en hurtig NOTE om KITEMATIC

med Docker 1.8 og frigivelsen af Docker værktøjskasse, Docker indeholder nu “Kitematic”, et smukt GUI-værktøj til at hjælpe med at styre og visualisere, hvad der sker med dine Docker-billeder og containere. Det meste af denne tutorial fokuserer på at bruge kommandolinjeargumenter og arbejde med Docker uden den Kitematiske GUI. Dette er for bedre at udsætte dig for de underliggende mekanismer. På samme måde begynder jeg i senere blogs at dække brugen af Compose til at starte og stoppe flere containere på en gang.

TRIN 1: INSTALLER DOCKER

1. Gå til: https://www.docker.com/docker-mac eller https://www.docker.com/docker-windows

2. Hent og installer den relevante version af Docker til dit operativsystem

3. Følg alle installationsinstruktioner.

4. Kontroller, at din installation fungerer ved at åbne den anbefalede skal til dit operativsystem (Terminal til os) ved at køre “Docker-Hurtigstart-Terminal”. På vinduer vil dette være en genvej på dit skrivebord. Du finder den i mappen applications/Docker. Kontroller følgende kommandoer, og sørg for, at du ikke får nogen fejl

docker ps

docker info

5. Før vi gør noget andet, skal vi øge standardhukommelsen og CPU-indstillingerne, som Docker bruger. Senere skal vi indstille Jenkins til at bruge mere hukommelse, og hvis vi ikke justerer disse indstillinger først, kan Jenkins gå ned.

• gå til din Docker-kontrol i din værktøjslinje, og vælg “Indstillinger”

• gå til fanen Avanceret konfiguration

• Forøg CPU-forbruget til mindst 4 kerner

6. Forøg hukommelsesforbruget til mindst 8 GB, helst mere, noget som 12 GB for at være sikkert (hvis du har det tilgængeligt)

trin 2: Træk og kør CLOUDBEES JENKINS-beholderen

1. Bliv i dit Docker terminal vindue.

2. Træk Jenkins fra den offentlige repo ved at køre:

docker pull jenkins/jenkins

docker run -p 8080:8080 --name=jenkins-master jenkins/jenkins

3. Bemærk, at meddelelsen” Jenkins initial setup ” i dit shell-vindue genererer en adgangskode til dig. Skriv det ned, som du har brug for det senere. Hvis du mister det, kan du køre `docker eksekutor jenkins-master cat /var/jenkins_home/secrets/initialadminadgangskode` med din container kører for at hente den.

4. Åbn din foretrukne bro. ser og peg den på http://localhost:8080

Bemærk venligst, Du vil se, at jeg bruger Docker-navn flag og navngiv containeren jenkins – master-dette er en konvention, jeg vil bruge i hele denne blog. Navngivning af dine containere er en praktisk bedste praksis med tre fordele:

1. Det gør dem nemme at huske og interagere med

2. Docker tillader ikke to containere at have samme navn, hvilket forhindrer fejl som ved et uheld at starte to identiske

3. Mange almindelige Docker-værktøjer (som Docker Compose) bruger specifikke containernavne, så det er en god bedste praksis at vænne sig til at navngive dine containere.

trin 3: gør dette lidt mere praktisk

det forrige trin starter Jenkins med sine mest basale opstartsindstillinger. Du kan endda se, at Jenkins har brug for grundlæggende konfiguration og beder dig om en administratoradgangskode (som du kan få fra de logfiler, der vises på skærmen under opstart). Hvis du er som Riot, er det usandsynligt, at du kører Jenkins på standardindstillinger. Lad os gå gennem at tilføje nogle nyttige muligheder. Vi gider ikke konfigurere Jenkins endnu; det er nok at vide, at det kan starte og køre.

trin 3a: DAEMONISERING

du vil sandsynligvis ikke se Jenkins logs spy til standard ud det meste af tiden. Så brug Docker daemon flag til at starte beholderen (- d).

1. Ctrl-c i terminalvinduet, der kører din container for at stoppe den

2. Kør følgende kommandoer

docker rm jenkins-master

docker run -p 8080:8080 --name=jenkins-master -d jenkins/jenkins

nu skal du bare få en hashstreng vist og returneres til din terminal. Hvis du er ny hos Docker, er den hashstreng faktisk det unikke ID for din container (nyttigt, hvis du begynder at automatisere disse kommandoer).

trin 3B: hukommelsesindstillinger

vi har tendens til at køre Jenkins med nogle kødfulde indstillinger på Riot. Husk, når du øget CPU / hukommelse Docker bruger tidligere? Dette er den primære årsag til hvorfor. For en grundlæggende start skal du køre følgende kommandoer

docker stop jenkins-master

docker rm jenkins-master

docker run -p 8080:8080 --name=jenkins-master -d --env JAVA_OPTS="-Xmx8192m" jenkins/jenkins

det skulle give Jenkins en dejlig 8 GB hukommelsespool og plads til at håndtere affaldssamling.

trin 3c: forøgelse af FORBINDELSESPULJEN

hos Riot får vi meget trafik til vores Jenkins-server, så vi har lært at give Jenkins lidt mere åndedrætsrum. Kør følgende

docker stop jenkins-master

docker rm jenkins-master

det vil give Jenkins en god base pulje af handlere og en hætte. Tilfældigt har du nu lært, hvordan du bruger både JAVA OPTS og JENKINS OPTS som miljøvariabler på en meningsfuld måde. Bemærk, Dette fungerer på grund af, hvordan Cloudbees bekvemt strukturerede deres Jenkins Dockerfile.

trin 4: at sætte det hele sammen

jeg lagde alt, hvad vi lærte her, i en simpel makefile, så du kan bruge make-kommandoer til at kontrollere, at du kører din Jenkins docker-container. Du kan finde det her:

• https://github.com/maxfields2000/docker Jenkins_tutorial / træ / master / tutorial_01

du kan bruge følgende kommandoer:

• gør build-trækker Jenkins billede

• gør run-kører beholderen

• gør stop-stopper beholderen

• gør rent-stopper og sletter den eksisterende beholder

du behøver ikke bruge makefilen, jeg finder det bare lettere end at skrive hele kommandoen Kør. Du kan nemt sætte disse i et script efter eget valg i stedet.

forhåbentlig ser du, hvor nemt det er at komme i gang med Docker og Jenkins. Jeg har forsøgt at give dig nogle grundlæggende muligheder for at tage standard Cloudbees Jenkins container og gøre det lidt mere brugbart. Cloudbees har mange nyttige tutorials til at køre deres container, såsom hvordan man forudinstallerer plugins og gemmer Jenkins-data.

det bringer mig til fremtidige indlæg om emnet. Denne container / billede er nyttigt, men har et par ulemper: ingen konsekvent logning, ingen vedholdenhed, ingen server fuldmagt foran det, og ingen ren måde at garantere du bruger den version af Jenkins, du ønsker. Dette rejser spørgsmål som: Hvad hvis du vil holde dig til en ældre version? Eller hvad hvis du vil bruge den seneste tilgængelige udgivelsesperiode?

i den næste lektion vil jeg dække at gøre denne beholder lidt mere robust. Navnlig:

• oprettelse af din egen Dockerfile for at pakke Cloudbees-basen

• flytter nogle af miljøvariablerne ind i dette nye billede

• oprettelse af en logmappe, indstilling af tilladelser og andre nyttige Jenkins-mapper og hentning af Jenkins-logfilerne, mens den kører

Lektion 2-en JENKINS BASE BILLEDINDPAKNING

i den foregående lektion diskuterede jeg oprettelse af et udviklingsmiljø til at køre Docker og eksperimenterede med Jenkins Docker-billedet leveret af Cloudbees. Vi fandt ud af, at det var enkelt og let at bruge, med nogle fantastiske funktioner ud af kassen. For at gøre fremskridt inden for de forbedringsområder, vi identificerede, er Docker-koncepterne, der er dækket af denne lektion:

• gør din egen Dockerfile

• Indstilling af miljøvariabler i en Dockerfil

• oprettelse af mapper og tilladelser i en Dockerfil

• brug af docker til at køre kommandoer mod en kørende container

gør din BASE DOCKERFILE

vi ønsker at foretage nogle ændringer i, hvordan Jenkins starter som standard. I den sidste blog håndterede vi dette ved at oprette en makefile, der passerede i argumenter som miljøvariabler. I betragtning af at vi vil gøre dette hver gang, kan vi bare flytte dem ind i vores egen Dockerfile. Derudover vil vores egen Dockerfile lade os låse den version af Jenkins, vi bruger, hvis Cloudbees opdaterer deres, og vi er ikke klar til at opgradere.

vi gør dette i fire trin:

1. Opret en arbejdsmappe

2. I din foretrukne teksteditor skal du oprette en ny fil kaldet “Dockerfile”

3. Tilføj følgende til filen og gem den:

FROM jenkins/jenkins:2.112LABEL maintainer=""

4. Indtast derefter kommandolinjen:

docker build -t myjenkins .

hvad vi gjorde her var at trække en bestemt version af Jenkins-billedet fra den offentlige docker repo. Du finder alle de tilgængelige versioner her:

• du kan altid indstille fra-klausulen til at være den version af billedet, der er tilgængelig. Du kan dog ikke bare indstille versionen til den version af Jenkins, du ønsker. Dette er billedversionen” tag “eller” label”, og Cloudbees er rart nok til at få det til at matche Jenkins-versionen inde i billedet. Cloudbees tilbyder ” jenkins / jenkins “som en bekvem måde at få den nyeste version på, eller” jenkins/jenkins:lts “for at få den seneste” langsigtede Support ” – version. I dette eksempel bruger jeg en bestemt version. Disse tags, der mærker typer udgivelser, er gode, men at bruge dem betyder, at versionen af Jenkins kan ændre sig under dig, hvilket kan forårsage komplikationer, hvis du ikke var klar til at opgradere. Jeg anbefaler “versionslåsning” som en generel bedste praksis, når man beskæftiger sig med afhængigheder i Docker eller andre afhængighedsstyringsværktøjer. Du vil have tingene til at ændre sig, når du har til hensigt dem, ikke før. Derfor bruger jeg en bestemt version her.

  test af den nye DOCKERFILE

  vi kan skifte til billedet meget let ved at ændre vores docker run-kommando til følgende:

  docker run -p 8080:8080 --name=jenkins-master -d --env JAVA_OPTS="-Xmx8192m" --env JENKINS_OPTS=" --handlerCountMax=300" myjenkins

  nu kan vi rydde op i disse miljøvariabler ved at placere dem i vores egen Dockerfile.

  tilføjelse af miljøvariabler til vores DOCKERFILE

  det er nemt at tilføje standardindstillinger for ting som miljøvariabler til Dockerfiles. Dette giver også et godt stykke selvdokumentation. Og fordi du altid kan overskrive disse, når du kører Docker-containeren, er der virkelig ingen ulempe.

  1. I din Dockerfile tilføj følgende linjer efter linjen “vedligeholder” :

  ENV JAVA_OPTS="-Xmx8192m"ENV JENKINS_OPTS=" --handlerCountMax=300"

  2. Gem og genopbyg dit billede:

  • docker bygge-t myjenkins .

  docker build -t myjenkins .

  ret simpelt! Du kan teste, at det stadig fungerer ved at indtaste følgende tre kommandoer:

  docker stop jenkins-master

  docker rm jenkins-master

  docker run -p 8080:8080 --name=jenkins-master -d myjenkins

  

  dit billede skal starte helt op! Men hvordan ved du, at miljøvariablerne fungerede? Simpel: på samme måde ville du kontrollere for at se, hvilke argumenter der startede din Jenkins-app normalt ved hjælp af ps. Og det virker, selvom du udvikler på vinduer.

  kører en grundlæggende kommando mod din CONTAINER

  for at bekræfte, at Java-og Jenkins-indstillingerne er indstillet korrekt, kan vi køre ps i vores container og se den kørende Jenkins Java-proces ved hjælp af docker-eksekvering

  docker exec jenkins-master ps -ef | grep java

  du skal se noget, der ligner dette kom tilbage

  jenkins 1 0 99 21:28 ? 00:00:35 java -Xmx8192m -jar /usr/share/jenkins/jenkins.war --handlerCountMax=300

  

  fra dette kan du nemt se, at vores indstillinger sidder fast. docker er en enkel måde at udføre shell kommandoer inde i din container og også en utrolig enkel måde at inspicere dem. Dette fungerer endda på vinduer, fordi, husk, kommandoen efter” eksekvering ” køres inde i din container og er således baseret på det basisbillede, din container bruger.

  opsætning af en LOGMAPPE

  i den forrige blog bemærkede vi, at vi mistede synligheden i Jenkins-logfilerne, når vi kørte vores container med dæmoniseringsflagget (- d). Vi vil bruge den indbyggede Jenkins-funktion til at indstille en logmappe. Vi bliver nødt til at gøre dette i Vores Dockerfile og derefter videregive logging-indstillingen til Jenkins.

  lad os redigere vores Dockerfile igen. Mellem “vedligeholder” og første ENV-linje vil vi tilføje følgende

  RUN mkdir /var/log/jenkins

  vi placerer kommandoen på dette sted i filen for at følge bedste praksis. Det er mere sandsynligt, at vi vil ændre miljøvariablerne end disse opsætningsmapper, og hver kommandolinje i en Dockerfile bliver i det væsentlige sit eget billedlag. Du maksimerer genbrug af lag ved at placere ofte ændrede genstande nær bunden.

  byg nu dit billede igen:

  docker build -t myjenkins

  du får en fejl, der ligner

  ---> Running in 0b5ac2bce13bmkdir: cannot create directory '/var/log/jenkins': Permission denied

  

  bare rolig. Dette skyldes, at standard Cloudbees-containeren indstiller den kørende bruger til” Jenkins ” – brugeren. Hvis du ser på deres Dockerfile (findes her: https://github.com/ Jenkinsci/docker/blob/master/Dockerfile), skal du se, nær bunden

  USER ${user}

  denne syntaks kan være lidt forvirrende. Det bruger Dockers build” argumenter ” for at give dig mulighed for at definere brugeren. Hvis du kigger længere op i Docker-filen, finder du standardværdien. Se tæt på toppen af Dockerfile for

  ARG user=jenkins

  dette skaber argumentet “bruger” (ARG) og indstiller det til Jenkins-brugeren. Dette giver dig mulighed for at ændre det brugernavn, som Jenkins bruger, når du ringer til docker build-build-arg somevariable=somevalue. Bemærk, at dette kun fungerer, hvis du bygger Dockerfilen fra bunden. Du kan ikke ændre disse værdier med en Docker pull eller en docker run. Du kan læse mere om build argumenter her. Fordi vi bruger en forudbygget version i vores FROM-klausul, ender vi med standardbrugeren: “jenkins”.

  i normal linje bruger du bare SUDO eller andre midler til at oprette mappen (/var/log ejes af root). Heldigvis for os Docker lader os skifte brugere.

  Føj følgende til din Dockerfile:

  1. Før din køre mkdir linje tilføje

  USER root

  2. Efter din køre mkdir linje tilføje

  RUN chown -R jenkins:jenkins /var/log/jenkins

  3. Efter dit løb Tilføj linje:

  USER jenkins

  Bemærk, at vi også måtte tilføje en kommando, fordi vi ønsker, at Jenkins-brugeren skal kunne skrive til mappen. Dernæst sætter vi rod og nulstiller derefter Jenkins, så Dockerfilens opførsel bevares.

  byg nu dit billede igen:

  docker build -t myjenkins .

  

  og… dine fejl skal være væk.

  med logmappesættet (Bemærk: Du kan placere denne mappe, hvor du vil, vi bruger /var/log for konsistens) kan vi nu bede Jenkins om at skrive til den mappe ved opstart ved at ændre jenkins_opts miljøvariabler.

  i din Dockerfile Rediger jenkins_opts-linjen for at se sådan ud:

  • ENV JENKINS_OPTS= ” –handlercountmaks=300 — logfil=/var/log/jenkins/jenkins.log”

  ENV JENKINS_OPTS="--handlerCountMax=300 --logfile=/var/log/jenkins/jenkins.log"

  byg nu dit billede endnu en gang

  docker build -t myjenkins .

  lad os teste vores nye billede, og hvis vi kan hale logfilen! Prøv følgende kommandoer

  docker stop jenkins-master

  docker rm jenkins-master

  docker run -p 8080:8080 --name=jenkins-master -d myjenkins

  når containeren kører, kan vi hale logfilen, hvis alt fungerede

  docker exec jenkins-master tail -f /var/log/jenkins/jenkins.log

  Hent logfiler, hvis JENKINS går ned

  tid til en bonusrunde! Så længe vi diskuterer logfiler, Docker præsenterer et interessant problem, hvis Jenkins går ned. Containeren stopper med at køre, og docker-udførelsen fungerer ikke længere. Så hvad skal man gøre?

  vi diskuterer mere avancerede måder at fortsætte logfilen på senere. For nu, fordi beholderen er stoppet, kan vi kopiere filer ud af den ved hjælp af kommandoen docker cp. Lad os simulere et nedbrud ved at stoppe beholderen og derefter hente logfilerne:

  1. ctrl-c for at afslutte logfilens hale

  2. Kør følgende kommandoer

  docker stop jenkins-master

  docker cp jenkins-master:/var/log/jenkins/jenkins.log jenkins.log

  cat jenkins.log

  

  afsluttende tanker

  du kan finde alt arbejdet i min tutorial Git repo (og den opdaterede bekvemmelighed makefile) her:

  • https://github.com/maxfields2000/docker Jenkins_tutorial / træ / master / tutorial_02

  ved at lave vores egen Dockerfile, der ombryder Cloudbees-filen, var vi i stand til at gøre livet lidt lettere for os selv. Vi oprettede et praktisk sted at gemme logfilerne og lærte at se på dem med docker-eksekveringskommandoen. Vi flyttede vores standardindstillinger til Dockerfile, og nu kan vi gemme dette i kildekontrol som et godt stykke selvdokumentation.

  vi har stadig en data persistens udfordring. Vi har lært, hvordan man trækker logfiler ud af en stoppet container (praktisk, når Jenkins går ned). Men generelt, hvis vores container stopper, mister vi stadig alle de job, vi skabte. Så uden vedholdenhed er dette Jenkins-billede kun nyttigt til lokal udvikling og test.

  det fører os til den næste artikel. Med vores fundamenter på plads – vores egen Dockerfilindpakning, låst til en praktisk version af Jenkins – kan vi løse vedholdenhedsproblemet. Den næste artikel vil undersøge disse begreber:

  • bevare Jenkins Job og Plugin data

  • Docker Data persistens med mængder

  • fremstilling af en Data-volumen container

  • deling af data i mængder med andre containere

  for mere information, tjek resten af denne serie:

  Del I: tænker inde i beholderen
  Del II: sætte Jenkins i en Docker Container (denne artikel)
  Del III: Docker & Jenkins: Data, der vedvarer
  Del IV: Jenkins, Docker, fuldmagter og komponere
  Del V: Tager kontrol over din Docker billede
  Del VI: bygning med Jenkins inde i en flygtig Docker Container
  del VII: Tutorial: bygning med Jenkins inde i en flygtig Docker Container
  del VIII: DockerCon Talk og historien hidtil