Elastic beanstalk что это

Возможности AWS Elastic Beanstalk

Широкий выбор платформ для приложений

Широкий выбор платформ для приложений

Многочисленные варианты развертывания приложений

Многочисленные варианты развертывания приложений

AWS Elastic Beanstalk позволяет развертывать программный код из Консоли управления AWS, интерфейса командной строки Elastic Beanstalk, а также из Visual Studio или Eclipse. На выбор предоставляются разнообразные политики развертывания, в том числе единовременное, поэтапное, поэтапное с дополнительным пакетом, постоянное либо сине-зеленое (динамическое) развертывание. Эти политики помогут найти разумный баланс между скоростью и безопасностью развертывания приложений при минимальном объеме администрирования.

Мониторинг

AWS Elastic Beanstalk предоставляет единый пользовательский интерфейс для мониторинга работоспособности приложений и управления таковой.

Чтобы точно определять работоспособность приложения, Elastic Beanstalk собирает более 40 важных метрик и атрибутов. Панель управления работоспособностью в Elastic Beanstalk наглядно показывает рабочее состояние приложений и позволяет настраивать соответствующие проверки, разрешения и отчеты в едином интерфейсе.

Мониторинг, ведение журнала и отслеживание

Elastic Beanstalk интегрирован с Amazon CloudWatch и AWS X-Ray. На панели управления мониторингом отображаются такие важные рабочие метрики, как сетевая задержка, загрузка ЦПУ и коды ответов. Кроме того, здесь можно настроить оповещения CloudWatch, которые будут срабатывать при выходе метрик за установленные пределы.

Управление средой и обновления

Управление средой и обновления

AWS Elastic Beanstalk может автоматически обновлять среду Elastic Beanstalk до новейшей версии, используя обновляемые обновления платформы. Механизм постоянного развертывания обеспечивает безопасную и комфортную для конечных пользователей установку исправлений и обновлений платформы на уровне второстепенных версий. Для текущего управления можно также настроить свойства приложений, создать оповещения и включить уведомления по электронной почте через Amazon Simple Notification Service (Amazon SNS).

Масштабирование

AWS Elastic Beanstalk использует Elastic Load Balancing и Auto Scaling для автоматического масштабирования приложения в сторону увеличения или сокращения ресурсов с учетом фактических потребностей. Кроме того, использование нескольких зон доступности повышает надежность и доступность приложений, работающих одновременно в нескольких зонах доступности.

Настройка

C помощью AWS Elastic Beanstalk можно выбирать ресурсы AWS, например тип инстанса Amazon EC2 (включая спотовые инстансы), оптимально подходящие для конкретного приложения. Кроме того, сервис Elastic Beanstalk позволяет «заглянуть внутрь» приложения и сохранять полный контроль над ресурсами AWS, выделяемыми под ваше приложение. Если вы решили взять в свои руки контроль над элементами инфраструктуры, это легко сделать с помощью функций управления Elastic Beanstalk.

Соответствие требованиям

AWS Elastic Beanstalk соответствует стандартам ISO, PCI, SOC 1, SOC 2 и SOC 3, а также всем требованиям HIPAA. Это означает, что приложения на Elastic Beanstalk могут обрабатывать регулируемые финансовые данные и закрытую медицинскую информацию (PHI).

Источник

Разворачиваем API с AWS Elastic Beanstalk

В конце января мы провели очередной онлайн-интенсив по курсу «Backend-разработчик на PHP». В этот раз темой открытого урока стало создание Telegram-бота для заказа кофе в заведении и оплаты онлайн. Вебинар получился очень насыщенным, поэтому растянулся на два дня: «День 1» и «День 2». Мы же предлагаем вашему вниманию текстовую версию первого дня онлайн-интенсива. Он был посвящён знакомству с AWS Elastic Beanstalk и разворачиванию API с его помощью.

Преподаватель — Михаил Каморин, Senior Backend Developer в Skyeng.

Облачные вычисления

