Linux cloud box su Dockup: 7 distribuzioni disponibili

I Linux cloud box forniscono un ambiente con sistema operativo configurabile tramite SSH. Sono utili per esperimenti, software legacy, servizi di sistema personalizzati, build host e workload il cui ciclo di vita non è naturalmente legato a un repository Git o a un'immagine container.

Dockup supporta sette immagini: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 e Rocky Linux 9.

Quando è preferibile un Linux box a un container service?

Scegli un box quando il workload richiede il controllo del sistema operativo, non soltanto di un processo applicativo.

Esempi appropriati:

• Installare diversi demoni di sistema.
• Testare interattivamente i pacchetti del sistema operativo.
• Eseguire un'applicazione legacy con configurazione manuale.
• Gestire un build host o un host per l'automazione.
• Riprodurre l'ambiente Linux di un cliente.
• Eseguire strumenti di lunga durata non organizzati come un deploy Git.
• Creare un workspace SSH temporaneo e isolato.

Preferisci un servizio Dockup quando il workload è un'applicazione riproducibile con repository, comando di build, comando di avvio, health endpoint ed esigenze di horizontal scaling.

Requisito	Linux box	Container service
Personalizzazione del sistema operativo con privilegi root	Scelta ideale	Inserisci le modifiche nel Dockerfile
Amministrazione tramite SSH	Nativa	Interactive shell disponibile in PRO
Auto-deploy con Git push	Configurazione manuale	Integrato
Health gate blue-green	Progettazione manuale	Integrato
Immagine riproducibile	Servono runbook/script	Dockerfile/Nixpacks
Autoscaling	Non previsto dal modello del box	Opzione Kubernetes
Test rapidi delle distribuzioni	Scelta ideale	Potrebbe bastare la base image

Un box scambia l'automazione del deploy con la flessibilità del sistema operativo.

Quali sette distribuzioni Linux sono disponibili?

Interroga l'elenco aggiornato delle immagini:

dockup box images --json

Immagine	Ecosistema dei pacchetti	Motivo tipico per sceglierla
ubuntu-22.04	APT	Compatibilità a lungo termine
ubuntu-24.04	APT	Base Ubuntu LTS più recente
debian-12	APT	Server general-purpose conservativo
alpine-3.20	apk	Ambiente compatto basato su musl
fedora-40	DNF	Tooling Linux più recente
almalinux-9	DNF	Compatibilità con Enterprise Linux
rockylinux-9	DNF	Compatibilità con Enterprise Linux

Scegli la distribuzione in base all'ambiente supportato dal fornitore del software. Alpine usa musl invece di glibc, e questo può influire sui binary nativi precompilati. Le varianti Enterprise Linux sono utili quando il software si aspetta quel determinato ecosistema di pacchetti.

Annota lo slug esatto dell'immagine. “Ubuntu” non è sufficiente, perché le versioni dei pacchetti e i periodi di supporto differiscono tra 22.04 e 24.04.

Come si crea un Linux cloud box?

Esegui il provisioning dell'immagine specificando nome, memoria e CPU:

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

Questo esempio richiede 2.048 MB di RAM e 1 vCPU. Parti dai requisiti misurati e adatta le risorse in base al workload osservato. L'utilizzo di CPU, RAM e disco viene sottratto dal saldo del piano con misurazione al minuto.

Il piano Free costa $0 al mese e include $10 di credito iniziale, un workspace, tre database e tre deployment. I piani a pagamento consentono un numero illimitato di risorse, ma il compute effettivo continua a consumare il saldo incluso. Il piano Pro consigliato costa $20 al mese e include $20 di credito per l'utilizzo.

Il box creato diventa una risorsa del progetto con un target stabile come production/build-host. Mantieni questo target nel runbook.

Come si recupera e si protegge l'accesso SSH?

Richiedi i dati di connessione:

dockup box ssh production/build-host --json

La risposta include host, porta, utente e password. Tratta la password come un dato sensibile. Conservala in un password manager approvato, non stamparla nella risposta di un agent e ruota o sostituisci l'accesso secondo le policy dell'organizzazione.

Prima di connetterti:

1. Verifica il progetto e lo slug del box.
2. Conferma che l'operatore sia autorizzato.
3. Registra lo scopo della sessione.
4. Evita di copiare secret di produzione su un box usa e getta.
5. Mantieni la cronologia dei comandi e i log privi di credenziali.
6. Chiudi i percorsi di accesso e le sessioni non utilizzati.

L'accesso SSH offre ampi privilegi all'interno del box. Un coding agent in possesso della credenziale potrebbe installare pacchetti, modificare servizi, esporre porte o eliminare file. Concedi l'accesso a un agent solo nell'ambito di un task circoscritto e verificato, conservando un audit record esterno alla shell.

L'articolo AI agent production guardrails descrive il modello di autonomia.

Come dovrebbe avviarsi un workload SSH su un Linux box?

Dopo aver recuperato l'accesso SSH, configura l'avvio dei processi con gli strumenti del sistema operativo supportati dalla distribuzione. Ubuntu, Debian, Fedora, AlmaLinux e Rocky Linux usano comunemente systemd; Alpine adotta le proprie convenzioni per la gestione dei servizi.

La definizione di avvio dovrebbe specificare l'eseguibile, la working directory, l'utente di runtime, l'ambiente richiesto, la restart policy e la destinazione dei log. Mantieni le credenziali fuori dall'unit file o dallo startup script e usa percorsi assoluti, così il comportamento non dipende da una shell interattiva.

Verifica che:

• Il workload si avvii dopo un riavvio senza che un operatore debba effettuare il login.
• L'ambiente richiesto sia disponibile senza export limitati alla shell.
• I log abbiano una posizione nota.
• Il processo venga eseguito con l'utente previsto.
• Gli errori siano rilevabili.
• Gli aggiornamenti non sostituiscano silenziosamente le dipendenze.

Per un singolo processo web con questi requisiti, un container service basato su Git potrebbe già offrire un ciclo di vita migliore.

Come si gestisce e si ricostruisce un Linux box?

Considera ogni comando manuale come una potenziale fonte di configuration drift. Acquisisci la configurazione in uno script o in un processo di configuration management:

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

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

Questo esempio generico non è un comando Dockup; mostra come rendere ripetibile la configurazione del box. Fissa o documenta le versioni dei pacchetti quando il workload richiede stabilità.

Un runbook del box dovrebbe includere:

• Slug dell'immagine.
• CPU e memoria richieste.
• Pacchetti e repository installati.
• Account utente e policy SSH.
• Posizioni nel filesystem.
• Servizio di avvio, eseguibile e working directory.
• Servizi esposti e relativa autenticazione.
• Metodo di backup dei dati.
• Procedura di patching e riavvio.
• Passaggi per la ricostruzione.
• Criteri di migrazione o dismissione.

Non dare per scontato che il filesystem di un box abbia lo stesso processo di snapshot del volume di un servizio Dockup, a meno che tale processo non sia configurato esplicitamente e supportato per la risorsa. Progetta i backup in funzione dei dati e del software effettivamente in esecuzione.

Quando spostare il workload in un container?

Passa a un container service quando:

• La configurazione è diventata uno script stabile.
• Lo scopo principale è eseguire un singolo processo applicativo.
• Le modifiche al codice devono essere deployate da Git.
• Sono necessarie release zero-downtime con health gate.
• Il rollback deve selezionare un deployment ID precedente.
• Sono necessarie diverse repliche identiche.
• Il box presenta differenze tra un operatore e l'altro.
• L'accesso SSH viene usato soltanto per eseguire nuovamente il deploy manualmente.

Trasforma la configurazione in un Dockerfile, definisci la porta dell'applicazione e il percorso di health check, quindi esegui prima il deploy su un servizio preview o non di produzione. Confronta il comportamento prima di arrestare il box.

La guida Nixpacks vs Dockerfile aiuta a scegliere il nuovo metodo di build. Kubernetes vs Docker illustra le opzioni di posizionamento del runtime.

Checklist per scegliere un Linux box

Una decisione affidabile sui Linux cloud box risponde a queste domande:

1. Quale dei sette slug delle immagini corrisponde al supporto del fornitore?
2. Perché il workload non può usare un servizio standard?
3. Come vengono protette le credenziali SSH?
4. Come viene riprodotta la configurazione?
5. Dove si trovano log e dati persistenti?
6. Come vengono testate le patch?
7. Quale processo deve avviarsi automaticamente?
8. Quale evento determina la containerizzazione o la dismissione?

Consulta il riferimento della Dockup CLI per i comandi aggiornati dei box e l'elenco delle immagini. Per i workload disponibili solo su Windows, confronta Windows VM con RDP.

Controllo dell'affidabilità di pacchetti e repository

Un box può installare qualsiasi pacchetto richiesto dall'operatore, quindi le sorgenti dei pacchetti diventano parte del perimetro di sicurezza. Usa i repository firmati della distribuzione, documenta i repository di terze parti ed evita di inoltrare direttamente script di rete non verificati a una root shell.

Registra l'elenco dei pacchetti dopo la configurazione e confrontalo durante la manutenzione. Quando un agent propone di installare uno strumento, richiedi la sorgente del pacchetto, la versione, lo scopo e il piano di rimozione.

Verifica se il box è ancora giustificato

Ogni mese verifica la frequenza delle sessioni SSH, i passaggi di deploy manuale, il requisito di uptime, l'utilizzo delle risorse e gli incidenti dovuti al drift. Un box che riceve regolarmente release applicative tramite SSH indica che avrebbe bisogno di un workflow di servizio riproducibile.

Controlla il consumo di CPU, RAM e disco del box in app.dockup.ai, insieme al runbook. I Linux cloud box sono preziosi quando il controllo del sistema operativo è un requisito; hanno un costo operativo elevato quando si limitano a nascondere un deploy applicativo non documentato.

Dismetti i box temporanei in modo deliberato

Un box di test dovrebbe avere un owner e una data di scadenza già al momento della creazione. Prima della dismissione, esporta solo i dati persistenti approvati, rimuovi le credenziali copiate, conserva gli script di configurazione riutilizzabili e conferma che nessun DNS, job pianificato o runbook del team dipenda ancora dall'host.

In questo modo eviti che un breve esperimento si trasformi in un server permanente non aggiornato.

Mantieni un responsabile per l'accesso di emergenza

Indica la persona o il team responsabile quando l'operatore SSH abituale non è disponibile. Il responsabile di backup dovrebbe sapere dove sono archiviate le credenziali e come verificare il target esatto senza condividere le password.

Conserva la motivazione

Documenta perché i Linux cloud box restano necessari.

Inizia con un deploy verificabile

Crea un box di piccole dimensioni in un ambiente non di produzione, automatizza l'intera configurazione partendo da un'immagine pulita e stabilisci in anticipo quali evidenze giustificherebbero lo spostamento del workload in un container.

Inizia gratuitamente su app.dockup.ai. Il piano Free costa $0 al mese, include $10 di credito iniziale e supporta un workspace, tre database e tre deployment.

FAQ

Quali distribuzioni Linux possono usare i box Dockup?

Dockup supporta ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 e rockylinux-9.

Come ottengo le credenziali SSH per un Linux box?

Esegui dockup box ssh con il target esatto progetto/box e --json, quindi conserva in modo sicuro i dati di connessione restituiti.

Come dovrebbe avviarsi il software dopo la configurazione SSH?

Configura l'avvio con il service manager supportato dalla distribuzione selezionata e documenta eseguibile, working directory, utente di runtime, ambiente, restart policy e log.

Quando è preferibile un container service a un Linux box?

Usa un container service quando il workload è un'unica applicazione riproducibile che beneficia del deploy Git, degli health gate, del rollback e dell'autoscaling.

Come vengono addebitate le risorse dei Linux box?

Il consumo di CPU, RAM e disco viene misurato al minuto rispetto al saldo del piano; monitora quindi l'utilizzo effettivo ed evita allocazioni sovradimensionate.