Бессерверный!

Эта статья предназначена для разработчиков, которые достаточно хорошо знакомы с созданием приложений Kotlin (или Java), но, возможно, менее осведомлены о том, что делать дальше. Мы исходим из нескольких предположений:

  • Вы создали новый блестящий микросервис Kotlin и хотите поделиться им со всем миром.
  • Это веб-приложение, поэтому его нужно где-то разместить.
  • Имеет некоторые зависимости - база данных; возможно тайник. Это то, что вы тоже не хотите держать на домашнем компьютере.
  • Вы хотите, чтобы он был масштабируемым в будущем - если он наберет обороты.
  • Вы хотите изучить возможности, которые предлагают крупные облачные провайдеры, и начинаете с AWS.
  • Он dockerized - значит, вы опубликовали его Docker-образ в каком-то репозитории контейнера. Это важно в контексте данной статьи, поскольку решение, которое мы рассмотрим в первую очередь, будет основано на контейнерах.

Будет несколько статей о различных способах сделать это на AWS, но мы начнем с AWS Fargate.

AWS Fargate - это бессерверный вычислительный механизм с оплатой по мере использования, который позволяет вам сосредоточиться на создании приложений без управления серверами. AWS Fargate совместим как с Amazon Elastic Container Service (ECS), так и Amazon Elastic Kubernetes Service (EKS).

Итак, FAQ будет:

  1. Что такое ECS, EKS и в чем разница?

ECS - это полностью управляемая служба оркестровки контейнеров, созданная Amazon. EKS также является сервисом оркестровки контейнеров на Amazon, но он основан на Kubernetes, поэтому для вас это как управляемый Kubernetes.

  • Повлияет ли на стоимость, если я выберу ECS или EKS?

Не совсем. Ценообразование Fargate основано на количестве виртуальных ЦП, памяти и ресурсов хранения (примечание: ресурсы хранения теперь доступны для ECS). Так что, если вам просто нужна вычислительная мощность, все будет так же.

  • Как мне начать?

Вот о чем статья! Читать дальше.

Для статьи я выбрал инструмент Kotlink - это решение для создания и обмена запоминающимися псевдонимами URL, которое черпает вдохновение из внутренней системы Go-Links от Google. Это инструмент для повышения продуктивности, которым я часто пользуюсь, с открытым исходным кодом и бесплатным. Я использую его как плагин Chrome, который позволяет мне, например, вводить такие вещи в строку местоположения браузера:

kk_berlin weekend tips

и нажмите Return на предложенной ссылке - и я сразу перейду к сохраненной мной ссылке. Это намного лучше, чем закладки, потому что они не загромождают меню / панели инструментов моего браузера, и, честно говоря, я не беспокоюсь о том, чтобы запоминать ссылки или даже имена доменов, поэтому я часто борюсь с тем, что набирать. В любом случае, статья не о самом Котлинке, а о том, как мы его развертываем.

Однако есть несколько предварительных условий для его использования, которые я здесь опустил.

Предпосылки

  • Приложение OAuth. Этот инструмент должен использоваться с авторизацией OAuth, и вам потребуются идентификатор клиента и секрет клиента для клиента Oauth2 Google. Его можно создать через Google API Console, и процесс описан в Инструкции по развертыванию Kotlink. Скорее всего, в вашем приложении этого нет, поэтому это выходит за рамки.
  • Доменное имя. Я зарегистрировал его в Amazon Route 53, и это то, что вам понадобится, поскольку вы собираетесь каким-то образом представить свое приложение миру, верно? Но есть много руководств о том, как зарегистрировать домен в Route 53, а также вы можете зарегистрировать домен в другом месте и просто использовать его со своей службой - это ваш выбор.

Конфигурация приложения

База данных

Моему приложению требуется экземпляр базы данных Postgres, который я решил настроить отдельно. Некоторые решения позволят вам настроить базу данных непосредственно в процессе развертывания, и у этого есть ряд преимуществ, а именно:

  • Инфра управляется как единое целое. Если вы решите убить свой кластер, база данных умирает вместе с ним (или не умирает - вы всегда можете сохранить ее или сделать снимок).
  • Первоначальная настройка может быть проще - вам не нужно делать это в нескольких местах.
  • Все масштабируется вместе, в зависимости от того, как части взаимодействуют.

