Mașini cloud Linux pe Dockup: 7 opțiuni de distribuții

Mașinile cloud Linux oferă un mediu de sistem de operare pe care îl configurezi prin SSH. Sunt utile pentru experimente, software legacy, servicii de sistem personalizate, build hosts și workload-uri al căror ciclu de viață nu este legat în mod natural de un repository Git sau de o imagine de container.

Dockup oferă șapte opțiuni de imagini: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 și Rocky Linux 9.

Când este o mașină Linux mai potrivită decât un serviciu de containere?

Alege o mașină atunci când workload-ul are nevoie de control asupra sistemului de operare, nu doar asupra unui proces de aplicație.

Exemple potrivite:

• Instalarea mai multor daemons de sistem.
• Testarea interactivă a pachetelor sistemului de operare.
• Rularea unei aplicații legacy cu configurare manuală.
• Întreținerea unui build host sau a unui host pentru automatizări.
• Reproducerea mediului Linux al unui client.
• Executarea unor tool-uri long-lived care nu sunt organizate ca un Git deploy.
• Crearea unui workspace SSH temporar și izolat.

Preferă un serviciu Dockup atunci când workload-ul este o aplicație reproductibilă, cu repository, comandă de build, comandă de pornire, health endpoint și nevoi de scaling orizontal.

Cerință	Mașină Linux	Serviciu de containere
Personalizarea sistemului de operare cu privilegii de root	Potrivire foarte bună	Pune modificările în Dockerfile
Administrare prin SSH	Nativă	Interactive shell este PRO
Git push auto-deploy	Configurare manuală	Inclus
Blue-green health gate	Proiectare manuală	Inclus
Imagine reproductibilă	Este necesar un runbook/script	Dockerfile/Nixpacks
Autoscaling	Nu face parte din modelul mașinii	Opțiune Kubernetes
Testare rapidă a distribuțiilor	Potrivire foarte bună	Imaginea de bază poate fi suficientă

O mașină înlocuiește automatizarea deployment-ului cu flexibilitate la nivelul sistemului de operare.

Ce șapte distribuții Linux sunt disponibile?

Interoghează lista actuală de imagini:

dockup box images --json

Imagine	Ecosistem de pachete	Motiv obișnuit pentru alegere
ubuntu-22.04	APT	Compatibilitate pe termen lung
ubuntu-24.04	APT	Bază Ubuntu LTS mai nouă
debian-12	APT	Server general cu schimbări conservatoare
alpine-3.20	apk	Mediu de dimensiuni mici, bazat pe musl
fedora-40	DNF	Tooling Linux mai nou
almalinux-9	DNF	Compatibilitate cu Enterprise Linux
rockylinux-9	DNF	Compatibilitate cu Enterprise Linux

Alege distribuția în funcție de mediul acceptat de furnizorul software. Alpine folosește musl, nu glibc, ceea ce poate afecta binarele native precompilate. Variantele Enterprise Linux sunt utile când software-ul se bazează pe acel ecosistem de pachete.

Notează exact image slug-ul. „Ubuntu” nu este suficient, deoarece versiunile pachetelor și perioadele de suport diferă între 22.04 și 24.04.

Cum creezi o mașină cloud Linux?

Provisionează imaginea cu un nume, memorie și CPU:

dockup box create \
  --project production \
  --image ubuntu-24.04 \
  --name build-host \
  --memory 2048 \
  --cpu 1 \
  --json

Acest exemplu solicită 2.048 MB de RAM și 1 vCPU. Începe cu cerințe măsurate și ajustează pe baza workload-ului observat. Consumul de CPU, RAM și disk este dedus din balanța planului, pe baza unei măsurători realizate minut cu minut.

Planul Free costă 0 $ pe lună și include un credit inițial de 10 $, un workspace, trei baze de date și trei deployment-uri. Planurile plătite permit un număr nelimitat de resurse, însă compute-ul consumă în continuare balanța inclusă. Planul Pro recomandat costă 20 $ pe lună și include un credit de utilizare de 20 $.

Mașina creată devine o resursă a proiectului, cu o țintă stabilă precum production/build-host. Păstrează această țintă în runbook.

Cum obții și protejezi accesul SSH?

Solicită detaliile de conectare:

dockup box ssh production/build-host --json

Răspunsul include host-ul, portul, utilizatorul și parola. Tratează parola ca pe o informație sensibilă. Stocheaz-o într-un password manager aprobat, nu o afișa într-un răspuns al agentului și rotește sau înlocuiește accesul conform politicii organizației.

Înainte de conectare:

1. Verifică proiectul și box slug-ul.
2. Confirmă că operatorul este autorizat.
3. Notează scopul sesiunii.
4. Evită copierea secretelor de producție pe o mașină de unică folosință.
5. Păstrează istoricul comenzilor și log-urile fără credențiale.
6. Închide căile de acces și sesiunile neutilizate.

Accesul SSH oferă puteri extinse în interiorul mașinii. Un coding agent care deține credențiala ar putea instala pachete, modifica servicii, expune porturi sau șterge fișiere. Folosește accesul agentului numai pentru o sarcină analizată și limitată și păstrează o evidență de audit în afara shell-ului.

Articolul Măsuri de protecție pentru agenții AI în producție prezintă modelul de autonomie.

Cum ar trebui să pornească un workload SSH pe o mașină Linux?

După obținerea accesului SSH, configurează pornirea proceselor folosind tool-urile de sistem de operare acceptate de distribuție. Ubuntu, Debian, Fedora, AlmaLinux și Rocky Linux folosesc în mod obișnuit systemd; Alpine are propriile convenții pentru gestionarea serviciilor.

Definiția de pornire trebuie să specifice executabilul, directorul de lucru, utilizatorul de runtime, mediul necesar, politica de restart și destinația log-urilor. Păstrează credențialele în afara fișierului unit sau a scriptului de pornire și folosește căi absolute, astfel încât comportamentul să nu depindă de un shell interactiv.

Testează:

• Workload-ul pornește după un reboot fără autentificarea unui operator.
• Mediul necesar este disponibil fără export-uri specifice shell-ului.
• Log-urile au o locație cunoscută.
• Procesul rulează sub utilizatorul dorit.
• Erorile pot fi observate.
• Actualizările nu înlocuiesc în mod necontrolat dependențele.

Pentru un singur proces web cu aceste cerințe, un serviciu de containere bazat pe Git poate oferi deja un ciclu de viață mai potrivit.

Cum operezi și reconstruiești o mașină Linux?

Tratează fiecare comandă manuală ca pe o posibilă configurație divergentă. Documentează configurarea într-un script sau într-un proces de configuration management:

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app

Acest exemplu generic nu este o comandă Dockup; ilustrează cum poți face configurarea mașinii reproductibilă. Fixează sau documentează versiunile pachetelor atunci când workload-ul necesită stabilitate.

Un runbook pentru mașină ar trebui să includă:

• Image slug-ul.
• CPU-ul și memoria solicitate.
• Pachetele și repository-urile instalate.
• Conturile de utilizator și politica SSH.
• Locațiile din filesystem.
• Serviciul de pornire, executabilul și directorul de lucru.
• Serviciile deschise și autentificarea acestora.
• Metoda de backup pentru date.
• Procedura de patching și reboot.
• Pașii pentru rebuild.
• Criteriile de migrare sau retragere.

Nu presupune că filesystem-ul unei mașini are același workflow de snapshot ca volumul unui serviciu Dockup, cu excepția cazului în care acest workflow este configurat și acceptat explicit pentru resursa respectivă. Proiectează backup-urile pentru datele și software-ul care rulează efectiv acolo.

Când ar trebui mutat workload-ul într-un container?

Treci la un serviciu de containere atunci când:

• Configurarea a devenit un script stabil.
• Un singur proces de aplicație este scopul principal.
• Modificările sursei ar trebui să fie livrate din Git.
• Sunt necesare release-uri zero-downtime controlate prin health checks.
• Rollback-ul ar trebui să selecteze un deployment ID anterior.
• Sunt necesare mai multe replica identice.
• Configurația mașinii diferă între operatori.
• Accesul SSH este folosit doar pentru redeploy manual.

Transformă configurarea într-un Dockerfile, definește portul aplicației și health path-ul și efectuează mai întâi un deploy pentru un serviciu preview sau non-production. Compară comportamentul înainte de a opri mașina.

Ghidul Nixpacks vs Dockerfile te ajută să alegi noua metodă de build. Kubernetes vs Docker explică opțiunile de plasare în runtime.

Checklist pentru alegerea unei mașini Linux

O decizie corectă privind mașinile cloud Linux răspunde la următoarele întrebări:

1. Care dintre cele șapte image slug-uri corespunde suportului oferit de furnizor?
2. De ce nu poate workload-ul să folosească un serviciu obișnuit?
3. Cum sunt protejate credențialele SSH?
4. Cum este reprodusă configurarea?
5. Unde se află log-urile și datele persistente?
6. Cum sunt testate patch-urile?
7. Ce proces ar trebui să pornească automat?
8. Ce eveniment declanșează containerizarea sau retragerea?

Folosește referința CLI Dockup pentru comenzile actuale ale mașinilor și lista de imagini. Pentru workload-uri disponibile doar pe Windows, compară Windows VM cu RDP.

Controlează încrederea acordată pachetelor și repository-urilor

O mașină poate instala orice pachet solicitat de operator, astfel încât sursele pachetelor devin parte din limita de securitate. Folosește repository-urile semnate ale distribuției, documentează repository-urile terțe și evită să trimiți direct script-uri de rețea neverificate într-un root shell.

Înregistrează lista pachetelor după configurare și compar-o în timpul operațiunilor de mentenanță. Când un agent propune instalarea unui tool, solicită sursa pachetului, versiunea, scopul și planul de eliminare.

Măsoară dacă mașina mai este justificată

Analizează în fiecare lună frecvența sesiunilor SSH, pașii de deployment manual, cerința de uptime, consumul de resurse și incidentele cauzate de configurația divergentă. O mașină care primește periodic release-uri ale aplicației prin SSH indică faptul că are nevoie de un workflow reproductibil de serviciu.

Verifică utilizarea CPU, RAM și disk a mașinii în app.dockup.ai, împreună cu runbook-ul. Mașinile cloud Linux sunt valoroase atunci când controlul asupra sistemului de operare este cerința principală; operațional, devin costisitoare când ascund doar un deployment de aplicație nedocumentat.

Retrage mașinile temporare în mod controlat

O mașină de testare ar trebui să aibă un proprietar și o dată de expirare încă de la creare. Înainte de retragere, exportă doar datele persistente aprobate, elimină credențialele copiate, păstrează orice script de configurare reutilizabil și confirmă că niciun DNS, job programat sau runbook al echipei nu mai depinde de host.

Astfel previi transformarea unui experiment scurt într-un server permanent fără patch-uri.

Păstrează un responsabil pentru accesul de urgență

Desemnează persoana sau echipa responsabilă atunci când operatorul SSH obișnuit nu este disponibil. Responsabilul de rezervă trebuie să știe unde sunt stocate credențialele și cum să verifice ținta exactă fără să partajeze parolele.

Păstrează justificarea

Documentează de ce mașinile cloud Linux sunt în continuare necesare.

Începe cu un deployment verificabil

Creează o mașină mică, non-production, automatizează configurarea completă pornind de la o imagine curată și decide dinainte ce dovezi ar justifica mutarea workload-ului într-un container.

Începe gratuit pe app.dockup.ai. Planul Free costă 0 $ pe lună, include un credit inițial de 10 $ și oferă suport pentru un workspace, trei baze de date și trei deployment-uri.

Întrebări frecvente

Ce distribuții Linux pot folosi mașinile Dockup?

Dockup acceptă ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 și rockylinux-9.

Cum obțin credențialele SSH pentru o mașină Linux?

Rulează dockup box ssh cu ținta exactă proiect/mașină și --json, apoi stochează în siguranță detaliile de conectare returnate.

Cum ar trebui să pornească software-ul după configurarea SSH?

Configurează pornirea cu managerul de servicii acceptat de distribuția selectată și documentează executabilul, directorul de lucru, utilizatorul de runtime, mediul, politica de restart și log-urile.

Când este un serviciu de containere mai potrivit decât o mașină Linux?

Folosește un serviciu de containere atunci când workload-ul este o singură aplicație reproductibilă, care beneficiază de deployment din Git, health gates, rollback și autoscaling.

Cum sunt tarifate resursele unei mașini Linux?

Consumul de CPU, RAM și disk este măsurat minut cu minut în raport cu balanța planului, așa că monitorizează utilizarea efectivă și evită alocările supradimensionate.