streamalism.org

1. Overzicht

In deze tutorial gaan we kijken naar Spinnaker, een open-source platform voor continue levering gebouwd door Netflix. We kunnen het gebruiken om onze applicaties bij meerdere cloudproviders te implementeren.

Het systeem is bovenop Spring Boot gebouwd en ondersteunt veel cloudproviders.

We zullen zien hoe het werkt en voor welke gevallen we het kunnen gebruiken.

2. Achtergrond

Laten we eens kijken naar de geschiedenis van softwareontwikkeling. Ten eerste hadden we de waterval met zeldzame releases.

Daarna zijn we Agile gaan werken en hebben we elke sprint features opgeleverd. We hebben echter nog steeds niet elke sprint in productie genomen. Helaas konden de gebruikers nog steeds geen gebruik maken van de nieuwe functies, die op een plank lagen.

Er waren enkele redenen om niet regelmatig te implementeren. Een daarvan was het feit dat implementatiestappen vaak handmatig werden uitgevoerd en vatbaar waren voor menselijke fouten.

Daarnaast dachten sommigen dat vaker inzetten meer risico op mogelijke problemen betekende. Tegenwoordig zijn we het er grotendeels over eens dat het doorvoeren van kleine veranderingen minder risico op grote fouten met zich meebrengt. Als er toch een fout is gemaakt, kunnen we deze snel vinden in de kleine wijziging en een nieuwe versie uitbrengen die het probleem oplost.

3. Spinnaker

Met Spinnaker kunnen we continue levering of continue implementatie gebruiken om onze applicatie automatisch in productie te brengen. Doorlopende levering betekent dat alles is voorbereid op een productievrijgave.

De release wordt echter handmatig goedgekeurd voordat de applicatie in productie wordt genomen. Door de continue inzet is er geen handmatige tussenkomst. Alle stappen worden uitgevoerd, inclusief de implementatie naar productie. We pushen gewoon onze applicatiecode naar een versiebeheersysteem en dat is alles.

Van het pushen van onze code tot versiebeheer tot de implementatie tot productie, we kunnen veel stappen uitvoeren. We kunnen onze code bouwen, de code unit testen, deze in een testomgeving implementeren en functionele tests uitvoeren. We gebruiken een zogenaamde pipeline om al die stappen te configureren.

Met Spinnaker kunnen we zo'n pijplijn creëren en onze applicatie op de meeste cloudproviders inzetten.

4. Componenten

Spinnaker bestaat in feite uit twee delen: een abstractielaag bovenop verschillende cloudproviders en een tool voor continue levering.

4.1. Traditionele cloudimplementaties

Als we kijken naar cloudproviders, bieden ze allemaal min of meer dezelfde diensten aan. Deze services omvatten zaken als instances, serverless en containerondersteuning.

De configuratie van die services verschilt echter sterk tussen de providers. Dat maakt het moeilijker om tussen providers te wisselen. Het kost wat tijd om naar een andere cloudprovider te verhuizen en alle details te leren, wat betekent dat we in feite een vendor lock-in hebben met onze cloudprovider.

Netflix wilde de mogelijkheid hebben om gemakkelijk tussen cloudproviders te schakelen, in plaats van afhankelijk te zijn van slechts één. Daarom bouwden ze een abstractielaag bovenop de cloudproviders.

4.2. Abstractielaag

Wanneer we Spinnaker gebruiken, is het hetzelfde voor alle cloudproviders. We kunnen het gebruiken op Amazon Web Services, Microsoft Azure, Google Cloud Platform, OpenStack, Google App Engine of Kubernetes. Hierdoor kunnen we overstappen naar een andere cloudprovider als de prijzen concurrerender zijn.

Sterker nog, we kunnen ervoor kiezen om bij meerdere providers tegelijk in te zetten. Op die manier kunnen we onze applicatie op twee of meer providers draaien voor extra redundantie.

Een ander voordeel van de abstractielaag is dat deze zich richt op de applicaties in plaats van op de bronnen. Normaal gesproken laten cloudproviders ons de bronnen zien die we momenteel gebruiken. We moeten echter zelf uitzoeken welke applicatie welke bronnen gebruikt.

