Valg af Ubuntu-image og kontrol af installationen

Saml kravene før bestilling

Notér understøttede operativsystemer, runtimes, databaseversioner og native udvidelser. Medtag container-images samt backup- og overvågningsagenter. Skeln mellem leverandørens officielle support og en kombination, dit team blot har prøvet.

Ubuntu 24.04 introducerede blandt andet Python 3.12 som standard, PHP 8.3 og PostgreSQL 16. Patchversioner ændres med opdateringer. En applikation til ældre hovedversioner er ikke automatisk kompatibel. Brug LTS-oversigten til vedligeholdelsesperioden, og bekræft udbyderens image og region.

Identificér den installerede platform

Kør disse læsende kontroller på VPS’en, og gem resultatet før installation af mere software:

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

VERSION_ID i /etc/os-release angiver Ubuntu-release. uname -r viser den kørende kerne, som ikke alene bestemmer release eller support. amd64 fra dpkg svarer til x86_64 fra uname; arm64 svarer til aarch64.

En binærfil kun til amd64 skal ikke forventes at virke nativt på arm64. Kontroller en understøttet Arm-version eller en udtrykkeligt valgt alternativ løsning.

Afvent og kontroller provisioneringen

Cloud-init kan oprette konti, nøgler og netværk ved første opstart. Kontroller først, om det findes:

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init is not installed; check the provider provisioning method.'
fi

Hvis værktøjet ikke findes, viser eksemplet en engelsk meddelelse; fravær er ikke i sig selv en fejl. Undersøg, hvordan udbyderen provisionerer imaget. Ved running afventer du afslutningen. Error eller degraded kræver undersøgelse, også når SSH virker.

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

Opstartslogs kan indeholde følsomme værdier. Fjern dem før deling. Kør ikke cloud-init clean og erstat ikke netværksfiler blot for at skjule en fejl. Afsluttet provisionering beviser ikke, at applikation og backup virker.

Se pakkernes kandidater før installation

Opdatér metadata og se kandidater i de konfigurerede pakkekilder:

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

apt update opdaterer indekset uden at installere de nævnte applikationspakker. Installed: (none) betyder, at pakken ikke er installeret. Candidate: (none) betyder, at kilderne ikke tilbyder den. Kontroller navn, arkitektur og Ubuntu-komponenter før tilføjelse af et vilkårligt eksternt arkiv.

Metapakker som php og postgresql vælger en standardimplementering. Se også den versionsspecifikke pakke og applikationens virkelige executable. En databaseklients version beviser ikke versionen på databaseserveren.

Et eksempel med to uafhængige krav

Antag en applikation, der kræver Python 3.10 og en native udvidelse, som kun leveres til amd64. Det er et tænkt eksempel. Et standardimage med Ubuntu 24.04 arm64 opfylder hverken kravet om standard-Python eller arkitektur.

Skift til amd64 løser arkitekturen, men ændrer ikke Python-versionen. Et virtuelt miljø bruger den interpreter, der oprettede det; det omdanner ikke Python 3.12 til 3.10. Erstat ikke Ubuntus system-Python for at tilpasse applikationen.

Overvej en applikationsopgradering eller en separat vedligeholdt runtime/container med tydelig supportplan. Et ældre Ubuntu har sin egen resterende vedligeholdelsesperiode. Test udvidelsens funktion, en databaseoperation, et baggrundsjob og gendannelse — ikke kun forsiden.

Medtag containere og hver pakkes vedligeholdelse

En container adskiller nogle applikationsafhængigheder fra systempakker, men bruger stadig værtskerne, netværk og lagring. Vælg et understøttet image til arkitekturen. Emulering ændrer antagelser om ydeevne og support og skal være en bevidst beslutning.

Gem data på dokumenterede volumener, og prøv gendannelse uafhængigt af containeren. Lås version eller digest for reproducerbarhed, men planlæg løbende opdatering. Ubuntu Main, Ubuntu Pro, eksterne pakkekilder og downloadede programmer har ikke identiske supportvilkår.

Hold almindelige opdateringer adskilt fra release-opgradering

Efter opdatering af pakkemetadata kan du se ventende opdateringer, fejlede tjenester og en eventuel genstartsmarkør:

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

Kontrollerne foretager ikke en distributionsopgradering. Anvend opdateringer i et passende vindue og test igen; tjenester kan blive genstartet. Fravær af genstartsmarkøren beviser ikke, at alle komponenter er aktuelle.

Prøv en release-opgradering på en kopi eller ny maskine. Gennemgå runtime, pakkekilder, databaseopgradering og udvidelser. En tilbagevenden til et snapshot mister ellers skrivninger, der skete bagefter, så planlæg sidste datasynkronisering og en brugbar vej tilbage.

Efterlad en reproducerbar beslutning

Gem release, arkitektur, kerne, image-ID, applikationsbuild, afhængighedslåse og pakkernes oprindelse. Tilføj provisioneringsresultat, accepttest, ansvarlig for vedligeholdelse samt tidspunkt og resultat for sidste gendannelsestest. Gem ikke hemmeligheder i dokumentationen.

Når miljøet er afklaret, kan du fortsætte med første HTTPS-websted eller det afgrænsede Oracle-forsøg.

Spørgsmål og svar