В конце января мы провели очередной онлайн-интенсив по курсу «Backend-разработчик на PHP». В этот раз темой открытого урока стало создание Telegram-бота для заказа кофе в заведении и оплаты онлайн. Вебинар получился очень насыщенным, поэтому растянулся на два дня: «День 1» и «День 2». Мы же предлагаем вашему вниманию текстовую версию первого дня онлайн-интенсива. Он был посвящён знакомству с AWS Elastic Beanstalk и разворачиванию API с его помощью.
Преподаватель — Михаил Каморин, Senior Backend Developer в Skyeng.
Облачные вычисления
Использование облачных вычислений в целом и AWS в частности несёт нам следующие плюсы:
- Удобный сетевой доступ по требованию. Мы можем подключиться в любой момент 365 дней в году в режиме 24/7.
- Общий фонд конфигурируемых вычислительных ресурсов. Облачные вычисления позволяют нам пользоваться неким общим фондом вычислительных ресурсов, которые значительно больше, чем ресурсы одной машины, если сравнивать с приватным сервером.
- Оперативное предоставление и освобождение. Мы можем в сжатые сроки получить дополнительные ресурсы, если в этом возникнет необходимость. И так же быстро освободить эти ресурсы, как только они станут не нужны.
- Минимальные эксплуатационные затраты. В зависимости от уровня абстракции требуется разный уровень финансовых вложений, но он, как правило, минимален.
Какие проблемы мы решаем:
- Самообслуживание. Когда мы общаемся с обычным провайдером тех же самых VPS-серверов, мы пишем письмо, просим выделить необходимые ресурсы и т. п. В ответ нам предлагают тарифы и варианты конфигурации. Мы выбираем, оплачиваем и прочее. В AWS всё гораздо проще: карточка сразу привязана, мы сами выбираем окружение и сами всё запускаем с учётом своих потребностей. Речь идёт о полном самообслуживании, что очень удобно.
- Хостинг. Естественно, для того, чтобы выполнять наш код на удалённой машине, мы получаем необходимый хостинг. В принципе, эту проблему решают не только облака.
- Конфигурируемый пул ресурсов. Конкретный Telegram-бот, конечно, много ресурсов не потребует, но бывает, что речь идёт о более сложных бизнес-задачах или росте проекта.
- Эластичность. Что тут подразумевается? Когда у нас есть выраженная сезонность (пусть даже в рамках дня), когда мы знаем время наступления прайм-тайм и пиковых нагрузок, мы можем сэкономить. Понятно, что если мы будем пользоваться вычислительными ресурсами, покрывающими пиковые нагрузки, в режиме 24/7, мы будем переплачивать. Эластичность нам позволяет увеличивать вычислительные ресурсы незадолго до прайм-тайм и освобождать их сразу после его завершения. Тем самым мы существенно сокращаем стоимость обслуживания своей инфраструктуры.
- Измеряемость. Мы видим количество вызовов наших функций (в случае, например, AWS Lambda), мы видим ресурсы (сколько виртуальных машин работают, какова нагрузка), то есть у нас есть достаточно продвинутый и точный мониторинг.
Уровни абстракции
Немного поговорим про уровни абстракции:
- В традиционном On-Premises мы обеспечиваем всё, начиная с закупки железа, заканчивая конфигурацией приложения, которое запускаем.
- В IaaS нам предоставляется некое железо и гипервизор. Дальше мы можем самостоятельно выбирать и устанавливать требуемую ОС, окружение, можем делать масштабирование и т. п.
- CaaS. Уровень Container as a Service выделился достаточно недавно с развитием контейнеризации в целом и докеризации в частности. В случае с CaaS от нас не требуется выполнять настройки операционной системы — нам её уже предоставляют из некоторого набора преднастроенных ОС.
- PaaS. Достаточно старый уровень абстракции, который появился задолго до того, как выделился CaaS. На этом уровне нам также предоставляют runtime-окружение, то есть, по сути, это классический хостинг. Допустим, нам предоставляют какую-нибудь версию PHP на выбор с набором расширений. На уровне этого PHP мы можем делать, что угодно: ставить балансировщики, писать свой код и т. д.
- FaaS. Один из примеров — тот же AWS Lambda. В этом случае у нас масштабирование уже обеспечивается средствами того облачного провайдера, который предоставляет функционал, и у нас не возникают проблемы, когда приложение начинает расти. Та же AWS Lambda может поддерживать тысячи инстансов без какого-либо требования к нам по настройкам (только платите).
- SaaS. В этом случае нам доступна только та возможность конфигурации, которую программисты заложили в софт, которым мы пользуемся.
Чтобы не быть голословными, приведём примеры по уровням абстракции:
- IaaS – Amazon Elastic Compute Cloud (EC2) — с ним сегодня и поработаем;
- CaaS – Amazon Elastic Container Service (ECS);
- PaaS – Google App Engine;
- FaaS – AWS Lambda;
- SaaS – Gmail.
Совместное использование ресурсов
Как вообще используются облака? Есть несколько сценариев:
- Приватное облако. Вся инфраструктура находится в дата-центре и принадлежит компании (принадлежит в том смысле, что никто кроме нас на этих ресурсах работать не может).
- Публичное облако. Вся инфраструктура находится в облаке. Мы знаем только то, что у нас есть сервис выбранного уровня, который нам предоставляется. Мы не знаем, каким образом, он устроен на нижестоящих уровнях. Мы не владеем нашими данными в полной мере хотя бы потому, что если мы захотим, чтобы наши данные удалили, у нас нет никаких гарантий, что это произойдёт. Мало того, если провайдера взломают, высока вероятность потери конфиденциальной информации. Да, эти риски есть и с приватным облаком, но там речь идёт о целенаправленном взломе именно ваших ресурсов, а тут можно попасть под раздачу, что называется, случайно и за компанию.
- Гибридное облако. Тут возможны варианты:
- в штатном режиме используется своя инфраструктура, на пиковых нагрузках подключается облако;
- в облако выносятся отчуждаемые от нашего софта вычисления;
- в штатном режиме используется облако, в экстренных ситуациях происходит переключение на свою инфраструктуру.
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 не предоставляется, это не хорошо и не плохо, а просто факт, который нужно иметь в виду). Поскольку мы управлять этим всем не будем, то нам, в принципе, всё равно.
Установка и настройка
Что же, перейдём к практике. Первый этап — регистрация и настройка прав доступа:
- регистрируемся на amazon.com. Берём бесплатный аккаунт с минимальным набором машинок;
- логинимся. Т. к. Elastic Beanstalk по умолчанию предлагает регион Oregon, выбираем Oregon и в AWS Management Console:
- заходим в службу IAM через консоль (пишем iam в строке поиска):
- там видим dashboard, на котором выполняем определённые действия
- для работы с Elastic Beanstalk создаём и настраиваем нового пользователя (только программный доступ):
- добавляем группу с правами AWSElasticBeanstalkFullAccess:
- скачиваем реквизиты доступа и сохраняем их где-нибудь в надёжном месте. Если файл потеряете, пользователя придётся пересоздавать.
Итак, у нас появился пользователь, и с этим пользователем мы будем работать дальше. На этом этапе всё.
EB CLI
Теперь нужно поставить саму консоль ElasticBeanstalk. Это достаточно длительный процесс, вот краткий обзор того, что нужно сделать:
- Клонируем репозиторий https://github.com/aws/aws-elastic-beanstalk-cli-setup.
- Внимательно читаем readme и выполняем необходимые действия для вашей ОС (потенциальные проблемы также описаны в readme).
- После установки не забудьте экспортировать переменные с путями.
- Проверяем, что всё работает, командой
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-бота для заказа кофе в заведении и оплаты онлайн:
