Usługi / DevOps i platform engineering
DevOpsProjektujemy i utrzymujemy pipeline, GitOps i klaster pod Waszą aplikację
Projektujemy, wdrażamy i utrzymujemy platformę dostarczania oprogramowania. Zaczynamy od aplikacji: repozytoria, testy, sekrety, środowiska i kto wdraża. Potem stawiamy pipeline w GitLab albo GitHub Actions, Kubernetes i Argo CD. Aplikację budujemy w CI i wdrażamy z Gita, najpierw na staging, potem na produkcję, z dashboardem i dyżurem.
Jak to składa się w całość
Od aplikacji do pipeline, klastra i dyżuru
Najpierw rozumiemy aplikację i sposób, w jaki zespół wdraża. Na tej podstawie składamy CI, Kubernetes, Argo CD i monitoring. GitLab, GitHub Actions i Grafana służą do tej pracy na co dzień.
- Preview i produkcja korzystają z tych samych manifestów, z inną konfiguracją.
- Zmianę w klastrze zapisujemy w Git. Ręczna poprawka na produkcji wraca do repozytorium.
Budujemy pipeline, który testuje i wpuszcza aplikację
W GitLab albo GitHub Actions składamy test, skan, obraz i bramkę do środowiska. Merge przechodzi przez te same kontrole. Preview wstaje na merge request i znika po zamknięciu.
Bramki
Testy, lint, SAST i polityka obrazu. Na main wchodzi tylko to, z czego da się wdrożyć.
Środowiska
Dev, staging i produkcja na tym samym pipeline. Różnica to zatwierdzenie i sekrety.
Tożsamość
Runner, registry i chmura na kontach serwisowych, z krótkim życiem tokenu.
Ślad
Kto odpalił job, jaki commit, jaki artefakt poszedł dalej. To materiał pod audyt zmiany.
Wdrażamy aplikację z Gita, najpierw na staging
Pipeline buduje obraz. Argo CD porównuje klaster z repozytorium i wdraża to, co przeszło przegląd. Najpierw staging, potem produkcja. Rollback to powrót do znanego commita.
Źródło
Manifesty, Helm albo Kustomize w repozytorium. Na produkcję idzie merge.
Widoczność
Health, sync i diff na aplikacji. OutOfSync ma właściciela.
Granice
Projekt per zespół albo per klient. Na produkcji węższy dostęp.
Awaria
Gdy sync zawiedzie, widać zasób i zdarzenie. Playbook na rollback i eskalację.
Stawiamy klaster, na którym zespół wdraża sam
Kubernetes w chmurze albo w serwerowni, z tą samą polityką sieci, limitów i kopii. Node, storage i ingress zapisujemy w kodzie. Zmiana na produkcji idzie przez Git. Dashboard służy do diagnozy.
Powtarzalność
Terraform na klaster, addony i sieć. Drugie środowisko wstaje z tego samego opisu.
Limity
Request, limit, quota i NetworkPolicy. Jeden workload nie zabiera CPU pozostałym.
Utrzymanie
Upgrade, certyfikaty, storage class i PDB. Okno zmiany i plan cofnięcia są w zakresie.
Dostęp
kubectl przez tożsamość firmową. Każde żądanie API ma ślad.
Dyżur widzi aplikację po każdym wdrożeniu
Metryki, logi i ślady schodzą do Grafany. Dashboard per usługa. Alert ma runbook. Po wdrożeniu widać, czy p95 i błąd zostały w budżecie SLO.
Sygnał
RED albo USE per usługa. Logi z kontekstem poda i commita. Tracing tam, gdzie ścieżka jest rozproszona.
Alert
Priorytet, cisza przy oknie utrzymania, eskalacja. Szum ścinamy w pierwszym miesiącu.
Koszt
Retencja i sampling ustawiamy świadomie, żeby logi nie rozjechały rachunku.
Ludzie
Zespół i dyżur widzą ten sam dashboard.
Jak pracujemy
Od aplikacji klienta do produkcji
Zaczynamy od aplikacji: repozytoria, testy, sekrety, środowiska i kto wdraża. Potem stawiamy pipeline, klaster i Argo CD. Aplikację budujemy w CI i wdrażamy z Gita, najpierw na staging, potem na produkcję. Zostajemy przy dashboardach, SLO i dyżurze.
- Aplikacja Sprawdzamy repozytoria, stack, sekrety i kto dziś wdraża. Ustalamy środowiska. Z tego wychodzi zakres: pipeline, klaster, GitOps.
- Pipeline W GitLab albo GitHub Actions składamy test, skan, obraz i bramki. Preview wstaje na merge request.
- Klaster i staging Stawiamy Kubernetes, limity i Argo CD. Staging ma ten sam kształt co produkcja, tylko mniejszy.
- Produkcja i dyżur Argo CD wdraża to, co przeszło przegląd. Po starcie dashboard, SLO, alert i przegląd dryfu.
Rozmowa
Omówimy aplikację, pipeline i wdrożenia
Na tej podstawie przygotujemy zakres: CI, klaster, GitOps i dyżur.
Skontaktuj się