Microservices till frukost

Frukostseminarium är en mycket trevlig seminarieform, blev jag idag åter påmind om. Idag hade Calllista Enterprise ett mycket intressant och kompakt seminarium http://callistaenterprise.se/event/externa/2015-05-27_Microservices med många arkitektkollegor jag kände igen.

Magnus Larsson beskrev hur man delar upp en mikrotjänstearkitektur och hur man tänker sig att den skiljer sig från SOA.

Demon var cool. Han hade gjort en liten demoapplikation som bestod av en liten flock mikrotjänster och hade sedan lagt på Netflix Zuul, Eureka, Turbine, Hystrix Dashboard, ELK stack och startade förstås upp allting med docker-compose.

Screen Shot 2015-05-27 at 18.49.05

Sedan skalade han upp en av tjänsterna, docker kickar bara in och lastbalanseraren fångar bara upp, och vår inspektion i Kibana visade på att det funkade ju fin-fint.

Sedan testade han kretsbrytaren genom att simulera långa svarstider från en av tjänsterna.

Netflix prylar är definitivt värda besväret att kolla på – ”proven in battle” -de har ju pallat för de 24% av USAs internettrafik som Netflix utgör.

En annan sak jag fick med mig från diskussionerna efteråt, förutom en Callista reklamvattenflaska, var att kolla på Gatling som alternativ till JMeter för att prestandatesta med HTTP. Jag höll på att få med mig en tom frukostkaffekopp ut på Drottninggatan också, men jag kom på mig själv och lämnade tillbaka den.

Tack igen Magnus Larsson för en fantastisk start på den här dagen!

Publicerad i Cloud Computing, DevOps, Java

Build 2015

Bland molnen

Sitter i en Dreamliner på 40000 fot i 935 km/h på väg från Stockholm mot San Francisco och Build 2015.

Dreamliner

Dreamliner

Jag har just sett Birdman och reflekterar över det faktum att det är över 7 timmar kvar till SF. Planet är långt ifrån fullt jag har en egen stolsrad men livet vore inte livet om allt var perfekt. Ett ungt par sitter en och en halv stolsrad bort med en ny generation i sina armar som pockar på uppmärksamhet.

Ser med spänning fram mot konferensen och vad som ska presenteras där.

San Francisco

Anländer ett par dagar före konferensens start för att vänja mig vid tidszonen och hinna se något av staden.

Går från hotellet på Union Square till Fishermans wharf och Pier 39. Det är rejält soligt men det blåser en riktigt kall vind från havet. Stan passar på att visa upp några av sina värsta uppförsbackar på vägen så det sitter fint med en Bisonburgare på en riktig turistfälla med utsikt över Alcatraz.

San Francisco

Alcatraz väntar om man inte följer den smala vägen

Promenaden tillbaka går genom Italian district och San Francisco’s världsberömda Chinatown. Jag blir lika rödbränd som de jag smålett åt nere vid piren.

Jag och en annan svensk delegat som jag träffat på Arlanda försöker hyra en bil för att ta en tur över Golden Gate och sedan fortsätta mot redwoodskogarna. Det går åt skogen (trumvirvel), uthyrningsfirman kan bara erbjuda en Ford F150, vilken ingen av oss känner för att köra i den täta trafiken. Vi beger oss i stället till Oakley-butiken på Market street. Där träffar vi butiksbiträdet Debbie som tipsar oss om en buss, Muni 76x, den går över Golden Gate och till Marine Headlands. Hon ringer till och med till sin man, de bor nära bron,  för att kolla att det inte är någon dimma. Vi åker med bussen till Bonita Lighthouse. En mycket vacker tur i ett kuperat och vindpinat landskap, billigaste nöjet i SF? 2.49$ hop-on hop-off.

San Francisco

Golden Gate, men, men … ?

Konferens

Registreringen öppnar dagen innan den officiella starten av Build 2015, är där tidigt så att jag kan få tag i en konferens T-shirt som passar. Sen blir det en eller två maltdrycker på vägen till Microsoft Sveriges event på Roe i South Market området. De delar ut en kul väldigt reflektiv jacka som Volvo varit med och sponsrat, ingen lyckades fotografera den med blixt. Från Roe bär det av till Xamarins event på Jillians där är det en ordentlig kö, den första under konferensen, det blir många fler. Det visar sig att eventet slår upp portarna precis när vi ställer oss i kön och vi är inne på mindre än 10 minuter. Det blev kvällens sista mingel.