Однако в моем случае я хочу попробовать несколько разных способов развертывания приложения и не хочу каждый раз терять (или повторно импортировать) свои данные тестирования. Кроме того, я хочу иметь возможность повторно использовать конфигурацию приложения. В случае моего приложения такие вещи, как URL-адрес базы данных и учетные данные, настроены в application.yml и могут быть переопределены параметрами программы или переменными среды. Приложение является приложением Spring Boot и, как таковое, имеет множество возможных источников свойств. Но поскольку наше приложение является контейнерным, проще всего передать свойства через переменные среды, поскольку его легко настроить для контейнера докеров.

Для базы данных есть много вариантов, но большинство из них я принял по умолчанию. Главное, что вам нужно выбрать, - это тип экземпляра, а также моментальные снимки: как часто вы их создаете, в какое время (непиковое время имеет смысл), срок хранения (как долго вы их храните) и т. Д. Кроме того, вы можете выбрать создать резервный экземпляр для аварийного переключения (помните, что в AWS RDS резервный экземпляр не является репликой - он не предназначен для балансировки нагрузки; это только ваш вариант аварийного переключения). Я выбрал довольно маленький экземпляр, но, тем не менее, вижу, что он используется не в полной мере - см. Вкладку "Мониторинг".

Я, вероятно, мог бы обойтись только db.t2.micro - вам выставляют счет за ресурсы, поэтому нет смысла чрезмерно выделять ресурсы, хотя, конечно, должен быть некоторый запас.

Создание кластера Fargate

Если вы выполните поиск Fargate в списке сервисов AWS в пользовательском интерфейсе консоли AWS, вы не найдете его. Вместо этого вы увидите предложение Elastic Container Service. Поскольку мы уже знаем, что Fargate поддерживается ECS или EKS, вы выбираете именно это.

Чтобы создать кластер Fargate, вам нужно щелкнуть Getting Started, когда вы находитесь в разделе «Кластеры». Также есть кнопка Create Cluster, но она предлагает на выбор только кластер с простой сетью или кластер с экземплярами EC2 на базе Windows или Linux. Ни то, ни другое нам не нужно, поэтому давайте выберем другую кнопку.

Get Started screen предлагает сразу несколько вариантов:

  • sample-app (из httpd изображения)
  • nginx (с nginx:latest)
  • tomcat-webserver (из tomcat изображения)
  • custom - это то, что нам нужно; это позволит нам создать наш собственный имидж.

Следующий экран позволит вам настроить изображение, а также некоторые параметры памяти и процессора. Мы также настраиваем сопоставление портов. Это порты, которые мы хотим открыть. Kotlink - это приложение SpringBoot, и по умолчанию его http порт сервера установлен на 8080, а https - на 8443.

Есть также некоторые дополнительные параметры, которые мы можем настроить. Например, есть возможность указать команду ahealthcheck; в случае сбоя кластер будет знать, что нужно перезапустить службу. Мы можем указать период отсрочки, если мы знаем, что приложение запускается не очень быстро. Это даст контейнерам время для начальной загрузки, прежде чем неудачные проверки работоспособности будут учитываться при максимальном количестве повторных попыток. По умолчанию повторяются 3 попытки, поэтому вы можете оставить это число пустым, если все в порядке, или указать любое число от 1 до 10.

Вы также можете указать блоки ЦП, блоки графического процессора, а также такие параметры, связанные с докерами, как ENTRYPOINT, CMD, WORKDIR. Поскольку в образе Kotlink все это уже есть, я не заполнял его.

ВАЖНО: количество модулей ЦП не совпадает с количеством ЦП!

Соотношение 1024 единиц ЦП на 1 ядро ​​ЦП. Я усвоил это на собственном горьком опыте, когда моя первая настроенная служба просто не могла запуститься, потому что количество ЦП, которое я указал, было смехотворно низким.

Есть несколько других вариантов - для сети, тайм-аутов контейнеров, хранения и ведения журнала, ограничения ресурсов. Я почти все оставил пустым, но нам нужны некоторые переменные среды для настройки приложения. Их можно указать, прикрепив .env файл или просто добавив их по одному в пользовательском интерфейсе. Я выбрал второй вариант, но, как правило, использование файлов удобнее, если вам придется делать это несколько раз.

