🥇 Beginnersgids: een DevOps-pijplijn opzetten

Als je nieuw bent in DevOps, bekijk dan deze handleiding voor het opzetten van je eerste vijf stappen pipeline.

DevOps is de standaardoplossing geworden voor het verhelpen van trage, gefragmenteerde of niet-functionerende softwareontwikkelingsprocessen. Het probleem is dat als je nieuw bent in DevOps en niet weet waar te beginnen, je mogelijk een gebrek aan begrip van deze methoden hebt. Dit artikel gaat over de definitie van een DevOps-pipeline en biedt een stapsgewijze handleiding voor het opzetten ervan. Hoewel deze gids niet allesomvattend is, zou het je een basis moeten geven om je reis te beginnen en je kennis in de toekomst uit te breiden. Maar laten we beginnen met de geschiedenis.

Mijn reis door DevOps

Previously, I worked in the cloud team at Citi Group, developing a web application Infrastructure-as-a-Service (IaaS) for managing Citi's cloud infrastructure, but I was always interested in how to make the development process more efficient and bring positive cultural changes to the development team. The answer I found in a book recommended by Greg Lavender, Citi's chief technical officer for cloud architecture and infrastructure. The book was called “The Phoenix Project” (The Phoenix Project), which explains DevOps principles while reading like a novel.

In the table on the back of the book, it shows how often various companies deploy their systems in a release environment:

Amazon: 23,000 per day
Google: 5,500 per day
Netflix: 500 per day
Facebook: Once a day
Twitter: 3 times a week
Typical company: Once every 9 months

How are the frequencies of Amazon, Google, and Netflix even possible? It’s because these companies have figured out how to create an almost perfect DevOps pipeline.

We were far from it until we implemented DevOps at Citi. At that time, my team had different environments, but deployment on the development server was entirely manual. All developers had access to only one development server based on IBM WebSphere Application Server Community Edition. The problem was that the server would shut down every time multiple users attempted to deploy simultaneously, so developers had to inform each other of their intentions, which was quite painful. Additionally, there were issues with low-level test coverage of the code, cumbersome manual deployment processes, and a lack of the ability to track code deployments related to a specific task or user story.

I realized that something needed to be done and found a like-minded colleague. We decided to collaborate on creating the initial DevOps pipeline – he set up a virtual machine and Tomcat application server while I worked on Jenkins, integrated Atlassian Jira and BitBucket, and focused on code test coverage. This side project was very successful: we almost completely automated many processes, achieved nearly 100% uptime of our development server, enabled tracking, improved code test coverage, and added the capability to link branches in Git with tasks in Jira or deployments. Most of the tools we used to build our DevOps pipeline were open source.

Now I understand how simple our DevOps pipeline was: we didn't use extensions like Jenkins files or Ansible. However, this simple pipeline worked well, possibly due to the Pareto principle (also known as the 80/20 rule).

A brief introduction to DevOps and the CI/CD pipeline

Als je een aantal mensen zou vragen: 'Wat is DevOps?', krijg je waarschijnlijk verschillende antwoorden. DevOps, net als Agile, is ontstaan om verschillende disciplines te omvatten, maar de meeste mensen zijn het erover eens dat DevOps een software ontwikkelingspraktijk of software ontwikkelingscyclus (SDLC) is, waarvan het centrale principe de verandering van cultuur is, waarin ontwikkelaars en niet-ontwikkelaars bestaan in een omgeving waarin:

Operaties die vroeger handmatig werden uitgevoerd, zijn geautomatiseerd;
Iedereen doet waar hij het beste in is;
Het aantal implementaties in een bepaalde periode neemt toe; de doorvoer neemt toe;
De flexibiliteit van de ontwikkeling neemt toe.

Hoewel het hebben van de juiste softwaretools niet het enige is dat nodig is om een DevOps-omgeving te creëren, zijn sommige tools essentieel. Een belangrijke tool is continue integratie en continue uitrol (CI/CD). In deze pijplijn zijn er verschillende fasen (bijv. DEV, INT, TST, QA, UAT, STG, PROD), veel operaties zijn geautomatiseerd, en ontwikkelaars kunnen hoogwaardige code schrijven, de ontwikkeling flexibiliteit behalen en een hoge frequentie van uitrol realiseren.

In dit artikel wordt een vijf stappen benadering beschreven voor het creëren van een DevOps-pijplijn, vergelijkbaar met de afbeelding in de volgende diagram, met gebruik van open-source tools.

Stap 1: CI/CD-methoden

Het eerste wat je nodig hebt, is een tool voor CI/CD. Jenkins, een open-source tool, gebaseerd op Java en verspreid onder de MIT-licentie, is het middel dat de richting van DevOps heeft gepopulariseerd en de facto standaard is geworden.

Wat is Jenkins? Beschouw het als een soort magische universele afstandsbediening die kan communiceren met verschillende services en tools en deze kan organiseren. CI/CD-tools zoals Jenkins zijn op zichzelf nutteloos, maar worden krachtiger naarmate ze worden aangesloten op verschillende tools en services.

Jenkins is slechts een van de vele open-source tools voor CI/CD die je kunt gebruiken om een DevOps-pijplijn te bouwen.

Jenkins: Creative Commons en MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Zo zien DevOps-processen eruit met een CI/CD-tool:

Je hebt een CI/CD-tool die op je localhost draait, maar op dit moment kun je er niet veel mee doen. Laten we naar de volgende fase van de reis in de wereld van DevOps gaan.

Stap 2: Beheer van versiebeheersystemen

De beste (en misschien wel eenvoudigste) manier om te controleren of jouw CI/CD-tool magie kan verrichten, is door deze te integreren met een bronbeheersysteem (SCM). Waarom heb je versiebeheer nodig? Stel dat je een applicatie ontwikkelt. Elke keer dat je een applicatie maakt, programmeer je, ongeacht of je Java, Python, C++, Go, Ruby, JavaScript of een van de vele andere programmeertalen gebruikt. De code die je schrijft, wordt broncode genoemd. In het begin, vooral wanneer je alleen werkt, kun je waarschijnlijk alles in een lokale map plaatsen. Maar als het project groter wordt en je anderen uitnodigt om samen te werken, heb je een manier nodig om conflicten te voorkomen bij een effectieve uitwisseling van aanpassingen. Je hebt ook een manier nodig om eerdere versies te herstellen, want het maken van back-ups en het knippen/plakken in die versies is inmiddels verouderd. Jij (en jouw teamgenoten) hebben iets beters nodig.

Hier wordt een bronbeheersysteem bijna een noodzaak. Dit hulpmiddel slaat je code op in repositories, houdt versies bij en coördineert het werk van projectdeelnemers.

Hoewel er veel bronbeheertools zijn, is Git de standaard, en dat is terecht. Ik raad ten zeerste aan om Git te gebruiken, hoewel er ook andere open-source opties zijn als dat nodig is.

Git: GPLv2 en LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Zo ziet een DevOps-pijplijn eruit met de toevoeging van bronbeheertools.

Een CI/CD-tool kan de processen van het controleren, ophalen van broncode en samenwerking tussen teamleden automatiseren. Niet slecht? Maar hoe maak je hier een werkende applicatie van zodat miljarden mensen deze kunnen gebruiken en waarderen?

Stap 3: Creëren van een buildautomatiseringstool

Geweldig! Je kunt de code controleren en wijzigingen aanbrengen in het versiebeheersysteem, evenals je vrienden uitnodigen om samen te werken aan de ontwikkeling. Maar je hebt nog geen applicatie gemaakt. Om een webapplicatie te maken, moet deze worden samengesteld en verpakt in een uitrolbaar pakketformaat of als uitvoerbaar bestand worden uitgevoerd. (Houd er rekening mee dat een geïnterpreteerde programmeertaal, zoals JavaScript of PHP, geen compilatie vereist).

Maak gebruik van een buildautomatiseringstool. Ongeacht welke buildautomatiseringstool je besluit te gebruiken, ze hebben allemaal hetzelfde doel: de broncode samen te stellen in een gewenste indeling en de taken van opschonen, compileren, testen en uitrollen in een bepaalde omgeving te automatiseren. De buildtools zullen variëren afhankelijk van je programmeertaal, maar hier zijn enkele algemene open source opties.

Naam
Licentie
Programmeertaal

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/V

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Fantastisch! Je kunt de configuratiebestanden van de buildautomatiseringstool in het versiebeheersysteem plaatsen en je CI/CD-tool laten alles samenvoegen.

