DevOps w praktyce
Podczas dostarczania rozwiązań dla naszych klientów coraz częściej w składzie zespołu projektowego pojawia się Inżynier DevOps. Kto to? Czy to tylko inne słowo na programistę? Nie tylko.
Myślę, że warto wytłumaczyć pojęcie DevOps - tym bardziej, że funkcjonuje ono w różnych kontekstach, a jego znaczenie rozszerza się i obejmuje kolejne obszary. Chciałbym wyjaśnić, skąd wzięła się potrzeba nowego podejścia w dostarczaniu oprogramowania oraz jak wygląda realizacja tej filozofii w e-point.
Dlaczego DevOps
Tradycyjnie narzędzia i aplikacje były wybierane oraz wstępne konfigurowane przez zespół deweloperski (Dev), a następnie, po przygotowaniu instrukcji instalacji i konfiguracji były przekazywane do zespołu administratorów (Ops). Instrukcje instalacji i podręczniki użytkowania stanowiły wówczas kontrakt definiujący podział odpowiedzialności między deweloperów i administratorów.
W tych warunkach zespoły Dev i Ops pracowały zazwyczaj osobno. Oczywiście, musiały się ze sobą komunikować, ale często między przedstawicielami tych dwu profesji dało się wyczuć napięcie. Programista postrzegał administratora jako przeszkodę na drodze do uruchomienia aplikacji. Administrator zaś postrzegał programistę jako źródło ciągłych zmian, nowych wymagań i zagrożenie dla wysokiej dostępności, bezpieczeństwa i stabilności systemu.
To trudna sytuacja, ale można było tę złożoność opanować. Przynajmniej w modelu kaskadowym oraz, póki aplikacje zależały od stosunkowo niewielkiej ilości komponentów, a nowe wersje samej aplikacji i komponentów pojawiały się co parę miesięcy.
Ten podział odpowiedzialności zaczął się chwiać wraz z pojawieniem się metod zwinnych (np. Agile). Ich zastosowanie wprowadziło szybsze tempo zmian i częste wydania nowych wersji aplikacji - już nie co parę miesięcy, ale nawet co tydzień czy dwa. Każde wydanie mogło pociągać za sobą również zmiany wymagań od innych komponentów. Oprogramowanie zaczęto produkować szybciej, więc wąskie gardło procesu przesunęło się w stronę „ostatniej mili”, czyli dostarczenia oprogramowania do środowisko produkcyjnego. A tu czekałyby instrukcje instalacji lub co najmniej instrukcje aktualizacji z wersji do wersji, nie tylko aplikacji, ale potencjalnie innych komponentów. Przy tradycyjnym podziale ról programistów i administratorów proces dostarczenia trwałby długo i byłby podatny na błędy ludzkie.
Potrzeba zrównania tempa rozwoju oprogramowania i możliwości jego wdrożenia zaowocowała rozciągnięciem zasad zwinnych również na obszar tradycyjnie należący do Ops, czyli zwinne zarządzanie wymaganiami i zmianami w infrastrukturze.
Nie było innego rozwiązania - aby oprogramowanie trafiało na produkcję razem z cyklem częstych, zwinnych wydań, specjaliści Ops musieli stać się częścią zespołu Dev, ewentualnie niektórzy deweloperzy musieli wyjść poza ulubione IDE i poznać domenę Ops – klastry, systemy, techniki wysokiej dostępności, zapory ogniowe i zasady bezpieczeństwa.
Nowe podejście zostało nazwane właśnie DevOps.
Czym dla nas jest DevOps
Dla nas DevOps to z jednej strony świadomość i wiedza o infrastrukturze w zespole programistów (deklaratywne kodowanie infrastruktury), z drugiej zaś strony, dostarczanie przez administratorów środowiska, które będzie w stanie sprawnie uruchomić nie tylko aplikację, ale również wszystkie wymagane przez nią komponenty, najlepiej automatycznie, przy żadnym lub minimalnym zaangażowaniu człowieka.
Cały cykl życia aplikacji wraz z kluczowymi przenikającymi się obszarami doskonale ilustruje, klasyczny już dla metody, rysunek przypominający symbol nieskończoności.
DevOps w praktyce: Docker, Kubernetes i OpenShift
Aby w pełni wykorzystać potencjał metody DevOps potrzeba technologii, która stanie się płaszczyzną współpracy i umożliwi deweloperom wpływ na kolejne środowiska, w których będzie działać aplikacja - od stacji deweloperskiej zaczynając, na środowisku produkcyjnym kończąc.
Po analizie i testach dostępnych rozwiązań zdecydowaliśmy się w e-point na poniższy stos technologiczny:
- Docker
- Kubernetes
- OpenShift
Pierwsza niezbędna technologia to kontenery (docker). Kontenery to jeszcze nie DevOps, ale ich użycie pozwala w sposób zwinny podejść do procedur instalacji. Zamiast instalatora i instrukcji instalacji, specjaliści DevOps tworzą całe obrazy (kontenery), które definiują potrzeby aplikacji. Nie tylko zawierają one binaria, ale także określają:
- Jakich zasobów potrzebuje kontener
- Na jakie wartości konfiguracyjne trzeba zwrócić uwagę
- Jakich innych narzędzi i kontenerów potrzebuje do działania
- Jakie usługi sieciowe udostępnia aplikacja
Kontenery pozwalają uruchomić te same dockery na stacji roboczej, w środowisku CI i QA, a na końcu w środowisku produkcyjnym. W ten sposób minimalizują ryzyko pomyłek przy instalacji oraz skracają czas przygotowania nowej wersji.
Kontenery działają na pojedynczej instancji serwera, natomiast uruchomienie produkcyjne wprowadza wymóg wysokiej dostępności i skalowania, co pociąga za sobą konieczność uruchamiania wielu kontenerów na różnych serwerach oraz zapewnieniu między nimi komunikacji - jednym słowem potrzebna jest metoda definiowania i uruchamianiu aplikacji w klastrach. Ten poziom zarządzania dostarczają nam Kubernetes.
To jednak nie wszystko. Potrzebowaliśmy technologii, w której będziemy mogli uruchamiać aplikacje bezpiecznie, zarządzając prawami dostępu do repozytoriów aplikacji oraz do zasobów w ramach infrastruktury. Takie możliwości dostarcza OpenShift:narzędzie do zaawansowanego zarządzania dockerami oraz kontenerami, zarówno obrazami, jak i wieloma uruchomionymi instancjami obrazów.
W nowym modelu administratorzy zarządzają infrastrukturą, zasobami i bezpieczeństwem. Nie muszą już pochylać się nad instalacją każdego narzędzia wg. właściwej dla niego metody, ponieważ jedyną metodą jest kontrakt definicji kontenerów, a specjaliści DevOps uruchamiając aplikacje i komponenty zależne zużywają tylko dostępną dla ich projektu określoną ilość zasobów.
Podsumowując: po pierwsze, rozpoczęcie myślenia o DevOps zaczyna się już w kodzie i zdefiniowaniu poprawnego procesu produkcji oprogramowania, który nie tylko wspiera, ale wręcz wymusza istnienie mechanizmu automatycznego budowania oraz testów.
Po drugie, proces przydzielania zasobów infrastruktury musi być automatyczny. Bardzo trudno prowadzić sprawnie działania DevOps bez warstwy pośredniej między infrastrukturą a kontenerami w postaci chmury prywatnej, publicznej lub bezpośrednio OpenShift.
Kiedy warto zastosować tę metodykę?
Dzięki wdrożeniu podejścia DevOps, zwiększamy szybkość wydawania nowych wersji, minimalizujemy ilość i czas trwania przerw technicznych związanych z uruchomieniem nowej wersji oraz redukujemy liczbę błędów, wynikających z różnic między środowiskami. Pozwala ona także na lepsze rozumienie wymagań niefunkcjonalnych w całym zespole projektowym oraz optymalne wykorzystanie tak czasu pracy deweloperów, jak i zasobów infrastruktury (jeżeli DevOps będzie związany z użyciem kontenerów).
DevOps warto zastosować zawsze, gdy pracujemy w metodyce zwinnej. W sytuacji, gdy aplikacja to raczej cały system, czyli zestaw aplikacji lub mikroserwisów, zdecydowanie polecam użycie kontenerów wraz z technologią konstrukcji klastrów.Trzeba jednak pamiętać że nie warto robić nic “dla sztuki” i wdrażać DevOps tylko dlatego że to temat na czasie.