Test av Cloud Foundry: Smeltedigel for suksess!

"Kraftig verktøy som hjelper utviklere med å levere applikasjoner raskere" mener vår skytester.

kode24s skytester har testa Cloud Foundry. 📸: Unsplash / Ole Petter Baugerød Stokke / Cloud Foundry
kode24s skytester har testa Cloud Foundry. 📸: Unsplash / Ole Petter Baugerød Stokke / Cloud Foundry Vis mer

Da var ferien vel overstått og skrivekløa på plass igjen. Jeg håper dere alle har fått lada batteriene og er klare for nye eventyr i tåka sammen med meg, mens vi forsøker å få litt oversikt over jungelen av sky-tilbydere og deres konglomerater av tjenester.

Dette er del 2 i serien, og her skal vi ta for oss en ferdig pakket versjon av det åpen kildekode lisensierte Platform-as-a-Service produktet Cloud Foundry. Innpakningen er levert av Pivotal i form av Pivotal Web Services.

Den første artikkelen tok en nærmere kikk på Heroku, og den kan du lese her: Heroku er konge!

Poenget med denne testen er å vise litt av hvordan man jobber med denne plattformen som utvikler i det daglige ved å demonstrere publisering av en "Hello World"-applikasjon. Som i første artikkel er fokuset med testingen å se på følgende brukerreise:

"Hvordan kan skyen hjelpe meg med å kjøre applikasjonen min på enkleste vis?"

image: Test av Cloud Foundry: Smeltedigel for suksess!

En sky utenom det vanlige

Jeg har lenge vært stor fan av Cloud Foundry og tankene rundt plattformen og arkitekturen der. Konseptet ble først tenkt ut i 2009 hos VMware og lansert i 2011, og siden har denne plattformen i aller høyeste grad blitt en viktig brikke i sky-infrastrukturen vi omgir oss med.

«Den har mange likheter med tankene og konseptene bak Heroku.»

Den har mange likheter med tankene og konseptene bak Heroku, men fremfor å være innelåst som en tilbydd tjeneste er den gitt ut som åpen kildekode. Dette har medført at industrigiganter som IBM, SAP, Suse og VMware, samt over 60 andre bedrifter og organisasjoner, har samlet seg i en stiftelse for å forvalte prosjektet på nøytral grunn. Cloud Foundry Foundation ble grunnlagt i 2015 som et Linux Foundation samarbeidsprosjekt.

I 2012, 3 år før stiftelsen ble skapt, opprettet EMC og VMware et selskap for å forvalte dette prosjektet, samt andre prosjekter som Spring og RabbitMQ. Selskapet ble kalt Pivotal og ble i 2018 børsnotert.

I skrivende stund er VMware og Pivotal akkurat blitt enige om at VWware kjøper opp Pivotal som en videreutvikling av sky-strategien til VMware etter deres oppkjøp av Heptio (et selskap med ekspertise innenfor Kubenetes) i 2018.

VMware har også akkurat lekket litt info om neste store milepæl i vSphere, management produktet deres for den virtuelle plattformen. Kubernetes vil bli innlemmet som en del av selve produktet for å gi administratorer samme grensesnitt for applikasjoner og konteinere som for virtuelle maskiner. Med tanke på dette oppkjøpet er det derfor ikke utenkelig at ikke også store deler av Cloud Foundry vil kunne bli innlemmet som en del av porteføljen.

Det er derfor ikke helt klart enda hvilke Pivotal-merkevarer som forblir intakte, hvilke som får nytt navn og hvilke som eventuelt avvikles, selv om vi trygt kan anta at Cloud Foundry som prosjekt vil bestå. Jeg velger uansett å basere testen på Pivotal Web Services fremfor feks IBM BlueMix eller en instans jeg setter opp selv da PWS er så mye mer tilgjengelig.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Du som utvikler kan også fint kjøre dette selv, siden den finnes i developer utgaver som ikke krever datahall-størrelse for å kjøre komponentene sine. OpenStack, Azure, AWS og Google er også alle sertifisert til å kjøre plattformen på, og Azure har til og med en pakket utgave i sitt marketplace for raskt oppsett. Brukergrensesnitt vil kunne variere noe på tvers av pakketerte og åpne løsninger, men API-ene er like, og det betyr at CLI-verktøyet fungerer likt.

Teknologi ⚙️

Teknologien som driver denne plattformen er som nevnt veldig lik Heroku i konsept og tanker. Under panseret finner vi autoskalering, lastbalansering, routing, helsesjekker, automatiske utrullinger og alle slike ting man må sette opp manuelt hvis man leker med Docker, NginX, Apache eller andre mer eller mindre tradisjonelle metoder for å publisere applikasjoner.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Som i Heroku har vi også konseptet med byggepakker her, og Heroku sine byggepakker skal visstnok kunne kjøre på Cloud Foundry, og visa versa. I tillegg er det støtte for Docker-baserte utrullinger.

