Docker Compose

Zaimportuj plik compose jednorazowo. Nodion utworzy na jego podstawie aplikację, procesy i zarządzane usługi.

Przewodniki wdrożeniowe krok po kroku: Docker Compose.

Ta ścieżka jest eksperymentalna. To nie jest docker compose up. Nodion nie uruchamia Compose na stałe, nie stosuje sieci (networks) i nie odczytuje pliku ponownie przy kolejnych wdrożeniach.

W Applications → New połącz repozytorium Git. Jeśli skan znajdzie plik compose z co najmniej jedną usługą aplikacji, pojawi się opcja Docker Compose. Nie jest zaznaczona domyślnie. Wybierz ją, sprawdź plan, a potem utwórz aplikację.

Który plik

Wybierany jest plik o jednej z tych nazw, położony najbliżej katalogu głównego:

• docker-compose.yml / docker-compose.yaml
• compose.yml / compose.yaml

Plik zawierający tylko bazy danych lub cache (bez usługi aplikacji) jest pomijany. Podobnie plik z błędem parsowania. Plik compose położony głęboko w dużym repozytorium może zostać przeoczony, jeśli skanowanie zostanie ucięte.

Co zostaje utworzone

Jedna aplikacja, a nie osobna aplikacja dla każdej usługi. Dodatkowe usługi stają się dodatkowymi procesami tej aplikacji. Przed utworzeniem kreator pozwala wybrać pakiet i liczbę replik (1-16). deploy.replicas w pliku jest ignorowane.

Tagi obrazów, takie jak postgres:16, nie wybierają wersji zarządzanego silnika. Nodion używa swojej bieżącej wersji domyślnej dla danego silnika. Użytkownicy i hasła bazy danych pochodzą z Nodion, a nie ze zmiennych środowiskowych compose w usłudze bazy danych.

Jeśli wartość zmiennej środowiskowej usługi aplikacji wskazuje inną usługę jako host (postgres://…@db:5432/…, redis://cache:6379), klucz zostaje powiązany z podłączanym zasobem (attach binding) i jest wstrzykiwany przy wdrożeniu. W przeciwnym razie bazy danych typu Postgres są podłączane jako DATABASE_URL, Valkey jako REDIS_URL, a MinIO jako standardowe klucze AWS/S3.

Do aplikacji kopiowane są tylko pozostałe zmienne środowiskowe głównej usługi aplikacji. Klucze, które wyglądają na sekrety, są w formularzu oznaczane jako sekretne.

Wolumeny

Nazwane wolumeny stają się wolumenami (domyślnie 5 GB, do zmiany w kreatorze) i są montowane w odpowiednich procesach. Bind mounty (./data:/data) i anonimowe wolumeny są pomijane.

Jak przebiega późniejszy build

Strategią aplikacji nadal jest Dockerfile lub Buildpacks, zgodnie z tym samym skanem repozytorium. build.context i build.dockerfile z Compose nie są kopiowane do tych ustawień. Na aplikację przypada jeden build z Git. Druga usługa z własnym build: współdzieli ten obraz.

Usługa, która ma tylko image: (i nie jest zmapowaną bazą danych), zachowuje ten obraz i działa jako proces. Główna usługa z build: dostaje nazwę web.

Pierwsze wdrożenie czeka, aż podłączone bazy danych i buckety będą gotowe. Po utworzeniu procesy, zmienne środowiskowe i zasoby zmieniasz w dashboardzie. Edycja pliku compose w Git nie aktualizuje planu.

Co jest ignorowane

• Sieci (networks), profile i healthchecki Compose
• depends_on jako kolejność uruchamiania (pomocniczy kontener, który tylko czeka, jest pomijany)
• Bind mounty
• Osobne buildy usług poza jednym obrazem aplikacji

Jeśli zarządzany silnik lub magazyn obiektowy nie jest dostępny w danym regionie, zasób jest pomijany, a aplikacja nadal zostaje utworzona.