[DOgi]

#programowanie #programista15k #devops #kiciochpyta
Jaką wiedzę techniczną powinien posiadać mid level DevOps w 2024/2025 roku? Z jakimi zadaniami ma na co dzień co czynienia? Odrzućmy całkowicie kwestie legacy - powiedzmy, że będziesz szukał pracy w jakimś nowym startupie, które korzysta z technologii bleeding edge.

[DOgi]

Chat wypluwa coś takiego:

1. Kubernetes – Orkiestracja kontenerów

2. Docker – Konteneryzacja aplikacji

3.

[Hauleth]

@DOgi: Wygląda sensownie ta lista, ale ja bym po prawdzie bardziej się skupił na tym co jest po - niż na konkretnych programach, bo większość z nich ma alternatywy i część firm będzie używać innych rozwiązań, a nie tylko to co tutaj wymienione. Np. zamiast Dockera masz chociażby Podmana, zamiast Prometheusa może być np. InfluxDB, alternatywą dla Grafany jest np. Graphite, Terraform vs Pulumi, Ansible vs Puppet vs Chef, vs

[emitar]

@DOgi coś z bazami danych by się jeszcze przydało. Coś z programowania Bash/python, coś z clouda i chyba było by git

[BreathDeath]

@DOgi: Olej Jenkinsa i Gitlaba na rzecz GitHub actions. Nginx ingress controller to raczej nie jest używany w dobie np. EKS czy AKS.

[DOgi]

@Hauleth: @emitar @BreathDeath bardzo szanownemu gronu dziękuję.

Draftuję sobie toola do vmek na dedyku i chcę stworzyć przy okazji kilka use casów.

[rippie]

@BreathDeath: Wybacz, ale tutaj głupotę palnąłeś. Jak to nginx ingress controller nie jest używany przy EKS/AKS? XD Natywne LB AWSa I azure nie ogarniają wielu funkcjonalności routingu nginxa i controllery nadal są używane w 90% przypadkach produkcyjnych zastosowań (nginx/traefik).

Co do jenkinsa i gitlaba - O ile GitHub actions jest spoko do prostych i średnio skomplikowanych workflow, Jenkins nadal wygrywa swoją elastycznością integracji i prostotą obsługi dla zwyczajnego deva. W

[maxiek]

Mocna lista nie powiem, że nie. Problem taki - że nie mówi ona za wiele.

" Prometheus – Monitorowanie metryk Grafana – Wizualizacja metryk

No spoko, ale co to znaczy? Że powinno się umieć postawić cała architekturę do badania stanu infrastruktury, z alertami i wszystkim? Czy może po prostu umiejętność poruszania się po nich, dodanie jakiś alertów, jak trzeba to użycie ich api w jakiś jenkins jobach?

Jenkins – Automatyzacja CI/CD

[BreathDeath]

@rippie: Co do jenkinsa to ja od 2 lat migruje klientów na github actions.

Co do ingress na nginx to tak, jest używany, ale większość to AWS czy azure. Ja głównie robię chmurę, więc polecam to co popularne. K8s na bym stawiany ręcznie to nisza teraz.

Pisze z własnego doświadczenia.

[rippie]

@BreathDeath: Mylisz pojęcia i toole. Nginx ingress controller to narzędzie/dodatek do K8S. Nie ważne, czy to EKS, AKS, czy cokolwiek innego. https://github.com/kubernetes/ingress-nginx

[BreathDeath]

@rippie: Nie, nie mylę pojęć. Wiem, że jest nginx-ingress-controller oraz ingress-nginx. ;)
Ja uważam, że jeżeli używasz EKS, AKC czy GKE to tak naprawdę w większości przypadków tego nie potrzebujesz i wystarczą Ci mechanizmy dostarczane przez chmurę, np. aws alb ingress controller. Zresztą jak masz ingressa to także musisz przekierować do niego ruch, najczęściej load balancerem. 99% przypadków spokojnie ogarnia alb-ingress-controller. Ja mam własną firmę i stawiam ludziom infrastruktury, głównie

[rippie]

@BreathDeath: I nie wiesz, że ALB nie wspiera path rewritingu, więc do bardziej skomplikowanych API potrzebny jest nginx lub trafiki? ( ͡° ͜ʖ ͡°)

[BreathDeath]

@rippie: Wiem, że nie wspiera i co z tego? Widocznie API moich klientów jest nieskomplikowane. ;) Chociaż może kłamię deweloperom, że się nie da, bo jestem leniwy, a oni robią tak, żeby było dobrze? ;)

BTW Ja zazwyczaj do API używam envoy-proxy, sprawdzam tam sobie JWT i przekierowuje ruch. Ale stawiam to normalnie jako zwykły serwis i podpinam pod ALB. Zazwyczaj też nie używam traefika, mam takie podejście, że staram

[rippie]

@BreathDeath: Widzisz, ja nigdzie nie napisałem, że natywne ingressy w cloudzie się do niczego nie nadają i nie są używane z EKS/AKS :) Sporo dev'ów pewnie tak robi. Pracowałem przy startupach i w średniej wielkości korpo, gdzie tak robilismy. Teraz mam jednak do czynienia z klastrami stojącymi w govcloudach AWS oraz Azure i 90% z nich jest stawianych używając zewnętrznych ingress kontrolerów.
Pisanie że ingress kontrolery są passe i niszowe

[BreathDeath]

@rippie: Ja nie napisałem, że ingress controlery są złe. ;)
Napisałem, że moim zdaniem warto robić jak najprościej i dopiero później uczyć się bardziej skomplikowanych rzeczy.

[rippie]

@BreathDeath: no to zgoda :)

[some_ONE]

@BreathDeath: w przypadku ingress controllera najprościej to akurat użyć nginxowego a nie p-------ć się z tymi zabugowanymi wariantami od dostawców chmurowych

[BreathDeath]

@some_ONE: No nie wiem, ja wolę mieć jak najprościej i jak mam wystawić poda to wolę sobie wrzucić AWS ALB z targetem IP żeby łączył się bezpośrednio do poda zamiast dodawać dodatkowego hopa.
Jakie bugi masz na myśli np. w AWS ALB?

[BreathDeath]

więc poda na klastrze mogło już nie być, ale chmurowy load balancer jeszcze się nie zaktualizował i wciąż próbował routować do tego adresu IP ruch co kończyło się pięknymi 502/503

@some_ONE: W AWS działa to inaczej. Oczywiście jak uwalisz poda z --force to dostaniesz 500, ale normalnie masz wyrejestrowanie poda z load balancera. Tak samo jak odpalasz poda to jest aktywny dopiero jak się zarejestruje w LB. Zresztą w ingress

[some_ONE]

W AWS działa to inaczej. Oczywiście jak uwalisz poda z --force to dostaniesz 500, ale normalnie masz wyrejestrowanie poda z load balancera.

@BreathDeath: No to tutaj wygląda że działa tak samo.
I to się może wydarzyć nawet bez force'a. Pod jest w stanie terminating więc kontroler po stronie klastra zaczyna aktualizować chmurowy ALB. Pod się skasował, ale chmurowy ALB jeszcze się nie zaktualizował. Co wtedy?

Tak samo jak odpalasz poda to jest