{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Een beginnershandleiding: een DevOps-pijplijn cre\u00ebren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Als je nieuw bent in DevOps, bekijk dan deze handleiding voor het opzetten van je eerste vijf stappen pipeline.<\/i><\/p>\n

\"Een<\/p>\n

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.<\/p>\n

Mijn reis door DevOps<\/h3>\n

\nPreviously, 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 \u201cThe Phoenix Project\u201d (The Phoenix Project<\/a><\/noindex>), which explains DevOps principles while reading like a novel.<\/p>\n

In the table on the back of the book, it shows how often various companies deploy their systems in a release environment:<\/p>\n

Amazon: 23,000 per day
\nGoogle: 5,500 per day
\nNetflix: 500 per day
\nFacebook: Once a day
\nTwitter: 3 times a week
\nTypical company: Once every 9 months<\/p>\n

How are the frequencies of Amazon, Google, and Netflix even possible? It\u2019s because these companies have figured out how to create an almost perfect DevOps pipeline.
\n<\/a><\/noindex>
\nWe 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.<\/p>\n

I realized that something needed to be done and found a like-minded colleague. We decided to collaborate on creating the initial DevOps pipeline \u2013 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.<\/p>\n

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).<\/p>\n

A brief introduction to DevOps and the CI\/CD pipeline<\/h3>\n

\nAls 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:<\/p>\n

Operaties die vroeger handmatig werden uitgevoerd, zijn geautomatiseerd;
\nIedereen doet waar hij het beste in is;
\nHet aantal implementaties in een bepaalde periode neemt toe; de doorvoer neemt toe;
\nDe flexibiliteit van de ontwikkeling neemt toe.<\/p>\n

Hoewel het hebben van de juiste softwaretools niet het enige is dat nodig is om een DevOps-omgeving te cre\u00ebren, 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.<\/p>\n

In dit artikel wordt een vijf stappen benadering beschreven voor het cre\u00ebren van een DevOps-pijplijn, vergelijkbaar met de afbeelding in de volgende diagram, met gebruik van open-source tools.<\/p>\n

Stap 1: CI\/CD-methoden<\/h3>\n

\nHet 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.<\/p>\n

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.<\/p>\n

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

Jenkins: Creative Commons en MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

Zo zien DevOps-processen eruit met een CI\/CD-tool:<\/p>\n

\"Een<\/p>\n

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.<\/p>\n

Stap 2: Beheer van versiebeheersystemen<\/h3>\n

\nDe 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.<\/p>\n

Hier wordt een bronbeheersysteem bijna een noodzaak. Dit hulpmiddel slaat je code op in repositories, houdt versies bij en co\u00f6rdineert het werk van projectdeelnemers.<\/p>\n

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.<\/p>\n

Git: GPLv2 en LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

Zo ziet een DevOps-pijplijn eruit met de toevoeging van bronbeheertools.<\/p>\n

\"Een<\/p>\n

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?<\/p>\n

Stap 3: Cre\u00ebren van een buildautomatiseringstool<\/h3>\n

\nGeweldig! 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\u00efnterpreteerde programmeertaal, zoals JavaScript of PHP, geen compilatie vereist).<\/p>\n

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\u00ebren afhankelijk van je programmeertaal, maar hier zijn enkele algemene open source opties.<\/p>\n

Naam
\nLicentie
\nProgrammeertaal<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/V<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

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

\"Een<\/p>\n

Alles is goed, toch? Maar waar ga je je applicatie uitrollen?<\/p>\n

Stap 4: Server voor webapplicaties<\/h3>\n

\nTot 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.<\/p>\n

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).<\/p>\n

Er zijn verschillende open source servers voor webapplicaties beschikbaar.<\/p>\n

Naam
\nLicentie
\nProgrammeertaal<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Je DevOps-pijplijn is bijna klaar voor gebruik. Goed gedaan!<\/p>\n

\"Een<\/p>\n

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.<\/p>\n

Stap 5: Testdekking van de code<\/h3>\n

\nHet 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.<\/p>\n

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.<\/p>\n

Code test systemen<\/b><\/p>\n

Naam
\nLicentie
\nProgrammeertaal<\/p>\n

JUnit
\nEclipse Public License
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Aanbevelingssystemen voor codeverbetering<\/b><\/p>\n

Naam
\nLicentie
\nProgrammeertaal<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nCommon Public License
\nJava<\/p>\n

JaCoCo
\n Eclipse Public License
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Let op, de meeste tools en frameworks die hierboven zijn genoemd, zijn geschreven voor Java, Python en JavaScript, aangezien C++ en C# propri\u00ebtaire programmeertalen zijn (hoewel GCC open source heeft).<\/p>\n

Nu je de code testdekkingtools hebt ge\u00efmplementeerd, zou je DevOps-pijplijn eruit moeten zien zoals de diagram die in het begin van deze handleiding is weergegeven.<\/p>\n

Extra stappen<\/h3>\n

\nContainers<\/b><\/p>\n

Zoals ik al zei, je kunt je server hosten op een virtuele machine of server, maar containers zijn een populaire oplossing.<\/p>\n

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.<\/p>\n

Hoewel er andere containeropties zijn, zijn Docker en Kubernetes de meest populaire.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Tussentools voor automatisering<\/b><\/p>\n

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.<\/p>\n

Hier zijn enkele open-source tussentools voor automatisering:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache of GPL<\/p>\n

\"Een<\/p>\n

Ontdek meer over hoe je een gewilde carri\u00e8re vanaf nul kunt opbouwen of een Level Up kunt maken in vaardigheden en salaris door betaalde online cursussen van SkillFactory te volgen:<\/p>\n