Serwer Crunu na Google Cloud Run

Co Crunu robi na Cloud Run

Crunu działa w chmurze na app.crunu.com, więc na start nie potrzebujesz własnego serwera. Jeśli twoja infrastruktura jest w Google Cloud, serwer Crunu wdraża się na Cloud Run jednym skryptem, trzyma swoje sekrety w Secret Manager i korzysta z Postgresa na Cloud SQL lub Neon.

Na Cloud Run serwer, jak wszędzie, nie może odczytać wartości: baza danych zawiera zaszyfrowane dane, klucze publiczne, podpisane dokumenty i metadane, nigdy klucz, który odszyfrowałby wartość.

Wdrożenie

Potrzebujesz Node.js 24, zalogowanego gcloud, projektu z włączonymi płatnościami, bazy danych Postgres i pliku .env utworzonego przez server-init. Polecenia uruchamia się z katalogu serwera Crunu, w którym są skrypty wdrożeniowe.

node scripts/server-init.mjs --origin https://vault.company.example --database-url env:DATABASE_URL
sh deploy/gcp/deploy.sh --project my-project --region europe-west1 --service vault

Skrypt sprawdza .env, włącza API Cloud Run, Artifact Registry i Secret Manager, buduje obraz linux/amd64 w Artifact Registry, zapisuje sekrety serwera w Secret Manager i tworzy konto usługi, które może odczytać tylko te sekrety. Następnie wdraża usługę.

• Sekrety przypięte do rewizji. Nowa wersja sekretu pojawia się tylko przy zmianie wartości, a usługa odwołuje się do sekretów po numerze wersji, a nie jako latest. Każda rewizja zachowuje wartości, z którymi ją wdrożono, więc przełączenie ruchu z powrotem na starszą rewizję przywraca też jej sekrety.
• Cloud SQL przez gniazdo. Użyj adresu w postaci postgres://user:password@/database?host=/cloudsql/project:region:instance. Skrypt podłącza instancję do usługi i nadaje jej kontu usługi rolę Cloud SQL Client.
• Scalane ustawienia. Zmienne środowiskowe są scalane, więc wartości ustawione ręcznie w usłudze zostają. Zmienne, których nie ma już w .env, są wypisywane i usuwane tylko z --prune.
• Adresy klientów. Domyślnie klienci łączą się z usługą bezpośrednio. Za zewnętrznym load balancerem Google wdróż z --trust-proxy xff:2: usługa przyjmuje wtedy ruch tylko z load balancera, a PUBLIC_ORIGIN musi być adresem load balancera.

Czyszczenie działa tylko przy ruchu

Maszyny z agentem crunu domyślnie sprawdzają serwer co minutę, więc gdy maszyny są online, czyszczenie przy okazji działa mniej więcej co 5 minut.

Stare rewizje

Skrypt wdrożeniowy nie taguje rewizji, więc starsze nie mają własnych adresów. Jeśli tagujesz rewizje ręcznie, usuń te tagi, bo otagowana stara rewizja działa z tą samą bazą danych i sekretami:

gcloud run services update-traffic <service> --region <region> --remove-tags <tag>

Zobacz także

• Własny hosting
• Google Cloud Run w dokumentacji
• Przenoszenie między platformami
• Docker