Sådan installeres din Cloud Foundry-app med (næsten) nul frygt ved hjælp af Travis CI

Applikationsinstallationer til skyen skal være smertefri. Vi skal være i stand til at implementere ny kode kontinuerligt, så ofte vi vil, uden frygt. Den blå-grønne implementeringsmodel giver os mulighed for at gøre dette.

Jeg sluttede mig for nylig til et nyt team på arbejdspladsen, der implementerede node.js Cloud Foundry-applikationer til IBM Cloud ved hjælp af Travis med Bluemix CloudFoundry-implementeringsudbyderen. Dette fungerer godt til hurtigt og nemt at konfigurere din implementering med blot et par parametre.

Desværre betyder hver implementering et afbrydelse af din applikation, da den eksisterende version stopper, og den nye version starter. Der er heller ingen bekræftelse på, at den nye kode er god, før den gamle kode blæses væk.

Med den blå-grønne implementeringsteknik fortsætter din nuværende applikation (Blue) med at køre og tage netværkstrafik. Mens din nye applikationskode (grøn) er implementeret på en midlertidig rute. Den nye grønne ansøgning kan valideres på den midlertidige rute. Hvis der er nogen problemer, stopper implementeringen. Den blå applikation fortsætter med at betjene trafik uafbrudt. Når den grønne applikation er undersøgt, opdateres routeren, så den peger på den grønne applikation. Den blå kan stoppes.

På denne måde er der altid en version af applikationen tilgængelig til at tage trafik. Eventuelle problemer i implementeringen eller runtime af den nye kode påvirker ikke tilgængeligheden af ​​din applikation.

Jeg begyndte straks at kigge efter en måde, hvorpå blågrøn kunne implementere vores applikationer. For at skrive så lidt brugerdefineret kode som muligt besluttede jeg at udnytte cf-blå-grøn-implementerings-plugin til Cloud Foundry-kommandolinjegrænsefladen (CLI). Jeg vil dele, hvordan jeg gjorde dette her.

Jeg antager, at hvis du landede her, er du sandsynligvis forbi punktet for blot at "komme i gang" med Travis. Jeg vil ikke dække disse detaljer her.

Hvis du ikke er interesseret i at følge med og bare vil komme direkte til varerne, kan du klone min arbejdsprøve fra GitHub.

Installation af CF CLI og blågrønt plugin

Da vi ikke bruger Cloud Foundry-implementeringsudbyderen, er vi selv nødt til at installere Cloud Foundry CLI såvel som det blågrønne implementeringsplugin. Vi kan gøre dette i den before_deployfase af Travis-byggeriets livscyklus.

Bemærk, at before_deployfasen kører før hver implementeringsudbyder. Hvis du laver yderligere ting i din implementeringsfase, kan du flytte disse trin ind i after_successfasen (som kører kun en gang efter en vellykket build) for at undgå unødvendige ekstrainstallationer. Du kan også flytte disse trin ind i selve implementeringsskriptet, som vi skriver næste gang.

Uanset hvor du lægger det, her er scriptet:

- echo "Installing cf cli"- test x$TRAVIS_OS_NAME = "xlinux" && rel="linux64-binary" || rel="macosx64"; wget "//cli.run.pivotal.io/stable?release=${rel}&source=github" -qO cf.tgz && tar -zxvf cf.tgz && rm cf.tgz- export PATH="$PATH:."- cf --version
- echo "Installing cf blue-green deploy plugin"- cf add-plugin-repo CF-Community //plugins.cloudfoundry.org- cf install-plugin blue-green-deploy -r CF-Community -f

Kommandoen til at installere CLI kommer direkte fra CloudFoundry DPL-kilden. Kommandoerne til at installere det blå-grønne implementeringsplugin kommer fra plugins README.

Påkalder den blågrønne implementering

For at påkalde den blågrønne implementering bruger vi scriptinstallationsudbyderen, som udfører en forudsat kommando og kontrollerer for nul status som indikation af succes.

deploy:# on update to master branch we deploy to Cloud Foundry- provider: script skip_cleanup: true script: ./scripts/cf-blue-green-deploy.sh blue-green-cf-travis manifest.yml prod on: branch: master

