Différences entre versions de « Mettre a jour CoreOS manuellement »

De Ikoula Wiki
Jump to navigation Jump to search
(3 versions intermédiaires par le même utilisateur non affichées)
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 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.
+
<!--T:1-->
 +
CoreOS intègre par défaut un système de mise à jour <span class="notranslate">(update_engine)</span> 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.
  
  
−
Nous partons du principe que vous venez de déployer une instance CoreOS et que vous y êtes connecté en SSH en utilisateur "core".
+
<!--T:2-->
 +
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.
  
  
−
On commence par vérifier la version de CoreOS actuelle :
+
<!--T:3-->
 +
Nous partons du principe que vous venez de déployer une instance CoreOS et que vous y êtes connecté en SSH en utilisateur <span class="notranslate">"core"</span>.
  
  
 +
<!--T:4-->
 +
Nous commençons par vérifier la version actuelle de CoreOS :
 +
 +
 +
<!--T:5-->
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
core@CoreOSnode ~ $ cat /etc/lsb-release
 
core@CoreOSnode ~ $ cat /etc/lsb-release
Ligne 20 : Ligne 27 :
  
  
−
On lance l'installation des mises à jours (le retour a été volontairement tronqué):
+
<!--T:6-->
 +
Nous lançons l'installation des mises à jour (le retour a été volontairement tronqué) :
  
 
   
 
   
 +
<!--T:7-->
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
core@CoreOSnode ~ $ sudo update_engine_client -update
 
core@CoreOSnode ~ $ sudo update_engine_client -update
Ligne 54 : Ligne 63 :
 
NEW_SIZE=137131931
 
NEW_SIZE=137131931
  
 +
<!--T:8-->
 
Broadcast message from locksmithd at 2015-06-22 10:59:57.244742724 +0200 CEST:
 
Broadcast message from locksmithd at 2015-06-22 10:59:57.244742724 +0200 CEST:
 
System reboot in 5 minutes!
 
System reboot in 5 minutes!
  
 +
<!--T:9-->
 
LAST_CHECKED_TIME=1434963460
 
LAST_CHECKED_TIME=1434963460
 
PROGRESS=0.000000
 
PROGRESS=0.000000
Ligne 67 : Ligne 78 :
  
  
−
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.
+
<!--T:10-->
 +
À 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.
  
  
 +
<!--T:11-->
 
Après redémarrage de notre instance CoreOS, nous vérifions la nouvelle version de celle-ci :
 
Après redémarrage de notre instance CoreOS, nous vérifions la nouvelle version de celle-ci :
  
  
 +
<!--T:12-->
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
core@CoreOSnode ~ $ cat /etc/lsb-release
 
core@CoreOSnode ~ $ cat /etc/lsb-release
Ligne 82 : Ligne 96 :
  
  
−
Nous sommes maintenant dans la dernière version CoreOS stable (681.2.0 à l'heure de cette FAQ)
+
<!--T:13-->
 +
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==
+
==Les différentes stratégies de mise à jour/redémarrage== <!--T:14-->
  
  
−
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 :
+
<!--T:15-->
 +
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 :
  
  
 +
<!--T:16-->
 
;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 supposée faire partie d'un cluster et donc utilise la stratégie "etcd-lock" sinon cela utilise simplement la stratégie "reboot"
+
: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.
  
 +
<!--T:17-->
 
;etcd-Lock
 
;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) :
+
: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) :
  
  
 +
<!--T:18-->
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
core@CoreOSnode ~ $ locksmithctl set-max 2
 
core@CoreOSnode ~ $ locksmithctl set-max 2
Ligne 105 : Ligne 124 :
  
  
 +
<!--T:19-->
 
;reboot
 
;reboot
−
:Cette stratégie redémarre la machine aussitot que les mises à jours sont installées.
+
:Cette stratégie redémarre la machine aussitôt que les mises à jours sont installées.
  
 +
<!--T:20-->
 
;off
 
;off
−
:Cette stratégie fait que la machine attend une commande demandant explicitement le redémarrage après installation des mises à jour.
+
: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éfinie soit dans le fichier /etc/coreos/update.conf :
+
<!--T:21-->
 +
La stratégie se définit soit dans le fichier /etc/coreos/update.conf :
  
  
 +
<!--T:22-->
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
core@CoreOSnode ~ $ cat /etc/coreos/update.conf
 
core@CoreOSnode ~ $ cat /etc/coreos/update.conf
Ligne 121 : Ligne 144 :
  
  
 +
<!--T:23-->
 
soit dans le fichier cloud-config utilisé comme ceci :
 
soit dans le fichier cloud-config utilisé comme ceci :
  
  
 +
<!--T:24-->
 
<pre>
 
<pre>
 
#cloud-config
 
#cloud-config
Ligne 133 : Ligne 158 :
  
  
 +
<!--T:25-->
 
[[Category:CoreOS]]
 
[[Category:CoreOS]]
 
[[Category:Linux]]
 
[[Category:Linux]]
Ligne 138 : Ligne 164 :
 
[[category:cloud public]]
 
[[category:cloud public]]
 
[[category:cloud privé]]
 
[[category:cloud privé]]
 +

Version du 21 septembre 2015 à 15:50


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
Récupérée de « https://fr-wiki.ikoula.com/index.php?title=Mettre_a_jour_CoreOS_manuellement&oldid=8142 »