Нужно понимать принципиальную разницу подхода:

apt - установка из маленьких пакетов, вместе образующих большую и сложную систему, при этом софт может массово совместно использовать одни и те же файлы и библиотеки, благодаря чему экономится место на диске, оперативная память итд итп. Надо понимать, что apt - это пакетный менеджер для определённого вида пакетов (deb), хотя в своё время существовал вариант для rpm (может и сейчас существует, просто смысла в нём мало после появления yum).

snap - установка большого приложения со всеми зависимостями, которые никак не использует остальной софт на этом же компьютере. Отсюда тратится лишнее место на диске и в оперативной памяти. Зато никаких проблем с зависимостями, плюс snap работает в любых системах и не завязан на конкретный менеджер пакетов и собственно пакетный формат.

snap по большому счёту часто используют для установки тяжёлых приложений, которые может бысть сложно опакетить, особенно учитывая разнообразие присутствующих в мире дистрибутивов (debian/ubuntu и их клоны) разных версий. В то время как большинство штатного общеиспользуемого софта чаще распространяют в виде пакетов, идущих в составе дистрибутива или отдельно (в том числе в виде разных собранных под разные варианты систем пакетов).

Начнём с того, что 500 шт. каждые 5 с - это 100 запросов в секунду. Прокси будут баниться очень быстро при подобном трафике.

Далее, получение данных мегабыстро имеет смысл в автоматизированных системах торгов на фондовой бирже, а если это в телеграм человеку сливать, то он в любом случае будет реагировать намного медленнее этих 5 секунд. И зачем тогда так часто опрашивать? Если опрашивать с интервалом в 3 секунды, то товары будут приходить с опозданием в среднем 13 минут, максимум 25 минут, что для многих задач вполне приемлемо.

Советую поговорить с заказчиком ещё раз на тему того, что именно ему нужно.

Никак нельзя. Это же мечта любого спамера - чтобы пользователь не мог избежать действия.

1. Фильтровать по владельцу: iptables -m owner -h

2. Использовать cgroups и фильтровать по ним: iptables -m cgroup -h

3. Использовать отдельный network namespace без доступа в интернет: ip help netns

4. Использовать docker с none-сетью: docker run -it --net=none my_awesome_image_for_application

Никто не заставляет использовать docker, systemd, ansible и вообще какие угодно системы оркестрации и оптимизации. Необязательно делать шаблоны конфигов или кластерные конфигурации сервисов, необязательно использовать библиотеки настраиваемого логгирования, возиться с балансерами и реприцируемыми базами. Но люди это делают, значит, смысл всё-таки есть?

Опытный администратор не должен задавать вопрос "нужно ли это вообще?" и исходить из идей вида "любому специалисто в области DevOps нужно вот конкретно это и не нужно конкретно другое". Он должен сам понимать, в какой момент сложность его инфраструктуры достигает того состояния, при котором ей нужно то или иное усложнение. Не рассуждать о том, что консул вообще не нужен или остро необходим, а принять решение о том, что и когда ему нужно для решения практических задач. Прекрасно, что в современном мире существует множество инструментов, которые позволяют достаточно быстро делать различные полезные вещи.

Консул - это тоже инструмент. Вряд ли хоть кто-то использует его возможности целиком и полностью, тем более что никто не заставляет. Кому-то достаточно того, что у него все сервисы зарегистрированы в одном месте и из коробки имеют автоматическое DNS-имя вида NAME.service.consul. Кто-то использует kv-хранилище для хранения параметров, а кто-то хранит в нём секреты и целые конфиги, настраивает токены с различными acl и скрещивает всё это с consul-template. Вообще, необязательно использовать именно консул, есть и другие инструменты для подобных задач. Например, zk/etcd.

Консул чаще используют совсем не с ансиблом, а с инструментами оркестрации, в которых сервисы могут расширяться и сворачиваться, перезагружаться и мигрировать. Скажем, пусть у нас есть условный сервис rabbitmq на три ноды. Тогда у нас может быть три контейнера rabbitm{1..3}, при запуске они регистрируются в консуле скриптом запуска вместе с проверками, а далее consul отдаёт их все три в виде имени rabbitmq.service.consul. Если какой-то из них вдруг упадёт, consul оперативно это обнаружит и исключит из DNS проблемный узел. Если вдруг управляющий всем этим администратор или автоматическая система оркестрации посчитает нужным добавить новые узлы или перенести их куда-то ещё в кластере, то consul также отразит все нужные изменения. При этом использующее rabbitmq приложение должно будет знать только адрес rabbitmq.

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