Od repozytorium Git do produkcji: przewodnik wdrażania w Dockup

Przeniesienie repozytorium Git do produkcji wymaga czegoś więcej niż podłączenia zdalnego repozytorium i naciśnięcia przycisku wdrażania. Platforma musi znać docelową usługę, branch, metodę buildowania, komendę startową, port nasłuchiwania, środowisko, warunek health checku oraz procedurę odzyskiwania. Dockup pozwala jawnie skonfigurować te elementy, obsługując zarówno automatyczne buildy Nixpacks, jak i pliki Dockerfile zarządzane w repozytorium.

Ten poradnik zaczyna się od repozytorium, które nigdy wcześniej nie było wdrażane, a kończy na zweryfikowanym URL-u, historii wdrożeń, logach i przetestowanej komendzie rollbacku.

Co należy sprawdzić przed pierwszym wdrożeniem produkcyjnym?

Upewnij się, że repozytorium można wdrożyć bez nieudokumentowanego stanu lokalnego. Czysty clone powinien zawierać wszystko, co jest potrzebne do zainstalowania zależności i uruchomienia aplikacji, z wyjątkiem sekretów.

Skorzystaj z tej checklisty:

Element	Oczekiwany rezultat
Domyślny branch	Istnieje branch przeznaczony do produkcji
Lockfile zależności	Jest zapisany w repozytorium, aby zapewnić powtarzalność instalacji
Proces startowy	Nasłuchuje na skonfigurowanym porcie i 0.0.0.0
Endpoint health checku	Zwraca sukces bez zewnętrznych efektów ubocznych
Migracje bazy danych	Mają jasno określony, bezpieczny plan wykonania
Sekrety	Są przechowywane poza Git
Pliki trwałe	Korzystają z volume, a nie z systemu plików kontenera
Rollback	Poprzednie wdrożenie można uruchomić ponownie

Zainstaluj CLI i uwierzytelnij się:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Przed utworzeniem czegokolwiek wyświetl istniejące usługi:

dockup services --json

Zapobiega to tworzeniu zduplikowanych zasobów i potwierdza dokładną konwencję workspace oraz targetu.

Jak Dockup create obsługuje wdrażanie z Git?

Zwykle pierwsze wdrożenie wykonuje się za pomocą komendy, która tworzy usługę, wdraża ją, czeka na rezultat i łączy z bieżącym katalogiem:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Utworzony target to production/api. Link .dockup pozwala późniejszym komendom rozpoznać tę usługę podczas uruchamiania ich wewnątrz repozytorium, ale dokumentacja produkcyjna nadal powinna zawierać pełny target.

Jeśli próba provisioningu została przerwana, wyświetl usługi i sprawdź dokładny target przed ponownym uruchomieniem tworzenia:

dockup services --json

Jeśli production/api już istnieje, kontynuuj, odczytując jego status i historię wdrożeń. Dzięki temu nie zamienisz niepewnego wyniku sieciowego w zduplikowaną usługę. Dane uwierzytelniające do repozytorium przechowuj poza kontrolą wersji i wyjściem komend.

Jak Dockup wybiera Nixpacks lub Dockerfile?

Jeśli repozytorium zawiera plik Dockerfile, Dockup go używa. W przeciwnym razie Nixpacks wykrywa aplikację i automatycznie ją builda. Dzięki tej kolejności jawna definicja kontenera w repozytorium ma pierwszeństwo.

Nixpacks to dobry pierwszy wybór, gdy aplikacja korzysta z typowych konwencji danego ekosystemu i nie wymaga dostosowania na poziomie systemu operacyjnego. Dockerfile przydaje się, gdy potrzebujesz konkretnego obrazu bazowego, pakietów systemowych, multi-stage builda, niestandardowego użytkownika runtime albo dokładnie określonych granic kopiowania plików.

Nie musisz dodawać pustego Dockerfile tylko po to, by aplikacja „wyglądała na gotową do produkcji”. Niepoprawny Dockerfile może zapewniać mniejszą powtarzalność niż konwencjonalny automatyczny build. Skorzystaj z procesu decyzyjnego opisanego w Nixpacks vs Dockerfile.

Po utworzeniu usługi sprawdź jej konfigurację:

dockup info production/api --json

Odpowiedź zawiera URL repozytorium, branch, typ wdrożenia, port, ustawienia builda i startu, klucze środowiskowe, domeny niestandardowe oraz dane najnowszego wdrożenia.

Jeśli wykryte komendy wymagają nadpisania, użyj udokumentowanych ustawień:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Ustawienia zaczną obowiązywać przy następnym wdrożeniu.

Jak skonfigurować środowisko produkcyjne i health check?

Dodaj zwykłe wartości i sekrety osobno:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Wartości sekretów są maskowane podczas wyświetlania środowiska. Można je ustawiać i zastępować, ale zapisana wartość nie jest zwracana.

