Generator plików devopsowych
Usage
Set up generator
npm -g install yo
npm -g install @bitnoi.se/generator-devops
Available Generators
- fe: any type of frontend app that create their build with
yarn build
and store the build files in thepublic
catalogue
Generate devops configuration
// Go to your project catalogue
yo @bitnoi.se/devops:<generator>
// for example
yo @bitnoi.se/devops:fe
Overview
Technologia
- Cloud: AWS EKS (kubernetes v1.20
- Command line tool: aws-cli 2.7.9, eksctl v0.102
- Orkiestrator: Kubernetes v1.20
- Command line tool: kubectl v1.20
- testy lokalne można oprzeć o narzędzie minikube v1.18
- Deployment CI/CD
- Bitbucket pipelines
- Tworzenie szablonów
- aplikacja node.js: btn_devops
- wykorzystanie generatora szablonów: yoaman-generator
Idea
- każda aplikacja posiada pewien powtarzający się schemat działania, np.
- FE + Api na next.js + Postgress
- FE + Koa + MySQL
- na poziomie infrastruktury każdy element jesteśmy w stanie opakować w uniwersalny kontener dockerowy:
- FE w HTTP Serwer nginx
- API jako uruchomiony proces node.js
- MySQL/Postgress/itd jako kontener bazodanowy z volumenem
- znając typy kontenerów tworzymy szablony Kubernetesm, które będą opakowywały określone aplikacje
- rozpoczynając projekt generujemy pliki konfiguracyjne za pomocą wizarda, które dołączamy do projektu
- pliki można dostosować pod siebie, jeżeli wymagane są jakieś specjalne konfiguracje
- szablon zawiera konfiguracje CI/CD, która aplikuje konfiguracje kubernentes oraz tworzy obrazy dla kontenenerów, które umieszcza w repozytorium na AWS ECR
- release na staging polega na wypchnięciu repozytorium na określony branch
Pre-konfiguracja
- ustawienie clustra AWS EKS (Elastic Kuberenetes Service) na którym będziemy deployować aplikacje stagingowe
- instalacja Ingressa na clustrze, który będzie obsługiwał żądania HTTP oraz przyjmował ruch HTTPS
- konfiguracja kluczy AWS (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION) dla pipelinów CI/CD w Bitbucket
- stworzenie generatora szablonów
- dodanie domeny z wildcardem (
*.btn.fyi
) - każdy projekt dostaje swoją subdomenę automatycznie
Obiekty Kubernetes
Każda aplikacja HTTP (FE/API) składa się kilku obiektów Kubernetes:
- obiekt typu Ingress:
- określaja reguły routowania
- określa domenę
- wskazuje na obiekt typu
Service
- konfiguruje HTTPS dla endpointu
- konfiguruje load balancer (funkcja AWS EKS)
- obiekt typu Service:
- pośrednik pomiędzy Ingressem, a Pod'em
- mapuje port przychodzący z Ingressa na port kontenera w podzie
- wskazuje na konkretny Pod (zbiór kontenerów dockerowych)
- obiekt typu Deployment:
- konfiguruje Pod'y
- Pod zawiera w sobie 1 lub więcej kontenerów dockerowych
- odpowiednik Task Definition z ECS lub plików docker-compose
- określa z jakiego obrazu mają być zbudowane kontenery
- określa ile instancji podów ma być stworzonych (skalowanie), sposób deploymentu (zero downtime, canary, blue-green), itp
- zazwyczaj zawiera kontener z aplikacją i np. nginx, który na niego kieruje
- obiekty typu Config-Map
- aplikowalne konfiguracje, które mogą być użyte w kontenerach, np. pliki konfiguracyjne nginx, listy zmiennych środowiskowych, konfiguracje .ini dla serwisów, itp
- Persitent Volume Claim (PVC) i Persistent Volume (PV)
- PVC deklaruje konfiguracje dla PV
- PV tworzy wolumen danych, których następnie jest montowany do kontenerów
- PV jest przechowywane na stałe (stosujemy np. do trzymania danych z baz danych)
- zależność pomiędzy PVC, a PV jest jak pomiędzy klasą, a instancją klasy
CI/CD
-
wykorzystujemy konfiguracje dla Bitbucket Pipelines
-
pojedynczy pipeline składa się z kilku kroków:
- Konfiguracja - ustawienie zmiennych
- Zbudowanie obrazu dockerowego - każdy serwis powinien sam wiedzieć jak się budować
- Wypchnięcie obrazu na repozytorium AWS ECR (Elastic Container Repository) z odpowiednimi tagami
- Zaaplikowanie obiektów Kubernetes z katalogu
k8s
- Aktualizacja tagu obrazu w deploymencie, co wymusi przeładowanie kontenera (
kubectl set image
)