Как стать автором
Обновить
115
0

Пользователь

Отправить сообщение

Непрерывная репликация из старой в новую версию PostgreSQL с помощью Slony

Время на прочтение4 мин
Количество просмотров7.7K


Нативная потоковая репликация в PostgreSQL работает только между серверами с одинаковой основной версией. О логической репликации мы говорили в предыдущем посте. Мы увидели, как логическая репликация помогает перенести данные из одной версии PostgreSQL в другую. Но логическая репликация подходит только для поддерживаемых версий PostgreSQL, например, для PostgreSQL 9.4 и PostgreSQL 11. Что делать с версиями до 9.4? Использовать Slony-I.


Используйте репликацию с помощью Slony-I, чтобы перенести данные из старых баз в последнюю версию PostgreSQL. Что такое Slony и как он работает?

Читать дальше →
Всего голосов 23: ↑23 и ↓0+23
Комментарии2

Новый GitLab 12.0 с визуальными ревью и списком зависимостей

Время на прочтение20 мин
Количество просмотров18K


Dev, Sec и Ops


GitLab 12.0 — это ключевой выпуск на пути к реализации подхода, который будет охватывать все элементы DevSecOps и позволит всем вносить свой вклад.


У нас был очень увлекательный год — мы много работали над решением, которое объединило бы все команды. Сообщество внесло тысячи дополнений, чтобы GitLab стал еще круче.



Мы верим, что каждый может внести свой вклад, поэтому добавили функции для сотрудничества между разными командами, быстрой поставки отличного кода и объединения Dev, Sec и Ops.

Всего голосов 20: ↑19 и ↓1+18
Комментарии3

Как Verizon и BGP Optimizer устроили большой оффлайн

Время на прочтение4 мин
Количество просмотров10K


Крупная утечка маршрутов повлияла на большие секторы интернета, включая Cloudflare


Что случилось?


24.06 в 10:30 UTC в интернете случился коллапс: на небольшую компанию на севере Пенсильвании хлынул поток трафика из множества маршрутов, проходящих через крупного провайдера Verizon (AS701), — с тем же успехом навигатор мог бы отправить поток машин с многополосного шоссе на узкую улочку. В результате у многих веб-сайтов на Cloudflare и многих других провайдеров возникли проблемы с доступом. Этого вообще не должно было произойти, ведь Verizon не должен был рассылать эти маршруты всему интернету. Чтобы узнать, как так вышло, читайте дальше.

Читать дальше →
Всего голосов 37: ↑36 и ↓1+35
Комментарии12

Логическая репликация между версиями PostgreSQL

Время на прочтение6 мин
Количество просмотров17K


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


В предыдущих статьях мы уже говорили о методах обновления PostgreSQL (Обновление версии PostgreSQL с помощью pg_dumpall и Обновление версии PostgreSQL с помощью pg_dump/pg_restore) в рамках серии Обновление или миграция старых версий PostgreSQL в новые. Но оба этих метода не исключают простоя.

Читать дальше →
Всего голосов 18: ↑17 и ↓1+16
Комментарии6

Southbridge в Челябинске и Битрикс в Kubernetes

Время на прочтение7 мин
Количество просмотров5.1K

В Челябинске проходят митапы системных администраторов Sysadminka, и на последнем из них я делал доклад о нашем решении для работы приложений на 1С-Битрикс в Kubernetes.


Битрикс, Kubernetes, Сeph — отличная смесь?


Расскажу, как мы из всего этого собрали работающее решение.


Поехали!


Всего голосов 24: ↑21 и ↓3+18
Комментарии8

Развертывание кластера Kubernetes в OpenStack с помощью Kubespray

Время на прочтение14 мин
Количество просмотров15K


