's Picture

Fem containers är fler än fyra servrar

Postad av Fredrik Ögren

Det var dags igen, att byta hostingleverantör, och flytta alla system. Något som är en återkommande process för en organisation som är i ständig rörelse.

Utmaningarna den här gången var många, men främst var att vi varken hade tid eller resurser att göra något avbrott i den dagliga utvecklingen och publiceringen.

Ett annat dilemma var att den nuvarande miljön hade växt, organiskt och okontrollerat, över flera år. Varje gång en ny tjänst hade skapats hade fler maskiner beställts.

Traditionellt sett hade flyttprojekt av denna omfattning involverat en mängd migreringskonsulter, projektledare från IT-Stockholms alla hörn och en massiv kopiering av system 1:1, som efter avslutad flytt säkerställt att systemen var lika uråldriga som förut. Men inte denna gång!

Den nystartade DevOps-grupperingen inom Bonnier News, en skara på sex personer, tillsammans med en extern projektledare, tog sig an uppgiften att flytta sex av Sveriges största digitala publikationer, däribland Expressen.se, på lika många månader.

Men inte 1:1. Nej, här behövdes ett nytt tänk, ett som fungerade lika bra i praktiken som det tillgodosedde ledningens krystade buzzwords så som ”Kostnadskostym”, Konsolidering” samt ”Plattformslinjering”.

Expressen hade redan, som står att läsa i Joel Abrahamssons tidigare blogginlägg, ett nytt tänk kring Micro Services. Efter att har räknat igenom alla dessa olika tjänster, och ritat igenom alla tänkbara systemskisser på traditionellt vis, kom vi fram till följande:
Om vi paketerade varje tjänst som en Docker Container, och lät varje Container köra på varsin egen processorkärna så skulle vi riskfritt kunna packa så många tjänster som en maskin hade kärnor, utan att de krockade med varandra. Dessutom skulle det skala linjärt med antalet maskiner vi köpte in (och med lite hjälp av Helios och en egen provisioneringsmall vi tagit fram). Vi köpte även in egen hårdvara för detta, då vi kunde utnyttja systemresurserna maximalt utan all overhead som virtualisering ger.

Men att bara göra Docker Containers av all tjänster och sedan hantera detta på traditionellt sätt skulle ha blivit en mardröm. När man börjar abstrahera maskiner och miljöer från utvecklarna så måste man även gå hela vägen med sättet som man underhåller, övervakar och hanterar denna typ av Micro Service-miljö.
I slutändan byggde vi en miljö från grunden, baserat på Salt där alla miljöer och variabler är scriptade, managering av containers sker via Helios, registrering genom Consul och sedan övervakas det hela via status endpoints genom dess API:er och AlertManager.

I Expressens fall gick vi från 42 virtuella maskiner ner till 12 fysiska hostar. Kapade både drift-, underhåll och övervakningskostnader vid fotknölarna och fick på köpet en helt dynamisk, självunderhållande miljö som i det närmaste går att likna vid en egen privat PaaS.

För att sedan populera den nya miljön med data så replikerade vi våra Elastic Search kluster via RabbitMQ och våra äldre system via Solr och indexreplikering.

I slutändan hade vi två parallella miljöer som båda var uppdaterade med senaste datat, och där migreringen endast bestod i att peka om ett CNAME.

Ibland är det bra att göra slut med gamla sanningar och börja om på nytt. Det är oftast svårt att implementera ny teknik när man sitter fast i gammal legacy som, i bästa fall, får en liten uppgradering av versionsnummer mellan varven.
Kan för visso inte påstå att någon av oss ser fram emot nästa stora migrering, men att ersätta Helios mot Nomad och köra Nano i Containers, blir lagom som nästa utmaning!

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan