Używa ktoś z was kubernetesa i podejścia GitOps?
Interesuje mnie ten temat, a w szczególności jak realizujecie proces przepływu artefaktów pomiędzy środowiskami (nie wiem jak po polsku fachowo nazywa się artifact promotion).
Z tego co się orientuję to sam GitOps nie udziela na tę kwestię odpowiedzi i nie ma jeszcze utartych standardów.
W tej terminologii chodzi o reużywanie tego samego artefaktu dla każdych kolejnych środowisk (poprzez promowanie do innego registry), po przejściu poszczególnych kryteriów dla każdego z nich?
Jeśli tak, to mi osobiście nie zdarzyło się tego podejścia użyć (a nawet o nim słyszeć) - zazwyczaj korzystałem z osobnych registry, odizolowanych od siebie z osobnymi artefaktami.
Tak się zastanawiam, czy nie sprowadza się to do zwiększonej złożoności rozwiązania?
Przykładowo w przypadkach gdy:
Poza tymi przemyśleniami to całkiem ciekawie brzmi.
Same obrazy to jedno i w sumie tutaj bez różnicy czy mamy GitOps, czy nie, bo i tak trzeba podjąć decyzję czy mamy jeden rejestr i współdzielone obrazy, czy np. rejestry dla każdego środowiska.
W tym temacie bardziej chodziło mi o wszystkie definicje kubernetesowe trzymane w repo, które obserwuje operator GitOps.
Jak zrobić automatykę w przypadku mikroserwisów i wsparciu tradycyjnych narzędzi CI/CD. Jak najlepiej podejść do struktury repozytorium z definicjami k8s (różne gałęzie czy może foldery w jednej gałęzi). W takim repo część definicji to będą definicje mikroserwisów, a część to definicje infrastruktury działającej na k8s (service meshe, ingress kontrolery itp.). Jak teraz zrobić spójny i w miarę automatyczny sposób wdrażania zmian na różne środowiska (bo możliwości raczej jest kilka :)).
U mnie wygląda to tak:
Helm Charty dla k8s + Dockerfile'a są identyczne dla każdego ze środowisk, przetrzymywane w kontroli wersji wraz z domyślnymi valuesami. Docelowe wartości przetrzymuję w buckecie, do którego ma dostęp CI / CD w trakcie podgrywki.
Każde środowisko jest budowane i wdrażane z osobnych gałęzi, tzn release/dev, release/test, release/staging etc.
Pipeline + storage artefaktów można opisać tak dla każdego z mikroserwisów:
Build:
Deploy:
niektóre artifactory maja wbudowane to w siebie np jfrog.
Ja osobiście trzymam się ludowej mądrości że każdy świeży artefakt trzeba przetestować :v.
@DonStefano: Tylko to mi wygląda na standardowe podejście "push based deployment", a nie GitOpsowe "pull based deployment", gdzie to operator ArgoCD/Flux/cokolwiek innego obserwuje repo i aplikuje zmiany :P
Ale wracając jeszcze do Twojego przypadku. Jak ogarniasz zmiany w komponentach infrastrukturalnych k8s? Tak jak wcześniej wspomniałem, chodzi mi o np. ingress kontroler i service mesh. Masz dla nich oddzielne repo z takimi samymi pipeline'ami jak dla mikroserwisów czy jakoś inaczej?
@some_ONE: infrę mam na GCP opisaną w Terraformie, trzymam w innym repozytorium. Tam mam między innymi provisioning klastra GKE i instalowanie na nim ingress controller'a z użyciem helm_release.