Kubernetes быстро стал стандартом для поставок и масштабирования контейнерных приложений и управления ими. Это очень гибкое и универсальное решение с открытым исходным кодом. У него обширная документация, и в ней не всегда легко найти нужный раздел. Поэтому Kubernetes так непросто освоить. После планирования кластера его еще нужно установить, а тут тоже не все гладко. Поэтому и существуют инструменты развертывания, вроде Kubespray, которые упрощают работу. Я расскажу об автоматическом развертывании кластера Kubernetes с помощью Kubespray в облаке OpenStack (Open Telekom Cloud).

Читать дальше →
Всего голосов 23: ↑21 и ↓2+19
Комментарии6

KubeCon EU 2019: 10 ключевых выводов

Время на прочтение10 мин
Количество просмотров3.7K


Мы с ребятами из Datawire недавно вернулись с потрясающих конференций KubeCon и CloudNativeCon в Барселоне. Мы участвовали в 6 выступлениях на KubeCon, раздали на своем стенде кучу классных (без ложной скромности) футболок, пообщались с десятками людей и посетили крутые выступления. На KubeCon EU было столько всего интересного, что я решил написать пост с ключевыми итогами.


И вот какие выводы я сделал (не в порядке важности):


  1. Многоплатформенность и гибридное облако (все еще) популярны.
  2. Объединение технологий набирает обороты.
  3. Анонс Service Mesh Interface (SMI): следите за новостями.
  4. (Туманное?) будущее Istio.
  5. Политика как код поднимается по стеку.
  6. Облачный DevEx по-прежнему не обходится без проблем.
  7. Компании (все еще) на начальных этапах внедрения технологий.
  8. Локальный Kubernetes реален (но заковырист).
  9. Считайте кластеры стадом.
  10. Успех Kubernetes по-прежнему зависит от сообществ.
Читать дальше →
Всего голосов 29: ↑27 и ↓2+25
Комментарии3

Слёрм: гусеница превратилась в бабочку

Время на прочтение4 мин
Количество просмотров4.5K


<TL;DR>


  1. Слёрм действительно позволяет войти в тему Kubernetes или подтянуть свои знания.
  2. Участники довольны. Тех, кто ничего нового не узнал или не решил свои задачи, считанные единицы. Безусловным манибеком первого дня («Если вы чувствуете, что Слёрм вам не подходит, мы вернем полную цену билета») воспользовался всего один человек, обосновав тем, что переоценил свои силы.
  3. Следующий Слёрм пройдет в начале сентября в Питере. Selectel, наш бессменный спонсор, предоставляет не только облако для стендов, но и свой конференц-зал.
  4. Мы повторяем базовый Слёрм (9-11 сентября) и представляем новую программу: Слёрм DevOps (4-6 сентября).
Читать дальше →
Всего голосов 24: ↑20 и ↓4+16
Комментарии0

Tupperware: «убийца» Kubernetes от Facebook?

Время на прочтение10 мин
Количество просмотров10K

Эффективное и надежное управление кластерами в любом масштабе с Tupperware



Сегодня на конференции Systems @Scale мы представили Tupperware — нашу систему управления кластерами, которая оркестрирует контейнеры на миллионах серверов, где работают почти все наши сервисы. Впервые мы развернули Tupperware в 2011 г., и с тех пор наша инфраструктура разрослась с 1 датацентра до целых 15 геораспределенных датацентров. Все это время Tupperware не стоял на месте и развивался вместе с нами. Мы расскажем, в каких ситуациях Tupperware обеспечивает первоклассное управление кластерами, включая удобную поддержку stateful-сервисов, единую панель управления для всех датацентров и возможность распределять мощности между сервисами в реальном времени. А еще мы поделимся уроками, которые усвоили по мере развития нашей инфраструктуры.


Tupperware выполняет разные задачи. Разработчики приложений с его помощью поставляют приложения и управляют ими. Он упаковывает код и зависимости приложения в образ и поставляет его на серверы в виде контейнеров. Контейнеры обеспечивают изоляцию между приложениями на одном сервере, чтобы разработчики занимались логикой приложения и не думали о том, как найти серверы или контролировать обновления. А еще Tupperware отслеживает работоспособность сервера, и если находит сбой, переносит контейнеры с проблемного сервера.

Читать дальше →
Всего голосов 27: ↑18 и ↓9+9
Комментарии7

Полное руководство по Prometheus в 2019 году

Время на прочтение11 мин
Количество просмотров332K


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


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


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


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


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

Всего голосов 30: ↑29 и ↓1+28
Комментарии30

Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup

Время на прочтение7 мин
Количество просмотров19K


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


Компоненты репозитория могут дополнительно сжиматься и шифроваться, а самое главное — при повторных процессах резервного копирования — переиспользоваться повторно.


Резервная копия в подобном репозитории — именованная цепочка связанных друг с другом компонентов, например, на основе различных hash-функций.


Есть несколько подобных решений, я остановлюсь на 3: zbackup, borgbackup и restic.

Читать дальше →
Всего голосов 26: ↑26 и ↓0+26
Комментарии20

Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati

Время на прочтение6 мин
Количество просмотров27K


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


Из тех, которые удовлетворяют требованиям — duplicity (к которому есть приятный интерфейс в виде deja dup) и duplicati.


Еще одно весьма примечательное средство резервного копирования — dar, но поскольку у него имеется весьма обширный список опций — методика тестирования покрывает едва ли 10% от того, на что он способен, — его в рамках текущего цикла не тестируем.

Читать дальше →
Всего голосов 20: ↑20 и ↓0+20
Комментарии3

Как соединить кластеры Kubernetes в разных дата-центрах

Время на прочтение7 мин
Количество просмотров12K


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


Сегодняшний эксперт — Даниэль Поленчик (Daniele Polencic). Даниэль работает инструктором и разработчиком ПО в Learnk8s.

Если вы хотите получить ответ на свой вопрос в следующем посте, свяжитесь с нами по электронной почте или в Твиттере: @learnk8s.


Пропустили предыдущие посты? Ищите их здесь.


Как соединить кластеры Kubernetes в разных дата-центрах?


Кратко: скоро выходит Kubefed v2, а еще советую почитать о Shipper и проекте multi-cluster-scheduler.
Читать дальше →
Всего голосов 23: ↑23 и ↓0+23
Комментарии1

GitLab 11.11: несколько ответственных для мердж-реквестов и улучшения для контейнеров

Время на прочтение15 мин
Количество просмотров5.6K


Больше возможностей для совместной работы и дополнительные уведомления


Мы в GitLab постоянно ищем новые способы улучшить совместную работу по всему жизненному циклу DevOps. Мы с радостью объявляем, что с этого выпуска поддерживаем несколько ответственных лиц для одного мердж-реквеста! Эта функция доступна с уровня GitLab Starter и по-настоящему воплощает наш девиз: «Каждый может внести свой вклад». Мы знаем, что с одним мердж-реквестом может работать много людей, чтобы все точно было в порядке, и теперь у вас есть возможность назначать несколько ответственных за мердж-реквесты!


А еще команды DevOps теперь получают автоматические уведомления о событиях деплоя в Slack и Mattermost. Добавьте новые уведомления в список событий отправки в этих двух чатах, и ваша команда будет почти моментально узнавать о новых деплоях.


Сокращение издержек с поддержкой контейнеров Docker в Windows и подготовкой кластеров Kubernetes на уровне экземпляра

Всего голосов 17: ↑17 и ↓0+17
Комментарии5

Бенчмарк потребления ЦП для Istio и Linkerd

Время на прочтение6 мин
Количество просмотров4.3K


Введение


Мы в Shopify занялись развертыванием Istio в качестве service mesh. В принципе все устраивает, кроме одной вещи: это дорого.


В опубликованных бенчмарках для Istio говорится:


С Istio 1.1 прокси потребляет примерно 0,6 vCPU (виртуальных ядер) на 1000 запросов в секунду.

