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 the public 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:

  1. Konfiguracja - ustawienie zmiennych
  2. Zbudowanie obrazu dockerowego - każdy serwis powinien sam wiedzieć jak się budować
  3. Wypchnięcie obrazu na repozytorium AWS ECR (Elastic Container Repository) z odpowiednimi tagami
  4. Zaaplikowanie obiektów Kubernetes z katalogu k8s
  5. Aktualizacja tagu obrazu w deploymencie, co wymusi przeładowanie kontenera (kubectl set image)