Kilka myśli / pytań odnośnie zespołów
- Co obecnie robi zespół od infrastruktury? Uruchamia hello world na kubernetesie? Pisze swoją aplikację?
- Ogarnia środowisko, które na ten moment jest jeszcze środowiskiem dev / testowym.
- Stanowi support dla zespołu programistycznego.
- Zarządza (to duże słowo) Kubernetesem za pomocą Ranchera na którym stoi ów aplikacja + kilka innych mniejszych projektów typu wordpressy, systemy ticketowe etc.
- Ogarnia serwery na miejscu w serwerowni - dorzuca doń fizyczne graty, przepina, rozpina, podpina czyli to co old school admini.
- Próbuje zrozumieć problemy zespołu programistycznego nie mając kompletnie pojęcia jak sklejona została aplikacja jak już wspomniałem. Kompletny brak wiedzy na ten temat.
- Wystawia certyfikaty (u nas są tego tony, wszędzie potrzebujesz certyfikat).
- Sprząta po jednym takim architekcie teoretyku, który teorię zna naprawdę po mistrzowsku. Niestety jego praktyka bazuje na tej teorii z książek w których wszystko jak zawsze pięknie działa. Jak pewnie wiesz to w realnym świecie nigdy tak ładnie nie wygląda.
- I wiele innego szitu, który zajmuje dużo więcej czasu niż klasyczne 8h.
- Rozumiem, że jest zespół - zrobił 2/5 prac (ciekawe...) i nie ma CI? Grubo (i smutno). Chyba bym zaczął od tego (co jak rozumiem robisz). Tu może się da najwięcej współpracy ugrać.
W pewnym sensie jest. Aplikacja stoi łącznie na 3 albo nawet 4 środowiskach. Może nie tyle środowiskach co są 3-4 jej kopie.
- Jedna dla testów, które są przeprowadzane z docelowymi klientami.
- Druga dla zespołu klikającego w aplikacji.
- Trzecia w formie typowej piaskownicy, bo teraz się obudzono, że security nie do końca ma sens i trzeba je szybko przerobić.
- Czwarta została wdrożona u jednego klienta na zasadzie testów wewnątrz.
-
Zespół infrastruktury nie ma pojęcia dlaczego do budowy aplikacji zostały wybrane takie, a nie inne elementy (DB, biblioteki, frameworki etc.)
- ale dlaczego mieliby mieć pojęcie?
Ponieważ jest sporo problemów z samą aplikacją. I oczywiście narzekanie zespołu programistycznego, że wina leży po stronie zespołu infrastruktury. Nie ma sensownego toola, który mógłby monitorować flow całej aplikacji na środowisku testowym/dev. Często padają kontenery np. Redisa i nijak nie wiadomo jaki jest tego powód. Dodanie do compose restart: always
nie podnosi kontenera. Wobec czego na ostatniej prezentacji gdy "nagle" wszystko padało siedziała osoba od infry gapiąc się w terminal i gdy padało restartowała ręcznie :D
Po ostatnim spotkaniu i propozycji wpięcia jakiegoś porządnego monitoringu zespół programistyczny stwierdził (cytuję):
Haha! Chcecie tak nas tutaj dokładnie monitorować żeby zrzucać na nas winę?
Przykre, bo nie taki jest cel infry. W moim odczuciu powinni oni mieć monitoring wszystkiego żeby móc dostarczyć konkretne logi, a nie później się tłumaczyć dlaczego Kubernetes jest niestabilny (jest stabilny).
Wydaje mi się, że zespół infry lepiej zrozumie co gdzie szukać i ewentualne problemy w chwili gdy będzie wiedzieć jak zbudowana jest aplikacja. Ale mogę oczywiście być w błędzie.
Przykładowy temacik sprzed kilku dni.
- Pada prośba od zespołu programistycznego o dodanie headera dla CORS do jednego z modułów aplikacji, bo chłopaki mają błąd. Zespól infrastruktury nie wie czym ów CORS jest, gdzie go szukać i jaki nagłówek dodać. Złapanie jednego z programistów i zadanie mu konkretnych pytań pozwala oczywiście szybko zrobić temat wraz z restartem samej aplikacji.
Problem trywialny ale mimo wszystko jest to niejako aktualnie problem.
Ci/CD, dla niektórych środowisk jest. Aczkolwiek dla mnie to jakaś proteza nie mająca wspólnego zbyt wiele z automatyzacją. Bo co to za pipeline przy którym devops i tak musi wiecznie coś robić. Wraz z przenoszeniem środowisk. Mam tu na myśli fakt, że środowisko klikane przez testerów po ich akceptacji trzeba ręcznie przenosić na środowisko do prezentacji dla klientów.
Był docker-swarm połączony z TeamCity. Teraz jest Kubernetes połączony z TeamCity. Decyzje te zostały zapoczątkowane przez osoby, których już tu nie ma, a ja niejako wpadłem w to gościnnie i próbuję się rozeznać w temacie + wnieść coś co jakoś uporządkuje ten burdel.
Jedno środowisko jeszcze nie jest przeniesione więc trzeba je ręcznie siekać.
- Pobierać z jednego środowiska kontenery do siebie lokalnie.
- Tagować je pod drugie środowisko.
- Przelogować się na drugie środowisko.
- Wypychać je na drugi registry.
- Ubijać stare / podnosić nowe.
- Może powinna być jasna odpowiedzialność - za odpalenie i działanie, maintenance tej aplikacji odpowiada zespół programistyczny. Skoro wybrali technologię, architekturę to jakby naturalne.
Nie teraz to oni to wszystko "instalują". W tym momencie zespół od infra powinien być do pomocy i review.
W punkt. Próbujemy to właśnie ogarnąć ale do tego potrzeba. Teraz wygląda to tak:
- Wewnętrzny git z tonami branchy i o dziwo nie. To, że coś jest na
master
nie oznacza, że jest finalne i działające (w zależności od repo).
- Część leci do TC jako kod, a część jako artefakty - :D !?
- Następuje cały proces pchania tego w kontenery do lokalnego registry.
- Pchania kontenerów na K8s.
Teraz nie bardzo wiadomo kto dokładnie podjął takie decyzje, a nie inne więc chcemy to podzielić według jakiejś fajnej logiki. Z drugiej strony puszczenie programistów na infrastrukturę prosi się o kłopoty.
- Może niech zespół infra przygotuje demo jak sobie wyobraża aplikację, monitorowanie, debugowanie itd i zaprezentuje to na małym przykładzie,
Chyba tak bym to widział - niech to będą mentorzy, nauczyciele, coache od infra, ale nie oni to teraz powinni głównie teraz nad yamlami zapierniczać.
Dobra sugestia. Dodam jeszcze, że na pytanie czy w aplikacji jakoś logują błędy (na froncie logują wyrzucając komunikat Wystąpił błąd 093893984374
) dostałem odpowiedź, że: `tak, tak. Ludzie z infry chcieliby mieć (powinni?) dostęp do tych logów u siebie żeby móc podrzucać je do programistów.
W ogóle wydaje mi się, że wszelkiej maści zgarnianie logów powinna robić infra i rzucać je do programistów. Jestem w błędzie?
-
Zespół programistyczny sam zadecydował o tym kiedy i w jakich okolicznościach jakaś część aplikacji ma się skalować - nie wzięto pod uwagę, że Kubernetes może mieć to za przeproszeniem w d...e.
tego nie rozumiem - pewnie z powodu technologii użytej. Jak aplikacja jest zrobiona jako mikroserwisy to gdzie tu może być problem? I jak może tu kubernetes przeszkadzać?
Zastanawiam się czy jak aplikacja i jej superhiper framework (oczywiście zbudowany przez kilku geniuszy) zacznie się sama skalować wedle jakichś ichniejszych założeń to co się stanie w przypadku gdy infra zdecyduje zrobić swoje własne reguły dla Kubernetesa? Tu znowu wydaje mi się, że przy użyciu K8s takie tematy powinny zostać zdefiniowane bezpośrednio w nim, a nie samej aplikacji. Oczywiście tutaj również mogę być w błędzie i chętnie posłucham bardziej doświadczonych.
Lubię takie chore sytuacje. Zwykle i tak problem wynika z 2-3 konkretnych panów Edków, którzy robią nie to co powinni. Nie zawsze jest oczywiste jak ich zlokalizować.
I tak lepiej niż 3 zespoły programistyczne, które robią jedną aplikację, ale ze sobą nie gadają i każdy zespół robi po swojemu i od nowa - a takie akcje bywają.
Problem wynika jak już mówiłem z braku komunikacji. Stres zaczyna się w momencie gdy jest jakiś deadline
. Wtedy z góry idzie zjebka. I to trwa do prezentacji. Na prezentacji "jakoś" się uda więc lecimy dalej z tematem i nie cofamy się żeby naprawić ten burdel. Rączki na górze uściśnięte, papierki podpisane, uśmiechy wymienione, plecy poklepane.
Ja też jestem podniecony na samą myśl tej dramy. Ale podniecenie może minąć jak mnie ktoś jeszcze kilka razy "zirytuje" i pójdę sobie gdzieś gdzie nie będzie irytacji. Finalnie będziemy próbować wymusić niejako na obu zespołach pewne zachowania. Najpierw jednak pasowałoby wiedzieć co i na kim wymuszać. Stąd mój temat do bardziej doświadczonych, którzy już przerobili takie (podobne) problemy.