Может, продажи стационарных компьютеров растут в том числе благодаря им: Изображен: ip kvm Nanokvm
Не взирая на тот факт что Nanokvm - лютая годнота. Я все же не понимаю, каким образом благодаря ему вырастут продажи ПК? У скольки процентов людей вы видели ip kvm дома и для чего он им? Сколько по вашему людей знают о существовании подобного класса устройств вообще? Так что возросшая доступность этих устройств превратится в их покупку и вслед за ней покупку еще одного ПК? Использую nanokvm чтобы абменистрировать кампуктер родителей на расстоянии 700км от своего дома. Настолько ли это частый и востребованный кейс по вашему? Хотя даже в моём случае это не вылилось в покупку еще одного ПК.
Попытка везти живого человека вызывает только смех. Авторы такого проекта явно слабо себе представляют размеры необходимой замкнутой биосферы для удовлетворения потребностей 1 человека. И плохо понимают что формула циолковского всеравно работает, даже если ваш корабль с ядерным двигателем. И вот вы привезли живого человека, а там не кислорода, ни почвы, ни произошло избавленение от токсичных элементов. Что этот человек будет там делать? Задача доставить его туда - это не конец миссии. Нужно чтобы он смог основать там цивилизацию, в этом задача миссии. Поэтому вначале летят ГМО бактерии на небольших зондах, потом летят простейшие многоклеточные - лишайники, потом высшие растения, черви и насекомые, и только потом через 10 - 100 тысячь лет человек в виде эмбрионов, в составе с фабрикой по их выращиванию, воспитанию и обеспечению первых десятков поколений.
Рекомендую другое видео в формате презентации, а не беседы. Имхо там повествование гораздо более последовательное. У него есть еще художественная книжка: "Ковчег 47 Либра" - ровно на эту тему. Мне весьма доставила. Прочитал за 1 заход (она небольшая).
Это какой-то фэнтезийный идеалистический мир с эльфами и единорогами.
Всем выгодно если его подрежут.
Конечно не выгоднее. Тут всего 2 варианта:
Провайдер ограничит трафик и не будут обновлять оборудование/каналы. Просто пустит профит с ограничения в свой доход, если называть вещи своими именами.
Или не ограничит и провайдеру придется обновлять оборудование/каналы делая буквально всем пользователям лучше.
Пожалуй я с вами соглашусь. Это имеет смысл. Какая-то уже проф деформация, совсем не подумал что существуют проекты на 4 контнейнерах: postgres + backend + frontend + http proxy.
Делать коробки все в одном, имхо, для опенсорса это странное решение. Разумеется если это для кровавого ынтерпрайза, да еще если это проприетарь за бешеные доллары - тогда это база. Совеременные IT продукты довольно сложные, в них и без того много сущностей, источников разных событий, метрик, алертов и т.д. Если вы будете для метрик, алертинга, рисования графиков использовать свои велоспеды, то вы будете сильно увеличивать сложность вашего продукта.
Каноническим инструментов мониторинга и алертинга в современном IT является prometheus, отправщиком вебхуков - alertmanager, рисователем графиков - grafana. Почему бы не использовать их? Сколько времени можно съэкономить на отсутствии необходимости их разрабатывать и вникать в кустомные велосипеды при эксплуатации. А уж вопросы интеграции даже обсуждать нечего.
Сам типичный инстанс postgresql бекаплю 2мя независимыми путями (все деплоится и параметризуется через ansible (включая helm), все в контейнерах, частично в кубере):
PITR: wal-g для wal + shell обертка вокруг wal-g генерирующая prometheus метрики/статус для basebackup'ов + скрипт python генерирующий prometheus метрики о состоянии бекапов в хранилище (например о пропущеном сегменте или отсутствии изменений в течении периода) из вывода wal-g (да, используя exeс) + cronjob python восстанавливатеть бекапов с прогоном стандартных тестов (встроенный тест целостности и pg_dump > /dev/null) и пушатель результата в prometheus pushgw.
Архив: shell обертка вокруг restic: получение списка баз, последовательный бекап каждой базы (pg_dump | restic backup --stdin, т.е. без сохранения промежуточного состояния на диск) в отдельный репозиторий, экспорт prometheus метрик для каждой базы. Хочу когда-нибудь прикрутить восстновление и сюда. Но беда в том что для дампов нарушается прозрачность процесса восстановления. При восстановлении нужно чтобы были созданы например роли присутствующие в дампе. Не придумал красивого решения, как это не сопровождать и чтобы оно не ломалось.
Когда соберусь менять место работы попрошу разрешения работодателя заопенсорсить (больше для самого себя, использовать в будущем, не повторять эту работу). Сейчас увы нет времени и мотивации причесывать до такого состояния чтобы было не стыдно выкладывать в паблик.
Вы упустили важный момент в своём рассказе о zfs на linux. То что использование ARC кеша в linux происходит без отключения стандартного механизма кеширования linux. Таким образом одни и те же данные могут лежать в кеше linux и в ARC (а потом еще L2ARC). Так же это генерирует бестолковые копирования между этими слоями абстракций повышая нагрузку и латенси. Увы и ах, zfs для linux это сторонний продукт под несовместимой лицензией. Надежд что в последнем организуют механизмы позволяющие уйти от двойного кеширования - их буквально нет. Для этого, насколько я понимаю, нужно "всего лишь" переписать VFS. И этим точно никто и никогда не займется для какого-то левого проекта сбоку. Так что для zfs, как это не парадоксально для 2025, нужно использовать FreeBSD (хоть какая-то область крепко держится за этой старушкой). Особенно если предполагается использование исключительно как NAS или SAN.
Вы всерьез верите что кто-то выпускает с конвеера УР-100 в гражданском варианте? Зачем по вашему нужна ракета на гидразине + ат для граждан? Какие в этом плюсы? (с военкой понятно какие). Вам не кажется что все УР-100УНТТХ это перемаркированные и слегка доработанные УР-100? Поэтому ваш аргумент не проходит.
Вы придумали какое-то экзотическое употребление тегов для передачи с помощью них логики действия, а потому самостоятельно же победили свою же выдумку. Но зачем?
Статью в целом можно свести к 2 тезисам:
Не используйте теги в тасках ролей, используйте в плейбуках на уровне ролей.
Используйте членство в группах и переменные для управления ролями.
Но кажется что проблема кроется глубже:
Итак, лично мое мнение на этот счет такое. Теги в Ansible – это аналог оператора GOTO в инфраструктурном коде. В программировании оператор безусловного перехода (goto) давно считается плохим стилем.
Нет, конечно. Использую теги только над ролями и не понимаю о какой проблеме говорит автор? Если одним тегом помечается несколько ролей, то в плейбуке они и так перечисляются в порядке их преполагаемого выполнения. Где проблема?
Потому что он позволяет нарушить естественный порядок исполнения кода, делая программу трудно читаемой и сложно поддерживаемой, особенно при масштабировании и росте кодовой базы
Отсюда и растет непонимание. Ansible - это не программа с порядком исполнения, а набор шагов последовательно преводяший состояние к желаемому. Это никак не код с каким-то локальным контекстом из-за выскакивания/заскакивания из/в который так не любят goto. В идеальном ansible playbook никакого контекста нет вовсе (такого конечно не бывает на практике, но мы стремимся).
В мире Ansible аналогичную роль играют теги.
Нет. Теги играют роль ОПЕРАТИВНОГО (нужного не всегда, а в редких моментах) включения/отключения ролей при отладочном прогоне плейбука и при применении конкретных изменений. (например если мне нужно выкатить только изменения firewall, то я пишу --tag nftables (покрывающий одноименную роль) и получаю результат без ожидания прохода сотен тасок).
Отсутствие иерархии и дефолтных значений
А зачем мне иерария и дефолтные значения тагов если я ими только ОПЕРАТИВНО включаю/выключаю роли? Иерархия включения ролей уже есть в каждом play в ключе hosts, что разумеется наследуется. Дефолтные значения того чем нет необходимости постоянно пользоваться? Зачем?
Вы не можете просто взять и переопределить или структурировать теги при импорте чужого кода или при попытке интеграции в более крупный проект.
Это не имеет отношения только к тегам. Проблема в соглашении об именовании всех вообще сущностей в ansible. Аналогичные проблемы встречаются и с переменными. Возьмите какой-нибудь крупный проект (например kubespray) и посмотрите как там переменные называются.
Например, представьте плейбук с несколькими задачами, каждая из которых помечена разными тегами: install, config, deploy
Это неправильные границы разбития плейбука/ролей на задачи. Должна быть просто 1 роль: - { role: что_вы_там_запускаете }. Возможности дергать роль за потроха быть не должно.
если у вас есть аналогичные теги с таким же названием
А если будут аналогичные переменные? Что-то изменится? Ну так скорее будет хуже, таги - просто включат/выключат отдельные роли и сервер останется в корректном текущем/прерыдущем состоянии, а переменные - сломают состояние сервера.
Теги просто не позволяют установить чёткую иерархию и структуру исполнения.
Она написана в плейбуке. Зачем мне для этого еще и теги? Неудобно.
потом пытаемся получить предсказуемый результат, запуская их в неком произвольном сочетании.
Почему пытаемся? Вполне себе получаем. Тагируя только роли мы получаем ситуацию что прогон плейбука гарантированно корректно исполняется. Роли ведь не зависят друг от друга, а те которые зависят, помечаются одним тагом.
Вместо создания сценариев в виде плейбук, где каждая отвечает за отдельную часть процесса (например, nginx_install, nginx_configure, nginx_deploy), вы помечаете разные задачи тегами типа setup, configuration, deployment и т.п. В итоге получается код, который очень сложно поддерживать и масштабировать, так как задачи теряют контекст, превращаясь просто в набор абстрактных команд, запускаемых хаотично.
У вас какая-то ложная дихотомия или "аксиома Эскобара" ("что то... что это..."). Правильный выбор границ разбиения - { role: nginx }.
На практике, каждый новый тег удваивает число потенциальных комбинаций исполнения кода.
А какая разница как сильно растет это сочетание покуда таги не зависят друг от друга?
Допустим, у вас есть три задачи с тегами install, configure, start. Если мы используем все три тега в нашем коде автоматизации, то появляется не просто три сценария запуска, а восемькомбинаций: install, configure, start, install&configure, install&start, configure&start, install&configure&start
В очередно раз неправильная граница разбиения. Уже не смешно.
Можно выделить три условных плейбука: app_full_deploy app_packages_upgrade app_config
Снова неверные границы. Зачем? Вот так надо: { role: app }. Зачем мне плодить на каждую роль еще и несколько плейбуков? По вашему "Infrastructure as a bash history" работает только в отношении тагов? А в отношении 100500 плейбуков не работает? Почему? Нужно избавляться от сложности, а не переносить её в другую плоскость, где пока вы её не видите.
В эти плейбуки вы можете выборочно включать нужные файлы тасков или задавать гибкие критерии их запуска, используя различные инструменты ветвления кода (when, with_first_found, incude_tasks, tasks_from для ролей и т.п.)
Вот это уже просто пушка. Правильное использование тагов конечно же в 1000 раз лучше, чем оголтелое навязывание вместо них любых условных конструкций. (Не рекомендую для всех: но последнее время максимально отказываюсь от when, как раз чтобы было видно отсутствие ветвления. И использую вместо него "{{ obj | selectattr() }}" (и т.п. и в том же духе) так что запуск превращается в запуск над подмножеством, а не ответвлением.)
инструменты ветвления кода
С "оператора ветвления" в контексте ансибл... кекнул в голос.
Довольно неоднозначный вопрос. Есть заметная вероятность того, что Земная жизнь - это жизнь с Марса. Как нимимум потому что условия для возникновения жизни на Марсе появились раньше на пару сотен миллионов лет (он меньше и остывал быстрее). И по тому факту, что жизнь на Земле, внезапно, появилась сразу же после её остывания (остывания - это еще как сказать, например Luca (а это еще и не первый живой организм) жил при 80 градусов цельсия) без длительной до биогенной эволюции. Хотел ответить - да не смог.
Старт создания новой орбитальной станции запланирован на 2027 год.
А с "лунной станцией к 2015" уже закончили? Должно быть из-за старости её эксплуатация уже не рентабельна? Хотя бы научились не врать, уже прогресс. "Старт создания" будет успешно "запущен", не сомневаюсь (а саму станция вам никто и не обещал).
Ну может быть, например, желание посмотреть что же произойдет в конце? Особенно если ждать этого конца не придется долго. Или произнести сакральное: "Я же говорил!". :)
Зачем покупать ваш Сhа-rle=s Рr-0x-y? Чтобы в следующий раз обнаружить отправку личных данных в нем? Есть же свободный mitmproxy. Постоянно юзаю его в подобных кейсах, все устраивает. Чем он по вашему хуже?
Вы не поняли самого главного говоря про ботнеты. Возможность сканирования ботнетами новых устройств для их последующего заражения, собственно роста и формирования этого ботнета, она качественно ограничена гиганскими числами ipv6 адресов и, внезапно, пропускной способностью самого "интернет". Чтобы просканировать мой блок: нужно отправить (и принять) 48 (ipv6 ping) х 2^64 (моя сеть) = 8.854 х 10^20 байт трафика или 7.084 х 10^21 бит трафика. Полоса пропускания международных каналов интернет составляет 5 петаБит/c или 5 х 10^15 бит/c. Таким образом поделив 1 на 2 (= контролирую все магистральные каналы интернета) узнаем что это сканирование можно выполнить за 1.417 млн секунд или за 16 дней. И это тот случай когда вы целенаправленно сканируете только мою сеть отключив остальной интернет и вообще не имея никакой возможности маштабирования (никаких 100500 и близко нет). Но в реальности будет гораздо хуже.
Вы для начала должны попасть в мой занятый /64 блок, какой-то из занятых в /48 у конкретного провайдера. Надо понимать что 2^16 тоже довольно много и мало у каких провайдеров будет большая его заполненость.
Вам каким-то образом еще нужно получить этот ipv6 ботнет. Добавляя единицы устройств в месяц, а потом укладывая этими устройствами удаленный канал в полочку, вы врятли добьетесь ощутимого результата. Устройства "тормозящие интернет" будут обнаруживаться самими пользователями и их провайдерами и оперативно отключаться.
Я 10/8 параллельным nmap за 25 минут проходил в поисках принтеров с snmp-портом
А теперь попробуйте посканировать хотя бы денек внешний интернет. Ваш провайдет довольно быстро вам перезвонит.
Боюсь представить какие пополнения у ботнетов будут, если все устройства начнут светиться в дикий интернет, с учетом текущего уровня осведомленности пользователей.
Если говорить о переборе брутофорсом, то сразу понятно - никакие. Пользователям предлагается отдавать /64 от 128 битного пространства. Это 2^64 адресов или количество всех ipv4 адресов в квадрате. Если злоумышленик будет перебирать ваш блок со скоростью 1 млрд адресов в секунду (на секундочку надо канал 500Гбит/c), то ему потребуется 585 лет чтобы просканировать весь блок. Что-то мне подсказывает, что за это время ваше IoT устройство успеет не один раз сломаться и замениться устройством с другим маком и стало быть ip. Но по побочным канал конечно ipv6 будут часто утекать. Посредством просмотра трафика, посредством попадания логов в чужие руки, недобросовестных сервисов и т.д.
Использую Ansible + Terraform. Анлиблом делаю конфигурации не требующие трекинга ресурсов и генерю конфиги терраформа, терраформом - требующее трекинга. Пишу модули и фильтры для первого, поэтому подерживаю ansible код в достаточно декларативном стиле (императивный подход остается под капотом).
Концеп Pulumi вообще не понимаю. Помоему это тулза не нового поколения, это шаг назад в 70-80e к шелл портянам с размазаным по всему файлу контекстом выполнения и императивщиной в полный рост.
А вот это заявление:
появились привычные нам языки программирования... Go, .NET.
вызывает у меня опасения за тех кто это придумал, за их ментальное здоровье. Почему бы не пойти дальше? Где C, Fortran, Cobol... и asm разумеется?
Такое чувство что люди совершенно оторвались от реальности. Зачем вам интеграция инфраструктурной тулзы в ваш язык программирования, а особенно компилируемые? Вам что нужно запускать её раз в 100мкс? Точно нужно, да? А зачем? Ведь в противном случае задача решается самым прямым образом: запускайте самые обычные инструменты через exec. Это не настолько плохо как люди об этом думают, особенно если вы делаете это реже чем раз в секунды. Или если вы делаете не mvp колхоз, лишь бы заработало, и вам нужна изоляция, границы модулей - вот это все, то дергаете их по API (например ansible можно дергать через AWX или Semaphore, terraform тоже чем-то, вроде тоже через последний). Зачем миксовать в коде приложения принципильно разные сущности? Не понимаю.
А еще к вопросу безопасности, вы забиваете в свой код credentials позволяющие, допустим, управлять инстансами VM... Угадайте что произойдет если это сервис сломают? На каком количестве инстансов вылезет злоумышленик? Конечно, можно сделать и безопасно. Но это как будто бы вариант тем кому "нужны шашечки", в другом случае (обычная тулза по api) у тех кому "ехать" сразу работает достаточно безопасно.
Тезис про собственные языки ansible и terraform на мой взгляд ошибочен. Их нельзя сравнивать с обычными языками программирования - это dsl поверх стандартного формата сериализации. В ансибле точно можно юзать для сериализаци json вместо yml, в terraform вроде тоже можно json вместо hcl. Таким образом остается только ознакомиться с самим dsl, который очень простой, потому что ограниченный. Это близко нельзя сравнить с изучением языка программирования. Разные порядки сложности. Вобщем очередной раз не убедили.
Не взирая на тот факт что Nanokvm - лютая годнота. Я все же не понимаю, каким образом благодаря ему вырастут продажи ПК? У скольки процентов людей вы видели ip kvm дома и для чего он им? Сколько по вашему людей знают о существовании подобного класса устройств вообще? Так что возросшая доступность этих устройств превратится в их покупку и вслед за ней покупку еще одного ПК?
Использую nanokvm чтобы абменистрировать кампуктер родителей на расстоянии 700км от своего дома. Настолько ли это частый и востребованный кейс по вашему?
Хотя даже в моём случае это не вылилось в покупку еще одного ПК.
Потому что формула Циолковского.
Достаточно мощный двигатель (вместе с топливом) надо полагать будет примерно размером с Землю?
Попытка везти живого человека вызывает только смех. Авторы такого проекта явно слабо себе представляют размеры необходимой замкнутой биосферы для удовлетворения потребностей 1 человека. И плохо понимают что формула циолковского всеравно работает, даже если ваш корабль с ядерным двигателем.
И вот вы привезли живого человека, а там не кислорода, ни почвы, ни произошло избавленение от токсичных элементов. Что этот человек будет там делать? Задача доставить его туда - это не конец миссии. Нужно чтобы он смог основать там цивилизацию, в этом задача миссии.
Поэтому вначале летят ГМО бактерии на небольших зондах, потом летят простейшие многоклеточные - лишайники, потом высшие растения, черви и насекомые, и только потом через 10 - 100 тысячь лет человек в виде эмбрионов, в составе с фабрикой по их выращиванию, воспитанию и обеспечению первых десятков поколений.
Рекомендую другое видео в формате презентации, а не беседы. Имхо там повествование гораздо более последовательное.
У него есть еще художественная книжка: "Ковчег 47 Либра" - ровно на эту тему. Мне весьма доставила. Прочитал за 1 заход (она небольшая).
Это какой-то фэнтезийный идеалистический мир с эльфами и единорогами.
Конечно не выгоднее.
Тут всего 2 варианта:
Провайдер ограничит трафик и не будут обновлять оборудование/каналы. Просто пустит профит с ограничения в свой доход, если называть вещи своими именами.
Или не ограничит и провайдеру придется обновлять оборудование/каналы делая буквально всем пользователям лучше.
Пожалуй я с вами соглашусь. Это имеет смысл.
Какая-то уже проф деформация, совсем не подумал что существуют проекты на 4 контнейнерах: postgres + backend + frontend + http proxy.
Делать коробки все в одном, имхо, для опенсорса это странное решение. Разумеется если это для кровавого ынтерпрайза, да еще если это проприетарь за бешеные доллары - тогда это база.
Совеременные IT продукты довольно сложные, в них и без того много сущностей, источников разных событий, метрик, алертов и т.д. Если вы будете для метрик, алертинга, рисования графиков использовать свои велоспеды, то вы будете сильно увеличивать сложность вашего продукта.
Каноническим инструментов мониторинга и алертинга в современном IT является prometheus, отправщиком вебхуков - alertmanager, рисователем графиков - grafana. Почему бы не использовать их? Сколько времени можно съэкономить на отсутствии необходимости их разрабатывать и вникать в кустомные велосипеды при эксплуатации. А уж вопросы интеграции даже обсуждать нечего.
Сам типичный инстанс postgresql бекаплю 2мя независимыми путями (все деплоится и параметризуется через ansible (включая helm), все в контейнерах, частично в кубере):
PITR: wal-g для wal + shell обертка вокруг wal-g генерирующая prometheus метрики/статус для basebackup'ов + скрипт python генерирующий prometheus метрики о состоянии бекапов в хранилище (например о пропущеном сегменте или отсутствии изменений в течении периода) из вывода wal-g (да, используя exeс) + cronjob python восстанавливатеть бекапов с прогоном стандартных тестов (встроенный тест целостности и
pg_dump > /dev/null) и пушатель результата в prometheus pushgw.Архив: shell обертка вокруг restic: получение списка баз, последовательный бекап каждой базы (
pg_dump | restic backup --stdin, т.е. без сохранения промежуточного состояния на диск) в отдельный репозиторий, экспорт prometheus метрик для каждой базы. Хочу когда-нибудь прикрутить восстновление и сюда. Но беда в том что для дампов нарушается прозрачность процесса восстановления. При восстановлении нужно чтобы были созданы например роли присутствующие в дампе. Не придумал красивого решения, как это не сопровождать и чтобы оно не ломалось.Когда соберусь менять место работы попрошу разрешения работодателя заопенсорсить (больше для самого себя, использовать в будущем, не повторять эту работу). Сейчас увы нет времени и мотивации причесывать до такого состояния чтобы было не стыдно выкладывать в паблик.
Есть по существу сказать что не так и как на самом деле?
Двойного кеширования (ARC + page cache) zfs в linux нет?
OpenZFS (каноническая реализация zfs) лицензированна под gpl и вот вот войдет в ядро Linux?
zfs работает во FreeBSD хуже чем в Linux?
Вы упустили важный момент в своём рассказе о zfs на linux. То что использование ARC кеша в linux происходит без отключения стандартного механизма кеширования linux. Таким образом одни и те же данные могут лежать в кеше linux и в ARC (а потом еще L2ARC). Так же это генерирует бестолковые копирования между этими слоями абстракций повышая нагрузку и латенси.
Увы и ах, zfs для linux это сторонний продукт под несовместимой лицензией. Надежд что в последнем организуют механизмы позволяющие уйти от двойного кеширования - их буквально нет. Для этого, насколько я понимаю, нужно "всего лишь" переписать VFS. И этим точно никто и никогда не займется для какого-то левого проекта сбоку.
Так что для zfs, как это не парадоксально для 2025, нужно использовать FreeBSD (хоть какая-то область крепко держится за этой старушкой). Особенно если предполагается использование исключительно как NAS или SAN.
Вы всерьез верите что кто-то выпускает с конвеера УР-100 в гражданском варианте? Зачем по вашему нужна ракета на гидразине + ат для граждан? Какие в этом плюсы? (с военкой понятно какие).
Вам не кажется что все УР-100УНТТХ это перемаркированные и слегка доработанные УР-100? Поэтому ваш аргумент не проходит.
Вы придумали какое-то экзотическое употребление тегов для передачи с помощью них логики действия, а потому самостоятельно же победили свою же выдумку. Но зачем?
Статью в целом можно свести к 2 тезисам:
Не используйте теги в тасках ролей, используйте в плейбуках на уровне ролей.
Используйте членство в группах и переменные для управления ролями.
Но кажется что проблема кроется глубже:
Нет, конечно.
Использую теги только над ролями и не понимаю о какой проблеме говорит автор?
Если одним тегом помечается несколько ролей, то в плейбуке они и так перечисляются в порядке их преполагаемого выполнения.
Где проблема?
Отсюда и растет непонимание. Ansible - это не программа с порядком исполнения, а набор шагов последовательно преводяший состояние к желаемому. Это никак не код с каким-то локальным контекстом из-за выскакивания/заскакивания из/в который так не любят goto. В идеальном ansible playbook никакого контекста нет вовсе (такого конечно не бывает на практике, но мы стремимся).
Нет. Теги играют роль ОПЕРАТИВНОГО (нужного не всегда, а в редких моментах) включения/отключения ролей при отладочном прогоне плейбука и при применении конкретных изменений. (например если мне нужно выкатить только изменения firewall, то я пишу --tag nftables (покрывающий одноименную роль) и получаю результат без ожидания прохода сотен тасок).
А зачем мне иерария и дефолтные значения тагов если я ими только ОПЕРАТИВНО включаю/выключаю роли?
Иерархия включения ролей уже есть в каждом play в ключе hosts, что разумеется наследуется.
Дефолтные значения того чем нет необходимости постоянно пользоваться? Зачем?
Это не имеет отношения только к тегам. Проблема в соглашении об именовании всех вообще сущностей в ansible.
Аналогичные проблемы встречаются и с переменными. Возьмите какой-нибудь крупный проект (например kubespray) и посмотрите как там переменные называются.
Это неправильные границы разбития плейбука/ролей на задачи. Должна быть просто 1 роль:
- { role: что_вы_там_запускаете }. Возможности дергать роль за потроха быть не должно.А если будут аналогичные переменные? Что-то изменится?
Ну так скорее будет хуже, таги - просто включат/выключат отдельные роли и сервер останется в корректном текущем/прерыдущем состоянии, а переменные - сломают состояние сервера.
Она написана в плейбуке. Зачем мне для этого еще и теги? Неудобно.
Почему пытаемся? Вполне себе получаем. Тагируя только роли мы получаем ситуацию что прогон плейбука гарантированно корректно исполняется. Роли ведь не зависят друг от друга, а те которые зависят, помечаются одним тагом.
У вас какая-то ложная дихотомия или "аксиома Эскобара" ("что то... что это...").
Правильный выбор границ разбиения -
{ role: nginx }.А какая разница как сильно растет это сочетание покуда таги не зависят друг от друга?
В очередно раз неправильная граница разбиения. Уже не смешно.
Снова неверные границы. Зачем?
Вот так надо:
{ role: app }.Зачем мне плодить на каждую роль еще и несколько плейбуков?
По вашему "Infrastructure as a bash history" работает только в отношении тагов? А в отношении 100500 плейбуков не работает? Почему?
Нужно избавляться от сложности, а не переносить её в другую плоскость, где пока вы её не видите.
Вот это уже просто пушка.
Правильное использование тагов конечно же в 1000 раз лучше, чем оголтелое навязывание вместо них любых условных конструкций. (Не рекомендую для всех: но последнее время максимально отказываюсь от when, как раз чтобы было видно отсутствие ветвления. И использую вместо него "{{ obj | selectattr() }}" (и т.п. и в том же духе) так что запуск превращается в запуск над подмножеством, а не ответвлением.)
С "оператора ветвления" в контексте ансибл... кекнул в голос.
Думаю 10 кеков/10
Довольно неоднозначный вопрос.
Есть заметная вероятность того, что Земная жизнь - это жизнь с Марса. Как нимимум потому что условия для возникновения жизни на Марсе появились раньше на пару сотен миллионов лет (он меньше и остывал быстрее). И по тому факту, что жизнь на Земле, внезапно, появилась сразу же после её остывания (остывания - это еще как сказать, например Luca (а это еще и не первый живой организм) жил при 80 градусов цельсия) без длительной до биогенной эволюции.
Хотел ответить - да не смог.
А с "лунной станцией к 2015" уже закончили? Должно быть из-за старости её эксплуатация уже не рентабельна?
Хотя бы научились не врать, уже прогресс. "Старт создания" будет успешно "запущен", не сомневаюсь (а саму станция вам никто и не обещал).
Ну может быть, например, желание посмотреть что же произойдет в конце? Особенно если ждать этого конца не придется долго.
Или произнести сакральное: "Я же говорил!". :)
Подскажите показания на термометре инвестиционного климата в ИТ?
Зачем покупать ваш Сhа-rle=s Рr-0x-y? Чтобы в следующий раз обнаружить отправку личных данных в нем?
Есть же свободный mitmproxy. Постоянно юзаю его в подобных кейсах, все устраивает.
Чем он по вашему хуже?
Вы не поняли самого главного говоря про ботнеты. Возможность сканирования ботнетами новых устройств для их последующего заражения, собственно роста и формирования этого ботнета, она качественно ограничена гиганскими числами ipv6 адресов и, внезапно, пропускной способностью самого "интернет".
Чтобы просканировать мой блок: нужно отправить (и принять) 48 (ipv6 ping) х 2^64 (моя сеть) = 8.854 х 10^20 байт трафика или 7.084 х 10^21 бит трафика.
Полоса пропускания международных каналов интернет составляет 5 петаБит/c или 5 х 10^15 бит/c. Таким образом поделив 1 на 2 (= контролирую все магистральные каналы интернета) узнаем что это сканирование можно выполнить за 1.417 млн секунд или за 16 дней. И это тот случай когда вы целенаправленно сканируете только мою сеть отключив остальной интернет и вообще не имея никакой возможности маштабирования (никаких 100500 и близко нет). Но в реальности будет гораздо хуже.
Вы для начала должны попасть в мой занятый /64 блок, какой-то из занятых в /48 у конкретного провайдера. Надо понимать что 2^16 тоже довольно много и мало у каких провайдеров будет большая его заполненость.
Вам каким-то образом еще нужно получить этот ipv6 ботнет. Добавляя единицы устройств в месяц, а потом укладывая этими устройствами удаленный канал в полочку, вы врятли добьетесь ощутимого результата. Устройства "тормозящие интернет" будут обнаруживаться самими пользователями и их провайдерами и оперативно отключаться.
А теперь попробуйте посканировать хотя бы денек внешний интернет. Ваш провайдет довольно быстро вам перезвонит.
Если говорить о переборе брутофорсом, то сразу понятно - никакие.
Пользователям предлагается отдавать /64 от 128 битного пространства. Это 2^64 адресов или количество всех ipv4 адресов в квадрате.
Если злоумышленик будет перебирать ваш блок со скоростью 1 млрд адресов в секунду (на секундочку надо канал 500Гбит/c), то ему потребуется 585 лет чтобы просканировать весь блок. Что-то мне подсказывает, что за это время ваше IoT устройство успеет не один раз сломаться и замениться устройством с другим маком и стало быть ip.
Но по побочным канал конечно ipv6 будут часто утекать. Посредством просмотра трафика, посредством попадания логов в чужие руки, недобросовестных сервисов и т.д.
А в качестве MCU + zigbee приемопередатчика если не секрет что?
Использую Ansible + Terraform.
Анлиблом делаю конфигурации не требующие трекинга ресурсов и генерю конфиги терраформа, терраформом - требующее трекинга. Пишу модули и фильтры для первого, поэтому подерживаю ansible код в достаточно декларативном стиле (императивный подход остается под капотом).
Концеп Pulumi вообще не понимаю.
Помоему это тулза не нового поколения, это шаг назад в 70-80e к шелл портянам с размазаным по всему файлу контекстом выполнения и императивщиной в полный рост.
А вот это заявление:
вызывает у меня опасения за тех кто это придумал, за их ментальное здоровье. Почему бы не пойти дальше? Где C, Fortran, Cobol... и asm разумеется?
Такое чувство что люди совершенно оторвались от реальности. Зачем вам интеграция инфраструктурной тулзы в ваш язык программирования, а особенно компилируемые? Вам что нужно запускать её раз в 100мкс? Точно нужно, да? А зачем? Ведь в противном случае задача решается самым прямым образом: запускайте самые обычные инструменты через exec. Это не настолько плохо как люди об этом думают, особенно если вы делаете это реже чем раз в секунды. Или если вы делаете не mvp колхоз, лишь бы заработало, и вам нужна изоляция, границы модулей - вот это все, то дергаете их по API (например ansible можно дергать через AWX или Semaphore, terraform тоже чем-то, вроде тоже через последний). Зачем миксовать в коде приложения принципильно разные сущности? Не понимаю.
А еще к вопросу безопасности, вы забиваете в свой код credentials позволяющие, допустим, управлять инстансами VM... Угадайте что произойдет если это сервис сломают? На каком количестве инстансов вылезет злоумышленик? Конечно, можно сделать и безопасно. Но это как будто бы вариант тем кому "нужны шашечки", в другом случае (обычная тулза по api) у тех кому "ехать" сразу работает достаточно безопасно.
Тезис про собственные языки ansible и terraform на мой взгляд ошибочен. Их нельзя сравнивать с обычными языками программирования - это dsl поверх стандартного формата сериализации. В ансибле точно можно юзать для сериализаци json вместо yml, в terraform вроде тоже можно json вместо hcl. Таким образом остается только ознакомиться с самим dsl, который очень простой, потому что ограниченный. Это близко нельзя сравнить с изучением языка программирования. Разные порядки сложности.
Вобщем очередной раз не убедили.