Для первого региона в service mesh (по 2 прокси с каждой стороны соединения) у нас будет 1200 ядер только для прокси, из расчета один миллион запросов в секунду. Согласно калькулятору стоимости от Google получается примерно $40/месяц/ядро для конфигурации n1-standard-64, то есть один этот регион будет стоить нам больше 50 тыс. долларов в месяц за 1 млн запросов в секунду.


Айвен Сим (Ivan Sim) наглядно сравнил задержки service mesh в прошлом году и обещал то же самое для памяти и процессора, но не получилось:


Судя по всему, values-istio-test.yaml серьезно увеличит запросы к процессору. Если я все правильно посчитал, нужно примерно 24 процессорных ядра для панели управления и 0,5 ЦП для каждого прокси. У меня столько нету. Я повторю тесты, когда мне выделят больше ресурсов.

Я хотел сам убедиться, насколько показатели Istio схожи с другой service mesh с открытым кодом: Linkerd.

Читать дальше →
Всего голосов 22: ↑21 и ↓1+20
Комментарии3

Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования

Время на прочтение8 мин
Количество просмотров18K

Данной статьей продолжается


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

Из тех, что больше всего подходят под наши условия, я буду рассматривать 3: rdiff-backup, rsnapshot и burp.
Читать дальше →
Всего голосов 30: ↑27 и ↓3+24
Комментарии6

Docker: невредные советы

Время на прочтение6 мин
Количество просмотров34K

В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.


Краткое содержание предыдущей серии: два разработчика в жестком дедлайне составляют Dockerfile. В процессе к ним заходит Ops Игорь Иванович. Итоговый Dockerfile плох настолько, что ИИ оказывается на грани инфаркта.



Сейчас разберемся, что не так с этим Dockerfile.


Итак, прошла неделя.

Читать дальше →
Всего голосов 61: ↑57 и ↓4+53
Комментарии75

МегаСлёрм для инженеров и архитекторов Kubernetes

Время на прочтение2 мин
Количество просмотров2.5K


Через 2 недели стартуют интенсивы по Kubernetes: Слёрм-4 для тех, кто знакомится с k8s и МегаСлёрм для инженеров и архитекторов k8s.


На Слёрм-4 остались последние 10 мест в зале. Желающих освоить k8s на базовом уровне хватает.


Для Ops, который знакомится с Kubernetes, запустить кластер и задеплоить приложение – уже неплохой результат. У Dev запросы и того меньше: понять, как оптимизировать приложение под работу в кластере.


У инженеров и архитекторов задачи другого уровня:


  • можно ли запустить базу данных в k8s, нужно ли это делать, что мы выигрываем и проигрываем от такой архитектуры;
  • какие подходы к деплою очевидно не подходят для k8s;
  • какие угрозы безопасности несет k8s (например, разработчик легко может получить админский доступ) и как их предотвратить;
  • какие схемы автоматизации инфраструктуры допускает k8s и как научиться их находить и использовать.

Если вы уже дошли до такого уровня, на МегаСлёрме вас ждет много интересного.

Читать дальше →
Всего голосов 23: ↑18 и ↓5+13
Комментарии0

Руководство для чайников: создание цепочек DevOps с помощью инструментов с открытым исходным кодом

Время на прочтение6 мин
Количество просмотров35K


Создание первой цепочки DevOps за пять шагов для новичков.


DevOps стал панацеей для слишком медленных, разобщенных и прочих проблемных процессов разработки. Но нужны минимальные познания в DevOps. Здесь будет рассмотрены такие понятия, как цепочка DevOps и как создать ее за пять шагов. Это не полное руководство, а только “рыба”, которую можно расширять. Начнем с истории.


Мое знакомство с DevOps


Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.

Читать дальше →
Всего голосов 31: ↑26 и ↓5+21
Комментарии18

Скорость хранилища подходит для etcd? Спросим fio

Время на прочтение6 мин
Количество просмотров5.6K


Короткая история о fio и etcd


Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:


fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Нужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:


  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]
Читать дальше →
Всего голосов 25: ↑25 и ↓0+25
Комментарии2

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность