Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret "Инструменты создания бэкапов PostgreSQL" . В конце обновленная сводная таблица по инструментам

Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.

Прим. перев.: Эта статья входит в состав опубликованных в свободном доступе материалов проекта learnk8s, обучающего работе с Kubernetes компании и индивидуальных администраторов. В ней Daniele Polencic, руководитель проекта, делится наглядной инструкцией о том, какие шаги стоит предпринимать в случае возникновения проблем общего характера у приложений, запущенных в кластере K8s.



TL;DR: вот схема, которая поможет вам отладить deployment в Kubernetes:

Классический вопрос, с которым разработчик приходит к своему DBA или владелец бизнеса — к консультанту по PostgreSQL, почти всегда звучит одинаково: «Почему запросы выполняются на базе так долго?»

Традиционный набор причин:

• неэффективный алгоритм
  когда вы решили сделать JOIN нескольких CTE по паре десятков тысяч записей
• неактуальная статистика
  если фактическое распределение данных в таблице уже сильно отличается от собранной ANALYZE'ом в последний раз
• «затык» по ресурсам
  и уже не хватает выделенных вычислительных мощностей CPU, постоянно прокачиваются гигабайты памяти или диск не успевает за всеми «хотелками» БД
• блокировки от конкурирующих процессов

И если блокировки достаточно сложны в поимке и анализе, то для всего остального нам достаточно плана запроса, который можно получить с помощью оператора EXPLAIN (лучше, конечно, сразу EXPLAIN (ANALYZE, BUFFERS) ...) или модуля auto_explain.

Но, как сказано в той же документации,

«Понимание плана — это искусство, и чтобы овладеть им, нужен определённый опыт, …»

Но можно обойтись и без него, если воспользоваться подходящим инструментом!

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

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

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

Итак, сегодня Mikrotik (RouterOS), Suricata 4.1, Elasticsearch+Filebeat+Kibana 6.5.

Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».

Буду рассматривать следующие аспекты производительности виртуальных машин:

• CPU,
• RAM,
• DISK,
• Network.

Начну с CPU.

Для анализа производительности нам понадобятся:

• vCenter Performance Counters – счетчики производительности, графики которых можно посмотреть через vSphere Client. Информация по данным счетчикам доступна в любой версии клиента (“толстый” клиент на C#, web-клиент на Flex и web-клиент на HTML5). В данных статьях мы будем использовать скриншоты из С#-клиента, только потому, что они лучше смотрятся в миниатюре:)
• ESXTOP – утилита, которая запускается из командной строки ESXi. С ее помощью можно получить значения счетчиков производительности в реальном времени или выгрузить эти значения за определенный период в .csv файл для дальнейшего анализа. Далее расскажу про этот инструмент подробнее и приведу несколько полезных ссылок на документацию и статьи по теме.

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

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

Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.

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

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

• Хотите скрыть наличее у вас некоторых сервисов?
• В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
• Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
• SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!


А ведь могло быть по-другому. Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать. Нет надобности срочно ехать на работу и восстанавливать сервер БД. Выяснение причин сбоя и работы по восстановлению спокойно переносятся на рабочий понедельник.

Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL. Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync.

В связи с последними событиями в России хочу рассказать вам о классном self-hosted VPN-сервере. После простой установки, без особого труда и углубленных знаний вы сможете создавать пользователей, генерировать VPN-профили и смотреть графики использования сети.

А обеспечив VPN-подключением себя и ваших близких, вы можете попробовать разделить траты за виртуальный сервер с вашими друзьями и знакомыми.

В результате чего пятидоллоравая VPS'ка может превратится в мощный инструмент обхода блокировок

В данный момент инсталяция по данному мануалу работать не будет. Из за больших изменений API Kubemaster, в данный момент я готовлю новый цикл статей где будут рабочие версии мануалов
Первая из статей habr.com/ru/post/462473

Здравствуйте!

В данной публикации я хотел бы рассказать о кластере Kubernetes с высокой доступностью (HA).



Оглавление:

1. Вступление
2. Список используемого софта
3. Список и назначение хостов
4. Принцип работы и развертывания
5. Подготовка ОС к развертыванию. Установка docker, kubeadm, kubelet и kubectl
6. Подготовка конфигурационного скрипта
7. Создание etcd кластера
8. Инициализация мастера с помощью kubeadm
9. Настройка CIDR
10. Инициализация остальных мастернод
11. Настройка keepalived и виртуального IP
12. Добавление рабочих нод в кластер
13. Установка ingress-nginx
14. Дополнительно
    
    • Dashboard
    • Heapster
    
    

Краткая шпаргалка:

HOST1: ip link add grelan type gretap  local <IP1> remote <IP2>
HOST1: ip link set grelan up
HOST1: iptables -I INPUT -p gre -s <IP2> -j ACCEPT
HOST2: ip link add grelan type gretap local <IP2> remote <IP1>
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s <IP1> -j ACCEPT

Четыре команды на туннель и две на firewall (не нужны если трафик между своими серверми уже разрешен)
Это всё что нужно, дальше длинное объяснение с подробностями.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Загрузочная флешка с набором нужного софта — замечательный инструмент системного администратора. Казалось бы, что может быть лучше? А лучше может быть загрузочный сервер!

Представьте, вы выбрали в BIOS загрузку по сети и можете установить ОС/вылечить компьютер от вирусов/реанимировать диски/протестировать ОЗУ/etc с PXE Boot сервера, ведь это куда удобнее, нежели бегать с флешкой от машины к машине.
А в случае большого компьютерного парка, такой инструмент и вовсе незаменим.

Вот такое меню встречает нашу команду инженеров при загрузке с PXE



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

Abstract: как заставить себя изучить любую из существующих систем конфигураций и перестать редактировать файлы на сервере руками.

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

Введение для отшельников, которые не слышали что такое configuration management systems

Уже многие годы (по айтишным меркам — три поколения как) существуют программы, которые позволяют автоматизировать процесс конфигурации серверов. Все эти программы сложные, они вторгаются в святую святых администраторов и заставляют их делать "всё не так, как раньше". Их изучение и интернализация (признание, что "так надо и так правильно") — абсолютный must have в карьере любого системного администратора.

Главная боль любой системы управления конфигурациями

Главная боль состоит в том, что система управления конфигурациями ломает привычную автоматику пальцев. Раньше вы могли поднять веб-сервер за 2 минуты почти не глядя на экран. Теперь вам предлагают потратить на абсолютно те же самые действия минут 15-20 (если вы хорошо знаете систему управления конфигурациями) или даже несколько дней (!!!!!), если вы её изучаете.

Это преступление против личной эффективности. Уменьшить её в десять (0xA) раз — и это они называют прогрессом?

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback'ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

Итак, начнём!

Привет, хабрчане! Какой бы заезженной не была тема создания телеграм бота на python3, я не нашёл инструкций, где показан путь от первой строчки кода до деплоинга бота (по крайней мере все методы, что я видел, немного устарели). В этой статье я хочу показать процесс создания бота от написания BotFather-у до деплоинга бота на Heroku.

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

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


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

TL;DR Можно уместить полноценный Linux Live дистрибутив в один файл, если вкомпилировать в ядро initramfs с корневой файловой системой. Компьютеры с UEFI умеют загружать такой файл напрямую, без помощи загрузчика типа GRUB. У меня получилось уместить дистрибутив с программами aircrack-ng, reaver и драйверами для карт Wi-Fi в файл размером 12 мегабайт (наверняка можно еще меньше).

Основные преимущества

• Работает на любых компьютерах с UEFI — один и тот же файл будет работать на PC и Mac.
• Не требует установки — достаточно скопировать один файл на EFI-раздел диска и указать в переменных NVRAM путь к этому файлу.
• Не нужно устанавливать загрузчики GRUB, rEFInd — ядро Linux собранное с поддержкой EFI Stub можно грузить напрямую без промежуточного загрузчика.
• Не нужны USB-флешки — скопированный на раздел EFI дистрибутив остается там навсегда, и его можно будет загрузить в любой момент. Он не занимает места на разделе основной системы, так как раздел EFI не используется в ОС.
• Не изменяет процесс загрузки — систему можно загрузить один раз, без изменения порядка загрузки в настройках UEFI. Следующая перезагрузка компьютера загрузит обычную операционную систему. Никаких следов Linux в очередности загрузки не останется.
• Совместимо с шифрованием диска FileVault и т.д. — файл копируется на EFI System Partition, специальный зарезервированный раздел диска. В компьютерах Mac его размер около 200 мегабайт. Он выделен под Boot Camp и обычно не используется

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

Плюс в питоне есть немало регулярных плюшек. Например, re.split может добавлять тот кусок текста, по которому был разрез, в список частей. А в re.sub можно вместо шаблона для замены передать функцию. Это — реальные вещи, которые прямо очень нужны, но никто про это не пишет.
Так и родился этот достаточно многобуквенный материал с подробностями, тонкостями, картинками и задачами.

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

Добрый день!

Все чаще стучась в различные компании разработчиков в качестве DevOps инженера, я получаю приблизительно одни и те же тестовые задания. Они отличаются друг от друга версиями PHP или проектами которые надо запустить.

Но в целом они упираются в одну связку это Nginx\Appache, SQL (тут вариаций много, все зависит от предпочтений заказчика), PHP и желательно чтобы это было разложено по контейнерам.
Поэтому я решил рассказать на примере, как все это поднять без особых усилий.

Возможно кому-то это поможет понять, на простом примере, что к чему. Описывать что такое Docker я не буду, т.к. статей на эту тему вагон и маленькая тележка.

В данной статье, мы подготовим небольшую структуру:

• В качестве вэб сервера будет использоваться Nginx с минимальной настройкой для запуска проекта.
• В качестве SQL будет использовать MySQL.
• PHP7.0-fpm версия c небольшими надстройками для запуска нашего проекта.
• В качестве проекта который мы будем разворачивать — берем magento2.