Build 2015

Morgon i San Francisco

En sedvanligt bisarr konferensfrukost bestånde av croissant, en kaka och ett egg väntar när jag anländer till Moscone Center West. Efter frukosten är det dags att köa till keynoten, det gäller att hänga på låset, de som kommer sist får inte plats i huvudsalen utan får följa keynoten på skärmar i mindre rum.

Build 2015

Rejäl kö till keynoten på Build 2015

Build 2015

Keynote är på väg att starta

Satya Nadella inleder konferensen med ett inspirerande tal och målar med den stora penseln.

Han följs av en rad kända Microsoft profiler bl a Scott, Scott och Scott.

En av de stora nyheterna är Microsofts nya operativsystem Windows 10 och det är grunden för många av de andra nyheterna som presenteras.
Ett av målen är att nå 1 miljard  aktiva Windows 10 installationer under 2018, för att operativet snabbt ska bli intressant för utvecklare kommer Windows 10 att erbjudas som en gratis uppgradering till Windows 8.

En ny applattform, Universal Windows Platform, presenteras. Den verkar mycket lovande och kommer ebjuda utvecklare möjlighet att utveckla appar i en miljö som känns hemtam. Fyra nya toolkits presenterades för utveckling på Universal Windows Platform, Webb, .NET / Win32, iOS och Android. De färdiga Universal Windows Apparna kan sedan distribueras via Windows Store.

Continuum, som kommer som en del i Windows 10, kommer att förändra möjligheterna att arbeta på enheter med lite för lite ”screen estate”, kopplar man till exempel telefonen till en större skärm kommer den utnyttja den större ytan, applikationerna anpassar sig och gränssnittet blir ungefär som på en vanlig PC. Om det kommer fungera lika bra som jag hoppas kommer det ge fantastiska möjligheter när det gäller mobilitet. Kontoret på fickan.

Edge tidigare känt som Project Spartan visas upp, Microsofts nya web browser.
Microsoft har ju länge haft en stor förbättringspotential med IE så det känns skönt att de försöker realisera den nu. Det här blogginlägget är skrivet i Windows 10 med hjälp av Edge, den verkar ganska skarp även i den här inte helt färdiga versionen.

Microsofts kanske mest hypade produkt någonsin, HoloLens, äntrar scenen till mångas stora förväntan. HoloLens är en dator man sätter på huvudet som projicerar 3D objekt ovanpå verkligheten. Nytt fönster i lägenheten, click, ny storbildstv, click, kliva in i ritningen på nya villan för att gå runt i rummen, click. Ta en titt på hur nya bilen skulle se ut med tribals i neon, click. Gå runt på Mars, click.

HoloLens

HoloLens

Demonstrationen var mycket imponerande och enligt de få som fick plats på en testkörning motsvarade den alla förhoppningar. Tyvärr lyckades jag inte boka mig, platserna tog slut väldigt väldigt fort.

HoloLens

En RasberryPi 2 kontrollerad bas med en virtuell robotkropp sedd genom en HoloLens

Visual Studio Code, en gratis lättviktig editor för kodning, släpptes på Windows, Mac och Linux. Det är första gången Microsoft förser utvecklarna med en riktig cross-platform kod-editor.

Microsoft släppte en preview på .NET Core för Windows, Linux and Mac OS X

De släppte även Visual Studio 2015 Release Candidate.

Build 2015

Docker för Windows!

Build 2015

Mellan passen fans det mycket intressant att se och göra.

Det här är givetvis bara en liten del av vad som presenterades, ett smakprov.

Jag rekommenderar er att ta en titt på områden som IoT, Azure och Office365.

Presentationerna går att se på nätet, det finns mycket intressant och matnyttigt att välja mellan.

Publicerad i .NET, Windows Taggar: , , , ,

Docker-compose

Våra regelbundna workshops kring vår build pipeline med Docker fortsätter.