Zmiany środowiska wymagają ponownego wdrożenia, ponieważ działający proces nie może otrzymać nowego środowiska po fakcie. Pełny cykl życia opisano w artykule zmienne środowiskowe i sekrety.

Skonfiguruj health gate reprezentujący gotowość aplikacji:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup korzysta z blue-green deployment bez przestoju i kieruje ruch do nowego wdrożenia dopiero po pomyślnym przejściu readiness checku. Jeśli ścieżka HTTP nie jest skonfigurowana, health gate może użyć gotowości portu TCP.

Endpoint health checku powinien weryfikować, czy proces aplikacji jest gotowy do obsługi żądań. Unikaj wykonywania w nim destrukcyjnych operacji lub kosztownych testów całego systemu. Głębokie sprawdzanie zależności może powodować fałszywe awarie, gdy opcjonalna usługa działa nieprawidłowo.

Jak wdrożyć, obserwować i zweryfikować produkcję?

Uruchom release i poczekaj na stan końcowy:

dockup deploy production/api --wait --json

Domyślny timeout wynosi 900 sekund. Kod wyjścia 0 oznacza sukces. Wyniki deploy_failed i deploy_timeout mają wartość różną od zera, dzięki czemu skrypty shellowe i systemy CI poprawnie się zatrzymują.

Aby obserwować build w formacie NDJSON:

dockup logs production/api --build -f --json

Strumień kończy się po sukcesie lub niepowodzeniu. Jeśli build zakończy się sukcesem, ale kontener ulegnie awarii, sprawdź logi runtime:

dockup logs production/api --json

Po udanym release zweryfikuj stan platformy i działanie publicznego endpointu:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Probe’y uptime są wykonywane co minutę i raportują średni czas odpowiedzi oraz p95. Skanowanie bezpieczeństwa sprawdza CVE w obrazie i konfigurację. Dodaj smoke test specyficzny dla aplikacji, obejmujący właściwy endpoint biznesowy — gotowość platformy jest konieczna, ale niewystarczająca.

Szczegółową metodę pracy z logami opisano w artykule debugowanie logów builda i runtime.

Jak wprowadzać automatyczne wdrożenia i preview?

Pierwsze wdrożenie produkcyjne wykonaj ręcznie, aby obserwować każdą granicę procesu. Gdy build, health gate i ścieżka rollbacku będą już znane, włącz wdrażanie po pushu:

dockup auto-deploy production/api --on --json

Automatyczne wdrażanie powinno być powiązane z chronionym branchem i polityką code review. Push jest wyzwalaczem produkcyjnym, dlatego uprawnienia do repozytorium stają się uprawnieniami do infrastruktury.

Preview dla pull requestów i branchy zapewniają izolowane URL-e i środowiska:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

W projekcie z prywatną siecią preview dołącza do sieci projektu. Może łączyć się z tą samą produkcyjną bazą danych przez <slug>.internal, ale Dockup automatycznie tworzy dla preview użytkownika bazy danych tylko do odczytu. Preview może odczytywać dane o strukturze zbliżonej do produkcyjnej bez możliwości ich modyfikacji.

Nie eliminuje to obowiązków związanych z prywatnością. Dostęp do preview nadal powinien być ograniczony i audytowany, a dane produkcyjne należy odczytywać wyłącznie tam, gdzie jest to dozwolone.

Jak wykonać rollback nieudanego wdrożenia?

Przed rozpoczęciem odzyskiwania zachowaj dowody. W przypadku błędu builda odczytaj logi builda, a w przypadku awarii — logi runtime. Następnie wyświetl historię wdrożeń:

dockup deployments production/api -n 20 --json

Wybierz identyfikator wdrożenia o znanym statusie i czasie, a następnie uruchom je ponownie:

dockup rollback <deploymentId> production/api --json

Rollback powinien być jawną czynnością wykonywaną w ramach obsługi incydentu. Zapisz identyfikator nieudanego wdrożenia, wybrany identyfikator odzyskiwania, przyczynę oraz plan dalszych działań. Jeśli migracja bazy danych nie jest kompatybilna wstecz, sam rollback aplikacji może nie przywrócić zgodności; projekt migracji musi być częścią planu release.

Przewodnik po wdrożeniach bez przestoju wyjaśnia przełączanie ruchu, a dokumentacja Dockup CLI opisuje wszystkie flagi komend.

Rekord ukończenia pierwszego wdrożenia

Na końcu procesu od repozytorium Git do produkcji zapisz:

