W dniach 22 -23 listopada w hotelu Gromada na Okęciu odbyła się druga edycja konferencji DevOpsDays Poland. DevOps jest metodą współpracy programistów, administratorów systemów oraz wdrożeniowców pozwalającej organizacji na szybkie wytwarzanie i wydawanie kolejnych wersji oprogramowania. Metodę adaptują organizacje, którym zależy na jak najszybszym i bezbolesnym wdrażaniu zmian i udostępnieniu ich szybko użytkownikom końcowym. DevOps kładzie też duży nacisk na komunikację oraz współpracę w zespole.
Na konferencji można było uczestniczyć nie tylko w prezentacjach wygłaszanych przez specjalistów z całego świata, ale także forach typu Openspace. Przed każdym spotkaniem uczestnicy konferencji mogli zasugerować interesujący ich temat. Po zebraniu sugestii tematów można było zagłosować na najciekawszy i wziąć udział lub wysłuchać prelekcji.
Chwilkę po wejściu do hotelu Gromada Okęcie, gdzie odbywała się konferencja na mojej szyi zawisła plakietka, na której krzywymi literami nabazgrałem swoje imię. Od razu moją uwagę przykuł bardzo ciekawy design grafik promujących konferencję. Ktoś wykonał przy nich kawał świetnej roboty.
First day
Pini Reznik: From Monoliths Through Cloud Native to Software Supply Chains
Wykład rozpoczął się od przedstawienia historii wynalezienia kontenera transportowego. Pini opisał jaki wpływ na przemysł w skali globalnej miał ten fakt. Koszt transportu dowolnego towaru spadł na tyle, że opłacalne stało się tworzenie poszczególnych części produktu w oddalonych od siebie geograficznie częściach świata. Można to sobie lepiej zobrazować wyobrażając sobie w ilu różnych krajach i dzięki ilu różnym dostawcom podzespołów powstawał sprzęt, na którym czytacie teraz tę recenzję.
Okazało się, że historia ta była analogią dla bieżącej sytuacji w wytwarzaniu oprogramowania. Podobnie jak kontener transportowy zrewolucjonizował transport w skali globalnej tak DevOps zrewolucjonizuje sposób w jaki tworzymy oprogramowanie. Popularyzacja konteneryzacji, usług w chmurze i inne ostatnio obserwowane trendy sprawiają, że coraz łatwiejsze staje się tworzenie oprogramowania przy udziale podwykonawców. Postęp w dziedzinie sztucznej inteligencji pozwoli na optymalizację procesów. Duże monolityczne organizacje staną się konglomeratami przedsiębiorstw zupełnie jak Alphabet Inc.

Na kolejnym wykładzie dowiedziałem się czym jest Site Reliability Engineering. Najważniejszą funkcjonalnością każdego programu jest to, że działa niezawodnie. Zapewnienie niezawodności działania powinno być integralną częścią procesu tworzenia oprogramowania. Grzegorz Cempla opowiedział o tym jaką drogę przebyła jego firma przy wdrażaniu SRE i podzielił się z nami kilkoma dobrymi radami.
Następnie wykład, podczas którego Diogo Oliveira mówił z kolei z jakiego powodu i w jaki sposób jego firma wdrożyła Continuous Delivery. Dzięki wykorzystaniu narzędzi do zarządzania konfiguracją (Chef – https://www.chef.io), automatyzacji CD (GoCD – https://www.go.cd) oraz przeniesieniu infrastruktury w chmurę znacznie usprawniony i przyspieszony został proces testowania oprogramowania. Diogo zwrócił uwagę na użyteczność przeprowadzania sesji informacyjnych o zaletach Continuous Delivery wśród członków zespołu. Jak powszechnie wiadomo na każdej konferencji jest przynajmniej jeden slajd z mistrzem Yodą. Tym razem Diogo pokazał slajd, na którym Drużyna A szczerzy kły, ktoś wykuwa najmniejszy miecz świata, a mistrz Yoda ostrzega, że “No tests is the path to the dark side”.

Po przerwie na kawę i ciastko Tomasz Torcz opowiedział o tym w jaki sposób ożenił Jboss’a z Chef’em. Dzięki temu był w stanie niemal natychmiast podnieść kolejne hosty wirtualne w sytuacji dużego obciążenia.
Rafał Kuć: Building a Resilient Log Aggregation Pipeline Using Elasticsearch and Kafka
Ciekawy wykład związany z tematyką agregacji dużej ilości logów. Współcześnie działające systemy informatyczne nie tylko przetwarzają ogromne ilości informacji ale także często generują ich równie wiele. To na podstawie logów jesteśmy w stanie stwierdzić czy któraś część systemu działa nieprawidłowo. Dlatego gromadzenie logów oraz ich analiza stają się coraz istotniejsze.
Rafał pokazał jak zmierzyć się z tym problemem wykorzystując Elasticsearch w połączeniu z Apache Kafka. Zwrócił uwagę na fakt, że dobór odpowiedniej strategii przechowywania logów w indeksach Elasticsearch może mieć duże znaczenie. W kontekście pracy w klastrze indeksowanie oparte o czas może się okazać mniej optymalne niż indeksowanie w oparciu o rozmiar logów. Następnie omówione zostały zalety zastosowania Kafki w roli scentralizowanego bufora dla logów. Prowadzący zalecał też, o ile to możliwe zapisywanie logów w formacie JSON. Dzięki temu można je gromadzić w Elasticsearch pomijając konieczność ich przetwarzania. Bardzo ciekawa prezentacja naszpikowana świetnymi praktycznymi radami. Doskonale przekazana praktyczna wiedza, której próżno szukać w książkach!
Second day
Frank Scholten: minimesos – The Experimentation and Testing Tool for Apache Mesos
Apache Mesos jest managerem klastra, który pozwala na wydajne współdzielenie jego zasobów między działające na nim aplikacje i frameworki (np. Marathon). Dzięki minimesos możemy w prosty i szybki sposób wypróbować Mesos’a w akcji. Twórcy tego narzędzia inspirowali się vagrant’em. Po zainstalowaniu narzędzia, w konsoli wpisujemy polecenie minimesos up i po chwili na naszej lokalnej maszynie mamy postawiony cały klaster. Jest to świetne narzędzie do nauki i eksperymentowania. Na tym jednak nie kończą się jego zalety. minimesos może być odpalony z poziomu testu JUnit. Daje nam to możliwość symulowania działania Apache Mesos na potrzeby testów.
Jörg Schad: Nobody Puts Java in a Container
Konteneryzacja, a w szczególności Docker stają się z dnia na dzień coraz bardziej popularne. Wiele firm zdecydowało się na przeprowadzkę z maszyn wirtualnych na kontenery. Kontenery są lżejsze, szybsze i “w dotyku” podobne do maszyn wirtualnych. Należy jednak pamiętać, że nimi nie są. Używają one kernela swojego gospodarza i w zasadzie są tylko pewnym zbiorem uruchomionych procesów. Dzięki mechanizmom (cgroups, namespaces) kernela aplikacja działająca w kontenerze widzi abstrakcję systemu operacyjnego. Jednakże procesy Java 7 i 8 nie widzą tej abstrakcji w sposób poprawny. Dla aplikacji napisanych w Javie konieczne jest ręczne określenie granic CPU i pamięci jeśli mają bezproblemowo funkcjonować w kontenerze. Java w wersji 9 ma rozwiązywać problem jeśli chodzi o CPU. Nie ma natomiast jeszcze gotowego rozwiązania kwestii widoczności ilości dostępnej pamięci. Bez odpowiedniej konfiguracji procesy Javowe będą myślały, że mają dostępną na swoje potrzeby całą pamięć gospodarza. To może szybko skończyć się OutOfMemoryError. Jörg wykonał kawał dobrej roboty wyjaśniając od początku do końca podstawy problemu i wskazując jego rozwiązanie.

Po tym jak Jörg zgarnął zasłużone brawa od widowni Seth Thomas z Chef opowiadał czego nauczyło go zarządzania konfiguracją. Zwrócił on uwagę na aspekty tej dziedziny, które nie są jeszcze doskonałe i których działanie można poprawić. Seth wskazał narzędzie Habitat by Chef – https://www.habitat.sh jako odpowiedź na niektóre z tych niedoskonałości.
Stefan Thies: Monitoring and Log Management for Docker Swarm and Kubernetes
Zarządzanie logami staje się niezwykle skomplikowanym problemem jeśli weźmiemy pod uwagę jeden parametr – skalę. Obsłużenie tysięcy węzłów generujących nieustannie ogromną ilość logów może się okazać niemożliwe bez scentralizowanego systemu zarządzania logami. Stefan przedstawił podstawy działania dwóch narzędzi do zarządzania kontenerami w klastrach Kubernetes oraz Docker Swarm i wskazał najistotniejsze różnice między nimi. Oba te narzędzia mają jeden wspólny mianownik, są oparte o Docker’a. Dzięki temu można przykładowo stworzyć agenta, który będzie monitorował metryki kontenera. Wykorzystanie Docker API pozwala także na zautomatyzowanie odkrywania kontenerów i uruchamianie takich agentów na żądanie. Interesująca i dobrze przygotowana prezentacja.
Sebastian Krzyszkowiak: The Pipeline – a Shift from Classic UI-based Job Configuration Tool to a Domain-specific Language
Wszyscy znamy, kochamy i szanujemy Jenkins’a. Wszystkim jest też wiadomo, że Jenkins w wersji 1 ma swoje wady. Chyba największą z nich jest możliwość konfiguracji jedynie z poziomu interfejsu użytkownika. Przy większych projektach konfiguracja staje się nieczytelna i trudna w utrzymaniu. W kwietniu 2016 roku został wypuszczony Jenkins w wersji 2. Jedna z funkcjonalności dostępnych w wersji 1 tylko w postaci pluginu została dodana do podstawy. Mówię tu o Jenkins Pipeline, który pozwala na tworzenie konfiguracji Jenkinsa w sposób programowalny. W tym celu tworzymy plik Jenkinsfile i w nim określamy jak ma wyglądać zadanie Jenkinsa. To podejście daje duże możliwości. Możemy przykładowo stworzyć build aplikacji, a następnie uruchomić testy integracyjne razem z testami funkcjonalnymi w tym samym czasie. Jeśli nie jest ci obce programowanie w Groovy to w prosty sposób możesz również rozszerzyć funkcjonalność oferowaną przez Jenkins Pipeline.
Podsumowanie
Udana i profesjonalnie zorganizowana konferencja dla wszystkich zainteresowanych tematyką DevOps. Organizatorzy zadbali nie tylko o wysoką wartość merytoryczną wykładów ale także o dobre samopoczucie uczestników. Wiadomo przecież, że nic tak nie poprawia samopoczucia jak oklepanie koledze buzi w Mortalu zakończone udanym Fatality :))

Po ostatniej prezentacji przyszedł czas na aspekt hazardowy każdej konferencji czyli losowanie nagród ze stoisk. Bardzo liczyłem na to, że dowiem się wreszcie jak mieszkanie urządzili sobie moi sąsiedzi ale niestety quadcoptera z kamerką HD wygrał ktoś inny.

Do zobaczenia na DevOpsDays Warsaw 2017 !!!
Michał “Kwadrat” S.
1 komentarz