При построении микросервисной архитектуры часто возникает потребность анализировать логи из нескольких источников (баз, сервисов и т. д.). В этой статье я бы хотел поделиться решением к которому в итоге пришел.

Управление конфигурациями позволяет автоматизировать и оптимизировать эти процессы, снижая риски человеческих ошибок и обеспечивая более высокую эффективность и безопасность систем.

В управлениях конфигурациями выделяются три крупных игрока: Puppet, Chef и Ansible. Все они предлагают мощные возможности, но каждый со своим уникальным подходом и философией.

Ведущие инструменты для управления конфигурацией по разному подходят к автоматизации серверов

В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.

В статье расскажу о том, почему архитектура стала такой, какой стала, а также расскажу, как реализовать подобный сценарий для вашей базы PostgreSQL.

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

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

В этой статье мы собираемся разобраться со следующими вопросами:

* Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у них есть отдельные сетевые среды?

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

* Как выйти во внешний мир (например, в Интернет) изнутри контейнера?

* Как связаться с контейнерами, работающими на хосте Linux, из внешнего мира?

* Как реализовать публикацию портов, подобную Docker?

Как известно, Docker умеет создавать виртуальные сети для безопасного и удобного сетевого взаимодействия внутри контейнеров. В этой статье мы рассмотрим, как именно он это делает на примере базовых манипуляций с сетью в рамках одного хоста с операционной системой Linux.

Сейчас без преувеличения можно сказать, что контейнеризация прочно вошла в нашу жизнь. Контейнеры используются в различных программных продуктах, начиная от микросервисов и заканчивая решениями ИБ, такими как песочницы. Однако, контейнеры не были бы столь удобным инструментом построения распределенной архитектуры, если бы они не могли взаимодействовать между собой, а также обмениваться данными с внешними сетевыми ресурсами. В этой статье мы подробно рассмотрим механизмы, позволяющие контейнерам работать с сетями.  

Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.

В предыдущей статье я рассказал, как Docker использует виртуальные интерфейсы Linux и bridge-интерфейсы, чтобы установить связь между контейнерами по bridge-сетям. В этот раз я расскажу, как Docker использует технологию vxlan, чтобы создавать overlay-сети, которые используются в swarm-кластерах, а также где можно посмотреть и проинспектировать эту конфигурацию. Также я расскажу, как различные типы сетей решают разные задачи связи для контейнеров, которые запущены в swarm-кластерах.

Я предполагаю, что читатели уже знают, как разворачивать swarm-кластеры и запускать сервисы в Docker Swarm. Также в конце статьи я приведу несколько ссылок на полезные ресурсы, с помощью которых можно будет изучить предмет в деталях и вникнуть в контекст обсуждаемых здесь тем. Опять же, буду ждать ваших мнений в комментариях.

Я познакомился с Docker довольно давно и, как и большинство его пользователей, был мгновенно очарован его мощью и простотой использования. Простота является основным столпом, на котором основывается Docker, чья сила кроется в легких CLI-командах. Когда я изучал Docker, я захотел выяснить, что происходит у него в бэкграунде, как вообще все происходит, особенно что касается работы с сетью (для меня это одна из самых интересных областей).

Я нашел много разной документации о том, как создавать контейнерные сети и управлять ими, но в отношении того, как именно они работают, материалов намного меньше. Docker широко использует Linux iptables и bridge-интерфейсы для создания контейнерных сетей, и в этой статье я хочу подробно рассмотреть именно этот аспект. Информацию я почерпнул, в основном, из комментариев на github-е, разных презентаций, ну и из моего собственного опыта. В конце статьи можно найти список полезных ресурсов.

Я использовал Docker версии 1.12.3 для примеров в этой статье. Я не ставил своей целью дать исчерпывающее описание Docker-сетей или написать полное введение в эту тему. Я надеюсь, что этот материал будет полезен для пользователей, и я буду рад, если вы в комментариях оставите обратную связь, укажете на ошибки или скажете, чего недостает.

Данная статья посвящена настройке и работе с Docker Swarm.

Swarm это стандартный оркестратор для docker контейнеров, доступный из «коробки», если у вас установлен сам docker.

Что нам потребуется для освоения:

Репликация PostgreSQL с опережающей записью (WAL) — ключевая концепция в высоконагруженных архитектурах, поскольку она позволяет создавать высокодоступные и отказоустойчивые системы баз данных.

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

Заметку написала моя коллега, орфография и пунктуация по возможности сохранены. В какой-то момент ей надоело вспоминать или гуглить как чистить мусор, который оставляет докер, его билды, образы и вольюмы, и она свела всё в одну заметку.

Как мне кажется, получилось довольно смешно. Всё написанное в статье выдумка, любые совпадения с реальным миром случайны, если вы вводите в консоль sudo или его аналог - вы делаете это на свой страх и риск. Слова, замененные на другие для соблюдения правил Хабра, выделил курсивом, но думаю всё поймут, что было в оригинале написано.

Подробное исследование методологии взлома протоколов WPA2-Personal / Enterprise и WPA3: какие атаки и уязвимости существуют, и какой инструментарий применяется для их эксплуатации.

Привет, Хабр!

Многие из вас наверное слышали о Home Assistant (HA) - система домашней автоматизации с открытым исходным кодом, которая прекрасно работает на различных аппаратных решениях и поддерживает операционные систем Linux, macOS, Windows. К сожалению, в списке поддерживаемых операционных систем нет FreeBSD. А как быть тем, кто уже имеет рабочий сервер для домашней автоматизации на FreeBSD и не хочет заморачиваться с установкой дополнительного оборудования для запуска Home Assistant? Тут два варианта решения проблемы: первое решение это использование виртуальной машины с поддерживаемой операционной системой для HA, что занимает некоторые ресурсы сервера и второй вариант это установка HA непосредственно на FreeBSD. Как вы понимаете, я пошел вторым путем (путь граблей и приключений) и об этом расскажу далее.

Хочу показать как развернуть готовый и полностью работающий стек мониторинга Grafana + Loki + Prometheus + Pushgateway + Promtail за пару минут (в прямом смысле этого слова), без необходимости устанавливать на машину дополнительное ПО (плагины docker и плагины логирования) и собирать логи со всех контейнеров машины (или сразу со всех нод, в случае с swarm).