Différences entre versions de « Mettre a jour CoreOS manuellement »
Ligne 1 : | Ligne 1 : | ||
− | CoreOS intégre par défaut un système de mise à jour automatique (update_engine) qui planifie une vérification des mises à jours disponibles à interval régulier et les installe si il y en a effectivement. | + | CoreOS intégre par défaut un système de mise à jour automatique (update_engine) qui planifie une vérification des mises à jours disponibles à interval régulier et les installe si il y en a effectivement puis programme un reboot pour que celles-ci soient effectives. |
− | Cependant il peut être utile de faire cette vérification et l'installation des mises à jours à disponibles manuellement. Nous allons voir ci-dessous comment mettre à jour une CoreOS stable. | + | Cependant il peut être utile dans certains cas de faire cette vérification et l'installation des mises à jours à disponibles manuellement. Nous allons voir ci-dessous comment mettre à jour une CoreOS stable. |
Ligne 12 : | Ligne 12 : | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
− | core@ | + | core@CoreOSnode ~ $ cat /etc/lsb-release |
DISTRIB_ID=CoreOS | DISTRIB_ID=CoreOS | ||
DISTRIB_RELEASE=633.1.0 | DISTRIB_RELEASE=633.1.0 | ||
Ligne 24 : | Ligne 24 : | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
− | core@ | + | 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(245)] Initiating update check and install. | ||
[0622/105739:INFO:update_engine_client.cc(250)] Waiting for update to complete. | [0622/105739:INFO:update_engine_client.cc(250)] Waiting for update to complete. | ||
Ligne 63 : | Ligne 63 : | ||
NEW_SIZE=137131931 | NEW_SIZE=137131931 | ||
[0622/105959:INFO:update_engine_client.cc(193)] Update succeeded -- reboot needed. | [0622/105959:INFO:update_engine_client.cc(193)] Update succeeded -- reboot needed. | ||
− | core@ | + | core@CoreOSnode ~ $ |
</syntaxhighlight> | </syntaxhighlight> | ||
Ligne 74 : | Ligne 74 : | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
− | core@ | + | core@CoreOSnode ~ $ cat /etc/lsb-release |
DISTRIB_ID=CoreOS | DISTRIB_ID=CoreOS | ||
DISTRIB_RELEASE=681.2.0 | DISTRIB_RELEASE=681.2.0 | ||
Ligne 89 : | Ligne 89 : | ||
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 : | 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 | ;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 | + | :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 donc utilise la stratégie "etcd-lock" sinon cela utilise simplement la stratégie "reboot" |
;etcd-Lock | ;etcd-Lock | ||
− | :Avec cette stratégie, chaque machine | + | :Avec cette stratégie, chaque machine verrouille le redémarrage avant d'autoriser celui-ci. Cela permet à une mise à jour d'être appliqué rapidement à un cluster sans perdre le quorum dans Etcd. En effet le nombre de machine autorisées à redémarrer simultanément est configurable via la commande suivante (en adaptant le nombre maximum à votre contexte) : |
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
− | core@CoreOSnode | + | core@CoreOSnode ~ $ locksmithctl set-max 2 |
Old-Max: 1 | Old-Max: 1 | ||
Max: 2 | Max: 2 | ||
Ligne 109 : | Ligne 110 : | ||
;off | ;off | ||
:Cette stratégie fait que la machine attend une commande demandant explicitement le redémarrage après installation des mises à jour. | :Cette stratégie fait que la machine attend une commande demandant explicitement le redémarrage après installation des mises à jour. | ||
+ | |||
+ | |||
+ | La stratégie se définie soit dans le fichier /etc/coreos/update.conf : | ||
+ | |||
+ | |||
+ | <syntaxhighlight lang="bash"> | ||
+ | core@CoreOSnode ~ $ cat /etc/coreos/update.conf | ||
+ | REBOOT_STRATEGY=off | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | soit dans le fichier cloud-config utilisé comme ceci : | ||
+ | |||
+ | |||
+ | <pre> | ||
+ | #cloud-config | ||
+ | coreos: | ||
+ | update: | ||
+ | reboot-strategy: best-effort | ||
+ | </pre> | ||
+ | |||
+ | |||
[[Category:CoreOS]] | [[Category:CoreOS]] | ||
[[Category:Linux]] | [[Category:Linux]] | ||
+ | [[category:cloudstack]] | ||
+ | [[category:cloud public]] | ||
+ | [[category:cloud privé]] |
Version du 24 juin 2015 à 16:32
CoreOS intégre par défaut un système de mise à jour automatique (update_engine) qui planifie une vérification des mises à jours disponibles à interval régulier et les installe si il y en a effectivement puis programme un reboot pour que celles-ci soient effectives.
Cependant il peut être utile dans certains cas de faire cette vérification et l'installation des 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".
On commence par vérifier la version de CoreOS actuelle :
core@CoreOSnode ~ $ cat /etc/lsb-release
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=633.1.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 633.1.0"
On lance l'installation des mises à jours (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
Broadcast message from locksmithd at 2015-06-22 10:59:57.244742724 +0200 CEST:
System reboot in 5 minutes!
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 ~ $
A 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 5minutes.
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 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 donc utilise la stratégie "etcd-lock" sinon cela utilise simplement la stratégie "reboot"
- 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é rapidement à un cluster sans perdre le quorum dans Etcd. En effet le nombre de machine 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 aussitot que les mises à jours sont installées.
- off
- Cette stratégie fait que la machine attend une commande demandant explicitement le redémarrage après installation des mises à jour.
La stratégie se définie 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