• Dokładny target project/service.
• Repozytorium i produkcyjny branch.
• Metodę builda: Nixpacks lub Dockerfile.
• Komendy builda i startu, jeśli zostały nadpisane.
• Port nasłuchiwania i ścieżkę health checku.
• ID wdrożenia i stan końcowy.
• Produkcyjny URL i plan konfiguracji domeny niestandardowej.
• Wyniki weryfikacji uptime i bezpieczeństwa.
• ID wdrożenia używanego do rollbacku lub regułę jego wyboru.

Dzięki temu drugie wdrożenie staje się rutynową operacją, a nie kolejnym etapem odkrywania konfiguracji.

Oddziel stan aplikacji od obrazu kontenera

Zapisywalny system plików wewnątrz kontenera usługi należy traktować jako wymienny. Nowe wdrożenie tworzy nową wersję, a rollback uruchamia starszy obraz ponownie; pliki zapisane wyłącznie w starym kontenerze nie są trwałą strategią przechowywania danych.

Korzystaj z zarządzanych baz danych dla danych relacyjnych, dokumentowych lub cache, a dla plików, które muszą przetrwać kolejne wdrożenia, podłącz volume. Przed pierwszym produkcyjnym release potwierdź ścieżki mountowania. Katalog uploadów w kontenerze, który nigdy nie został zamontowany, może działać poprawnie aż do kolejnego wdrożenia, podczas którego dane zostaną usunięte.

Przed przeniesieniem plików generowanych przez użytkowników zapoznaj się z artykułem trwałe volume i snapshoty. W przypadku danych bazy używaj systemu backupów właściwego dla danej bazy, zamiast traktować snapshot działającego volume jako backup spójny transakcyjnie.

Oszacuj pierwszy miesiąc bez wymyślania stałego kosztu instancji

Dockup mierzy zużycie CPU, RAM-u i dysku co minutę, a następnie odejmuje wykorzystanie od salda planu. Plan Free obejmuje kredyt początkowy w wysokości 10 USD i maksymalnie trzy wdrożenia; rekomendowany plan Pro kosztuje 20 USD miesięcznie i zawiera kredyt na wykorzystanie o wartości 20 USD.

Gdy usługa zacznie obsługiwać rzeczywisty ruch, sprawdź zużycie CPU, RAM-u i dysku w app.dockup.ai. Na podstawie rzeczywistego zużycia na minutę — a nie założonego maksimum — zdecyduj, czy wymaga ono dostosowania dla usługi, bazy danych lub dysku trwałego.

Zweryfikuj poprawne drugie wdrożenie

Po pierwszym release wprowadź niewielką, przejrzaną zmianę i wdróż ją ponownie. Potwierdzi to, że link do repozytorium, założenia dotyczące build cache, health gate, środowisko i historia działają jako stały proces, a nie tylko jednorazowy sukces provisioningu.

Zawsze podawaj jawny target

Zapisz końcowy ciąg project/service.

Zachowaj URL release

Zapisz produkcyjny URL obok ID wdrożenia.

Potwierdź następny wyzwalacz

Zapisz, czy przyszłe release’y będą wykonywane ręcznie, czy będą korzystać z opcjonalnego wdrażania po pushu. Dzięki temu po pierwszym wdrożeniu uprawnienia do repozytorium, ochrona brancha i oczekiwania dotyczące produkcji pozostaną spójne.

Zacznij od wdrożenia, które można zweryfikować

Wybierz niewielkie repozytorium z jasną komendą startową i endpointem health checku, a następnie po pierwszym udanym release zapisz dokładny target i ID rollbacku.

Zacznij bezpłatnie na app.dockup.ai. Plan Free kosztuje 0 USD miesięcznie, obejmuje kredyt początkowy w wysokości 10 USD oraz obsługuje jeden workspace, trzy bazy danych i trzy wdrożenia.

FAQ

Czy Dockup może wdrożyć repozytorium bez pliku Dockerfile?

Tak. Jeśli plik Dockerfile nie istnieje, Dockup używa Nixpacks do automatycznego wykrycia i zbudowania aplikacji.

Co robi dockup create --link?

Zapisuje link .dockup w bieżącym katalogu, dzięki czemu późniejsze komendy mogą rozpoznać powiązany target projektu/usługi.

Dlaczego pierwsze wdrożenie powinno używać --wait?

Komenda pozostaje aktywna do momentu, aż wdrożenie zakończy się sukcesem, niepowodzeniem lub timeoutem, i zwraca kod wyjścia dokładnie odzwierciedlający stan końcowy.

Czy zmiany zmiennych środowiskowych są stosowane natychmiast?

Nie. Zostaną zastosowane w nowym kontenerze przy następnym wdrożeniu, dlatego po zmianie konfiguracji środowiska wdróż usługę ponownie.

Jak Dockup wykonuje rollback aplikacji?

Wyświetl historię wdrożeń, znajdź znany wcześniejszy identyfikator wdrożenia i użyj dockup rollback z tym identyfikatorem oraz dokładnym targetem usługi.