Использование облачных вычислений в целом и AWS в частности несёт нам следующие плюсы:

Немного поговорим про уровни абстракции:

Чтобы не быть голословными, приведём примеры по уровням абстракции:

Как вообще используются облака? Есть несколько сценариев:

Говоря об AWS, сначала упомянем некоторые составные части, которые нам понадобятся и будут использоваться под капотом.

IAM (Identity and Access Management) — это первое, с чем придётся столкнуться, когда зарегистрируетесь. IAM позволяет выполнять настройку прав доступа к аккаунту, осуществлять управление ролями, группами и пользователями.

Amazon предполагает, что мы будем следовать Best practices, хотя мы их немного вынужденно нарушим во время урока. Речь идёт о следующих практиках:

EC2 – Elastic Compute Cloud (IaaS) — веб-сервис, который предоставляет нам возможность разворачивать виртуальные машины. EC2 обеспечивает:

Тут необходимо отметить, что напрямую мы EC2 трогать не будем, так как там необходимо настраивать всё самостоятельно, начиная от окружения и заканчивая параметрами сетевого доступа. Тем не менее надо понимать, что под капотом EC2 всегда есть.

AWS Elastic Beanstalk

Elastic Beanstalk – сервис оркестрации (PaaS либо CaaS, в зависимости от того, что будете оркестрировать). Если контейнеризация — это работа с самим контейнером и его начинкой, то оркестрация — это работа с контейнерами, скажем так, на метауровне. Оркестрация — это, по сути, механизм, который позволяет нам стартовать контейнеры/виртуальные машины либо по API, либо через консоль.

Beanstalk добавляет поверх ОС слой с окружением для конкретного языка программирования, веб-сервер, контейнеризацию, набор библиотек, расширений и т. д.

Мы будем использовать PHP 7.3 с веб-сервером Apache (nginx не предоставляется, это не хорошо и не плохо, а просто факт, который нужно иметь в виду). Поскольку мы управлять этим всем не будем, то нам, в принципе, всё равно.

Установка и настройка

Что же, перейдём к практике. Первый этап — регистрация и настройка прав доступа:

Итак, у нас появился пользователь, и с этим пользователем мы будем работать дальше. На этом этапе всё.

Теперь нужно поставить саму консоль ElasticBeanstalk. Это достаточно длительный процесс, вот краткий обзор того, что нужно сделать:

Инициализация Elastic Beanstalk

Теперь нужно проделать инициализацию Elastic Beanstalk в нашем проекте. Для этого:

Создание и запуск инстанса EC2

Теперь нужно создать и запустить инстанс EC2 через Beanstalk. Для этого:

Источник

AWS Elastic Beanstalk

Просто загрузите код, а Elastic Beanstalk автоматически выполнит развертывание: выделит ресурсы, займется балансировкой нагрузки, автоматическим масштабированием и мониторингом работоспособности приложения. При этом пользователь сохраняет полный контроль над ресурсами AWS, используемыми для приложения, и в любое время может получить к ним доступ.

Дополнительная плата за Elastic Beanstalk не взимается – вы платите только за ресурсы AWS, необходимые для хранения и работы приложений.

Преимущества

Простое и быстрое развертывание

Elastic Beanstalk – это самый быстрый и простой способ развертывания приложений в AWS. Чтобы загрузить приложение, используйте Консоль управления AWS, репозиторий Git или интегрированную среду разработки (IDE), например Eclipse или Visual Studio. А Elastic Beanstalk выполнит развертывание, выделит ресурсы, обеспечит балансировку нагрузки, автоматическое масштабирование и мониторинг работоспособности приложения. За считаные минуты приложение будет готово к использованию. С вашей стороны не потребуется никакой настройки инфраструктуры или ресурсов.

Эффективность разработчиков

Elastic Beanstalk автоматически настраивает и контролирует инфраструктуру, а также управляет стеком приложения. Вам не придется тратить на это время или изучать документацию. Сервис также регулярно устанавливает последние обновления ПО и обновления безопасности платформы, на которой выполняется ваше приложение. Вы сможете сосредоточиться на написании кода. Больше не нужно настраивать и контролировать серверы, базы данных, балансировщики нагрузки, брандмауэры и сети.

Невозможно перерасти

Elastic Beanstalk автоматически масштабирует приложение в соответствии с потребностями, используя удобные настройки Auto Scaling. Например, вы можете инициировать действия Auto Scaling с помощью метрик использования ЦП. Благодаря Elastic Beanstalk ваше приложение сможет обрабатывать пиковые нагрузки или трафик, минимизируя расходы.

Полный контроль над ресурсами

Вы можете выбрать ресурсы AWS, например тип инстанса Amazon EC2, оптимальные для вашего приложения. Кроме того, сервис Elastic Beanstalk позволяет «заглянуть внутрь» приложения и сохранять полный контроль над ресурсами AWS, выделяемыми под ваше приложение. Если вы решили взять в свои руки контроль над элементами инфраструктуры, это легко сделать с помощью функций управления Elastic Beanstalk.

Источник

Перенос интернет-приложения ASP.NET в сервис AWS Elastic Beanstalk

с помощью интерактивного средства Windows Web Application Migration Assistant (WWAMA)

Обзор

Цель данного практического занятия – перенести интернет‑приложение ASP.NET в полностью управляемую среду AWS Elastic Beanstalk с помощью средства Windows Web Application Migration Assistant (WWAMA). Дополнительные сведения о средстве Windows Web Application Migration Assistant см. здесь.

Ожидаемый результат

Вы перенесете интернет-приложение ASP.NET в полностью управляемую среду AWS Elastic Beanstalk.

Предварительные требования

Вам потребуется аккаунт AWS и разрешения IAM, чтобы создать инстанс EC2, пару ключей, группу безопасности, пользователя IAM и среду Elastic Beanstalk. В данном учебном пособии мы развернем шаблон AWS CloudFormation, автоматически подготавливающий веб-сайт на инстансе EC2, который будет исходным интернет-приложением для миграции.

1. Регистрация в AWS

Шаблон CloudFormation, используемый в данном учебном пособии, запускает инстанс EC2 t2.micro. На инстансы t2.micro распространяется уровень бесплатного пользования. Если выбрать другой тип инстанса, вам будет начислена плата за использование сервиса EC2. Оценить затраты на использование сервиса EC2 можно на странице цен EC2.

2. Создание и настройка

С помощью CloudFormation запустите инстанс EC2, в котором будет размещен веб-сайт. Затем настройте необходимые разрешения IAM.

А. Запустите инстанс EC2 с помощью CloudFormation

С помощью CloudFormation запустите инстанс EC2 в регионе US-East-1.

Затем нажмите кнопку Next (Далее).

Выберите имеющуюся пару ключей или (если у вас нет ее) создайте ее. Затем нажмите кнопку Next (Далее).

На экране Configure Stack Options (Настройка параметров стека) нажмите кнопку Next (Далее). В нижней части экрана Review (Проверка) нажмите кнопку Create Stack (Создать стек).

После создания стека его состояние изменится на CREATE_COMPLETE.

Б. Создайте пользователя IAM

В расположенном слева меню навигации щелкните Users (Пользователи), а затем Add User (Добавить пользователя).

В поле User name (Имя пользователя) введите имя MigrationUser, установите флажок Programmatic access (Программный доступ) и щелкните Next:Permissions (Далее: разрешения).

Щелкните Attach existing policies directly (Прикрепить существующие политики напрямую) и в строке поиска введите текст Beanstalk, чтобы отфильтровать политики.

Установите флажки для указанных ниже политик, управляемых AWS, и щелкните Next:Tags (Далее: теги).

Щелкните Next:Review (Далее: проверка), а затем нажмите кнопку Create User (Создать пользователя).

После создания пользователя на отобразившемся экране нажмите кнопку Download CSV (Загрузить CSV-файл).

3. Вход в систему в консоли EC2 и выполнение настройки для запуска средства WWAMA

А. Перейдите в консоль EC2 и выполните вход

После входа в систему в консоли EC2 выберите инстанс WWAMA и нажмите кнопку Connect (Подключиться).

Нажмите кнопку Download Remote Desktop File (Загрузить файл удаленного рабочего стола) и сохраните RDP-файл. Затем нажмите кнопку Get Password (Получить пароль) и отправьте свой файл пары ключей, чтобы получить пароль Widows Server. Пароль отобразится в виде простого текста. Скопируйте его, так как он понадобится вам на следующем шаге.

Войдите в систему в инстансе EC2 с помощью ранее сохраненного RDP-файла и введите свой пароль.

Б. Откройте терминал PowerShell в EC2 Windows Server

Откройте терминал PowerShell от имени администратора и выполните команды, указанные в расположенном внизу справа примере, чтобы настроить данные AWS для доступа. В процессе создания пользователя MigrationUser замените значения параметров ACCESS_KEY и SECRET_ACCESS_KEY значениями, указанными в ранее загруженном CSV-файле.

В. Извлеките файлы помощника по миграции

Помощник по миграции предварительно загружен шаблоном CloudFormation и находится на диске C:\. Это файл wwama.zip.

Щелкните файл wwama.zip правой кнопкой мыши и извлеките помощник.

Г. Просмотрите веб-сайт перед переносом

Откройте веб-браузер в инстансе EC2 Windows Server и перейдите по адресу http://localhost/. Отобразится веб-сайт, который предполагается перенести с использованием помощника по миграции.

4. Запуск помощника по миграции

А. Запустите скрипт MigrateIISWebsiteToElasticBeanstalk.ps1

В ранее открытом вами терминале PowerShell запустите скрипт миграции.

Помощник предложит указать расположение вашего файла с данными для доступа. Нажмите клавишу ВВОД, чтобы пропустить это действие.

Когда будет предложено ввести имя профиля AWS, введите default.

Б. Выберите регион AWS

Укажите регион AWS, в котором вы хотите запустить свою среду Elastic Beanstalk. Пример: us-east-1. Перечень регионов AWS, в которых доступен сервис Elastic Beanstalk, см. в разделе адресов и расценок сервиса AWS Elastic Beanstalk в общих справочных материалах по AWS.

В. Выберите интернет-приложение, которое необходимо перенести

Далее помощник обнаружит все веб-сайты, работающие на вашем сервере IIS, и отобразит их, как показано в примере ниже.

Введите число 2, чтобы перенести сайт.

Г. Обновите строки подключений

Далее помощник предложит обновить выбранные выше строки подключений. Нажмите клавишу ВВОД, так как в этом приложении нет строк подключений.

Отобразится следующее сообщение:

The migration assistant didn’t find any connection strings. (Помощнику по миграции не удалось найти ни одной строки подключения).

Д. Настройте приложение Elastic Beanstalk

Далее присвойте имя своему новому приложению Elastic Beanstalk.

Когда будет предложено выбрать версию Windows Server, введите 6 и нажмите клавишу ВВОД.

Введите тип инстанса, в котором будет работать ваше приложение. Введите t2.micro. Полный перечень см. в разделе типов инстансов Amazon EC2.

Далее помощник по миграции перенесет ваше приложение в сервис Elastic Beanstalk.

По завершении миграции в интерфейсе командной строки (CLI) отобразится сообщение об успешном выполнении.

5. Переход к интернет-приложению, размещенному в сервисе Elastic Beanstalk

Теперь, когда веб-сайт успешно перенесен, убедитесь, что он работает.

А. Доступ в веб-браузере

URL-адрес можно найти в выходных данных скрипта PowerShell.

Перейдите по этому URL-адресу в веб-браузере. Должно отобразиться ваше интернет-приложение, которое теперь работает в сервисе Elastic Beanstalk.

Б. Доступ в консоли Elastic Beanstalk

Вы также можете просмотреть среду Elastic Beanstalk в консоли AWS. Убедитесь, что у вас открыта консоль для того же региона, в котором вы развернули свое приложение. Вы можете изучить доступные здесь возможности, используя расположенное слева меню.

6. Удаление ресурсов

На этом финальном шаге вы удалите все свои ресурсы.

А. Удаление приложения Elastic Beanstalk

Перейдите в консоль Elastic Beanstalk и щелкните расположенное справа меню Actions (Действия). Затем щелкните Terminate Environment (Завершить работу среды).

Б. Удаление стека CloudFormation

Перейдите в консоль CloudFormation и удалите стек CloudFormation с именем WWAMAStack, созданный в начале этого практического занятия.

Поздравляем!

Вы успешно перенесли интернет‑приложение ASP.NET в полностью управляемую среду Elastic Beanstalk с помощью средства Windows Web Application Migration Assistant (WWAMA).

Просто загрузите код, а Elastic Beanstalk автоматически выполнит развертывание: выделит ресурсы, займется балансировкой нагрузки, автоматическим масштабированием и мониторингом работоспособности приложения. При этом вы сохраняете полный контроль над ресурсами AWS, используемыми для приложения, и в любое время можете получить доступ к ним.

Дополнительные сведения см. в разделе AWS Elastic Beanstalk.

Источник

Хайлоад без хлопот. Масштабируем твой сервис с помощью Amazon Elastic Beanstalk

Содержание статьи

Ты написал свой веб-сервис. Обложил тестами, дофиксил баги, сделал последние предрелизные коммиты. Теперь нужно его где-то захостить. Конечно, можно особо не напрягаться и выложить его на обычном хостинге или VPS. Но что, если ты, сам того не зная, написал новый Instagram и завтра к тебе придет миллион юзеров? Хорошо бы сразу настроить все по уму: предусмотреть балансировку нагрузки, доставку кода, правила масштабирования. И желательно без сложностей и преждевременной оптимизации. Займемся этим!

Зачем это нужно: краткий ликбез

Как известно, у платформы AWS есть множество сервисов на все случаи жизни. Из всего многообразия сегодня нам понадобятся два наиболее популярных:

Все сервисы AWS управляются с помощью админки AWS или через API. При работе через консоль администратора алгоритм действий в нашем случае будет таким:

Выглядит довольно просто, если понимаешь логику инфраструктуры AWS. Однако на практике управлять всем этим вручную довольно неудобно. Процесс осложняется, если инстансы нужно сгруппировать в балансировщик нагрузки и включить в autoscaling-группу. Кроме того, что все это нужно просто создать и настроить, сервисами надо как-то управлять, надо их мониторить, иметь возможность быстрого масштабирования, желательно автоматического. Вот тут и приходит на помощь Elastic Beanstalk.

Что это такое

EBS — это надстройка-оркестратор над сервисами Amazon. Он поможет по заданной конфигурации быстро поднять несколько инстансов нашего приложения, базу данных, связать их с кешем, настроить балансировщик нагрузки и получить агрегированные логи. Всего несколько простых команд из CLI, и через пару минут у нас готово продакшен-окружение и настроенное приложение, которое будет само масштабироваться в зависимости от нагрузки.

Прелесть EBS в том, что он бесплатный. То есть за услуги оркестрации мы не платим ничего, оплачивается только стоимость инстансов по стандартным тарифам EC2.

Чем это отличается от Docker или оркестраторов?

Главное отличие EBS в том, что он более высокоуровневый и заточен под типовые кейсы. Если при работе с Docker тебе, скорее всего, нужно будет написать несколько докерфайлов, настроить доступы и продумать логику построения контейнеров на хосте (что не всегда так уж и просто, хотя compose сильно облегчает задачу), то EBS берет все это на себя. Все, что нужно сделать, — это загрузить исходный код приложения, выбрать стек технологий для нее (например, Ruby on Rails или Node.js) и указать команду, которой твое приложение запускается. Все остальное EBS сделает сам. К тому же в твоем распоряжении из коробки окажется вся мощь инфраструктуры Amazon с практически неограниченными ресурсами, а значит — и возможностями масштабирования.

Конечно, EBS с дочерними сервисами — это по логике работы такие же контейнеры, как и Docker. Но под капотом большая разница. Docker — это настоящие, честные изолированные контейнеры, которые могут располагаться на одном хосте — инстансе виртуальной машины. При желании ты сможешь перенести Docker-контейнеры на другой хост (с некоторым количеством телодвижений). А вот EBS — это контейнеры «более низкого уровня», здесь роль контейнера выполняет сам инстанс EC2, внутри которого может хоститься воркер, веб-сервер или реляционная база данных.

Приступаем к работе

Процесс работы с EBS довольно прост:

При обновлении приложения нужно закоммитить изменения в репозиторий приложения, после чего отправить новую версию (слепок кода после последнего сделанного коммита) в EBS. Через несколько секунд EBS доставит измененный код на все инстансы и перезапустит процессы твоего приложения.

Из чего состоит EBS-проект?

EBS-проект обычно состоит из двух основных компонентов:

Пример такого файла конфигурации (из доков AWS, но показательный):

Например, для Node.js (неймспейс aws:elasticbeanstalk:container:nodejs ) ты можешь сконфигурировать следующие параметры:

Готовим приложение

Давай создадим приложение на Node.js и задеплоим его в EBS. Приведу простейший пример приложения, которое на любой запрос будет отвечать текущей датой, полученной из PostgreSQL. Сейчас и далее предполагаем, что у тебя установлен и настроен Node.js, PostgreSQL, npm и Git.

Инициализируем новый пакет:

Добавим в app.js следующий код:

С целью экономии места из листинга намеренно вырезаны все обработчики ошибок. Тем не менее это вполне рабочее веб-приложение на Node.js и для наших учебных целей оно подойдет.

Теперь, когда ты запустишь скрипт командой node app.js (предполагаем, что у тебя установлен Node и модуль pg ), в ответ на http://localhost:3000 придет что-то вроде

Окей, Гугл, пришло время закоммитить наш код в репозиторий. Забегая вперед, сразу скажу, что код в EBS можно доставлять двумя способами:

Пример бакета с множеством версий приложения

Xakep #200. Тайная жизнь Windows 10

Итак, создаем репозиторий:

Коммитим код в репозиторий:

Теперь давай разбираться с самим EBS.

Ставим EB CLI

EB CLI — это набор консольных утилит для работы с EBS. Он поддерживается для всех основных ОС: Windows, Linux и OS X. На сегодняшний день официально Amazon предлагает только один вариант установки EBS — с помощью пакетного менеджера pip для Python. Однако для OS X доступна еще и формула для Homebrew ( brew install awsebcli ).

Кстати, еще полгода назад была возможность скачать исходники EBS на Python, самостоятельно положить в нужную директорию и создать алиасы к главному скрипту EBS. Но сейчас давай пойдем официальным путем.

Если ты на Windows, тебе, возможно, понадобится скачать и установить сам Python, а также pip. Детальные инструкции для твоей ОС можно найти здесь.

Проверяем установленную версию EB CLI:

Все хорошо, идем дальше.

Инициализируем EBS-проект

Перед тем как уже выложить наш проект в EBS, открой консоль EBS и посмотри, как выглядит админка этого сервиса.

«Чистая» админка EBS без созданных окружений и приложений

Возможно, ты обратил внимание на кнопки Create new application и форму выбора платформы. Все верно, EBS предоставляет возможность быстрого запуска тестового сервиса на базе нужной платформы с помощью GUI. К сожалению, такой метод не очень удобен и немного противоречит правильному workflow при работе с EBS, поэтому мы будем делать все из консоли, чтобы лучше понять принцип.

Итак, переходим в директорию нашего репозитория и инициализируем новый проект:

EBS начнет задавать вопросы о конфигурации проекта. Пройдемся быстро по ним.

Инстансы EBS — это на самом деле инстансы EC2. Как и любой сервис AWS, они могут физически располагаться в одном из девяти дата-центров AWS. Выбирай тот, который географически ближе к твоей аудитории, чтобы пинг был меньше. Я обычно использую или Франкфурт, или Ирландию.

EBS — это сервис AWS, значит, авторизация к нему происходит на основании общих механизмов, принятых в инфраструктуре AWS. Если конкретнее, ты должен создать ключ и секретный ключ, у которых будут права на работу с частью сервисов, нужной EBS. В нашем случае это EC2, LoadBalancers, S3 и управление ролями EC2.

Долго останавливаться на этой теме не буду, разве что подчеркну, что с точки зрения безопасности правильно создать IAM-юзера, наделить его минимально необходимым правами, нужными для EBS, и использовать его ключики. Сделать это можно здесь.

Предложим, ты создал юзера, приаттачил к нему необходимые политики (права) и получил следующие ключи:

EBS попросит ввести имя для твоего приложения. Оставляем myapp.

В нашем случае EBS угадал стек технологий, на которых работает наше приложение. Если по каким-то причинам этого не произошло, ответь n и выбери нужный образ, например Ruby on Rails или Django.

Отлично, проект создан! Убедимся в этом:

Пока наш файл глобального конфига EBS не очень информативен. Он не содержит самого главного — информации об окружении, в котором будет исполняться наше приложение:

Давай это исправим и создадим окружение:

Опять несколько вопросов:

Сейчас начнется долгий процесс построения рабочего окружения, в котором будет запускаться наше приложение. В процессе создания консоль AWS покажет одно созданное окружение в статусе Pending:

Созданное окружение, еще без инстансов в статусе Pending

Если ты получаешь ошибку вида:

это значит, что ты не приаттачил к своему IAM-юзеру права для создания EC2-ролей. Подробнее читай тут.

Если все прошло успешно, ты получишь сообщение о том, что окружение создано:

Давай наконец посмотрим на наше приложение в браузере! Пишем:

Открывается браузер, и мы видим.

Что-то пошло не так

Кажется, что-то задеплоилось не так — приложение не работает, а nginx отдает 502. Судя по тому, что мы получаем 502 от nginx, а не простой тайм-аут, наш первый инстанс действительно работает и его nginx пытается получить ответ от нашего приложения. И в этот момент случается что-то нехорошее. Давай разбираться.

Что тут могло пойти ТАК?

Конечно же, внимательный читатель заметит, что в самом начале при создании нашего приложения мы обращались к базе данных со строкой соединения

Это работало на нашей локальной машине (192.168.59.103 — адрес моего Docker-контейнера с PostgreSQL). Но в AWS его нет. Соответственно, наше приложение пытается присоединиться к БД, получает NOT FOUND и отдает ошибку! Отсюда и 502, который показывает нам nginx, — он просто не получает валидного ответа от Node.js-приложения при попытке проксировать клиентский запрос.

Для проверки нашей догадки воспользуемся встроенным механизмом получения логов инстансов. Перейди в директорию приложения и выполни команду

Ответом будет длиннющая простыня логов. Кстати, иногда получать логи из консоли не очень удобно, поэтому можно зайти в опции твоего окружения и запросить нужный объем через GUI:

Запрашиваем логи через GUI в настройках нашего окружения

Спасаем положение

Создаем БД

Давай создадим БД, с которой и будет работать наше приложение. Для этого воспользуемся сервисом Amazon Relational Database Service, далее — RDS.

RDS — сервис для виртуализации реляционных БД в AWS

Переходи в админку RDS и создавай новую БД на движке PostgreSQL. Особо долго останавливаться не буду, иначе эта статья никогда не закончится. Подчеркну только несколько моментов.

Читай, что предлагает тебе AWS. Например, если, не думая, оставить опцию «use Multi-AZ Deployment and Provisioned IOPS Storage as defaults while creating this instance», можно нехило удивиться счету, который выставит тебе AWS в конце месяца. Для нашего тестового приложения вся эта избыточная надежность совсем не нужна.

Выставляем опции инстанса и настройки PG

К следующему шагу нужно отнестись особенно внимательно.

Publicly Accessible. Выставляй No, нам не нужно, чтобы всякие роботы стучались в нашу БД. Сами мы будем получать к ней доступ по внутреннему адресу через амазоновскую private network.

VPC Security Group(s). Доступы к сервисам в AWS предоставляются на основе так называемых Securtiy Groups. Если кратко, это набор правил для файрвола для входящего и исходящего трафика. Нам нужно запретить любой исходящий трафик с нашей БД, но при этом разрешить входящий трафик с любого инстанса из всего пула нашего балансировщика нагрузки, который был автоматически создан вместе с нашим окружением.

Почему это важно? Дело в том, что сейчас у нашего балансировщика нагрузки всего один инстанс и мы можем указать его внутренний IP в качестве разрешенного для доступа к нашей БД (TCP 5432, 5432 — порт Постгреса). Однако, когда трафик вырастет, балансировщик нагрузки создаст еще один инстанс и начнет распределять трафик между ними двумя, у нового инстанса уже не будет доступа к БД, так как его IP нет в списке разрешенных на файрволе БД.

Решение проблемы — создать отдельную Security-группу для нашей БД и указать в качестве разрешенного источника трафика не какой-то конкретный инстанс, а сам балансировщик нагрузки (по его названию).

Создаем секьюрити-группу с нужным источником трафика

Теперь возвращаемся к созданию RDS и выбираем нужную нам секьюрити-группу:

Задаем для RDS созданную секьюрити-группу

Ура, наконец-то наша RDS создана и готова к работе.

Наша созданная RDS с правильно выставленными правилами для входных соединений

Пробуем подружить окружение с нашей БД

Если использовать первый вариант, можно довольно быстро все починить, однако это не наш метод :). GUI-конфигуратор, безусловно, удобен, и на самом деле он предоставляет доступ к большинству опций, которые задаются через переменные и неймспейсы конфигов. Однако он не дает необходимого уровня автоматизации при повторном деплое приложения, так что воспользуемся первым, чтобы лучше понять процесс.

В разделе Software Configuration можно просто добавить все нужные нам переменные окружения

Теперь необходимо научить наше приложение коннектиться к БД по предоставленным ему переменным окружения. Что-то пояснять здесь смысла нет, просто приведу код итогового приложения:

Обновляем приложение

Теперь самое время запушить обновления нашего приложения в EBS:

Как мы видим, создан новый «срез» кода с меткой «f7a9». Он и отправляет на все инстансы приложения в нашем окружении, и через пару минут окружение будет обновлено. По завершении обновления если мы зайдем в настройки нашего окружения, то увидим, что наши скрипты сработали и переменные окружения подцепились.

Окружение обновилось с учетом добавленных конфигов

Естественно, наше приложение будет по-прежнему отдавать 502, так как значения переменных дефолтные. Давай забьем настоящие. Адрес БД можно получить в свойствах БД в консоли RDS. Он будет примерно таким:

Добавляем «настоящие» значения в переменные окружения

После чего применим изменения, и окружение начнет пересборку.

Пересборка окружения после применения новых значений переменных окружения

Немного погодя идем по заветному URL и.

Домашнее задание

Вот мы и задеплоили наше первое приложение в EBS. Со стороны процесс может показаться довольно сложным, но, если чуть-чуть въехать в AWS, во всех шагах появляется логика.

Мы не коснулись темы установки правил масштабирования в зависимости от трафика / количества подключений или запуска cron-задач на leader_only. Все это местами с трудом, но гуглится, а статья получилась и так гигантская :). Если есть вопросы по этим темам, пиши на rusanen@glc.ru. Буду рад помочь. Удачи!

Илья Русанен

Главный редактор ][, занимаюсь разработкой и безопасностью

Источник