В конце января мы провели очередной онлайн-интенсив по курсу «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-бота для заказа кофе в заведении и оплаты онлайн: