Если вы планируете работать с докер - меняйте ваше представление о том, как все должно работать.
процесс = контейнер.
процесс падает = падает контейнер, докер демон его перезапускает.
заббикс(тоже контейнер) мониторит докер и репортит о перезапуске контейнера
Если надо заббиксом снимать с основного процесса какие то метрики - порт откуда запрашивать метрики выставляется из контейнера на хост
Если процесс пушит метрики в заббикс - так еще проще, выставляем заббиксовый эндпойнт на хост
Если не строить внутри контейнера связку сервисов - ваша жизнь будет сильно легче. Конфигурация приложения не должна зависеть от конфигурации мониторинга этого приложения, а вы именно это пытаетесь построить.
Однако же,иногда есть потребность в таком запуске(несколько процессов внутри контейнера).
Крайне рекомендую вам почитать официальную документацию как это делать https://docs.docker.com/config/containers/multi-se...
Urbansamurai многие клауд вендоры имеют решения совместимые с S3 API. Это не значит что они работают точно так же как и AWS S3, особенности реализации могут играть важную роль.
добавлю еще: Если не получается разобраться, то вот вам статья хабраюзера zhovner в помощь
Мы в похожей конфигурации живем достаточно долго - с 2016 года и все работает как часы, правда используем eap-radius в интеграции с MS AD
Иван Шумов, не хочу с вами спорить, вы слишком категоричны.
Продукт жив и здравствует, нас вполне себе аффектили эти самые падения, но не аффектили наших клиентов.
и PhD на подписке шлет новости, так что :D
Иван, все зависит от того, как построено приложение.
Случаев падения региона полностью еще не было - падение одной AZ нам не страшно.
Регион был выбран по близости клиентам =)
Вообще (я, кстати, ни разу не девелопер, чтобы если вдруг что сослаться "у одного моего друга, не у меня, есть опыт работы с индексами в S3) в случае необходимости БД-подобных операций AWS всегда предлагал использовать БД в дополнение к S3
Например, хранить индекс в динамо (даже лямбдочки по автозаполнению динамы где то в доках AWS есть) - и уже с индексом работать батчами, следующей операцией читая предложенные объекты.
Однако же, динамо ограничен 100 объектами в батчах и размером выдаваемых объектов, так что и тут не все так однозначно.
Что, впрочем не мешает использовать какую нибудь другую БД вместо динамы
2. chef, ansible - да любой.
То, что терраформ может, скажем, темплейтировать файлы - не означает что он должен это делать всегда и везде. Тем более что делает он это плохо, а любой дополнительный ресурс - это вероятность зависимости которая тригернет пересоздание других ресурсов.
1. каждый логический слой - это отдельная папка с файлами терраформа. Терраформ всегда применяет все файлы лежащие в папке, если вы не задали таргет ключ в командной строке
Например, логический слой - элементы VPC(подсети, route tables, dhcp options и т.п.)
Логический слой - один сервис вашего приложения
Логический слой - все инфраструктурные сервисы, запускаемые с помощью нормально написанных модулей.
Здесь все обсуждаемо, поскольку если за activemq+rabbitmq отвечает одна команда - она может не задевая других делать применение изменений в своем слое.
Если это разные команды - возможно имеет смысл разнести, чтобы изменения одной команды не аффектили сервис другой команды.
Здесь нужно подходить логично и, впоследствие, итеративно решать проблемы возникающие из-за того распределения которое вы организовали.
Например, изначально мы запихали все инфраструктурные сервисы в один слой, но, все они были написаны в модулях и применялись через -target. В принципе, было норм.
Например, terraform apply -target='module.activemq' применял изменения только AMQ, даже если были реальные изменения в соседних rabbitmq, couchbase и т.п. модулях в этом же слое.
Впоследствие, мы неоднократно перераспределяли все сервисы по другим слоям, согласно зоне ответственности команд которые за них отвечают (например если rabbit уехал в другую команду из той, в которой он был изначально)
Отдельно хочется отметить, что большую попаболь в объединении сервисов в слоях доставляет корректность написанных модулей сервисов( напомню, что модули нужны, чтобы ваш препрод и прод запускались из одного кода и инфра изменения тестировались не на проде). Например, в нашем случае, один или два сервиса пересоздавались каждый раз, когда делался терраформ apply несмотря на то, что реальных изменений ни в сервисах ни в параметрах их не было - и приходилось постоянно таргетироваться на изменяемый сервис вместо того чтобы просто делать terraform apply в репозитории (валидация получившегося плана была просто адовой - куча изменений не имеющих отношения к тому, что реально должно поменяться). В нашем случае причиной было использование вполне определенных ресурсов терраформ, которые пересоздаются всегда. Например template_dir или local_file.
Приходится искать способы чтобы их не использовать.
Иван Шумов, Проблема в девопс :D
Любой девелопер должен следить за своим сервисом, в том числе выполнять преподготовленные терраформ модули для публикации своего сервиса\мейнтенанс работ. А для этого нужны CLI креды.
Генерировать access key\secret key и следить за тем что они регулярно меняются - это проблема для любого человека. С точки зрения безопасности заводить и следить за тем, что все регулярно обновляют свои креды - тот еще геморрой.
Гораздо более корректно - выписывать временные креды через соответствующие интерфейсы. Креды, которые гарантированно устареют и ты на это никак не повлияешь. Креды, которые не надо чистить - они сами удаляются. Креды, которые генерятся человеку, а не сервисному аккаунту, что исключает необходимость держать их постоянно.
Временные креды - решение. С гугловой авторизацией их сгенерить, чтобы не приходилось вычищать - проблема, хотя и (через задницу) решаемая. С реализацией в AWS SSO - тебе напрямую выдают временные креды соответствующие твоей роли. Это очень удобно, мы сейчас заняты вычищением всего того дерьма, что нагенерили жалкие 30 пользователей AWS за два года. CLI креды 450 дней от роду, "очень нужные".
Тоже не обнаружили удобного способа работы через CLI при использовании Auth через G-Suite. Даже питоновский скрипт писал который через формы вытягивал данные аутентификации гугловые и вбивал в переменные окружения сгенеренные accesskey secretkey и token, но это то еще удовольствие.
Однако, как обычно, не было бы счастья... Родительская компания решила уходить от гугла в microsoft в офисных приложениях.
Вследствие этого пользователи потеряли доступ к гуглу и нам пришлось переизобрести Single Sign On для наших нужд в AWS.
Теперь используем сервис AWS SSO с интеграцией каталога с AD (у нас свой, через AD connector, но можно использовать AWS Managed Microsoft AD) для каталога пользователей. Удобство - колоссальное. Прозрачный маппинг ролей и политик доступа на группы в AD, лёгкое добавление прав, временные (причем время жизни регулируется в политике на стороне AWS) креды для работы - залогинился в SSO, копипастой взял креды, в командную строку вбил и N часов работаешь с ними.
Идеальный сервис, на мой взгляд. К сожалению умеет только каталоги AD на данный момент. Но SSO через интеграцию с гуглом - и рядом не валялся.
я понимаю смысл pwd в буфер обмена быстро засовывать, немного.
Но зачем засовывать имя файла в буфер обмена, если вы все равно будете его печатать? Не проще сразу напечатать там где надо? Опишите кейс какой нибудь, пожалуйста
процесс = контейнер.
процесс падает = падает контейнер, докер демон его перезапускает.
заббикс(тоже контейнер) мониторит докер и репортит о перезапуске контейнера
Если надо заббиксом снимать с основного процесса какие то метрики - порт откуда запрашивать метрики выставляется из контейнера на хост
Если процесс пушит метрики в заббикс - так еще проще, выставляем заббиксовый эндпойнт на хост
Если не строить внутри контейнера связку сервисов - ваша жизнь будет сильно легче. Конфигурация приложения не должна зависеть от конфигурации мониторинга этого приложения, а вы именно это пытаетесь построить.
Однако же,иногда есть потребность в таком запуске(несколько процессов внутри контейнера).
Крайне рекомендую вам почитать официальную документацию как это делать https://docs.docker.com/config/containers/multi-se...