Dotychczas wszystkie nasze aplikacje, znajdowały swój produkcyjny finał na serwerze dedykowanym z oferty OVH lub na świetnej usłudze mikr.us stworzonej przez znanego w branży Jakuba Mrugalskiego.
To rozwiązanie miało jeden niezaprzeczalny plus — byliśmy „self-hosted”, bez zaprzątania sobie głowy niejasnymi cennikami oraz estymacjami kosztów. Niestety to rozwiązanie implikowało wiele wad. Przede wszystkim musieliśmy sami dbać o bezpieczeństwo sprzętu, aktualizację systemu na serwerze oraz reguły na firewallu. Co więcej, uciążliwe również stało się przekazywanie wiedzy w obrębie zespołu o tym, jak administrować systemem oraz jak zbudowania jest infrastruktura.
Podjęliśmy decyzję, przechodzimy w chmurę! Zaczęło się żmudne poszukiwanie odpowiedniego rozwiązania dla nas. Po przejrzeniu ofert gigantów, na placu boju zostało Fly.io.
Fly.io jest amerykańskim dostawcą rozwiązań chmurowych scentralizowanym na doświadczenie dla Developera. Nie uświadczymy tu skomplikowanych usług o nieznanych nazwach czy też niejasnych cenników.
Dotychczas nasz proces deploymentu opierał się na kontenerach dockerowych, które budowaliśmy poprzez Github Actions. Docelowo nasze środowiska reprezentowaliśmy przez odpowiednie pliki docker-compose. Niestety to podejście okazało się niemożliwe do implementacji w przypadku Fly. Zaczęliśmy obmyślać plan jak przenieść nasze aplikacje.
Podzieliliśmy nasze pliki docker-compose na poszczególne aplikacje w oddzielnych repozytoriach. Następnie każda z aplikacji zgodnie z dokumentacją otrzymała dedykowany plik fly.toml, w którym definiujemy nazwę aplikacji, reguły watchdoga, oraz powiązane usługi.
app = "backend"
[[services]]
internal_port = 5000
protocol = "tcp"
[services.concurrency]
hard_limit = 25
soft_limit = 20
[[services.ports]]
handlers = ["http"]
port = "80"
[[services.ports]]
handlers = ["tls", "http"]
port = "443"
[[services.tcp_checks]]
interval = 10000
timeout = 2000
[mounts]
source="files_volume"
destination="/files"
Kolejnym krokiem była modyfikacja pipeline w Github Actions by następował deployment.
Przykładowy Github flow:
name: Fly Deploy
on:
push:
branches:
- main
env:
FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
jobs:
deploy:
name: Deploy app
runs-on: self-hosted
steps:
- uses: actions/checkout@v3
- uses: superfly/flyctl-actions/setup-flyctl@master
- run: flyctl deploy --remote-only
I to wszystko!
Na prawdę, tyle i aż tyle :) Fly za nas zadba, by znaleźć Dockerfile , zbudować obraz, a następnie uruchomić ją na swap slocie. Proste, prawda?
Kolejny aspekt, w którym zakochaliśmy się na Fly. Od razu po deploymencie aplikacji otrzymujemy dostęp do Grafany, w której możemy podejrzeć podstawowe metryki takie jak czas odpowiedzi czy ruch sieciowy. Dodatkowo mamy możliwość wypychania własnych metryk poprzez Prometheusa.
Interfejs dostępny przez przeglądarkę dostarcza ascetycznych wrażeń — za wiele z niego nie zrobimy. Pazurki dopiero zobaczymy, gdy zbadamy interfejs konsolowy - flyctl.
Dzięki niemu odbywa się interakcja z chmurą, możemy między innymi zrestartować aplikację czy przeskalować ją w górę lub w dół. Jednak to co kupiło nasze serce była możliwość przekierowania dowolnego portu naszej aplikacji na komputer lokalny, praktycznie tak samo, jak w dockerze.
Linia komend pozwoli nam również zanurzyć się w kontenerze poprzez SSH lub podejrzeć logi za pomocą komendy flyctl logs.
Również otrzymujemy bezpłatnie usługę przetrzymywania sekretów. Nie jest ona tak rozbudowana, jak chociażby Azure Vault, lecz spełnia swoje zadanie. Sekrety wstrzykiwane są do kontenera aplikacji w formie zmiennych środowiskowych, których można użyć w naszej aplikacji.
Zdecydowany Gamechanger!
Wszystkie nasze projekty korzystające z relacyjnej bazy danych mają pod maską Postgresa.
I tutaj również Fly.io wychodzi nam naprzeciw, udostępniając klaster PostgreSQL, którym możemy zarządzać w dowolny sposób. Między innymi możemy dynamicznie skalować ilość zasobów, jak i ilość węzłów. Dodatkowo mamy możliwość uruchomienia TimescaleDB.
Zdecydowanie tak! Mimo początkowych trudności związanych ze zmianą architektury osiągnęliśmy skalowalne i stabilne środowisko, nie martwiąc się o infrastrukturę oraz koszta (które są stosunkowo niskie jak na rozwiązanie chmurowe). Oczywiście w tym słoiku miodu znajdzie się łyżka dziegciu. Fly.io nie jest rozwiązaniem, które grzeszy dobrym wsparciem ze strony producenta. Na szczęście dostajemy w zamian bardzo dobrą dokumentację oraz forum społeczności.
Fly.io jest zdecydowanie dobrą alternatywą, jeżeli szukamy chmury, która nie przytłoczy nas ilością funkcji i skomplikowanym cennikiem, który opiera się na szacunkach. W zamian jednak musimy się przekonać do zarządzania z linii komend i do braku wsparcia technicznego innego niż społeczność.