De siste årene har unektelig Kubernetes blitt snakket om av de fleste som jobber med utvikling og sky-teknologi, og det jobbes med å integrere det originale prosjektet med Kubernetes for å gi en mer effektiv utnyttelse av den underliggende infrastrukturen, uten å endre på brukeropplevelsen for utviklerne, men dette er foreløpig skilt ut i et eget prosjekt "Project Quark".

Cloud Foundry har ut-av-boksen-støtte for Java med Spring, Ruby med Rails eller Sinatra, JavaScript via Node.js, .NET, .NET Core, Python, PHP og Go. Man kan i tillegg bruke egendefinerte oppsett via Docker.

Gjennom CLI-verktøyet BOSH, som også er åpen kildekode, kan man håndtere og styre selve Cloud Foundry oppsettet. Det er et verktøy rettet mer mot system-administratorene som sørger for at infrastrukturen gjør jobben sin, men jeg føler det er på sin plass å nevne det da det er en så sentral del av moderne sky-arkitektur.

image: Test av Cloud Foundry: Smeltedigel for suksess!

BOSH ble laget av VMware i 2010 for å styre utrullingen av Cloud Foundry, men det kan brukes til å rulle ut andre typer software også. Det er spesielt godt egnet til å håndtere hele livssyklusen til store, distribuerte løsninger og benyttes bl.a. til å rulle ut installasjoner med Hadoop, RabbitMQ eller MySQL. Det støtter både Linux og Windows-servere.

Verktøyet virker gjennom å bruke et grensesnitt de kaller "Cloud Provider Interface" som støttes i installasjonene til bl.a. AWS EC2, Apache CloudStack, Google Compute Engine, Azure, OpenStack og VMware vSphere.

Dokumentasjon 📚

I forhold til Heroku vil jeg ikke si at dokumentasjonen er like grei å forholde seg til for Cloud Foundry. I hovedsak er dette begrunnet med at plattformen som sådan er noe fragmentert siden den er tilgjengelig som åpen kildekode og som levert tjeneste i flere varianter.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Det at den i tillegg er levert som et kommersielt produkt for kjøring på egenhånd eller i den skyen du velger, gjør ikke landskapet mer oversiktlig. Når du søker etter informasjon må du passe litt på søkeordene dine for å være sikker på at du får treff relatert til den varianten du benytter.

«Når du søker må du passe litt på søkeordene.»

Det er selvsagt veldig store likheter mellom de forskjellige variantene, men det kan være viktige detaljer som skiller, og som vil kunne forvirre.

For å blir kjent med plattformen til å begynne med vil jeg absolutt anbefale å bruke PWS og tilhørende dokumentasjon, da denne ikke inneholder all informasjonen om hvordan installere, drifte og administrere selve plattformen, men fokuserer på bruk av tjenesten for en utvikler eller produktansvarlig som skal betjene livssyklusen til applikasjonen.

Der finner man også guider for noen av de forskjellige rammeverkene, og andre godbiter som kan være til hjelp.

image: Test av Cloud Foundry: Smeltedigel for suksess!

I tillegg til den tradisjonelle dokumentasjonen har Cloud Foundry også en god portefølje med kurs. Det er kurs tilgjengelig i alle vanskelighetsgrader, både gratis og betalt. De har dessuten inngått samarbeid med, i skrivende stund, 14 partnere for opplæring, inkludert Pluralsight.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Tjenester 🛒

Pivotal Web Services har ikke et like fyldig knippe med ekstra tjenester som er ferdig integrert, sammenlignet med Heroku. Det er likevel de viktigste tjeneste man kan ønske seg, med alt fra mLabs for managed Mongo DB, til MySQL, RabbitMQ, logging, monitorering osv.

image: Test av Cloud Foundry: Smeltedigel for suksess!

I tillegg kan man definere egne tjenester man skal integrere mot, noe som åpner dørene for å koble seg på omtrent hva det skal være av tjenester. Det at det ikke er flere ferdig integrert i PWS trekker riktignok noe ned.

Det må også nevnes at ved å kjøre den selv, kan det hende du må definere alle tjenestene selv, da det ikke er sikker din variant inkluderer ferdig satt opp markedsplass. Det er dog megler-tjenester man kan integrere for å få tilgang på flere tjenester i markedsplassen.

Pris 💸

Prisstrukturen på Pivotal Web Services er veldig enkel. Du betaler 3 cent per Gigabyte-time for minnet du bruker. Har du tilleggstjenester er de priset separat fra dette, men grunnprisen er så enkel, $0.03/GB-hr.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Tilleggstjenestene har varierende priser og kan sees nærmere på på markedsplassen. Der finner du som regel mange gratis-nivåer også, så du kan kjøre Proof-of-Concept og initiell utviklingsfase der.

