Systèmes d'exploitation Linux - AWS OpsWorks
Amazon LinuxUbuntu LTSCentOSUtilisation de Red Hat Enterprise Linux

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Systèmes d'exploitation Linux

Important

Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur AWS Re:Post ou via le AWS Support Premium.

AWS OpsWorks Stacks prend en charge les versions 64 bits des systèmes d'exploitation Linux suivants.

Vous pouvez également utiliser les AMI personnalisées basées sur ces systèmes d'exploitation.

Quelques notes générales sur les instances Linux :

Versions de package prises en charge

Les versions prises en charge et les niveaux de correctifs pour les packages, comme Ruby, dépendent du système d'exploitation et la version, comme décrit dans les sections suivantes.

Mises à jour

Par défaut, AWS OpsWorks Stacks garantit que les instances Linux disposent des derniers correctifs de sécurité en appelant automatiquement yum update ou apt-get update après le démarrage d'une instance. Pour désactiver les mises à jour automatiques, utilisez les UpdateLayeractions CreateInstanceUpdateInstance, CreateLayer, ou, ou les méthodes du SDK AWS ou les commandes de l'interface de ligne de commande AWS équivalentes, pour définir le InstallUpdatesOnBoot paramètre sur. false

Pour éviter les interruptions de service, AWS OpsWorks Stacks n'installe pas automatiquement les mises à jour une fois qu'une instance est en ligne. Vous pouvez mettre à jour manuellement le système d'exploitation d'une instance en ligne à tout moment en exécutant la commande de pile Upgrade Operating System. Pour plus d'informations sur la gestion des mises à jour de sécurité, consultez Gestion des mises à jour de sécurité.

Pour mieux contrôler la façon dont AWS OpsWorks Stacks met à jour vos instances, créez une AMI personnalisée basée sur l'un des systèmes d'exploitation pris en charge. Par exemple, avec des AMI personnalisées, vous pouvez spécifier les versions de packages installées sur une instance. Chaque distribution Linux a des chronologies de prise en charge et des stratégies de fusion de packages différentes, donc vous devez choisir l'approche la plus adaptée à vos besoins. Pour plus d’informations, consultez Utilisation d'AMI personnalisées.

Fichier d'hôtes

Chaque instance en ligne possède un /etc/hosts fichier qui associe les adresses IP aux noms d'hôtes. AWS OpsWorks Stacks inclut les adresses publiques et privées de toutes les instances en ligne de la pile dans le hosts fichier de chaque instance. Supposons, par exemple, que vous ayez une pile contenant deux instances de Node.js App Server, nodejs-app1 et nodejs-app2, et une instance MySQL, db-master1. Le fichier hosts de l'instance nodejs-app1 ressemblera à quelque chose de similaire à l'exemple suivant et les autres instances auront des fichiers hosts similaires.


...
# OpsWorks Layer State
192.0.2.0 nodejs-app1.localdomain nodejs-app1
10.145.160.232 db-master1
198.51.100.0 db-master1-ext
10.243.77.78 nodejs-app2
203.0.113.0 nodejs-app2-ext
10.84.66.6 nodejs-app1
192.0.2.0 nodejs-app1-ext
AWS OpsWorks Support de proxy pour les agents Stacks

L'agent AWS OpsWorks Stacks pour Chef 11.10 et versions ultérieures inclut un support de base pour les serveurs proxy, qui sont généralement utilisés avec des VPC isolés. Pour activer la prise en charge du serveur proxy, une instance doit avoir un fichier /etc/environment qui fournit les paramètres appropriés pour le trafic HTTP et HTTPS. Le fichier doit être similaire à ce qui suit, en sachant que vous remplacez le texte en surbrillance par l'URL et un port de votre serveur proxy :


http_proxy="http://myproxy.example.com:8080/"
https_proxy="http://myproxy.example.com:8080/"
no_proxy="169.254.169.254"

Pour activer la prise en charge de proxy, nous vous recommandons de créer une AMI personnalisée qui inclut un fichier /etc/environment approprié et qui utilise cette AMI pour créer vos instances.

Note

Nous vous déconseillons d'utiliser une recette personnalisée pour créer un /etc/environment fichier sur vos instances. AWS OpsWorks Stacks a besoin des données du serveur proxy au début du processus de configuration, avant l'exécution de toute recette personnalisée.

Amazon Linux

AWS OpsWorks Stacks prend en charge les versions 64 bits d'Amazon Linux et Amazon Linux 2. En plus des mises à jour et des correctifs réguliers, Amazon Linux lance une nouvelle version environ tous les six mois, ce qui peut impliquer des modifications importantes. Lorsque vous créez une pile ou une instance, vous devez spécifier la version d'Amazon Linux à utiliser. Lorsqu'AWS lance une nouvelle version, vos instances continuent à exécuter la version spécifiée jusqu'à ce que vous la remplaciez explicitement. Une fois qu'une nouvelle version d'Amazon Linux a été lancée, il y a une période de quatre semaines de migration au cours de laquelle AWS continue à fournir des mises à jour régulières pour l'ancienne version. Après la fin de la période de migration, vos instances peuvent continuer à exécuter l'ancienne version, mais AWS ne fournit plus de mises à jour. Pour plus d'informations, consultez FAQ sur l'AMI Amazon Linux.

