Jak zaktualizować plik konfiguracyjny Nginx na wielu identycznych serwerach jednocześnie?

Mamy flotę serwerów Nginx na Amazon EC2, gdzie od czasu do czasu musimy aktualizować pliki konfiguracyjne, aby wprowadzić nowe ustawienia.

Obecnie mamy konfiguracje w niestandardowym interfejsie AMI i jeśli musimy zaktualizować, musimy odbudować instancje AMI, a następnie EC2. Mamy kilka skryptów pomocniczych, ale wciąż jest to dość trudny wysiłek. Czy jest jakiś lepszy sposób?

Istnieje wiele koncepcji, które można wykorzystać.

Kluczem do sukcesu jest automatyzacja

Pierwszą opcją jest kontynuowanie robienia tego, co robisz teraz, tj. Przebudowywanie EC2 przy każdej zmianie konfiguracji . Tylko w pełni zautomatyzowany sposób.

Gdy wykonujesz teraz aktualizacje konfiguracji za pośrednictwem interfejsów AMI, posuwasz się o krok dalej i tworzysz potok, który po zmianie pliku konfiguracyjnego w pewnym repozytorium:

1. Automatycznie buduj nowy AMI - jednym z najpopularniejszych narzędzi do tego celu jest Packer
2. Automatycznie odbuduj swoją flotę Nginx - powinieneś już mieć wszystkie serwery Nginx w grupie automatycznego skalowania z modułem równoważenia obciążenia aplikacji z przodu. Jeśli nie , powinieneś, ponieważ spowoduje to, że aktualizacja będzie tak prosta, jak aktualizacja konfiguracji uruchamiania ASG i oczekiwanie na ponowne utworzenie instancji z nowego interfejsu AMI.

Drugą opcją jest utrzymanie instancji na miejscu i wdrażanie tylko plików konfiguracyjnych bez ich odbudowywania. Zasadniczo można traktować pliki konfiguracyjne jako kod i wdrażać zmiany konfiguracji w taki sam sposób, jak wdraża się wydania kodu. AWS ma wiele narzędzi, które mogą w tym pomóc.

• AWS Elastyczna fasolka szparagowa, która używa Chef wewnętrznie i możesz w ten sposób skryptować aktualizacje Nginx.
• AWS Code Deploy, które jest w pełni skryptowalnym narzędziem do wdrażania, które dobrze integruje się z innymi częściami AWS Code Suite :
  • Code Commit, w którym możesz przechowywać swoje pliki konfiguracyjne Nginx w Git.
  • Potok kodu, który może automatycznie wyzwalać wdrożenie za każdym razem, gdy plik konfiguracyjny jest aktualizowany w programie Code Commit.
• Ansible lub Puppet, które są popularnymi narzędziami innymi niż AWS, które mogą pomóc w utrzymaniu konfiguracji wszystkich serwerów w ten sam sposób.

Gdy poczujesz się swobodnie z automatyzacją aktualizacji konfiguracji Nginx, możesz chcieć rozszerzyć automatyzację na resztę infrastruktury.

Jest świetny oficjalny dokument Przegląd opcji wdrażania w AWS , który da ci ładny przegląd.

Mam nadzieję że to pomogło :)

Zapisz swoje konfiguracje na EFS i zamontuj EFS w miejscu, w którym spodziewane są konfiguracje Nginx. Alternatywnie umieść je na Amazon S3 i od czasu do czasu uruchom synchronizację lub użyj s3fs (strzeż się, że s3fs może nie być wystarczająco dobry do użytku produkcyjnego).

Gdy potrzebujesz zmienić konfigurację, zwiększ żądany rozmiar grupy automatycznego skalowania, aby podwoić liczbę potrzebną do uruchomienia nowych instancji w nowej konfiguracji, a następnie wróć do potrzebnych ustawień, które usuną stare instancje. Alternatywnie po prostu wykonaj ciągły restart serwerów.

Inną opcją jest po prostu wypchnięcie nowych konfiguracji na serwer za pomocą podstawowego narzędzia do automatyzacji, takiego jak wdrażanie kodu AWS.

W pełni zautomatyzowane opcje powyżej są technicznie lepsze i czystsze, ale jeśli rzadko zmieniasz konfiguracje i chcesz łatwego rozwiązania, może to pomóc.

AWS Run Command https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html

Lub możesz użyć Opsworks https://aws.amazon.com/opsworks/

Przebudowa interfejsów AMI lub tworzenie pełnych możliwości potoków wdrażania, jak sugerują inni, tylko dla zmiany pliku konfiguracyjnego wydaje się przesadą. Powinieneś użyć Ansible, aby wypchnąć zmiany i zachować synchronizację wszystkich swoich węzłów. Istnieje wiele modułów Ansible, które mogą pomóc w automatyzacji typowych zadań.