Size: a a a

2020 August 11

S

Salem in AWS_RU
ну это как раз из-за левой пятки
источник

AG

Alexey Gravanov in AWS_RU
пишите в саппорт, описывайте проблему и просите увеличить лимиты.
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
ну начну)
1. persistent data. каждая нода консул кластера должна иметь свой data-dir, как такое реализовать с Fargate + EFS я пока не совсем понял
2. Что сервер, что клиент консула должны подыматься на интерфейсе с приватным айпи.
у меня это получилось CONSUL_BIND_INTERFACE=eth1 (почему так, может ли изменится?)
3. Ригистраторы в контейнерах не вариант, приходится опять же прокидывать в efs конфиг сервиса, который consul client будет регистрировать - не удобно
4. ECS service для consul server-a состоит из 3 тасок. К нему подвязан cloudmap, что бы клиенты джойнились по dns. Получается 2 Service discovery. А иначе пришлось бы подвязывать NLB. Это или я тупой, или просто ECS не создан для консула.
5. client не умеет реджойнится, если днс сервера изменился, это если честно вообще бред, приходится перезапускать таску
1. на EFS должно быть можно, там есть разные варианты подключения volume в доке
2. ENI интерфейс получит отдельный IP
4. Вот тут тоже думаю.. но можно например не включать cloudmap и использовать только консул

Пока еще сам играюсь с ECS)) первый раз ковыряю. Документация есть, но могли бы хоть примеров добавить ))
У меня другая задача но тож ECS )
источник

AK

Aleksandr Kostiuk in AWS_RU
Vladimir Samoylov
1. на EFS должно быть можно, там есть разные варианты подключения volume в доке
2. ENI интерфейс получит отдельный IP
4. Вот тут тоже думаю.. но можно например не включать cloudmap и использовать только консул

Пока еще сам играюсь с ECS)) первый раз ковыряю. Документация есть, но могли бы хоть примеров добавить ))
У меня другая задача но тож ECS )
1. я собственно подключил efs. В task definition описывается data-dir для всего сервиса, а не каждой отдельной таски. А контейнеры должны писать каждый в свою data dir
2. ENI понятно. Как я могу узнать до старта, что это будет eth1, или eth0 или еще что?
4. Моим сервисам на старте нужно знать куда consul клиенту джойнится. Приватный айпи могут изменится в любой момент. Я другого решения не увидел пока

что за задача?
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
1. я собственно подключил efs. В task definition описывается data-dir для всего сервиса, а не каждой отдельной таски. А контейнеры должны писать каждый в свою data dir
2. ENI понятно. Как я могу узнать до старта, что это будет eth1, или eth0 или еще что?
4. Моим сервисам на старте нужно знать куда consul клиенту джойнится. Приватный айпи могут изменится в любой момент. Я другого решения не увидел пока

что за задача?
ну у меня просто микросервисы в ecs засунуть
это я сам для себя фактически делаю заодно разбираюсь
1. там есть возможность вроде задать для сервиса в целом набор папок а потом отдельно для таски их уже подключать
2. тут я как понял есть связь ENI - запущенная задача и нам не нужно знать eth1, eth0 или т.п.
4. до этого я еще не дошел)) возможно через пару дней
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
1. я собственно подключил efs. В task definition описывается data-dir для всего сервиса, а не каждой отдельной таски. А контейнеры должны писать каждый в свою data dir
2. ENI понятно. Как я могу узнать до старта, что это будет eth1, или eth0 или еще что?
4. Моим сервисам на старте нужно знать куда consul клиенту джойнится. Приватный айпи могут изменится в любой момент. Я другого решения не увидел пока

что за задача?
про network_mode изучал? я вот сейчас читаю про awsvpc какие дает плюсы и какие ограничения
но вероятно это мой выбор будет
источник

AK

Aleksandr Kostiuk in AWS_RU
Vladimir Samoylov
ну у меня просто микросервисы в ecs засунуть
это я сам для себя фактически делаю заодно разбираюсь
1. там есть возможность вроде задать для сервиса в целом набор папок а потом отдельно для таски их уже подключать
2. тут я как понял есть связь ENI - запущенная задача и нам не нужно знать eth1, eth0 или т.п.
4. до этого я еще не дошел)) возможно через пару дней
1. Нет там такого)
2. консулу нужно

да, awsvpc хорош, но у него есть ограничения
у меня часть сервисов на bridge, часть на awsvpc
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
1. Нет там такого)
2. консулу нужно

да, awsvpc хорош, но у него есть ограничения
у меня часть сервисов на bridge, часть на awsvpc
1. "Added support for using Amazon EFS file system volumes for persistent task storage."
я думал это для таски .. типа в 1.4.0 добавили
https://docs.aws.amazon.com/AmazonECS/latest/userguide/efs-volumes.html - вот ту тесть пример task definition и там указывается прям mountPoints
но я не тестил еще
источник

AK

Aleksandr Kostiuk in AWS_RU
я уже писал выше. EFS на идет на таску, но если в сервисе 3 одинаковые таски - маунт один и тот же, что абсолютно не подходит консулу
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
я уже писал выше. EFS на идет на таску, но если в сервисе 3 одинаковые таски - маунт один и тот же, что абсолютно не подходит консулу
спрошу у одного товарища в понедельник (следующий)
у него консул как раз , но вот не помню используется ли ECS или там nomand у них был
источник

AK

Aleksandr Kostiuk in AWS_RU
Ребят, а кто тут использует ECS?
Есть пару вопросов по task definition в пайплайне.
У меня создание и управление task definition положено полностью на terraform, а хотелось бы что бы девы без моего участия могли добавить/изменить env переменные контейнеров.
Как у вас это реализовано?
источник

MC

M@s0n C01em@n in AWS_RU
Aleksandr Kostiuk
Ребят, а кто тут использует ECS?
Есть пару вопросов по task definition в пайплайне.
У меня создание и управление task definition положено полностью на terraform, а хотелось бы что бы девы без моего участия могли добавить/изменить env переменные контейнеров.
Как у вас это реализовано?
ну, как вариант можно дать доступ к редактированию таски через юай task definition
источник

AK

Aleksandr Kostiuk in AWS_RU
M@s0n C01em@n
ну, как вариант можно дать доступ к редактированию таски через юай task definition
Не вариант... Руками низя

Я думал о каком-то json в репе, который будет "комбинироваться" с тем что создаётся в терраформе, но выглядит как костыль

Вот хотел consul приплести, с его K/V. Но там тоже столько моментов вылазит...
источник

V

Vladislav Alexandrov in AWS_RU
Если переменные едины для одного образа, то можно запекать их прямо в докер образ. Соответственно разрабы будут рулить ими через докерфайл или какие другие обвязки в CI
источник

AK

Aleksandr Kostiuk in AWS_RU
Vladislav Alexandrov
Если переменные едины для одного образа, то можно запекать их прямо в докер образ. Соответственно разрабы будут рулить ими через докерфайл или какие другие обвязки в CI
такие переменные да

но иногда бывают моменты что так не выходит

и полностью отдать все env в ci я не могу, ибо terraform туда впихивает эндпоинты/arn некоторых созданных ресурсов
источник

V

Vladislav Alexandrov in AWS_RU
Aleksandr Kostiuk
такие переменные да

но иногда бывают моменты что так не выходит

и полностью отдать все env в ci я не могу, ибо terraform туда впихивает эндпоинты/arn некоторых созданных ресурсов
Так часть переменных будет разруливать тф, часть сам докер образ. Но варик далеко не идеальный, да
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
Ребят, а кто тут использует ECS?
Есть пару вопросов по task definition в пайплайне.
У меня создание и управление task definition положено полностью на terraform, а хотелось бы что бы девы без моего участия могли добавить/изменить env переменные контейнеров.
Как у вас это реализовано?
значения переменных или добавление самих переменных типа хотим BACKEND_URL сегодня , а завтра её уже не хотим и уберите её?
у меня тут на днях json вообще не потянулся , хотя в .tf файл когда записал всё было ок..
источник

AK

Aleksandr Kostiuk in AWS_RU
Vladimir Samoylov
значения переменных или добавление самих переменных типа хотим BACKEND_URL сегодня , а завтра её уже не хотим и уберите её?
у меня тут на днях json вообще не потянулся , хотя в .tf файл когда записал всё было ок..
Типа такого да. Что бы меня не трогали по таким моментам))
источник

VS

Vladimir Samoylov in AWS_RU
Aleksandr Kostiuk
Типа такого да. Что бы меня не трогали по таким моментам))
мне кажется что плавно всё идет к consul + nomad + vault
и к созданию площадки такой для разработки))
я этим вопросом еще не занимался , но вот так издалека скажем посмотрел
источник

AK

Aleksandr Kostiuk in AWS_RU
Vladimir Samoylov
мне кажется что плавно всё идет к consul + nomad + vault
и к созданию площадки такой для разработки))
я этим вопросом еще не занимался , но вот так издалека скажем посмотрел
я уже 2-3 дня ковыряю consul + ecs
в итоге понимаю что многие фишки consul мне банально не нужны, а держать отказоустойчивый consul кластер, от которого будут зависеть ВСЕ сервисы... ну мне кажется не благорозумно. + придется перелопатить половину инфраструктуры.
источник