År etter år vitner vi om den stadig raskere utviklingen i IT-bransjen. Det har nå gått mer enn to tiår siden det banebrytende slagordet 'Skriv en gang, løp hvor som helst' satte et helt nytt nivå av forventning for programvareutviklingssamfunnet. Og her er vi i dag, med et resulterende, stadig utvidende sett med verktøy som samlet har tatt Java utvikling spesielt, og programvareutvikling generelt, til et helt nytt univers av muligheter.

Metoder som Agile, DevOps og kontinuerlig integrering og implementering - sammen med utviklingen av mikrotjenester - har samlet økt produktiviteten til programvareutviklingsprosessen til et punkt der det er en glede å utvikle programvare mer enn noen gang før. Å bruke automatisering og sette opp riktig sett med verktøy kan gjøre utvikling og levering av programvareprodukter overraskende smertefri.

Denne artikkelen vil se på dette nye universet fra perspektivet til a Java-utvikler som går over til DevOps og søker for å optimalisere produktutvikling og levering maksimalt.

I dag er begreper som Spring Boot, Docker, Cloud, Amazon Web Services, kontinuerlig levering mye brukt, men mindre forstått. Denne artikkelen tar den enkleste ruten mulig for å presentere alle disse teknologiene og forklare disse vilkårene, og pakke den opp i form av en veiledning der vi vil utvikle et lite programvare og forberede det for produksjonsleveranse ved hjelp av alle de nevnte verktøyene.

Lei av å håndtere JVM-problemer? Dockerize Java-appen din. kvitring

Hvorfor disse verktøyene?

Forenkle implementeringer med Docker

”Skriv en gang, kjør hvor som helst“ var det konseptuelle gjennombruddet som ga teknologier som Java Virtual Machine (JVM) som gjorde at koden din kunne kjøre hvor som helst. Og nå er vi her, et par tiår senere, med noe som heter Docker blir presentert for IT-samfunnet. Docker er et inneslutningsverktøy der du kan plassere programvaren din og kjøre den smertefritt, nesten hvor som helst.

Imidlertid kan en Java-utvikler se på Docker og si 'Hvorfor trenger vi det, vi har allerede JVM, som er anerkjent som den bærbare bærbare løsningen.' Men er det?

”Skriv en gang, løp hvor som helst” høres fint ut, og spiller bra ... i det minste mesteparten av tiden. Inntil du støter på flere JVM-leverandører, flere Java-versjoner, flere operativsystemer og forskjellige permutasjoner og kombinasjoner av alle de ovennevnte. Du finner deg selv å bytte fra den elegante ”Skriv en gang, løp hvor som helst” paradigme til kontraproduktiv ”Skriv en gang, feilsøke overalt “fallgruve.

Og det er her Docker kommer inn for å redde dagen.

Docker forenkler utvikling, testing og forsendelse av programvare. Hvis du har programvaren du vil teste, legg den i Docker-beholderen, og den vil kjøre og være smertefri å installere for alle involverte parter.

I slekt: Komme i gang med Docker: Forenkle Devops

Fremskynd utvikling med vårstøvel

Mindre enn et tiår etter at slagordet 'løp hvor som helst' ble introdusert, dukket våren opp på scenen. I dag fortsetter vårøkosystemet å blomstre, og har produsert mange verdifulle vårbaserte prosjekter, kanskje spesielt Spring Boot. Som nevnt på Vårstøvel nettside:

Spring Boot gjør det enkelt å lage frittstående, produksjonsklasse vårbaserte applikasjoner som du bare kan kjøre.

Spring Boot lar deg starte applikasjonen i løpet av få minutter. Programvareutviklere kan fokusere på programvareutvikling og kan dra nytte av et verktøy som gjør hele konfigurasjonen for dem.

I denne opplæringen vil vi bruke Spring Boot til å utvikle mikroservicen.

Kontinuerlig integrasjon (CI) med Jenkins

