2016-11-22 DevOpsDays Warsaw 2016

Kilka suchych faktów na początek

Dzięki uprzejmości Łódzkiego Juga oraz odrobinie szczęścia podczas losowania, miałem możliwość uczestniczenia w świetnej konferencji DevOpsDays Warsaw 2016, która była organizowana przez firmę Proidea i tak samo jak inna duża warszawska konferencja 4Developers, miała miejsce w hotelu Gromada blisko Lotniska Chopina.

Format

Na konferencji była jedna ścieżka, co dosyć mocno ułatwiało wybór. Prezentacje trwały po 30 minut, ale jedna godzina pierwszego dnia była poświęcon na tzw. Ignite talks, na który każdy mógł się zgłosić z 5 minutową prezentacją. Ponadto, na koniec każdego dnia przewidziane były open space'y, czyli dyskusje w mniejszych gronach na interesujące tematy.

Dzień pierwszy

Oczywiście zaczęło się od rejestracji, która poszła bardzo gwałtownie i sprawnie (dużo szybciej niż na wspomnianej wcześniej 4Developers), więc na ceremonii otwarcia mieliśmy pełną salę. Szybka ankieta wśród uczestników wykazała, iż procentowy udział devów i opsów był parktycznie 50 na 50%. Zaskoczeniem była jednak bardzo duża liczba ludzi z tak zwanego enterprise'a, względem ludzi ze startupów lub małych firm.

Talk #1: From Monoliths Trough Cloud Native to Software Supply Chains

Świetna prezentacja pokazująca jak kontenery zmieniły świat. Nie nasz, programistyczny, ale ten przemysłowy. Jak kontenery, dzięki łatwości transportu, pozwoliły przenieść fabryki dalej od brzegu morskiego i przyczyniły się do utworzenia łańcucha dostawców, którzy nie musieli znajdować się w jednym miejscu. Pozwoliło to też na specjalizacje poszczególnych firm. Było to o tyle ciekawe, iż powoli będziemy dochodzili do takich samych specjalizacji: każdy będzie mógł dostarczać swoje, specjalizowane kontenery i duże firmy (jak Google, Facebook, Twitter) nie będą musiały budować całego stosu usług tylko będą korzystali z usług innych dostawców.

Talk #2: A Journey Towards SRE @ Ocado

Prezentacja otwierająca oczy na bardzo interesujący fakt - operation zajmuje więcej czasu niż development. W miarę rozwoju systemów, zespół operation powinien być powiększany. Ale czy tak sie dzieje naprawdę? Inna bardzo ważna prawda, o której zapominamy, to fakt, iż najważniejszy feature każdego systemu to: It works, co odnosi się do nowych, ale przede wszystkim do istniejących już funkcji systemu.

Talk #3: The OutSystems R&D Continuous Delivery Journey

Moim zdaniem jedna z najlepszych prezentacji na tej konferencji. Opowiadała o długiej drodze jaką przeszła portugalska firma, z której przybył prelegent. Z małego zespołu z ciekawym produktem i brakiem testów, udało im się zbudować Continuous Delivery w miarę przybywania nowych funkcji, integracji i ludzi. Po maksymalnie godzinie byli gotowi do przekazania artefaktów na produkcję.

Talk #4: DevOps Transformation Tailored to Organizational Culture

Jak zmienić kulturę swojej firmy w stonę kultury Devops? Okazuje się, iż w każdej firmie są obecne różne kultury: hierarchiczna, klanowa, adhokracyjna oraz zorientowana na market. Najpierw musimy zrozumieć, jaką kombinację kulturową prezentuje nasza firma oraz w którą stronę chcemy iść. Co interesujące z wielu analiz wynika, iż firmy chcą dążyć do kultury adhortacyjnej i jest to właśnie transformacja DevOpsowa.
Ciekawostka: pierwszy raz widziałem na prezentacji link do Linkedin prelegenta.

Talk #5: The Song of JBoss and Chef

Była to interesująca prezentacja, jak dzięki narzędzia Chef zarządzać swoim klastrem JBossów. Nie było to proste, bo wymagało korzystania tylko z CLI JBossa (a dostawcy najbardziej lubią przesyłać instrukcje w formacie screenshotów...). Dzięki determinacji zespołu możliwe było powiększenie klastra o dwa dodatkowe węzły w jedną godzinę.

Talk #6: Building a Resilient Log Aggregation Pipeline Using Elasticsearch and Kafka

Świetna prezentacja, choć tempo jej prowadzenia było bardzo duże, by w 30 minut przekazać tak wielką ilość informacji i dobrych rad. jeżeli zarządzasz klastrem Elasticsearch to ta prezentacja jest właśnie dla Ciebie. jeżeli chcesz się dowiedzieć jak podzielić swój klaster, jak skonfigurować poszczególne węzły, by były zoptymalizowane pod kątem swojej funkcji, jak przydzielić do nich zasoby, to musisz to zobaczyć. Było tutaj też trochę informacji na temat konfiguracji Kafki jako scentralizowanego buffora, konfiguracji dostawcy logów oraz systemu operacyjnego dla takiego stosu technologicznego.

Talk #7: Contive – Container Networking Done Right with Cisco ACI Fabric

Najsłabsza moim zdaniem prezentacja, prowadzona przez dwóch prelegentów. Pierwszy z nich opowiedział o narzędziu Mantl opartego na Mesosie, a drugi prelegent skupił się na zaletach narzędzia Contive od Cisco.

Ignite talks

Miało być maksymalnie 10 prelegentów - było ich 5. Dobra rada dla organizatorów: zapisujcie nie tylko tytuły prezentacji, ale i zgłaszających je, bo potem prelegenci się nie zjawiają:)

Ignite talk #1: How to manage on calls rotation effortlessly

Bardzo interesująca prezentacja o powiązaniu DataDog, PagerDuty, aplikacji na Heroku oraz Twilio do obsługi i przekierowania połączeń. Była ona szczególnie interesująca dla mnie, bo właśnie taką aplikację potrzebujemy wdrożyć.

Ignite talk #2: Invitation to TestWarez conference

Zaproszenie na konferencje TestWarez 2017 - tak po prostu:)

Ignite talk #3: DevOps mind of security & Ignite talk 4: Testing infrastructure