Johan Elmström på Aptitude hostade denna Continuous Delivery Pipeline workshop. Den här gången blev vi bara fyra stycken. En hel flock andra DevOps-intresserade hade varit tvungna att kasta in handduken med skäl såsom sjukdom, VAB eller helt enkelt bara tagit fel på vecka.

Johan kunde stoltsera med ett alldeles nytt nätverk med 1000 MBit internet-access. Nätverket får alltid mycket uppmärksamhet på våra träffar när man sitter flera tillsammans och tankar operativsystemsavbildningar från internet hela tiden.

Vi singlade slant om vi skulle ge dagen till ELK eller till Docker-compose. Det blev Docker-compose. Senare visade det sig att myntet Mikael Sennerholm valt hade Docker-compose på bägge sidor.

Docker-compose är det nya namnet på Fig. För alla oss som fortfarande ser ut som fågelholkar nu är Docker-compose alltså ett kompakt sätt att gruppera ihop flera Docker-konfigurationer. Vi har precis den situationen här i pipelinen. För oss ersätter Docker-compose vår befintliga Vagrant-baserade lösning. Samma sak med Docker-compose blir snyggare och mer kompakt. Se https://docs.docker.com/compose/ och även http://www.fig.sh.

Toppdomänen .sh förresten, är den dedicerad för shell-script-relaterade ämnen? Efter närmare undersökning visade sig den tillhöra ön S:t Helena i Atlanten, ni vet den som när man var liten det alltid fanns en rövare på i spelet Den Försvunna Diamanten, och utan pengar kunde man ju inte ens åka båt därifrån och då var spelet slut och då blev man arg och ledsen.

denförsvunnadiamanten

Två nya docker-versioner har kommit sedan sist vi byggde pipeline tillsammans, men ingen ny Vagrant. Vagrant känns som ett gammalt spår. Vi konstaterar att maintainern för boot2docker-vagrant-box fortfarande inte tagit hand om Mikaels pull-request.

Vi började skriva en docker-compose.yml och konstaterade att man inte får ha tab-tecken i sådana filer.

Vi lyckades få en färdig image gocd/gocd-server att fungera. Funkade inte för en månad sedan, så det var positivt. Bleeding edge kan man kalla det, eller en förlorad månad, beroende på hur på man är.

Vi landade i en docker-compose.yml som såg ut så här:

repository:
  image: mattgruter/artifactory
  volumes:
    - data/artifactory/data:/artifactory/data
    - data/artifactory/logs:/artifactory/logs
  ports:
    - "18080:8080"
goserver:
  image: gocd/gocd-server
  volumes_from:
    - godata
  ports:
    - "28153:8153"
  environment:  
    - AGENT_KEY=388b633a88de126531afa41eff9aa69e
godata:
  build: gocd-data
goagent:
  build: go-agent
  volumes:
     - "/var/run/docker.sock:/var/run/docker.sock"
  links:
    - repository
    - goserver

repository är vårt maven-repo. Den sparar sitt repository i data-katalogen så att man slipper att tanka ned hela internet om man startar om pipelinen.

goserver är Thoughtworks Go Server och användargränssnittet. Det får in sin konfiguration via godata och cruise-config.xml.

goagent är den som hoppar igång och utför själva byggjobben.

Någonstans innan middagen dök vi på nästa problem:

Pulling repository java
Service 'goagent' failed to build: Get https://index.docker.io/v1/repositories/library/java/images: dial tcp: lookup index.docker.io on 10.0.2.3:53: server misbehaving

Det visade sig bero på Johans nya nätverk som krånglade på så vis att Mikael stokastiskt tappade paket. Jag och Mikael slog över på mobilt internet, då fungerade det plötsligt igen. Men för Johan fungerade det fortfarande. Mikael misstänkte att Johan saboterade just hans nät för att Johan skulle få ha kvar projektorsladden.

IMG_20150427_170946
Anders Ekdahl har hittat en lös nätverkssladd.

Med Johan i täten började pipelinen fungera igen, men vi fick Out of Memory när vi byggde. Det avhjälpte vi genom att ge boot2docker ger minne. Original har den 2GB vilket inte räcker för att köra både go-server, go-agent, artifactory, och applikationen med integrationstester samtidigt. Vi gav den 4GB istället:

$ boot2docker delete 
$ boot2docker init -m 4096 ... lots of output ... 
$ boot2docker info { ... "Memory":4096 ...}

