просто по структуре не предполагается что это будут использовать в "цельной" инфраструктуре.
да оно решает задачу "выкатить кластер". но не предполагает что этот код будет выкатываться на нее например на протяжении года.
И не предполагает что там кроме серверов посгреса будет что-то еще. Оно вероятно будет. но это будет уже другой набор плейбуков. в другой репе.
Насчет объемов системы - да в общем то нет. у нас типовая задача - развернуть что-то под заказчика. это "что-то" бывает как одним сервером так и сотней. причем с диким дрефом технологий вида - у нас там "mysql был, теперь нам посгрес нужен, и мемкешей. и ребит меняем на кафку."
Но у нас специфика несколько другая - мы работаем над чужими проектами.
Моя фраза "я предпочитаю" в первую очередь акцентирует внимание что я по умолчанию не экстраполирую своё мнение на всю команду и избегаю считать что оно единственно верное.
По поводу использования плейбуков разработчиками - обычно ими пользуется девопс-команда. влияние разработчиков на инфраструктуру обычно оборачивается в CI/CD.
Собственно мне и интересно как вы реализуете проект например из таких компонентов:
посгрес
кафка
эластик
мемкеш
php
десяток сервисов на golang
фронт на NUXT
балансировщик нагрузки
на три среды (prod, stage, test) с задачей сделать среды идентичными по настройкам (чтобы банально не окзалось "ой а на проде у нас по другому").
в нашем подходе это будет выглядеть как 1 репозиторий, 3 инвентаря + 1 плейбук + набор ролей. и возможность гонять ансибл через CI/CD для нивелирования дрейфа конфигурации.
По тому коду что я вижу выше мне кажется у вас не совсем "декларативный подход" и не совсем "IaC". Ну и общее впечатление - "слишком усложнено"
я лично предпочитаю немного другой подход. более декларативно, и зачастую вся инфраструктура - одним плейбуком при самодостаточных ролях которые и выступают "компонентами".
«Когда я закончу школу, я поступлю в университет на химический факультет. Но учиться там я буду заочно. А работать я пойду в магазин химических реактивов. Это моя мечта, и я сделаю все, что нужно, для того чтобы она осуществилась.»
И вот это грустно. В доброй и замечательной детской книге уже присутствует подход «с чем работаю то и имею».
В информационной безопасности есть такая штука как «air gap» оно же «воздушный зазор» означающее что сеть физически изолирована.
С вашим подходом там можно вайфай бридж поставить и говорить что «воздушный зазор» есть. :-)
Использую AnywhereUSB/14 с пачкой ключей. Нареканий нет. По моему уже сильно больше года аптайма у самой железки и сервера из-за ключей перезагружать не приходилось.
Какие версии прошивки и драйвера используете?
ПС: Использовать удаленный USB с ЭЦП кажется мне не очень правильной идеей. Токен с ЭЦП на мой взгляд должен полностью контролироваться человеком которому эта ЭЦП принадлежит.
На удивление в пассажирской авиации практически нет ситуаций требующих реакции за доли секунды. В основном требуется не паниковать и не нажимать на все что видишь. Даже при отказах на взлете счет идет не на доли секунды.
Вот в этой статье так же упоминается подобный метод оптимизации: habr.com/ru/post/443064
На мой взгляд его основным преимуществом на земле является не только и не столько снижение массы сколько снижение стоимости при использовании аддитивных технологий которым такая ячеистая структура фактически не добавляет сложности изготовления но снижает затраты.
Клапаны вероятно получаются компактней моторов. Собственно плюс пневматики в том что можно поставить один мощный насос и от него питать множество исполнительных механизмов.
Theoretical analysis shows the carbon nanotube springs could ultimately have an energy density — a measure of the amount of energy that can be stored in a given weight of material — more than 1,000 times that of steel springs, and comparable to that of the best lithium-ion batteries.
Теоретический анализ показывает, что пружины из углеродных нанотрубок могут в конечном итоге иметь плотность энергии (количество энергии, которое может храниться в данной массе материала) более чем в 1000 раз больше, чем у стальных пружин, и сравнимо с лучшими литий-ионными батареями.
Спасибо.
По примеру +/- так же получается, кроме того что мы не вводим сущность "компонента" и ограничиваемся ролями.
Не декларативно и не IaC - например https://github.com/vitabaks/postgresql_cluster/blob/master/
просто по структуре не предполагается что это будут использовать в "цельной" инфраструктуре.
да оно решает задачу "выкатить кластер". но не предполагает что этот код будет выкатываться на нее например на протяжении года.
И не предполагает что там кроме серверов посгреса будет что-то еще. Оно вероятно будет. но это будет уже другой набор плейбуков. в другой репе.
Насчет объемов системы - да в общем то нет. у нас типовая задача - развернуть что-то под заказчика. это "что-то" бывает как одним сервером так и сотней. причем с диким дрефом технологий вида - у нас там "mysql был, теперь нам посгрес нужен, и мемкешей. и ребит меняем на кафку."
Но у нас специфика несколько другая - мы работаем над чужими проектами.
Моя фраза "я предпочитаю" в первую очередь акцентирует внимание что я по умолчанию не экстраполирую своё мнение на всю команду и избегаю считать что оно единственно верное.
По поводу использования плейбуков разработчиками - обычно ими пользуется девопс-команда. влияние разработчиков на инфраструктуру обычно оборачивается в CI/CD.
Собственно мне и интересно как вы реализуете проект например из таких компонентов:
посгрес
кафка
эластик
мемкеш
php
десяток сервисов на golang
фронт на NUXT
балансировщик нагрузки
на три среды (prod, stage, test) с задачей сделать среды идентичными по настройкам (чтобы банально не окзалось "ой а на проде у нас по другому").
в нашем подходе это будет выглядеть как 1 репозиторий, 3 инвентаря + 1 плейбук + набор ролей. и возможность гонять ансибл через CI/CD для нивелирования дрейфа конфигурации.
как это будет выглядеть в вашей реализации?
По тому коду что я вижу выше мне кажется у вас не совсем "декларативный подход" и не совсем "IaC". Ну и общее впечатление - "слишком усложнено"
я лично предпочитаю немного другой подход. более декларативно, и зачастую вся инфраструктура - одним плейбуком при самодостаточных ролях которые и выступают "компонентами".
Можете рассказать почему вы пришли к созданию "компонентов" в виде плейбуков, а не задействовали для этих целей имеющийся механизм "ролей"?
reestr.minsvyaz.ru/reestr/77546
reestr.minsvyaz.ru/reestr/106992
reestr.minsvyaz.ru/reestr/130415
Ни Veeam ни Acronis в реестре нет. Хотя разработка у них вполне в России. Acronis на мой вопрос сказали что внесения в реестр в планах у них нет.
В том числе и на войне. Но к сожалению иногда приходится.
И вот это грустно. В доброй и замечательной детской книге уже присутствует подход «с чем работаю то и имею».
С вашим подходом там можно вайфай бридж поставить и говорить что «воздушный зазор» есть. :-)
Какие версии прошивки и драйвера используете?
ПС: Использовать удаленный USB с ЭЦП кажется мне не очень правильной идеей. Токен с ЭЦП на мой взгляд должен полностью контролироваться человеком которому эта ЭЦП принадлежит.
habr.com/ru/post/443064
На мой взгляд его основным преимуществом на земле является не только и не столько снижение массы сколько снижение стоимости при использовании аддитивных технологий которым такая ячеистая структура фактически не добавляет сложности изготовления но снижает затраты.
Совместно с 3D печатью это отрывает очень интересные перспективы. На стандартных технологиях производства он вероятно экономически не оправдан, но при печати кроме экономии массы еще позволит экономить материалы и время печати соответственно снизив стоимость изделия.
У них еще интересная статья есть: 3dtoday.ru/blogs/articoon/is-it-possible-to-perform-highquality-reverseengineering-and-topologic
Ну и ранее с подобным подходом встречался в автотрассировщике печатных плат TopoR, результаты тоже были весьма интересны.
news.mit.edu/2009/super-springs-0921