Skip to content
VeloxMedia
Use case

VPS dla samodzielnych runnerów CI/CD

Hostowane minuty CI są mierzone, kolejkowane i wolno się rozgrzewają. VPS VeloxMedia zamienia dowolny system CI w trwały runner, którym zarządzasz: zainstaluj Docker i agenta runnera raz, utrzymuj cache buildów rozgrzany między zadaniami i płać stałą stawkę miesięczną zamiast przekroczeń rozliczanych za minutę.

Każdy serwer jest dostarczany z pełnym dostępem root, pamięcią NVMe SSD, nielimitowanym transferem danych i dedykowanym IPv4. Zarejestruj GitLab Runner, samodzielny runner GitHub Actions, agenta Jenkins, Drone, Woodpecker lub agenta Buildkite, a następnie skieruj swoje pipeline'y na sprzęt, którym zarządzasz. Wdrożenia kończą się w około 60 sekund, a reinstalacja jednym kliknięciem przywraca runner do czystego stanu, gdy tylko środowisko buildu zacznie się rozjeżdżać.

Ponieważ transfer jest nielimitowany, pobieranie obrazów bazowych, instalowanie zależności i wypychanie artefaktów nigdy nie wywołuje opłat za ruch wychodzący. Klastrowa wysoka dostępność utrzymuje runnery online mimo awarii sprzętu, a migracja na żywo bez przestojów przenosi obciążenia podczas konserwacji hosta, więc długie buildy nie są przerywane.

  • Stała cena miesięczna od $5 bez opłat za minutę buildu i bez opłat wstępnych
  • Pamięć NVMe SSD dla szybkiego przywracania zależności i cache'owania warstw Docker
  • Nielimitowany transfer danych dla pobierania obrazów i przesyłania artefaktów
  • Pełny dostęp root do instalacji Docker i dowolnego samodzielnego agenta runnera
  • Wdrożenia w 60 sekund i reinstalacja jednym kliknięciem dla czystych, powtarzalnych runnerów
  • Dedykowany IPv4 do dodawania runnerów na listy dozwolonych w prywatnych rejestrach i celach wdrożeniowych

Dlaczego uruchamiać własne runnery CI/CD na VPS

Hostowane runnery rozliczają się za minutę i ograniczają współbieżność w planach, których nie kontrolujesz. Dedykowany VPS odwraca ten model. Płacisz stałą cenę miesięczną bez opłat za minutę i bez opłat wstępnych, więc ruchliwy pipeline kosztuje tyle samo co spokojny. Runner pozostaje online między zadaniami, co oznacza, że cache zależności, warstwy Docker i sklonowane repozytoria są już na dysku, gdy zaczyna się kolejny build. Ty decydujesz o zestawie narzędzi, współbieżności i tagach runnera, a nic nie jest dławione za poziomem użycia.

Szybsze buildy na NVMe z nielimitowanym transferem

Większość czasu CI spędzana jest na instalowaniu zależności, przywracaniu cache'y i pobieraniu obrazów kontenerów. Pamięć NVMe SSD skraca ten narzut: cache npm, pip, cargo, go mod i Maven przywracają się szybko, cache warstw Docker odczytuje i zapisuje z prędkością NVMe, a checkouty dużych monorepo pozostają szybkie. Nielimitowany transfer danych oznacza, że ciągłe pobieranie obrazów bazowych i wypychanie artefaktów buildu nie dodaje rachunku za przepustowość. Rozproszona, replikowana pamięć NVMe leży pod każdym serwerem, więc dane w cache są chronione przed awarią pojedynczego dysku lub hosta.

Pełny root dla Docker, kontenerów i dowolnego agenta runnera

Otrzymujesz pełny dostęp root lub administratora na każdym serwerze, więc możesz zainstalować Docker, Podman, buildx, zestawy narzędzi językowych i wybranego agenta runnera. Zarejestruj GitLab Runner z executorem Docker lub shell, samodzielny runner GitHub Actions, agenta Jenkins albo agentów Drone, Woodpecker i Buildkite. Wybierz spośród Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, CentOS lub Alpine i wybierz Windows Server, gdy potrzebujesz zbudować cele .NET, MSVC lub inne cele Windows. Przeglądarkowa konsola daje Ci dostęp VNC, SSH i RDP prosto z portalu, gdybyś kiedykolwiek zablokował sobie dostęp w trakcie konfiguracji.

Czyste, powtarzalne runnery, które resetujesz w kilka sekund

Higiena buildu ma znaczenie, gdy zadania współdzielą hosta. Reinstalacja i przebudowa jednym kliknięciem przywracają runner do czystego systemu operacyjnego w około 60 sekund, więc możesz odświeżyć maszynę, która nagromadziła stan. Migawki przechwytują w pełni skonfigurowany wzorcowy runner i pozwalają go przywrócić lub sklonować konfigurację na nowy serwer. Kopie zapasowe i tryb ratunkowy odzyskują hosta, który się nie uruchamia, a monitorowanie podatności oznacza niezałatane pakiety, zanim trafią do buildu. Dedykowany IPv4 wraz z regułami zapory pozwala dodać runner do listy dozwolonych w prywatnym rejestrze, magazynie artefaktów lub docelowym wdrożeniu produkcyjnym, a odwrotny DNS można edytować z panelu.

Dobierz plan do swojego pipeline'u i umieść go blisko kodu

Sześć jednolitych planów skaluje się od lekkich do ciężkich pipeline'ów. Micro (1 vCPU / 2 GB / 20 GB) i Small (2 / 4 / 40) pasują do lintingu i pojedynczych małych buildów. Medium (4 / 8 / 80) to solidny uniwersalny runner kontenerowy. Plus (4 / 12 / 120) dodaje pamięć dla buildów JVM, dużych drzew node_modules i zestawów integracyjnych, podczas gdy Pro (6 / 16 / 160) i Max (8 / 32 / 200) obsługują równoległe zadania matrycowe i duże monorepo. Uruchom większy plan lub dodaj więcej instancji runnera w miarę wzrostu obciążenia. Wdróż w London, Amsterdam, US East (Ohio) lub US West (California), przy czym Warsaw, Montreal i Utah pojawią się wkrótce, więc runner znajduje się blisko Twojego hosta git i celów wdrożeniowych. Ceny zaczynają się od $5 miesięcznie, Amsterdam od $6, z rozliczeniem rocznym dającym dwa miesiące gratis. Każde wdrożenie, reinstalacja i migawka odbywa się w portalu klienta, wspierana bezpieczną hostowaną płatnością kartą i wsparciem 24/7.

VPS dla samodzielnych runnerów CI/CD pytań

Jakie systemy CI/CD mogę uruchamiać na tych runnerach VPS?

Dowolny system CI, który obsługuje samodzielne runnery lub agentów. Popularne wybory to GitLab Runner, samodzielne runnery GitHub Actions, agenci Jenkins oraz agenci Drone, Woodpecker lub Buildkite. Masz pełny root, aby zainstalować agenta, Docker i swój zestaw narzędzi na Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, CentOS, Alpine lub Windows Server.

Jakiej wielkości VPS potrzebuję dla runnera CI/CD?

To zależy od Twoich buildów. Small (2 vCPU / 4 GB) obsługuje pojedynczy lekki pipeline, Medium (4 / 8) to dobry uniwersalny runner kontenerowy, a Plus (4 / 12) pasuje do pamięciożernych buildów JVM lub integracyjnych. Pro (6 / 16) i Max (8 / 32) uruchamiają równoległe zadania matrycowe i duże monorepo. Gdy obciążenie rośnie, przejdź na większy plan lub wdróż więcej instancji runnera.

Jak utrzymać środowiska buildu w czystości między zadaniami?

Uruchamiaj każde zadanie w kontenerze dla izolacji i użyj reinstalacji lub przebudowy jednym kliknięciem, aby zresetować cały runner do czystego systemu operacyjnego w około 60 sekund. Migawki pozwalają zapisać skonfigurowany wzorcowy runner i przywrócić go na żądanie, podczas gdy kopie zapasowe i tryb ratunkowy odzyskują hosta, który się nie uruchamia.

Czy pobieranie obrazów i wypychanie artefaktów liczy się do limitu przepustowości?

Nie. Każdy serwer zawiera nielimitowany transfer danych, więc pobieranie obrazów bazowych, przywracanie cache'y i przesyłanie artefaktów buildu nie wiąże się z opłatami za ruch wychodzący za GB. Każdy serwer jest również dostarczany z dedykowanym IPv4, który możesz dodać do listy dozwolonych w prywatnym rejestrze lub zaporze.

Wdróż swój pierwszy serwer w niecałą minutę

Wybierz region, wybierz rozmiar i połącz się przez SSH. Bez opłat wstępnych, anuluj w każdej chwili.