Comment mettre à jour le fichier de configuration Nginx sur plusieurs serveurs identiques en même temps?


12

Nous avons une flotte de serveurs Nginx sur Amazon EC2 où nous devons parfois mettre à jour les fichiers de configuration pour implémenter de nouveaux paramètres.

Actuellement, nous avons les configurations dans une AMI personnalisée et si nous devons mettre à jour, nous devons reconstruire les instances AMI puis EC2. Nous avons quelques scripts d'aide, mais c'est encore un effort pour le faire. Y a-t-il une meilleure façon?


3
ansible, saltstack pour n'en nommer que quelques-uns.
poige

Réponses:


26

Il existe un certain nombre de concepts que vous pouvez exploiter.

La clé du succès est l' automatisation

La première option est de continuer à faire ce que vous faites maintenant, c'est-à-dire de reconstruire les EC2 à chaque changement de configuration . Juste de manière entièrement automatisée.

Comme vous effectuez maintenant des mises à jour de configuration via des AMI, vous allez plus loin et créez un pipeline qui, lors d'un changement de fichier de configuration dans un référentiel,:

  1. Créer automatiquement une nouvelle AMI - Packer est l'un des outils les plus populaires pour ce faire
  2. Reconstruisez automatiquement votre flotte Nginx - vous devriez déjà avoir tous les serveurs Nginx dans un groupe Auto-Scaling avec un équilibreur de charge d'application en face. Si vous ne le faites pas, vous devriez, car cela rendra la mise à jour aussi simple que de mettre à jour la configuration de lancement ASG et d'attendre que les instances soient reconstruites à partir de la nouvelle AMI.

La deuxième option consiste à conserver les instances en place et à ne déployer que les fichiers de configuration , sans les reconstruire. En règle générale, vous pouvez traiter les fichiers de configuration comme du code et déployer vos modifications de configuration de la même manière que vous déploieriez les versions de code. AWS dispose de nombreux outils pour vous y aider.

  • AWS Elastic Beanstalk qui utilise Chef en interne et vous pouvez écrire vos mises à jour Nginx de cette manière.
  • AWS Code Deploy, qui est un outil de déploiement entièrement scriptable qui s'intègre bien avec d'autres parties d' AWS Code Suite :
    • Code Commit où vous pouvez conserver vos fichiers de configuration Nginx dans Git.
    • Pipeline de code pouvant déclencher automatiquement le déploiement chaque fois qu'un fichier de configuration est mis à jour dans Code Commit.
  • Ansible ou Puppet qui sont des outils non AWS populaires qui peuvent vous aider à garder tous les serveurs configurés de la même manière.

Une fois que vous serez à l'aise avec l'automatisation de ces mises à jour de configuration Nginx, vous souhaiterez peut-être étendre l'automatisation au reste de votre infrastructure.


Il y a un grand livre blanc Aperçu des options de déploiement sur AWS qui vous donnera une belle vue d'ensemble.

J'espère que ça aide :)


Une alternative à Ansible ou Puppet est Salt, qui est conçue pour une configuration de type maître / séide et une sorte de système optimisé pour les déploiements à plus grande échelle.
Araho

5

Stockez vos configurations sur EFS et montez EFS à l'emplacement où les configurations Nginx sont attendues. Mettez-les également sur Amazon S3 et exécutez une synchronisation de temps en temps, ou utilisez s3fs (méfiez-vous que s3fs peut ne pas être assez bon pour une utilisation en production).

Lorsque vous devez modifier votre configuration, augmentez la taille souhaitée de votre groupe de mise à l'échelle automatique pour doubler ce dont vous avez besoin pour déclencher de nouvelles instances avec la nouvelle configuration, puis redescendez sur ce dont vous avez besoin, ce qui supprimera les anciennes instances. Sinon, faites simplement un redémarrage continu des serveurs.

Une autre option consiste à simplement pousser les nouvelles configurations sur votre serveur à l'aide d'un outil d'automatisation de base, comme le déploiement de code AWS.

Les options entièrement automatisées ci-dessus sont techniquement meilleures et plus propres, mais si vous modifiez rarement les configurations et souhaitez une solution simple, cela pourrait vous aider.



1

Reconstruire les AMI ou créer des pipelines de déploiement à part entière comme les autres suggèrent juste pour un changement de fichier de configuration semble être une exagération. Vous devez utiliser Ansible pour pousser les modifications et garder tous vos nœuds synchronisés. Il existe de nombreux modules Ansible qui peuvent vous aider à automatiser les tâches courantes.


Un avantage de l'infrastructure immuable est que vous savez que vous n'avez pas de serveurs "pour animaux de compagnie" qui sont fragiles et doivent être maintenus. Cela vous donne l'assurance que vous pouvez créer plus de serveurs en prod / DR / testing sans problème.
Tim
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.