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



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

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


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


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

    1. Удобный сетевой доступ по требованию. Мы можем подключиться в любой момент 365 дней в году в режиме 24/7.
    2. Общий фонд конфигурируемых вычислительных ресурсов. Облачные вычисления позволяют нам пользоваться неким общим фондом вычислительных ресурсов, которые значительно больше, чем ресурсы одной машины, если сравнивать с приватным сервером.
    3. Оперативное предоставление и освобождение. Мы можем в сжатые сроки получить дополнительные ресурсы, если в этом возникнет необходимость. И так же быстро освободить эти ресурсы, как только они станут не нужны.
    4. Минимальные эксплуатационные затраты. В зависимости от уровня абстракции требуется разный уровень финансовых вложений, но он, как правило, минимален.

    Какие проблемы мы решаем:

    1. Самообслуживание. Когда мы общаемся с обычным провайдером тех же самых VPS-серверов, мы пишем письмо, просим выделить необходимые ресурсы и т. п. В ответ нам предлагают тарифы и варианты конфигурации. Мы выбираем, оплачиваем и прочее. В AWS всё гораздо проще: карточка сразу привязана, мы сами выбираем окружение и сами всё запускаем с учётом своих потребностей. Речь идёт о полном самообслуживании, что очень удобно.
    2. Хостинг. Естественно, для того, чтобы выполнять наш код на удалённой машине, мы получаем необходимый хостинг. В принципе, эту проблему решают не только облака.
    3. Конфигурируемый пул ресурсов. Конкретный Telegram-бот, конечно, много ресурсов не потребует, но бывает, что речь идёт о более сложных бизнес-задачах или росте проекта.
    4. Эластичность. Что тут подразумевается? Когда у нас есть выраженная сезонность (пусть даже в рамках дня), когда мы знаем время наступления прайм-тайм и пиковых нагрузок, мы можем сэкономить. Понятно, что если мы будем пользоваться вычислительными ресурсами, покрывающими пиковые нагрузки, в режиме 24/7, мы будем переплачивать. Эластичность нам позволяет увеличивать вычислительные ресурсы незадолго до прайм-тайм и освобождать их сразу после его завершения. Тем самым мы существенно сокращаем стоимость обслуживания своей инфраструктуры.
    5. Измеряемость. Мы видим количество вызовов наших функций (в случае, например, AWS Lambda), мы видим ресурсы (сколько виртуальных машин работают, какова нагрузка), то есть у нас есть достаточно продвинутый и точный мониторинг.

    Уровни абстракции

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

    1. В традиционном On-Premises мы обеспечиваем всё, начиная с закупки железа, заканчивая конфигурацией приложения, которое запускаем.
    2. В IaaS нам предоставляется некое железо и гипервизор. Дальше мы можем самостоятельно выбирать и устанавливать требуемую ОС, окружение, можем делать масштабирование и т. п.
    3. CaaS. Уровень Container as a Service выделился достаточно недавно с развитием контейнеризации в целом и докеризации в частности. В случае с CaaS от нас не требуется выполнять настройки операционной системы — нам её уже предоставляют из некоторого набора преднастроенных ОС.
    4. PaaS. Достаточно старый уровень абстракции, который появился задолго до того, как выделился CaaS. На этом уровне нам также предоставляют runtime-окружение, то есть, по сути, это классический хостинг. Допустим, нам предоставляют какую-нибудь версию PHP на выбор с набором расширений. На уровне этого PHP мы можем делать, что угодно: ставить балансировщики, писать свой код и т. д.
    5. FaaS. Один из примеров — тот же AWS Lambda. В этом случае у нас масштабирование уже обеспечивается средствами того облачного провайдера, который предоставляет функционал, и у нас не возникают проблемы, когда приложение начинает расти. Та же AWS Lambda может поддерживать тысячи инстансов без какого-либо требования к нам по настройкам (только платите).
    6. SaaS. В этом случае нам доступна только та возможность конфигурации, которую программисты заложили в софт, которым мы пользуемся.



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

    • IaaS – Amazon Elastic Compute Cloud (EC2) — с ним сегодня и поработаем;
    • CaaS – Amazon Elastic Container Service (ECS);
    • PaaS – Google App Engine;
    • FaaS – AWS Lambda;
    • SaaS – Gmail.

    Совместное использование ресурсов

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

    1. Приватное облако. Вся инфраструктура находится в дата-центре и принадлежит компании (принадлежит в том смысле, что никто кроме нас на этих ресурсах работать не может).
    2. Публичное облако. Вся инфраструктура находится в облаке. Мы знаем только то, что у нас есть сервис выбранного уровня, который нам предоставляется. Мы не знаем, каким образом, он устроен на нижестоящих уровнях. Мы не владеем нашими данными в полной мере хотя бы потому, что если мы захотим, чтобы наши данные удалили, у нас нет никаких гарантий, что это произойдёт. Мало того, если провайдера взломают, высока вероятность потери конфиденциальной информации. Да, эти риски есть и с приватным облаком, но там речь идёт о целенаправленном взломе именно ваших ресурсов, а тут можно попасть под раздачу, что называется, случайно и за компанию.
    3. Гибридное облако. Тут возможны варианты:

    • в штатном режиме используется своя инфраструктура, на пиковых нагрузках подключается облако;
    • в облако выносятся отчуждаемые от нашего софта вычисления;
    • в штатном режиме используется облако, в экстренных ситуациях происходит переключение на свою инфраструктуру.

    AWS


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

    AWS IAM

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

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

    • для каждого физического человека — отдельный пользователь;
    • для каждого приложения — отдельная роль;
    • доступы, которые будут выданы, не коммитим, не шарим, в коде не используем;
    • никогда не используем root-аккаунт, кроме первоначальной настройки. Если вы случайно где-то засветите пароль, с вашего root-аккаунта кто-то сможет прикупить виртуальных машин. И даже если вы настроите все необходимые alert’ы, на тысячу-полторы долларов можно попасть очень быстро.

    AWS EC2

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

    • управление вычислительными мощностями, которые мы будем использовать (когда регистрируешь бесплатный аккаунт, предоставляется доступ только к одному типу инстансов);
    • набор Amazon Machine Image (AMI) – образов виртуальной машины с приложениями, библиотеками и т. п.;

    Также обычно для работы с EC2 потребуется использование Amazon S3 (Simple Storage Service) – файлового хранилища.

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

    AWS Elastic Beanstalk

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

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

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

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


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

    1. регистрируемся на amazon.com. Берём бесплатный аккаунт с минимальным набором машинок;
    2. логинимся. Т. к. Elastic Beanstalk по умолчанию предлагает регион Oregon, выбираем Oregon и в AWS Management Console:
    3. заходим в службу IAM через консоль (пишем iam в строке поиска):
    4. там видим dashboard, на котором выполняем определённые действия

    5. для работы с Elastic Beanstalk создаём и настраиваем нового пользователя (только программный доступ):


    6. добавляем группу с правами AWSElasticBeanstalkFullAccess:
    7. скачиваем реквизиты доступа и сохраняем их где-нибудь в надёжном месте. Если файл потеряете, пользователя придётся пересоздавать.




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

    EB CLI

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

    1. Клонируем репозиторий https://github.com/aws/aws-elastic-beanstalk-cli-setup.
    2. Внимательно читаем readme и выполняем необходимые действия для вашей ОС (потенциальные проблемы также описаны в readme).
    3. После установки не забудьте экспортировать переменные с путями.
    4. Проверяем, что всё работает, командой eb –version.



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

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

    • распаковываем архив с исходным кодом;
    • выполняем composer install;
    • выполняем eb init;
    • выбираем регион (по умолчанию это Oregon) и указываем реквизиты доступа из скачанного файла;
    • указываем имя приложения, язык программирования PHP и версию 7.3.

    При этом обратите внимание, что мы не будем использовать CodeCommit и ssh-доступ.

    После инициализации в приложении появится папка .elasticbeanstalk, внутри которой будет файл с конфигурацией.



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

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

    • выполняем eb create;
    • указываем имя окружения, DNS CNAME, выбираем load balancer (application);
    • отказываемся от Spot Fleet (эластичность под нагрузкой);
    • проверяем статус eb status / eb health;
    • пытаемся открыть сайт eb open.

    Как ни странно, но мы сталкиваемся с ошибкой 403. Что могло пойти не так? Поскольку, наше приложение на Laravel, то точка входа расположена в директории /public, а EB ожидает по умолчанию точку входа в корневом каталоге.



    Исправление конфигурации

    Следующий этап — исправление конфигурации:

    • в консоли заходим в Elastic Beanstalk;
    • выбираем наше приложение и заходим в Configuration;
    • в разделе Software нажимаем кнопку Modify;
    • устанавливаем Document root в /public;
    • нажимаем Apply;
    • проверяем работоспособность (/api/v1/goods).

    Настройка health check

    Собственно говоря, осталось настроить health check. Для этого:

    • заходим в консоли в Elastic Beanstalk;
    • выбираем наше приложение и заходим в Configuration;
    • в разделе Load Balancer нажимаем кнопку Modify;
    • в разделе Processes выбираем default и выбираем действие Edit;
    • указываем Path /api/v1/goods и HTTP code 200 в разделе Health Check;
    • нажимаем Save и Apply.

    Далее обсудили мониторинг и первый день онлайн-интенсива подошёл к концу. Если эта тема вам интересна, лучше пересмотрите урок полностью и повторите все шаги за преподавателем. Кроме того, рекомендуется также обратить внимание и на продолжение. Напомним, что результатом 2-дневного онлайн-интенсива стало создание Telegram-бота для заказа кофе в заведении и оплаты онлайн:

    OTUS. Онлайн-образование
    Цифровые навыки от ведущих экспертов

    Похожие публикации

    Комментарии 1

      0
      клевая статья)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое