Tworzenie pierwszego łańcucha DevOps w pięciu krokach dla nowicjuszy.
DevOps stał się panaceum dla zbyt wolnych, rozproszonych oraz innych problematycznych procesów rozwoju. Ale potrzebna jest minimalna wiedza na temat DevOps. Omówimy tu takie pojęcia jak łańcuch DevOps oraz jak go stworzyć w pięciu krokach. To nie jest pełny przewodnik, a jedynie "ryba", którą można rozwijać. Zacznijmy od historii.
Moje pierwsze doświadczenia z DevOps
Kiedyś pracowałem z chmurami w Citi Group i rozwijałem aplikację IaaS, aby zarządzać infrastrukturą chmurową Citi, ale zawsze ciekawiło mnie, jak można zoptymalizować łańcuch rozwoju i poprawić kulturę wśród programistów. Greg Lavender, nasz dyrektor techniczny ds. architektury chmurowej i infrastruktury, polecił mi książkę . Wyjaśnia ona doskonale zasady DevOps, a przy tym czyta się jak powieść.
W tabeli po drugiej stronie pokazano, jak często firmy wypuszczają nowe wersje:
Jak Amazon, Google i Netflix są w stanie wypuszczać tak wiele? A to proste: zrozumieli, jak stworzyć niemal idealny łańcuch DevOps.
W Citi wszystko wyglądało zupełnie inaczej, dopóki nie przeszliśmy na DevOps. Wtedy moja drużyna miała różne środowiska, ale wdrożenie na serwerze rozwojowym odbywało się ręcznie. Wszyscy programiści mieli dostęp tylko do jednego serwera rozwojowego opartego na IBM WebSphere Application Server Community Edition. Podczas jednoczesnej próby wdrożenia serwer "siadał", a my za każdym razem musieliśmy "bolesnie" się dogadywać. Mieliśmy też niewystarczające pokrycie kodu testami, czasochłonny proces ręcznego wdrożenia i brak możliwości śledzenia wdrożenia kodu związanego z jakimś zadaniem lub wymaganiem klienta.
Było jasne, że trzeba coś pilnie zrobić i znalazłem kolegę o podobnych poglądach. Postanowiliśmy wspólnie stworzyć pierwszy łańcuch DevOps — on skonfigurował maszynę wirtualną i serwer aplikacji Tomcat, a ja zająłem się Jenkins, integracją z Atlassian Jira i BitBucket oraz pokryciem kodu testami. Projekt odniósł sukces: całkowicie zautomatyzowaliśmy łańcuch rozwoju, osiągnęliśmy niemal 100% nieprzerwanej pracy serwera rozwojowego, mogliśmy śledzić i poprawiać pokrycie kodu testami, a gałąź Git mogła być powiązana z wdrożeniem i zadaniem Jira. A niemal wszystkie narzędzia, którymi zbudowaliśmy łańcuch DevOps, były oparte na otwartym kodzie źródłowym.
W rzeczywistości, proces był uproszczony, ponieważ nawet nie stosowaliśmy zaawansowanych konfiguracji przy użyciu Jenkinsa czy Ansible. Ale wszystko się udało. Być może to efekt zasady (znana także jako zasada 80/20).
Krótki opis łańcucha DevOps i CI/CD
DevOps ma różne definicje. DevOps, podobnie jak Agile, obejmuje różne dyscypliny. Jednak większość zgodzi się z następującą definicją: DevOps to metoda, czyli cykl życia, rozwoju oprogramowania, której główną zasadą jest tworzenie kultury, w której deweloperzy i inni pracownicy "na tej samej fali", ręczna praca zostaje zautomatyzowana, każdy zajmuje się tym, w czym jest najlepszy, zwiększa się częstotliwość dostaw, rośnie wydajność, a elastyczność wzrasta.
I chociaż same narzędzia nie wystarczają do stworzenia środowiska DevOps, są one niezbędne. Najważniejszym z nich jest ciągła integracja i ciągłe dostarczanie (CI/CD). W łańcuchu dla każdego środowiska istnieją różne etapy (na przykład, DEV (rozwój), INT (integracja), TST (testowanie), QA (kontrola jakości), UAT (testowanie akceptacyjne przez użytkowników), STG (preparacja), PROD (użytkowanie)), zadania ręczne są zautomatyzowane, deweloperzy mogą pisać jakościowy kod, dostarczać go i łatwo się dostosowywać.
Niniejsza notka opisuje, jak w pięciu krokach stworzyć łańcuch DevOps, jak pokazano na obrazku poniżej, przy użyciu narzędzi z otwartym kodem źródłowym.
Przechodzimy do rzeczy.
Krok 1: Platforma CI/CD
Na początek potrzebujesz narzędzia CI/CD. Jenkins to otwarte narzędzie CI/CD napisane w Javie na licencji MIT, które rozpoczęło popularyzację ruchu DevOps i które de facto stało się standardem dla CI/CD.
Czym jest Jenkins? Wyobraź sobie, że masz magiczny pilot do różnych usług i narzędzi. Samo narzędzie CI/CD, takie jak Jenkins, jest bezużyteczne, ale z różnymi narzędziami i usługami staje się wszechmocne.
Oprócz Jenkinsa istnieje wiele innych otwartych narzędzi, wybierz jakiekolwiek.
Oto jak wygląda proces DevOps z narzędziem CI/CD
Masz na localhost narzędzie CI/CD, ale na razie niewiele można z tym zrobić. Przechodzimy do następnego kroku.
Krok 2: zarządzanie wersjami
Najlepszym (a może najprostszym) sposobem na sprawdzenie możliwości narzędzia CI/CD jest zintegrowanie go z narzędziem do zarządzania wersjami (source control management, SCM). Po co potrzebne jest zarządzanie wersjami? Załóżmy, że tworzysz aplikację. Piszesz ją w Java, Pythonie, C++, Go, Rubym, JavaScripcie lub w jakimkolwiek innym języku, których jest mnóstwo. To, co piszesz, nazywa się kodem źródłowym. Na początku, zwłaszcza jeśli pracujesz samodzielnie, możesz zapisywać wszystko w lokalnym katalogu. Ale kiedy projekt się rozwija i dołącza do niego więcej osób, potrzebujesz sposobu na dzielenie się zmianami w kodzie, unikając jednocześnie konfliktów podczas scalania zmian. A także musisz mieć sposób na odzyskiwanie wcześniejszych wersji bez korzystania z kopii zapasowych i stosowania metody kopiuj-wklej dla plików z kodem.
I tutaj nie obędzie się bez SCM. SCM przechowuje kod w repozytoriach, zarządza jego wersjami i koordynuje go wśród programistów.
Jest sporo narzędzi SCM, ale de facto standardem stał się Git. Zalecam korzystanie z niego, ale są też inne opcje.
Oto jak wygląda pipeline DevOps po dodaniu SCM.
Narzędzie CI/CD może automatyzować ładowanie i pobieranie kodu źródłowego oraz współpracę w zespole. Nieźle? Ale jak teraz zamienić to na działającą aplikację, kochaną przez miliardy użytkowników?
Krok 3: narzędzie automatyzacji budowy
Wszystko idzie zgodnie z planem. Możesz przesyłać kod i rejestrować zmiany w systemie kontroli wersji, a także zaprosić znajomych do współpracy. Ale na razie nie masz aplikacji. Aby to było web-aplikacja, trzeba ją skompilować i umieścić w paczce do dostarczenia lub uruchomić jako plik wykonywalny. (Język programowania interpretowany, jak JavaScript czy PHP, nie wymaga kompilacji.)
Użyj narzędzia automatyzacji budowy. Niezależnie od tego, jakie narzędzie wybierzesz, będzie ono zbierało kod w odpowiednim formacie i automatyzowało czyszczenie, kompilację, testowanie i dostarczanie. Narzędzia budowy różnią się w zależności od języka, ale zazwyczaj używane są następujące popularne opcje z otwartym kodem.
Doskonale! Teraz wstawimy pliki konfiguracyjne narzędzia automatyzacji budowy do systemu kontroli wersji, aby narzędzie CI/CD mogło je zebrać.
Wygląda na to, że wszystko jest w porządku. Ale dokąd teraz to wszystko wdrożyć?
Krok 4: serwer aplikacji webowych
Zatem masz spakowany plik, który można wykonać lub wdrożyć. Aby aplikacja naprawdę była użyteczna, musi mieć jakiś serwis lub interfejs, ale musisz to wszystko gdzieś umieścić.
Aplikację internetową można umieścić na serwerze aplikacji. Serwer aplikacji zapewnia środowisko, w którym można wykonać logikę programową z pakietu, zrealizować renderowanie interfejsu i otworzyć usługi internetowe przez gniazdo. Potrzebujesz serwera HTTP i kilku innych środowisk (na przykład maszyny wirtualnej), aby zainstalować serwer aplikacji. Na razie wyobraźmy sobie, że znasz się na tym w trakcie działania (choć o kontenerach opowiem poniżej).
Istnieje kilka otwartych serwerów aplikacji webowych.
Już mamy prawie działający łańcuch DevOps. Świetna robota!
W zasadzie tutaj można się zatrzymać, dalej poradzisz sobie sam, ale warto jeszcze wspomnieć o jakości kodu.
Krok 5: Pokrycie Testowe
Testowanie zabiera dużo czasu i wysiłku, ale lepiej natychmiast znaleźć błędy i poprawić kod, aby zadowolić końcowych użytkowników. Istnieje wiele otwartych narzędzi, które nie tylko przetestują kod, ale także doradzą, jak go poprawić. Większość narzędzi CI/CD może integrować się z tymi narzędziami i automatyzować proces.
Testowanie dzieli się na dwie części: ramy testowe do pisania i wykonywania testów oraz narzędzia z podpowiedziami dotyczącymi poprawy jakości kodu.
Ramy testowe
Narzędzia z podpowiedziami dotyczącymi jakości
Większość tych narzędzi i ram została napisana dla Java, Python i JavaScript, ponieważ C++ i C# są proprietary (choć GCC ma otwarty kod źródłowy).
Zastosowaliśmy narzędzia do pokrycia testowego i teraz pipeline DevOps powinien wyglądać jak na rysunku na początku przewodnika.
Dodatkowe kroki
Kontenery
Jak już wspomniałem, serwer aplikacji można umieścić na maszynie wirtualnej lub serwerze, ale kontenery są bardziej popularne.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Dla kontenerów zwykle wybiera się Docker i Kubernetes, chociaż są też inne opcje.
Przeczytaj artykuły o Dockerze i Kubernetesie na :
Narzędzia automatyzacji pośredniego oprogramowania
Nasz łańcuch DevOps koncentruje się na wspólnej budowie i dostarczaniu aplikacji, ale z narzędziami DevOps można robić również inne ciekawe rzeczy. Na przykład, można wykorzystać narzędzia „infrastruktura jako kod” (IaC), które nazywane są również narzędziami automatyzacji oprogramowania pośredniego. Te narzędzia pomagają zautomatyzować instalację, zarządzanie i inne zadania związane z oprogramowaniem pośrednim. Na przykład, narzędzie automatyzacji może pobierać aplikacje (serwer aplikacji webowych, bazę danych, narzędzia monitorujące) z odpowiednimi konfiguracjami i wdrażać je na serwerze aplikacji.
Oto kilka przykładów otwartych narzędzi do automatyzacji oprogramowania pośredniego:
Szczegóły w artykułach na :
I co teraz?
To tylko wierzchołek góry lodowej. Łańcuch DevOps może zrobić znacznie więcej. Zacznij od narzędzia CI/CD i dowiedz się, co jeszcze można zautomatyzować, aby ułatwić sobie pracę. Nie zapomnij o dla efektywnej współpracy.
Oto kilka dobrych artykułów o DevOps dla początkujących:
Można także integrować DevOps z otwartymi narzędziami dla agile:
Źródło: habr.com
