🥇Przewodnik dla początkujących: tworzymy pipeline DevOps

Jeśli jesteś nowicjuszem w DevOps, zapoznaj się z tym przewodnikiem po tworzeniu swojego pierwszego pięcioetapowego procesu.

DevOps stał się standardowym rozwiązaniem dla naprawy wolnych, rozproszonych lub nieefektywnych procesów rozwoju oprogramowania. Problem w tym, że jeśli jesteś nowy w DevOps i nie wiesz, od czego zacząć, możesz nie mieć pełnego zrozumienia tych metod. W tym artykule omówimy, czym jest pipeline DevOps oraz przedstawimy instrukcję jego stworzenia w pięciu krokach. Choć ten poradnik nie jest wyczerpujący, ma on na celu zapewnienie podstaw do rozpoczęcia twojej drogi oraz dalszego zgłębiania tej tematyki. Zacznijmy jednak od historii.

Moja podróż z DevOps

Dawniej pracowałem w zespole chmurowym Citi Group, rozwijając aplikację webową Infrastructure-as-a-Service (IaaS) do zarządzania infrastrukturą chmurową Citi, ale zawsze interesowało mnie, jak uczynić proces rozwoju bardziej efektywnym oraz wprowadzić pozytywne zmiany kulturowe w zespole programistów. Odpowiedź znalazłem w książce polecanej przez Grega Lavender, dyrektora technicznego Citi ds. architektury chmurowej i infrastruktury. Książka nosiła tytuł „Projekt Feniks” (The Phoenix Project), która wyjaśnia zasady DevOps, a czyta się ją jak powieść.

W tabeli na odwrocie książki pokazano, jak często różne firmy wdrażają swoje systemy w środowisku produkcyjnym:

Amazon: 23 000 dziennie
Google: 5 500 dziennie
Netflix: 500 dziennie
Facebook: raz dziennie
Twitter: 3 razy w tygodniu
Typowa firma: raz na 9 miesięcy

Jak w ogóle możliwe są takie częstotliwości w Amazonie, Google i Netflixie? Wszystko dlatego, że te firmy wymyśliły, jak stworzyć niemal idealny pipeline DevOps.

Byliśmy daleko od tego, aż do momentu, gdy wprowadziliśmy DevOps w Citi. Wtedy w moim zespole były różne środowiska, ale wdrożenie na serwerze deweloperskim było całkowicie ręczne. Wszyscy programiści mieli dostęp tylko do jednego serwera deweloperskiego opartego na IBM WebSphere Application Server Community Edition. Problem polegał na tym, że serwer wyłączał się za każdym razem, gdy kilku użytkowników próbowało jednocześnie przeprowadzić wdrożenie, więc programiści musieli informować się nawzajem o swoich zamiarach, co było dość bolesne. Ponadto występowały problemy z niskim pokryciem testowym kodu, ciężkimi procesami ręcznego wdrożenia i brakiem możliwości śledzenia wdrożenia kodu związanego z określonym zadaniem lub historią użytkownika.

Zrozumiałem, że trzeba coś zrobić, i znalazłem kolegę z podobnymi poglądami. Postanowiliśmy współpracować przy tworzeniu początkowego konwejera DevOps – on zainstalował maszynę wirtualną i serwer aplikacji Tomcat, podczas gdy ja pracowałem nad Jenkins, integrując Atlassian Jira i BitBucket, a także zajmując się pokryciem testowym kodu. Ten projekt poboczny okazał się bardzo udany: prawie całkowicie zautomatyzowaliśmy wiele procesów, osiągnęliśmy niemal 100% funkcjonalności naszego serwera deweloperskiego, zapewniliśmy śledzenie oraz poprawiliśmy pokrycie testowe kodu, a także dodaliśmy możliwość łączenia gałęzi w Git z zadaniami w Jira lub z wdrożeniami. Większość narzędzi, które używaliśmy do budowy naszego konwejera DevOps, miała otwarty kod źródłowy.

Teraz rozumiem, jak prosty był nasz pipeline DevOps: nie używaliśmy rozszerzeń takich jak pliki Jenkins czy Ansible. Jednak ten prosty konwejer działał dobrze, być może dzięki zasadzie Pareto (znanej również jako zasada 80/20).

Krótkie wprowadzenie do DevOps i pipeline'u CI/CD

Jeśli zapytasz kilka osób: „Czym jest DevOps?”, prawdopodobnie otrzymasz kilka różnych odpowiedzi. DevOps, podobnie jak Agile, rozwijał się, aby objąć wiele różnych dyscyplin, ale większość ludzi zgodzi się co do kilku rzeczy: DevOps to praktyka rozwoju oprogramowania lub cykl życia rozwoju oprogramowania (SDLC), którego centralnym zasadą jest zmiana kultury, w której programiści i osoby spoza obszaru IT istnieją w środowisku, w którym:

Automatyzowane są operacje, które wcześniej były wykonywane ręcznie;
Każdy robi to, co potrafi najlepiej;
Liczba wdrożeń w określonym czasie rośnie; Wydajność wzrasta;
Zwiększa się elastyczność rozwoju.

Chociaż posiadanie odpowiednich narzędzi programowych to nie jedyna rzecz potrzebna do stworzenia środowiska DevOps, niektóre narzędzia są niezbędne. Kluczowym narzędziem jest ciągła integracja i ciągłe wdrażanie (CI/CD). W tym procesie środowiska mają różne etapy (np. DEV, INT, TST, QA, UAT, STG, PROD), wiele operacji jest zautomatyzowanych, a programiści mogą pisać wysokiej jakości kod, osiągać elastyczność rozwoju i wysoką częstotliwość wdrożeń.

W tym artykule opisano pięcioetapowe podejście do budowania potoku DevOps, podobnego do przedstawionego na następnej diagramie, przy użyciu narzędzi open source.

Krok 1: Metody CI/CD

Pierwszą rzeczą, której potrzebujesz, jest narzędzie CI/CD. Jenkins, narzędzie open source, oparte na Javie i udostępniane na licencji MIT, to środek, który spopularyzował kierunek DevOps i stał się de facto standardem.

Czym więc jest Jenkins? Można to uznać za pewien magiczny uniwersalny pilot zdalnego sterowania, który może rozmawiać z różnymi usługami i narzędziami oraz je organizować. Samo narzędzie CI/CD, takie jak Jenkins, jest bezużyteczne, ale staje się potężniejsze, gdy łączy się z różnymi narzędziami i usługami.

Jenkins to tylko jedno z wielu narzędzi open source do CI/CD, które możesz wykorzystać do budowy potoku DevOps.

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

Oto, jak wyglądają procesy DevOps z narzędziem CI/CD:

Masz narzędzie CI/CD działające na swoim lokalnym serwerze, ale na razie niewiele możesz zrobić. Przejdźmy na kolejny etap podróży w świat DevOps.

Krok 2: Zarządzanie systemami kontroli wersji

Najlepszym (i prawdopodobnie najprostszym) sposobem, aby sprawdzić, czy twoje narzędzie CI/CD może zdziałać cuda, jest integracja z narzędziem kontroli wersji (SCM). Po co potrzebujesz kontroli wersji? Załóżmy, że tworzysz aplikację. Za każdym razem, gdy programujesz, niezależnie od tego, czy używasz Javy, Pythona, C++, Go, Rubiego, JavaScriptu czy jakiegokolwiek innego z niezliczonej ilości języków programowania. Kod, który piszesz, nazywa się kodem źródłowym. Na początku, zwłaszcza gdy pracujesz sam, prawdopodobnie można wszystko umieścić w lokalnym katalogu. Ale gdy projekt rośnie i zapraszasz innych do współpracy, potrzebujesz sposobu na zapobieganie konfliktom podczas efektywnej wymiany modyfikacji. Potrzebujesz też sposobu na przywracanie wcześniejszych wersji, ponieważ tworzenie kopii zapasowych i kopiowanie/wklejanie ich już nie wystarcza. Ty (i twoi koledzy z zespołu) potrzebujecie czegoś lepszego.

To właśnie tutaj narzędzie kontroli wersji staje się praktycznie niezbędne. To narzędzie przechowuje twój kod w repozytoriach, prowadzi rejestr wersji i koordynuje pracę uczestników projektu.

Chociaż istnieje wiele narzędzi kontroli wersji, Git jest standardem i to prawda. Zdecydowanie polecam korzystanie z Gita, chociaż istnieją także inne opcje z otwartym kodem.

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

Tak wygląda pipeline DevOps z dodanym narzędziem kontroli wersji.

Narzędzie CI/CD może zautomatyzować procesy sprawdzania, pobierania kodu źródłowego i współpracy między członkami zespołu. Niezłe, prawda? Ale jak sprawić, aby to działało jako aplikacja, z której miliardy ludzi będą mogły korzystać i ją oceniać?

Krok 3: Tworzenie narzędzia automatyzacji kompilacji

Świetnie! Możesz sprawdzać kod i wprowadzać zmiany w systemie kontroli wersji, a także zapraszać swoich znajomych do współpracy przy rozwoju. Ale jeszcze nie stworzyłeś aplikacji. Aby stworzyć aplikację internetową, musisz ją skompilować i spakować w format wywoływalny lub uruchomić jako plik wykonywalny. (Zauważ, że interpretowany język programowania, taki jak JavaScript czy PHP, nie wymaga kompilacji).

Skorzystaj z narzędzia automatyzacji budowy. Niezależnie od tego, które narzędzie automatyzacji budowy zdecydujesz się użyć, wszystkie one dążą do tego samego celu: przekształcenia kodu źródłowego w pożądany format i zautomatyzowania zadania czyszczenia, kompilacji, testowania i wdrażania w określonym środowisku. Narzędzia do budowy będą się różnić w zależności od twojego języka programowania, oto kilka ogólnych opcji z otwartym kodem źródłowym.

Nazwa
Licencja
Język programowania

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/A

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

Świetnie! Możesz umieścić pliki konfiguracyjne narzędzia automatyzacji budowy w systemie kontroli wersji i pozwolić swojemu narzędziu CI/CD połączyć wszystko w jedną całość.

Wszystko w porządku, prawda? Ale gdzie wdrożyć swoją aplikację?

Krok 4: Serwer dla aplikacji internetowych

Na razie masz zapakowany plik, który może być zarówno wykonywalny, jak i instalacyjny. Aby aplikacja była naprawdę przydatna, musi oferować jakąś usługę lub interfejs, ale potrzebujesz kontenera do umieszczenia swojej aplikacji.

Serwer dla aplikacji internetowych to dokładnie taki kontener. Serwer zapewnia środowisko, w którym logiczna struktura pakietu wywoływalnego może być określona. Serwer także udostępnia interfejs i oferuje usługi internetowe, otwierając gniazda dla zewnętrznego świata. Potrzebujesz serwera HTTP oraz jakiegoś środowiska (na przykład maszyny wirtualnej) do jego instalacji. A na razie załóżmy, że dowiesz się o tym później (choć powiem o kontenerach poniżej).

Istnieje kilka otwartych serwerów dla aplikacji internetowych.

Nazwa
Licencja
Język programowania

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

Twój pipeline DevOps jest prawie gotowy do użycia. Dobra robota!

Choć można na tym poprzestać i zająć się integracją samodzielnie, jakość kodu to ważna kwestia dla programisty aplikacji i należy się nią martwić.

Krok 5: Pokrycie testowania kodu

Wdrażanie testów może być kolejnym uciążliwym wymaganiem, ale programiści muszą wychwytywać wszelkie błędy w aplikacji na wczesnym etapie i poprawiać jakość kodu, aby zapewnić satysfakcję końcowych użytkowników. Na szczęście istnieje wiele narzędzi open source do testowania kodu i generowania rekomendacji dotyczących poprawy jego jakości. Jeszcze lepiej, że większość narzędzi CI/CD może łączyć się z tymi narzędziami i automatyzować proces.

Testowanie kodu składa się z dwóch części: frameworków do testowania kodu, które pomagają pisać i uruchamiać testy, oraz narzędzi do generowania sugestii, które pomagają poprawić jakość kodu.

Systemy testowania kodu

Nazwa
Licencja
Język programowania

JUnit
Licencja publiczna Eclipse
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Systemy rekomendacji dotyczące poprawy kodu

Nazwa
Licencja
Język programowania

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Licencja publiczna Eclipse
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Zauważ, że większość narzędzi i frameworków wymienionych powyżej została napisanych dla Javy, Pythona i JavaScriptu, ponieważ C++ i C# są językami programowania objętymi prawami własnościowymi (choć GCC ma otwarte źródło).

Teraz, gdy wdrożyłeś narzędzia do pokrycia kodu testami, Twój pipeline DevOps powinien przypominać diagram pokazany na początku tego przewodnika.

Dodatkowe kroki

Kontenery

Jak już wspominałem, możesz hostować swój serwer na maszynie wirtualnej lub serwerze, ale kontenery są popularnym rozwiązaniem.

Czym są kontenery? Krótkie wyjaśnienie polega na tym, że maszyna wirtualna potrzebuje ogromnej ilości pamięci systemu operacyjnego, przekraczającej rozmiar aplikacji, podczas gdy kontener potrzebuje tylko kilku bibliotek i konfiguracji do uruchomienia aplikacji. Oczywiście maszyna wirtualna ma wciąż ważne zastosowania, ale kontener to lekkie rozwiązanie do hostingu aplikacji, w tym serwerów aplikacyjnych.

Choć istnieją inne opcje kontenerów, najpopularniejsze to Docker i Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Środki automatyzacji pośredniej

Nasz pipeline DevOps głównie skupia się na wspólnym tworzeniu i wdrażaniu aplikacji, ale istnieje wiele innych rzeczy, które można zrobić za pomocą narzędzi DevOps. Jednym z nich jest wykorzystanie narzędzi Infrastructure as Code (IaC), które znane są również jako środki automatyzacji pośredniej. Te narzędzia pomagają zautomatyzować instalację, zarządzanie i inne zadania dla oprogramowania pośredniego. Na przykład, narzędzie automatyzacji może wyodrębniać aplikacje, takie jak serwer aplikacji, bazy danych i narzędzia do monitorowania, z odpowiednimi konfiguracjami i wdrażać je na serwerze aplikacji.

Oto kilka narzędzi automatyzacji pośredniej z otwartym kodem źródłowym:

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

Dowiedz się szczegółów, jak zdobyć pożądaną profesję od podstaw lub rozwinąć umiejętności i zarobki, ucząc się na płatnych kursach online SkillFactory: