у 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.

Вместо node_selector, рекомендую использовать daemonset + toleration. будет возможность гибче управлять количеством ingress only нод.

Интересное решение, спасибо!

это образец.
Все переменные можно переопределить через

ansible-playbook -e @vars.yml

, пользователя указать на прямую —

ansible-playbook -u

IP адрес APIPA для получение aws metadata с хоста. Он для всех машин одинаков.

Хорошая обзорная статья, радует подробное описание Docker TLS auth.

Пара замечаний:

$ nano /etc/systemd/system/multi-user.target.wants/docker.service

Не надо так делать, при следующем обновление пакета докер перестанет работать, нужно создать директорию:

nano  /etc/systemd/system/multi-user.target.wants/docker.service.d/ 

и в ней переопределить параметр запуска, создав файл с расширением .conf и параметром, который нужно добавить или переопределить.

И image для develop/master по комитам я бы не тегал, лучше для этого feature_ бранчи использовать и git tag для релизов. Это больше от реализации git flow у вас зависит, конечно.

Очень хотелось бы видеть и про безопасность. Можно было бы посвятить этому вторую статью в цикле, это бы отлично дополнило представленный материал! Так же могу подсказать идею для статьи, разделить средствами NPS политик Login, VPN Access, а так же Login и Wi-Fi auth. Это бы вписалось в концепцию безопасности.
Безопасность очень важный аспект, но ее слишком часто опускают для упрощения. В итоге получается интересная статья, но не применимая в боевых условиях.

Есть, не использовать Winbox для которого это требуется. У него слишком много минусов, например, пароли локально хранит в незащифрованном виде.

HTTPS web-interface, ssh более чем достаточно для управления.

Поддерживаю, strongswan отлично себя зарекомендовал.

По-крайней мере у себя, не замечал ситуации, где pci-dss влияет на коммуникацию.

+1 LLD лучший выход.

Тоже интересует за stp — смысл включать root-guard, если фильтр уже весит? И как после этого бороться с петлями?

Поразительный цикл статьей не о чем (:

Рад, что вы решили проблему!

Спасибо за хорошую статью. Отлично, overlay — логичное продолжение.

В какой части этого остросюжетного триллера эта проблема будет решена?)

Если у вас в домашней сети только один компьютер, то 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/
очень удобно.

QoS в микротике боль и страдания, когда у тебя несколько провайдеров, несколько тунелей…

Кстати, почему pfifo, а не pcq?

Интересная статья, спасибо за пример.

Что на мой взгляд еще необходимо:
1) авторизация на веб-интерфейсе.
2) автообнаружение в сети шлюзов ( у них есть уникальный снмп?)
3) после обнаружения, цепляем к ним этот шаблон + переменную ip адреса или имени передаем в external check.
4) автообнаружение только линий со статусом «On»

Я у себя использую порядка 12 подобных устройств, возможно прикручу к ним подобный мониторинг.