Alles is goed, toch? Maar waar ga je je applicatie uitrollen?

Stap 4: Server voor webapplicaties

Tot nu toe heb je een verpakt bestand dat zowel uitvoerbaar als installeerbaar kan zijn. Om een applicatie echt nuttig te maken, moet deze een bepaalde dienst of interface bieden, maar je hebt een container nodig om je applicatie te hosten.

Een server voor webapplicaties is precies zo'n container. De server biedt een omgeving waarin de logica van het uitrolbare pakket kan worden gedefinieerd. Daarnaast biedt de server een interface en biedt het webservices door poorten voor de buitenwereld open te stellen. Je hebt een HTTP-server nodig, evenals een soort omgeving (bijvoorbeeld een virtuele machine) voor de installatie. Laten we ondertussen aannemen dat je hier verderover leert (hoewel ik hieronder over containers zal vertellen).

Er zijn verschillende open source servers voor webapplicaties beschikbaar.

Naam
Licentie
Programmeertaal

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

Je DevOps-pijplijn is bijna klaar voor gebruik. Goed gedaan!

Hoewel je hier kunt stoppen en zelf met integratie aan de slag kunt gaan, is de kwaliteit van de code een belangrijke factor voor applicatieontwikkelaars, en daar moet je je zorgen over maken.

Stap 5: Testdekking van de code

Het implementeren van tests kan een andere tijdrovende eis zijn, maar ontwikkelaars moeten eventuele fouten in de applicatie vroegtijdig opsporen en de kwaliteit van de code verbeteren om ervoor te zorgen dat eindgebruikers tevreden zijn. Gelukkig zijn er tal van open-source tools beschikbaar voor het testen van je code en het geven van aanbevelingen voor verbeteringen. Nog beter is dat de meeste CI/CD-tools met deze tools kunnen worden verbonden en het proces kunnen automatiseren.

Code testen bestaat uit twee delen: testframeworks die helpen bij het schrijven en uitvoeren van tests, en tools die aanbevelingen doen om de kwaliteit van de code te verbeteren.

Code test systemen

Naam
Licentie
Programmeertaal

JUnit
Eclipse Public License
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Aanbevelingssystemen voor codeverbetering

Naam
Licentie
Programmeertaal

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Eclipse Public License
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Let op, de meeste tools en frameworks die hierboven zijn genoemd, zijn geschreven voor Java, Python en JavaScript, aangezien C++ en C# propriëtaire programmeertalen zijn (hoewel GCC open source heeft).

Nu je de code testdekkingtools hebt geïmplementeerd, zou je DevOps-pijplijn eruit moeten zien zoals de diagram die in het begin van deze handleiding is weergegeven.

Extra stappen

Containers

Zoals ik al zei, je kunt je server hosten op een virtuele machine of server, maar containers zijn een populaire oplossing.

Wat zijn containers? In het kort heeft een virtuele machine een enorme hoeveelheid geheugen van het besturingssysteem nodig, die groter is dan de grootte van de applicatie, terwijl een container slechts enkele bibliotheken en configuraties nodig heeft om de applicatie uit te voeren. Het is duidelijk dat virtuele machines nog steeds belangrijke toepassingen hebben, maar een container is een lichte oplossing voor het hosten van applicaties, inclusief applicatieservers.

Hoewel er andere containeropties zijn, zijn Docker en Kubernetes de meest populaire.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Tussentools voor automatisering

Onze DevOps-pijplijn is voornamelijk gericht op het gezamenlijk ontwikkelen en in productie nemen van applicaties, maar er zijn talloze andere dingen die je kunt doen met DevOps-tools. Een daarvan is het gebruik van Infrastructure as Code (IaC)-tools, ook wel bekend als tussentools voor automatisering. Deze tools helpen bij het automatiseren van de installatie, het beheer en andere taken voor tussenliggende software. Zo kan een automatiseringstool bijvoorbeeld applicaties zoals een webapplicatieserver, database en monitoringtool met de juiste configuraties extraheren en ze op de applicatieserver in productie nemen.

Hier zijn enkele open-source tussentools voor automatisering:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache of GPL

Ontdek meer over hoe je een gewilde carrière vanaf nul kunt opbouwen of een Level Up kunt maken in vaardigheden en salaris door betaalde online cursussen van SkillFactory te volgen: