Взвешивать надо…
Кто-то может и электричество сам производит под ИТ.
А кто-то все в лямды в облаках запихал и радуется… На клиента надо ориентироваться…
Ок, спасибо.
Вроде Оверлей с драйвеорм https://github.com/projectcalico/calico-containers
совсем не плохо…
Да и не в throughput всегса дело… Достаточно редко это нужно. С Latency интереснее тут (покрайней мере мне)
Хотелось бы задержаться и задать пару вопросов к этому:
«ECS позволяет настроить каждый аспект окружения по вашим потребностям. По этой причине ECS — не самый простой инструмент в начале пути.»
Мы начали и солкнулись с неработающими метриками в CloudWatch и сложностями ручным добавлением машин в класетер, все это доставляет операционной возни которой хочется избежать…
Но с другой стороны если я правильно понял ещё более «высокая» абстракция AWS Elastic Beanstalk с мультиконтейнерной конфигурацией — вроде неплохой варинат, но устроена так что первична аппликация а потом уже Энвайронмент (кластер) для нее. Если аппликушечки сравнительно маленькие и их лучше деплоить в один большой кластер то это как-то совсем не то. Вы используете AWS Elastic Beanstalk и как решаете эту проблему если она у вас конечно возникает?
Также ни ECS ни како-то другой сервис в AWS не предоставляет Service Discovery, даже в Гугле есть сервис метаданных, в AWS есть сервис по мэнеджменту сертификатов — что уже неплохо в нашем случае кое-какие вопросы решим… Но хотелось бы решить вопрос с конфигурацией Контейнеров в разных кластерах… Хочется не делать это в ручну через передавемы параметры сервису…
Вы это как-то решаете? Это тема для вас есть опыт? Я знаю про consul и нахожу интересным. Но это означает что надо начинать провизинонировать машины на уровне IaaS но у нас пока еще есть надежда что мы можем как-то польностью мимо это-го пройти, что-бы как можно больше предоставить AWS.
Как вы на это смотрите?
Караз есть, если все совать в контенеры, то глупо полагаться на то что контеенер приземлится на определенной машине…
Более того имеет смысл использовать систему абстрагированую в принципе от маунтингда чего либо к одному хосту… в облаках это не делают…
Представьте что у вас 1000 > контейнеров
Но переде тем как переписать всю апплику хотелось найти что-то быстрое по середине как компромис. Пока у нас 3 контейнера, на след. неделе будет 7.
В перспективе >200 в этом году.
Это интереснее в определенный сценариях это ок.
Но мы планиеруем на будущее и как можно меньше хочется полагаться на информацию с хостов и провизионировать туда…
Если использовать какой-нибудь kubernetes или у нас в данном случае AWS ECS то размещением контейнеров на хостах занимается scheduler
Поэтому краткосрочно мы решим это с привязкой к хосту или переменной. Но в дальнешем похоже надо будет написать клиент который будет забирать себе сертефикат и прочее откуда-нибудь…
Вы как-то не определили DevOps…
На хабре часто так начинают и заканчивают в позивном или негативном…
Вы начали о введении каких-то инструментов и тулов вашу статью… Когда это совершено вторично…
Первично именно то что вы написали ниже:
А что если объединить несколько выделенных специалистов с различными профильными знаниями в одну группу, которая сможет решать DevOps-задачи всей компании
Толькпо
DevOps-задачи всей компании
а что остается? Если в компании вводится ДевОпскультура то разве могут остаться какие-то куски IT за которую другие команды будут решать задачи DevOps Firefighters?
Не совсем ясно. Помоему это лишает смысла саму идею…
DevOps это глубокая трансформация тесно связаная с Time to Market, тоесть она служит каким то целям всей компании и коррелирует с другими идеями (Agile Methods) а не сама по себе самоцель.
Поидее все Dev и Ops должны трансформироваться в подобные комманды с различными скилами (cross-functional teams, T-shaped)
И это самое сложное, дело в организации, методах управления, мотивации и опыте людей.
А TeamCity, Гитлаб, Артифактори, Ансибле, Докер и облака, сами придут как следствия принятия технических решений умными enhabled командами — которой вы были наверно.
Спасибо. Какраз сегодная строили…
Вроде можно на стадии сборки добавить и корпоративный корневой сертификат так как keytool сохранен. Завтра будем пробовать…
Это позволит доверять SSL/ соединениям к серверма подпоисаным корневиком.
Но вот не придумали еще как быть с серверным сертификатом для SSL/TLS.
Ны портируем готовое приложение в облако…
Раньше сертификаты сервера устанавливались на машину а ява приложению просто передавался путь на кейстор, както-так.
А теперь все будет динамичнее, и не хочется вводить привязку к хосту в принципе.
Не совсем еще понятно куда класть сертфикаты сервера, особенно с учетом того что один и тот-же докер-имидж хочется тестировать на дев-энвайроменте и в продекшне…
Один из радикальных вариантов это запекать оба сертификата в Docker image и подставлять в зависимости от конфиги (дев, прод).
Другой вариант куда-то стучаться из стартующего контейнера шелскриптом перед запуском javы что-бы то куда постучались вернуло нужный серверный сертификат и ключ и он был положен в нужно еместо перед запуском апликухи…
Вот такие две версии крутятся. Может у вас есть опыт или идеи?
Докер не то решает что вы пытаетесь там ковырять.
Ну не нужен он вам, не используйте.
Вот тут может о том почему это не замена виртуалке и не об этом вообще
http://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-normal-virtual-machine/25938347#25938347
Тут фишка в том что не надо быть догматичным. Это хорошее правило…
Но вы решаете что такое «аппликация» и сколько процессов она должна стартануть что быть самодостаточной.
docker контейнер и запуск более чем одного приложения в нем, ну это как бы даже не соответствует документации по docker, там написано что в одном контейнере лучше запускать не более одного приложения.
Приложения, сервиса… и не обезательно что это один процесс, хотя проще, да…
И вам решать что есть именно ваше приложение… Для микросервица очень вазжна акакрза его самодостаточность и его как можно меньшая зависимость от внешнего мира в плане конфигурации и прочих предположений о среде…
Тут прежде всего напрашивается упоминание о тестовой пирамиде… (http://martinfowler.com/bliki/TestPyramid.html)
Микросервисная архитектура позволяет писать хорошие тесты у базы пирамиды и многое ими покрывать и отлавливать…
Однако МСА переносит часть сложности в интеграционный слой… и это момент особого внимания в микросервисной архитектуре…
Тут все должно быть четко и понятно, тогда можно (и нужно) ограничится минимум правильно написаных интеграционных тестов.
Кто-то может и электричество сам производит под ИТ.
А кто-то все в лямды в облаках запихал и радуется… На клиента надо ориентироваться…
Вроде Оверлей с драйвеорм https://github.com/projectcalico/calico-containers
совсем не плохо…
Да и не в throughput всегса дело… Достаточно редко это нужно. С Latency интереснее тут (покрайней мере мне)
Именно так! Тоже с две недели поткали ЕЦС и лично я пришел вашему выводу!
Есть какие-то цыфры по этому поводу?
Это все звучит как антипаттерн… Но не важно это уже выходит за рамки вопроса…
Хотелось бы задержаться и задать пару вопросов к этому:
«ECS позволяет настроить каждый аспект окружения по вашим потребностям. По этой причине ECS — не самый простой инструмент в начале пути.»
Мы начали и солкнулись с неработающими метриками в CloudWatch и сложностями ручным добавлением машин в класетер, все это доставляет операционной возни которой хочется избежать…
Но с другой стороны если я правильно понял ещё более «высокая» абстракция AWS Elastic Beanstalk с мультиконтейнерной конфигурацией — вроде неплохой варинат, но устроена так что первична аппликация а потом уже Энвайронмент (кластер) для нее. Если аппликушечки сравнительно маленькие и их лучше деплоить в один большой кластер то это как-то совсем не то. Вы используете AWS Elastic Beanstalk и как решаете эту проблему если она у вас конечно возникает?
Также ни ECS ни како-то другой сервис в AWS не предоставляет Service Discovery, даже в Гугле есть сервис метаданных, в AWS есть сервис по мэнеджменту сертификатов — что уже неплохо в нашем случае кое-какие вопросы решим… Но хотелось бы решить вопрос с конфигурацией Контейнеров в разных кластерах… Хочется не делать это в ручну через передавемы параметры сервису…
Вы это как-то решаете? Это тема для вас есть опыт? Я знаю про consul и нахожу интересным. Но это означает что надо начинать провизинонировать машины на уровне IaaS но у нас пока еще есть надежда что мы можем как-то польностью мимо это-го пройти, что-бы как можно больше предоставить AWS.
Как вы на это смотрите?
Более того имеет смысл использовать систему абстрагированую в принципе от маунтингда чего либо к одному хосту… в облаках это не делают…
Представьте что у вас 1000 > контейнеров
Но переде тем как переписать всю апплику хотелось найти что-то быстрое по середине как компромис. Пока у нас 3 контейнера, на след. неделе будет 7.
В перспективе >200 в этом году.
Но мы планиеруем на будущее и как можно меньше хочется полагаться на информацию с хостов и провизионировать туда…
Если использовать какой-нибудь kubernetes или у нас в данном случае AWS ECS то размещением контейнеров на хостах занимается scheduler
Поэтому краткосрочно мы решим это с привязкой к хосту или переменной. Но в дальнешем похоже надо будет написать клиент который будет забирать себе сертефикат и прочее откуда-нибудь…
Ктому же трафик между nginx и явой тоже должен быть подписал сертификатом…
На хабре часто так начинают и заканчивают в позивном или негативном…
Вы начали о введении каких-то инструментов и тулов вашу статью… Когда это совершено вторично…
Первично именно то что вы написали ниже:
Толькпо а что остается? Если в компании вводится ДевОпскультура то разве могут остаться какие-то куски IT за которую другие команды будут решать задачи DevOps Firefighters?
Не совсем ясно. Помоему это лишает смысла саму идею…
DevOps это глубокая трансформация тесно связаная с Time to Market, тоесть она служит каким то целям всей компании и коррелирует с другими идеями (Agile Methods) а не сама по себе самоцель.
Поидее все Dev и Ops должны трансформироваться в подобные комманды с различными скилами (cross-functional teams, T-shaped)
И это самое сложное, дело в организации, методах управления, мотивации и опыте людей.
А TeamCity, Гитлаб, Артифактори, Ансибле, Докер и облака, сами придут как следствия принятия технических решений умными enhabled командами — которой вы были наверно.
Вроде можно на стадии сборки добавить и корпоративный корневой сертификат так как keytool сохранен. Завтра будем пробовать…
Это позволит доверять SSL/ соединениям к серверма подпоисаным корневиком.
Но вот не придумали еще как быть с серверным сертификатом для SSL/TLS.
Ны портируем готовое приложение в облако…
Раньше сертификаты сервера устанавливались на машину а ява приложению просто передавался путь на кейстор, както-так.
А теперь все будет динамичнее, и не хочется вводить привязку к хосту в принципе.
Не совсем еще понятно куда класть сертфикаты сервера, особенно с учетом того что один и тот-же докер-имидж хочется тестировать на дев-энвайроменте и в продекшне…
Один из радикальных вариантов это запекать оба сертификата в Docker image и подставлять в зависимости от конфиги (дев, прод).
Другой вариант куда-то стучаться из стартующего контейнера шелскриптом перед запуском javы что-бы то куда постучались вернуло нужный серверный сертификат и ключ и он был положен в нужно еместо перед запуском апликухи…
Вот такие две версии крутятся. Может у вас есть опыт или идеи?
Ну не нужен он вам, не используйте.
Вот тут может о том почему это не замена виртуалке и не об этом вообще
http://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-normal-virtual-machine/25938347#25938347
Но вы решаете что такое «аппликация» и сколько процессов она должна стартануть что быть самодостаточной.
Приложения, сервиса… и не обезательно что это один процесс, хотя проще, да…
И вам решать что есть именно ваше приложение… Для микросервица очень вазжна акакрза его самодостаточность и его как можно меньшая зависимость от внешнего мира в плане конфигурации и прочих предположений о среде…
Вот теперь вспомнил почему я сделал по другому
я не хотел перемешивать окружения
и поэтому у меня выглядит так как описано тут:
http://toja.io/using-host-and-group-vars-files-in-ansible/
Очень важная фишка, зависимоти между ролями…
Надо использовать, тогда сами роли будут меньше и проще
Что нужно сделать что-бы работала следующая схема по переменным различающихся по stages?
Групповые (общие) переменные
В Плейбуках пропивывате пути к файлам с переменными?
Микросервисная архитектура позволяет писать хорошие тесты у базы пирамиды и многое ими покрывать и отлавливать…
Однако МСА переносит часть сложности в интеграционный слой… и это момент особого внимания в микросервисной архитектуре…
Тут все должно быть четко и понятно, тогда можно (и нужно) ограничится минимум правильно написаных интеграционных тестов.