у helm есть опция -i — это позволяет установить релиз, если его нет.
Предпочитаю иметь свои vars.yml под разные среды, а не плодить кучу if.
Так же использую у себя конструкцию вида: - helm upgrade -i -f chart/vars.yml chart_name
- kubectl rollout status deploy || helm rollback chart_name 0 && exit 1
Немного упрощенно, там есть еще несколько шагов, но смысл в ролл бэке. Можно у хэлма использовать опцию wait, но она мне не нравится, так как не наглядна и иногда нужно делать цепочку из rollout status.
и в ней переопределить параметр запуска, создав файл с расширением .conf и параметром, который нужно добавить или переопределить.
И image для develop/master по комитам я бы не тегал, лучше для этого feature_ бранчи использовать и git tag для релизов. Это больше от реализации git flow у вас зависит, конечно.
Если у вас в домашней сети только один компьютер, то pfifo достаточно, только буфер дефолтный можно увеличить. Если же несколько устройств, то необходима очень pcq, это позволит в рамках одного класса трафика поделить полосу пропускания и нивелировать загрузку канала одним из устройств ( буферы тоже можно подкрутить, ну и бёрст по желанию).
2) Я думал над обнаружением через отдельный скрипт (поиск в dhcp, например, по имени/маку) и скармливать хосты через zabbix_send. Но, во-первых, мы от них постепенно отказываемся, во-вторых, большой необходимости в мониторинге этих устройств я пока не вижу ( данные о регистрациях собираю на АТС).
4) В дискавери можно возвращать несколько параметров, не только Line — имя линии, но и ее состояние. А потом по этому состоянию сделать фильтр регулярным выражением на вкладке фильтры.
Я подумываю написать статью о мониторинге OSPF в микротиках/cisco с помощью внешних скриптов, но очень сложно найти свободное время.
Почему не nginx в качестве прокси? Он легче и удобнее апача в этой роли. К тому же, если что-то пойдет не так, сервис не упадет после nginx reload.
Как я понял, на время выпуска сертификата certbot останавливает апач и запускает свой сервис для подтверждения сертификата — не очень удобно. Как быть, если за проксей несколько сайтов, certbot сам для них выпустит сертификаты?
У себя использую сервис продления в отдельном докер контейнере, как в этом примере — http://www.automationlogic.com/using-lets-encrypt-and-docker-for-automatic-ssl/
очень удобно.
Что на мой взгляд еще необходимо:
1) авторизация на веб-интерфейсе.
2) автообнаружение в сети шлюзов ( у них есть уникальный снмп?)
3) после обнаружения, цепляем к ним этот шаблон + переменную ip адреса или имени передаем в external check.
4) автообнаружение только линий со статусом «On»
Я у себя использую порядка 12 подобных устройств, возможно прикручу к ним подобный мониторинг.
Предпочитаю иметь свои vars.yml под разные среды, а не плодить кучу if.
Так же использую у себя конструкцию вида:
- helm upgrade -i -f chart/vars.yml chart_name
- kubectl rollout status deploy || helm rollback chart_name 0 && exit 1
Немного упрощенно, там есть еще несколько шагов, но смысл в ролл бэке. Можно у хэлма использовать опцию wait, но она мне не нравится, так как не наглядна и иногда нужно делать цепочку из rollout status.
Все переменные можно переопределить через , пользователя указать на прямую —
IP адрес APIPA для получение aws metadata с хоста. Он для всех машин одинаков.
gist.github.com/f41gh7/1ed0fcf6b7db9ca62e769ad0d004ff77
Пара замечаний:
Не надо так делать, при следующем обновление пакета докер перестанет работать, нужно создать директорию:
и в ней переопределить параметр запуска, создав файл с расширением .conf и параметром, который нужно добавить или переопределить.
И image для develop/master по комитам я бы не тегал, лучше для этого feature_ бранчи использовать и git tag для релизов. Это больше от реализации git flow у вас зависит, конечно.
Рад, что вы решили проблему!
4) В дискавери можно возвращать несколько параметров, не только Line — имя линии, но и ее состояние. А потом по этому состоянию сделать фильтр регулярным выражением на вкладке фильтры.
Я подумываю написать статью о мониторинге OSPF в микротиках/cisco с помощью внешних скриптов, но очень сложно найти свободное время.
Как я понял, на время выпуска сертификата certbot останавливает апач и запускает свой сервис для подтверждения сертификата — не очень удобно. Как быть, если за проксей несколько сайтов, certbot сам для них выпустит сертификаты?
У себя использую сервис продления в отдельном докер контейнере, как в этом примере — http://www.automationlogic.com/using-lets-encrypt-and-docker-for-automatic-ssl/
очень удобно.
Кстати, почему pfifo, а не pcq?
Что на мой взгляд еще необходимо:
1) авторизация на веб-интерфейсе.
2) автообнаружение в сети шлюзов ( у них есть уникальный снмп?)
3) после обнаружения, цепляем к ним этот шаблон + переменную ip адреса или имени передаем в external check.
4) автообнаружение только линий со статусом «On»
Я у себя использую порядка 12 подобных устройств, возможно прикручу к ним подобный мониторинг.