Совершенно верно. В тестовом окружении уже проводили работы по переходу на iam роль. В скором времени внедрим и в других.
И спасибо за новодку по кэшу с roleArn, не знал.
По поводу kubeconfig тоже согласен, да и править его в таком случае будет во много раз легче думаю. Возьму это в план на доработку в будущем.
А подключение через SSM - тут все зависит от того, кто работает с этим. Для кого то это станет новым инструментом и риском для сбоев. Стоит это учесть при реализации.
Аналогично и с доставкой новых правок в AMI. Мы в данный момент решили это через packer+terraform, что во много раз упростило жизнь. Это также стоит учесть.
Честно скажу, такой вариант даже не рассматривали. Но, думаю, можно выделить несколько нюансов при такой схеме:
GitLab Runner — это stateful-демон с долгоживущим подключением к GitLab.
Lambda же — stateless-функция, не предназначенная для постоянных фоновых процессов. И как себя это покажет в работе вопрос интересный, и ответа на него у меня нет к сожалению.
Также - один дешёвый инстанс (допустим t3.nano — ~$5 в месяц) с простым GitLab Runner проще в поддержке, обновлении и отладке, чем кастомная serverless-оркестрация на Lambda+SQS со всей логикой управления жизненным циклом раннеров.
К тому же stateful решение - это проверенный и документированный подход. Замена его на кастомное serverless-решение увеличила бы нагрузку и создала бы самописную сложность.
Если у вас есть такой опыт, то буду рад услышать о нем. Может быть в действительно это все выглядит гораздо проще.
Спасибо, действительно перепутано, исправил :)
Совершенно верно. В тестовом окружении уже проводили работы по переходу на iam роль. В скором времени внедрим и в других.
И спасибо за новодку по кэшу с roleArn, не знал.
По поводу kubeconfig тоже согласен, да и править его в таком случае будет во много раз легче думаю. Возьму это в план на доработку в будущем.
А подключение через SSM - тут все зависит от того, кто работает с этим. Для кого то это станет новым инструментом и риском для сбоев. Стоит это учесть при реализации.
Аналогично и с доставкой новых правок в AMI. Мы в данный момент решили это через packer+terraform, что во много раз упростило жизнь. Это также стоит учесть.
Честно скажу, такой вариант даже не рассматривали.
Но, думаю, можно выделить несколько нюансов при такой схеме:
GitLab Runner — это stateful-демон с долгоживущим подключением к GitLab.
Lambda же — stateless-функция, не предназначенная для постоянных фоновых процессов. И как себя это покажет в работе вопрос интересный, и ответа на него у меня нет к сожалению.
Также - один дешёвый инстанс (допустим t3.nano — ~$5 в месяц) с простым GitLab Runner проще в поддержке, обновлении и отладке, чем кастомная serverless-оркестрация на Lambda+SQS со всей логикой управления жизненным циклом раннеров.
К тому же stateful решение - это проверенный и документированный подход. Замена его на кастомное serverless-решение увеличила бы нагрузку и создала бы самописную сложность.
Если у вас есть такой опыт, то буду рад услышать о нем. Может быть в действительно это все выглядит гораздо проще.