@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. WPokaż całość

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

@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 niszowePokaż całość

@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, vsPokaż całość

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

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

Pokaż całość

@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.

@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

@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łówniePokaż całość

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

@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 staramPokaż całość

@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.

@BreathDeath: no to zgoda :)

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

@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: no nie wiem jak z AWSowym, bo z niego nie korzystałem ale natywny Azurowy miał kiedyś mega z-----y design gdzie:
1. działał sprawnie tylko z jednym określonym pluginem sieciowym (Azure CNI), jakiekolwiek Calico, Cilium czy cokolwiek innego go dyskwalifikowało
2. ten plugin sieciowy z którym działał wymagał adresacji każdego poda adresem z sieci wirtualnej co było tragedią w środowiskach hybrydowych, bo nagle twój 3 node'owy klaster wymagał adresacji sieci niePokaż całość

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 ingressPokaż całość

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

Pokaż całość

@some_ONE: Podczas rolling update nie masz downtime, bo kontroler dba czy pod jest zarejestrowany w LB. Jak nie jest to nie idzie dalej deployment. Nie ma sytuacji, że deployment poszedł, a nie ma lodów w alb. Tutaj nie ma ryzyka bo masz pod readiness gate. Do tego jak pod jest terminated to kontroler od razu mówi ALB, że na wyrejestrować Target. Nie musisz czekać aż helathcheck się nie uda. ToPokaż całość