DevOps er en raskt voksende bevegelse som integrerer tett programvareutvikling og systemadministrasjonsteam, med målet å gjøre en programvareutviklings- og leveringssyklus så smertefri, sømløs og produktiv som mulig for alle involverte parter: utviklere, sysadmins, testere og til slutt , sluttbrukere.

Kontinuerlig integrasjon (CI) er en av hjørnesteinene i DevOps-revolusjonen. Tanken er at hver gang en utvikler forplikter kode til kodelageret, blir den automatisk testet og pakket for levering (distribusjon) til produksjon.

CI går hånd i hånd med:

• Kontinuerlig levering - Automatisk levering av pakken forberedt for sluttbrukervirksomhetstesting med manuell utløser til produksjonsutrulling.
• Kontinuerlig distribusjon - Automatisk distribusjon av det pakkede produktet direkte til produksjonen.

Det finnes mer enn noen få verktøy som kan brukes til å implementere CI-prosessen. En av de mest populære er Jenkins, et open source CI-verktøy. Med mer enn tusen plugins og et stort fellesskap bak seg, er Jenkins et enkelt valg når du begynner å tenke på å implementere kontinuerlig integrering, levering eller distribusjon.

I vår opplæring vil Jenkins bli brukt til å levere produktet vårt til skyen, nærmere bestemt Amazon (AWS) skyen.

Cloud Computing med AWS

Hvis du har litt sysadmin-erfaring, kan du forestille deg å fjerne noen av bekymringene for systemadministrasjon fra skuldrene. Du har noen få applikasjoner; du har en ide om hvor mye ressurs de vil kreve, men du vet ikke nøyaktig maskinvarestørrelsen du trenger. Du gjør estimeringen, ressursene er kjøpt, og systemet går til produksjon. Hvis du er heldig, vil du oppdage at du overvurderte og har flere ressurser enn du trenger. Men gitt Murphys lov, vil du mer sannsynlig oppdage at du undervurderte ressurskrav og ender med å kryptere for å få litt mer minne eller prosessorkraft under enormt tidspress. Hvis du derimot distribuerer til skyen, legger du ganske enkelt systemet ditt der ute og størrelse det etter behov, med fleksibiliteten som tilbys av skyleverandørene. Med skyen trenger du verken å bekymre deg for at du går tom for systemressurser, og du trenger heller ikke å bekymre deg for at 90 prosent av minnet eller CPU-en sitter i tomgang.

Selvfølgelig er det utfordringen å bestemme hvilken leverandør du skal velge. Skykrigen pågår fortsatt. Sammenstøt mellom Microsoft, Amazon og Google for fremtiden for databehandling er et eksempel på en tittel du kan finne i det siste i tech-world nyheter. For denne bloggen har jeg valgt Amazon Web Services (AWS), i stor grad basert på den nåværende populariteten og markedsandelen.

En av fordelene med AWS er ​​at Amazon tilbyr mange tjenester etter at du registrerer deg:

I denne opplæringen vil vi bruke følgende to AWS-tjenester: Elastic Compute Cloud EC2 (nærmere bestemt Amazon EC2 Container Registry, eller Amazon ECR) og Amazon S3 (Simple Storage Services).

Amazon ECR

Vi må lagre Docker-bildene våre et sted. Amazon ECR er en administrert AWS Docker-registertjeneste. Som nevnt på Amazon ECR-nettsted :

... gjør det enkelt for utviklere å lagre, administrere og distribuere Docker-containerbilder. Amazon ECR er integrert med Amazon EC2 Container Service (ECS), forenkler utviklingen din til produksjonsarbeidsflyt. Amazon ECR eliminerer behovet for å betjene dine egne containerregister eller bekymre deg for å skalere den underliggende infrastrukturen.

Amazon S3

Som nevnt vil applikasjonen vi utvikler være en Spring Boot-mikrotjeneste som skal laste opp filer til Amazon S3. Som nevnt på Amazon S3-nettsted :