Bemærk, at der skip_cleanuper indstillet til true. Uden dette ville det CF CLI og det blå-grønne implementerings-plugin, du lige har installeret, blive fjernet inden implementeringen kører.

Scriptet cf-blue-green-deploy.sh logger ind på Cloud Foundry API og påberåber det blå-grønne implementerings-plugin. Ud over at angive et applikationsnavn og en manifestfil kan du også videregive et røgtest script til det blågrønne implementerings plugin. Pluginet kalder røgtest scriptet efter den nye applikationskode er blevet implementeret, men før applikationsruten skiftes til den nye applikation. Dette giver dig mulighed for at køre et vilkårligt antal tests mod den nye kode, før nogen reel trafik får adgang til den.

Røgtest scriptet er bestået et enkelt argument. Argumentet er den midlertidige URL til den nyligt implementerede applikation. Hvis røgtest scriptet afsluttes med succes, vil den blå-grønne implementering gennemføres ved at skifte rute til den nye applikation. Hvis røgtest scriptet afsluttes med en fejl, fortsætter trafikken til den gamle version af applikationen. Den nye version er fortsat tilgængelig til fejlfinding.

I mit eksempelprojekt påkalder smoke test-scriptet en / version API og verificerer, at det vender tilbage med en 200 statuskode.

I vores rigtige projekter på arbejdspladsen kører vi en postbudssamling mod den nyligt implementerede app. Du vil have, at din røgtestpakke skal være tilstrækkelig stor til, at du føler dig sikker på din nye kode, men ikke så stor, at det tager lang tid at gennemføre en implementering, eller flaky tests forhindrer dig i at gennemføre en vellykket implementering.

Du kan eventuelt køre en mere omfattende række regressionstest som et after_deploytrin, efter at din nye kode er live.

Bivirkninger af en blågrøn implementering i IBM Cloud

Der er et par nuancer af denne tilgang at være opmærksom på, hvis du implementerer til IBM Cloud. Fordi du opretter en ny CF-applikationsinstans hver gang du blå-grøn implementerer, ændres din applikationsvejledning. Hvis du bruger tilgængelighedsovervågningstjenesten, går dine konfigurerede tests tabt, når din guide ændres.

For at omgå dette skal du oprette en permanent dummy-applikation. Skriv dine tests til din blågrønne implementerede app i denne dummy-applikations konfiguration. Du kan angive en hvilken som helst URL, når du skriver dine test for tilgængelighedsovervågning.

Similarly, if you use the Log Analysis service, you’ll see that when you click the “View in Kibana” link on your application dashboard’s Logs tab, you will be launched into a Kibana search on the application guid string. Any application logs from before your most recent deployment will not show up. To work around this, you can simply filter on the application name rather than the application guid.

Another service that has the same issue is Auto-Scaling. Each time a new application is stood up as part of the blue-green deploy, it needs its Auto-Scaling policy reconfigured. There is a command line interface available that you presumably could use to script this, but I have not yet had a need to try this.

If any of these issues are non-starters for you, you always have the option of writing a custom blue-green deploy script that leverages two permanent CF applications, a blue, and a green. These two apps would take turns being live and being idle. You could configure both applications with an auto-scaling policy, for example.

Of course, this approach means you can’t take advantage of the blue-green deploy plugin described in this post, and you need to maintain your own custom script.

Wrapping up

In this post, we’ve examined how we can accomplish a low risk, zero-downtime deployment using Travis and the cf blue-green deploy plugin.

I et rigtigt projekt ville vi have endnu større forsikringer, da vi ville have en række enhedstests på plads, og fejl der ville fejle Travis-bygningen, før implementeringen havde en chance for at køre. Vi vil muligvis også have udviklings- og iscenesættelsesgrene konfigureret til at distribuere til deres egne respektive rum i vores Cloud Foundry-organisation, så vi kan validere og stabilisere applikationen efter behov, inden vi fremmer ændringer i produktionen.

Tak for læsningen! Dette er min første Medium-historie, og jeg håber, du fandt det nyttigt.