Wdróż Docker Compose na Nodion

Wdróż Docker Compose krok po kroku

1. Sprawdź plik Compose Nodion odczytuje docker-compose.yml, docker-compose.yaml, compose.yml lub compose.yaml i bierze plik położony najbliżej katalogu głównego repozytorium. Oprócz baz danych i cache potrzebna jest co najmniej jedna usługa aplikacji; plik zawierający tylko bazy danych i cache jest ignorowany. docker-compose.yml

   services:
     web:
       build: .
       environment:
         DATABASE_URL: postgres://app:app@db:5432/app
         REDIS_URL: redis://cache:6379
     db:
       image: postgres:17
     cache:
       image: valkey/valkey:8

2. Wybierz Docker Compose przy tworzeniu aplikacji Utwórz aplikację ze swojego repozytorium w regionie EU Central. Gdy skanowanie znajdzie odpowiedni plik Compose, pojawi się opcja Docker Compose; nigdy nie jest zaznaczona domyślnie. Wybierz ją i przejrzyj plan: przed utworzeniem aplikacji możesz jeszcze wybrać rozmiar i liczbę instancji dla każdego procesu oraz zmienić rozmiary wolumenów.
3. Zobacz, co staje się usługą zarządzaną Nodion kieruje się nazwą obrazu: z postgres i postgis powstaje Managed PostgreSQL, z pgvector pgvector, z redis i valkey Valkey, z mysql i mariadb MySQL, z clickhouse ClickHouse, a z minio bucket. Każda inna usługa uruchamia swój obraz jako proces tej jednej aplikacji. Tag obrazu nie decyduje o wersji bazy danych, a użytkowników i hasła nadaje Nodion. Managed PostgreSQL nie ma rozszerzenia PostGIS, więc aplikacja, która potrzebuje PostGIS, po imporcie traci funkcje przestrzenne; taką bazę danych pozostaw poza plikiem Compose.
4. Sprawdź zmienne połączenia Zmienna usługi aplikacji, która wskazuje inną usługę po nazwie, jak @db:5432 powyżej, jest traktowana jako podłączenie: Nodion przy wdrożeniu wstawia rzeczywisty adres. W przeciwnym razie bazy danych trafiają do aplikacji jako DATABASE_URL, a Valkey jako REDIS_URL. Z pozostałych zmiennych kopiowane są tylko te z głównej usługi aplikacji, a wartości wyglądające na sekrety są oznaczane jako sekrety.
5. Od tej pory zarządzaj aplikacją w dashboardzie Pierwsze wdrożenie czeka, aż bazy danych będą gotowe. Potem plik Compose nie jest już odczytywany: przy każdym pushu Nodion buduje aplikację za pomocą strategii Dockerfile lub Buildpacks wykrytej w tym samym repozytorium, a procesy, zmienne i rozmiary zmieniasz w dashboardzie.

Warto wiedzieć

• Eksperymentalny i jednorazowyImport to skrót do pierwszej konfiguracji, a nie runtime Compose. Jeśli nie da się jednoznacznie przełożyć Twojego pliku, zbuduj tę samą konfigurację ręcznie: jedna aplikacja, baza danych podłączona w zakładce Environment i dodatkowe procesy w zakładce Processes.
• Co Nodion ignorujeSieci, profile, healthchecki Compose, depends_on jako kolejność startu, deploy.replicas, bind mounty i anonimowe wolumeny. Druga usługa z własnym build: współdzieli jeden obraz aplikacji.
• WolumenyNazwane wolumeny stają się wolumenami Nodion (domyślnie 5 GB, rozmiar można zmienić w planie) i są montowane w procesach, które z nich korzystają.

Czym Nodion zajmuje się za Ciebie

• Wdrożenia bez przestojów Wypchnij zmiany do swojej gałęzi, a Nodion zbuduje nowy release. Ruch przełącza się, gdy nowe instancje przejdą health check; nieudany release nie wpływa na działającą wersję. Aplikacje z lokalnym wolumenem są natomiast uruchamiane ponownie, bo dysk należy do jednej instancji.
• Bazy danych obok aplikacji Zarządzane PostgreSQL, pgvector, MySQL, Valkey i ClickHouse w tym samym regionie. Podłączone bazy danych trafiają do aplikacji jako DATABASE_URL, REDIS_URL lub CLICKHOUSE_URL.
• Środowiska podglądu dla pull requestów Włącz środowiska podglądu, a każdy pull request z Twojego repozytorium dostanie własną aplikację z własnym adresem URL i nowymi, pustymi bazami danych, tworzoną automatycznie lub ręcznie. Forki i pull requesty od botów są pomijane.
• Workery, zadania cron i skalowanie Uruchamiaj workery jako dodatkowe procesy tej samej aplikacji, planuj zadania w zakładce Cron i skaluj każdy proces do 16 instancji.
• Etap release W przypadku buildpacków linia release: w Procfile uruchamia się przy każdym nowym buildzie. Aplikacje z Dockerfile, a także ponowne wdrożenia i rollbacki do wcześniejszego obrazu, korzystają z polecenia release ustawionego w samej aplikacji, które ma też pierwszeństwo przed linią z Procfile. W przypadku stron statycznych krok release działa w obrazie zawierającym tylko zbudowane pliki.
• Logi i metryki W dashboardzie znajdziesz logi z builda, release'u i działania aplikacji oraz metryki CPU, pamięci, dysku i sieci dla każdej instancji.
• Domeny i HTTPS Domyślna nazwa hosta z HTTPS od pierwszego wdrożenia; Twoje własne domeny automatycznie dostają certyfikaty.

Warto przeczytać

• Dockerfile vs buildpacki: co wybrać dla aplikacji? Oba podejścia zamieniają Twój kod w obraz kontenera. Różni je to, kto pisze kroki builda, a od tego zależą kontrola, utrzymanie i aktualizacje bezpieczeństwa.
• Alternatywy dla Railway w Europie: porównanie 5 opcji Kontenery i bazy danych rozliczane według zużycia, z firmą lub regionem w UE: pięć alternatyw dla Railway w porównaniu rozliczeń, baz danych i lokalizacji.

Docker Compose na Nodion: pytania i odpowiedzi