Да, я вас понимаю. Kyverno или Gatekeeper, как инструменты категории policy engine, могут использоваться для широкого круга задач, в том числе и для мутации ресурсов.
Reloader просто более узкоспециализированный и достаточной стабильный инструмент и мне приходилось его использовать на проектах как раз в связке с ротацией секретов. Так что могу рекомендовать, если задача только в этом и не хочется заносить в кластер policy engine.
В репозитории external-secrets есть открытый issue с запросом на добавление функционала перезапуска workload при обновлении секрета.
Если секреты размещаются в Hashicorp Vault, то у них есть свой оператор, который в том числе умеет самостоятельно делать rollout restart для указанных в VaultStaticSecret/VaultDynamicSecret spec.RolloutRestartTarget kind и name.
Есть достаточно подробная статья по tw_reuse, tw_recycle, которая даёт четкое понимание что в их изменении может быть плохого или хорошего: TCP Time-Wait state Linux
Недавно мне помогла, когда настраивал haproxy для одной задачи.
Да, все верно. Graylog2 использует Elasticsearch для хранения лог данных и MongoDB для хранения конфигурации. По сути это Kibana+аналог logstash+alerting+аутентификация/авторизация.
То есть Elasticsearch и MongoDB можно развернуть сбоку, в желаемой конфигурации.
В итоге к этому и пришёл. С consul кластером, запущенным не в контейнерах, все прекрасно работает.
Кстати, на днях смотрел состояние Docker UCP. Там в качестве KV хранилища выступает etcd, развёрнутый в контейнере. И если делать разворачивать все по официальной инструкции все прекрасно работает до тех пор, пока не выполняешь шаг, необходимый для поддержки multi-host networking. Как только docker engine меняет настройки для использования etcd для хранения конфигурации overlay сетей все встаёт колом по той же самой причине, что и у меня с consul, до его запуска вне контейнера. Вот такая вот официальная документация.0
В процессе развертывания обнаружилась еще одна проблема. Для хранения метаданных multi-host network в Docker тоже используется Consul. В таком случае на тех хостах, где запускаются контейнеры c Consul Docker придется запускать без использования multi-host network. Так как до старта контейнеров с Consul Docker пытается обратиться к key-value store Consul и становится практически недоступным для управления. После старта контейнера все нормализуется.
Это накладывает ограничение на способы запуска контейнеров с Consul. Их придется запускать политикой restart=always. В случае использования systemd для старта контейнеров через docker run или любой другой init системы вы просто замучаетесь ждать, когда демон Docker среагирует на ваш запрос, так как в это время он будет постоянно пытаться подключится к кластеру Consul.
Так совпало, что я сейчас изучаю эту же тему со связкой Ansible+Consul+Docker Swarm. Вы используете для service discovery при построении кластера Docker Swarm подключение к Consul первый IP адрес в датацентре. В таком случае, при сбое этой ноды кластера Consul, у вас развалится кластер Docker Swarm. Это проверено на личном опыте. Правда я кластеризую еще и роль Docker Swarm Manager.
В issue репозитария Swarm на гитхабе разработчиков просили дать возможность указывать несколько адресов нод Consul, но это невозможно из-за ограничение go библиотеки клиента Consul, которая используется в коде Swarm. В итоге обсуждений пришли к решению использовать в качестве адреса подключение consul.service.consul. Если указать в качестве дополнительных DNS адресов на холстах в датацентре адреса нод кластера Consul, то в вашем случае consul.service.dc1.consul вернёт вам как раз «здоровые» ноды кластера Consul.
К сожалению я не успел проверить отказоустойчивость этого решения, так как в данный момент борюсь со связкой Ansible+VMware vSphere.
Да, я вас понимаю. Kyverno или Gatekeeper, как инструменты категории policy engine, могут использоваться для широкого круга задач, в том числе и для мутации ресурсов.
Reloader просто более узкоспециализированный и достаточной стабильный инструмент и мне приходилось его использовать на проектах как раз в связке с ротацией секретов. Так что могу рекомендовать, если задача только в этом и не хочется заносить в кластер policy engine.
Вместо Kyverno проще будет использовать stakater/Reloader.
В репозитории external-secrets есть открытый issue с запросом на добавление функционала перезапуска workload при обновлении секрета.
Если секреты размещаются в Hashicorp Vault, то у них есть свой оператор, который в том числе умеет самостоятельно делать rollout restart для указанных в VaultStaticSecret/VaultDynamicSecret
spec.RolloutRestartTargetkind и name.Понял, спасибо. К сожалению доступно только для Android платформы.
https://companion.home-assistant.io/docs/core/sensors#notification-sensors
Подскажите, а каким образом вы получаете в HA информацию о нотификации из приложений, чтобы потом включить режим «Курьер» у домофона?
У www.nuget.org IP адрес не в списке, у api.nuget.org-в списке.
TCP Time-Wait state Linux
Недавно мне помогла, когда настраивал haproxy для одной задачи.
То есть Elasticsearch и MongoDB можно развернуть сбоку, в желаемой конфигурации.
Кстати, на днях смотрел состояние Docker UCP. Там в качестве KV хранилища выступает etcd, развёрнутый в контейнере. И если делать разворачивать все по официальной инструкции все прекрасно работает до тех пор, пока не выполняешь шаг, необходимый для поддержки multi-host networking. Как только docker engine меняет настройки для использования etcd для хранения конфигурации overlay сетей все встаёт колом по той же самой причине, что и у меня с consul, до его запуска вне контейнера. Вот такая вот официальная документация.0
Это накладывает ограничение на способы запуска контейнеров с Consul. Их придется запускать политикой restart=always. В случае использования systemd для старта контейнеров через docker run или любой другой init системы вы просто замучаетесь ждать, когда демон Docker среагирует на ваш запрос, так как в это время он будет постоянно пытаться подключится к кластеру Consul.
В issue репозитария Swarm на гитхабе разработчиков просили дать возможность указывать несколько адресов нод Consul, но это невозможно из-за ограничение go библиотеки клиента Consul, которая используется в коде Swarm. В итоге обсуждений пришли к решению использовать в качестве адреса подключение consul.service.consul. Если указать в качестве дополнительных DNS адресов на холстах в датацентре адреса нод кластера Consul, то в вашем случае consul.service.dc1.consul вернёт вам как раз «здоровые» ноды кластера Consul.
К сожалению я не успел проверить отказоустойчивость этого решения, так как в данный момент борюсь со связкой Ansible+VMware vSphere.