[Gennwat]

Ostatnio zacząłem trochę bardziej na poważnie wkraczać w #devops i mam za zadanko ogarnąć działanie CI/CD w #google cloudzie. Cloud Build jest jedną z wielu usług w GCP i oferuję ona właśnie możliwość CI/CD. Sam schemat CI/CD już całkiem spoko rozumiem (w obrazku wrzucę schemat ze stacka, który całkiem fajnie mi to zobrazował).
I teraz projekt wygląda tak :
Są dwa repo :
1. Repo z master branchem i aplikacją + kubernetes.yaml
2. Repo ENV, która ma dwa branche - candidate i prod

Wszystko zrobiłem tak jak jest w dokumentacji GCP i wszystko fajnie hula, a same kroki budowy wyglądają w taki sposób :

1. Developer #!$%@? zmiany na master brancha na repo nr 1.
2. Trigger A na Cloud Build po wykryciu zmian na masterze :
- uruchamia testy,
- następnie buduje obraz,
- #!$%@? go do registry,
- klonuje 2. Repo ENV, przełącza się na candidate brancha i pcha tam kubernetes.yaml z pierwszego brancha
3. Po wykonaniu tych kroków uruchamia się Trigger B
- wali deploy (apply -f kubernetes.yaml) wcześniej przepchniętego yamla k8s
- drugim i ostatnim krokiem to przekopiowanie zdeployowanego yamla k8s na brancha produkcyjnego w drugim repo
4. Apka została zdeployowana i śmiga na cloudowym kubernetesie.
I w sumie jaram się, że to wszystko fajnie bangla, bo całkiem "zwinnie" mi to poszło, jak na pierwszą, "praktyczną" styczność z CI/CD.
Teraz mam parę pytań, na które zapewne devops25k będzie znał odpowiedź.
Czy w #jenkins stosuje się podobny przebieg deployu? Jak bardzo daleko od CI/CD z prawdziwego zdarzenia jest mój deploy? Jak dobrze rozumiem, to końcówka drugiego triggera i w ogóle drugi trigger + REPO ENV z dwoma branchami, mają za zadanie uporządkować działające od nie działających yamli, tak aby te yamle, które działają na produkcji były trzymane w prod branch?
Najbardziej mnie ciekawi, co jeśli mam kilka yamli? I czyim obowiązkiem jest napisać działającego yamla? Devopsa czy programisty? Załóżmy w aplikacji definiuje wartość A która musi się również znaleźć w argumencie w kubernetes.yaml, trzeba ją przepisać ręcznie czy da się jakoś to zdefiniować?

Tyle pytań a brak odpowiedzi xD domyślam się, że na wykopie nikomu się nie będzie chciało na to odpowiadać, więc jak rzeczywiście nie będzie odpowiedzi to walne ten post na sysop/devops polska, ale ten pewnie znajdą się tacy przejadacze, którzy mnie mocno pocisną i podbiją sobie ego przyokazji xd

#devops #docker #kubernetes #informatyka #cloud w sumie ktoś z #programowanie #programista15k może będzie wiedział.

[Gennwat]

@Gennwat:

[devopsiarz]

@Gennwat: Developer #!$%@? zmiany na master brancha na repo nr 1. - zazwyczaj to zła praktyka, by jakiś dev robił sobie pusha na mastera. Taki trigger winien być przy otwieraniu MR/PR do mastera i jeżeli przejdą testy wszelkiego rodzaju + będzie approval od 1 osoby, wtedy dopiero można zrobić merge do mastera z brancha tego developera.

[4n000n]

@Gennwat: Zalezy co preferujesz, ja lubie simplicity i taki galimatias ze sprcjalnym repo z yamlami smierdzi.
Jak dziala to dziala i w locie generuj uamle albo uzyj helma

[MikelThief]

Developer #!$%@? zmiany na master brancha na repo nr 1

@devopsiarz: pierwsze o czym pomyślałem i się nie zawiodłem ( ͡° ͜ʖ ͡°)

[Gennwat]

@devopsiarz: @MikelThief: okej, czyli pierwszy krok do zmiany.
a następne kroki są okej? jak się ma to do jenkinsa

[ddzwon]

@Gennwat: Podasz mi proszę info skąd zadanka/wiedzę bierzesz? Też mnie to czeka, lecz na razie Kubernetesa nadrabiam.

[Gennwat]

@ddzwon: https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build?authuser=1#about_this_tutorial