Lorsqu'une nouvelle version d'Amazon Linux est disponible, nous vous recommandons de mettre à jour vers la nouvelle version pendant la période de migration afin que vos instances continuent de recevoir des mises à jour de sécurité. Avant de mettre à jour les instances de votre pile de production, nous vous recommandons de commencer une nouvelle instance et de vérifier que votre application est exécutée correctement sur la nouvelle version. Vous pouvez ensuite mettre à jour les instances de la pile de production.

Note

Par défaut, les AMI personnalisées basées sur Amazon Linux sont mises à jour automatiquement avec la nouvelle version quand elle devient disponible. La méthode recommandée consiste à verrouiller votre AMI personnalisée sur une version Amazon Linux spécifique, ce qui vous permet de reporter la mise à jour jusqu'à ce que vous ayez testé la nouvelle version. Pour plus d'informations, consultez Comment verrouiller mon AMI avec une version spécifique ?.

Si vous utilisez un AWS CloudFormation modèle pour créer des piles avec des instances exécutant Amazon Linux, les modèles doivent spécifier explicitement une version d'Amazon Linux. En particulier, si votre modèle spécifie Amazon Linux, les instances continueront d'exécuter la version 2016.09. Pour plus d'informations, reportez-vous AWS::OpsWorks::Stackaux sections et AWS::OpsWorks::Instance.

Pour mettre à jour la version Amazon Linux d'une instance, effectuez l'une des actions suivantes :

  • Pour les instances en ligne, exécutez la commande de pile Upgrade Operating System.

    Lorsqu'une nouvelle version d'Amazon Linux est disponible, les pages Instances et Stack affichent un avis avec un lien qui vous conduit jusqu'à la page Run Command (Exécuter une commande). Vous pouvez ensuite exécuter Upgrade Operating System (Mettre à niveau le système d'exploitation) pour mettre à niveau votre instance.

  • Pour les instances hors ligne soutenues par Amazon Elastic Block Store (soutenues par EBS), démarrez les instances et exécutez Upgrade Operating System, comme décrit dans l'instruction précédente.

  • Pour les instances basées sur le stockage d'instance hors connexion, y compris les instances basées sur le temps et sur la charge, modifiez le paramètre Operating system (Système d'exploitation) de l'instance pour spécifier la nouvelle version.

    AWS OpsWorks Stacks met automatiquement à jour les instances vers la nouvelle version lorsqu'elles sont redémarrées.

Amazon Linux : versions de Node.js prises en charge
Version d'Amazon Linux Versions Node.js 
2
 
(Not applicable to operating systems that are available for Chef 12 and higher stacks only)
 
2018.03
 
0.12.18
 
2017.09
 
0.12.18
 
2017.03
 
0.12.18
 
2016.09
 
0.12.18
0.12.17
0.12.16
0.12.15
 
2016.03
 
0.12.18
0.12.17
0.12.16
0.12.15
0.12.14
0.12.13
0.12.12
0.12.10
Amazon Linux : versions de Chef prises en charge
Version de Chef Versions d'Amazon Linux prises en charge 
12
 
Amazon Linux 2
Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03
 
11.10
 
Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03
 
11.4 (deprecated)
 
Amazon Linux 2016.09
Amazon Linux 2016.03
Important

Avant de mettre à jour les instances t1.micro, assurez-vous qu'elles ont un fichier d'échange temporaire, /var/swapfile. Les instances t1.micro sur les piles de Chef 0.9 n'ont pas de fichier d'échange. Pour les piles de Chef 11.4 et Chef 11.10, les versions récentes de l'agent d'instance créent automatiquement un fichier d'échange pour les instances t1.micro. Toutefois, ce changement a été effectué sur une période de plusieurs semaines, donc vous devez vérifier l'existence de /var/swapfile sur les instances créées avant le 24 mars 2014 environ.

Pour les instances t1.micro qui n'ont pas de fichier d'échange, vous pouvez en créer un comme suit :

  • Pour la version Chef 11.10 et les versions ultérieures, créez de nouvelles instances t1.micro qui ont automatiquement un fichier d'échange.

  • Pour les piles de Chef 0.9, exécutez les commandes suivantes sur chaque instance en tant qu'utilisateur racine.

    dd if=/dev/zero of=/var/swapfile bs=1M count=256
 mkswap /var/swapfile
 chown root:root /var/swapfile
 chmod 0600 /var/swapfile
 swapon /var/swapfile

    Vous pouvez également utiliser ces commandes sur la version Chef 11.10 et les piles ultérieures si vous ne souhaitez pas créer de nouvelles instances.

Ubuntu LTS

Ubuntu lance une nouvelle version d'Ubuntu LTS environ tous les deux ans et prend en charge chaque version pendant environ cinq ans. Ubuntu fournit des mises à jour et des correctifs de sécurité pendant la durée de la prise en charge du système d'exploitation. Pour plus d'informations, consultez LTS - Ubuntu Wiki.

CentOS

AWS OpsWorks Stacks prend en charge la version 64 bits de CentOS 7. La version initialement prise en charge est CentOS 7 et CentOS publie une nouvelle version tous les deux ans environ.

Lorsque vous démarrez une nouvelle instance dans une pile CentOS, AWS OpsWorks Stacks installe automatiquement la version la plus récente de CentOS. Comme AWS OpsWorks Stacks ne met pas automatiquement à jour le système d'exploitation des instances existantes lorsqu'une nouvelle version mineure de CentOS est publiée, une instance nouvellement créée peut recevoir une version plus récente que les instances existantes de la pile. Pour que toutes les versions soient cohérentes sur votre pile, vous pouvez mettre à jour vos instances existantes vers la version actuelle de CentOS, comme suit :

  • Pour les instances en ligne, exécutez la commande de pile Upgrade Operating System (Mettre à niveau le système d'exploitation) qui exécute yum update sur les instances spécifiées afin de les mettre à jour vers la version actuelle.

    Lorsqu'une nouvelle version mineure de CentOS 7 est disponible, les pages Instances et Stack (Pile) affichent un avis avec un lien qui vous conduit jusqu'à la page Run Command (Exécuter une commande). Vous pouvez ensuite exécuter Upgrade Operating System (Mettre à niveau le système d'exploitation) pour mettre à niveau vos instances.

  • Pour les instances hors ligne basées sur Amazon EBS, démarrez les instances et exécutez Upgrade Operating System comme décrit dans l'élément de liste précédent.

  • Pour les instances hors ligne sauvegardées en magasin, AWS OpsWorks Stacks installe automatiquement la nouvelle version au redémarrage des instances.

CentOS : versions de Chef prises en charge
Version de Chef Version de CentOS prise en charge 
12
 
CentOS 7
 
11.10
 
(None supported)
 
11.4 (deprecated)
 
(None supported)
Note

AWS OpsWorks Stacks prend en charge Apache 2.4 pour les instances CentOS.

Utilisation de Red Hat Enterprise Linux

AWS OpsWorks Stacks prend en charge la version 64 bits de Red Hat Enterprise Linux 7 (RHEL 7). La version initiale prise en charge est RHEL 7.1 et Red Hat lance une nouvelle version mineure tous les 9 mois environ. Les versions mineures sont généralement compatibles avec RHEL 7.0. Pour plus d'informations, consultez Stratégies de cycle de vie et de mise à jour.

Lorsque vous démarrez une nouvelle instance, AWS OpsWorks Stacks installe automatiquement la version actuelle de RHEL 7. Comme AWS OpsWorks Stacks ne met pas automatiquement à jour le système d'exploitation des instances existantes lorsqu'une nouvelle version mineure de RHEL 7 est publiée, une instance nouvellement créée peut recevoir une version plus récente que les instances existantes de la pile. Pour que toutes les versions soient cohérentes sur votre pile, vous pouvez mettre à jour vos instances existantes vers la version actuelle de RHEL 7, comme suit :

  • Pour les instances en ligne, exécutez la commande de pile Upgrade Operating System (Mettre à niveau le système d'exploitation) qui exécute yum update sur les instances spécifiées afin de les mettre à jour vers la version actuelle.

    Lorsqu'une nouvelle version mineure de RHEL 7 est disponible, les pages Instances et Stack (Pile) affichent un avis avec un lien qui vous conduit jusqu'à la page Run Command (Exécuter une commande). Vous pouvez ensuite exécuter Upgrade Operating System (Mettre à niveau le système d'exploitation) pour mettre à niveau vos instances.

  • Pour les instances hors ligne basées sur Amazon EBS, démarrez les instances et exécutez Upgrade Operating System comme décrit dans l'élément de liste précédent.

  • Pour les instances hors ligne sauvegardées en magasin, AWS OpsWorks Stacks installe automatiquement la nouvelle version au redémarrage des instances.

Red Hat Enterprise Linux : versions Node.js prises en charge
Version de l'RHEL Versions Node.js 
7
 
(Node.js versions only apply to Chef 11.10 stacks)
0.8.19
0.8.26
0.10.11
0.10.21
0.10.24
0.10.25
0.10.27
0.10.29
0.10.40
0.12.10
0.12.12
0.12.13
0.12.15
Red Hat Enterprise Linux : versions prises en charge de Chef
Version de Chef Versions d'RHEL prise en charge 
12
 
Red Hat Enterprise Linux 7
 
11.10
 
Red Hat Enterprise Linux 7
 
11.4 (deprecated)
 
(None supported)

Toutes les versions de Node.js antérieures à 0.10.40 sont obsolètes. Les versions 0.12.7 et 0.12.9 sont également obsolètes.

Note

AWS OpsWorks Stacks prend en charge Apache 2.4 pour les instances de RHEL 7.