DevOps *

Всем добрый вечер! Спешим поделиться новостью о том, что уже в феврале у нас запускается новый поток по курсу «Devops — практики и инструменты», а это значит, что пора закончить начатое и опубликовать третью часть статьи: «Почему важна SRE документация». Поехали!

Документы для управления командами SRE

Командам SRE для эффективной работы необходима надежная и доступная документация.

Сайт команды

Примечание: Вместо сайта можно использовать отдельный спейс или раздел в Confluence/Wiki.

Сайт команды важен тем, что обеспечивает координацию информации и документации, связанной с командой SRE и ее проектами. Например в Google, многие команды SRE используют g3doc (внутренняя платформа документирования Google, где доки живут в исходном коде вместе со связанным кодом), а некоторые команды используют g3doc и Google Sites: в таком случае страницы g3doc тесно связаны с кодом/деталями реализации.

Устав команды



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

Эта статья расшифровка видеодоклада Алексея Вахова из Учи.ру «Облака в облаках»

Учи.ру — онлайн-платформа для школьного образования, более 2 миллионов школьников, регулярно решают у нас интерактивные занятия. Все наши проекты хостятся полностью в публичных облаках, 100% приложений работают в контейнерах, начиная от самых маленьких, для внутреннего пользования, и заканчивая крупными продакшенами на 1k+ запросов в секунду. Так получилось, что у нас 15 изолированных докер-кластеров (не Kubernetes, sic!) в пяти облачных провайдерах. Полторы сотни пользовательских приложений, количество которых постоянно растет.

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

В процессе доклада мы обсудим:

• Мотивацию выбора технологий и особенности бизнеса
• Инструменты: Ansible, Terraform, Docker, Github Flow, Consul, Nomad, Prometheus, Shaman — web-интерфейс для Nomad.
• Использовании федерации кластеров для управления распределенной инфраструктурой
• NoOps выкатки, тестовые окружения, схемы приложения (практически все изменения девелоперы делают самостоятельно)
• Занимательные истории из практики

Кому интересно, прошу под кат.

Как правильно хранить секреты? В репозитории, в системе деплоя или в системе управления конфигурациями? На личном компьютере, на серверах, а может в коробке под кроватью? А как управлять секретами, чтобы не допускать утечек?

Сергей Носков (Albibek) — руководитель группы информационной безопасности платформы из Авито, знает ответ на эти вопросы и поделится с нами. В Авито два года активно используют HashiCorp Vault, за это время набили шишки, и прокачали опыт до уровня «Мастер».

В статье всесторонне поговорим про Vault: что это такое, где и как используется в компании, как в Авито управляют секретами с помощью HashiCorp Vault, как используют Puppet и Kubernetes, варианты использования с Puppet и другими SCM, какие возникают проблемы, что болит у безопасников и разработчиков, и, конечно, поделимся идеями, как все исправить.

Пришла задача WEB-12982
Создаешь ветку web-12982 в репозитории
Пока ветка собирается, читаешь тз и пьешь кофе
Приступаешь непосредственно к разработке

git commit, git push
Пока ветка пересобирается листаешь хабр
git commit, git push
Пока ветка пересобирается листаешь твиттер
git commit, git push
…
Сдаешь на ревью ветку с 50 коммитами

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

Знакома ситуация? В моей компании инфраструктура разработки организована таким образом:

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

Но, медленно... Если тебе близка эта ситуация, добро пожаловать под кат.

Как и любое другое решение, Helm — пакетный менеджер для Kubernetes — имеет плюсы, минусы и область применения, поэтому при его использовании стоит правильно оценивать свои ожидания…


Мы используем Helm в своём арсенале инструментов непрерывного выката. На момент написания статьи в наших кластерах более тысячи приложений и примерно 4000 инсталляций этих приложений в различных вариациях. Периодически мы сталкиваемся с проблемами, но в целом довольны решением, не имеем простоев и потерь данных.

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

И снова здравствуйте!

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

В воскресенье закончился Слёрм-3: интенсив по Kubernetes.

Поставили личный рекорд: 132 участника, 65 в онлайне и 67 в зале.
На первом Слёрме было 50 человек, на втором 87. Растем потихоньку.

126 человек создали кластер (задание первого дня), а 115 выполнили практику до конца.
6 человек вообще проигнорировали практику. Будем считать, что им нужны были только лекции.

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

Всем привет!

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

• «Стоит ли работать удаленно?»
• «Как вы организовали удаленную работу для своей команды?»
• «Нам сложно работать с удаленными разработчиками...»

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

И раз… два… три… Поехали!

Модель «Инфраструктура как код (IaC)», которую иногда называют «программируемой инфраструктурой», — это модель, по которой процесс настройки инфраструктуры аналогичен процессу программирования ПО. По сути, она положила начало устранению границ между написанием приложений и созданием сред для этих приложений. Приложения могут содержать скрипты, которые создают свои собственные виртуальные машины и управляют ими. Это основа облачных вычислений и неотъемлемая часть DevOps.

Инфраструктура как код позволяет управлять виртуальными машинами на программном уровне. Это исключает необходимость ручной настройки и обновлений для отдельных компонентов оборудования. Инфраструктура становится чрезвычайно "эластичной", то есть воспроизводимой и масштабируемой. Одни оператор может выполнять развертывание и управление как одной, так и 1000 машинами, используя один и тот же набор кода. Среди гарантированных преимуществ инфраструктуры как кода — скорость, экономичность и уменьшение риска.

Как раз об этом расшифровка доклада Кирилла Ветчинкина на DevOpsDays Moscow 2018. В докладе: переиспользование модулей Ansible, хранение в Git, ревью, пересборка, финансовые выгоды, горизонтальное масштабирование в 1 клик.

Кому интересно, прошу под кат.

Всем привет!

Девятая конференция DUMP пройдёт 19 апреля в Екатеринбурге. Доклады будут идти в 8 потоков: Backend, Frontend, Mobile, Тестирование и QA, Devops, Design, Science и Management. Плюс мастер-классы и афтепати.

В этом посте — темы, которые мы хотим обсудить в секциях Frontend, Backend, Science и инструкция, как стать докладчиком. А еще мы придумали кое-что интересное для спикеров, которые хотят не просто выступить, но еще дополнительно пообщаться с другими докладчиками и посмотреть Екатеринбург. Под катом все подробности.


Маленький ролик о том, как прошел прошлогодний DUMP

Привет, друзья. Недавно мы запустили свою серию митапов по Kubernetes в Mail.ru – @Kubernetes Meetup. Мы немного недооценили интерес к теме и получили несколько сотен заявок на участие в первом событии серии – больше, чем смогли подтвердить.

В честь 14 февраля мы решили устроить special edition-митап для всех, кто любит Kubernetes: соберемся бо́льшим кругом, начнем чуть раньше, расширим традиционную программу выступлений горячей дискуссией и интерактивом. Также мы подготовили для участников несколько особых сюрпризов.

Встреча пройдет 14 февраля (четверг) в 17:00 в московском офисе Mail.ru Group (Ленинградский проспект, д. 39, стр. 79).

На митапе Booking.com раскроет детали своего сетапа Kubernetes; крупнейший чешский хостинг WEDOS поделится своим опытом работы с K8S на Bare Metal, а Mail.ru Cloud Solutions расскажут, как сделать Kubernetes по-настоящему безопасным. В рамках дискуссии приглашенные спикеры обсудят, за чем будущее – за ванильным Kubernetes или дистрибутивом вендора?

Регистрация обязательна и закрывается 12 февраля в 23:59 (или раньше, если закончатся места).

Прим. перев.: Оригинальную статью написал Miłosz Smółka — один из основателей небольшой польской компании Three Dots Labs, специализирующейся на «продвинутых backend-решениях». Автор опирается на свой опыт активной эксплуатации GitLab CI и делится накопленными советами для других пользователей этого Open Source-продукта. Прочитав их, мы поняли, насколько нам близки описанные им проблемы, поэтому решили поделиться предлагаемыми решениями с более широкой аудиторией.



На этот раз я затрону более продвинутые темы в GitLab CI. Частой задачей здесь является реализация в пайплайне нестандартных возможностей. Большинство советов специфичны для GitLab, хотя некоторые из них можно применить и к другим системам CI.

Говоря о типовых сценариях автоматизации сети, никак не обойтись без набора модулей command. Благодаря этим модулям, Ansible позволяет запускать команды на сетевом оборудовании так, как будто вы вводите их прямо с консоли. При этом вывод команд не просто проскакивает в окне терминала, чтобы кануть в лету, а может быть сохранен и использован в дальнейшем. Его можно записать в переменные, парсить для использования в последующих задачах или же сохранить на будущее в переменных хоста.



Цель этого поста – показать, что любую повторяющуюся задачу по управлению сетью можно автоматизировать, и что Ansible не просто позволяет управлять конфигурациями, а помогает избавиться от рутины и сэкономить время.

Мне показалось, будет прикольно запилить пост под названием «Жизнь действия GitHub Action». На вводном обучении в Google тебя проводят через «Жизнь запроса», и у меня это был один из самых любимых элементов. Поэтому я использую аналогичный подход для GitHub Action.

Для тех, кто в танке, Actions — это функция GitHub, запущенная на конференции Universe в прошлом году. Хотите в бета-тестеры? Гоу сюда.

Общая идея — это GitHub с поддержкой сценариев, но страдать фигней и разливаться в объяснениях я не стану. Лучше проведу вас через события, которые происходят при запуске действия.

Проблема

Вот типичный рабочий процесс:

• Создаю пулл-реквест в репозиторий.
• Пулл-реквест поглощается.
• Ветка сохраняется до скончания времен, съедая мне ту часть мозга, которая любит чистоту и порядок.

Остающиеся ветви — моя боль, сосредоточимся на ней. Хотя проблема-то общая, поэтому давайте создадим действие для удаления ветвей после поглощения пулл-реквеста.

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

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

Сфера применения

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

Короткая история о «тяжелом» запросе и изящном решении проблемы

Недавно нас по ночам стали будить алерты: на диске не хватает места. Мы быстро разобрались, что проблема в ETL-задачах.

ETL-задача выполнялась в таблице, где хранятся двоичные записи, дампы. Каждую ночь эта задача должна была удалять повторяющиеся дампы и освобождать место.

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

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

Управление релизами стало намного проще

GitLab 11.7 выпускает Releases в GitLab Core. Теперь у пользователей есть снэпшоты релиза, включающие не только исходный код, но и все связанные артефакты. Больше не надо вручную собирать исходный код, выходные данные сборки и прочие метаданные или артефакты, связанные с выпущенной версией вашего кода. Кроме того, Releases — основа для более широкого и надежного взаимодействия релизов в будущем.

Управление портфелем поддерживает более сложные структуры декомпозиции работ

Multi-level Child Epics — это новейшее дополнение к управлению портфелем GitLab, доступное в Ultimate. Child Epics позволяют создавать многоуровневые рабочие структуры, помогая управлять более сложными проектами и рабочими планами. Теперь эпик содержит как задачи, так и эпики. Такая структура обеспечивает прямую связь между планируемыми и реализуемыми задачами для их внедрения.

Оптимизация разработки JavaScript с помощью реестров NPM

Gitlab 11.7 Premium поставляет реестры NPM непосредственно в GitLab, предоставляя стандартный, более безопасный способ совместного использования и контроля версий пакетов NPM между проектами. Просто поделитесь именем пакета, а NPM и GitLab обработают все остальное в одном интерфейсе!

И многое другое

У нас в 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, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).