Différences entre versions de « Mettre a jour CoreOS manuellement »
Ligne 1 : | Ligne 1 : | ||
+ | <span data-link_translate_en_title="Update CoreOS manually" data-link_translate_en_url="Update+CoreOS+manually"></span>[[:en:Update CoreOS manually]][[en:Update CoreOS manually]] | ||
Ligne 164 : | Ligne 165 : | ||
[[category:cloud public]] | [[category:cloud public]] | ||
[[category:cloud privé]] | [[category:cloud privé]] | ||
− |
Version du 24 septembre 2015 à 09:03
CoreOS intègre par défaut un système de mise à jour (update_engine) qui planifie une vérification des mises à jours disponibles à intervalles réguliers, les installe automatiquement et programme un reboot pour que celles-ci soient effectives.
Cependant, il peut être utile dans certains cas de rechercher et d'installer les mises à jours à disponibles manuellement. Nous allons voir ci-dessous comment mettre à jour une CoreOS stable.
Nous partons du principe que vous venez de déployer une instance CoreOS et que vous y êtes connecté en SSH en utilisateur "core".
Nous commençons par vérifier la version actuelle de CoreOS :
core@CoreOSnode ~ $ cat /etc/lsb-release
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=633.1.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 633.1.0"
Nous lançons l'installation des mises à jour (le retour a été volontairement tronqué) :
core@CoreOSnode ~ $ sudo update_engine_client -update
[0622/105739:INFO:update_engine_client.cc(245)] Initiating update check and install.
[0622/105739:INFO:update_engine_client.cc(250)] Waiting for update to complete.
LAST_CHECKED_TIME=1434963460
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_UPDATE_AVAILABLE
NEW_VERSION=0.0.0.0
NEW_SIZE=137131931
LAST_CHECKED_TIME=1434963460
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_UPDATE_AVAILABLE
...
NEW_VERSION=0.0.0.0
NEW_SIZE=137131931
LAST_CHECKED_TIME=1434963460
PROGRESS=0.993617
CURRENT_OP=UPDATE_STATUS_DOWNLOADING
NEW_VERSION=0.0.0.0
NEW_SIZE=137131931
LAST_CHECKED_TIME=1434963460
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_FINALIZING
NEW_VERSION=0.0.0.0
NEW_SIZE=137131931
LAST_CHECKED_TIME=1434963460
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_FINALIZING
NEW_VERSION=0.0.0.0
NEW_SIZE=137131931
<!--T:8-->
Broadcast message from locksmithd at 2015-06-22 10:59:57.244742724 +0200 CEST:
System reboot in 5 minutes!
<!--T:9-->
LAST_CHECKED_TIME=1434963460
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_UPDATED_NEED_REBOOT
NEW_VERSION=0.0.0.0
NEW_SIZE=137131931
[0622/105959:INFO:update_engine_client.cc(193)] Update succeeded -- reboot needed.
core@CoreOSnode ~ $
À la fin de l'installation des mises à jour, nous sommes invités à redémarrer notre instance CoreOS soit immédiatement ("sudo reboot") soit automatiquement au bout de 5 minutes.
Après redémarrage de notre instance CoreOS, nous vérifions la nouvelle version de celle-ci :
core@CoreOSnode ~ $ cat /etc/lsb-release
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=681.2.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 681.2.0"
Nous sommes maintenant dans la dernière version CoreOS stable (681.2.0 à l'heure de cette FAQ).
Les différentes stratégies de mise à jour/redémarrage
CoreOS intègre 4 stratégies de redémarrage (reboot-strategy), ces stratégies contrôlent la façon dont le redémarrage se produit. Ces 4 stratégies sont :
- best-effort
- Le paramètre "par défaut dans CoreOS". Ce paramètre détermine si la machine fait partie d'un cluster. Si ETCD est démarré la machine est supposée faire partie d'un cluster et utilise donc la stratégie "etcd-lock". Dans le cas contraire, c'est la stratégie "reboot" qui est utilisée.
- etcd-Lock
- Avec cette stratégie, chaque machine verrouille le redémarrage avant d'autoriser celui-ci. Cela permet à une mise à jour d'être appliquée rapidement à un cluster sans perdre le quorum dans Etcd. En effet, le nombre de machines autorisées à redémarrer simultanément est configurable via la commande suivante (en adaptant le nombre maximum à votre contexte) :
core@CoreOSnode ~ $ locksmithctl set-max 2
Old-Max: 1
Max: 2
- reboot
- Cette stratégie redémarre la machine aussitôt que les mises à jours sont installées.
- off
- Avec cette stratégie, la machine attend une commande demandant explicitement le redémarrage après installation des mises à jour.
La stratégie se définit soit dans le fichier /etc/coreos/update.conf :
core@CoreOSnode ~ $ cat /etc/coreos/update.conf
REBOOT_STRATEGY=off
soit dans le fichier cloud-config utilisé comme ceci :
#cloud-config coreos: update: reboot-strategy: best-effort