Wdróż Ruby on Rails na Nodion

Wdróż Ruby on Rails krok po kroku

1. Zbuduj z wygenerowanego Dockerfile Utwórz aplikację ze swojego repozytorium GitHub, GitLab, Bitbucket lub Gitea w regionie EU Central. Rails 7.1 i nowsze zawierają Dockerfile, więc formularz od razu zaznacza strategię Dockerfile. To droga dla aplikacji z jsbundling, cssbundling lub Vite: build JavaScriptu działa w Twoim Dockerfile, zgodnie z Twoją konfiguracją.
2. Ustaw master key i port W zakładce Environment dodaj RAILS_MASTER_KEY z zawartością config/master.key jako sekret. Dla aplikacji z Dockerfile Nodion nie ustawia PORT: serwer nasłuchuje na porcie procesu web, który formularz uzupełnia na podstawie EXPOSE. Rails 7.1 i 7.2 wystawiają port 3000 dla serwera Puma. Rails 8 wystawia port 80 dla Thrustera, który działa przed serwerem Puma; obraz działa jako użytkownik bez uprawnień roota, więc ustaw HTTP_PORT=8080 i w zakładce Processes podaj 8080 jako port procesu web.
3. Podłącz PostgreSQL Utwórz bazę danych PostgreSQL w tym samym regionie i podłącz ją w zakładce Environment; Rails użyje DATABASE_URL, które otrzyma przy następnym wdrożeniu. Wygenerowany bin/docker-entrypoint uruchamia bin/rails db:prepare przed startem serwera Rails, więc oczekujące migracje wykonują się podczas uruchamiania nowej wersji. Możesz też ustawić ./bin/rails db:migrate jako polecenie release aplikacji (pole API release_command, zobacz przewodnik po Dockerze), które jest wykonywane raz na wdrożenie, przed startem nowej wersji.
4. Użyj /up jako ścieżki health checku Rails 7.1 i nowsze odpowiadają na /up kodem 200, gdy tylko aplikacja się uruchomi; ustaw tę ścieżkę jako ścieżkę health checku w ustawieniach aplikacji. Nodion odpytuje każdą instancję z jej wewnętrznym adresem IP jako Host, więc jeśli ustawiasz config.hosts, wyklucz /up ze sprawdzania hostów (host authorization), bo inaczej release nigdy nie trafi na produkcję. config/environments/production.rb

   config.hosts << "www.example.com"
   config.host_authorization = { exclude: ->(request) { request.path == "/up" } }

5. Albo użyj buildpacków dla aplikacji z importmap Aplikacja z importmap i bez package.json może zamiast tego wybrać Buildpacks w formularzu tworzenia aplikacji. Nodion uruchamia wtedy bundle install bez gemów development i test oraz assets:precompile z RAILS_ENV=production i SECRET_KEY_BASE_DUMMY=1, startuje serwer Puma z config/puma.rb na porcie PORT i ustawia RAILS_SERVE_STATIC_FILES oraz RAILS_LOG_TO_STDOUT. Migracje uruchamiasz z Procfile: Procfile

   release: bin/rails db:migrate

Warto wiedzieć

• Solid Queue i SidekiqPrzy buildpackach dodaj do Procfile worker: bin/jobs (Solid Queue) lub worker: bundle exec sidekiq razem z jawną linią web: bundle exec puma -C config/puma.rb; bez linii web: pierwszy wpis w Procfile inny niż release: staje się domyślnym poleceniem. Następnie dodaj w zakładce Processes proces o nazwie worker bez portu. Przy Dockerfile nadaj temu procesowi zamiast tego polecenie ./bin/jobs lub bundle exec sidekiq. Valkey w tym samym regionie zapewnia Sidekiq zmienną REDIS_URL.
• Dodatkowe bazy danych w Rails 8Aplikacja Rails 8 wygenerowana dla PostgreSQL wymienia w config/database.yml dla produkcji także bazy cache, queue i cable, a DATABASE_URL ustawia tylko główną. Przed pierwszym wdrożeniem skonfiguruj połączenie także dla pozostałych albo usuń te, których Twoja aplikacja nie używa.
• Wersja RubyPrzy Dockerfile wersja Ruby pochodzi z RUBY_VERSION w Dockerfile. Przy buildpackach Nodion odczytuje .ruby-version lub linię ruby w Gemfile i oferuje 3.3, 3.4 (domyślnie) i 4.0.

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ć

• Alternatywy dla Heroku z hostingiem w UE: porównanie 5 opcji Niemiecka platforma i amerykańskie chmury z regionami w UE, porównane pod względem siedziby, regionów i zarządzanych baz danych.
• 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.

Ruby on Rails na Nodion: pytania i odpowiedzi