Szybka prezentacja, jakie mamy zasady (ssh wystawione na innym niż 22 porcie, zasady tworzenia haseł) oraz jaki jest wpływ czynników ludzkich (szczególnie skleroza i lenistwo) na bezpieczeństwo systemów. Jak sobie z tym radzić i czego pilnować? Mamy zestaw reguł opisany w STIGs - Security Technical Implementation Guides i powinniśmy z nich korzystać, a choćby automatycznie je sprawdzać dzięki np. Ansible (Ignite talk #4).

Ignite talk #5: Puppet vs Chef vs Ansible vs Bash

Mamy dużo dostępnych narzędzi do automatyzacji - prelegent w ekspresowym tempie wyjaśnił, jakie są zalety i wady każdego z nich. Najważniejsze:

• bash przegrywa, bo nie ma możliwości łatwego rollbacku, ale dla obrazów dockerowych jest najlepszy
• puppet skompiluje wszystko na masterze - ale właśnie master jest potrzebny
• chef - możesz spodziewać się błędów w runtime
• ansible - najlepszy do fire & forget

Open spaces

Open spaces zaczęły się od propozycji - zebranych zostało około 13, a następnie każdy dzięki formularza Google głosował na interesujące go tematy. Wybranych zostało 8 tematów. Dla mnie najciekawsze tego dnia były Continuous delivery pipelines (najciekawsze cześć dyskusji dotyczyła zagadnienia testowania pipeline'ów) oraz F**k ups - worst experience (aż włos się jeżył na głowie).

Dzień drugi

Pierwsze dwie prezentacje przeszły mi koło nosa, ponieważ korki w Warszawie postanowiły zorganizować mi dwugodzinną podróż na miejsce prezentacji. Tak zwane: dogodne miejsce konferencji blisko lotniska nie zawsze znaczy, iż będzie łatwo się na nią dostać...

Talk #1 & Talk #2

W autobusie...

Talk #3: Nobody Puts Java in a Container

Dlaczego nie uruchamiać aplikacji Javowych na dockerze? Nigdy o tym nie myślimy. Prelegent przez większość czasu opowiadał o tym jak działa docker, o co chodzi z namespaces i cgroups, a dopiero ostatnie 5 minut traktowało o samej Javie. Tylko, iż bez tak długiego wstępu trudniej byłoby zrozumieć dlaczego nie uruchamiać JVMów na dockerze. Problemem jest to, iż mimo iż docker pozwala na ograniczenie dostępnej pamięci lub ilości procesorów, JVM w wersji 8 nic sobie z tego nie robi i uruchamia się widząc wszystkie zasoby maszyny pod spodem. Dlatego czasem wybór wirtualizacji jest lepszy od konteneryzacji, bo daje większą izolację.

Talk #4: Learning From Configuration Management

Prezentacja opowiadająca o problemach z jakimi spotykamy się przy automatyzacji, które też paradoksalnie są często wymieniane jako plusy, np. niezmienna architektura, centralizacja, ukryte zależności systemów operacyjnych. Aktualnie narzędzia te przypominają instrumentacje (zarządzanie z boku), a my potrzebujemy choreografii, czyli dynamicznego reagowania na zainstniałe sytuacje. Rozwiązaniem tutaj ma być narzędzie Habitat od Chef.

Talk #5: Managing Server Secrets at Scale

Konkretny problem i wspaniałe rozwiązanie do niego: mamy setki albo tysiące serwerów, każdy serwer potrzebuje kilku kluczy: kluczy ssh, klucz do szyfrowania dysku, serwera zarządzania konfiguracją, tokenów do aplikacji itp. Gdzie przechowywać takie klucze? Przecież nie będziemy manualnie ich przepisywać z płaskich plików z naszych komputerów. Przy wielkich data center to jest niewykonalne. Z pomocą przychodzi nam tu UEFI i możliwość zapisywania zmiennych w specjalnej przestrzeni w BIOSie. Jest ona łatwo dostępna, ale też bardzo mała, dlatego nie zapiszemy tam wszystkich kluczy. Jednak wystarczy zapisać jeden klucz, a z niego w deterministyczny sposób wygenerować inne podczas uruchamiania systemu. Do tego właśnie służy narzędzie gokey.

Talk #6: How We Phased out Motivational System: About Motivation in DevOps Culture

Problem motywowania ludzi nie jest nam obcy. Wszyscy odkrywają, iż pieniądze to nie wszystko. Wycieranie pieniędzmi łez spowodowanych przez smutne zadania i atmosferę w pracy często nie wystarczą. Prezentacja powinna być obejrzana szczególnie przez firmy, które chcą sprawić, by ludziom pracowało się lepiej. Mam szczęście pracować w firmie, która większość z przedstawionych tu rzeczy używa w praktyce, dlatego mogę gorąco polecić ten sposób prowadzenia firmy.

Talk #7: Monitoring and Log Management for Docker Swarm and Kubernetes

Dobre porównanie możliwości zarządzania logami, gdy mamy Kubernetesa lub Docker Swarma. Poza logami ważne jest też zbieranie metryk. Istotne jest to, iż są to mechanizmy wbudowane w dockera. Dla naszych aplikacji musimy sami radzić sobie z agregacją logów i metryk.

Talk #8: The Pipeline: a Shift from Classic UI-based Job Configuration Tool to a Domain-specific Language

Od historii Jenkinsa (i Hudsona) do pipeline'ów w Jenkinsie 2.0. Niestety uważam, iż co do samego tematu pipeline oraz DSL, dużo szybciej można byłoby pozyskać więdzę z tutoriali dostępnych w internecie...

Talk #9: Patching 100 OpenStack Compute Nodes with Zero-day Patch within 16 Hours

Prelegent skupił się na patchowaniu libvirta używanego w OpenStacku. jeżeli chcesz się dowiedzieć jak w 16 godzin wgrać łatkę do całej masy maszyn wirtualnych i zrestartować je, ale tak by klienci tego nie odczuli, to ta prezentacja jest właśnie dla Ciebie. Hint: wyłącz Tunneling :)

Open spaces

Ponownie przeszliśmy przez proces zgłaszania i wyboru tematów do dyskusji. Tym razem dla mnie najciekawszy temat Automatic log anomaly detection. Wnioski: jeżeli jesteś dużą firmą, to albo już masz narzędzie do takiej analizy, albo stać Cię na enterprise'ową wersję oprogramowania. jeżeli jesteś małą firmą, to niestety piszesz coś własnego lub bierzesz narzędzie, które ktoś już oddał jako open source. Tylko, iż jeżeli coś staje się w tym przypadku dostępne, tzn. to są już dużo lepsze narzędzia.

Problemy

Konferencja nie ustrzegła się błędów i problemów. Przede wszystkim trudności przysparzało podłączanie komputerów przed prezentacjami. To zawsze zajmuje dużo czasu i zawsze coś pójdzie nie tak...

Kilka słów na koniec

Konferencję mogę z czystym sumieniem polecić wszystkim zainteresowanym tematyką DevOps lub administrowania systemami informatycznymi. Sponsorzy dopisali, a prelegenci byli w większości dobrze przygotowani. Polecam też obejrzenie nagrań z konferencji, które ku mojemu zdziwieniu, zaczęły się pojawiać już w trakcie drugiego dnia konferencji.
Idąc na konferencję zastanawiałem się, co jest największym problemem w świecie DevOpsów... Myślałem, iż jest to wojna Kubernetes vs. Docker Swarm. Okazuje się, iż problemem tym jest wdrażanie odpowiedniej kultury w firmach oraz zarządzanie logami. To było całkiem interesujące odkrycie.