Если у вас 1 сервер, то прекрасное решение. Но если их сотни, то куда проще добавить немного автоматизации в настройку и получить более удобный продукт.
Пакер ансиблом бутсрапит шаблон. Ну и всё равно может быть какой то кастом после поднятия вм. Обычно какая нибудь мелочь типа таймзоны, серверов нтп, адреса реджистри, управление ключами (техические учётки самого ансибла могут иметь политику обновления)
Вопрос, а можно ли будет обнаружение всех подключенных устройств к шлюзу делать в НА на этом протоколе?
И другой вопрос, если колбеков нет, то шлюз не сможет уведомлять НА о выполняемых автоматизациях/статусах zigbee устройств? Если настроены одновременно и в михоум и в НА одинаковые скрипты, то чтобы статус zigbee лампочки включенной через михоум из интернета отправился в НА.
Я всё таки считаю, что кросс ОС роли для простых вещей вроде настройки ссш или судо это удобно. Но только в том случае если вы используете immutable servers (неизменяемые сервера?), когда вы создали тераформом виртуалки из заранее известного шаблона ОС (а шаблон создан вами пакером который бутстрапит ансиблом), а потом универсальной ролью нтп меняете пару параметров и релоадите сервис. Если что-то пошло не так, удалить сервер и уведомить человека об ошибке. В подавляющем большинстве случаев, разницы в действиях не будет, разница будет только в именах пакетов, путей или именах юнитов системд.
Я бы делал чуть по другому. На бастион хосте бы получал сертификат и устанавливал его на нужном сервисе. Хотя я так и делаю. Свой PKI требует чтобы мы добавили СА на все устройства работающие с сервисом. Когда я приношу свой ноут или работаю удалённо, а так же на свой телефон я совсем не хочу добавлять СА, который не возможно защитить, как и подтверждать неизвестные мне сертификаты. Считаю что для всех сервисов бесплатное получение и обновление сертификата для SOHO и SMB сегмента от Let's Encrypt это хорошо.
Нет, вендорлоки с закрытыми исходниками это плохо. Если я открываю бизнес, то по началу у меня нет тысяч долларов на оплату всего софта (и не важно как он поставляется, саас или у себя). Если у меня развился бизнес из 1-2 человек до 50 то у меня тоже может не быть ещё тысяч баксов на софт, в этот момент могут появляться новые требования, разворачивать на своих\арендованных мощностях и кроме популярного гитлаба ничего не подходит. А потом менять гитлаб на битбакет совершенно не выгодно, но с другой стороны расширять функционал гитлаба выгоднее.
CI/CD интеграции с битбакетом ужасны, большинство ориентированы на гитхаб. Бамбу за его цену даже использовать не хочется.
Вообще никакой пульт не хочу. Я же не просто так беру все устройства с поддержкой zigbee/bt/wifi (rs485 через esp8266 через wifi для водосчётчиков и электросчётчика). В отличии от других решений, я хочу максимально на беспроводных технологиях построить всё. Квартира маленькая 48 квадратов. И хочу использовать только сяоми решения (исключения: регуляторы отопления, вентили водоснабжения, регуляторы тёплого пола, электромеханический замок, бризер, водосчётчики, электросчётчики). Увы стиралку, посудомойку, варочную плиту, вытяжку, духовку, холодильник, питьевой фильтр не по карману мне купить сейчас умными.
Заказал сегодня мини, купил комплект сяоми для умного дома, в прошлом году купил сяоми телек 55. Увы на телек через АПК пришлось ставить яндекс.радио и через голосовой поиск запускать. Алису на телек не поставить, из Алисы телек не включить/выключить, из Гугл ассистента телек не включается/выключается, совсем не хочу ик передатчик покупать. Готовлю проект автоматизации в новую квартиру, где запустил капитальный ремонт.
Вот бы колонка имела параметр места установки. А то в спальне одна колонка, в гостиной вторая, в обоих комнатах телеки сяоми. Хочется сказать: "Алиса, выключи телек/свет/кондей" и по месту установки она бы добавила контекст собственного местоположения спальня/гостиная. Ну и софт со станции портировали бы на андроид, чтобы на телек можно было поставить и рулить им как станцией ютубы/вкл/выкл/музыка/радио.
На Хабре полно статей для сравнения этих инструментов и даже больше. Не забывайте, что в комментариях бывает иногда даже больше информации, чем в самой статье. Не ленитесь читать сотни комментариев под статьями.
Я рад что вы любите гетерогенные инфраструктуры. Жаль что нам надо работать, а не изучать 100500 компонентов инфраструктуры, для собственного ЧСВ. Нужен быстрый онбординг, низкие требования к квалификации и делать максимум задач в самые сжатые сроки.
Из всего многообразия scm, puppet нравится больше всего. Жаль что ансибл проще (в одной такой статье можно весь ансибл описать) и везде где я работал, выгоднее использовать именно ансибл.
Как руководство относится к срокам, которые вы тратите на реализацию качественного функционала? У меня для переписывания шаблона под нджинкс ушёл целый рабочий день на шаблон, тестирование, оформление репозитория и добавление в zabbix share. Были несколько недовольно руководство, что я потратил на задачу день, а не 5 минут.
Кажется выражение "натягивать сову на глобус", здесь уместно. Настройка линтера делается один раз, правила хранятся в гите, как и инструкции/скрипты для эксплуатации в ide.
Вопрос, а можно ли будет обнаружение всех подключенных устройств к шлюзу делать в НА на этом протоколе?
И другой вопрос, если колбеков нет, то шлюз не сможет уведомлять НА о выполняемых автоматизациях/статусах zigbee устройств? Если настроены одновременно и в михоум и в НА одинаковые скрипты, то чтобы статус zigbee лампочки включенной через михоум из интернета отправился в НА.
Первая ссылка в гугле сразу дала нам более простое решение github.com/mdbraber/acmeproxy.
CI/CD интеграции с битбакетом ужасны, большинство ориентированы на гитхаб. Бамбу за его цену даже использовать не хочется.
За упоминание битбакет гореть вам в гиене огненной.
Вот бы колонка имела параметр места установки. А то в спальне одна колонка, в гостиной вторая, в обоих комнатах телеки сяоми. Хочется сказать: "Алиса, выключи телек/свет/кондей" и по месту установки она бы добавила контекст собственного местоположения спальня/гостиная. Ну и софт со станции портировали бы на андроид, чтобы на телек можно было поставить и рулить им как станцией ютубы/вкл/выкл/музыка/радио.
На Хабре полно статей для сравнения этих инструментов и даже больше. Не забывайте, что в комментариях бывает иногда даже больше информации, чем в самой статье. Не ленитесь читать сотни комментариев под статьями.
Я рад что вы любите гетерогенные инфраструктуры. Жаль что нам надо работать, а не изучать 100500 компонентов инфраструктуры, для собственного ЧСВ. Нужен быстрый онбординг, низкие требования к квалификации и делать максимум задач в самые сжатые сроки.
Из всего многообразия scm, puppet нравится больше всего. Жаль что ансибл проще (в одной такой статье можно весь ансибл описать) и везде где я работал, выгоднее использовать именно ансибл.
ufo awesome!
Кажется выражение "натягивать сову на глобус", здесь уместно. Настройка линтера делается один раз, правила хранятся в гите, как и инструкции/скрипты для эксплуатации в ide.
А почему в Нексус нельзя? Раз уж в заголовке написали, то в статье надо пояснить.