DevOps dla aplikacji, kontenery i Kubernetes
Zajmujemy się DevOps dla aplikacji, które budujemy i przejmujemy. Każdą aplikację zamykamy w kontenerze Docker, infrastrukturę opisujemy w Terraform lub AWS CDK, a testy i wdrożenia uruchamia automatycznie GitHub Actions. Gdy aplikacja składa się z wielu usług, uruchamiamy ją w klastrze Kubernetes.
Kiedy aplikacja potrzebuje DevOps
-
Wdrożenie nowej wersji to ręczna procedura
Ktoś loguje się na serwer, kopiuje pliki i restartuje usługę. Zastępujemy to pipeline'em, który po zatwierdzeniu zmiany sam buduje, testuje i wdraża aplikację.
-
U programisty działa, na produkcji nie
Różne wersje bibliotek i systemu na komputerach i serwerach powodują błędy trudne do odtworzenia. Kontener Docker zawiera wszystko, czego aplikacja potrzebuje.
-
Nikt nie wie, jak odtworzyć środowisko
Konfiguracja powstawała latami, ręcznie i bez dokumentacji. Opisujemy ją w Terraform, więc środowisko da się odtworzyć i sprawdzić, co się w nim zmieniło.
-
Aplikacja rozrosła się do wielu usług
Kilka usług, kolejki i zadania w tle trudno utrzymać ręcznie. Klaster Kubernetes sam uruchamia, skaluje i restartuje każdą z nich.
Kiedy wybrać Kubernetes, a kiedy prostsze rozwiązanie
Kubernetes daje najwięcej, gdy aplikacja składa się z wielu usług, które trzeba skalować osobno, gdy kilka zespołów wdraża swoje części niezależnie albo gdy ta sama aplikacja ma działać w różnych chmurach. Wtedy jeden sposób uruchamiania i monitorowania wszystkich usług oszczędza czas, a klaster zarządzany przez dostawcę chmury zdejmuje z zespołu utrzymanie jego warstwy sterującej.
Większości aplikacji firmowych wystarcza prostsze rozwiązanie. Pojedynczą aplikację w kontenerze uruchamiamy w usłudze kontenerowej chmury, takiej jak ECS Fargate w AWS, Azure Container Apps albo Cloud Run. Kosztuje to mniej i nie wymaga wiedzy o klastrze. Przy małej aplikacji ze stałym ruchem wystarczy kontener na jednym serwerze z automatycznym wdrożeniem. Rekomendację podajemy razem z szacunkiem kosztu każdego wariantu.
Przykładowy przebieg wdrożenia zmiany
- Programista zatwierdza zmianę w repozytorium, a GitHub Actions uruchamia budowę i testy automatyczne.
- Pipeline sprawdza zależności, buduje obraz Docker i zapisuje go w rejestrze obrazów chmury.
- Nowa wersja trafia do środowiska testowego, gdzie możesz ją sprawdzić.
- Po akceptacji ta sama wersja obrazu trafia do produkcji. Nowe kopie aplikacji startują obok starych i przejmują ruch dopiero wtedy, gdy odpowiadają poprawnie.
- Jeśli alarmy pokażą błąd, wracamy do poprzedniej wersji jednym poleceniem.
Utrzymanie aplikacji po wdrożeniu, czas reakcji na awarie i rozwój w ramach puli godzin opisujemy na stronie utrzymanie i rozwój aplikacji. Przykłady aplikacji działających w kontenerach znajdziesz w opisach Offer Exchange i Service Quotes.
Co robimy
- Przygotowujemy obrazy Docker dla aplikacji Next.js, .NET i Node.js
- Budujemy pipeline CI/CD w GitHub Actions, który testuje i wdraża każdą zmianę
- Opisujemy infrastrukturę w Terraform, AWS CDK lub Bicep
- Uruchamiamy aplikacje w klastrach Kubernetes w chmurze, Amazon EKS, Azure Kubernetes Service i Google Kubernetes Engine
- Przygotowujemy osobne środowiska testowe i produkcyjne z tych samych plików
- Przechowujemy hasła i klucze w menedżerach sekretów chmury zamiast w kodzie
- Konfigurujemy logi, metryki i alarmy dla aplikacji
Dla kogo
- Wdrażasz nowe wersje aplikacji ręcznie i boisz się każdej aktualizacji
- Twoja aplikacja ma kilka usług, kolejek i zadań w tle
- Przejmujesz aplikację po innej firmie i chcesz uporządkować sposób jej wdrażania
- Planujesz przeniesienie aplikacji do kontenerów albo do Kubernetes
Pipeline, który sprawdza każdą zmianę
Każda zmiana w kodzie uruchamia w GitHub Actions ten sam ciąg kroków: budowę, testy automatyczne, kontrolę zależności i budowę obrazu Docker. Wersja, która przejdzie wszystkie kroki, trafia najpierw do środowiska testowego, a po akceptacji do produkcyjnego. Przy nowych stronach Conetso pipeline przed każdym wdrożeniem sprawdza linki, przekierowania, wielkość skryptów i dostępność WCAG 2.2 AA.
- Testy automatyczne przed każdym wdrożeniem
- Ta sama wersja w środowisku testowym i produkcyjnym
- Historia wdrożeń i szybki powrót do poprzedniej wersji
Kubernetes, gdy usług jest wiele
W klastrze Kubernetes każda część aplikacji działa jako osobna usługa z własną liczbą kopii i limitami zasobów. Klaster sam uruchamia nowe kopie przy większym ruchu i restartuje te, które przestały odpowiadać. Korzystamy z klastrów zarządzanych przez dostawcę chmury, czyli Amazon EKS, Azure Kubernetes Service lub Google Kubernetes Engine, a konfigurację usług przechowujemy w repozytorium.
- Klastry zarządzane w AWS, Azure i Google Cloud
- Automatyczne skalowanie i restart usług
- Konfiguracja usług w repozytorium
Infrastruktura jako kod w Terraform
Sieci, bazy danych, kolejki, uprawnienia i alarmy opisujemy w plikach Terraform. Przed każdą zmianą widać plan: co powstanie, co się zmieni i co zostanie usunięte. Tak opisaliśmy infrastrukturę nowych stron Conetso Group w AWS i Cloudflare. W projektach tylko w AWS korzystamy też z AWS CDK, a w Azure z Bicep.
- Plan zmian widoczny przed wdrożeniem
- Te same moduły dla wielu środowisk
- Pełna historia zmian infrastruktury
Jak pracujemy
-
Przegląd wdrożeń
Sprawdzamy, jak aplikacja jest dziś budowana, konfigurowana i wdrażana, oraz które kroki wykonuje się ręcznie.
-
Kontener i pipeline
Zamykamy aplikację w kontenerze Docker i budujemy pipeline w GitHub Actions z testami i wdrożeniem do środowiska testowego.
-
Infrastruktura w kodzie
Opisujemy środowiska w Terraform lub AWS CDK. Testowe i produkcyjne powstają z tych samych plików.
-
Przełączenie produkcji
Wdrażamy aplikację w nowym środowisku, sprawdzamy logi i alarmy, a potem przełączamy domenę bez przerwy w działaniu.
Doświadczenie
- Offer Exchange, Service Quotes i INVENTA Licenses działają w kontenerach Docker za serwerem Nginx.
- Nasz produkt Savanna One instalujemy u klientów w kontenerach Docker albo udostępniamy w chmurze AWS.
- Infrastrukturę nowych stron Conetso Group w AWS i Cloudflare opisaliśmy w Terraform, a wdrożenia uruchamia automatycznie GitHub Actions.
- Kod przechowujemy w GitHub Enterprise z danymi w regionie Unii Europejskiej.
Realizacje
-
Savanna One
Savanna One to nasz własny produkt: system dla zakładów produkcyjnych, który łączy magazyn, produkcję i dokumentację. Pracują na nim producenci żywności.
-
Offer Exchange
Platforma SaaS do zakupów firmowych, która łączy w jednym miejscu zapytania ofertowe, porównanie ofert od handlowców i zamówienia.
-
Service Quotes
Aplikacja dla firmy usługowej z klientami B2B. Obsługuje zlecenia, przydział pracowników, wycenę wykonanej usługi i płatność online.
Najczęstsze pytania
Czy każda aplikacja potrzebuje Kubernetes?
Nie. Dla jednej aplikacji z bazą danych Kubernetes to niepotrzebny koszt i złożoność. Taką aplikację taniej uruchomić w usłudze kontenerowej chmury, na przykład w ECS Fargate, Azure Container Apps albo Cloud Run. Kubernetes polecamy, gdy usług jest kilka lub kilkanaście albo aplikacja ma działać w różnych chmurach.
Czy uporządkujecie wdrożenia aplikacji, której nie budowaliście?
Tak. Zaczynamy od przeglądu kodu, konfiguracji i obecnego sposobu wdrażania. Potem zamykamy aplikację w kontenerze i budujemy pipeline, nie zmieniając jej funkcji. Dopiero gdy wdrożenia działają automatycznie, proponujemy dalsze zmiany.
Czy możemy korzystać z GitLab albo Azure DevOps zamiast GitHub?
Tak. Pipeline budujemy tam, gdzie Twój zespół trzyma kod. Zasady są te same niezależnie od narzędzia, a kroki budowy, testów i wdrożenia zapisujemy w pliku w repozytorium.
Zobacz także
-
Utrzymanie i rozwój aplikacji webowych
W abonamencie dodajemy nowe funkcje, instalujemy poprawki bezpieczeństwa i dbamy o serwer. Czas reakcji określa umowa SLA.
-
Platformy SaaS i MVP dla startupów
Budujemy pierwszą wersję produktu (MVP) i platformy SaaS z kontami użytkowników, subskrypcjami, płatnościami, licencjami i API.