Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

Не задумывались ли вы когда-нибудь над тем, чтобы знать о каждом входе на ваши сервера? Меня охватила такая же паранойя: а вдруг, когда я сплю, на мой сервер заходит домовой и творит там ужасы? Хотя логин на наши сервера и запрещен по паролю, а SSH-ключи есть только у меня, в любом случае это вызывает большие опасения.

В этой статье мы развёрнем через Terraform несколько серверов в Yandex.Cloud, а затем при помощи Ansible настроим необходимый софт на каждом сервере. У нас будет основной сервер c Loki (система агрегирования логов) и Grafana (инструмент для визуализации данных), на серверах, которые мы хотим отслеживать, будет установлен Promtail (агент для сбора и отправки логов). Мы разберёмся с тем, как отслеживать входы на сервер, а затем в удобном формате отправлять об этом уведомления в чат с помощью вышеуказанных сервисов.

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

Представляем перевод статьи, где подробно рассматриваются переменные Ansible.

В посте рассматриваются следующие Ansible модули loop: with_items, with_nested, with_subelements, with_dict.

Представляю вашему вниманию короткий обзор что же произошло в России и в мире в области цензуры интернета и того, как этому противостоят энтузиасты. На всякий случай напоминаю, что статья «Надежный обход блокировок в 2024: протоколы, клиенты и настройка сервера от простого к сложному» заблокирована на Хабре для пользователей из РФ, но по‑прежнему без проблем открывается через прокси/VPN с иностранных адресов. Ну а мы сейчас разберем, что же изменилось с тех пор.

Сегодня в программе: Замедление YouTube — проблемы с Google Cache или намеренное вредительство? Можно ли заблокировать Shadowsocks и как РКН смог это сделать? Новые транспорты в XRay: HTTPUpgrade и SplitTunnel. Новости из мира Tor, и многое другое.

Привет, друзья!

За свою практику программирования я успел написать множество малых, средних и крупных проектов, преимущественно в формате Telegram-ботов. Моя история началась с популярной на то время версии aiogram 2.24 (тех, кто в теме, поймут), а сейчас я полностью перешел на версию 3.x, о чем нисколько не жалею.

В этом посте я хочу начать делиться с вами своим опытом разработки Telegram-ботов через библиотеку aiogram. Сейчас вы читаете вводный пост по этой обширной, но на самом деле не такой уж и сложной теме. Если я увижу положительный отклик, то пойму, что эта информация вам полезна, и мы будем углубляться в разработку ботов все дальше и дальше.

Сегодня мы научимся:

Привет, Хабр, на связи Okko! У нас одна из самых больших медиатек в России, поэтому мы постоянно работаем над развитием алгоритмов поиска и рекомендаций. Новые фичи тестируются с помощью А/Б тестов. Количество фичей неустанно растет, поэтому было решено создать специальную платформу для проведения экспериментов. Она позволила бы удобно их заводить и настраивать, сплитовать трафик в онлайн-режиме и формировать результаты экспериментов.
Мы — команда разработки платформы экспериментов — посвятим цикл рассказов самому важному и сложному компоненту сервиса — сплитовалке трафика. В этой статье расскажем о небольших по сложности, но больших по значению оптимизациях в коде, которые мы сделали, чтобы разогнать нашу платформу до скорости ракеты 🚀

Введение

Какие цели у этого руководства:
Обеспечение доступа через VDS сервер используя технологии xray, посредством маршрутизатора Keenetic и скрипта Xkeen.

Кому предназначено:
Для людей, которые хотят решить поставленную задачу, не вдаваясь во все тонкости настройки, выполняя инструкции шаг за шагом.

Приветствую! Благодарю за подписки, лайки и прочий позитивный отклик на мою деятельность. Продолжим.

Мы уже обсудили:

Текстовые клавиатуры

Инлайн клавиатуры

Командное меню

Встроенные фильтры и магические фильтры

Собственные фильтры

А это значит, что из базы остаётся только разобраться с сообщениями и работой с медиа. После этого можно будет переходить к более сложным и серьёзным темам, таким как: оплаты в боте, мидлвари, fsm-состояния, админ-панели и прочее. Но это всё потом, а сегодня мы рассмотрим следующие темы:

Использование цепочек прокси серверов позволяет обойти различные ограничения при доступе к сетевым ресурсам. Для проксирования обычно используют SOCKS или HTTP прокси. Сетевой протокол сеансового уровня SOCKS позволяет пересылать пакеты от клиента к серверу через прокси-сервер прозрачно (незаметно для них) и таким образом использовать сервисы за межсетевыми экранами.

Перевод зарубежной статьи на тему уязвимостей в сетях 5G/6G и WiFi 6, а также о том, какие проблемы безопасности возникают при совместном использовании спектра этими сетями.

apt-get install dh-make devscripts cdbs libmysqlclient-dev libcurl4-gnutls-dev
wget sunet.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/1.8/zabbix-1.8.tar.gz
tar zxvf zabbix-1.8.tar.gz
cd zabbix-1.8
dh_make --createorig


Во времена популярности микросервисной архитектуры появляется все больше потребности в платформах и решениях для автоматизации сложных или нереализуемых вручную процессов. Например, когда нам нужно работать с высоконагруженными приложениями, имеющими свои крутые пики и просадки посещаемости, было бы очень сложно построить архитектуру без использования Docker-контейнеров (виртуальных машин), которые позволяют разбивать приложение на части, взаимодействующие друг с другом. Однако задача становится еще более сложной, если мы работаем с приложением, которое делится на другие приложения, которые в свою очередь разделены на контейнеры, и вся эта система обрабатывает миллионы запросов пользователей и хранит невообразимый объем информации.

Яркие примеры таких приложений: YouTube или Google. Естественно, на одной машине такие сервисы не развернуть, поэтому в архитектуре используются тысячи компьютеров, именуемых Нодами (worker node). Однако эти Ноды, как части общего механизма, могут выходить из строя, и тогда их нужно заново поднимать, более того, хорошо бы вообще постоянно мониторить каждый Нод и считывать его состояние. Выполнять такие задачи становится очень сложно вручную. И, возможно, именно для этих площадок, а может быть и нет, но Google разработала технологию Kubernetes, которая выполняет роль оркестрации контейнеров. Kubernetes следит за Нодами и поднимает те, что выходят из строя, но это не единственная ее задача. Технология также может отключать неиспользуемые Ноды, оптимизируя расход ресурсов.