Hoe u uw Cloud Foundry-app met (bijna) geen angst implementeert met behulp van Travis CI

Applicatie-implementaties in de cloud moeten pijnloos verlopen. We moeten in staat zijn om continu nieuwe code te implementeren, zo vaak als we willen, zonder angst. Het blauwgroene inzetmodel stelt ons hiervoor in staat.

Ik ben onlangs lid geworden van een nieuw team op het werk dat node.js Cloud Foundry-applicaties aan het implementeren was in de IBM Cloud met behulp van Travis met de Bluemix CloudFoundry-implementatieprovider. Dit werkt uitstekend voor het snel en eenvoudig opzetten van uw implementatie met slechts een paar parameters.

Helaas betekent elke implementatie een uitval van uw applicatie omdat de bestaande versie stopt en de nieuwe versie opstart. Ook is er geen verificatie dat de nieuwe code goed is voordat de oude code wordt weggeblazen.

Met de blauwgroene implementatietechniek blijft uw huidige applicatie (blauw) draaien en netwerkverkeer opnemen. Terwijl uw nieuwe applicatiecode (groen) op een tijdelijke route wordt geïmplementeerd. De nieuwe Groene applicatie kan gevalideerd worden op de tijdelijke route. Als er problemen zijn, stopt de implementatie. De Blue-applicatie blijft het verkeer ononderbroken bedienen. Zodra de groene applicatie is doorgelicht, wordt de router bijgewerkt zodat deze naar de groene applicatie wijst. The Blue kan worden gestopt.

Op deze manier is er altijd een versie van de applicatie beschikbaar om verkeer op te vangen. Eventuele problemen bij de implementatie of runtime van de nieuwe code hebben geen invloed op de beschikbaarheid van uw applicatie.

Ik ging meteen op zoek naar een manier om onze applicaties blauwgroen in te zetten. In het belang van het schrijven van zo min mogelijk aangepaste code, besloot ik om de plug-in cf-blue-green-deploy te gebruiken voor de Cloud Foundry-opdrachtregelinterface (CLI). Ik zal hier vertellen hoe ik dit heb gedaan.

Ik ga ervan uit dat als je hier bent geland, je waarschijnlijk voorbij het punt bent waarop je met Travis gewoon 'aan de slag kunt gaan'. Ik zal die details hier niet behandelen.

Als je niet geïnteresseerd bent om mee te volgen en gewoon meteen naar de goederen wilt gaan, kun je mijn werkvoorbeeld van GitHub klonen.

De CF CLI en blauwgroene plug-in installeren

Omdat we de Cloud Foundry-implementatieprovider niet gebruiken, moeten we de Cloud Foundry CLI zelf installeren, evenals de blauwgroene implementatie-plug-in. Dit kunnen we doen in de before_deployfase van de Travis build lifecycle.

Merk op dat de before_deployfase vóór elke implementatieprovider wordt uitgevoerd. Als u aanvullende dingen doet in uw implementatiefase, wilt u deze stappen wellicht verplaatsen naar de after_successfase (die slechts één keer wordt uitgevoerd na een succesvolle build) om onnodige extra installaties te voorkomen. U kunt deze stappen ook verplaatsen naar het implementatiescript zelf, dat we hierna zullen schrijven.

Ongeacht waar u het plaatst, hier is het script:

- 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

De opdracht om de CLI te installeren, komt rechtstreeks van de CloudFoundry DPL-bron. De opdrachten om de blauwgroene deploy-plug-in te installeren, zijn afkomstig van de README van de plug-in.

Een beroep doen op de blauwgroene inzet

Om de blauw-groene implementatie aan te roepen, gebruiken we de scriptimplementatieprovider, die een opgegeven commando uitvoert en controleert op nulstatus als indicatie van 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

Merk op dat skip_cleanupis ingesteld op true. Zonder dit zou de cf CLI en blauwgroene deploy-plug-in die je zojuist hebt geïnstalleerd, worden verwijderd voordat de implementatie wordt uitgevoerd.

Het cf-blue-green-deploy.sh-script logt in op de Cloud Foundry API en roept de blauwgroene deploy-plug-in aan. Naast het specificeren van een applicatienaam en manifestbestand, kunt u ook een rooktestscript doorgeven aan de blauwgroene implementatie-plug-in. De plug-in roept het rooktestscript aan nadat de nieuwe applicatiecode is geïmplementeerd, maar voordat de applicatieroute wordt overgeschakeld naar de nieuwe applicatie. Hierdoor kunt u een onbeperkt aantal tests uitvoeren tegen de nieuwe code voordat er echt verkeer toegang toe heeft.

Het rooktestscript wordt met één argument doorgegeven. Het argument is de tijdelijke URL van de nieuw geïmplementeerde applicatie. Als het rooktestscript met succes wordt afgesloten, wordt de blauwgroene implementatie voltooid door de route naar de nieuwe applicatie over te schakelen. Als het rooktestscript wordt afgesloten met een fout, blijft het verkeer naar de oude versie van de applicatie stromen. De nieuwe versie blijft beschikbaar voor probleemoplossing.

In mijn voorbeeldproject roept het rooktestscript een / version API aan en verifieert dat het terugkeert met een 200 statuscode.

In onze echte projecten op het werk voeren we een Postman-verzameling uit tegen de nieuw geïmplementeerde app. U wilt dat uw rooktestsuite groot genoeg is om zeker te zijn van uw nieuwe code, maar niet zo groot dat het lang duurt om een ​​implementatie te voltooien of dat slechte tests u ervan weerhouden een succesvolle implementatie te voltooien.

U kunt optioneel een uitgebreider pakket regressietests uitvoeren als after_deploystap, nadat uw nieuwe code live is.

Bijwerkingen van een blauwgroene implementatie in IBM Cloud

Er zijn een paar nuances van deze benadering waar u op moet letten als u implementeert op IBM Cloud. Omdat u elke keer dat u blauwgroen implementeert een nieuwe CF-toepassingsinstantie maakt, verandert uw toepassingsrichtlijn. Als u de Beschikbaarheid Monitoring-service gebruikt, gaan uw geconfigureerde tests verloren wanneer uw GUID verandert.

Om dit te omzeilen, plaatst u een permanente dummy-applicatie. Schrijf uw tests voor uw blauwgroene geïmplementeerde app in de configuratie van deze dummy-applicatie. U kunt elke URL opgeven wanneer u uw beschikbaarheidsmonitoringstests schrijft.

Evenzo, als u de loganalyseservice gebruikt, zult u zien dat wanneer u op de link "Weergeven in Kibana" klikt op het tabblad Logboeken van uw toepassingsdashboard, u een Kibana-zoekopdracht op de toepassingsrichtreeks start. Eventuele toepassingslogboeken van vóór uw meest recente implementatie worden niet weergegeven. Om dit te omzeilen, kunt u eenvoudig filteren op de toepassingsnaam in plaats van op de toepassingsgids.

Een andere service met hetzelfde probleem is automatisch schalen. Elke keer dat een nieuwe applicatie wordt opgestart als onderdeel van de blauwgroene implementatie, moet het Auto-Scaling-beleid opnieuw worden geconfigureerd. Er is een opdrachtregelinterface beschikbaar die u vermoedelijk zou kunnen gebruiken om dit te scripten, maar ik heb dit nog niet hoeven proberen.

Als een van deze problemen u niet begint, heeft u altijd de mogelijkheid om een ​​aangepast blauwgroen implementatiescript te schrijven dat gebruikmaakt van twee permanente CF-toepassingen, een blauwe en een groene. Deze twee apps zouden om de beurt live zijn en inactief zijn. U kunt bijvoorbeeld beide applicaties configureren met een beleid voor automatisch schalen.

Deze aanpak betekent natuurlijk dat je geen gebruik kunt maken van de blauwgroene invoegtoepassing die in dit bericht wordt beschreven, en dat je je eigen aangepaste script moet onderhouden.

Afsluiten

In dit bericht hebben we onderzocht hoe we een implementatie met een laag risico en geen downtime kunnen realiseren met behulp van Travis en de cf blauwgroene implementatie-plug-in.

In a real project, we would have even greater assurances, as we would have a suite of unit tests in place, and errors there would fail the Travis build before the deployment had a chance to run. We would also potentially have dev and staging branches configured to deploy to their own respective spaces in our Cloud Foundry organization, allowing us to validate and stabilize the application as necessary before promoting changes to production.

Thanks for reading! This is my first Medium story, and I hope you found it useful.