Als u nieuw bent bij DevOps, bekijk dan deze handleiding in vijf stappen voor het maken van uw eerste pijplijn.
DevOps is de standaardoplossing geworden voor het repareren van trage, onsamenhangende of kapotte softwareontwikkelingsprocessen. Het probleem is dat als je nieuw bent bij DevOps en niet weet waar je moet beginnen, je mogelijk geen inzicht hebt in deze technieken. In dit artikel wordt de definitie van een DevOps-pijplijn besproken en worden ook instructies in vijf stappen gegeven voor het maken ervan. Hoewel deze tutorial niet uitputtend is, zou het je een basis moeten geven om aan je reis te beginnen en je kennis in de toekomst uit te breiden. Maar laten we beginnen met de geschiedenis.
Mijn DevOps-reis
Ik heb eerder in het cloudteam van de Citi Group gewerkt aan de ontwikkeling van een Infrastructure-as-a-Service (IaaS)-webapplicatie om de cloudinfrastructuur van Citi te beheren, maar ik was altijd geïnteresseerd in hoe ik het ontwikkelingsproces efficiënter kon maken en een positieve culturele verandering in de wereld kon bewerkstelligen. ontwikkelingsteam. Ik vond het antwoord in een boek aanbevolen door Greg Lavender, CTO van Cloud Architecture and Infrastructure bij Citi. Het boek heette The Phoenix Project (), en het legt de principes van DevOps uit, maar het leest als een roman.
De tabel achterin het boek laat zien hoe vaak verschillende bedrijven hun systemen inzetten in een release-omgeving:
Amazon: 23 per dag
Google: 5 per dag
Netflix: 500 per dag
Facebook: Eén keer per dag
Twitter: 3 keer per week
Typisch bedrijf: Eens in de 9 maanden
Hoe zijn Amazon-, Google- en Netflix-frequenties überhaupt mogelijk? Dit komt omdat deze bedrijven hebben ontdekt hoe ze een bijna perfecte DevOps-pijplijn kunnen creëren.
Totdat we DevOps bij Citi implementeerden, waren we daar nog lang niet mee bezig. Destijds had mijn team verschillende omgevingen, maar de implementatie op de ontwikkelserver gebeurde volledig handmatig. Alle ontwikkelaars hadden toegang tot slechts één ontwikkelingsserver gebaseerd op IBM WebSphere Application Server Community Edition. Het probleem was dat de server werd uitgeschakeld wanneer meerdere gebruikers tegelijkertijd probeerden te implementeren, dus moesten de ontwikkelaars hun bedoelingen aan elkaar communiceren, wat behoorlijk lastig was. Bovendien waren er problemen met de dekking van testcodes op laag niveau, omslachtige handmatige implementatieprocessen en het onvermogen om de implementatie van code te volgen die aan een specifieke taak of gebruikersverhaal was gekoppeld.
Ik besefte dat er iets moest gebeuren en vond een gelijkgestemde collega. We besloten samen te werken bij het bouwen van de eerste DevOps-pijplijn. Hij zette een virtuele Tomcat-machine en applicatieserver op terwijl ik aan Jenkins werkte, integreerde Atlassian Jira en BitBucket en werkte aan de dekking van de testcode. Dit zijproject was zeer succesvol: we hebben veel processen bijna volledig geautomatiseerd, bijna 100% uptime op onze ontwikkelingsserver bereikt, tracking en verbeterde testdekking van de code verzorgd, en de mogelijkheid toegevoegd om Git-takken te koppelen aan Jira-problemen of -implementaties. De meeste tools die we gebruikten om onze DevOps-pijplijn te bouwen, waren open source.
Nu begrijp ik hoe eenvoudig onze DevOps-pijplijn was: we gebruikten geen extensies zoals Jenkins-bestanden of Ansible. Deze eenvoudige pijplijn werkte echter goed, wellicht dankzij het Pareto-principe (ook wel de 80/20-regel genoemd).
Een korte introductie tot DevOps en de CI/CD-pijplijn
Als je aan meerdere mensen vraagt: “Wat is DevOps?”, krijg je waarschijnlijk verschillende antwoorden. DevOps is, net als Agile, geëvolueerd om veel verschillende disciplines te omvatten, maar de meeste mensen zullen het over een paar dingen eens zijn: DevOps is een softwareontwikkelingspraktijk of softwareontwikkelingslevenscyclus (SDLC), waarvan het centrale principe het veranderen van de cultuur is waarin ontwikkelaars en niet-ontwikkelaars ontwikkelaars bevinden zich in een omgeving waarin:
Bewerkingen die voorheen handmatig werden uitgevoerd, zijn geautomatiseerd;
Iedereen doet waar hij goed in is;
Het aantal implementaties over een bepaalde periode neemt toe; De doorvoer neemt toe;
Grotere ontwikkelingsflexibiliteit.
Hoewel het hebben van de juiste softwaretools niet het enige is dat u nodig heeft om een DevOps-omgeving te creëren, zijn sommige tools essentieel. Een belangrijk hulpmiddel is continue integratie en continue implementatie (CI/CD). In deze pijplijn hebben omgevingen verschillende fasen (bijvoorbeeld DEV, INT, TST, QA, UAT, STG, PROD), zijn veel bewerkingen geautomatiseerd en kunnen ontwikkelaars code van hoge kwaliteit schrijven, ontwikkelingsflexibiliteit en hoge implementatiesnelheden bereiken.
In dit artikel wordt een aanpak in vijf stappen beschreven voor het maken van een DevOps-pijplijn, zoals weergegeven in het volgende diagram, met behulp van open source-tools.
Stap 1: CI/CD-methoden
Het eerste dat u nodig heeft, is een CI/CD-tool. Jenkins, een open source tool gebaseerd op Java en gelicentieerd onder de MIT-licentie, is de tool die DevOps populair heeft gemaakt en de de facto standaard is geworden.
Dus wat is Jenkins? Zie het als een soort magische universele afstandsbediening die kan praten met verschillende diensten en tools en deze kan organiseren. Op zichzelf is een CI/CD-tool als Jenkins nutteloos, maar hij wordt krachtiger naarmate hij verbinding maakt met verschillende tools en services.
Jenkins is slechts een van de vele open source CI/CD-tools die u kunt gebruiken om uw DevOps-pijplijn op te bouwen.
Jenkins: Creative Commons en MIT
Travis CI: MIT
Cruisecontrol:BSD
Bouwbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Zo zien DevOps-processen eruit met een CI/CD-tool:
Er draait een CI/CD-tool op uw localhost, maar u kunt momenteel niet veel doen. Laten we verder gaan naar de volgende fase van het DevOps-traject.
Stap 2: Beheer broncontrolesystemen
De beste (en misschien wel gemakkelijkste) manier om te verifiëren dat uw CI/CD-tool zijn magie kan doen, is door deze te integreren met een SCM-tool (source code control). Waarom heb je broncontrole nodig? Stel dat u een applicatie ontwikkelt. Wanneer u een applicatie maakt, bent u aan het programmeren, en het maakt niet uit of u Java, Python, C++, Go, Ruby, JavaScript of een van de ontelbare programmeertalen gebruikt. De code die je schrijft heet broncode. In het begin, vooral als je alleen werkt, is het waarschijnlijk geen probleem om alles in een lokale map te plaatsen. Maar naarmate het project groter wordt en u andere mensen uitnodigt om samen te werken, heeft u een manier nodig om conflicten te voorkomen en tegelijkertijd wijzigingen effectief te delen. Je hebt ook een manier nodig om eerdere versies te herstellen, omdat het maken van back-ups en het kopiëren/plakken daarin verouderd raakt. Jij (en je teamgenoten) hebben iets beters nodig.
Dit is waar broncodecontrole bijna een noodzaak wordt. Deze tool slaat uw code op in repositories, houdt versies bij en coördineert het werk van projectdeelnemers.
Hoewel er veel tools voor broncontrole bestaan, is Git de standaard, en terecht. Ik raad ten zeerste aan om Git te gebruiken, hoewel er ook andere open source-opties zijn als je dat liever hebt.
Git: GPLv2 en LGPL v2.1
Subversie: Apache 2.0
Systeem voor gelijktijdige versies (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Zo ziet een DevOps-pijplijn eruit met de toevoeging van broncodecontroles.
Een CI/CD-tool kan de processen van beoordeling, broncodeverwerving en samenwerking tussen leden automatiseren. Niet slecht? Maar hoe maak je er een werkende applicatie van, zodat miljarden mensen het kunnen gebruiken en waarderen?
Stap 3: Maak een bouwautomatiseringstool
Geweldig! U kunt code beoordelen en wijzigingen aanbrengen in het bronbeheer, en uw vrienden uitnodigen om samen te werken aan de ontwikkeling. Maar u heeft nog geen applicatie gemaakt. Om een webapplicatie te maken, moet deze worden gecompileerd en verpakt in een inzetbaar batchformaat of worden uitgevoerd als een uitvoerbaar bestand. (Merk op dat een geïnterpreteerde programmeertaal zoals JavaScript of PHP niet gecompileerd hoeft te worden).
Gebruik een tool voor bouwautomatisering. Welke tool voor bouwautomatisering u ook besluit te gebruiken, ze hebben allemaal hetzelfde doel: de broncode in een gewenst formaat bouwen en de taak van het opschonen, compileren, testen en implementeren in een specifieke omgeving automatiseren. Bouwtools variëren afhankelijk van uw programmeertaal, maar hier zijn enkele veelvoorkomende open source-opties.
Naam
Licentie
Programmeertaal
Maven
Apache 2.0
Java
Mier
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
Merk
GNU
NB
knorren
MIT
JavaScript
Slok
MIT
JavaScript
bouwr
apache
Ruby
Hark
MIT
Ruby
AAP
GNU
Python
SConen
MIT
Python
BitBake
GPLv2
Python
Taart
MIT
C#
aSDF
Expat (MIT)
LISPELEN
compleet
BSD
Haskell
Geweldig! U kunt de configuratiebestanden van de build-automatiseringstool in uw broncontrolesysteem plaatsen en uw CI/CD-tool alles laten samenstellen.
Alles is in orde, nietwaar? Maar waar moet u uw applicatie inzetten?
Stap 4: Webapplicatieserver
Voorlopig heb je een verpakt bestand dat zowel uitvoerbaar als installeerbaar kan zijn. Wil elke applicatie echt nuttig zijn, dan moet deze een soort service of interface bieden, maar je hebt een container nodig om je applicatie te hosten.
Een webapplicatieserver is zo'n container. De server biedt een omgeving waarin de logica van het pakket dat wordt geïmplementeerd, kan worden gedefinieerd. De server biedt ook een interface en biedt webservices door sockets bloot te stellen aan de buitenwereld. Je hebt een HTTP-server nodig, evenals een omgeving (zoals een virtuele machine) om deze te installeren. Laten we er voorlopig van uitgaan dat u hier meer over te weten komt (hoewel ik hieronder de containers zal bespreken).
Er zijn verschillende open source webapplicatieservers.
Naam
Licentie
Programmeertaal
Kater
Apache 2.0
Java
Steiger
Apache 2.0
Java
Wilde vlieg
GNU Klein Publiek
Java
GlassFish
CDDL & GNU Minder publiek
Java
Django
3-clausule BSD
Python
Tornado
Apache 2.0
Python
gunicorn
MIT
Python
Python
MIT
Python
Rails
MIT
Ruby
Node.js
MIT
Javascript
Uw DevOps-pijplijn is bijna klaar voor gebruik. Goed gedaan!
Hoewel u daar kunt stoppen en de integratie zelf kunt afhandelen, is codekwaliteit voor een app-ontwikkelaar belangrijk om zich zorgen over te maken.
Stap 5: Dekking van codetests
Het implementeren van tests kan een andere omslachtige vereiste zijn, maar ontwikkelaars moeten eventuele bugs in de applicatie vroegtijdig ontdekken en de kwaliteit van de code verbeteren om ervoor te zorgen dat eindgebruikers tevreden zijn. Gelukkig zijn er veel open source-tools waarmee je je code kunt testen en aanbevelingen kunt doen om de kwaliteit ervan te verbeteren. Wat nog beter is, is dat de meeste CI/CD-tools verbinding kunnen maken met deze tools en het proces kunnen automatiseren.
Het testen van code bestaat uit twee delen: raamwerken voor het testen van code waarmee u tests kunt schrijven en uitvoeren, en suggestietools waarmee u de kwaliteit van uw code kunt verbeteren.
Codetestsystemen
Naam
Licentie
Programmeertaal
JUnit
Eclipse Public License
Java
GemakkelijkMock
apache
Java
mockito
MIT
Java
PowerMock
Apache 2.0
Java
Pytest
MIT
Python
Hypothese
mozilla
Python
Tox
MIT
Python
Aanbevelingssystemen voor codeverbetering
Naam
Licentie
Programmeertaal
Dekking
GNU
Java
CodeCover
Eclipse Openbaar (EPL)
Java
Dekking.py
Apache 2.0
Python
Emma
Gemeenschappelijke openbare licentie
Java
JaCoCo
Eclipse Public License
Java
Hypothese
mozilla
Python
Tox
MIT
Python
Jasmijn
MIT
JavaScript
Karma
MIT
JavaScript
Mocha
MIT
JavaScript
er is
MIT
JavaScript
Houd er rekening mee dat de meeste hierboven genoemde tools en frameworks zijn geschreven voor Java, Python en JavaScript, aangezien C++ en C# eigen programmeertalen zijn (hoewel GCC open source is).
Nu u testdekkingstools hebt geïmplementeerd, zou uw DevOps-pijplijn er ongeveer zo uit moeten zien als het diagram aan het begin van deze zelfstudie.
Aanvullende stappen
containers
Zoals ik al zei, kun je je server hosten op een virtuele machine of een server, maar containers zijn een populaire oplossing.
Wat zijn containers? De korte verklaring is dat een virtuele machine een enorme hoeveelheid besturingssysteemgeheugen nodig heeft, groter dan de grootte van de applicatie, terwijl een container slechts een paar bibliotheken en configuraties nodig heeft om de applicatie uit te voeren. Uiteraard zijn er nog steeds belangrijke toepassingen voor een virtuele machine, maar een container is een lichtgewicht oplossing voor het hosten van een applicatie, inclusief een applicatieserver.
Hoewel er andere containeropties zijn, zijn Docker en Kubernetes de meest populaire.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Middelmatige automatiseringstools
Onze DevOps-pijplijn is primair gericht op het gezamenlijk creëren en implementeren van applicaties, maar er zijn nog veel meer dingen die kunnen worden gedaan met DevOps-tools. Eén daarvan is het gebruik van Infrastructure as Code (IaC)-tools, ook wel middleware-automatiseringstools genoemd. Deze hulpprogramma's helpen bij het automatiseren van de installatie, het beheer en andere taken voor middleware. Een automatiseringstool kan bijvoorbeeld applicaties zoals een webapplicatieserver, een database en een monitoringtool met de juiste configuraties extraheren en deze op de applicatieserver implementeren.
Hier zijn enkele open source middleware-automatiseringstools:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef-kok: Apache 2.0
Marionet: Apache of GPL
Ontdek details over hoe u een gewild beroep helemaal opnieuw kunt opbouwen of een hoger niveau kunt bereiken in termen van vaardigheden en salaris door betaalde online cursussen van SkillFactory te volgen:
- (12 maanden)
meer cursussen
- (12 weken)
- (12 maanden)
- (9 maanden)
- (9 maanden)
bruikbaar
Bron: www.habr.com