Linux-cloudbokser på Dockup: 7 distribusjonsalternativer

Linux-cloudbokser gir deg et operativsystemmiljø du konfigurerer over SSH. De er nyttige for eksperimenter, eldre programvare, tilpassede systemtjenester, build hosts og arbeidslaster som ikke naturlig er knyttet til et Git-repository eller et container image.

Dockup støtter sju image-alternativer: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 og Rocky Linux 9.

Når er en Linux-boks bedre enn en container service?

Velg en boks når arbeidslasten trenger kontroll over operativsystemet, ikke bare over en applikasjonsprosess.

Eksempler på passende bruksområder:

• Installere flere systemdaemons.
• Teste operativsystempakker interaktivt.
• Kjøre en eldre applikasjon med manuelt oppsett.
• Vedlikeholde en build- eller automasjonsvert.
• Gjenskape en kundes Linux-miljø.
• Kjøre langvarige verktøy som ikke er organisert som en Git-deploy.
• Opprette et midlertidig, isolert SSH-arbeidsområde.

Foretrekk en Dockup-tjeneste når arbeidslasten er en reproduserbar applikasjon med et repository, en build-kommando, en start-kommando, et health-endpoint og behov for horisontal skalering.

Krav	Linux-boks	Container service
Root-lignende tilpasning av operativsystemet	Passer godt	Legg endringene i Dockerfile
SSH-administrasjon	Innebygd	Interactive shell er PRO
Automatisk deploy ved Git push	Må settes opp manuelt	Innebygd
Blue-green health gate	Må utformes manuelt	Innebygd
Reproduserbart image	Krever runbook eller script	Dockerfile/Nixpacks
Autoscaling	Ikke en del av boksmodellen	Kubernetes-alternativ
Rask testing av distribusjoner	Passer godt	Base image kan være tilstrekkelig

En boks bytter ut deployment-automatisering mot fleksibilitet på operativsystemnivå.

Hvilke sju Linux-distribusjoner er tilgjengelige?

Hent den aktuelle image-listen:

dockup box images --json

Image	Package ecosystem	Typisk grunn til å velge det
ubuntu-22.04	APT	Langvarig kompatibilitet
ubuntu-24.04	APT	Nyere Ubuntu LTS-base
debian-12	APT	Konservativ generell server
alpine-3.20	apk	Lite, musl-basert miljø
fedora-40	DNF	Nyere Linux-verktøy
almalinux-9	DNF	Kompatibilitet med Enterprise Linux
rockylinux-9	DNF	Kompatibilitet med Enterprise Linux

Tilpass distribusjonen til leverandørens støttede miljø. Alpine bruker musl i stedet for glibc, noe som kan påvirke forhåndsbygde native binaries. Enterprise Linux-varianter er nyttige når programvaren forventer dette package ecosystemet.

Noter den nøyaktige image-sluggen. «Ubuntu» er ikke tilstrekkelig, fordi pakkeversjoner og supportperioder varierer mellom 22.04 og 24.04.

Hvordan oppretter du en Linux-cloudboks?

Provisioner imaget med navn, minne og CPU:

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

Dette eksempelet ber om 2 048 MB RAM og 1 vCPU. Start med målte krav og juster basert på den observerte arbeidslasten. CPU-, RAM- og diskforbruk trekkes fra planens saldo basert på målinger per minutt.

Free-planen koster $0 per måned og inkluderer $10 i startkreditt, ett workspace, tre databaser og tre deployments. Betalte planer tillater et ubegrenset antall ressurser, men faktisk compute-forbruk bruker fortsatt av den inkluderte saldoen. Den anbefalte Pro-planen koster $20 per måned og inkluderer $20 i brukskreditt.

Den opprettede boksen blir en prosjektressurs med et stabilt mål, for eksempel production/build-host. Ta vare på dette målet i runbooken.

Hvordan henter og beskytter du SSH-tilgangen?

Be om tilkoblingsdetaljer:

dockup box ssh production/build-host --json

Responsen inneholder vert, port, bruker og passord. Behandle passordet som sensitiv informasjon. Lagre det i en godkjent passordmanager, ikke skriv det ut i et agentsvar, og roter eller erstatt tilgangen i henhold til organisasjonens policy.

Før du kobler til:

1. Bekreft prosjektet og boks-sluggen.
2. Bekreft at operatøren har nødvendig autorisasjon.
3. Dokumenter formålet med økten.
4. Unngå å kopiere produksjonshemmeligheter til en boks som skal kastes.
5. Sørg for at kommandohistorikk og logger ikke inneholder credentials.
6. Lukk ubrukte tilgangsveier og økter.

SSH-tilgang gir omfattende kontroll inne i boksen. En coding agent med denne credentialen kan installere pakker, endre tjenester, eksponere porter eller slette filer. Bruk agenttilgang bare for avgrensede oppgaver som er gjennomgått, og oppbevar et audit-spor utenfor shell-et.

Artikkelen AI agent production guardrails beskriver autonomimodellen.

Hvordan bør en SSH-arbeidslast starte på en Linux-boks?

Når du har hentet SSH-tilgangen, konfigurerer du oppstart med operativsystemverktøyene som støttes av distribusjonen. Ubuntu, Debian, Fedora, AlmaLinux og Rocky Linux bruker vanligvis systemd; Alpine har egne konvensjoner for service management.

Oppstartsdefinisjonen bør angi den kjørbare filen, arbeidskatalogen, runtime-brukeren, nødvendige miljøvariabler, restart-policy og loggmål. Oppbevar credentials utenfor unit-filen eller oppstartsskriptet, og bruk absolutte stier slik at oppførselen ikke avhenger av et interaktivt shell.

Test at:

• Arbeidslasten starter etter en omstart uten at en operatør logger inn.
• Nødvendige miljøvariabler er tilgjengelige uten shell-spesifikke exports.
• Logger har en kjent plassering.
• Prosessen kjører under riktig bruker.
• Feil kan observeres.
• Oppdateringer ikke i det stille erstatter dependencies.

For én enkelt webprosess med disse kravene kan en Git-basert container service allerede gi en bedre lifecycle.

Hvordan bør en Linux-boks driftes og bygges på nytt?

Behandle hver manuelle kommando som mulig configuration drift. Dokumenter oppsettet i et script eller en prosess for configuration management:

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

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

Dette generiske eksempelet er ikke en Dockup-kommando; det illustrerer hvordan du gjør boks-konfigurasjonen repeterbar. Pin eller dokumenter pakkeversjoner når arbeidslasten krever stabilitet.

En runbook for boksen bør inneholde:

• Image-slug.
• Tildelt CPU og minne.
• Installerte pakker og repositories.
• Brukerkontoer og SSH-policy.
• Filsystemplasseringer.
• Oppstartstjeneste, kjørbar fil og arbeidskatalog.
• Åpne tjenester og autentiseringen deres.
• Metode for datasikkerhetskopiering.
• Prosedyre for patching og omstart.
• Steg for å bygge boksen på nytt.
• Kriterier for migrering eller avvikling.

Ikke anta at filsystemet på en boks har samme snapshot-workflow som et Dockup service volume, med mindre denne workflown er eksplisitt konfigurert og støttet for ressursen. Utform backupen for dataene og programvaren som faktisk kjører der.

Når bør arbeidslasten flyttes inn i en container?

Gå over til en container service når:

• Oppsettet har blitt et stabilt script.
• Én applikasjonsprosess er hovedformålet.
• Kildekodeendringer bør deployes fra Git.
• Releases uten nedetid med health gates er nødvendig.
• Rollback bør velge en tidligere deployment-ID.
• Det trengs flere identiske replicas.
• Boksen endres ulikt av forskjellige operatører.
• SSH-tilgang bare brukes til manuell redeploy.

Konverter oppsettet til en Dockerfile, definer applikasjonsporten og health path, og deploy først en preview- eller ikke-produksjonstjeneste. Sammenlign oppførselen før du stenger boksen.

Veiledningen Nixpacks vs Dockerfile hjelper deg med å velge den nye build-metoden. Kubernetes vs Docker forklarer alternativene for runtime-plassering.

Sjekkliste for valg av Linux-boks

En pålitelig beslutning om Linux-cloudbokser besvarer disse spørsmålene:

1. Hvilken av de sju image-sluggene samsvarer med leverandørens support?
2. Hvorfor kan arbeidslasten ikke bruke en vanlig tjeneste?
3. Hvordan beskyttes SSH-credentials?
4. Hvordan gjenskapes oppsettet?
5. Hvor finnes logger og persistent data?
6. Hvordan testes patcher?
7. Hvilken prosess skal starte automatisk?
8. Hvilken hendelse utløser containerisering eller avvikling?

Bruk Dockup CLI-referansen for oppdaterte boks-kommandoer og image-listen. For arbeid som bare fungerer på Windows, kan du sammenligne med Windows VM with RDP.

Kontroller tilliten til pakker og repositories

En boks kan installere alle pakker operatøren ber om, så pakkekilder blir en del av sikkerhetsgrensen. Bruk distribusjonens signerte repositories, dokumenter tredjepartsrepositories, og unngå å pipe ikke-gjennomgåtte nettverksskript direkte inn i et root-shell.

Registrer pakkelisten etter oppsettet og sammenlign den under vedlikehold. Når en agent foreslår å installere et verktøy, må du kreve pakkekilde, versjon, formål og plan for fjerning.

Mål om boksen fortsatt er riktig valg

Gå gjennom frekvensen av SSH-økter, manuelle deployment-steg, krav til oppetid, ressursbruk og hendelser med configuration drift hver måned. En boks som jevnlig mottar applikasjonsreleases via SSH, signaliserer at den trenger en reproduserbar service-workflow.

Se CPU-, RAM- og diskforbruket til boksen i app.dockup.ai sammen med runbooken. Linux-cloudbokser er verdifulle når kontroll over operativsystemet er kravet; operasjonelt kostbare blir de når de bare skjuler en udokumentert applikasjonsdeploy.

Avvikle midlertidige bokser på en planlagt måte

En testboks bør ha en eier og en utløpsdato allerede når den opprettes. Før avvikling eksporterer du bare godkjente, varige data, fjerner kopierte credentials, tar vare på eventuelle gjenbrukbare oppsettsskript og bekrefter at ingen DNS-oppføring, planlagte jobb eller team-runbook fortsatt er avhengig av verten.

Dette hindrer at et kort eksperiment blir til en permanent server uten patching.

Ha en ansvarlig for nødtilgang

Utpek personen eller teamet som er ansvarlig når den vanlige SSH-operatøren ikke er tilgjengelig. Backup-eieren bør vite hvor credentials lagres, og hvordan det nøyaktige målet verifiseres uten å dele passord.

Dokumenter begrunnelsen

Dokumenter hvorfor Linux-cloudbokser fortsatt er nødvendige.

Start med en verifiserbar deployment

Opprett en liten boks utenfor produksjon, lag et script for hele oppsettet fra et rent image, og bestem på forhånd hvilken dokumentasjon som skal begrunne at arbeidslasten flyttes inn i en container.

Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre deployments.

Vanlige spørsmål

Hvilke Linux-distribusjoner kan Dockup-bokser bruke?

Dockup støtter ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 og rockylinux-9.

Hvordan får jeg SSH-credentials til en Linux-boks?

Kjør dockup box ssh med det nøyaktige prosjekt-/boksmålet og --json, og lagre deretter de returnerte tilkoblingsdetaljene på en sikker måte.

Hvordan bør programvare starte etter SSH-oppsett?

Konfigurer oppstart med service manageren som støttes av den valgte distribusjonen, og dokumenter kjørbar fil, arbeidskatalog, runtime-bruker, miljøvariabler, restart-policy og logger.

Når er en container service bedre enn en Linux-boks?

Bruk en container service når arbeidslasten er én reproduserbar applikasjon som drar nytte av Git-deployment, health gates, rollback og autoscaling.

Hvordan belastes ressurser på Linux-bokser?

CPU-, RAM- og diskforbruk måles per minutt mot planens saldo. Følg derfor med på faktisk bruk og unngå å tildele mer ressurser enn nødvendig.