{"id":33504,"date":"2019-10-31T21:52:58","date_gmt":"2019-10-31T18:52:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom\/"},"modified":"2019-10-31T21:52:58","modified_gmt":"2019-10-31T18:52:58","slug":"rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","title":{"rendered":"Een beginnershandleiding: het cre\u00ebren van DevOps-ketens met open-source tools","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Een
\nHet opzetten van de eerste DevOps-keten in vijf stappen voor beginners.<\/em><\/p>\n

<\/p>\n

DevOps is een panacee geworden voor te trage, gefragmenteerde en andere problematische ontwikkelingsprocessen. Maar er zijn minimale kennis van DevOps nodig. We zullen concepten bespreken zoals de DevOps-keten en hoe deze in vijf stappen kan worden opgezet. Dit is geen volledig handboek, maar slechts een 'vis' die verder kan worden uitgebreid. Laten we beginnen bij het begin.<\/p>\n

<\/p>\n

Mijn kennismaking met DevOps<\/h3>\n

<\/p>\n

Enige tijd geleden werkte ik met cloudoplossingen bij Citi Group en ontwikkelde ik een IaaS-webapplicatie om de cloudinfrastructuur van Citi te beheren, maar ik was altijd benieuwd hoe je de ontwikkelingsketen kon optimaliseren en de cultuur onder ontwikkelaars kon verbeteren. Greg Lavender, onze CTO voor cloudarchitectuur en infrastructuur, raadde me een boek aan Het project \"Phoenix\"<\/a><\/noindex>. Het legt de principes van DevOps prachtig uit en leest als een roman.<\/p>\n

<\/a><\/noindex><\/p>\n

In de tabel aan de achterkant wordt getoond hoe vaak bedrijven nieuwe versies uitrollen:<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Hoe slagen Amazon, Google en Netflix erin om zoveel releases te doen? Het antwoord is simpel: ze hebben begrepen hoe ze een bijna perfecte DevOps-keten moeten cre\u00ebren.<\/p>\n

<\/p>\n

Bij Citi was het helemaal niet zo until we zijn overgestapt op DevOps. Toen had mijn team verschillende omgevingen, maar de levering aan de ontwikkelingsserver deden we handmatig. Alle ontwikkelaars hadden toegang tot slechts \u00e9\u00e9n ontwikkelingsserver op basis van IBM WebSphere Application Server Community Edition. Bij gelijktijdige pogingen om te leveren, viel de server uit en moesten we elke keer 'pijnlijk' onderhandelen. En bovendien hadden we onvoldoende testdekking, een arbeidsintensief handmatig leveringsproces, en geen mogelijkheid om de codelevering te volgen op basis van een bepaalde taak of klantvraag.<\/p>\n

<\/p>\n

Het was duidelijk dat er dringend iets moest gebeuren, en ik vond een medegrondlegger. We besloten samen de eerste DevOps-keten op te zetten \u2013 hij configureerde een virtuele machine en de Tomcat-applicatieserver, terwijl ik verantwoordelijk was voor Jenkins, de integratie met Atlassian Jira en BitBucket, en de testdekking. Het project was een succes: we automatiseerden de ontwikkelingsketen volledig, bereikten bijna 100% uptime van de ontwikkelingsserver, konden de testdekking volgen en verbeteren, en de Git-tak kon worden gekoppeld aan de levering en Jira-taak. En bijna alle tools die we gebruikten om de DevOps-keten op te bouwen, waren open source.<\/p>\n

<\/p>\n

In feite was de keten vereenvoudigd, aangezien we geen geavanceerde configuraties met Jenkins of Ansible hebben toegepast. Maar we hebben het voor elkaar gekregen. Dit is misschien een gevolg van het principe Pareto<\/a><\/noindex> (ook bekend als de 80\/20 regel).<\/p>\n

<\/p>\n

Korte beschrijving van de DevOps- en CI\/CD-keten<\/h3>\n

<\/p>\n

DevOps heeft verschillende definities. DevOps, net als Agile, omvat verschillende disciplines. Maar de meeste mensen zullen het eens zijn met de volgende definitie: DevOps is een methode, of ontwikkelingscyclus, waarvan het belangrijkste principe is het cre\u00ebren van een cultuur waarin ontwikkelaars en andere medewerkers 'op dezelfde golflengte' zitten, handmatig werk is geautomatiseerd, iedereen doet wat hij het beste kan, de frequentie van leveringen toeneemt, de productiviteit stijgt en de flexibiliteit toeneemt.<\/p>\n

<\/p>\n

En hoewel alleen tools niet genoeg zijn om een DevOps-omgeving te cre\u00ebren, kunnen we zonder hen niet. De belangrijkste is continue integratie en continue levering (CI\/CD). In de keten zijn er verschillende fasen voor elke omgeving (bijvoorbeeld DEV (ontwikkeling), INT (integratie), TST (testen), QA (kwaliteitscontrole), UAT (gebruikersacceptatietesten), STG (voorbereiding), PROD (gebruik)), handmatige taken zijn geautomatiseerd, ontwikkelaars kunnen kwalitatieve code schrijven, deze afleveren en gemakkelijk opnieuw structureren.<\/p>\n

<\/p>\n

Dit artikel beschrijft hoe je in vijf stappen een DevOps-keten kunt opzetten, zoals weergegeven in de afbeelding hieronder, met behulp van hulpmiddelen met open source.<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Laten we aan de slag gaan.<\/p>\n

<\/p>\n

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

<\/p>\n

Allereerst heb je een CI\/CD-tool nodig. Jenkins is een open CI\/CD-tool geschreven in Java met een MIT-licentie, waarmee de popularisering van de DevOps-beweging begon en die de facto de standaard voor CI\/CD is geworden.<\/p>\n

<\/p>\n

En wat is Jenkins? Stel je voor dat je een magische afstandsbediening hebt voor verschillende services en tools. De CI\/CD-tool zelf, zoals Jenkins, is nutteloos, maar in combinatie met verschillende tools en services wordt het almachtig.<\/p>\n

<\/p>\n

Naast Jenkins zijn er tal van andere open tools, kies er een die je bevalt. <\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Zo ziet het DevOps-proces eruit met een CI\/CD-tool.<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Je hebt een CI\/CD-tool op je localhost, maar er is nog niet veel te doen. Laten we verdergaan naar de volgende stap.<\/p>\n

<\/p>\n

Stap 2: versiebeheer<\/h3>\n

<\/p>\n

De beste (en waarschijnlijk eenvoudigste) manier om de magie van een CI\/CD-tool te testen, is door deze te integreren met een source control management (SCM)-tool. Waarom heb je versiebeheer nodig? Stel je voor dat je een applicatie aan het maken bent. Je schrijft het in Java, Python, C++, Go, Ruby, JavaScript of in een andere taal, waar er talloze van zijn. Wat je schrijft, heet de broncode. In het begin, vooral als je alleen werkt, kun je alles in een lokale map opslaan. Maar als het project groeit en er meer mensen bij komen, heb je een manier nodig om wijzigingen in de code te delen, terwijl je conflicten bij het samenvoegen van wijzigingen voorkomt. Je moet ook op de een of andere manier eerdere versies kunnen herstellen zonder back-ups en zonder het copy-paste principe voor bestanden met code toe te passen.<\/p>\n

<\/p>\n

En hier komt SCM om de hoek kijken. SCM slaat de code op in repositories, beheert de versies ervan en co\u00f6rdineert deze tussen ontwikkelaars.<\/p>\n

<\/p>\n

Er zijn veel SCM-tools, maar Git is terecht de de facto standaard geworden. Ik raad echt aan om dit te gebruiken, maar er zijn ook andere opties.<\/p>\n

<\/p>\n

\"Een<\/p>\n

<\/p>\n

Zo ziet de DevOps-pijplijn eruit na het toevoegen van SCM.<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Een CI\/CD-tool kan het uploaden en downloaden van broncode en samenwerking in een team automatiseren. Niet slecht, toch? Maar hoe maak je hier nu een werkende applicatie van, geliefd door miljarden gebruikers?<\/p>\n

<\/p>\n

Stap 3: hulpmiddel voor bouwautomatisering<\/h3>\n

<\/p>\n

Alles verloopt zoals gepland. Je kunt de code uploaden en wijzigingen in het versiebeheersysteem vastleggen, en je kunt ook vrienden uitnodigen om met je samen te werken. Maar je hebt nog steeds geen applicatie. Om dit een webapplicatie te maken, moet je deze compileren en verpakken voor levering of uitvoeren als een uitvoerbaar bestand. (Een ge\u00efnterpreteerde programmeertaal, zoals JavaScript of PHP, hoeft niet gecompileerd te worden.)<\/p>\n

<\/p>\n

Gebruik een hulpmiddel voor bouwautomatisering. Welke tool je ook kiest, deze zal de code in het benodigde formaat verzamelen en het opschonen, compileren, testen en leveren automatiseren. Bouwtools vari\u00ebren afhankelijk van de taal, maar de volgende open-source opties worden meestal gebruikt.<\/p>\n

<\/p>\n

\"Een<\/p>\n

<\/p>\n

Geweldig! Laten we nu de configuratiebestanden van de bouwautomatiseringstool in het versiebeheersysteem plaatsen, zodat de CI\/CD-tool ze kan verzamelen.<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Het lijkt allemaal in orde. Maar waar moet dit nu naartoe?<\/p>\n

<\/p>\n

Stap 4: webapplicatieserver<\/h3>\n

<\/p>\n

Dus, je hebt een verpakt bestand dat kan worden uitgevoerd of gelanceerd. Om de applicatie echt nuttig te maken, moet deze een of andere service of interface hebben, maar je moet het ergens onderbrengen.<\/p>\n

<\/p>\n

Een webapplicatie kan worden gehost op een webapplicatieserver. De server biedt een omgeving waar je de programmatische logica van het pakket kunt uitvoeren, de interface kunt renderen en webservices via sockets kunt openen. Je hebt een HTTP-server en een paar andere omgevingen (zoals een virtuele machine bijvoorbeeld) nodig om de applicatieserver in te stellen. Laten we aannemen dat je dit allemaal zelf kunt regelen (hoewel ik hieronder meer over containers zal vertellen).<\/p>\n

<\/p>\n

Er zijn verschillende open-source webapplicatieservers.<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

We hebben bijna een werkende DevOps-keten gemaakt. Goed gedaan!<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

In principe kun je hier stoppen, je kunt de rest zelf aan, maar het is de moeite waard om ook over de codekwaliteit te vertellen.<\/p>\n

<\/p>\n

Stap 5: Testdekking<\/h3>\n

<\/p>\n

Testen kost veel tijd en moeite, maar het is beter om fouten onmiddellijk te vinden en de code te verbeteren om de eindgebruikers tevreden te stellen. Hiervoor zijn er veel open-source tools die niet alleen de code testen, maar ook tips geven om deze te verbeteren. De meeste CI\/CD-tools kunnen verbinding maken met deze tools en het proces automatiseren.<\/p>\n

<\/p>\n

Testen is onderverdeeld in twee delen: testframeworks om tests te schrijven en uit te voeren, en tools met suggesties voor het verbeteren van de codekwaliteit.<\/p>\n

<\/p>\n

Testframeworks<\/h3>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Tools met suggesties voor kwaliteit<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

De meeste van deze tools en frameworks zijn geschreven voor Java, Python en JavaScript, omdat C++ en C# propri\u00ebtair zijn (hoewel GCC open source is).<\/p>\n

<\/p>\n

We hebben tools voor testdekking toegepast, en nu zou de DevOps-pijplijn eruit moeten zien zoals op de afbeelding aan het begin van de handleiding.<\/p>\n

<\/p>\n

Extra stappen<\/h2>\n

<\/p>\n

Containers<\/h3>\n

<\/p>\n

Zoals ik al zei, kan de applicatieserver worden gehost op een virtuele machine of server, maar containers zijn populairder.<\/p>\n

<\/p>\n

Wat zijn containers?<\/a><\/noindex>? \u0412\u043a\u0440\u0430\u0442\u0446\u0435, \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 \u043c\u0435\u0441\u0442\u0430, \u0447\u0435\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u0412 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0431\u0435\u0437 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u043d\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c, \u043d\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0432\u043c\u0435\u0449\u0430\u0435\u0442 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0431\u0435\u0437 \u043b\u0438\u0448\u043d\u0438\u0445 \u0437\u0430\u0442\u0440\u0430\u0442.<\/p>\n

<\/p>\n

Voor containers worden meestal Docker en Kubernetes gebruikt, hoewel er ook andere opties zijn.<\/p>\n

<\/p>\n

\"Een<\/a><\/noindex><\/p>\n

<\/p>\n

Lees artikelen over Docker en Kubernetes op Opensource.com<\/a><\/noindex>:<\/p>\n

<\/p>\n