Як автоматично оновлювати список nginx висхідного сервера, коли aws ec2 змінюється або збільшується?

Я хочу налаштувати автоматичне масштабування в AWS. Я не хочу використовувати еластичний балансир навантаження.

Автоматичне виклик в Amazon створює екземпляри EC2 плавно під час стрибків попиту, щоб підтримувати продуктивність, і автоматично зменшується під час затримки попиту, щоб мінімізувати витрати.

Оскільки ці екземпляри EC2 створюються автоматично, імена їх хостів NGINX невідомі.

Я знаю і вже маю налаштування upstream в nginx до 10 екземплярів EC2.

Я хочу , щоб мати можливість додавати / оновлювати / видаляти автоматично імена серверів в моїх випадках перед Nginx конфігурації, коли автомасштабирование додає / оновлення / вилучень EC2.

— Луїс Лобо Боробія
джерело

Вам потрібно видалити "автоматичне масштабування" зі свого запитання. Автоматичне масштабування - термін AWS. Я думаю, що ви маєте на увазі, що ви хочете автоматично масштабувати (горизонтально), додаючи більше вузлів висхідного потоку до вашого nginx, що діє як LB, і ви запитуєте, як автоматично змінити конфігурацію nginx, коли додаються / видаляються / змінюються верхні вузли. Якщо це так, будь ласка, відредагуйте своє запитання відповідно.

— talonx

ну, насправді я знаю, що таке автоматичне дзвінок, і я хочу це сказати. Я хочу змішати обидва. Я оновлю питання.

— Луїс Лобо Боробія

Питання зараз зрозуміліше, в його намірі. Я хотів проголосувати за повторне відкриття, але не бачу варіанту - здогадайтесь, у мене ще недостатньо представників.

— talonx

Дякую @talonx, сподіваюся, інші зможуть знайти мою відповідь

— Луїс Лобо Боробія

Я думаю, ви можете комбінувати сповіщення про автоматичне масштабування AWS (доставлені за допомогою SNS) - якщо припустити, що воно повертає ім'я хоста новоствореного / припиненого екземпляра - та одного з сторонніх API nginx для оновлення та перезавантаження конфігурації nginx. Вибачте за розпливчастість - я не дуже знайомий з API автоматичного масштабування.

— talonx

Відповіді:

Цього можна досягти, скориставшись Amazon SDK (я майже з цим закінчую, викладу його на github), використовуючи сервіс SNS, EC2 та автоматичне масштабування.

Я дотримувався наступних кроків, щоб досягти цього:

Увімкніть сповіщення HTTP та підписався на мій веб-сервер.
До моєї групи автоматичного масштабування для завершення роботи сервера додано кручок життєвого циклу з серцебиттям 1 хв (дочекатися 1 хвилини до закінчення)
Створено файл індексу для розбору повідомлення, щоб виявити, що таке повідомлення (тобто запустити або припинити)
Після того, як тип події вирішено, я запитав EC2, щоб отримати приватний ip примірника
У разі запуску зачекайте, до отримання заголовка 200, а потім додайте ip до nginx config та перезавантажте
У разі припинення видаліть IP-адресу з конфігурації та перезавантажте nginx

Знайдіть скрипт тут https://github.com/singhupendra/aws-autoscale

— Упендра
джерело

Будь-який шанс ви розмістили це на Github? Я намагаюся зробити те саме, і будь-яка допомога буде вдячна.

— Аарон

будь ласка , використовуйте - github.com/singhupendra/aws-autoscale

— Упендра

Дякую @talonx, я провів кілька досліджень, Amazon Autoscale має api для запиту поточного статусу групи автоматичних масштабів та перераховує його членів. Він повертає ідентифікатор екземпляра ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example ), тоді ви можете використовувати інструменти опису, щоб отримати ім’я сервера ( http: // docs .aws.amazon.com / AWSEC2 / найновіший / CommandLineReference / ApiReference-cmd-DescribeInsances.html ) і, нарешті, відтворити файл, що включає вхідний потік. Я міг відчути сповіщення автоматичного масштабування, щоб запустити процес, який виконує ці завдання.

Я все ще не реалізував це, але це шлях.

Можна також використовувати автоматичний дзвінок за допомогою SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html

— Луїс Лобо Боробія
джерело

Це в основному те, що я зробив. Я написав рубіновий сценарій, який працює кожні N хвилин. Використовуючи AWS SDK, він запитує членів ASG та за допомогою шаблону ERB створює новий конфігурацію. Якщо нова конфігурація відрізняється від поточної конфігурації, вона копіює її на місце і каже демону (у моєму випадку haproxy) перезавантажити його конфігурацію. Зауважте, що екземпляри залишаються в ASG деякий час після їх припинення, тому переконайтеся, що instance.status ==: запущений. Також зауважте, що якщо для запуску екземпляра для запуску екземпляра потрібно N хвилин, не використовуйте його unil зараз> instance.launch_time + N.

— Марк Вагнер

Дякую @MarkWagner. Чи є можливість ви десь поділитися цим сценарієм? Гіст, гітуб? Спасибі!

— Луїс Лобо Боробія

Чи пощастило вам із цим сценарієм? Чи є приклад на github чи деінде?

— Аарон

Ні, але зараз nginx-plus (платна версія) дозволяє це більше.

— Луїс Лобо Боробія

Я ще цього ще не реалізував, але я розглядаю можливість скористатись функцією "Потокова реконфігурація " NGiNX Plus . Я думаю, що або AMI, або управління конфігурацією (Puppet, Salt або подібне), що встановлює екземпляр групи автоматичного масштабування, може дійти до API конфігурації NGiNX (можливо, через внутрішнє ім'я домену Route53, тому жоден фіксований IP не буде потрібно використовувати) та додати себе до кластеру висхідного потоку для зворотного проксі. Після цього вбудована перевірка стану здоров’я NGiNX бере на себе цей [доданий] екземпляр і відміняє його, якщо він стає недоступним. Це здається найчистішим рішенням, і немає затримки з додаванням екземпляра, і навряд чи є затримка у видаленні його, оскільки NGiNX Plus має поза перевірку стану здоров’я.

Цей підхід дозволяє уникнути необхідності створення системи автоматичного виявлення (консул, кріпак тощо), яка для менших налаштувань часто здається значною як з точки зору встановлення / адміністрування, так і з необхідними екземплярами EC2. Наприклад, консул вимагає, щоб мінімум три екземпляри були стабільними. Кріпосний може, можливо, працювати самими екземплярами ASG, але все ще є накладні витрати на його підтримку, і якщо ASG зменшиться до одного або двох екземплярів, ви втратите кворум.

Нарешті, це може бути поєднано з автоматичним сповіщенням про зміни групи автоматичного масштабування, можливо, на сервері NGiNX, який / використовується для балансування навантаження. Слухач, ініційований таким сповіщенням (це може бути і посилання на Upendra), може негайно додати новий екземпляр до NGiNX за допомогою API модифікації на ходу. Окрім вартості NGiNX Plus, це змушує задуматися, чому б хтось в першу чергу використовував еластичний балансир навантаження з його численними проблемами.

Редагування 2015-12-07: ngx_openresty «и балансир-на-Lua ( див це GitHub нитка ) пропонує інше можливе рішення з відкритим вихідним кодом для гарячого додавання / видалення серверів з групи Nginx вгору по течії. Я сам ще не експериментував з цим, але хотів додати тут згадку про кожного, хто натикається на цю посаду.

— Віль
джерело