IV
у меня сейчас именно как ты написал, только -env нет, потому что aws аккаунт per env
Size: a a a
2020 May 15
O
Поэтому есть смысл брать то, что удобно "прямо сейчас" и чуть-чуть потом и с этим жить.
O
у меня сейчас именно как ты написал, только -env нет, потому что aws аккаунт per env
А что тебя в этой схеме беспокоит?
IV
А что тебя в этой схеме беспокоит?
- $project_codename или $app может быть очень длинным
- не понятно где webapp, где сервис и где worker
- ecs или fargate
- не понятно, что является must в случае degraded availability
- не понятно где webapp, где сервис и где worker
- ecs или fargate
- не понятно, что является must в случае degraded availability
O
- $project_codename или $app может быть очень длинным
- не понятно где webapp, где сервис и где worker
- ecs или fargate
- не понятно, что является must в случае degraded availability
- не понятно где webapp, где сервис и где worker
- ecs или fargate
- не понятно, что является must в случае degraded availability
Где-то я уже видел такие тезисы:)
IV
у меня очень много task defs
O
- $project_codename или $app делаются краткие мнемоники в 6-8 символов
- webapp по сути имя компонента, его можно добавлять к имени ($svname-api, $svname-wrk)
- ввести конечно можно, но действительно ли хочется видеть это в имени, или лучше в метадате посмотреть у конкретного сервиса?
- аналогично предыдущему, потому что потом с шансом появится несколько градаций, потом под-градации к этим градациям и в итоге гигантский нейминг, который сложно читать и который никуда не помещается. По крайней мере я такой путь видел.
Вводить длинные названия, включающие в себя все подряд идея соблазнительная, но к сожалению тут 2 проблемы:
1. Их становится невозможно запомнить
2. Их становится невозможно воспроизвести из головы даже логически
3. Тогда, когда тебе действительно нужны все эти данные, ты обычно можешь посмотреть в ту или иную метадату, где получишь гораздо более полную информацию об интересующем тебя сервисе.
4. Все равно рано или поздно все что хочется перестанет влезать в разрешенную длину имени.
- webapp по сути имя компонента, его можно добавлять к имени ($svname-api, $svname-wrk)
- ввести конечно можно, но действительно ли хочется видеть это в имени, или лучше в метадате посмотреть у конкретного сервиса?
- аналогично предыдущему, потому что потом с шансом появится несколько градаций, потом под-градации к этим градациям и в итоге гигантский нейминг, который сложно читать и который никуда не помещается. По крайней мере я такой путь видел.
Вводить длинные названия, включающие в себя все подряд идея соблазнительная, но к сожалению тут 2 проблемы:
1. Их становится невозможно запомнить
2. Их становится невозможно воспроизвести из головы даже логически
3. Тогда, когда тебе действительно нужны все эти данные, ты обычно можешь посмотреть в ту или иную метадату, где получишь гораздо более полную информацию об интересующем тебя сервисе.
4. Все равно рано или поздно все что хочется перестанет влезать в разрешенную длину имени.
O
А, ну и еще у тебя очень много трудозатрат на нейминг выплывает, особенно если там что-то не очевидное и с шансом переменчивое, вроде must. А переименовывать обычно больно, что сильно повышает шанс того, что отраженное в имени перестает соответствовать действительности. То же касается и какие-то сервисов, когда в имя включается локация, но при этом они не инфраструктурные и могут переехать, и вот у тебя уже сервис myshinyservice-east1 живет в west2, потому что была миграция по тем или иным причинам, а переименовывать - очень больно.
IV
Это все очевидные проблемы, но это не значит что их не нужно решать 😉 Поэтому и возник вопрос есть ли какие-то best practices
O
Ну, вот обо все эти очевидные проблемы все видимые мной решения во всех компаниях и сломались, потому что логические противоречия:)
O
Поэтому краткое имя, которое уникально идентифицирует сервис в рамках понимания, откуда он взялся и остальное достается с метаданных, благо сейчас можно к любой сущности хоть 100 полей накрутить.
O
Просто потому что имя - плохое хранилище информации:)
IV
считай что это не имя, а тег
O
Концептуально один тег же ничем не отличается от имени. Я все подобные штуки, о которых ты говорил, храню в разных тегах (ну или аннотациях, где как они называются). Я не припомню если честно за последние лет пять так точно ситуацию, когда что-то, где работают приложения, не позволяет хранить достаточно количество полей с метаданными, куда прекрасно помещается все что нужно.
IV
нет задачи хранить все в имени, но хотелось бы по имени хотя бы понять, что это такое. я прекрасно понимаю твои аргументы
A
коллеги, а где конфиги храните? хочется сервис, чтоб можно было настроить дефолтный конфиг для всех, переопределить для отдельных типов сервисов и environments. ну и в идеале чтоб бесплтано или в докере устанавливалось и нугет пакетом подключалось. сейчас приходится в каждый сервис заходить и руками править
A
в ажуре есть конфиг сервис, но там странное ограничение на 1000 бесплатных запросов параметров в сутки
IV
коллеги, а где конфиги храните? хочется сервис, чтоб можно было настроить дефолтный конфиг для всех, переопределить для отдельных типов сервисов и environments. ну и в идеале чтоб бесплтано или в докере устанавливалось и нугет пакетом подключалось. сейчас приходится в каждый сервис заходить и руками править
в амазоне есть SSM с parameter store и конфиг сервис. для моих нужд parameter store хватает
IV
и простите, consul
O
и простите, consul
Ну почему простите, hashicorp вполне себе ничего продукты делает:)