Efter några mindre mentala missöden med att sätta environment för fel maskin i docker-compose fick vi pipelinen att gå igenom alla byggsteg och visa grönt.

Screen Shot 2015-05-02 at 15.09.03

Jaha. Då funkar allt. Vad ska vi hitta på nu? Klockan är ju bara barnet.

Hur gör man om man vill ha flera go-agenter för att kunna bygga snabbare?

Första förslaget var att göra copy-paste på entryt “goagent” i docker-compose.yml och skapa en “goagent2”. Det kändes sådär.

Efter några sekunders betänketid visade Mikael hur man egentligen gör:

$ docker-compose scale goagent=2
Creating dockerapplicationserver_goagent_2...
Starting dockerapplicationserver_goagent_2...

och efter några ögonblick ploppar den nya agenten upp i användargränssnittet:

Screen Shot 2015-05-02 at 15.08.19

Det var så vackert att vi nästan blev gråtfärdiga.

Men, invände någon sedan vi hämtat oss, den docker-instansen går igång på samma host. Hur får man igång en agent på ett eget järn? En lösning på det är Docker Swarm.

Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual host.

Publicerad i Continuous Delivery, DevOps, Java, Linux

Automatisk test och kontinuerlig leverans

Under ett antal år har jag varit med och lagt grunden till många system och utvecklingsmiljöer där automatisk test och build pipelines utgjort viktiga element. Jag har även haft förmånen av att ha arbetat i teamen under en längre tid efter etableringen och den vägen erhållit praktisk erfarenhet av dagligt utvecklingsarbete där automatisk test och täta leveranser ingår.

IMG_20150331_173153

Jag har gjort liknande observationer som Jez Humble gjort och på ett utmärkt sätt beskrivit i boken Continuous Delivery.

För att automatisk test ska kunna fungera och underhållas över tid måste den integreras på ett bra sätt i den normala byggcykeln. Alla utvecklare och testare ska enkelt kunna köra testerna innan commit, och på samma vis som byggpipelinen gör. Testkod och testdata ska självklart också vara incheckat. Alla i teamet oavsett om man jobbar med applikationsutveckling eller testutveckling ska kunna rätta och utveckla testerna. Testerna ska köras automatiskt vid incheckning i kodrepot och om testerna fallerar avbryter man det man höll på med och avhjälper felet. Av detta följer att testutvecklare och applikationsutvecklare måste samarbeta om aktiviteterna.

Om testutveckling sker separat från applikationsutveckling och testutvecklingen ligger före applikationsutvecklingen kommer det alltid att finnas tester som fallerar eftersom funktionaliteten som testas inte är utvecklad än. Och om testutveckling istället ligger efter applikationsutveckling i fas är det stor risk att systemet som utvecklas inte blir testbart. Och under tiden applikationen och automattesterna inte är synkade så är systemet inte releasebart. Alla dessa situationer är oönskade.

De utvecklingsmiljöer jag etablerat de senaste åren har varit Maven-baserade och uppdelade i flera moduler. Den första uppdelningen är en applikationskatalog och en testkatalog. Under testkatalogen lägger jag moduler med olika automatiska tester, uppdelade per verktyg/ramverk samt tjänstestubbar, testdatamoduler m.m.

De vanligaste verktygen för automatisk test jag stött på är:

SoapUI Pro är rätt använt ett bra verktyg för att utveckla automatiska tester mot tjänstegränssnitt.

Selenium fungerar bra så länge man håller sig till smoke-tester av UI där och inte försöker sig på att skriva funktionella tester med anspråk på att täcka upp stora delar av systemets funktionalitet.

Java är fortfarande ett enkelt och effektivt verktyg att skriva funktionella tester med. Man skriver dem med JUnit-ramverket precis som med vanliga enhetstester, men koden kör mot det riktiga systemet som deployas via Maven i Mavens byggcykel. Om man är van vid Groovy istället för Java (i SoapUI använder man Groovy för lite mer avancerade saker) så är det lätt att lägga till en Groovy-modul istället, och fortfarande på JUnit-ramverket och med tillgång till samma stödbibliotek som i Java.

Cucumber fungerar bra och resulterar i trevlig och lättändrad kod, och sympatisk och lättläst rapportering med bra integration i Jenkins via Cucumber plugin. En risk som jag och flera omkring mig också observerat är att man från verksamhetssidan inte tar tillvara på fördelarna som en exekverbar kravspec på den här formen innebär och då blir det bara utvecklare som läser och uppdaterar den vilket innebär att man då lika gärna kan skriva dessa tester direkt i Java eller något annat programmeringsspråk.

För kapacitetstester är JMeter är ett verktyg jag nyfiken att undersöka vidare hur man lämpligast integrerar med Maven och hur det fungerar i längden. LoadUI är ett annat alternativ här som jag ännu bara kört manuellt, alltså ännu inte integrerat i en pipeline.

Spring Boot har jag använt många gånger för att skriva mer eller mindre avancerade tjänstemockar som krävs för automatisk test, både REST- och SOAP-servrar. Mycket effektivt och ändamålsenligt för detta.

Och sist men inte minst: Lamporna

Utan lampor eller liknande synlig och central indikator är det lätt att teamet efter den inledande CI-förälskelsen glömmer CI-statusen och att testjobb fallerar i veckor i sträck.

En för många ny aspekt av automatisk test är att testledaren bör ha kontroll på alla tester, oavsett om de är manuella eller automatiska, och oavsett vem i teamet de är utvecklade av. Gränsen mellan applikationsutvecklare och testutvecklare ska helst vara flytande eller obefintlig.

Om man har krav på sig att följa upp testtäckning mot krav måste detta också ske kontinuerligt, vilket kräver intrimmade procedurer och koll på krav- och testläget.

Vidare ska testledaren ha kontroll på vilka tester som implementeras automatiskt och i vilken modul och vilka som är manuella, ha en idé om vilka manuella tester som ligger på kö för automatisering och ta initiativ till och följa upp att så sker.

Levererar man ofta så behöver man inte ha samma kontroll på aktuell teststatus som annars, eftersom normalläget är att alla tester passerar, lampan är normalt grön. Merparten av testerna måste då vara automatisk och den manuella delen får inte ta lång tid att plöja igenom.

Levererar man till exempel varannan vecka kan man kanske kosta på sig en dags manuell test innan produktion, levererar man varje dag rör det sig kanske om någon timme. Får man en tillräckligt inoljad utvecklings- och leveransmodell slutar man kanske helt att ha en manuell testprocedur innan produktionssättning eftersom man lärt sig att utveckla och testa i små steg från början. Ett extra teststeg på slutet blir då redundant. Och inträffar fel i produktion är man vaken och fixar snabbt felet och skickar ut en rättning. Det går ändå inte att skydda sig helt från produktionssmällar eftersom våra användare och externa system ibland gör helt andra saker än vad vi tänkt oss som ingen testning i världen kan förutse. Bättre då vaka över systemet i drift och att göra det enkelt att skicka ut en rättning. Detta kräver i sin tur en väloljad pipeline hela vägen ut i produktion och nära samarbete med driften. I detta avseende har många fortfarande en bra bit kvar att vandra.

Men å andra sidan, att det finns mycket kul saker kvar att göra är underbart för alla oss som älskar det här jobbet :-)

Publicerad i Continuous Delivery, DevOps, Java, Test

Summering av Jfokus 2015

Inte heller 2015 blir ett sannolikt år för robotarnas övertagande. I sessionen Creating Our Robot Overlords: Autonomous Drone Development vi fick konstaterat att en AR Drone 2.0 inte klarar att bära en Raspberry Pi med batteri och därmed får fortsätta att flyga ointelligent, eftersom att hjärnan fått lämnats kvar på marken. Men inte bara därför – den intelligenta programvaran saknades också.

IMG_20150203_090941

Läs mer ›

Publicerad i Continuous Delivery, DevOps, Java, Uncategorized

Den sista MacBook:en i sitt slag

Mitt MacBook-liv började år 2011. Året därpå hade jag sönder den mekaniska hårddisken, så jag monterade istället en pirat-SSD och ominstallerade OS:et. Året efter det tog utrymmet på den disken slut (500GB) och jag ersatte den sedan länge oanvända och meningslösa optiska enheten med ytterligare en SSD på 1TB. Med 16GB RAM och 1.5TB disk gjorde den sedan susen under lång tid.

