Stwórz swój pierwszy łańcuch DevOps w pięciu krokach dla nowicjuszy.
DevOps stał się remedium na zbyt wolne, rozproszone i inne problematyczne procesy rozwoju. Wymaga jednak podstawowej znajomości DevOps. Omówimy tu pojęcia takie jak łańcuch DevOps i jak go stworzyć w pięciu krokach. To nie jest pełny przewodnik, a jedynie „szkic”, który można rozwijać. Zaczniemy od historii.
Moje pierwsze kroki z DevOps
Kiedyś pracowałem z chmurami w Citi Group i opracowywałem aplikację webową IaaS, aby zarządzać chmurą infrastruktury Citi, ale zawsze ciekawiło mnie, jak optymalizować łańcuch rozwoju i poprawiać kulturę wśród programistów. Greg Lavender, nasz dyrektor technologiczny ds. architektury chmurowej i infrastruktury, polecił mi książkę . Doskonale wyjaśnia zasady DevOps, a czyta się jak powieść.
W tabeli na odwrocie pokazano, jak często firmy wprowadzają nowe wersje:
Jak Amazon, Google i Netflix są w stanie tak często aktualizować? Odpowiedź jest prosta: zrozumieli, jak stworzyć niemal idealny łańcuch DevOps.
W Citi wszystko wyglądało zupełnie inaczej, dopóki nie przeszliśmy na DevOps. Moja zespół miał różne środowiska, ale wdrożenie na serwerze deweloperskim odbywało się ręcznie. Wszyscy deweloperzy mieli dostęp tylko do jednego serwera deweloperskiego opartego na IBM WebSphere Application Server Community Edition. Przy równoczesnej próbie wdrożenia serwer 'upadał', a my musieliśmy za każdym razem 'bolesne' negocjować ze sobą. Mieliśmy też niewystarczające pokrycie kodu testami, pracochłonny ręczny proces wdrożenia oraz żadnej możliwości śledzenia wdrożeń kodu związanych z jakimś zadaniem lub wymaganiem klienta.
Było jasne, że musimy szybko coś zrobić, więc znalazłem kolegę o podobnych poglądach. Postanowiliśmy razem stworzyć pierwszą pętlę DevOps — on skonfigurował maszynę wirtualną oraz serwer aplikacji Tomcat, a ja zająłem się Jenkins, integracją z Atlassian Jira i BitBucket oraz pokrywaniem kodu testami. Projekt odniósł sukces: całkowicie zautomatyzowaliśmy proces tworzenia, osiągnęliśmy prawie 100% ciągłości pracy serwera deweloperskiego, mogliśmy śledzić i poprawiać pokrycie kodu testami, a gałąź Git była powiązana z wdrożeniem i zadaniem w Jira. Co więcej, prawie wszystkie narzędzia, którymi budowaliśmy pętlę DevOps, były otwartym oprogramowaniem.
W rzeczywistości łańcuch był uproszczony, ponieważ nawet nie stosowaliśmy zaawansowanych konfiguracji za pomocą Jenkins czy Ansible. Ale nam się udało. Może to wynik zasady (znanej jako zasada 80/20).
Krótkie streszczenie pętli DevOps oraz CI/CD
DevOps ma różne definicje. Podobnie jak Agile, obejmuje różne dyscypliny. Jednak większość zgadza się z następującą definicją: DevOps to metoda, lub cykl życia, rozwoju oprogramowania, którego główną zasadą jest stworzenie kultury, w której programiści i inni pracownicy „są na tej samej fali”, prace ręczne są zautomatyzowane, każdy koncentruje się na tym, co robi najlepiej, wzrasta częstotliwość dostaw, zwiększa się wydajność pracy i elastyczność.
Chociaż samych narzędzi nie wystarcza 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 procesie 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 (przygotowanie), PROD (użytkowanie)), zadania ręczne są zautomatyzowane, programiści mogą pisać jakościowy kod, dostarczać go i łatwo się przystosowywać.
Ten artykuł opisuje, jak w pięciu krokach stworzyć łańcuch DevOps, jak pokazano na poniższym obrazku, przy użyciu narzędzi open-source.
Przejdźmy 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, licencjonowane na podstawie MIT, które zapoczątkowało popularność ruchu DevOps i stało się de facto 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 w połączeniu z różnymi narzędziami i usługami staje się wszechmocne.
Poza Jenkins istnieje wiele innych otwartych narzędzi, wybierz dowolne.
Oto jak wygląda proces DevOps z narzędziem CI/CD
Masz na localhost narzędzie CI/CD, ale na razie nie ma nic do zrobienia. Przejdźmy do następnego kroku.
Krok 2: zarządzanie wersjami
Najlepszy (i chyba najprostszy) sposób na sprawdzenie możliwości narzędzia CI/CD to zintegrowanie go z narzędziem do zarządzania wersjami (source control management, SCM). Dlaczego zarządzanie wersjami jest potrzebne? Załóżmy, że tworzysz aplikację. Programujesz ją w Java, Pythonie, C++, Go, Ruby, JavaScript lub w 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 sam, możesz przechowywać wszystko w lokalnym katalogu. Jednak gdy projekt rośnie i dołącza do niego więcej osób, potrzebujesz sposobu na dzielenie się zmianami w kodzie, unikając jednocześnie konfliktów przy scalaniu. Musisz także mieć możliwość przywracania wcześniejszych wersji bez korzystania z kopii zapasowych i metody kopiuj-wklej dla plików z kodem.
I tutaj nie można się obejść bez SCM. SCM przechowuje kod w repozytoriach, zarządza jego wersjami i koordynuje go wśród programistów.
Jest wiele narzędzi SCM, ale standardem de facto stał się zasłużenie Git. Polecam korzystać z niego, ale są także inne opcje.
Tak wygląda pipeline DevOps po dodaniu SCM.
Narzędzie CI/CD może automatyzować przesyłanie i pobieranie kodu źródłowego oraz współpracę w zespole. Nieźle, prawda? Ale jak teraz przekształcić to w działającą aplikację, ukochaną przez miliardy użytkowników?
Krok 3: narzędzie do automatyzacji budowy
Wszystko przebiega zgodnie z planem. Możesz przesyłać kod i wprowadzać zmiany w systemie kontroli wersji, a także zaprosić znajomych do współpracy. Ale na razie nie masz aplikacji. Aby to było aplikacją webową, musi zostać skompilowana i umieszczona w paczce do dostarczenia lub uruchomiona jako plik wykonywalny. (Języki interpretowane, takie jak JavaScript czy PHP, nie wymagają kompilacji.)
Użyj narzędzia do automatyzacji budowy. Niezależnie od tego, jakie narzędzie wybierzesz, będzie ono zbierać kod w odpowiednim formacie i automatyzować czyszczenie, kompilację, testowanie oraz dostarczanie. Narzędzia budowy różnią się w zależności od języka, ale zazwyczaj korzysta się z kilku popularnych opcji o otwartym kodzie źródłowym.
Świetnie! Teraz dodajmy pliki konfiguracyjne narzędzia do automatyzacji budowy do systemu kontroli wersji, aby narzędzie CI/CD mogło je skompilować.
Wygląda na to, że wszystko w porządku. Ale dokąd teraz to wszystko wdrożyć?
Krok 4: serwer aplikacji webowej
Macie spakowany plik, który można uruchomić lub wdrożyć. Aby aplikacja naprawdę przynosiła korzyści, musi mieć jakiś serwis lub interfejs, ale musicie to gdzieś umieścić.
Aplikację webową można umieścić na serwerze aplikacji webowej. Serwer aplikacji zapewnia środowisko, w którym można wykonać logikę programową z pakietu, zrenderować interfejs i otworzyć usługi webowe przez socket. Potrzebujecie serwera HTTP i kilku innych środowisk (na przykład maszyny wirtualnej), aby zainstalować serwer aplikacji. Na razie załóżmy, że ogarniacie to wszystko w trakcie (choć o kontenerach opowiem później).
Jest kilka otwartych serwerów aplikacji webowych.
Już prawie udało się wam stworzyć działający zestaw DevOps. Świetna robota!
W zasadzie tutaj można się zatrzymać, dalej poradzicie sobie sami, ale warto jeszcze wspomnieć o jakości kodu.
Krok 5: Pokrycie testowe
Testowanie zajmuje dużo czasu i wysiłku, ale lepiej od razu znaleźć błędy i poprawić kod, aby zadowolić końcowych użytkowników. W tym celu dostępnych jest wiele otwartych narzędzi, które nie tylko przetestują kod, ale także podpowiedzą, jak go ulepszyć. Większość narzędzi CI/CD może łączyć się z tymi narzędziami i automatyzować proces.
Testowanie dzieli się na dwie części: frameworki testowe do pisania i uruchamiania testów oraz narzędzia z podpowiedziami dla poprawy jakości kodu.
Frameworki testowe
Narzędzia z podpowiedziami jakości
Większość tych narzędzi i frameworków została napisana dla Javy, Pythona i JavaScriptu, ponieważ C++ i C# są proprietarne (chociaż GCC ma otwarty kod źródłowy).
Zastosowaliśmy narzędzia do pokrycia testowego, więc teraz nasz proces DevOps powinien wyglądać tak, jak na ilustracji na początku przewodnika.
Dodatkowe kroki
Kontenery
Jak już wspomniałem, serwer aplikacji można umieścić na wirtualnej maszynie lub serwerze, ale kontenery są bardziej popularne.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Do kontenerów zazwyczaj używa się Dockera i Kubernetes, chociaż są też inne opcje.
Przeczytaj artykuły o Docker i Kubernetes na :
Narzędzia automatyzacji oprogramowania pośredniego
Nasz cykl DevOps koncentruje się na współtworzeniu i dostarczaniu aplikacji, ale za pomocą narzędzi DevOps można robić wiele innych ciekawych rzeczy. Na przykład używać narzędzi do infrastruktury jako kodu (IaC), które są również nazywane narzędziami automatyzacji oprogramowania pośredniego. Narzędzia te pomagają automatyzować instalację, zarządzanie i inne zadania dotyczące oprogramowania pośredniego. Na przykład narzędzie automatyzacji może zająć aplikacje (serwer aplikacji webowej, bazę danych, narzędzia monitorujące) z odpowiednimi konfiguracjami i wdrożyć je na serwerze aplikacyjnym.
Oto kilka przykładów otwartych narzędzi automatyzacji oprogramowania pośredniego:
Szczegóły w artykułach na :
I co teraz?
To tylko wierzchołek góry lodowej. Łańcuch DevOps ma znacznie więcej do zaoferowania. Zacznij od narzędzia CI/CD i zobacz, 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 również zintegrować DevOps z otwartymi narzędziami dla agile:
Źródło: habr.com
