Перейти без сервера!
В этой статье продолжается обзор различных способов использования стека AWS для развертывания приложения Java/Kotlin в облаке без необходимости развертывания инфраструктуры. В предыдущей статье я рассказывал об AWS Fargate — и это оказалось довольно дорогим и, возможно, не лучшим способом запуска постоянно включенного приложения. Сегодня мы рассмотрим еще один вариант под названием AWS App Runner.
«AWS App Runner — это полностью управляемый сервис, который позволяет разработчикам быстро развертывать контейнерные веб-приложения и API в любом масштабе и без необходимости иметь опыт работы с инфраструктурой. Начните с исходного кода или образа контейнера. App Runner автоматически создает и развертывает веб-приложение и балансирует трафик с помощью шифрования. App Runner также автоматически масштабируется вверх или вниз в соответствии с вашими потребностями в трафике». — aws.amazon.com
Судя по моему опыту, App Runner не слишком известен. Многие мои знакомые, которые используют разные сервисы AWS для своей работы, даже не слышали об этом. Честно говоря, я тоже не знал, пока кто-то недавно не указал мне на это, когда я искал способы развернуть Котлинк для нашей команды.
Но давайте начнем с самого начала
В этой статье я буду развертывать приложение Kotlink, которое представляет собой инструмент повышения производительности, похожий на средство сокращения URL-адресов, но на стероидах. С помощью Kotlink вы можете установить плагин для браузера, и он предложит вам открыть ссылки на основе введенных вами коротких ключевых слов. Это то же приложение, которое я использовал в предыдущем примере, поэтому я многое пропущу. вещей, раскрытых в первой статье, а именно предварительных условий и конфигурации приложения. Они охватывают приложение OAuth, доменное имя и базу данных, и я просто предполагаю, что мы повторно используем их из предыдущей итерации.
Создание службы
Итак, давайте перейдем непосредственно к созданию сервиса. Вы легко найдете App Runner в списке сервисов (в отличие от Fargate, который отображается как Elastic Container Service).
И когда вы выбираете его, вы можете использовать кнопку Create service для чего? Да, создайте сервис!
Ой! Но у нас есть образ Docker, размещенный в хабе Docker, а не в Amazon ECR. И вообще, что такое Amazon ECR?
Создание реестра
«Amazon ECR — это полностью управляемый реестр контейнеров, предлагающий высокопроизводительный хостинг, поэтому вы можете надежно развертывать образы приложений и артефакты в любом месте». — aws.amazon.com
Итак, это просто еще один способ размещения образов контейнеров. Это не бесплатно, вы платите за хранилище, но оно включает в себя некоторое количество бесплатного уровня, которого может быть достаточно для целей разработчика. Но как нам получить образ в такой реестр?
Прежде всего, нам нужно создать реестр. Давайте пока оставим этот экран и перейдем к Amazon ECR.
Используйте кнопку Create repository, и вы увидите такой экран:
Итак, что это? Что ж, в моем случае я использую образ, который уже находится в общедоступном реестре (в hub.docker.com) и, следовательно, доступен для всех, поэтому я без колебаний выставляю его и из моего реестра AWS. Сделаем публичный.
По сути, реестру нужно имя; остальное опционально. Вы можете загрузить логотип, указать краткое и подробное описание, дать инструкции по использованию. И затем, у вас есть реестр. Вот код:
Чтобы поместить образ в этот реестр, нам нужно извлечь его, перепометить его именем реестра и отправить. Но сначала вам нужно использовать команду aws get-login-password как описано здесь для аутентификации в реестре AWS.
Теперь, когда у нас есть образ в реестре, вернемся к созданию сервиса.
Вернуться к созданию службы
Я выбрал ручное развертывание, но вы можете сделать его автоматическим, и тогда App Runner будет повторно развертывать службу каждый раз, когда будет отправлен новый образ с этим тегом. Как правило, это то, что вы хотели бы. В моем случае сервис состоит из двух частей — серверной части и пользовательского интерфейса плагина для браузера, поэтому я предпочитаю ручное развертывание, чтобы всегда иметь возможность координировать, чтобы у меня не было несовместимых версий.
Для сервиса настраиваем свои настройки — имя, ресурсы, переменные окружения.
App Runner также может управлять автоматическим масштабированием за вас, но я не хочу нести дополнительные расходы, поэтому хочу всегда использовать один экземпляр. Для приложения, которое не имеет большой нагрузки, этого должно быть достаточно.
Настройки проверки работоспособности практически такие же, как и у Фаргейта. Но не хватает одной мелочи. Читайте дальше — мы обнаружим это достаточно скоро. Давайте наконец создадим этот сервис!
После того, как вы закончите создание службы, она начнет загружаться. На данный момент все вроде бы в порядке. А потом…
… это не удалось.
Не совсем то, что мы ожидали, да. Мы можем проверить журналы приложений — ссылка на них есть на вкладке Logs.
Однако журналы просто показывают, что приложение запускается нормально… а затем закрывается без каких-либо ошибок. Но если бы не было ошибок, что могло бы это сделать?
Помните, я сказал, что в параметрах проверки здоровья не хватает одной вещи по сравнению с теми, которые мы установили для Фаргейта?
Фактическая команда проверки или путь проверки. KotLink — это приложение SpringBoot, и поэтому у него есть определенные конечные точки управления. Конфигурация Fargate позволяет указать путь для проверки, а App Runner — нет. Но… параметр Path описан прямо здесь, в документации по настройке проверки работоспособности! Значит, он существует, верно?
«Путь
URL-адрес, на который App Runner отправляет HTTP-запросы проверки работоспособности. Применимо только к проверкам HTTP». — aws.amazon.com
Верно. К сожалению, по какой-то причине эта опция не представлена в пользовательском интерфейсе консоли AWS. Но он существует, и мы можем указать его — через интерфейс командной строки AWS!
Когда вы проверите команды CLI Создать сервис или Обновить сервис, вы увидите, что полезная нагрузка для них довольно сложная, и, возможно, вы действительно не хотите создавать ее с нуля. Но поскольку у нас уже есть созданный сервис, мы можем попытаться получить существующее определение из интерфейса командной строки AWS, немного исправить его, а затем выполнить команду обновления!
Иногда я думаю, что я великолепен. Обычно именно тогда все начинает ломаться, и я понимаю, насколько ошибочным было это предположение.
Итак, запустим команду describe-service:
aws apprunner describe-service — service-arn arn:aws:apprunner:us-east-1:973520824978:service/KotLink/c22330b171d24c3e9956a14fdd8cf218 > runner.json
А потом загляните в наш runner.json!
Итак, можем ли мы просто изменить проверку работоспособности на что-то вроде этого:
А потом дать команду на обновление?
Даааа… вроде. (Именно это я имел в виду, когда говорил, что не так уж и хорош). Мне потребовалось довольно много попыток, потому что оказалось, что полезная нагрузка обновления имеет немного другую структуру, поэтому мне пришлось удалить лишнюю вложенность, очистить несколько параметров, которые были доступны только для чтения, и т. д. Затем мне также пришлось немного погуглить, чтобы поищите, как передать файл в качестве полезной нагрузки в интерфейс командной строки AWS, потому что интуитивно я попытался дать ему что-то вроде @filename.json, что является общепринятым способом сделать это для других инструментов на основе консоли (например, curl). Но у AWS свои пути, поэтому команда, которую я получил, выглядела так:
aws apprunner update-service --cli-input-json file://runner.json
И полезная нагрузка для него:
Когда вы обновляете службу, App Runner повторно развертывает ее, и о чудо.
Успех!
Работает. Работает! Это оно? Ну да и нет. Хорошо, что App Runner выделит вам домен. Это хорошо, потому что вы можете напрямую подключиться к нему. Но минус в том, что это похоже на тарабарщину. Это будет примерно так:
https://sd4klg54jie.us-east-1.awsapprunner.com/
(Это не настоящий, но вы поняли идею). Но мы уже зарегистрировали красивый и легко запоминающийся домен для сервиса — kotlink.click! Итак, как связать это сейчас?
В документации по App Runner есть раздел, в котором объясняется, как это сделать. Итак, мы переходим на вкладку Custom domains в пользовательском интерфейсе App Runner и нажимаем Link domain.
И тогда у нас есть настройки, необходимые для настройки DNS.
Так. Давайте перейдем в нашу зону хостинга на Route 53 и попробуем добавить новую запись CNAME для нашего домена!
Барабанная дробь…
Что теперь?
И мы уперлись в стену.
Похоже, что запись CNAME не может быть привязана к домену вершины (верхнего уровня). Основываясь на этой ветке Reddit, автор темы также пытался (и не смог) использовать www для поддомена, надеясь, что это сработает (спойлер: это не сработало).
А как же запись ALIAS? На GitHub есть открытый запрос на добавление App Runner в качестве опции для записи ALIAS — но сейчас там такой опции нет.
Итак, где мы находимся?
На этом этапе служба развернута и имеет конечную точку, к которой можно получить доступ извне. Итак, это (частичный) успех. Однако у нас есть этот красивый и блестящий домен, который нельзя связать. Мы ничего не можем сделать?
Вариант 1 — создать поддомен
Если вы повторите описанную выше настройку, но вместо этого используете поддомен (я решил назвать его app.kotlink.click), то вы можете использовать данные, предоставленные мастеромLink custom domain, для создания трех записей CNAME в вашей зоне хостинга: одну для самого домена App Runner, две для записи проверки сертификата. Это работает, хотя вашим пользователям нужно будет ввести четыре дополнительных символа.
Вариант 2 — использовать как есть
Всегда есть возможность просто использовать домен App Runner по умолчанию, каким бы уродливым он ни был. Зависит от вашего варианта использования. Если это просто серверная часть какого-то веб-приложения, и единственное место, где вам нужно указать его, — это конфигурация приложения, так что на самом деле это не ориентировано на пользователя, то зачем беспокоиться? Но если сложно использовать красивое доменное имя, то этот вариант не для вас.
Вариант 3 — зарегистрировать домен у другого провайдера
Да, для этого вам придется покинуть безопасные и хорошо нанесенные на карту воды AWS и отправиться в неизвестность. Но могут быть провайдеры, которые предлагают более гибкую настройку, которая позволит вам указать нужный вам псевдоним. Однако, поскольку мое приложение очень мало взаимодействует с пользователем (пользователю нужно указать этот URL-адрес только один раз в конфигурации плагина браузера), я выбрал первый вариант.
Привет. Но как насчет стоимости?
В статье Фаргейта я упомянул, что стоимость услуги была довольно заоблачной для чего-то такого маленького. Улучшил ли App Runner ситуацию?
Действительно так.
Как видите, теперь самая жадная служба — это база данных, и это потому, что я не смог уменьшить ее размер с t3.micro до t2.micro (похоже, какой бы регион я ни выбрал, бесплатных экземпляров этого типа нет — возможно, потому, что он подходит для уровня бесплатного пользования и, следовательно, , самый популярный). А еще есть Global Accelerator, съедающее что-то значительное — и это сервис, который мне больше не нужен с App Runner, но я просто забыл его выключить и сделал это всего пару дней назад как запоздалую мысль.
Сейчас только середина месяца, поэтому стоимость в итоге будет вдвое больше, чем сейчас. Но вы можете видеть, что App Runer будет стоить мне около 10 долларов в месяц, помимо платы за EC2. Общая стоимость в день, теперь, когда я убил Global Accelerator , составляет 0,97 доллара, то есть примерно 30 долларов в месяц. Это адское улучшение по сравнению с примерно 100 долларами с настройкой Fargate. Можем ли мы сделать лучше? В следующей статье я рассмотрю еще один вариант, так что оставайтесь со мной, и я надеюсь, что эта статья оказалась для вас полезной.
