— Совсем хорошо: Проект опенсорсный, программа бесплатная для России, разработчики ядра системы живут в России.
Если не считать возможных репутационных плюсов, в этом нет никакого смысла:
Проект и так открытый, следовательно программа бесплатна для всех, кто осилит её собрать.
PR предлагаете принимать на основании гражданства (а иначе как сохранить «расовую чистоту» кода)?
Открытый код предполагает недискриминационное право для любого этот код форкнуть. Или тоже по только паспорту?
Живущие в России разработчики ядра автоматически становятся невыездными на весь период участия?
И главное: весь мир открытого софта космополитичен по своей природе, так зачем самостоятельно ограничивать сообщество по совершенно искусственному критерию? Чтобы что? «Назло бабушке уши отморожу»?
RAID1 ни в коем случае нельзя приравнивать к резервному копированию, хотя бы потому, что он не спасает ни от чего кроме отказа носителя.
Простой пример: вы словили шифровальщика. Как вам RAID1 восстановить данные, если обе копии даже пошифровались синхронно?
Используя chef/puppet + ansible можно устанавливать zabbix-agent на тысячи серверов и делать обновление продукта/бизнес-программы через blue-green deployment, rolling update не используя kubernetes.
А без дублирования инструментария, получается, всё это нельзя?
Из собственного опыта, к счастью, не могу. Но умозрительная ситуация напрашивается сама:
Одновременное исполнение Энсиблом и Шефом любых операций с пакетным менеджером приведёт к блокировке у кого-то из них. А в случае с pip'ом, я даже не хочу себе представлять, что получится. Как такого добиться при рационалных настройках? Да запросто! Надо просто выключить хост на сутки и «очень вовремя» включить, чтобы Энсибл «дозвонился» именно тогда, когда шеф втянул новые конфиги и радостно приступил к исполнению.
Тут ИМХО первичен другой вопрос: вот мы по сути дублируем инструментарий, а чтобы что?
Скорее именно артефакты, потому что с точки зрения каждой из систем всё будет «just as planned», но в реальности будет вообще всё что угодно кроме ожидаемого результата.
И да, про идемпотентность в таком случае лучше даже и не вспоминать.
Ни в коем случае не назову Chef серебряной пулей. Как минимум, он «странненький» в плане видимости функций. А ещё есть два способа подружить его с SELinux:
* отключить к чёртовой бабушке SELinux.
* совершенно непонятные танцы с capabilities и не только.
Золотые ваши слова. Я ведь теперь в кошмарах буду видеть инфраструктуру, в которой и Энсибл, и Шеф. Это не просто странно, а скорее даже debugging-driven debugging. К тому же бессмысленный и бесконечный.
Про «быстро похоронить»: когда я понял, что systemd понятнее наших ролей, а инвентори перевалил за третий килобайт и обзавёлся собственными README и TODO, мы с CTO сели и взгрустнули. Потом я показал тестовый стенд с Шефом.
Был кейс прямо вот по слайду: разворачивали инфраструктуру Энсиблом, но довольно быстро упёрлись в предел применимости (началось всё с танцев вокруг zabbix-proxy) и очень больно мигрировали на Шефа. Но смигрировали-таки и не пожалели. Сопровождение — когда инстансов становится больше тысячи (bare metal) клиент/агент не просто нужен, а очень-преочень нужен.
Вооот! Ну наконец-то хоть кто-то озвучил самый логичный юзкейс! Для ансибла самое годное применение это быстрые развёртывания и быстрые же похороны без малейших попыток сопровождения.
Информация по добавленной вендором уязвимости. Много-премного информации, девать некуда. Вы издеваетесь, да?
То есть я покупаю железку (и сервис тоже) под названием USG (Unified SECURITY Gateway) и получаю admin/admin эту вашу стыдобушку, которую давно уже знает не только Shodan? Ну ок, спасибо за каминаут.
Post mortem (в данном контексте) — это разбор инцидента с определением причин его возникновения и мер по предотвращению подобных инцидентов впредь.
Я не сказал бы, что это прямо вот необходимо, но было бы определённо полезно и для сообщества, и для имиджа компании.
Если не считать возможных репутационных плюсов, в этом нет никакого смысла:
И главное: весь мир открытого софта космополитичен по своей природе, так зачем самостоятельно ограничивать сообщество по совершенно искусственному критерию? Чтобы что? «Назло бабушке уши отморожу»?
Осталось придумать, в чём.
Есть подозрение, что всё целеполагание умещается в этом предложении.
Возможно не приравниваете, а спрашиваете, вот я и ответил.
2) Копия на втором диске того же хоста? Никак. Да её и бэкапом-то можно считать с некоторой натяжкой. Нормальный бэкап хранится независимо.
Простой пример: вы словили шифровальщика. Как вам RAID1 восстановить данные, если обе копии даже пошифровались синхронно?
А без дублирования инструментария, получается, всё это нельзя?
Одновременное исполнение Энсиблом и Шефом любых операций с пакетным менеджером приведёт к блокировке у кого-то из них. А в случае с pip'ом, я даже не хочу себе представлять, что получится. Как такого добиться при рационалных настройках? Да запросто! Надо просто выключить хост на сутки и «очень вовремя» включить, чтобы Энсибл «дозвонился» именно тогда, когда шеф втянул новые конфиги и радостно приступил к исполнению.
Тут ИМХО первичен другой вопрос: вот мы по сути дублируем инструментарий, а чтобы что?
И да, про идемпотентность в таком случае лучше даже и не вспоминать.
* отключить к чёртовой бабушке SELinux.
* совершенно непонятные танцы с capabilities и не только.
То есть я покупаю железку (и сервис тоже) под названием USG (Unified SECURITY Gateway) и получаю
admin/adminэту вашу стыдобушку, которую давно уже знает не только Shodan? Ну ок, спасибо за каминаут.Я не сказал бы, что это прямо вот необходимо, но было бы определённо полезно и для сообщества, и для имиджа компании.