Efter att MacBook:en gjort tjänst varje dag i 4 år, började först grafiken spraka till och gjorde så oftare och oftare till dess hela skärmen blev randig och datorn låste sig. Till slut gick den inte ens att starta om.

IMG_20150118_193842

 

Läs mer ›

Publicerad i Java, OS X

Blue Green Deployment

Samarbetet kring vår open source Continuous Delivery Build Pipeline fortsätter i mobbprogrammeringsform. Den här gången bjöd Mikael Sennerholm in till Avega-kontoret på Östermalm eftersom det ryktades att någon en gång hade sett att man minsann kunde locka fram riktigt bra fart i det nätverket.

Vägen till DevOps-nirvanat visade sig gå genom att gräva fram det gamla sladdnätverket igen och plocka upp sin gamla RJ45-utrustning igen från längst ned i byrålådorna hemma, för Wifi fungerar fortfarande inte bra nog för att ladda ned alla maskinavbildningar på rimlig tid.

Men Avega är i gott sällskap, det tog år av tjat innan C.A.G fick ett på riktigt fungerande Wifi-nät med flås på Kista-kontoret. Så det borde väl inte vara helt omöjligt att få till det på Avega heller så småningom.

IMG_20150120_185748

Läs mer ›

Publicerad i Continuous Delivery, DevOps

Infrastruktur som kod

Docker är nästan magiskt. Hur går det till när Docker startar upp en maskin och ett kommando på den maskinen på bara en bråkdel av en sekund?

Men förr eller senare vänjer man sig även vid magi, och Mikael Sennerholm från Avega och jag gjorde till slut en kurs av det, där vi under en heldag gick igenom bland annat Docker, men även Vagrant och Thoughtworks Go. Träning på olika smaker av Linux följde med på köpet. Mikael höll kursen och jag hjälpte till med labbarna.

Screen Shot 2014-11-24 at 22.47.19

 

Läs mer ›

Publicerad i Cloud Computing, Continuous Delivery, DevOps, Java, LinkedIn, Linux

OS X Yosemite för Javautvecklare

Jag uppdaterade min Macbook till Yosemite idag och stötte bara på två små saker. Precis som vid uppdateringen till Mavericks så avinstallerar Apple Java 6. Det medför att IntelliJ inte startar efteråt, då dess launcher är hårdkodad att använda Java 6. Dessutom ser fonterna ut som skit rent ut sagt om man kör IntelliJ på en modern Java från Oracle.

Lösningen är att återinstallera Java 6 från Apple.

Den andra grejen var att Xcode behövde en refresh – av någon anledning hittade inte min installation command-line tools längre. Lösningen:

sudo xcode-select -r
sudo brew update

Efter att man godkänt licensavtalet för Xcode så fungerar Homebrew igen. Att använda sudo här är en engångsgrej efter uppdateringen till Yosemite. Givetvis ska man aldrig använda sudo för att köra brew i vanliga fall.

Ovan gällde för min maskin som hade fulla Xcode installerat sedan tidigare. När jag uppdaterade min nya maskin som bara hade command line tools, så fick man helt enkelt installera om dem:

xcode-select --install

På den maskinen har jag dessutom gått över till att köra Git från Homebrew, så där behövdes ingen uppdatering av command line tools för att göra brew update.

Publicerad i Java, OS X

Automatiskt byggnummer

Varje gång vi bygger en releasekandidat av systemet, deployar till en testmiljö eller kanske bara behöver en version vi vill kunna referera till i exempelvis felrapporter, ska bygget ges ett unikt versionsnummer.

Ett versionsnummer kan vara ett enkelt löpnummer eller kanske bygga på semantic versioning (1.2.42).

Det är praktiskt att tillgängligöra versionsnumret på ett antal olika sätt: Som inspekterbar i artefakten själv i MANIFEST.MF, i Mavens pom-versioner, maskinläsbar i runtime, till exempel i en endpoint /appversion i ett REST-gränssnitt eller synligt i användargränssnittet.

Screen Shot 2014-09-22 at 22.33.23
Läs mer ›

Publicerad i Continuous Delivery, Java, Uncategorized

Kommentarer

Kategorier

LinkedIn Auto Publish Powered By : XYZScripts.com