Список конфигураций, которые можно задать через переменные окружения для Kotlink, довольно велик и описан в руководстве по разработке. Я пропустил несколько вещей в своем развертывании, потому что хотел упростить процесс.

После настройки контейнера вам также следует отредактировать определение задачи. Это можно сделать, нажав кнопку Edit под выбранным контейнером после заполнения всплывающего окна сведений о контейнере.

Здесь важно изменить параметры ЦП и памяти. Они должны соответствовать параметрам, которые вы указали для контейнера. Например, для моего контейнера приложения я выбрал 1024 процессора; это означает, что значение по умолчанию 0.25 vCPU больше не подходит. Мне нужно как минимум одно полное ядро ​​ЦП, чтобы иметь возможность запускать этот контейнер. Затем после того, как вы выбрали требуемый процессор, пользовательский интерфейс, скорее всего, представит вам сообщение об ошибке, потому что теперь ограничения памяти слишком жесткие, поэтому вам необходимо соответствующим образом исправить ограничения памяти.

После того, как вы указали параметры задачи, вы переходите к следующему шагу, чтобы установить количество задач и параметры балансировщика нагрузки.

И экран с подробностями о нем:

На следующем экране вы завершите настройку кластера.

После просмотра экрана нажмите Create, чтобы создать и запустить кластер.

Если все в порядке и вы все настроили правильно, вы увидите несколько вещей, которые были созданы в этом кластере:

  • в кластере есть служба;
  • сервис запускает задачу;
  • задача запускает контейнер.

Вы можете видеть, что у вас есть определение в разделе Task Definitions консоли ECS.

По мере обновления задачи вы создаете версии этого определения задачи. Затем с новой версией вы можете обновить существующую службу или запустить новую.

Балансировщик нагрузки

Так что ли? Сервис запущен!

Да, служба работает. Однако вам нужно как-то получить доступ к приложению, не так ли? Но как? Ответ - через Application Load Balancer. Даже если вы фактически не балансируете нагрузку, потому что у вас постоянно работает только один контейнер, вам нужно что-то, чтобы привязать ваше приложение к тому доменному имени, которое вы указали в предварительных требованиях. Есть возможность создать балансировщик нагрузки приложений (ALB) при создании кластера. Однако вы также можете создать балансировщик нагрузки отдельно от сервисной консоли EC2 перед настройкой кластера Fargate, а затем выбрать его при создании службы. Важно то, что вам нужно установить запись A-типа в вашей размещенной зоне, ту, которая связана с доменным именем, чтобы связать ее с этим ALB. Я пропущу инструкции, так как для этого потребуется отдельная статья. Тем не менее, в руководстве по AWS есть полезный раздел с пояснениями.

Успех!

Если все идет хорошо и боги DNS смотрят на вас благосклонно, скорее всего, это все, и kotlink.click приведет нас на страницу входа. Или, в вашем случае, это будет стартовая страница вашего приложения, какой бы она ни была. Ура!

Успех?

Теперь мы развернули наше приложение в Fargate, и кластер запущен. Но разве это конец истории? Вот интересная мысль (да, думай, а не вещь - это не опечатка).

Я думаю, что задача Fargate не рассчитана на длительное время. Учитывая его цену (из расчета на процессор в час), это непомерно дорого. И я знаю, что львиная доля расходов приходится на Фаргейт, потому что я могу видеть это в моем Cost Explorer.

Подробности? Мой первый счет за AWS после развертывания сервиса в Fargate составил 170 долларов США. Я побежал к консоли и, по правде говоря, обнаружил, что неправильно сконфигурировал кластер, отдав ему 2048 процессорных единиц вместо 1024, которых было бы достаточно. Я сократил вдвое ресурсы кластера, и теперь, через три недели следующего месяца, у меня есть это.

Итак, счет в этом месяце, вероятно, составит около 100 долларов США, что, я бы сказал, все еще слишком много для забавного побочного проекта. Конечно, я могу (и буду) уменьшить размер БД, и мне, вероятно, нужно будет также изучить затраты на Global Accelerator и затраты на ELB… да ладно.

Однако есть шанс, что другие решения на базе AWS будут более экономичными. Поэтому я собираюсь изучить их в следующих статьях. Останьтесь со мной, чтобы узнать об этом больше!

Ресурсы