Maar middelen zijn voor ons niet interessant. We willen onze applicatie draaien zonder tijd te besteden aan het bijhouden van bronnen. Spinnaker heeft een toepassingsgerichte visie. Dus als we ernaar kijken, zien we eerst de applicatie en dan zien we de bronnen die door de applicatie worden gebruikt.

4.3. Continue levering

Bovenop de abstractielaag bouwde Netflix een continu leveringsplatform. Dit platform stelt ons in staat om onze applicatie op een of meerdere cloudproviders in te zetten. Het lijkt een beetje op Jenkins, maar biedt een betere integratie met de cloudproviders en vereist minder configuratie.

We kunnen bijvoorbeeld de pijplijn voor continue levering activeren vanuit Jenkins, een geüploade Docker-image of een git push. Daarna kunnen we eenvoudig een afbeelding of een container maken met onze applicatie en deze in productie starten.

Er zijn echter veel meer opties beschikbaar, zoals geautomatiseerde tests en handmatige goedkeuringen voordat deze in productie worden genomen.

We kunnen zelfs beslissen welke strategie we willen volgen bij het implementeren van een nieuwe versie van een bestaande applicatie. Hierdoor is het mogelijk om de oude versie eenvoudig te vervangen door de nieuwe. Een betere strategie zou echter zijn om ze eerst naast elkaar te houden. Op die manier kunnen we automatisch of handmatig controleren of de nieuwe versie werkt en, zo ja, de oude versie verwijderen.

5. Het Netflix-cloudmodel

Elke applicatie bestaat uit een of meer servergroepen. Dezelfde versie van de applicatie draait op alle instanties in de servergroep. De volgende naamgevingsconventie wordt gebruikt: ---. Het (optionele) stapelveld wordt gebruikt om aan te geven of de servergroep bedoeld is voor test-, productie- of andere doeleinden. Het optionele detailveld wordt gebruikt voor extra informatie.

Ten slotte hebben we het concept van een cluster dat een of meer servergroepen bevat met dezelfde naam, stapel en detail. Meestal voert elke servergroep in het cluster echter een andere versie van de toepassing uit. Falende instanties worden vervangen door een nieuwe instantie.

Het is ook mogelijk om automatisch instanties aan een servergroep toe te voegen om de verhoogde belasting op te vangen.

6. Implementatiestrategie

Wanneer we een nieuwe versie van een applicatie implementeren, wordt normaal gesproken de ‘rood / zwart'-strategie gekozen. Eerst wordt een nieuwe servergroep met de nieuwe versie van de applicatie in het cluster geïmplementeerd. Na de implementatie van de applicatie wordt gecontroleerd of de nieuwe servergroep in orde is.

Nu is de servergroep ingeschakeld en beschikbaar voor onze klanten. Ten slotte is de oude servergroep uitgeschakeld.

In dit scenario is het gemakkelijk terug te draaien als er iets misgaat met de nieuwe applicatieserver. We kunnen de servergroep met de oude versie gewoon weer inschakelen en beschikbaar stellen aan onze klanten.

7. Waarom Spinnaker

Met Spinnaker kunnen we ons concentreren op onze applicatie in plaats van op de cloudbronnen die we gebruiken. Dit maakt het eenvoudiger om onze applicaties te implementeren en te onderhouden.

Bovendien maakt Spinnaker het mogelijk om op meerdere cloudproviders tegelijk te draaien. Bovendien kunnen we gemakkelijk overschakelen naar andere cloudproviders, afhankelijk van hun prijsstrategie en beschikbare functies.

8. Conclusie

Spinnaker bouwt voort op de ervaring van Netflix. We kunnen hun kennis gebruiken en met minimale inspanning op dezelfde manier werken. Op basis van deze tools kunnen we eenvoudig een implementatiepijplijn implementeren om onze applicaties in productie te nemen.

Download het gratis e-boek Continuous Delivery with Spinnaker voor meer informatie over Spinnaker.