VPS : cloud-init et noyau linux-image-cloud (utilité ???)

[dezix]

Bonjour,

Les VPS d'OVH (VM) sont installés avec init-cloud et un noyau linux-image-cloud
une recherche sur "cloud" parmis les paquets installés donne :

• cloud-init
• cloud-utils
• cloud-guest-utils
• cloud-image-utils
• linux-image-cloud-amd64
• linux-image-4.19.0-8-cloud-amd64
• linux-image-4.19.0-9-cloud-amd64

J'ai besoin de votre aide pour comprendre à quoi cela sert exactement
et comment revenir sans problèmes vers une installation classique → sans cloud-init et avec un noyau classique.


Voici ce que j'en ai compris :

linux-image-4-19-0-9-cloud-amd64 : Ce paquet fournit le noyau 4.19 et les modules à utiliser sur les plateformes de nuage Amazon EC2, Google Compute Engine et Microsoft Azure. donc un noyau destiné à l'OS installé sur une VM louée par Amazon....

cloud-init : Contient des scripts et des fichiers exemples de config pour faciliter la config d'une telle VM


Ce serait donc pour faciliter l'installation de VM propulsées par Debian sur des VM des serveurs d'Amazon & Co
ce qui n'est vraiment pas mon intention.

Ce que je ne parviens pas à comprendre :

Pourquoi OVH installe cela par défaut sur des VPS que je suppose (à tord ?) destinés à héberger des sites web ou des applis qui n'ont rien à voir (en général) avec les clouds des GAFAM.

Je n'ai fait que survoler l'offre Amazon EC2,
mais il me semble qu'ils louent des VM créées sur leurs serveur pour y héberger du SAS
(c'est donc là que devraient être installés les paquets précités ? ).

Merci pour vos lumières.

PS : Ce sujet vient en support à ce qui est décrit dans : Virtualisation d'un système réel

[dezix]

Je commence à m'auto-répondre

Ce que je ne parviens pas à comprendre :

Pourquoi OVH installe cela par défaut sur des VPS que je suppose (à tord ?) destinés à héberger des sites web ou des applis qui n'ont rien à voir (en général) avec les clouds des GAFAM.

OVH propose le même genre de produits "Cloud" que les autres ... ceci explique cela.... Excusez mon ignorance, je découvre

[piratebab]

Les VM sont "paravirtualisées", et non pas simplement "virtualisées". Je te laisse chercher la différence sur wikipedia.
Et une VM "paravirtualisée" fonctionne plus efficacement si le noyau est configuré en conséquence. Mais je n'ai aucune idée en quoi consistent ces optimisations.

[dezix]

Je comprends : para-virtualisé = Matériel virtualisé donc nécessité d'avoir les pilotes (style virtio pour kvm)

Les VM sont "paravirtualisées", et non pas simplement "virtualisées".

De quelle VM tu parles de celle qui fait tourner le VPS (bas de gamme) que j'utilise
ou
celles qu'on installe sur les solutions "Cloud" pour du SAS & co
ou
toutes


Pour l'instant, je n'ai pas d'autres prétentions que du très classique :
* serveur HTTP
* serveur SMTP
* serveur FTP
* serveur SQL


Alors si j'installe le noyau classique et supprime le paquet cloud-init et associés

C'est la cata garantie ou pas ?

Et si je ne conserve que le noyau "cloud" j'aurai les pilotes et basta ?

[piratebab]

Je parle des machines virtuelles que tu peux louer chez OVH par exemple. Ce sont des systèmes virtualisé préinstallés.
Par opposition aux machines "dédiées" sur lequel tu dois tout installer toi même ou presque.
A la maison, lorsque j'instelle une VM, je prends la version standard de la distribution.

[dezix]

En attendant d'avoir plus de recul sur les éventuels problèmes engendrés par la désactivation complète de cloud-init
je n'ai encore rien remarqué, la connexion SSH fonctionne

Voici comment désactiver cloud-init (sans rien désinstaller) :

Code : Tout sélectionner

# touch /etc/cloud/cloud-init.disabled
# reboot

Pour vérifier si c'est vraiment désactivé, voir les journaux :

/var/log/cloud-init.log
/var/log/cloud-init-output.log


qui n'auront pas été édités lors du reboot

et

# ls -r /run/cloud-init

ne renvoie plus que : cloud-init-generator.log

alors que si cloud-init est actif, on a :

Code : Tout sélectionner

# ls -1pr /run/cloud-init
status.json
result.json
network-config-ready
enabled
ds-identify.log
cloud-init-generator.log
cloud.cfg

Dans mon cas (système minimum neuf) avec ou sans cloud-init j'ai :

Code : Tout sélectionner

# dmesg | egrep -i "(fail|warn)" 
[    0.422968] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    0.424643] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.

dont je ne pige pas la portée/importance

Au niveau du réseau : hosts ; hostname ; interfaces sont inchangés.

LVM et les partitions que j'ai déjà mis en place semble ok :

Code : Tout sélectionner

# mount | egrep -i "(vg0|sda)"
/dev/sda1 on /boot type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/vg0-lv_racine on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/vg0-lv_home on /home type ext4 (rw,relatime)
/dev/mapper/vg0-lv_srv_db on /srv/db type ext4 (rw,relatime)
/dev/mapper/vg0-lv_srv_http on /srv/http type ext4 (rw,relatime)
/dev/mapper/vg0-lv_srv_ftp on /srv/ftp type ext4 (rw,relatime)
/dev/mapper/vg0-lv_srv_mail on /srv/mail type ext4 (rw,relatime)
/dev/mapper/vg0-lv_tmp on /tmp type ext4 (rw,relatime)
/dev/mapper/vg0-lv_var_cache on /var/cache type ext4 (rw,relatime)
/dev/mapper/vg0-lv_var_log on /var/log type ext4 (rw,relatime)

Si quelqu'un a d'autres vérifications à me suggérer... elles seront bienvenues, merci.