... gir utviklere og IT-team sikker, holdbar og svært skalerbar skylagring. Amazon S3 er enkel å bruke objektlagring, med et enkelt webtjenestegrensesnitt for å lagre og hente datamengder hvor som helst på nettet.

En praktisk 'How To' -veiledning

Målet er å forberede distribusjon av en Spring Boot-mikrotjeneste som vil laste opp filer til Amazon S3. Fremgangsmåten er følgende:

• Utvikle mikroservice
• Definer byggeprosessen der tjenesten skal dockeriseres
• Bruk Bitbucket til å være vert for Git code repository
• Integrer Bitbucket med Jenkins for å pakke applikasjonen ved hjelp av Gradle
• Skyv den til en ekstern Amazon ECR

Det følgende er en veiledning for å sette opp alle nødvendige komponenter:

• Spring Boot eksempel applikasjon - mikroservice pakket og dockerisert ved hjelp av Gradle
• Jenkins-installasjon på en fersk Ubuntu-server
• Bitbucket-integrasjon med Jenkins via webhook
• Jenkins jobbkonfigurasjon
• Amazon ECR for å lagre Docker-bildene som inneholder applikasjonen vår

Forutsetninger

For å kunne bruke AWS skyressurser, må vi registrer deg hos Amazon først. Ved å registrere oss vil vi få en konto hos øyeblikkelig Gratis nivå bruksfordeler, for å muliggjøre praktisk erfaring i løpet av de 12 månedene etter registreringen.

Som nevnt vil vi i denne opplæringen bruke Amazon S3 og Amazon ECR. For begge deler trenger vi tilgangsnøkler for å koble til tjenestene.

Etter å ha registrert deg hos AWS, går vi til kontoen vår Sikkerhetsinformasjon , hvor vi velger Tilgangstaster og klikk på “Opprett ny tilgangsnøkkel”. Etter å ha klikket, genereres en nøkkel sammen med ID-en. Du må lagre dette trygt ettersom vi vil bruke det senere når vi konfigurerer AWS Jenkins-integrering og utvikler S3-filopplasting.

Den neste forutsetningen er at vi trenger en Amazon S3 bøtte (lagringsbeholder). Vårt oppstartsservice vil laste opp og laste ned filer til og fra Amazon S3-lagring. Bøtteoppretting er enkel nok og krever bare få klikk. En fullstendig beskrivelse av hvordan du gjør det er gitt i Lag en Bucket-dokumentasjon .

Vi vil også bruke Bitbucket for å være vert for koden vår og utløse forespørsler til Jenkins, så det er også behov for en Bitbucket-konto. Bitbucket er et flott alternativ for utviklere, og en av hovedfordelene er den ubegrensede mengden private arkiver du kan opprette.

Søknadsutvikling

I stedet for å komme inn på alle detaljene i vårkommentarer og hvordan de fungerer, vil jeg i stedet fokusere, fra et rent utviklerperspektiv, på den mer utfordrende delen av hele oppsettet; nemlig å installere og konfigurere Linux, Jenkins og andre verktøy som trengs for CI. Alle kodeeksemplene som brukes i denne opplæringen, inkludert applikasjonen Spring Boot microservice, er tilgjengelig på Bickbucket repository for prosjektet .

Vår applikasjonssammensetning er enkel. Vi har et startpunkt for Spring Boot-applikasjon i StorageWebserviceApplication.java fil. Logikken for opplasting og nedlasting av filer er i StorageService.java. StorageController.java er en Rest-kontroller, som inneholder API-endepunkter som brukes til filopplasting og nedlasting. Her er prosjekthierarkiet:

Vi har valgt Gradle som et byggeverktøy, og det vil pakke applikasjonen vår og komponere Docker-bildet. Så neste gang vil vi diskutere Gradle-byggefilen, servicekomponenten og Dockerfile.

For å kunne bruke AWS API, må vi inkludere avhengigheter i build-filen vår, som definert i AWS dokumentasjon for bruk av Gradle .

Oppsummert vil AWS-avhengighetskonfigurasjonsdelen av Gradle-skriptet se slik ut:

buildscript { ... repositories { mavenCentral() } dependencies { ... classpath('io.spring.gradle:dependency-management-plugin:0.5.4.RELEASE') } } .. apply plugin: 'io.spring.dependency-management' dependencyManagement { imports { mavenBom ('com.amazonaws:aws-java-sdk-bom:1.10.47') } } dependencies { .. compile ('com.amazonaws:aws-java-sdk-s3') }

Som nevnt tidligere, når vi laster opp filer til Amazon S3, gjør vi det ved å laste opp filer til en S3 bøtte .

For å koble til bøtta, må Amazon S3-klienten ha legitimasjon. Legitimasjonsinformasjon er tilgangsnøklene vi opprettet tidligere. Vi definerer tilgangsnøkkel-ID og verdi i application.properties fil; vi har kalt bøtta vår toptal-s3-example.

Vår viktigste servicekomponent er nå som følger:

@Service public class StorageService { @Value('${aws.accesKeyId}') private String awsAccessKeyId; @Value('${aws.secretKey}') private String awsSecretKey; @Value('${aws.bucketName}') private String awsBucketName; private AWSCredentials credentials; private AmazonS3 s3client;; @PostConstruct public void init(){ credentials = new BasicAWSCredentials(awsAccessKeyId, awsSecretKey); s3client = new AmazonS3Client(credentials); } public void uploadFile(MultipartFile file) throws IOException { File fileForUpload = transformMultipartToFile(file); s3client.putObject(new PutObjectRequest(awsBucketName, file.getOriginalFilename(), fileForUpload)); } public InputStream downloadFile(String amazonFileKey) throws IOException { S3Object fetchFile = s3client.getObject(new GetObjectRequest(awsBucketName, amazonFileKey)); InputStream objectData = fetchFile.getObjectContent(); return objectData; } …

StorageService les legitimasjonen fra application.properties filen og bruker dem til å sette i gang BasicAWSCredentials objekt, og deretter AmazonS3Client gjenstand. Det som følger er et enkelt spørsmål om å påkalle putObject for filopplasting og getObject for nedlasting av filer, på Amazon S3-klientobjektet.

Vi vil kjøre tjenesten inne i en Docker-container, og i løpet av Gradle-byggeprosessen vil vi bygge Docker-bildet. Vi vil gjøre dette ved å konfigurere build.gradle filen, som følger:

buildscript { ... dependencies { ... classpath('se.transmode.gradle:gradle-docker:1.2') } } ..... apply plugin: 'docker' ... task buildDocker(type: Docker, dependsOn: build) { push = false applicationName = 'storageservice' dockerfile = file('src/main/docker/Dockerfile') doFirst { copy { from jar into stageDir } } }

Buildscript del og apply plugin er ganske standard. Vi har også definert en buildDocker oppgave som leser Docker-konfigurasjonen som er lagret i src/main/docker/Dockerfile, og kopierer JAR-filen til Docker-bygningen.

Dockerfile inneholder en liste over rene Docker-kommandoer som vi vil forberede bildet vårt på:

FROM frolvlad/alpine-oraclejdk8 ADD storageWebService-0.0.1-SNAPSHOT.jar storageService.jar EXPOSE 8080 CMD ['java', '-Djava.security.egd=file:/dev/./urandom', '-jar', '/storageService.jar']

En forutsetning for å kjøre applikasjonen vår er å ha installert en Java Virtual Machine (JVM). Docker gir en liste over bilder med Java installert, og vi vil velge en av de minste, basert på en minimal 5MB Alpine Linux. frolvlad/alpine-oraclejdk8 bildet har alt vi trenger og er ganske lite (bare 170 MB).

FROM kommandoen setter det nevnte bildet som basen som vårt eget skal bygges på. Vi ADD den innebygde JAR-filen til containerfilsystemet under navnet storageService.jar. Deretter definerer vi at Docker-container skal lytte på port 8080 ved kjøretid med EXPOSE kommando. Dette vil imidlertid ikke muliggjøre kommunikasjon til 8080 fra verten. Når bildet er ferdig, og vi vil kjøre det, må vi også publisere porten på containeren med følgende kommando docker run -p 8080:8080 amazonRepository/storageservice, hvor amazonRepository er et lager vi vil konfigurere senere i denne opplæringen. Med CMD definerer vi hvilke kommandoer som skal utføres når vi kjører containeren. Verdier i parentesene til CMD kommando betyr ganske enkelt at følgende vil bli utført når vi kjører containeren:

java -Djava.security.egd=file:/dev/./urandom -jar /storageService.jar

Alternativet -Djava.security.egd=file:/dev/./urandom er nødvendig for å redusere JVM-forsinkelser under oppstart. Hvis den utelates, vil applikasjonen starte opp veldig tregt på grunn av en tilfeldig prosess for generering av tall som er nødvendig under oppstartprosessen.

Dette oppsummerer delen 'Applikasjonsutvikling'. Når dette er gjort, starter tjenesten vi har opprettet her automatisk når vi kjører en Docker-container senere. Så la oss starte installasjonen og konfigurasjonen av de andre verktøyene som trengs for å sette opp den kontinuerlige integrasjonsprosessen.

Søknad og systemoperasjoner

Først og fremst trenger vi en ren Linux-server for å sette opp Jenkins CI-verktøyet. Merk at følgende instruksjoner er spesielt for Ubuntu 14.04. Husk at instruksjonene kan variere litt for andre Linux-distribusjoner. Den brukte Jenkins-versjonen er 2.7.1, og skjermene og instruksjonene kan variere noe avhengig av hvilken versjon av Jenkins som brukes.

Så vi går til Linux-serverkonsollen vår og begynner å installere forutsetningene.

JDK Forutsetning

Vi må ha en JDK installert. Følgende er instruksjoner for installasjon av JDK8.

sudo add-apt-repository ppa:webupd8team/java sudo apt-get install python-software-properties sudo apt-get update sudo apt-get install oracle-java8-installer java -version

Installer Docker

For at Jenkins skal kunne utløse Docker-bygg, må vi installere docker-engine som følger:

sudo apt-get install apt-transport-https ca-certificates sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D #create a docker list file sudo vi /etc/apt/sources.list.d/docker.list #add the following entry in the docker.list file (change trusty to #the release you are running on if you are running on different, ie. #xenial, precise...): deb https://apt.dockerproject.org/repo ubuntu-trusty main #save and exit the file sudo apt-get update apt-cache policy docker-engine sudo apt-get install docker-engine

Som vi nå har installert Docker-motoren, vil vi med følgende kommando starte en hello-world Docker-bilde for å bekrefte at Docker fungerer riktig.

sudo docker run hello-world

Hello-world bildeutdata vil se ut som følger, og med dette kan vi bekrefte at motoren fungerer ok.

Installer AWS Command Line Interface (CLI)

Deretter installerer vi AWS CLI. Senere, i Jenkins-jobbkonfigurasjon, vil vi bruke CLI til å utføre kommandoer for AWS-autentisering og Docker-bildepush til Amazon EC2 containerregister.

For å installere AWS CLI følger vi retningslinjene beskrevet i detaljer på Amazon CLI-dokumentasjon .

Av de to installasjonsalternativene velger vi installasjon ved hjelp av Pip, et pakkehåndteringssystem som brukes til å installere og administrere Python-programmer. Vi installerer Pip og AWS CLI ved å kjøre følgende tre kommandoer:

#install Python version 2.7 if it was not already installed during the JDK #prerequisite installation sudo apt-get install python2.7 #install Pip package management for python sudo apt-get install python-pip #install AWS CLI sudo pip install awscli

AWS ECR

Som det siste trinnet i byggeprosessen, vil vi skyve vårt Docker-bilde til Amazon-containerregisteret. I Amazon-webtjenestekonsollen finner vi AWS EC2 Container Service.

Vi velger Datalagre undermenyen til venstre og klikk på Kom i gang .

Vi får deretter presentert det første skjermbildet for å konfigurere depotet der vi skriver inn depotnavnet og klikker på Neste steg knapp.

Klikk på Neste steg viser oss deretter en skjerm med instruksjoner om hvordan du skyver bilder til depotet.

Vi får et eksempel på hvordan du bygger og skyver et Docker-bilde til registret, men vi trenger ikke å bekymre oss for dette nå. Med dette har vi opprettet et depot.

Installer og konfigurer Jenkins

For å installere Jenkins skriver vi inn følgende kommandoer i skallet:

#Download Jenkins key and pipe it to apt-key tool, apt-key command #add will read from input stream, as defined by „–„. When added #apt will be able to authenticate package to be installed. wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - #create a sources list for jenkins sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list' #update your local package list sudo apt-get update #install jenkins sudo apt-get install jenkins

Når installasjonen er ferdig, starter Jenkins automatisk. Sjekk servicestatusen med følgende kommando:

sudo service jenkins status

Jenkins vil koble til Bitbucket Git repository, og for å gjøre det, må vi installere Git.

#install Git sudo apt-get install git

Jenkins vil utløse Gradle-byggeprosessen, der et Docker-bilde blir opprettet. For å kunne gjøre dette, må Jenkins-brukeren legges til docker brukergruppe:

#add Jenkins user to docker user group sudo usermod -aG docker jenkins

Under byggeprosessen vil Jenkins presse Docker-bilder til Amazon ECR. For å aktivere dette må vi konfigurere AWS for Jenkins-brukeren.

Først må vi bytte til jenkins bruker. For å gjøre det, må vi angi et passord.

#change Jenkins password sudo passwd jenkins #switch to Jenkins user su – jenkins #configure AWS aws configure

Etter å ha gått inn i aws configure kommando, begynner vi å legge inn den genererte hemmelige tilgangsnøkkelen og nøkkel-IDen (dette er legitimasjonen vi genererte tidligere i prosessen). I mitt tilfelle er kontoens region us-west-2, og så skriver jeg inn det. Vi setter også standard utdataformat for AWS-kommandoer til å være JSON.

Vi kan nå gå videre til å konfigurere Jenkins gjennom nettkonsollen tilgjengelig på port 8080 .

Når vi får tilgang til URL-en, blir vi presentert for følgende Starter skjerm.

Som nevnt på skjermen, må vi skrive inn passordet. Etter å ha gjort dette, ber installasjonsveiviseren oss om å gjøre følgende:

• Velg hvilke plugins du vil installere - vi velger Installer foreslåtte plugins .
• Opprett første administratorbruker ved å angi brukerlegitimasjon

Når du er ferdig, klikker du Lagre og fullfør . Med dette er vi ferdig med Jenkins-konfigurasjonskonfigurasjonen.

Før vi begynner å definere byggejobben, må vi legge til noen ekstra plugins. Vi vil gå til Administrer Jenkins og klikk på Administrer plugins . I Tilgjengelig kategorien, finner vi først Bitbucket plugin , merker av i boksen og klikker på Last ned og installer etter omstart .

Du vil da bli presentert med noe som følgende skjermbilde.

Etter at plugin er installert, gjentar vi prosessen for følgende tilleggsprogrammer som er nødvendige for å sette opp jobben:

• Gradle-plugin
• Docker build step plugin
• Cloudbees Docker tilpasset byggemiljø-plugin
• Amazon ECR-plugin

Docker-byggetrinnsprogrammet vi bruker, sender forespørsler til Docker-demonen. For dette formålet må vi aktivere TCP-kontakten på port 2375. For å gjøre det, skriver vi inn Docker-konfigurasjonsfilen som ligger på etc/default/docker.

sudo vi /etc/default/docker

Her legger vi til følgende linje i konfigurasjonen:

DOCKER_OPTS='-H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock'

Vi lagrer og avslutter filen og starter både Docker og Jenkins-tjenesten på nytt.

sudo service docker restart sudo service jenkins restart

Etter at Jenkins har startet på nytt, går vi til Jenkins-konsollen og, fra Administrer Jenkins , vi velger Konfigurer system .

Vi finner Dockerbygger seksjonen og skriv inn http://localhost:2375 for REST API URL, klikk på Søke om for å bekrefte endringen. Vi klikker deretter på Test tilkobling å forhåpentligvis bekrefte at alt er ok.

Vi lagrer konfigurasjonen og fortsetter til Jenkins jobbkonfigurasjon.

Jobbkonfigurasjon

Vi går til hjemmesiden til Jenkins og lager en Ny gjenstand .

Vi velger a Freestyle-prosjekt og skriv inn prosjektnavnet som vist på følgende skjermbilde:

Klikk på OK , blir vi presentert for jobbkonfigurasjonssiden. Vi vil at prosjektet skal bygges på hvert trykk til Bitbucket Git-depotet vårt. For å oppnå dette må vi først definere depotet vi kobler til.

Trinn 1: Kildekodestyring

Under kildekodeadministrasjon velger vi Git og skriver inn URL-en til Bitbucket-depotet vårt. URL-en har form av https://bitbucket.org/bitbucketUsername/repositoryName.

Etter at vi har angitt URL-en, vil Jenkins automatisk prøve å teste forbindelsen. Siden vi ikke har lagt inn legitimasjon ennå, vil det vise en feil som indikerer at den ikke kan koble til.

Åpne rullegardinlisten Legge til , og klikk på Legitimasjonserklæring Jenkins forsørger.

Vi presenteres med følgende skjermbilde, der vi skriver inn brukernavn og passord for Bitbucket-kontoen vår.

Etter å ha lagt til den nye legitimasjonsoppføringen, sørger vi for å velge den i rullegardinlisten for påloggingsinformasjon, og dette fullfører Kildekodestyring oppsett.

Trinn 2: Bygg utløsere

Kryss av Trigger bygger eksternt og definere et godkjenningstoken. Sørg for å definere et tilfeldig og sikkert token.

Trinn 3: Bitbucket Webhook

Jenkins ga allerede URL-en for oss som vi vil bruke på Bitbucket. Vi går til Bitbucket-arkivsiden og klikker på innstillingsmenyen Web kroker . Klikk deretter på Legg til webhook presenterer oss for følgende skjermbilde, som vi fyller ut som følger:

URL har følgende struktur: http://JENKINS_URL _HOST:PORT/job/JOB_NAME/build?token=TOKEN.

Skriv inn verdiene over henholdsvis med Jenkins URL, port den kjører på, navnet på jobben du har opprettet, og token du tidligere har definert.

Etter at du har lagret Webhook, får du tilgang til følgende skjermbilde, som du kan redigere om nødvendig, eller se forespørsler generert hver gang vi trykker på ny kode.

Med denne konfigurasjonen blir webhook utløst på hvert repository-push, uansett gren. På Jenkins-siden kan vi definere hvilket grenpress som vil utløse bygningen.

For at Bitbucket skal kunne skyve koden til Jenkins, må vi konfigurere Jenkins globale sikkerhet på nytt for å tillate anonym lesetilgang. I tillegg, for vårt oppsett, må vi deaktivere standard Jenkins-alternativet som forhindrer forfalskning av forespørsel på tvers av nettsteder. For å gjøre dette, gå til Administrer Jenkins og velg Konfigurer global sikkerhet . Kryss av Tillat anonym lesetilgang og sjekk Forhindre utnyttelse av forfalskning på tvers . Lagre deretter konfigurasjonen.

Vær oppmerksom på at dette bare gjøres for enkelhets skyld. Fullt oppsett overgår dekningen av denne opplæringen, og det vil omfatte ytterligere sikring av Jenkins bak en omvendt proxy, på TLS-tilkobling, og muliggjør CSRF-forebygging.

Trinn 4: Gradle Build

Vi kan nå gå tilbake til Jenkins-jobben og fortsette å konfigurere den. I byggeseksjonen legger vi til et byggetrinn: Påkalle graderskript .

På dette skjemaet skriver vi inn følgende:

Som vist på skjermen, vil vi bruke Gradle-innpakningen, en praktisk Gradle-funksjon som ikke krever at du har Gradle installert på verten. Sørg for å sjekke Gjør gradlew kjørbar eske.

I oppgavene spesifiserer vi build og buildDocker.

Trinn 5: Docker Tag Image

Denne delen av bygningen merker et Docker-bilde som tidligere er utarbeidet av Gradles dockerBuild oppgave. For dette legger vi til et nytt byggetrinn i jobben: Utfør Docker-kommandoen . Vi velger Merk bilde kommandoen og angi bildenavnet, måldatabasen hvor vi skal skyve bildet, og tag:

Trinn 6: Docker Push til Amazon ECR

Til slutt må vi definere hvordan vi kan skyve bildet vårt til Amazon ECR. For dette legger vi til en ny Utfør skallet bygg trinn og sett kommandoene for å autentisere til AWS og for å skyve bildet til Amazon ECR:

#region for our account is us-west-2 aws ecr get-login --region us-west-2 | bash #push the previously tagged image docker push 058432294874.dkr.ecr.us-west-2.amazonaws.com/springbootdocker:${BUILD_NUMBER}

Med dette er vi ferdig med byggeprosessen. Etter å ha presset ny kode til repoen, vil denne jobben aktiveres, og vi vil ha et nytt Docker-bilde lastet opp til Docker-registeret 'automatisk magisk'.

Bildet kan deretter trekkes dit vi har docker-engine installert, og kan kjøres med følgende kommando:

docker run -p 8080:8080 amazonRepository/springbootdocker

Denne kommandoen starter vår Spring Boot-mikrotjeneste, med følgende sluttpunkter for opplasting og nedlasting av filene våre til S3-bøtta:

• http://hostnameURL:8080/api/storage/upload
• http://hostnameURL:8080/api/storage/download?fileName=xyz

Ytterligere trinn med Java og kontinuerlig integrasjon

Det er alltid flere ting å gjøre. Mye grunn har blitt dekket i denne opplæringen, men jeg vil bare betrakte dette som et utgangspunkt for å lære videre. Å sette Jenkins bak en web-proxy-server, som Nginx, og etablere en TLS-forbindelse, er bare to eksempler på hva mer kan, og uten tvil, bør gjøres.

Docker-bildet vårt er tilgjengelig på Amazon ECR og klart for distribusjon. Vi kan nå ta det og distribuere det manuelt. En finere løsning ville imidlertid være å automatisere den videre. CI er bare første trinn, og neste trinn er kontinuerlig levering. Hva med høy tilgjengelighet? Amazon AWS EC2 tilbyr funksjoner for registrering av containere i skyen i et klynget miljø som er obligatorisk for produksjonsbasert tjeneste. Et godt arbeidseksempel på å utvikle en kontinuerlig leveringsprosess finner du på følgende AWS-blogginnlegg .

Konklusjon

Alt i alt har vi fått på plass en jevn og ren programvareutviklingsprosess. Ved hjelp av tilgjengelige verktøy har vi laget en infrastruktur som hjelper med å maksimere produktiviteten vår. Nå trenger vi ikke bekymre oss for konfigurasjonen av Java-tjenesten vår, som er en enkel webtjeneste med et REST-sluttpunkt. Vi lar Spring Boot-konvensjonen ta seg av alt og fokuserer bare på tjenestelogikken. Vi bruker Jenkins til å bygge et nytt Docker-bilde hver gang vi skyver koden vår til Bitbucket Git-arkivet, og til slutt har vi satt skyen til å være ansvarlig for lagring av Docker-bilder og filer. Når vi distribuerer tjenesten vår som er inneholdt i et Docker-bilde, vil vi være forsiktig uten begrensninger i operativsystemet (så lenge operativsystemet har docker-engine installert).