Сегодня я хочу поговорить с вами про такую замечательную вещь как Point in time recovery (PITR) в PostgreSQL.

Механизм восстановления на определенную точку во времени работает таким образом – у нас есть базовый бэкап, созданный при помощи какой-либо утилиты создания бэкапов (например pg_basebackup), а также набор журнальных файлов, постепенно применяя (накатывая) который, мы можем восстановиться до указанной точки.

Звучит это довольно просто, но, как водится, в каждой простой вещи есть какие-то нюансы, вот о них мы сегодня с вами и поговорим.

Задача 2

• создание автономных бэкапов на отдельном сервере
• создание архива wal-файлов и создание бэкапов в этом режиме
• развёртывание реплики из бэкапа и настройка создания бэкапов с реплики
• различные варианты восстановления

В заголовке использовано слово сложной, под которым можно понимать все, что угодно. Утверждение о том, что 2 * 2 = 4, если вдуматься, тоже очень не просто. Но в данном случае всё банальнее. Речь идёт о ЕСКД, ГОСТ, ОСТ и тому подобных скучных терминах, отягчаемых бюрократической процедурой согласования.

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

Сразу решили, что попробуем сделать документацию актуальной, т.е. обойтись без покраски травы в зелёный цвет. И сразу решили, что это будет Asciidoc. Почему? Потому что из текстовых языков разметки для подготовки документации он наиболее функциональный, а разворачивать неповоротливые DITA и Docbook не хотелось.

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

Terraform за 15 дней (AWS/Yandex). День 1

Мы от простого к сложному, поднимем небольшую инфраструктуру на aws и Яндекс (актуальность последнего я думаю объяснять не нужно). Так что по итогу вы сможете сказать: “Я изучал terraform от простого к сложному”.

Я постараюсь добавить все необходимые ссылки на документации и доп. источники, так что вы сможете дополнить необходимые знания, но данный курс (если это можно так назвать) скорее рассчитан на тех, кто в общем знаком с облачными технологиями. Это не пособие по terraform. Цель - помочь новичкам в данном вопросе начать изучать IaC и облака в целом. Некий quick start в terraform.

Разрабатываете приложения с применением Apache Kafka? Мы собрали для вас статьи, которые помогут освоить инструмент, познакомят с рабочими кейсами с использованием ПО. Делимся пользой и свежими идеями, подборками книг и реализованными задумками.

Близится кожаная свадьба Роскомнадзора с Телеграмом, именно 16 апреля 2018 года начался крестовый поход, ставший фактически символом уничтожения интернета в России, хотя в глобальной войне, начавшейся в 2012 году, он был всего лишь ярким эпизодом.

Ковровые блокировки в исполнении РКН стали причиной появления на свет множества различных сервисов, помогающих пользователям сети выживать под бомбежками. Одним из них стал antifilter.download, позволяющий получать списки находящихся под блокировками IP-адресов. Далее пользователи сервиса могли использовать полученную информацию по своему усмотрению. Одно из таких усмотрений было описано в статье Настройка BGP для обхода блокировок, версия 3, без VPS, которая стала достаточно популярной в сети и породила несколько сотен пользователей сервиса.

Однако "Tempora mutantur et nos mutamur in illis". За прошедшие три года сервис пережил Alpharacks-gate, похоронивший вместе с собой практически все донаты, упирание в технические ограничения как следствие роста количества пользователей, упирание в те же ограничения как следствие взрывного роста количества ip-адресов в списке РКН... Да что только не пережил. Каждое из этих изменений приводило к небольшому устареванию предыдущей статьи и когда неделю назад один из хабраюзеров предложил мне поправить ее под текущие реалии, я понял, что проще родить нового, чем отмыть этого написать новую версию, заодно и ответив на часто задаваемые вопросы. Результат - ниже.

За 6 часов сделал первую версию игры и ворвался в тренды Твиттера с одного твита. Привлек 100 000 пользователей за неделю, а также попал в ведущие СМИ страны. Как это было и что я для этого сделал можно узнать в статье.

Смотри, ты устроился работать в большую компанию, где много команд, каждая разрабатывает свой продукт, часть из них создаёт микросервисы вокруг ядра, часть создаёт свои отдельные полноценные продукты. И, допустим, вся разработка до сих пор не использует централизованное хранение кода, работает без CI/CD и без наработок DevOps. Твоей первой задачей поставили организовать подход к хранению исходного кода в рамках всей компании. По секрету скажу, большие компании любят, когда используется единый подход, индивидуализм для бизнес-конвейеров всегда означает сложность управления сроками разработки, поставки и т.д. Задача, которая кажется простой на первый взгляд, всегда обрастает сложностями в нюансах.

Ты настроен на волну NotOps и в этой статье я постараюсь ответить на вопросы:

14 февраля 2022 года GitHub объявила о старте нативной поддержки диаграмм Mermaid.js в README-файлах GitHub. Нововведение помогло быстрее и эффективнее оформлять блок-схемы и графики для документации. До этого диаграммы вставлялись в виде изображений и если содержимое менялось, то надо было сначала нарисовать новое изображение, а потом вставлять его. Сейчас же можно просто исправить несколько строк в коде и система сгенерирует новый график.

Доклад Алексея Лесовского про то, что нового есть в PostgreSQL в плане мониторинга.

Охватывать Алексей будет 13 и 14 версии. Далее от его лица.

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.

Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

Если вы совсем ничего не знаете о Prometheus или хотите лучше разобраться в нем, в его экосистеме и всех взаимодействиях, эта статья как раз для вас.

Преамбула… Даная статья была написана ещё летом но, по независящим от автора причинам, немножко подзадержалась...

Однажды, жарким летним вечером, после очередной введённой в консоли браузера команды вида :set content.proxy socks://localhost:9050, автор сего опуса понял, что дальше так жить нельзя и пора приводить выход во всякие скрытосети, а заодно и обход блокировок имени известной организации к какому-то единому, для любого софта вообще и браузера в частности, «общему знаменателю». А как приводить? Разумеется так, чтобы прокси сервер сам «понимал», через какой вышестоящий прокси отправлять и принимать трафик в зависимости от введённого адреса. Вторая цель, вытекающая из первой, вышестоящие прокси могут работать либо как http, либо как socks и оба протокола должны поддерживаться входным прокси. Ну и сам софт должен быть более менее актуальным, что б в случае ошибок или «хотения фич», не приходилось грустно смотреть на одинокую репу на гитхабе, а то и вообще на каком-нибудь сорсфорже.
Итак цели поставлены!

Ни для кого уже не новость, что начиная с 2 ноября 2020 года Docker Hub ввел ограничения на скачивание образов: для анонимных пользователей он будет равен одной сотне за шесть часов, а для авторизованных пользователей будет зависеть от уровня подписки.

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