Комментарии 12
Классный КДПВ! А по какому принципу у вас происходит выбор картинки? У каких-то статей последовательный стиль, а какие-то отличаются. По какому принципу это происходит? По воле конкретного автора?
Привет и спасибо за вопросы! Обычно у нас КДПВ придумывают вместе автор и редактор статьи: собираем все идеи, а затем выбираем ту, которая всем ближе. В этой конкретной статье мы вспомнили про «Звёздный путь» и серию «Проблема с трибблами» и делали отсылку к ней.
Что касается разных стилей, за ними стоит определённая логика. Обложки переводов сделаны в основном брендинге всего «Фланта» и довольно абстрактны. Обложки юнита DevOps as a Service всегда с муравьём. У Deckhouse обложки с их маскотом — уткой. А у «Экспесс 42» — с роботом :)
EC2 у нас остаётся только один управляющий инстанс с GitLab Runner, который занимается запуском и оркестрацией задач
А почему бы просто не использовать лямбду в связке с снс/скьюс для оркестрации по факту? Зачем инстансу зря простаивать
Честно скажу, такой вариант даже не рассматривали.
Но, думаю, можно выделить несколько нюансов при такой схеме:
GitLab Runner — это stateful-демон с долгоживущим подключением к GitLab.
Lambda же — stateless-функция, не предназначенная для постоянных фоновых процессов. И как себя это покажет в работе вопрос интересный, и ответа на него у меня нет к сожалению.
Также - один дешёвый инстанс (допустим t3.nano — ~$5 в месяц) с простым GitLab Runner проще в поддержке, обновлении и отладке, чем кастомная serverless-оркестрация на Lambda+SQS со всей логикой управления жизненным циклом раннеров.
К тому же stateful решение - это проверенный и документированный подход. Замена его на кастомное serverless-решение увеличила бы нагрузку и создала бы самописную сложность.
Если у вас есть такой опыт, то буду рад услышать о нем. Может быть в действительно это все выглядит гораздо проще.
У меня такой опыт есть. Нужно, наверное, отдельную статью написать. Fleeting Plugin мы тоже пробовали, как и автоскейлинг на лямбдах. Все равно везде получались свои недостатки. У Fleeting - довольно большое время реакции (время сырого старта инстанса из AMI - порядка минуты) и медленное масштабирование. Плюс сам основной раннер, отслеживающий очередь джоб и стартующий экзекьюторы, тоже в итоге становится боттлнеком и при большом потоке джоб начинает тормозить, а то и вообще зависает, делая весь CI нерабочим.
Интересная штука, но я пока останусь на k8s runner поверх autoscaling группы прерываемых инстансов.
несколько комментариев
Создание IAM-пользователя — отдельный AWS-аккаунт (например, gitlab-autoscaler), от имени которого Runner получает права на работу с EC2 и Auto Scaling.
Точно не перепутали AWS account с юзером?
accesskey/secretkey - использование статических кредов в принципе дело нехорошее - их же еще надо ротировать регулярно, что вызывает дикую боль. В кеше раннеров гитлаб так-то пишет что можно использовать roleArn и временные креды для доступа к кешу будут генериться автоматически
статические креды в ~/.aws/credentials тоже так себе решение. Вы запускаете инстанс в AWS, у него есть InstanceProfile - можно брать креды прямо оттуда, навесив политику на инстанс. Или же, если это недопустимо, и необходимо чтобы политикой владел пользователь gitlab-runner в ~/.aws/config всегда можно прописать получение кредов поддерживаемое SDK (тот же IAM Role с нужной политикой)
комментарии к "плюсам и минусам"
AMI
Как делаете версионирование инструментов? Иногда при обновлении инструментов появляются breaking changes в новой версии. Вы используете единую AMI для раннеров. Как быть если часть кода деплоится старой версией, а часть - новой? У нас с терраформом решали переименованием бинарников terraform011 terraform012 terraform1 и прописыванием в CI соответствующего бинарника
В планах было (больше там не работаю) заменить на использование tfenv. Как быть с другими инструментами даже идей нет
Отдельный процесс доставки конфигурационных изменений в любом случае нужен. Это не минус, это просто задача которую нужно решить
Плюс запечатывание kubeconfig в AMI - имхо, это плохо. Уж лучше на старте инстанса забирать из Secrets Manager
подключение через SSM - тоже не минус а просто решаемая техническая задача. Вы же контролируете обе части: и менеджера и клиента, версии SSM агента вам известны, политики пишете сами
про версионирование инструментов: del (а то время вышло на редактирование). docker же, че это я )
Спасибо, действительно перепутано, исправил :)
Совершенно верно. В тестовом окружении уже проводили работы по переходу на iam роль. В скором времени внедрим и в других.
И спасибо за новодку по кэшу с roleArn, не знал.
По поводу kubeconfig тоже согласен, да и править его в таком случае будет во много раз легче думаю. Возьму это в план на доработку в будущем.
А подключение через SSM - тут все зависит от того, кто работает с этим. Для кого то это станет новым инструментом и риском для сбоев. Стоит это учесть при реализации.
Аналогично и с доставкой новых правок в AMI. Мы в данный момент решили это через packer+terraform, что во много раз упростило жизнь. Это также стоит учесть.
packer+terraform
ну это стандартный способ, но он плохо подходит для обновления значений в конфигах\самих конфигов или каких-нибудь темплейтов. То есть данных которые потенциально могут меняться чаще чем AMI (или зависеть от окружения если одно и то же решение раскатывать для разных окружений)
Для этого удобно использовать SSM документы, где можно написать скрипт, синхронизирующий значения из SSM параметров или Secrets Manager по пинку
Масштабируемые GitLab Runners в AWS: как избавиться от ручного управления и снизить затраты