Gratisnivået til Pivotal Web Services, altså kjernetjenesten, består i at du får tildelt $87 i kreditt når du oppretter ny konto og starter prøveperioden. Kreditten er gyldig i ett år, og du kan i "test-organisasjonen" benytte opptil 2GB RAM. Legger du derimot inn kredittkortet ditt, får du tilgang til 25GB RAM og kreditten legges på saldoen din, noe som betyr at den ikke lengre løper kun ett år.

Hello World! 👋

Oversikt over prosjektet

Prosjektet er det samme som i forrige artikkel, så dere som leste forrige test husker sikkert at jeg har klatta sammen en mini-applikasjon for å vise at alt virker som forutsatt.

Applikasjonen er ikke kobla til sky-spesifikke tjenester, men for å få litt action utover å vise en statisk HTML-side, har jeg laget en Node.js server som gir data til en enkel front-end.

Back-enden henter data fra en ekstern tjeneste, men siden scopet med demoen er å vise publiseringen, fremfor alle integrasjonsmulighetene, valgte jeg et åpent API som serverer data om bysykler.

Hvis dere ønsker å se applikasjonen i sin fulle prakt før dere kjører gjennom guiden, så kan dere se den på Glitch.com her: https://hakash-hello-bikeshare.glitch.me/

Remix på Glitch: https://glitch.com/edit/#!/remix/hakash-hello-bikeshare

Klon fra GitHub: https://github.com/hakash/hello-bikeshare

Installasjon

Som sist tar jeg utgangspunkt i at Node.js allerede er satt opp på systemet demoen skal kjøres på. Det anbefales å bruke Git for kloning, men denne gangen kan også en vanlig nedlastet og utpakket .zip-fil brukes, da CF, i motsetning til Heroku, ikke bruker Git for å laste opp applikasjonen.

En gyldig konto på PWS kreves også og kan fåes her: http://run.pivotal.io/

image: Test av Cloud Foundry: Smeltedigel for suksess!

Du trenger også å installere klienten, og det kan du gjøre fra denne siden: https://console.run.pivotal.io/tools

image: Test av Cloud Foundry: Smeltedigel for suksess!

La oss nå gjøre som de foreslår, logge inn. Bruk kommandoen cf login, gjerne med parameteren -a for å definere eksplisitt at API-endepunktet skal være api.run.pivotal.io.

Du vil få spørsmål om e-post og passord, samt hvilket "space" du vil koble deg på. Har du gjort det etter boka vil du ha et space som heter "development" som kommer som standard for alle nye kontoer. Jeg satte opp et nytt space for denne demoen, så mitt heter "kode24", noe som dere ser gjenspeilet i loggene under.

$ cf login
API endpoint: https://api.run.pivotal.io

Email> xxxxx@xxxx.xxx

Password>
Authenticating...
OK

Targeted org xxx.xxxxx

Select a space (or press enter to skip):
1. kode24

Space> 1
Targeted space kode24

API endpoint:   https://api.run.pivotal.io (API version: 2.138.0)
User:           xxxx@xxxxx.xxx
Org:            xxx.xxxxxx
Space:          kode24

Gratulerer! Du har nå logget inn i CLI-et mot PWS og er klar til å gjøre mye gøy.

Pass nå på å finn et lett tilgjengelig sted å laste ned koden og naviger inn i rot-mappen på prosjektet.

Manifest

Som dere husker fra Heroku-artikkelen kunne vi legge ved en spesiell fil for å fortelle plattformen endel om applikasjonen, litt lignende en Dockerfile-fil. Dette gjelder også for CF, og CF benytter seg av forskjellige filer for forskjellig informasjon. Du har manifest.yml som beskriver størrelsen på minnet, navnet på applikasjonen, antall instanser, miljøvariabler som skal legges inn og slike ting.

---
# comments
applications:
  - name: hello-bikeshare
    command: node .
    instances: 1
    memory: 128M
    disk_quota: 200M
    env:
      NODE_ENV: production

I tillegg bruker byggepakkene de teknologispesifikke filene som gjerne ligger ved for å identifisere versjoner av kjøretidsmiljøer og slikt. Ett eksempel på dette er package-lock.json eller package.json for Node.js-baserte applikasjoner. Her kan du definere hvilken versjon av Node, npm o.l. du skal bruke.

Dette temaet kan man selvsagt dykke mye dypere i hvis man ønsker det, men jeg tenker en enkel oversikt over konseptet holder for denne artikkelen.

Kopier inn eksempel-konfigurasjonen gitt over i manifest.yml og legg den på rot-nivå i den mappen du skal kjøre kommandoene fra. Endre også navnet på applikasjonen til noe unikt, da navnet brukes senere til auto-generering av URL-en.

Publisering

Siden vi nå har et enkel manifest, og siden byggepakkene er såpass intelligente som de er i forhold til å identifisere riktig teknologi, kan vi nå ganske enkelt kjøre cf push for å publisere applikasjonen i den organisasjonen og det området man logget i.

CF vil automatisk opprette en offentlig tilgjengelig URL for prosjektet, så det er viktig at applikasjonene har unike navn.

$ cf push
Using manifest file /path/to/your/projects/hello-bikeshare/manifest.yml

---
masse som skjer...
---

requested state: started
instances: 1/1
usage: 128M x 1 instances
urls: hello-bikeshare.cfapps.io
last uploaded: Mon Aug 26 21:48:03 UTC 2019
stack: cflinuxfs3
buildpack: nodejs

     state     since                    cpu    memory      disk        details
#0   running   2019-08-26 11:48:42 PM   0.0%   0 of 128M   0 of 200M

Når applikasjonen er ferdig lastet opp begynner byggepakka å kjøre jobbene som installerer og klargjør applikasjonen. Jeg forkorta loggen over, men det er veldig mye som vil passere i terminalen før den er ferdig. Når du ser noe som ligner på de siste linjene i loggen min kan du kopiere URL-en og åpne den i en nettleser for å teste applikasjonen.

image: Test av Cloud Foundry: Smeltedigel for suksess!

CF har da satt opp last-balansert routing fra internett og inn til koden du nettopp lasta opp, uten at du må fikle med brannmur, sette opp helsesjekker, monitorering og alt det styret der.

På en produksjonsapplikasjon vil man selvsagt benytte overvåking av applikasjonen på et vis, men da gjerne sammen med de innebygde mekanismene, og på en annen måte enn de tradisjonelle LAMP/LEMP/WAMP/WIMP osv. stack-ene.

GUI

Som Heroku, har PWS et veldig godt web-grensesnitt for å forvalte applikasjonen. Inne på området du lastet opp applikasjonen gjennom CLI finner du oversikten over alle applikasjonene der.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Inne på applikasjonsdetaljene ser du oversikt over instanser, minne, CPU, status, siste hendelser og slike ting. Du finner også en knapp for å hoppe til et annet verktøy for å kunne se grafer.

image: Test av Cloud Foundry: Smeltedigel for suksess!

PCF Metrics er fortsatt ferskt, men utvilsomt et nyttig tilskudd i familien.

image: Test av Cloud Foundry: Smeltedigel for suksess!

Oppsummering 🎲

Cloud Foundry er et kraftig verktøy som hjelper utviklere med å levere applikasjoner raskere, og muliggjør høy grad av autonomi for de forskjellige teamene som utvikler og drifter sine applikasjoner. Det etter hvert så populære utsagnet "You build it, you run it" vil kunne sier å være en stor motivasjonsfaktor både for å bruke slike verktøy, men også for å delta i å kontinuerlig videreutvikle disse.

Cloud Foundry får terningkast fem.
Cloud Foundry får terningkast fem. Vis mer

CF, som presentert gjennom PWS, er et solid stykke arbeid som løser mange utfordringer, og som er spesielt godt egnet til å kjøre applikasjoner som er såkalt "cloud native", men som også er fleksibelt nok til å kunne kjøre en mer tradisjonell applikasjon, ofte kalt monolitt. Tradisjonelle Windows-server-baserte applikasjoner kan nok være en utfordring å kjøre, så sant de ikke kjører på en ren .NET eller .NET Core plattform, men det gjelder alle skyer på dette nivået.

Prismessig er PWS overraskende enkelt og forholde seg til, og oppleves som endel rimeligere enn Heroku i mange tilfeller da man kan finjustere minneforbruket i langt større grad enn på Heroku.

«Se hvordan den kan forenkle ting som i dag gjøres med komplekse Docker-oppsett.»

Dokumentasjonen kunne vært noe enklere å forholde seg til, og er hovedgrunnen til at toppkarakteren ryker. På den andre siden er kurs-tilbudet, soliditeten til selve prosjektet og den meget brukervennlige måten både kommandolinjeverktøyet og GUI-et fungerer på alle ting som trekker opp.

Det kommer nok derfor ikke som noen overraskelse at CF får samme karakter som Heroku, en soleklar femmer!

Prøv det ut, lek med produktet, se hvordan den kan forenkle endel ting som kanskje i dag gjøres med komplekse Docker-oppsett, men som kanskje egentlig ikke trenger tilpasning av bunnpanna.

Takk for oppmerksomheten, og lykke til!