Русский
Русский
English
Статистика
Реклама

Devops

CrowdSec современная альтернатива Fail2Ban и коллективный иммунитет для Интернета

16.11.2020 12:07:26 | Автор: admin

CrowdSec

Инструмент Fail2Ban хорошо известен админам. Программа анализирует логи на сервере и подсчитывает количество попыток доступа с конкретных IP-адресов по указанным протоколам. В случае нарушения правила данный IP-адрес блокируется на заданный отрезок времени. Например, джейл для авторизации по SSH включён с дефолтными настройками 5 попыток авторизации за 10 минут, после чего происходит бан IP-адреса на 10 минут. Отличный способ отфильтровать мусорный трафик от разных сканеров и защита от DDoS.

Fail2Ban и SSHGuard лучшие инструменты в своей области. Однако новый опенсорсный проект CrowdSec представляется интересной альтернативой. Это локальная замена Fail2Ban, а потенциально нечто большее глобальная база репутации IP-адресов типа иммунной системы интернета.

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



Разработчики CrowdSec называют следующие ключевые особенности:

  • обнаружение атак и реагирование на всех уровнях (логи могут лежать в любом месте);
  • простота в установке и обслуживании (установка с визардом в консоли);

    git clone https://github.com/crowdsecurity/crowdsec/releases/latest
    

    sudo ./wizard.sh -i
    


    Установка CrowdSec. Визард в консоли помогает выбрать и предлагает, какие демоны/логи нужно мониторить, хотя возможна и последующая настройка через обычные конфиги
  • интеграция с другими компонентами (чтение логов и автоматическая блокировка нарушителей на уровне CDN);
  • общий доступ (опционально): метаданные можно отправлять в центральный API, так что данные о вредоносных IP-адресах получат все пользователи. Нужно подчеркнуть, что это опциональная фича, и никто не заставляет передавать метаданные в общий доступ;
  • лёгкий вес: автономная работа, минимум оперативной памяти и CPU;
  • возможность обработки холодных логов (из архива) для своеобразной симуляции;
  • предустановленные панели мониторинга.

Важно отметить, что за разработкой стоит французская компания, а не американская, что по нынешним временам является плюсом для приватности. Даже если выбрать вариант коллективной работы и делиться собранными данными, отправляются только три параметра: метка времени, IP-адреса нарушителей и политика, которую они нарушили.

Ещё один интересный момент инструмент написан на языке программирования Go.

С архитектурной точки зрения система состоит из трёх основных компонентов:

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

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



На данный момент разработано пять модулей интеграции (bouncers):
cs-cloudflare-blocker, cs-custom-blocker (пользовательские сценарии), cs-netfilter-blocker, cs-nginx-blocker и cs-wordpress-blocker. Например, модуль для Nginx сверяет каждый неизвестный IP-адрес с базой данных, прежде чем веб-сервер ответит на запрос или выдаст ошибку 403. Модуль Netfilter просто добавляет вредоносные IP-адреса в чёрный список nftables/ipset.

Для простоты настройки на сайте собраны коллекции и конфигурации.

Коллекции это, по сути, просто наборы парсеров и сценариев для разных ситуаций. Например, в коллекцию Nginx входит парсер логов nginx-logs и базовые http-сценарии для определения типичных вредоносных ботов (агрессивный краулинг, сканирование/пробирование портов, чёрный список user-agent'ов, а также определение попыток проведения атаки path traversal).

Полный список коллекций:


Один из вариантов работы с CrowdSec через консольную программу cscli:

cscli metrics

Эта команда выдаёт основные метрики о работе парсеров, объёме обработанных логов, количестве обнаруженных и заблокированных угроз по каждой коллекции (перечень коллекций см. выше).

Следующая команда выводит список хостов с указанием причин, почему их забанили, кодом страны, идентификатором автономной сети (AS), количеством нарушений и другой информацией.

cscli ban list



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

Но кроме cscli, конфигурацию можно изменить и традиционным способом, путём редактирования текстового файла в формате YAML:

vi /etc/crowdsec/config/profiles.yaml

Естественно, кастомные сценарии тоже поддерживаются.

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

Сейчас компания пытается предложить пользователям платный доступ к облачному API и базе данных с репутацией IP-адресов, которая составляется совместными усилиями. При этом поставщики информации в эту базу освобождаются от оплаты, а платят только чистые потребители, которые не хотят делиться информацией из своих логов. Планируется два тарифных плана: premium и enterprise с услугами по поддержке, специальными служебными инструментами (типа развёртывания системы на несколько локаций из одного центрального места), применением дата-майнинга и машинного обучения (обнаружение тенденций в глобальных данных), более продвинутом анализе холодных логов (форензика, криминалистика, расследования хотя данное направление бизнеса в Европе затруднено из-за закона GDPR).

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



Разработчики обращают внимание, что программа пока в бета-версии, но никаких проблем на продакшне ни у кого не возникало. Они также говорят, что программа на Go элементарно портируется на другие платформы вроде Windows и Mac.

По итогу сейчас это добротный опенсорсный инструмент, который можно использовать в качестве альтернативы старому доброму Fail2Ban. А со временем он может превратиться в нечто большее. Разработчики ставят цель в создании своеобразного коллективного иммунитета, когда клетки организма (серверы) коллективно защищаются от атак, словно иммунная система.



На правах рекламы


Виртуальные серверы с защитой от DDoS-атак и новейшим железом, серверы размещены в одном из лучших российских дата-центров DataPro. Всё это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe! Поспешите заказать.

Подробнее..

Можно бить разработчиков за баги, а можно внедрить SRE о чём говорили на митапе Слёрма

17.11.2020 06:15:37 | Автор: admin


Зачем нужно SRE, когда есть DevOps, что такое SLO и бюджет на ошибки, каким компаниям точно не надо внедрять новую методологию, существуют ли джуниор-инженеры по SRE и сколько платят опытным. Об этом и не только говорили на митапе Слёрма Профессия SRE: практика и мифы.


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


Участники митапа:


  • Павел Селиванов DevOps Engineer в Mail.ru Cloud Solutions. Строит DevOps, CI/CD-процессы.
  • Артём Артемьев Lead SRE в компании Inspectorio. Помогает девопсам жить хорошо.
  • Марсель Ибраев CTO Слёрм.

Заметка на полях: Site Reliability Engineering (SRE) произносится на русском как эс-эр-и.


Что такое SRE и чем отличается от DevOps



Марсель Ибраев (МИ): Что такое SRE: это технология, методология или профессия? Что такое SRE простыми словами?


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


Артём Артемьев (АА): Ты давно читал про DevOps? Забей в поиске, прочтёшь почти то же самое. На самом деле SRE это то, как в Google в своё время увидели DevOps. Получилось немного по-другому, но нечто очень похожее на DevOps.


Павел Селиванов (ПС): Тут я соглашусь. Google пишет, что SRE это практическая имплементация методологии DevOps. И мне правда кажется, что это так.


АА: Проблема только в том, что у нас нет нормального определения DevOps. У каждого DevOps сильно свой. SRE одна из разновидностей DevOps.


МИ: В Google, получается, взяли на себя смелость опубликовать своё видение.


АА: Кстати, интересно, что у Facebook тоже есть своё видение DevOps, просто Facebook об этом не написал книжку. Не рассказал, как у них это получилось. Но у них DevOps нет. У них operations отдается всем инженерам, все инженеры так или иначе занимаются operations. Но есть люди, которые занимаются инфраструктурой, и они называются продакшн-инженерами.


П: У меня даже есть идея, почему Google написал такую книжку, а Facebook нет. Потому что Facebook делает сервисы для себя по большей части, а Google для других. И когда Google надоело, что пользователи их хают, когда сервисы работают нормально, они попытались объясниться.


М: Получается, Google переварил DevOps, в итоге у них родился Site Reliability Engineering. Но почему тогда концепция стала такой популярной? Просто бренд сыграл, или эта штука действительно хорошо показывает себя на практике?


АА: Многие конторы ищут Святой Грааль: вот у нас всё плохо, но сейчас мы наймём DevOps и всё полетит. С DevOps не получилось, давай теперь переименуем его в SRE.


МИ: Звучит логично.


АА: Насколько популярно, не знаю. Думаю, если собрать статистику, в скольких компаниях есть SRE У вас в Mail.ru есть SRE?


ПС: Да.


АА: Больше, чем DevOps?


ПС: Скорее всего, да. Больше ли, чем админов я не уверен. Mail.ru придумала, как работать хорошо, задолго до появления Docker, SRE, DevOps и всего прочего. А так как компания большая, смысла менять своё на новое и хайповое нет. Это огромные усилия. Поэтому мы по многим, особенно глобальным вещам живём на наших внутренних регламентах и инструментах. А ими занимаются сисадмины.


МИ: Непопулярно.


ПС: Зато работает.


АА: Я ещё вижу в реалиях русскоговорящего рынка, что у нас есть проблема никто не понимает (по крайней мере, мало кто понимает), что есть проблема с DevOps. Что мы должны получить от внедрения DevOps? Как правило, все говорят про Continuous delivery, сбор метрик.


МИ: Ну да, построили пайплайны, и у нас как будто построен DevOps.


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


В Google придумали, что нужно подойти к пользователю как можно ближе, и важны не показатели, а SLO, которое получает пользователь. В итоге в компаниях возникает необходимость нанять еще девопсов, которые будут делать похожую работу, но по-другому. И как их назвать? О, давай назовём SRE.

МИ: Получается, SRE это реинкарнация, нечто, что получило физическую оболочку в рамках Google. Был некий DevOps, который все понимали по-своему, и Google не исключение, они тоже поняли это по-своему, набили кучу шишек и пришли к подходу, который назвали Site Reliability Engineering.


АА: Когда Google начал выдумывать SRE, ещё DevOps не был объявлен (хотя о нём впервые заговорили в 2000 году где-то во Франции, но это было ещё не широко). Ребята из Google не знали о DevOps, просто придумали то же колесо сами.


ПC: Мне тоже кажется, что DevOps был придуман в рамках каких-то встреч и конференций (как и Agile манифест в своё время), когда люди собрались и начали думать, как сделать так, чтобы всем стало хорошо. Собрались, придумали, и кто-то дальше эту идею развивал. А Google к этому подходил иначе, с точки зрения своих внутренних проблем. Они решали конкретную задачу, да, возможно, ту же самую задачу, что и комьюнити, и очень похожими средствами, но задача была полностью практическая. Нужно было решать конкретные вещи в конкретные сроки и конкретными действиями.


МИ: Означает ли это, что концепция SRE и весь его инструментарий подойдут далеко не всем? Если заработало у Google, не факт, что заработает у других?


АА: Аналогично и для DevOps. Но смотря про что говорить. Если про то, что надо мерить SLO со стороны пользователя, наверное, это почти всем подойдет. Если про подход катись как можно чаще, а ты запускаешь космические корабли, то катиться как можно чаще дорого и непонятно, надо тестировать больше.


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


Кто такой SRE-инженер? Почему это больше разработчик, чем админ



МИ: SRE называют концепцией или методологией, а это, я бы сказал, слова-паразиты, потому что сейчас так называют что ни попадя. Если мы говорим, что SRE это ряд конкретных практик и решений, придуманных в Google, было бы интересно послушать, чем конкретно должен заниматься SRE-инженер. Можно описать типовой день или неделю. Что он должен делать, какие у него обязанности?


АА: Google приводит сравнение SRE и DevOps. Там перечисляются все эти пункты и оказывается, что всё матчится друг в друга. Но самая большая разница, о которой говорит Google, они не нанимают operations или админов.
Они решили везде нанимать software engineer, которые умеют программировать которые очень ленивые, ничего не любят делать руками и чуть что пишут код. Но Google может себе позволить найти software-инженера, который очень хорошо разбирается в сети, системе, производительности и т. д.


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


МИ: То есть глобально SRE-инженер занимается автоматизацией?


АА: Старается заниматься. Ну и DevOps тоже. Большая задача SRE уметь падать и быстро чиниться. Та самая концепция Error budget.


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


Концепция Error budget, когда сказано, что твой сервис 5% в месяц может быть сломанным, позволяет убедиться, что команда этого сервиса не замедлилась и бежит быстро. Move fast and break things не бояться немного сломать, но в то же время экспериментировать и доносить нужные ценности. Это второй аспект. Возможно, он важен только компаниям размера Google. Когда у тебя небольшая компания, вы и так все мотивированы и бежите вперёд. Error budget вас сильно не спасёт.


ПС: Прикол именно в том, что SRE это по большому счёту разработчик. Да, разрабатывать, естественно, это не единственная его функция, но именно майндсет разработчика, способность к разработке и реальный опыт программирования одна из ключевых вещей в этой профессии.


Марсель, ты говоришь, что SRE-engineer это человек, который должен заниматься автоматизацией. Мне кажется, это может вводить в заблуждение, потому что под словом автоматизация мы часто понимаем набор скриптов, который сделает grep в логи, положит в такой-то файлик, а дальше этот файлик по TCP отправит туда-то вот это автоматизация. Однострочник на Bash, скриптик на Python и так далее. Просто с этой точки зрения любой разработчик тоже занимается автоматизацией, но почему-то его работу мы автоматизацией не называем.


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

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


Странно было бы заопенсорсить свой набор из миллиона bash-скриптов, zabbix-шаблонов и прочего. Вывалить это всё на гитхаб и сказать: вот, ребят, мы за десять лет существования компании накопили вот такую кучу нате. Понятно, что это ни у кого бы не взлетело. А вот инструменты, которые делают разработчики для поддержки инфраструктуры, они действительно новые и полезные.


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


МИ: То есть SRE-инженер, как правило, из разработки. Появляется проблема, и он смотрит не на то, как это закостылить, а на то, как автоматизировать, и может написать программу или приложение, которое всё это будет обрабатывать. Ещё я слышал, что с SRE связаны системы мониторинга доступности, чтобы у нас приложение было доступно и соответствовало неким метрикам. Это тоже задача SRE-инженера? Его задача эти метрики настрААвать, отслеживать как он с ними работает?


АА: Метрики отслеживать не задача инженера SRE. Моя задача как инженера SRE сделать инструменты для команд, чтобы они понимали, сколько у них осталось SLO, почему он уменьшается и как выглядит работа их приложения, конкретного сервиса этой команды для конечного пользователя: какой был latency, сколько было ошибок и как это всё выглядело.


Они ко мне обращаются за помощью, когда видят, что тает их SLO и они не понимают почему. На авторизации логины стали длиннее на пару секунд, и они считают это нормальным, но это выпало из SLO, начинает выпадать из допустимого latency. Ко мне прям прибегали ребята из сервиса авторизации и спрашивали: почему у нас SLO тает, вчера было 3 секунды, а сегодня 3,5 секунды ничего страшного же. Но если вы договорились, что должно быть 3 секунды, то, ребят, извините.


Что такое SLO, SLA и Error Budget



МИ: А можешь расшифровать, что значат SLO, SLA, SLI?


АА: Думаю, все слышали про SLA (Service Level Agreement) это договор с любой компанией об уровне предоставления услуг, где компания обязуется, что 99% времени некий сервис будет работать.


МИ: Например, сервер на хостинге? То, что мы берём в аренду.


АА: Например, строка поиска в Google. Забиваешь, что нужно найти, а он тебе ищет. SLA там 99%. То есть Google сам говорит: зуб даю, что 99% будет.


При этом инженеры боятся, что они могут ошибиться и не попасть в эти 99%, и будет совсем больно. Поэтому внутри, у себя в команде, они договариваются: вот мы хотим, чтобы было 99.9%, тогда у нас есть в запасе 0,9%, и мы точно попадём. И вот этот их внутренний договор называется SLO.


МИ: Значит, SLA для внешних, а SLO внутри.


АА: И считается SLO по запросам от пользователя, как правило. Чем ближе к пользователю подошел, тем лучше. Идеально, если в java-скрипте тусуются отдельные элементы в браузере, и этот скрипт репортит куда-то о том, что не удалось аджаксом скачать какой-то кусочек элемента. Потому что часто, если у нас упал самый главный nginx, то это у нас в nginx логов нет, значит запросов нет, latency хорошие, всё хорошо. А тут java-скрипт начнет говорить, что есть ошибка. Либо, если это мобильный клиент, он прямо с мобилки сыплет свои ошибки, это просто идеально: мы всё знаем и считаем.


И есть ещё SLI (Service Level Indicator) это те параметры, о которых мы говорим. Например, задержка для клиента, как быстро он скачал страницу это один SLI. Либо количество ошибок, сколько клиентов у нас получили пятисотый статус ответа вместо двухсотого это второй SLI. Вот два очень распространенных SLI: latency и количество ошибок.


М: Ну и про Error budget расскажи. Я так понимаю, это некий бюджет, который закладывается на ошибки, на простой. Если команда разработки и в целом проект его превышает, то что-то происходит. Правильно ли я понимаю?


АА: Когда мы зафиксировали SLO и сказали, что обязуемся, чтобы 99.9% запросов валидно ответили пользователю, то у нас остались 0.01% запросов к сервису, которые могут пофейлиться. Если у нас там миллион запросов, то 0.01 от миллиона считаем. Это и есть наш Error budget или бюджет на ошибки.


Когда у нас есть в запасе эта цифра, мы в некоторых ситуациях можем не думать, что написали код, который не очень протестирован. Если у нас полно Error budget, мы можем не тратить ещё неделю на тестирование кода, а прямо сейчас выкатить его, потому что нам очень надо посмотреть, как он работает (понятно, что при этом мы должны уметь быстро откатываться и выкатывать код не на всех пользователей, а на 5%). Если код начал валиться, мы его откатили, перестали вести на него трафик и немного потратили своего Error budget. Но это позволило нам очень быстро проверить гипотезы и доставить ценности.


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


ПС: Мне кажется, Error budget ещё очень полезен для оценки, какие решения сейчас нужно внедрять, в каких решениях назрела необходимость. Предположим, у нас есть сервис, который в теории доступен 100% времени. Он работает без ошибок, мы его не разрабатываем или нечасто деплоим, новые ошибки туда не приезжают. А когда мы его деплоим, у нас нет никакого rolling updates и вот этих всех модных штук, мы просто выключаем и включаем заново. И смотрим, что, например, генерируем таким образом энное количество ошибок.


При этом мы понимаем, что если деплоим раз в какое-то количество времени, то, даже несмотря на то, что никакой системы rolling updates нет, такие деплои за рамки Error budget не выходят. И это такой прекрасный показатель сказать, когда команде нужно задумываться о технических вещах. Вот сейчас назрел момент, мы начали выходить за Error budget, давайте его пофиксим хотя быть тем, что начнём выкатываться без простоя. Или мы действительно можем выкатываться с простоем.


SRE-инженер это клей, а SRE это хайп?



МИ: Если всё сложить, то получается, что SRE-инженер это некий человек, который мыслит одновременно и в плоскости инфраструктуры, доступности приложений и в плоскости разработки. Некий клей, который связывает эти два дела и думает больше о конечном клиенте и доступности, чем о написании кода или настройке Terraform и подобных вещах. Он вне рутины и визионирует эти процессы.


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


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


В таком случае SRE-инженер никакой не клей, а админ, который теперь отвечает не только за работу в продакшене, но в том числе и разбирается в коде. И нет никаких разных целей у отдела сопровождения и отдела разработки. Есть одна цель рабочий продукт, который нужно сделать. Это не тот продукт, который никогда не падает (сервер, отключённый от питания, тоже никогда не падает) рабочий продукт это штука, которая приносит деньги компании. А для этого он: а) должен работать, б) должен обновляться. Так что отделы разработки и SRE реализуют одну цель.


МИ: Окей, с задачами SRE разобрались. Теперь другой вопрос: шумиха вокруг SRE это хайп, или все-таки у подхода есть реальное будущее? Второй Kubernetes или временное явление?


АА: Сложно сказать, DevOps это хайп или уже не хайп? Наверное, уже не хайп. Но если SRE это случай DevOps, то кто-то будет его использовать, а кто-то нет.


МИ: Мне кажется, хайп спадет, но останутся те, кто нашёл в этом пользу. На первый план выйдет что-то другое.


ПС: Как называть это в будущем SRE или DevOps это уже проблема будущих людей, а вот что инфраструктурой начнут заниматься люди, которые с руками, с головой и умеют код писать думаю, это весьма вероятно.


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


АА: Тут сложно говорить, потому что компаниям нужна стабильная работа, а как называются те, кто умеет делать твой сервис стабильным, неважно. Просто в какой-то момент сисадмины поссорились с разработчиками, зависели друг от друга, но не договаривались. Тогда придумали DevOps, чтобы подружить их, и для бизнеса DevOps стал очень выгоден: со всех сторон бенефиты.


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


По сути, DevOps может делать и работу SRE измерять значения максимально близко к пользователю и знать, как часто сервис падает. Но в текущих реалиях DevOps немного не про это. Случилось культурное изменение. И тут на сцену выходит SRE, и компании понимают, что им нужен ещё один DevOps, но он будет не DevOps, а SRE. Очень часто люди, работающие над DevOps и SRE могут быть взААмозаменяемыми.

ПС: Вот ты Марсель говоришь, человек, который умеет всё. Но я не согласен. Артём, как ты думаешь, бывают ли джуниор SRE-инженеры?


АА: Думаю, даже бывают SRE-интерны.


ПС: Наверное, бывают разных способностей люди. Если есть какая-то система обучения SRE, то интерна можно себе представить. Но по моему опыту, SRE-инженер это такой человек, который видел разработку (если он со стороны разработчика, то минимум стал мидлом), который занимался многими вещами в компании, в том числе видел администрирование и сопровождение представляет, что там ребята делают.


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


Как внедрить SRE в компании



МИ: Внедрение SRE, как и DevOps, это революция или эволюция? Стоит ли пушить решение о том, что нам нужен SRE или DevOps в компании?


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


Мне понравился доклад на одной из конференций. Там был тезис, что DevOps нельзя внедрить насильственно. Единственный вариант разогнать всю команду и набрать другую из людей, которые с DevOps знакомы. А чтобы никого не разгонять, надо взять несколько админов и послать на DevOps-конференцию. Пусть они послушают, поплюются, расскажут всем, что это фигня. Взять потом других админов или разработчиков, отправить туда. И постепенно за годик-два компания начнёт гореть идеями DevOps и со стороны разработки, и со стороны администрирования. Тогда команды сами придут к бизнесу и скажут: Чуваки, мы тут такую штуку знаем, давайте мы её внедрим. Из такого состояния SRE можно, пожалуй, считать революционным. Но когда нет никакого движения, никакой основы, то ничего не получится.


АА: Я вполне согласен с Павлом. Ещё часто SRE, как и DevOps, могут заносить сами владельцы бизнеса, которые хотят стабильности. Но насильно в инженера не занесёшь, надо продать, а продать тяжело, если кто-то упирается.


ММ: Мы сейчас по большей части поговорили про инженеров-разработчиков. Есть ли у вас представления, на какие аспекты работы проекта стоит обратить внимание с бизнесовой части? Как бизнес может понять, что им нужен SRE или какой-то другой подход в управлении проектами?


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


ПС: В целом да.


SRE это же одно из возможных решений. Если есть проблема с доступностью сервиса, стабильностью, можно задуматься об SRE. Или в то же время задуматься о введении каких-нибудь KPI, кнутов на входе, и начать разработчиков бить за баги. Тоже как вариант, наверное, тоже может работать. SRE точно не будет серебряной пулей, которая спасёт от всего. Но вот проблему стабильности, проблемы в организации IT-команды, когда есть классический конфликт между администрированием и разработкой, решить поможет.

Что должен знать SRE-инженер и сколько может зарабатывать



МИ: Как вообще вот этим мифическим SRE-инженером стать? Что нужно сделать? Какими скиллами обладать, чтобы претендовать на такую позицию?


ПС: Я недавно размышлял над этим вопросом. Думаю, особенно у нас, в России, есть проблема. Вот если бы конкретный живой человек спросил у меня, я бы ему рассказал об определённых вещах, на которые нужно посмотреть. Он бы пришёл в первую попавшуюся компанию, где нужен SRE, а ему бы начали задавать вопросы о рейдах, например, или еще каких-то странных вещах. И тут вопрос: когда вы в современной компании последний раз видели живой рейд и зачем? Наверное, это полезно знать, но честно мне это сейчас не нужно в моей работе, и я на эти вопросы не отвечу. В большинстве случаев это не задача SRE. Есть, конечно, системщики, которые этим занимаются. Но у большинства компаний не железные сервера, а есть какое-то облако, купленное или свое, и приложение нужно эксплуатировать в рамках этого облака.


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


Современные DevOps-инструменты типа infrastructure as code, инструменты оркестрации, как Kubernetes, инструменты мониторинга Prometheus, Grafana, возможно, и Zabbix всё еще бывает полезен. Docker. Это основной технологический список. Но очень важно то, в какую компанию вы придёте. Если ей нужны настоящие SRE, то с этим списком, скорее всего, получится пройти. Если нужны переименованные админы, то у вас начнут спрашивать про рейды и так далее.


АА: Я бы добавил, что Network тоже важен для SRE, потому что твои сервисы включаются по сети. И она, возможно, не ARP.


МИ: Да, есть такое. Я про это даже как-то рассказывал, что ездил в EPAM в гости, и мне жаловались, что сейчас растёт поколение девопсов, которые делают банальные ошибки, связанные с сетью.


МИ: Требуется ли делать упор на умение программировать как таковое или всё-таки надо знать какой-то конкретный язык?


ПС: Программирование как таковое это когда вам объяснили на Паскале в институте общие принципы программирования, циклы, операторы, ветвления? Нет, этого будет недостаточно. Но я знаю, что нормальный программист довольно легко переходит с одного языка на другой. Особых требований к языкам нет. Есть более популярные и менее популярные.


МИ: Стоит ли учиться программированию по книгам?


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


ПС: Я думаю, про языки проще найти готовые курсы, туториалы и документацию, если язык не первый. Книжки это скорее основы, которые в институте проходят. Но они довольно медленно устаревают. Тот же Чистый код читать это хорошо.


МИ: Что конкретно должен уметь кодить SRE? В какую сторону смотреть?


ПС: Я могу дать конкретный пример. Prometheus работает по следующему принципу: у него есть экспортеры (штуки, которые собирают данные систем и предоставляют их в формате, понятном для Prometheus), он приходит к экспортерам и собирает данные. Такая нормальная задача SRE была бы взять какую-нибудь часть системы, у которой всё еще нет опенсорсного решения, и сделать для неё один из экспортеров в Prometheus, к примеру. Или сказать разработчикам: Ребята, у нас там система сбора логов такая-то, а давайте вы все будете собирать логи и писать их вот в опредёленном виде, и вот вам для этого библиотека. Встройте её во все свои приложения. Библиотека для таких системных вещей типа логи, трейсинг и так далее. Тоже вполне нормальная задача для SRE-инженера.


МИ: Сколько зарабатывает SRE в России? У меня под рукой нет данных, но думаю, зависит от компании и требуемых скиллов.


ПС: Я тоже без понятия, но в целом про зарплату могу сказать так: когда я только начинал заниматься сопровождением, админы чаще всего получали меньше, чем разработчики на одинаковой позиции. Сейчас DevOps, SRE получают или так же, как разработчики, или больше, потому что и скилла нужно больше. Так что посмотрите на Хедхантере, сколько в среднем получают разработчики, и делайте выводы. Мне кажется, от 120-150 тысяч. Разумная верхняя граница, думаю, 250-300. Но границ, в принципе, нет.


Вакансии SRE на Headhunter


Что будет на интенсиве по SRE?



МИ: SRE это про практику. И как раз об этом мы будем говорить на нашем интенсиве, который пройдет 11-13 декабря. Будет много кейсов, с которыми сталкивается SRE-инженер.
Там же мы рассмотрим на практике построение метрик, проблемы с доступностью и прочее, прямо своими руками, реальными инструментами. Павел уже упомянул экспортеры, Prometheus, графики. Будем всё это щупать, со всем этим разбираться.


ПС: Я еще про интенсив добавлю чуть-чуть. Мы пытаемся за три дня дать людям понять, что такое быть SRE-инженером, пропустить это через себя. Показать три дня такой работы. Практику.


Мы дадим вам систему и будем её ломать и заставлять вас её чинить в коде, в инфраструктуре, смотреть на метрики, на логи, объясняться с пользователями и так далее. Мы показываем то, что написано в книгах Google об SRE через призму реальной работы.


МИ: Именно так. Там будут и Павел, и Артём. Еще к нам присоединится Иван Круглов. И мы все вместе будем во всем этом разбираться.


Блиц по вопросам из чата


SRE должен быть свой у каждой команды?


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


Что, если сервис зависит от другого сервиса? Например, авторизации. Сервис авторизации падает сильно и надолго, это приводит к исчерпанию Error budget.


АА: Если ты зависишь от другого сервиса, ты не можешь написать сервис надежнее того, от которого зависишь. Но тут есть нюансы, потому что ты можешь ретрААть некоторые запросы в рамках таймаута. Посылать сразу несколько запросов. То есть, если у тебя есть сервис, от которого ты зависишь, можно в него послать одновременно три запроса. И, возможно, один из них с большей вероятностью выполнится, чем просто один отправленный запрос. Либо ты можешь договориться с бизнесом и своими пользователями, 500-я ошибка это точно ошибка. А 403-405 могут считаться не полноценной ошибкой, а в рамках предоставления сервиса. И когда недоступен сервис, от которого ты зависишь, ты своему клиенту отдаешь код ошибки, чтобы он знал, что нужно зайти позже. И это может считаться в рамках SLO, если договориться об этом.


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


Когда сервисы общаются между собой, они же все клиенты друг друга. Поэтому все эти вещи про SLO и Error budget распространяются не только на конечного пользователя. По сути, мы для каждого сервиса компании можем объявить свои SLO и Error budget, и каждый сервис обязуется для всех своих клиентов предоставлять этот определенный уровень доступности. Причем, можно говорить не только про сами приложения и про их метрики. Мы можем говорить и про другие системы компании с теми же уровнями. Если есть команда, которая занимается сопровождением баз данных, то она может объявить свои уровни и поддерживать их. Мы внутри компании постоянно этим всем пользуемся.


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


Имеет ли место SRE в компании с редкими релизами (раз в пару лет, например)?


А: Всё-таки это сделано в Google, и тут больше вопрос про надежность, а не про релизы как таковые. С редкими релизами имеет смысл собирать статистику, знать, насколько ты надежен, где что ломается и как это чинить. Можно просто два года подставлять костыли, чтобы через три года зарелизиться. Вопрос зачем это надо, если мы все равно не можем починить быстро? Ну, можно чинить не быстро тоже вариант, какие-то прослоечки делать.


Какие знания нужны, чтобы принять участие в интенсиве с пользой? Для начинающих или опытных?


МИ: Отличный вопрос. Крайне желательно иметь бэкграунд разработки. У нас приложение будет на Python и, если вы админ и кодили, и делали скрипты, наверное, вы тоже разберётесь. Но, как мы уже выяснили, все-таки SRE-инженеру нужен бэкграунд разработчика. Наши приложения будут работать в Kubernetes и крайне желательно с ним тоже уметь работать. Будем использовать Grafana, Prometheus.

Подробнее..

Внедрение CICD в чем основная задача пайплайна и как сделать лучше жизнь разработчиков

26.11.2020 04:22:27 | Автор: admin


О своём опыте построения пайплайнов, правильных и неправильных подходах к CI/CD, здоровых профессиональных конфликтах и реализации GitOps в неидеальном мире рассказывают спикеры курса Слёрма по CI/CD Тимофей Ларкин и Александр Швалов.


Кто говорит


Тимофей Ларкин
Руководил направлением автоматизации в дирекции BigData компании X5 Retail Group, строил платформу для разработки и хостинга продуктов. Сейчас работает платформенным инженером Тинькофф.


Александр Швалов
Инженер Southbridge, настраивает и сопровождает проекты на Kubernetes. Помогал настраивать CI/CD как для небольших, так и для крупных компаний. Certified Kubernetes Administrator.


Почему тема настройки CI/CD до сих пор остаётся актуальна? Почему до сих пор все не научились это делать?


Т: Я думаю, по той же причине, по которой уже одиннадцать лет существует слово DevOps, но некоторые компании и коллективы только-только запускают так называемую DevOps-трансформацию. По той же причине, что всегда есть отстающие, которые пока в группе Low Performеrs. Не все ещё научились. Не всем это вдруг стало нужно, не все так быстро разрабатывали внутри себя технологическую экспертизу.


То есть дело не в том, что тема сама по себе невозможна для реализации, а в том, что просто кто-то ещё последовательно до неё не дошёл?


Т: Да, всё так.


А: Я добавлю, что есть некоторые компании, стартапы, где два человека, допустим, сидят, и им пока не нужен CI/CD. Может быть, они о нём знают, но пока без него обходятся. И внедрение это должно быть на каком-то этапе, когда проект вырос до точки, где это необходимо. Тогда это принесёт больше плюсов, чем минусов. Когда есть только один талантливый программист, ему намного быстрее будет разрабатывать без CI/CD. Ну, и да, отсталость некоторых проектов. Я сам работаю с клиентами, и у них есть сайты с большой посещаемостью, куда они заходят и в середине рабочего дня вешают заглушку и начинают править код. Прямо на продакшене.


Какие это проекты?


А: Да просто интернет-магазины. Небольшие, естественно. В больших очень критичны простои. Там используют серьёзные технологии. А небольшие может, не слышали, может, им это неинтересно. Мы иногда рассказываем, что и как можно настроить, но без особого энтузиазма воспринимают. Мол, старое работает, и ладно.


До вопроса внедрения мы ещё дойдём. Расскажите о своём опыте построения CI/CD, что это были за проекты?


Т: Я около двух лет назад пришёл в X5 Retail Group как, на тот момент, единственный сотрудник нового подразделения, и на мне висела задача построить платформу для разработки, чтобы разработчикам дирекции больших данных было, где собирать свой код и где его запускать. Там достаточно много разных проектов. Какие-то более будничные: прогнозирование оптимальных цен, оптимальных промо-акций (вроде скучное, но приносит прибыль). И что-то более хайповое, вплоть до проектов по компьютерному зрению.


Технологии были разные. В основном для бэкендеров это Java, для фронтендеров это React. Ну, и для дата-сайентистов Python (Anaconda, Jupyter Notebook и тому подобное). Я должен был создать для них эту самую платформу разработки. То есть, CI/CD-серверы (у нас был GitLab), Kubernetes заставить всё это работать в связке и помочь продуктовым командам начать этим эффективно пользоваться.


Два года назад это началось и? Процесс завершился?


Т: На сегодняшний день я уже в X5 не работаю, но там ребята уже активно развились, очень хорошо освоились. Естественно, дирекция больших данных сейчас и то, что было два года назад это совершенно разные вещи. По количеству рост сотрудников, наверное, раз в 5-6. Ну, это была очень молодая дирекция на тот момент. Она очень быстро росла. И по компетенции, по парку серверов на этой рантайм платформе, по всему прочему рост был на порядки.


И люди тоже очень сильно компетенций набрались. Как я говорил, тогда я был единственным сотрудником отдела, а сейчас там примерно 10 человек. И были какие-то измеряемые успехи. Я воспроизводил исследование Ускоряйся, которое лежит в основе методики ежегодных отчётов State of DevOps, и по результатам этого исследования в масштабах одной только дирекции успехи были.


Александр, какой у вас опыт?


А: У меня опыт построения CI/CD первый был на третьем или на четвёртом потоке Слёрма, где я участвовал в качестве студента. Ведь Слёрм изначально задумывался как средство обучения сотрудников Southbridge, а я работал в Southbridge и как раз на одном из потоков плотно познакомился с CI/CD. До этого у нас было несколько клиентов с не совсем правильными подходами к CI/CD, а на обучении я увидел такой конкретный, цельный пример, и потом он мне очень пригодился.


У нас пришел клиент, ему нужно было мигрировать из Docker Swarm в Kubernetes некий стек и плюс распилить монолит. Там были уже несколько контейнеризованных микросервисов и плюс был монолит, который разработчики пилили и добавляли микросервисы, и вот это все мы заворачивали в Kubernetes. Поэтому туда я взял пример нашего CI/CD из Слёрма. Он простенький, но вполне себе рабочий. И в итоге мы дошли до того, что последние микросервисы разработчики деплоили уже сами, без нашего участия. Мы всё построили и отладили, а дальше они уже сами всё по шаблонам делали.


Если по этапам описать проделанную вами работу, в чем она заключалась? Как вы дошли от нулевой точки до момента, когда команда уже сама могла что-то делать?


А: Сначала мы адаптировали практически вручную то, что уже было в Docker Swarm микросервисы. Потребовался небольшой допил конфигурации. Плюс, helm-чарты написали первые. Использовался Kubernetes. Helm 2 на тот момент ещё был популярен. Ну и GitLab CI. После этого разработчики задавали множество вопросов, иногда делали не так, как мы задумывали. Мы поправляли их. У нас не было прямо тесной связи, мы иногда приходили и советовали, где как лучше сделать, чтобы работало. Таким путем проб и ошибок пришли к тому, что они теперь без нас отлично справляются.


До этого вы упомянули неправильные подходы. Что это было?


А: В целом неправильный подход для мелких проектов, наверное, оправдан. Потому что там не было CI-инструмента. У нас в курсе будут описаны некоторые уже устоявшиеся инструменты (online, self-hosted-решения). А там было проще некуда: задание по расписанию, git pull из репозитория с кодом. Буквально каждые две минуты он делает git pull. И когда разработчик в нужную ветку пушит изменения, он понимает, что это попадёт на продакшн. Т.е. через вот этот промежуток времени 1-2 минуты скрипт сработал, и всё попало на продакшн. Разработчику не нужно было самому ходить. Это такой небольшой пример CI/CD. Естественно, о тестах говорить не приходилось, всё было на совести разработчика.


Какие проблемы могут возникнуть при таком подходе? Ошибки?


А: Да, плюс откат. Если мы из этой ветки пушим постоянно, то чтобы откатиться, нужно будет в ту же ветку запушить уже более поздним коммитом нужную версию, уже исправленную. А не вернуться к предыдущему коммиту или предыдущему релизу/тегу.


Т: Тут еще, понимаете, это очень здорово работает, пока там действительно стартап из двух человек. И один только финансами занимается, а кодит только второй. Зачем ему тогда сильно следить за качеством своего кода? Зачем ему выстроенный CI/CD процесс? Он и так отлично знает, что у него где лежит. Проблемы начинаются, когда такую модель работы переносят на командную разработку, и там есть 2-3-4 сеньора, которые всё отлично знают, но никто не может начать с ними работать, потому что они не столь ответственно относились к качеству кода, не запускали тесты. Вроде и так всё понятно, но всегда тяжело учесть, что придёт человек со стороны а в больших компаниях это постоянно случается которому будет сложно объяснить, что тут вообще происходит. Цель CI/CD не просто автоматизировано допихать код до продакшена, но и следить за его качеством.


Мне кажется, это даже не основная цель пайплайна собрать какой-то артефакт, Docker-образ и задеплоить. В любом случае, пайплайн должен уметь делать это безупречно. Потому что это такая типовая задача, которую мы должны легко делать каждый день с нашим кодом. Но вообще, в процессе разработки продукта полезно иметь здоровый профессиональный конфликт. Это конфликт между разработчиками и инженерами по обеспечению качества. И пайплайн тоже должен стоять на страже качества кода. Чтобы тыкать разработчика носом и говорить: Так, вот тут у тебя код не по стандартам отформатирован. Вот тут линтер ругается, тут юнит-тесты не проходят. Давай откатывай и переделывай.

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


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


Т: Да, нужно прийти к соглашению, что мы считаем плохим/хорошим, как мы будем делать. Но в целом, это спор ни о чем. Не так важно, до чего вы договоритесь у вас будут табы или пробелы. Это все второстепенно. Выберите уже что-нибудь. Это лучше, чем ничего. В этом плане Golang такой интересный пример. Он не стал давать разработчикам волю самим выбирать, какое будет соглашение о качестве. Он просто сказал: Ок, у нас отступы табами, табы шириной 8 символов. И всё, не колышет. Это встроено прямо в утилиты самого Golang. Есть такое высказывание: Все его ненавидят, но при этом он самый лучший. Потому что хоть какой-то стандарт есть. Встроить проверку соответствия кода выбранным стандартам в пайплайн это буквально две строчки.


Как обеспечить контроль выполнения стандартов?


Т: Мне не приходит на ум ни один язык, где нельзя какие-то юнит-тесты сделать. Как правило, они делаются обычно чуть ли не средствами самого компилятора. Это одна строчка. Если нет юнит-тестов, когда первый будет написан, он автоматически будет выполняться. Потом, если это компилируемый код, тогда сам факт, что компиляция прошла успешно, тоже о чём-то да говорит.


Значит, есть несколько таких ступенек?


Т: Да. Всегда принцип 20/80. 20% усилий дают 80% успеха.


А: Тут упомянули проверку кода. Это достаточно важно, и многие инструменты содержат в своём названии как раз CI. Travis CI, GitLab CI. И это очень важно проверить и программиста носом натыкать, это экономия труда тестировщиков. Может, потом код скомпилируется, запустится, даже будет первое время выглядеть нормально, но потом тестировщик найдёт ошибку. А если это сделает автоматика, это намного быстрее и экономия труда, половины рабочего дня тестировщика.


Вы сказали программиста носом натыкать. Это тот самый конфликт между разработкой и QA, о котором говорил Тимофей?


А: Могу привести свой пример, поскольку работаю с CI/CD каждый день, но не с кодом, а с конфигурациями. У нас есть линтеры лишний пробел поставил, он уже ругается. Иногда злишься, ведь это просто формальность, ни на что не повлияет, но это приучает к качеству. И стандарты эти нужны для обеспечения командной работы в том числе. Чтобы новый человек пришел и быстро разобрался.


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


А: Можно провести аналогию с конвейером. Если норма у рабочего на конвейере пять деталек в час, а он такой стахановец и делает десять. Это уже может быть непредсказуемость, если мы всегда будем считать, что он делает десять, хотя норма пять. Поэтому лучше пусть стабильно делает пять, но качественно. Можно фигачить код без стандартов, он будет работать, но новый человек не въедет быстро. Поэтому в командной работе есть ограничения, чтобы ото всех можно было получить одинаково стабильную работу. А не так, что один вкалывает, а другой сидит.


Т: А если сеньор проверяет код джуна и говорит: Слушай, а тут вот у тебя функция может вернуть исключение, а ты его не проверяешь. Это сеньор тогда против джуна? А что меняется, если то же самое делает автоматика? Что сеньор, что автоматика они против плохого кода, а не против разработчика.


Давайте мы теперь чуть отступим и поговорим про внедрение CI/CD. Как компании и команды приходят к тому, что пора что-то менять? Ошибки слишком частые, порядка нет, что-то ещё?


Т: Это очень по-разному случается. Вот мой опыт в X5 был такой, что была полная поддержка со стороны менеджмента, но при этом есть менеджмент всей дирекции, а есть отдельные продуктовые команды, у которых некое двоевластие. С одной стороны, есть руководитель отдела разработки, который, наверное, ратует за поставку качественного кода, но, с другой стороны, это продуктовая команда, у них есть дедлайны для поставки фич, и не всегда ясно, что поставить в приоритет. Конечно, нет откровенно глупых людей, которые говорят, что весь этот ваш DevOps не важен, нам нужно фичи пилить. Но при этом в разговорах проскакивает моментами. Мол, ну, я не знаю, у меня сейчас есть бюджет на одну ставку, и для меня вывод очевиден, кого я возьму DevOps или ещё одного разработчика. Мне нужно разрабатывать, так что я возьму разработчика.


Как сделать хорошую мину при плохой игре? Поскольку у нас есть такой инфраструктурный отдел, который ещё в какой-то степени DevOps-евангелисты, то есть отдел, которым я руководил в X5, лучшее, что можно сделать, это облегчить командам внедрение этих пайплайнов, этого CI/CD. Обучать людей до тех пор, пока это возможно, но лучше всего что-то сделать за них. Зашаблонизировать типовые действия. Например, даже банально собрать докер-образ и запушить его в репозиторий. Это нужно авторизоваться в docker registry. Рассчитать, с каким тегом мы соберем докер-образ. Это docker build, потом пуш несколько раз. Возможно, если мы хотим кэши, то нужно сначала скачать старый образ, который уже был, использовать его как кэш, потом закачать новый. Это куча рутины, которая может растянуться строчек на пятнадцать, но это всё однотипно.


Если инфраструктурная команда понимает немного в DevOps, она осознаёт, что это её задача. Сделайте Developer Experience получше. Зашаблонизируйте это, чтобы умещалось в три строчки, а не в пятнадцать. Тогда разработчики будут мыслить не категориями: надо спулить образ, собрать, туда-сюда. А категориями: а вот здесь Docker. Просто один блок, модульный такой. И им будет легче. Они тогда смогут абстрагироваться от деталей и больше заниматься своей непосредственной работой. А именно писать код. В этом плане DevOps он в том, чтобы фасилитировать, предоставлять разработчикам возможность лучше делать свою работу.
И таким образом снижать сопротивление.

А: Отвечу на тот же вопрос со своей стороны. У меня пример внедрения не из мира разработки, больше из мира администрирования. У нас в один прекрасный момент сказали: Мы вот подошли к тому, что откладывать нельзя. Базис мы подготовили для вас. Теперь все новые проекты вы будете создавать вместо старого пути по CI/CD. Вот у вас есть шаблончик, создаете в GitLab и работаете с ним. Каждая команда будет вольна его улучшать. Так и внедряли. Достаточно императивно. В некоторых проектах, когда этот путь нёс больше вреда, чем пользы, мы откатывались на старую версию, но сейчас половина проектов работают через CI/CD. Мы управляем конфигурациями серверов через GitLab CI. Точно так же, как у разработчиков, там есть проверки, линтеры.


Раз уж заговорили про администрирование, поговорим про GitOps. Что это такое, и какое значение имеет: это всё-таки хайп или полезность?


А: Мало что могу сказать про GitOps. Мое мнение такое, что это достаточно хайповое слово. В последнее время я много его слышу. Три года назад так хайповали на DevOps, так что GitOps для меня одно из слов, примазавшихся к DevOps. Для меня это больше хайп.


Это вообще о том, что вся правда хранится в Git. Там и управление конфигурациями серверов, Infrastructure-as-Code, и код проекта, который потом на эти сервера поедет, и описание процесса, как мы с исходного кода получаем приложение на серверах. Так это я понимаю. Возможно, Тимофей меня дополнит, исправит.


Т: GitOps, мне кажется, чуть более честное словечко, чем все эти DevOps, DevSecOps и так далее. Потому что оно значит почти буквально то, что и говорит. Это именно ведение своих действий по эксплуатации своего софта, своей инфраструктуры через Git. Вся правда хранится в Git.


Что это на практике значит? Вроде как мы запушили какой-то код в наш репозиторий, автоматически запустился пайплайн. Что-то произошло, допустим, какие-то манифесты отправились в Kubernetes. И вот у нас то, что мы запушили в Git, это теперь то, что находится в Kubernetes. В принципе, это тоже GitOps, хотя не всегда его так называют. В частности, это так называемая push-модель, когда мы информацию из репозитория толкаем на продакшн.


Еще бывает так называемая pull-модель. Когда, если речь идет о Kubernetes, то у нас там какой-то агент стоит, который мониторит изменения в репозиториях, и если видит, что там что-то закомитили, что-то изменилось, то он стягивает эти изменения. Он умеет и Helm, и Kustomize делать, и просто манифесты ямликами подтягивать. И опять же отправляет их в Kubernetes.


Некоторые пропоненты GitOps вовсе закрывают любое редактирование в Kubernetes и позволяют изменять состояние кластера, только подтягивая изменения из Git. Если этого не делать, всегда есть риск, что из-за чьих-то ручных действий состояние кластера и то, что описано в репозитории разъедется. Кто-то там ручками что-то поменял, а в Git ничего не поменялось. Поэтому частенько говорят про GitOps именно в контексте pull-модели, когда, ну, поменял ты что-то в Kubernetes, ничего страшного, потому что автоматика в ближайшие полчаса все равно вернет все, как описано в Git.


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


К примеру, смежный отдел, который управлял Data Lake в X5, быстро пришёл к тому, что у них вся конфигурация из двух сотен машин управлялась через Ansible, а он запускался каждые 30 минут, как пайплайн в GitLab. Это пример более-менее правильного применения GitOps.


Ну, и те инструменты, которые для GitOps используются, они ещё в какой-то мере нам подсвечивают: а у нас задеплоено именно то, что мы хотим? Иногда они не возвращают автоматически состояния, а просто зажигается желтый или красный светофор: Оп, ребята, у вас рассинхронизировалось состояние тут и тут.


Александр, когда вы говорили о том, как строите процесс работы с клиентами в Southbridge, вы упоминали что-то похожее на GitOps. Настройка конфигурации через описание в Git, это не то же самое?


А: В идеальном мире да. Но у софта зачастую очень много настроек. И чтобы в каждой ручечку/переключатель/ползунок поменять, роль управления конфигурацией должна быть очень развесистая, раскидистая. Либо шаблонизированная. Иногда бывает, что настройки просто нет, и мы идем вручную поправляем. Разработка не успевает за эксплуатацией. Потому что иногда задачи бывают критичные. А чтобы всё разработать, у нас просто нет времени. Но в идеальном случае мы делаем именно то, что описал Тимофей.


Тимофей, а подход GitOps учитывает это обстоятельство неидеального мира?


Т: Это тяжело, конечно. Потому что нам надо бизнес делать, бабки зарабатывать. Казалось бы, вот она, ручка, сходи и поменяй, надо же. Есть потребность, а тут какой-то скрипт ещё писать, дорабатывать helm-чарты. Поэтому да, есть соблазн всё быстренько сделать руками.
Чтобы и бизнес-потребности учесть и себе codebase не испортить, можно хотя бы завести тикет, что вот тут вручную настраиваемое значение, но это баг. Мы положим тикет в бэклог, потом обязательно вернемся и допилим тут автоматизацию. Главное не потерять места, где мы руками настраивали.


В чём ключевые преимущества подхода GitOps?


Т: Основное мы достоверно знаем, что у нас запущено в продакшене. Что все четко описано в репозитории, и не возникает сомнений, что кто-то руками поменял.


А: Когда большая команда, это очень важно, что все могут в любой момент посмотреть и увидеть, какая сейчас конфигурация работает на нужном сервере. Потому что если там 1-2 человека, они могут всегда договориться, а когда 15 человек, GitOps сильно экономит время. Не надо ходить, опрашивать, выяснять, откуда ноги растут у несоответствий.


Чем GitOps отличается от подхода Infrastructure-as-Code?


А: Это не только инфраструктура, но еще и приложение, как код. Они хранятся в единой точке. Может, в разных репозиториях, но в одном инстансе GitLab. Можно легко посмотреть состояние инфраструктуры и приложения. Плюс, в идеальном мире может быть вообще связана инфраструктура с кодом. Мы создали новый репозиторий, настроили с нуля хитрый пайплайн, запушили код и он сам пошёл, создал себе инфраструктуру где-нибудь в облаке и задеплоил туда приложение, которое мы туда написали. Это идеальный, конечно, случай, но думаю, где-то это работает. Например, в больших компаниях.


Т: Да, там предлагают даже держать отдельно несколько репозиториев. Один это просто сам код приложения, в котором собирается образ или бинарник. Второй репозиторий туда генерируются, допустим, манифесты для Kubernetes. Третий это такой большой репозиторий, который нам рассказывает, что в нашем кластере манифест из этого репозитория за таким-то тегом, из этого такой-то версии. Он уже просто по номерам версий описывает, что вообще в нашем кластере запущено. На это иногда даже автоматику натягивают: изменили приложение, только код, повесили на него новый тег, а там потом автоматически новый манифест запушился в репозиторий с манифестами, и нужная строчка с нужной версией изменилась в том месте репозитория, которое описывает общее состояние кластера.


Это такая идеальная система?


Т: Ну, да.


CI/CD это такая штука, которую один раз настроил и забыл, или это процесс, который нужно поддерживать?


Т: И да, и нет. Когда он только внедряется, не бывает сразу идеально. Когда в X5 я внедрял, то начальник отдела разработки спрашивал у разработчиков, сколько времени в неделю они тратят на обслуживание их CI/CD. Кто-то отвечал: А что там обслуживать? Вот мы настроили и забыли. И какое-то время это работает. Если сделать сходу правильно, можно сделать очень модульные блоки. И потом не сильно трогать нижележащий код, который это делает, а просто появился новый проектик/микросервис, подключили к нему типовые модульные блоки и поехали дальше. Но пока все учатся, что-то допиливается. Приходится на первых порах долго и мучительно внедрять новые хорошие практики в трудно обслуживаемый код. Дальше уже полегче.


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


Т: Все очень по-разному. У меня в X5 были продуктовые команды очень разных способностей. Какие-то хорошо въезжали в процесс, и редко надо было им помогать. Были более слабые. К ним привязывали инженера, который помогал писать пайплайны. Работал, в некоторой степени, приходящим релиз-инженером в их команде. Но в X5 порядка 9-10 DevOps обслуживали потребности где-то 200 техспециалистов.


Сейчас я работаю в Тинькофф, тоже в платформенной команде, но там масштабы немного другие. Нас 8 человек, а разработчиков тысячи полторы. И невозможно предоставлять каждой команде DevOps как сервис. Поэтому там предполагается, что команда сама добывает эту экспертизу или нанимает себе DevOps. Либо сами разработчики этому обучаются.


А: Моя версия такая, что да, вначале идет активная разработка. Мы программируем пайплайн, что за чем будет идти, потом ситуация может устаканиться. Если в архитектуре проекта нет глобальных изменений, всё может работать год без правок. Но в мире все меняется. Микросервисы могут быть переписаны за две недели. И если их переписали на другом языке программирования, то тесты выкидываем и пишем новые. Поэтому CI/CD тоже требует обслуживания.


Ну и добавлю, что у разработчиков разная компетенция. Кому-то постоянно нужна помощь, а кому-то нет. Вот у нас был пример с одним из клиентов. Мы им настроили базовые CI/CD, всё показали. Через какое-то время они к нам приходят и говорят: А мы вот переписали всё по-своему. Мы только и ответили: Ух ты, молодцы. Они просто взяли все в свои руки.

Подробнее..

Новые ограничения в использовании Docker Hub и как GitLab реагировал на их ввод

30.11.2020 22:22:08 | Автор: admin

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

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

Что же произошло?

Публичный регистр контейнеров Docker Hub очень широко и часто используется сообществом DevOps для достижения разнообразных целей: запуска CI/CD задач, стандартизации процессов, выката контейнерных приложений как в sandbox, так и в production. Как только мы узнали о введении новых ограничения по количеству запросов, мы начали анализ новых правил, чтобы понять, как они повлияют на работу наших пользователей, и как мы можем почем решить возможные проблемы.

Согласно новым правилам после 100 запросов за 6 часов с одного клиентского IP адреса каждый новый docker pull вернет ошибку 429 - too many requests, что несомненно приведет к сломанным CI/CD конвейерам, невозможности выкатить приложения и целому букету ошибок в ваших Kubernetes кластерах. Вполне понятно, что этот лимит может быть очень быстро достигнут, особенно если все задачи выполняются с одного и того же GitLab Runner агента, или если команда из нескольких инженеров работает с одного и того же публичного адреса.

Аутсорсинг Dependency Proxy

Как отметил мой коллега Tim Rizzi "Нам следует срочно всем рассказать о Dependency Proxy", который изначально создавался для проксирования и кэширования образов Docker Hub. Этот функционал существует в GitLab уже довольнейший давно (начиная с версии 11.11), но до сегодняшнего дня был доступен только для пользователей Enterprise подписки уровня Premium. Перед продуктовой командой встал вполне резонный вопрос: "Стоит ли нам вынести Dependency Proxy в open source версию продукта, помогая таким образом широкому сообществу пользователей минимизировать проблемы из-за новых ограничений Docker Hub?"

Не вдаваясь в подробности, ответ на этот вопрос был ДА. При принятии решения, в какой уровень подписки должен попадать тот или иной функционал продуктовая команда GitLab всегда руководствуется вопросом "Кто является целевым пользователем?". Согласно этому принципу те возможности, которые чаще всего запрашивает индивидуальный участник или разработчик, попадают в Core или Open Source версию продукта. Скачивание образов с Docker Hub вполне соответсвует этому описанию. Более того аутсорсинг Dependency Proxy поможет большому количеству разработчиков повысить надежность и производительность их CI/CD конвейеров.

Как результат, начиная с версии 13.6 вышедшей 22 ноября 2020 года, проксирование и кэширование образов в GitLab стало абсолютно бесплатным для всех наших пользователей!

Что дальше?

К сожалению, идеальные решения не появляются мгновенно. Мы как никто другой знаем, что нашему продукты есть куда расти, поэтому активно работаем над улучшением функционала Dependency Proxy и уже в ближайших релизах планируем добавить новые возможности / решить имеющиеся проблемы:

  • 13.7 (22 декабря, 2020)

    • gitlab-#11582 сделает возможным использование Dependency Proxy для приватных групп в GitLab (сегодня работает только для публичных проектов)

    • gitlab-#241639 позволит использовать закэшированный образ даже если Docker Hub недоступен. На сегодня это невозможно, так как даже при наличии закэшированного образа, его манифест всегда скачивается из конечного регистра

    • gitlab-#21619 добавит новый параметр pull_policy в YAML описании CI/CD задач, позволяющий разработчикам самим указывать политику скачивания контейнера (always, if-not-present, never) вместо того, чтобы полагаться на настройки GitLab Runner

    • gitlab-runner-#26558 позволит конфигурировать GitLab Runner с набором политик для скачивания образов (always, if-not-present)

Мониторинг ограничений

Решения обозначенные выше, а также в блог посте моего коллеги Steve Azzopardi, помогут упростить работу с новыми ограничениями, но не избавят от них на все 100%. Поэтому мы также выработали набор советов и инструментов, цель которых - помочь широкому сообществу адаптироваться к новым лимитам за счет их мониторинга.

Как проверить текущее значение лимита?

Документация Dockerрекомендует использовать HTTP запрос для проверки текущего значения ограничений запросов в Docker Hub.

Начнем с определения образа, для которого мы хотим получить текущее ограничение и получения токена для авторизации:

$ IMAGE="ratelimitpreview/test"$ TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:$IMAGE:pull" | jq -r .token)$ echo $TOKEN

Следующий шаг - симуляция запросаdocker pull. Вместо использования методаGETотправляемHEADзапрос (он не учитывается при подсчете ограничений). Ответ на этот запрос содержит параметрыRateLimit-Limit и RateLimit-Remaining.

$ curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/$IMAGE/manifests/latest

В примере ниже количество запросов ограничено2500, из которых2495еще доступны.21600определяет шестичасовой период (в секундах)

RateLimit-Limit: 2500;w=21600RateLimit-Remaining: 2495;w=21600

Автоматизация проверки лимитов

Michael Friedrich, один из евангелистов GitLab, поделился готовым решением на Python для проверки ограничений. Проект включает подробную документацию по установке и использованию

$ python check_docker_hub_limit.py --helpusage: check_docker_hub_limit.py [-h] [-w WARNING] [-c CRITICAL] [-v] [-t TIMEOUT]Version: 2.0.0optional arguments:  -h, --help            show this help message and exit  -w WARNING, --warning WARNING                        warning threshold for remaining  -c CRITICAL, --critical CRITICAL                        critical threshold for remaining  -v, --verbose         increase output verbosity  -t TIMEOUT, --timeout TIMEOUT                        Timeout in seconds (default 10s)

Скрипт возвращает следующие exit коды в зависимости от указанных параметров

  • 0- OK

  • 1- WARNING

  • 2- CRITICAL

$ python3 check_docker_hub_limit.pyOK - Docker Hub: Limit is 5000 remaining 4997|'limit'=5000 'remaining'=4997$ echo $?0$ python3 check_docker_hub_limit.py -w 10000 -c 3000WARNING - Docker Hub: Limit is 5000 remaining 4999|'limit'=5000 'remaining'=4999$ echo $?1$ python3 check_docker_hub_limit.py -w 10000 -c 5000CRITICAL - Docker Hub: Limit is 5000 remaining 4998|'limit'=5000 'remaining'=4998$ echo $?2

Экспортер Prometheus

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

Репозиторий проекта включает демо контейнер, включающий себе экспортер, Prometheus, Grafana, и docker-compose инструкции для его выката

$ cd example/docker-compose$ docker-compose up -d

Перейдите по адресу http://localhost:3000 для доступа к дэшборду Grafana

Надеюсь, наш опыт и рекомендации окажутся для вас полезными!

Подробнее..

Kubernetes для разработчиков трехдневный интенсив

19.11.2020 18:06:36 | Автор: admin
image

Спикеры Слёрма готовят обновленный интенсив, в котором не будет тем для администраторов. Мы убрали тему про обслуживание кластера и сосредоточились на особенностях разработки ПО в Kubernetes. В программе только то, что действительно нужно современному разработчику на проектах с K8s.

Почему трехдневный интенсив?


В Слёрме прошло уже 14 трехдневных интенсивов по Kubernetes, и мы уверены, что такой формат дает крутые результаты. К вечеру третьего дня студенты знают, что такое Kubernetes, что в нём есть и как в нём работать. Выпускник интенсива может свободно читать документацию по K8s и понимать её. Можно возвращаться и пересматривать материалы, когда понадобится. Интенсив возможность быстро запустить подготовку специалиста. Важно помнить, что такое обучение невозможно совместить с работой (учимся с 10 до 19, отвлекаться не получится).

Короткая история одного разработчика про K8s


Вот что рассказывает про обучение Артем из Gismeteo:
Я backend-разработчик в команде Gismeteo. Занимаюсь поддержкой и разработкой существующего погодного API, настройкой CI|/CD Gitlab, написанием ролей на Ansible, выкладкой на продакшн.

В компании мы в какой-то момент приняли решение избавиться от LXC-контейнеров в пользу Docker. Так как у нас highload, одним контейнером мы бы не отделались. Из этого появился вопрос: как за этим всем следить и управлять. Поэтому мы и решили присмотреться к Kubernetes, я стал искать возможности для обучения. Читал документацию, но информация, которая там есть, подходит только для ознакомления. Без практики это пустая трата времени. Пытался смотреть видео на Ютюбе, но, опять же, не хватало практики.

Тогда я решил пойти на практический курс, выбрал интенсив Слёрма. Хотел познакомиться ближе с принципами работы k8s, узнать best practices от спикеров. Интенсивное обучение мне хорошо подошло, помощь техподдержки не понадобилась. Самым интересным моментом на курсе, по-моему, было добавление rollback piplin'a для отката версии Docker-образа. Я любитель CI/CD, поэтому для меня это было особенно актуально. Также понравилась тема про интеграцию CI/CD с Kubernetes через Helm. Сложной практической темой оказалось написание своего helm chart'a.

После курса я убедился в том, что Kubernetes на текущий момент времени лучший оркестратор для контейнеров. Продолжаю повышать квалификацию в этом направлении, теперь уже на рабочих задачах. Сейчас пересматриваю материал курса, связанный с helm, так как пересобираю сейчас все наши ci/cd под диплойку через helm. Очень удобная вещь.

Ссылка на отзыв в ВК

Артем, как и многие другие разработчики, проходил Базовый интенсив по Kubernetes. Теперь есть возможность выбрать интенсив в зависимости от специализации и рабочих задач.

Kubernetes для разработчиков пройдет 35 марта 2021, но уже сейчас можно забронировать место до конца 2020 участие стоит 20 000 рублей.
Подробнее..

Эволюция процесса релиза LMS

20.11.2020 12:14:59 | Автор: admin


К чему вы стремитесь в работе? Мной всегда двигало желание быть причастным к чему-то, что действительно помогает людям решать важные задачи. Это стремление привело меня в проект онлайн-системы дистанционного обучения (Learning Management System, сокращённо LMS).

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

Что вы представляете, когда слышите об обучении в школе или университете? О чём бы вы сейчас ни подумали, скорее всего, это реализовано в LMS. Все инструменты, необходимые преподавателям для преподавания, ученикам для обучения, родителям для контроля, а директорам для администрирования учебного процесса, доступны в электронном виде. Платформой ежедневно пользуется более 7 000 000 пользователей из Европы и США, а трудится над ней распределённая команда из нескольких стран.

Особенности релиза


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

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

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

Монолитная архитектура


Проект к тому времени уже имел долгую историю разработки. Начавшись как студенческая курсовая работа, система перетекла в продолжительную фазу разработки на C++ (да, это было давно), затем шёл долгий этап развития на ASP.NET, который используется и по сей день. Многие актуальные сейчас подходы к разработке отсутствовали или только зарождались, .NET 2.0 вовсе не имел такую палитру возможностей, которая есть в современном .NET Core. То, что сейчас может видеться Франкенштейном, некоторое время назад не осознавалось как что-то ужасное. Архитектура системы была монолитна, как титановый шар, но до какого-то момента это всех устраивало.

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

Жёсткие требования


Если в России подобные системы даже на момент выхода статьи используются нечасто и почти всегда вся информация дублируется на бумаге, то в школах и университетах Европы LMS это ядро обучения. Все данные о студентах, учителях, родителях, их взаимодействии, посещаемости, успеваемости, учебные материалы, домашние работы и др. хранятся в электронном виде без двойного документооборота. Исходя из этого, к системе предъявляются крайне жёсткие требования безопасности, производительности и, что очень важно, доступности. Представьте, что ваш главный и единственный ресурс, обеспечивающий учебный процесс, вдруг сломался. Недоступность в течение 5 минут вызовет у вас дискомфорт, а часовой простой крайнюю степень возмущения. Поэтому uptime время, когда система доступна и полностью выполняет свои функции одна из ключевых метрик, которая является юридическим обязательством, за неисполнение которого предусмотрены большие штрафы. Uptime 99.9% это цифра, к которой мы стремимся.

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

Неудивительно, что с точки зрения специалистов по информационно-технологическому обслуживанию (Operations, или OPS) идеальный продакшен это продакшен без релизов, а с точки зрения пользователей продакшен с максимально частыми обновлениями. Поэтому концепция частых релизов предполагает компромисс между желаниями пользователей, разработчиков и операционистов. Пользователи должны получать обновления в приемлемый срок, OPS должны уметь быстро выкатить новую версию, а разработчики должны убедить операционистов в том, что каждый новый релиз безопасен и они не сядут в лужу.

Неоптимальные процессы


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

TL;DR


Дано: релизы раз в квартал, амбиции роста, сложный продукт с монолитной архитектурой, неоптимальные процессы, консервативность OPS.
Хотим: денег частых релизов новых фич.
Не хотим: штрафов даунтайма.

Трансформация


С осознанием глобальных проблем и чётким пониманием того, что хотелось бы иметь в итоге, компания начала постепенные изменения.

В этой статье я остановлюсь на изменениях в разработке и непосредственном процессе релиза, но стоит отметить, что немало изменений произошло и в работе OPS.

Устранение инфраструктурных проблем


Для начала нужно было устранить некоторые инфраструктурные проблемы.

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

Во-вторых, само развёртывание проекта состояло из неопределённого набора неунифицированных скриптов PowerShell, которые были написаны разными людьми для разных целей, содержали комментарии на разных языках и не всегда были понятны простому смертному. И хотя они худо-бедно выполняли свою функцию, при росте количества компонентов оперировать ими становилось всё тяжелее. Так у нас появилась своя собственная утилита для деплоймента. Она заточена под собственные нужды автоматизирует последовательность выполнения шагов и развёртывание каждого отдельного компонента системы, ведёт логи процесса. При добавлении нового компонента разработчики и OPS всегда обсуждают, как новое приложение будет разворачиваться на продакшен серверах, включая требования к инфраструктуре и процедуру развёртывания. Сам скрипт развёртывания пишут разработчики, он хранится вместе с исходным кодом компонента. Последовательность развёртывания универсальна для всех серверов, но переменные среды конфигурируются в зависимости от окружения. Новая утилита стала использоваться и на тестовых серверах, и в продакшене, что позволило находить проблемы развёртывания ещё на этапе тестирования.

Несмотря на то, что решения обеих проблем описаны достаточно коротко, они потребовали достаточного количества усилий, координации и времени.

Формализация и сокращение таймлайна


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

Мы начали с робких попыток ежемесячных релизов, затем постепенно дошли до релизов раз в 2 недели. Короткие циклы благотворно сказались на качестве. Меньше кода меньше рисков, больше вероятность заранее выявить все потенциальные проблемы.

С двухнедельными циклами мы прожили несколько лет, но всё же остановились на релизах раз в месяц. Так получилось потому, что процесс всё ещё требовал большого количества ручной работы (тестирование, стейджинг и т.п.). К тому же важным фактором стала усталость тестировщиков: в проекте их не так много, а релизные задачи часто отвлекали их от основной работы в команде. Ежемесячные релизы стали золотой серединой мы остались достаточно быстрыми в доставке обновлений, релизы всё ещё остались относительно небольшими, но при этом командам разработки стало работать комфортнее.

Как устроен релизный цикл
При обновлениях каждые две недели релизная итерация занимала почти 5 недель. Как же так?

Разберём один двухнедельный релиз методом обратного планирования. Мы знаем дату релиза и сколько занимают стабилизационное тестирование и стейджинг релиз-кандидата (2 недели), тогда к началу стабилизации в релиз должны быть включены все новые фичи (code freeze). Всё, что не было включено вовремя (кроме редких заранее оговорённых случаев), переходит на следующий релиз. Чтобы включить новую разработку в релиз, нужно полностью протестировать её функциональность, включая переводы, и убедиться в отсутствии багов. Локализацию выполняет сторонняя компания, и ей требуется около недели, чтобы перевести новые строки. Поэтому за 2 недели до начала тестирования релиз-кандидата мы отправляем на перевод новые строки. После получения переводов у команд есть примерно неделя, чтобы закончить тестирование и попасть в релиз. Непосредственно после релиза идёт неделя мониторинга новых проблем на продакшене. За это время нужно убедиться, что релиз не привнёс никаких новых проблем, а если проблемы появились решить, требуется ли их устранить до следующего релиза.



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

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

Новая стратегия создания веток


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

Схема, к которой мы в итоге пришли, была придумана не нами, но идеально подошла под наши нужды и выглядит так:



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

Изменение подхода к тестированию релиз-кандидата


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

Раньше в порядке вещей было найти десяток багов в новой функциональности во время регрессии и исправлять их (или откатывать), тем самым сдвигая срок релиза. Согласно новому definition of done, только функциональность, которая полностью выверена и не содержит багов, может быть отправлена в develop. Исходя из этого, мы оставили лишь беглый просмотр новой функциональности в релиз-кандидате на предмет интеграционных проблем.

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

Изменения в архитектуре


Монолитную систему релизить долго, сложно и рискованно. Переход к частым релизам форсировал декомпозицию на мелкие компоненты, которые можно деплоить отдельно (single deployable). Ввиду размеров проекта этот процесс до сих пор не завершён, но шаг за шагом мы вычленяем новые компоненты, релиз которых может происходить отдельно от релиза главного приложения. Новые компоненты сразу разрабатываются обособленно.

TL;DR


Разработка: перешли с TFS на Git, разработали собственное решение для деплоймента, ввели новую схему создания веток в разработке, пересмотрели и улучшили архитектуру.
Тестирование: убрали ручную регрессию, частично заменив её автоматическими тестами, оставили стабилизацию новой функциональности.
Процессы: описали таймлайн со всеми итерациями релизного процесса, ввели концепцию релизных поездов и добавили пилотирование новых фич на небольшом количестве пользователей.

Релиз-менеджмент: из креатива в рутину


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

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

Во-первых, принимая в расчёт время подготовки релиза и высокий уровень ответственности, эта работа была достаточно тяжёлой, и никто не горел желанием браться за неё часто. Нужно было расширить список потенциальных кандидатов, но это приводило ко второй проблеме: несмотря на то, что за плечами было достаточное количество релизов, каждый новый релиз был не похож на предыдущий. Никто не мог до конца понять, что входит в перечень обязанностей менеджера, а что нет. Самой главной задачей нового релиз-менеджера было выяснить, что вообще делает релиз-менеджер. В самом начале это было совсем непросто, но постепенно мы очертили круг основных задач и ответственности менеджера релиза. Процесс стал хорошо задокументированным: были описаны связи между компонентами, последовательность развёртывания, таймлайн релиза и многое другое. Когда менеджмент из креативной задачи, которую каждый решает по-своему, превращается в подробный алгоритм действий, задачу можно без особого риска поручить любому достаточно опытному человеку. Чем подробнее описан сложный процесс, тем проще найти ответ в случае необходимости. В данном случае бюрократизация процесса оказалась очень оправданной!

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

Обязанности менеджера релиза
Вот неполный перечень того, что делает менеджер релиза:

  • отправляет новые строки на переводы и добавляет готовые переводы;
  • организует встречу с представителями команд, участвующих в релизе, где подробно расспрашивает об изменениях, рисках, зависимостях и т. д.;
  • создаёт релизную ветку, разворачивает её на тестовых серверах и следит за работоспособностью тестового окружения;
  • мониторит логи во время стабилизации, раздаёт найденные баги;
  • находится в тесной связи с QA-координатором, который контролирует стабилизационное тестирование, отвечает на его вопросы, помогает найти ответственную команду при нахождении багов;
  • контролирует сроки; при невозможности вписаться с таймлайн обсуждает это с владельцами продукта, менеджментом и другими заинтересованными лицами;
  • просматривает все изменения в коде после исправления багов;
  • отдаёт релиз на стейджинг и отвечает на вопросы OPS;
  • в день релиза и последующую неделю мониторит логи;
  • при необходимости координирует патчи и хотфиксы, которые являются упрощёнными релизами;
  • участвует в ретроспективе релиза.


Что НЕ входит в задачи менеджера релиза:

  • развёртывание обновления в продакшене для этого есть OPS;
  • исправление найденных багов за это ответственны команды.


TL;DR


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

Так ли всё идеально?


Если у вас сложилось впечатление, что в проекте теперь всё идеально, то спешу вас уверить, что идеала не существует (что не мешает нам к нему стремиться).

Как и в других проектах, мы часто балансируем между созданием новых фич и техническими улучшениями, которые не добавляют прямой ценности с точки зрения конечных пользователей. Поэтому автоматизация регрессии не закончена на 100%, иногда в релиз-кандидате проскакивают баги, и приходится быстро принимать решение о дальнейших действиях. Иногда релизы отменяются или переносятся по разным причинам, начиная с долгих праздничных дней в начале года и мае и заканчивая поздно найденными критическими багами или форс-мажорами. А ещё случаются активности OPS обновления серверов, миграции данных, установка новой инфраструктуры, на время которых релизы останавливаются.

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

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



От маленьких, быстро тестируемых и малорискованных релизов произошёл откат в сторону долгой стабилизации (и как следствие, более долгой итерации), а также большего количества багов в релиз-кандидате, что было очень непривычно.
Стоит отметить, что даже при таком положении дел релизы оказались менее трудозатратны и рискованны, чем раньше.

Дальнейшее развитие


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

Вектор дальнейшего улучшения релиза предопределён:

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


Выводы


В разработке сложного веб-приложения релиз новой версии занимает особое место. За несколько лет мы сумели перейти с ежеквартальных релизов к релизам раз в 2 недели, но впоследствии остановились на ежемесячных. Это оказалось непросто и увлекательно, трансформация потребовала комплексных изменений, которые коснулись разработчиков, тестировщиков, OPS и менеджмента. Релизы новой версии стали менее объёмными, менее рискованными и более прозрачными с точки зрения сроков закончилась эпоха, когда релизы были СОБТИЕМ. К сожалению, традиция есть мороженое по случаю релиза тоже закончилась. ;(
Подробнее..

От кровавого энтерпрайза к командной работе

12.11.2020 14:14:33 | Автор: admin

.model tiny
.code
org 100h
start: mov ah,9
mov dx, offset message
int 21h
ret
message: db "Hello Habr!", 00h, 0Ah, '$'
end start

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

Большинство систем мы пишем сами, но в то же время мы иногда используем и коммерческий софт. В целом можно сказать, что мы стараемся работать модно-молодежно: у нас есть автоматизация на Ansible (именно автоматизация, а не деплой), у нас есть CI/CD на Bamboo + Bitbucket. Есть оркестрация на Mesos, от него мы постепенно переходим к Kubernetes.

Есть и заявки - это не только взаимодействие с другими отделами, но и взаимодействие разработки-эксплуатации. Поэтому мы смотрим в сторону GitOps.

Наши проблемы

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

Из предыдущего вытекает еще одна проблема это подход У меня локально все работает, если у коллег в деве/проде не запустилось это их проблемы, пускай сами разбираются. Подобная проблема есть, наверное, практически у всех. Как мы стараемся ее решать: по максимуму переносить окружения на единую платформу, в нашем случае Kubernetes с динамическими окружениями.

Но только применением инструментов здесь дело не решить, необходимо проводить большую социальную работу. То есть сделать так, чтобы команды в целом понимали, что, если все работает локально это не готово. Готово это когда работает в общем окружении.

Еще одна вечная проблема - разность в окружениях. Да, можно сказать, что это наследство, но не стоит недооценивать и наши заслуги желание что-то быстро запустить. Такие моменты нельзя решить чисто технологическим путем, надо перестраивать процессы и восприятие. Культивировать понимание, что сделанное наспех и с костылями обязательно необходимо в будущем отрефакторить.

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

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

И напоследок: взаимодействие со смежниками и инфраструктурой. Чтобы что-то решить, нужно заводить заявку. И если нет заявки, то нет и работы. На этом моменте много чего рушится. История с заявками в целом штука очень тяжелая, от нее сложно уйти, и полностью она не исчезнет, как бы мы ни старались с GitOps и владением инфраструктурным кодом продуктовыми командами.

DevOps ожидание vs. реальность

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

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

Как же мы видим DevOps? Для нас это и командная работа с подключением инженера эксплуатации (админа), и процесс, и методология, и философия. И главное здесь донести все до людей. Договориться, объяснить, проговорить что изменится и что нет, и только потом подключать инженера. Просто прийти и сказать: Вы теперь работаете по DevOps - этого мало. Инженер к команде не просто подключается, приходит и решает все задачи. Если работать по этому сценарию, инженер просто выгорит, а у нас все останется, как было (в лучшем случае). Все вопросы должны решаться совместно.

Помимо просто теории, процессов, необходимо понимать, что вообще происходит. То есть вводить метрики. Стандартные это время выкаток и их количество. Есть мнение, что чем их больше, тем лучше, но я с ним не согласен. Не нужно забывать про качество. Согласитесь, что выкатить что-то, а потом откатиться, или выкатить, а затем выдать фикс это не одно и то же. Я считаю, что выкатка должна быть наиболее стабильной и качественной, но этого не всегда можно добиться. И это нормально. Не все дается с первого раза, второго

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

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

Инструменты и социальность

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

Вы не можете просто поставить Kubernetes и сказать всем ура, у нас Kubernetes, работаем. Это не просто софт, это платформа, вопрос экосистемы, деплоев. Kubernetes добавляет много вопросов, на которые не всегда можно быстро ответить.

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

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

Автоматизация. Идеальный способ что-то испортить в процессе работы - это абсолютно бездумно что-то применять в работе и, более того, навязывать это остальным. С автоматизацией главное не перестараться, надо понимать, что и зачем, когда и для чего. Например, деплой при помощи Ansible чаще всего не очень хорошее решение

Гибкость. Нужна во всем, DevOps не может быть гибким только с одной стороны. Если так работают только инженеры/команды, а бухгалтерия не может, то получится, что команды будут ждать новых серверов долгое время. И таких историй множество.

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

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

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

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

Выводы

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

DevOps - это работа, большая работа. Нужно смотреть на методологии, подходы, выбирать то, что применимо именно к вашей ситуации, а не просто взять что-то и пытаться использовать. Да, это, скорее всего, будет дорого, но в перспективе это даст плюсы. Мы понимаем, что командам помогает такая трансформация, да и бизнесу тоже. DevOps не всегда нужен, и, занявшись его внедрением, можно сделать хуже. Это обычно заметно, если команда маленькая или не готова. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.

Подробнее..

Перевод Пять рекомендаций по экспортерам Prometheus для повышения производительности

12.11.2020 18:15:59 | Автор: admin

В преддверии старта кура "DevOps практики и инструменты" приглашаем вас записаться на бесплатный демо-урок по теме: "Алиса в мире облаков: приключения с Terraform и Ansible".

А прямо сейчас традиционно делимся полезным переводом.


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

Prometheus одна из базовых составляющих cloud-native-архитектуры. Он уже стал стандартом де-факто для мониторинга Kubernetes. Однако многие сторонние и облачные приложения изначально не предоставляют метрик в формате Prometheus. Например, Linux не предоставляет таких метрик. Для этого и предназначены экспортеры, такие как node exporter. Его легко скачать, запустить и получить сотни метрик для операционной системы.

Secure DevOps, также известный как DevSecOps, обеспечивает безопасность и мониторинг на протяжении всего жизненного цикла приложения: от разработки до продакшена. Что позволяет создавать безопасные, стабильные и высокопроизводительные приложения. Этот подход встраивается в ваш процесс разработки и предоставляет единый источник правды для DevOps-команд, разработчиков и служб безопасности, чтобы максимально повысить эффективность и обеспечить прозрачность при устранении неисправностей и оптимизации.

В этой статье мы рассмотрим несколько рекомендаций по мониторингу приложений и облачных сервисов с помощью экспортеров Prometheus.

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

Трудозатраты на обслуживание большого количества экспортеров Prometheus часто недооцениваются и бывают больше, чем вы себе представляете. Иногда все эти экспортеры и конфигурации могут показаться Диком Западом. Думая наперед и вооружившись практическими рекомендациями, вы сможете облегчить себе жизнь и тратить меньше времени на поддержку экспортеров, уделяя больше внимания действительно важным вещам для вашей организации.

1. Найдите подходящий экспортер

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

Один из способов решить эту проблему самому оценить насколько тот или иной экспортер-кандидат удовлетворяет вашим требованиям, предоставляет интересующие вас метрики и насколько он зрелый как программный продукт. Например, если экспортер был разработан много лет назад одним человеком, у него нет свежих обновлений и у него небольшое количество PR / issue / звезд на Github, то, скорее всего, он не используется и не поддерживается.

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

Вашей первой остановкой должна стать страница Exporters and Integrations на сайте Prometheus. Если ваше приложение или протокол, который оно использует для представления метрик, присутствуют там, то это тот экспортер, который, скорее всего, будет лучшим выбором.

Существуют также сторонние каталоги экспортеров, такие как PromCat.io, поддерживаемый Sysdig, или страница портов по умолчанию, которая непреднамеренно оказалась довольно полным списком экспортеров.

PromCat поможет вам сэкономить время, необходимое для выбора и тестирования экспортеров, дашбордов и алертов. В Sysdig есть команда инженеров, которая поддерживает этот сайт и постоянно проверяет работоспособность его содержимого. Смотрите также:

2. Изучите метрики экспортера

У каждого экспортера есть свой набор метрик. Обычно их описание есть на странице проекта экспортера, хотя иногда приходится заглядывать в справку или документацию. Если экспортер использует формат OpenMetrics, то он может добавлять к метрике поля с дополнительной информацией, такой как type, info, unit.

Еще один момент, на который стоит обратить внимание в документации экспортера, это использование меток (label).

Метки обеспечивают контекст: "Это продакшн-сервис или окружение разработки?", "На каком хосте запущен сервис?", "К какому приложению относится этот сервис?". Например, у команды бэкенда и у команды аналитиков могут быть отдельные инстансы MySQL. Позже вы захотите отфильтровать их метрики, разделить по приложению, окружению (продакшн или разработка) или по региону.

Помимо использования меток для анализа происходящего внутри приложения, они полезны при агрегировании метрик по всем развернутым системам. Правильное использование меток позволяет ответить на такие вопросы, как "Сколько всего процессоров в настоящее время используют все приложения по всему миру?" или "Какое общее использование оперативной памяти всеми приложениями, принадлежащими команде фронтенда в Европе?". Вы можете посмотреть примеры использования меток в этом вебинаре.

3. Настройте действительно полезные алерты

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

Первым шагом в определении любой стратегии алертов является изучение ваших приложений и Prometheus-экспортеров. Следуя рекомендациям DevOps по показателям (Service Level Indicators) и целевым уровням обслуживания (Service Level Objectives) наряду с "золотыми сигналами" мониторинга (golden signals) вы можете определить критические элементы, требующие алертов. Хороший инструмент мониторинга с глубокой видимостью и контекстом Kubernetes поможет найти эти критические факторы.

Работа с инструментами, нативно использующими для алертов PromQL, может сэкономить ваше время, поскольку не нужно переводить их в другой формат, что чревато появлением ошибок. Например, promtool поможет в тестировании конфигураций алертов PromQL (и не только в этом).

Но инструмент для алертов должен иметь больше функций, чем простая обработка PromQL. Помимо настройки алертов для любой метрики или события, также должна быть возможность отправлять алерты на электронную почту, Slack, Pagerduty, Service Now и т.д.

4. Предоставьте данные вашей команде (или нет)

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

Наиболее распространенный способ взаимодействия с метриками визуализация на дашбордах. Для помощи в их создании PromCat.io предоставляет шаблоны, готовые к импорту в Grafana или Sysdig Monitor.

Но как ваша команда организует дашборды? Лучшая практика заключается в том, что вместо создания своих индивидуальных дашбордов каждым членом команды, создается единый дашборд, который используется всей DevOps-командой. Члены команды могут использовать его в качестве примера и вносить только незначительные изменения в случае необходимости. Чтобы все работало, инструмент мониторинга также должен предоставлять возможность разграничения прав доступа к дашбордам (View Only или Collaborator с правами редактирования).

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

PromQL это мощный язык запросов метрик, собираемых экспортерами Prometheus. С помощью PromQL вы можете выполнять сложные математические операции, статистический анализ и использовать различные функции.

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

5. Составьте план по масштабированию

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

Давайте посмотрим на некоторые проблемы масштабирования Prometheus и способы их решения.

Глобальная видимость Prometheus (Global Prometheus Visibility): по мере роста вам потребуется видеть данные одновременно по нескольким кластерам.

Горизонтальное масштабирование: по мере роста вашего окружения увеличивается количество сервисов в Kubernetes, количество метрик и использование памяти Prometheus'ом. По своей архитектуре Prometheus по горизонтали не масштабируется. И когда вы достигнете предела вертикального масштабирования, то все.

Долгосрочное хранение: Prometheus может отслеживать миллионы измерений в реальном времени. Однако чем дольше вы храните данные, тем больше ресурсов вы тратите. Можно уменьшить срок хранения метрик, но тогда вы не сможете анализировать данные за недели, месяцы или годы.

Чтобы справиться с проблемами масштабирования, вы можете попробовать консолидировать Grafana, развернуть Thanos, Cortex или использовать коммерческое решение, такое как Sysdig. Некоторые проблемы, связанные с масштабированием, позволяет решить SaaS-решение, поскольку SaaS-поставщику проще приспособиться к росту, чем вам. Потенциальные проблемы, связанные с этими решениями по масштабированию, подробно рассмотрены в статье Challenges using Prometheus at scale. (Проблемы с масштабированием Prometheus).

Заключение

Prometheus, как одна из базовых составляющих cloud-native-архитектуры, стал де-факто стандартом мониторинга для Kubernetes. Для мониторинга приложений и облачных сервисов вам понадобятся экспортеры. Важно помнить, что не все экспортеры одинаково хороши, и решения для мониторинга могут быть не готовы к масштабированию. Я надеюсь, эти советы помогут вам преуспеть в мониторинге благодаря использованию проверенных проектов, понимания ваших метрик и заблаговременного планирования роста.

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

Вы можете увидеть процесс мониторинга приложений и облачных сервисов в действии, на нашем вебинаре So Many Metrics, So Little Time: 5 Prometheus Exporter Best Practices ("Так много метрик и так мало времени: пять рекомендация по экспортерам Prometheus").


Записаться на бесплатный демо-урок.

Подробнее..

Обзор операторов PostgreSQL для Kubernetes. Часть 2 дополнения и итоговое сравнение

13.11.2020 10:21:32 | Автор: admin


На прошлую статью, где мы рассмотрели три оператора PostgreSQL для Kubernetes (Stolon, Crunchy Data и Zalando), поделились своим выбором и опытом эксплуатации, поступила отличная обратная связь от сообщества*.

Продолжая эту тему, мы добавили в обзор два других решения, на которые нам указали в комментариях: StackGres и KubeDB, и сделали сводную таблицу сравнения. Также за время эксплуатации оператора от Zalando у нас появились новые интересные кейсы спешим поделиться и ими.

* Первую часть статьи заметили даже разработчики Zalando, благодаря чему(?) они решили активизироваться в приёме некоторых PR. Это не может не радовать!



Итак, сначала дополним обзор ещё двумя решениями

KubeDB




Оператор KubeDB разрабатывается командой AppsCode c 2017 года и хорошо известен в Kubernetes-сообществе. Он претендует на звание платформы для запуска различных stateful-сервисов в Kubernetes и поддерживает:

  • PostgreSQL;
  • Elasticsearch;
  • MySQL;
  • MongoDB;
  • Redis;
  • Memcache.

Однако в контексте статьи мы рассмотрим только PostgreSQL.

В KubeDB реализован интересный подход с использованием нескольких CRD, которые содержат в себе различные настройки, такие как:

  • версия с образом базы и вспомогательными утилитами за это отвечает ресурс postgresversions.catalog.kubedb.com;
  • параметры восстановления ресурс бэкапа <codesnapshots.kubedb.com

собственно, корневой ресурс postgreses.kubedb.com, который собирает в себе все эти ресурсы и запускает кластер PostgreSQL.

Особой кастомизации KubeDB не предоставляет (в отличие от оператора Zalando), но вы всегда можете управлять конфигом PostgreSQL через ConfigMap.

Интересной особенностью является ресурс dormantdatabases.kubedb.com, который предоставляет защиту от дурака: все удалённые базы сначала переводятся в такое архивное состояние и могут быть легко восстановлены в случае необходимости. Жизненный цикл БД в KubeDB описывается следующей схемой:



Что же касается самого технологического стека, то тут используются свои наработки для управления кластерами, а не знакомые всем Patroni или Repmgr. Хотя для полинга соединений используется pgBouncer, который также создается отдельным CRD (pgbouncers.kubedb.com). Кроме того, разработчики предоставляют плагин для kubectl, который позволяет удобно управлять базами через всем привычную утилиту, и это огромный плюс на фоне Stolon или Crunchy Data.

KubeDB интегрируется с другими решениями AppsCode, чем напоминает Crunchy Data. Если вы везде используете решения этого вендора, то KubeDB, безусловно, отличный выбор.

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

Есть минусы у KubeDB. Многие возможности: бэкапы, полинг соединений, снапшоты, dormant-базы доступны только в enterprise-версии, а для её использования требуется купить подписку у AppsCode. Кроме того, самой старшей поддерживаемой версией PostgreSQL из коробки является 11.x. Перечеркивают ли эти моменты изящную архитектуру KubeDB решать вам.

StackGres




В твиттере и в комментариях к предыдущей статье нам резонно указали на оператор StackGres. Разработка данного оператора началась совсем недавно, в мае 2019 году. В нем используются известные и проверенные технологии: Patroni, PgBouncer, WAL-G и Envoy.

Общая схема оператора выглядит так:



Кроме того, в комплекте с оператором можно установить:

  • веб-панель, как в Zalando;
  • систему сбора логов;
  • систему мониторинга, аналогичную Crunchy Data, о которой мы говорили в первой части;
  • систему сбора бэкапов на основе MinIO, хотя можно подключить и внешнее хранилище.

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

Вкратце про все CRD:

  • sgbackupconfigs.stackgres.io, sgpgconfigs.stackgres.io, sgpoolconfigs.stackgres.io описание кастомных конфигов;
  • sginstanceprofiles.stackgres.io размер инстанса Postgres, который будет использоваться как limit/request для контейнера с PostgreSQL/Patroni. Для остальных контейнеров лимитов нет;
  • sgclusters.stackgres.io когда есть конфигурации для базы, пула коннектов и бэкапа, можно создать кластер PostgreSQL, который описывается этим CRD;
  • sgbackups.stackgres.io ресурс, схожий со snapshot у KubeDB и позволяющий обратиться к конкретному бэкапу из кластера K8s.

Однако оператор не позволяет использовать свои кастомные сборки образов или же несколько вспомогательных sidecar для сервера баз данных. Pod c Postgres содержит 5 контейнеров:



Из них мы можем отключить экспортер метрик, пулер коннектов и контейнер со вспомогательными утилитами администратора (psql, pg_dump и так далее). Да, оператор позволяет при инициализации кластера баз данных подключить скрипты с SQL-кодом для инициализации БД или создания пользователей, но не более того. Это сильно ограничивает нас в кастомизации, например, в сравнении с тем же оператором Zalando, где можно добавлять нужные sidecar с Envoy, PgBouncer и любыми другими вспомогательными контейнерами (хороший пример подобной связки будет ниже).

Подводя итог, можно сказать, что этот оператор понравится тем, кто хочет просто управлять PostgreSQL в кластере Kubernetes. Отличный выбор для тех, кому нужен инструмент с простой документацией, покрывающей все аспекты работы оператора, и кому не нужно делать сложные связки контейнеров и баз.

Итоговое сравнение


Мы знаем, что наши коллеги нежно любят сводные таблицы, поэтому приводим подобную для Postgres-операторов в Kubernetes.

Забегая вперед: после рассмотрения двух дополнительных кандидатов мы остаёмся при мнении, что решение от Zalando оптимальный для нашего случая продукт, так как позволяет реализовывать очень гибкие решения, имеет большой простор для кастомизации.

В таблице первая часть посвящена сравнению основных возможностей работы с БД, а вторая более специфичным особенностям, следуя нашему пониманию об удобстве работы с оператором в Kubernetes.

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

Stolon Crunchy Data Zalando KubeDB StackGres
Текущая версия 0.16.0 4.5.0 1.5.0 0.13 0.9.2
Версии PostgreSQL 9.49.6, 10, 11, 12 9.5, 9.6, 10, 11, 12 9.6, 10, 11, 12 9.6, 10, 11 11, 12
Общие возможности
Кластеры PgSQL
Теплый и горячий резерв
Синхронная репликация
Потоковая репликация
Автоматический failover
Непрерывное архивирование
Инициализация: из WAL-архива
Бэкапы: мгновенные, по расписанию
Бэкапы: управляемость из кластера
Инициализация: из снапшота, со скриптами
Специализированные возможности
Встроенная поддержка Prometheus
Кастомная конфигурация
Кастомный Docker-образ
Внешние CLI-утилиты
(kubectl-плагин)
Конфигурация через CRD
Кастомизация Pod'ов
NodeSelector и NodeAffinity
(через патчи)
Tolerations
Pod anti-affinity

Бонусы про оператор от Zalando


Ежедневно пользуясь решением от Zalando, мы столкнулись с некоторыми сложностями, и этим опытом хотелось бы поделиться с сообществом.

1. Приватные репозитории


Недавно нам потребовалось запустить через оператор наряду с PostgreSQL контейнер с SFTP, который позволил бы получать выгрузки из базы в формате CSV. Сам SFTP-сервер со всеми нужными параметрами был собран в закрытом registry.

И тут стало ясно, что оператор не умеет работать с registry secrets. К счастью, с такой проблемой мы были не одни с такой проблемой: все легко решилось коллегами на GitHub. Оказалось, что достаточно добавить в описание ServiceAccount имя с доступами в registry:

pod_service_account_definition: '{ "apiVersion": "v1", "kind": "ServiceAccount", "metadata": { "name": "zalando-postgres-operator" }, "imagePullSecrets": [ { "name": "my-fine-secret" } ] }'

2. Дополнительные хранилища и init-контейнеры


Для работы SFTP нам также требовалось корректно выставлять права на директории, чтобы заработал chroot. Возможно, не все знают, но OpenSSH-сервер требует особых привилегий на директории. Например, чтобы пользователь видел только свой /home/user, необходимо, чтобы /home принадлежал root с правами 755, а уже /home/user был доступен пользователю. Соответственно, мы решили использовать init-контейнер, который исправлял бы права на директории.

Но оператор не умеет пробрасывать дополнительные диски в init-контейнеры! Благо, есть подходящий PR, которым мы и дополнили свою сборку оператора.

3. Перезапуск PgSQL при проблемах с control plane


В процессе эксплуатации кластеров на основе Patroni в Kubernetes мы получили от клиента странную проблему: ровно в 4 часа ночи по Москве обрывались все подключения PostgeSQL. Разбираясь в ситуации, мы обнаружили следующее в логах Spilo:

2020-10-21 01:01:10,538 INFO: Lock owner: production-db-0; I am production-db-02020-10-21 01:01:14,759 ERROR: failed to update leader lock2020-10-21 01:01:15,236 INFO: demoted self because failed to update leader lock in DCS2020-10-21 01:01:15,238 INFO: closed patroni connection to the postgresql cluster2020-10-21 01:01:15 UTC [578292]: [1-1] 5f8f885b.8d2f4 0     LOG:  Auto detecting pg_stat_kcache.linux_hz parameter...

Согласно issue на GitHub, это означает, что Patoni не смог обработать ошибку Kubernetes API и упал с ошибкой. А проблемы с API были связаны с тем, что в 4 часа стартовали сразу 50 CronJob, что приводило к проблемам в etcd:

2020-10-21 01:01:14.589198 W | etcdserver: read-only range request "key:\"/registry/deployments/staging/db-worker-db1\" " with result "range_response_count:1 size:2598" took too long (3.688609392s) to execute

Ситуация исправлена в версии Patroni 2.0. По этой причине мы собрали версию Spilo из мастера. При сборке стоит учитывать, что требуется взять PR с исправлениями сборки, который на данный момент уже принят в мастер.

4. Пересоздание контейнеров


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

time="2020-10-28T20:58:25Z" level=debug msg="spec diff between old and new statefulsets: \nTemplate.Spec.Volumes[2].VolumeSource.ConfigMap.DefaultMode: &int32(420) != nil\nTemplate.Spec.Volumes[3].VolumeSource.ConfigMap.DefaultMode: &int32(420) != nil\nTemplate.Spec.Containers[0].TerminationMessagePath: \"/dev/termination-log\" != \"\"\nTemplate.Spec.Containers[0].TerminationMessagePolicy: \"File\" != \"\"\nTemplate.Spec.Containers[1].Ports[0].Protocol: \"TCP\" != \"\"\nTemplate.Spec.Containers[1].TerminationMessagePath: \"/dev/termination-log\" != \"\"\nTemplate.Spec.Containers[1].TerminationMessagePolicy: \"File\" != \"\"\nTemplate.Spec.RestartPolicy: \"Always\" != \"\"\nTemplate.Spec.DNSPolicy: \"ClusterFirst\" != \"\"\nTemplate.Spec.DeprecatedServiceAccount: \"postgres-pod\" != \"\"\nTemplate.Spec.SchedulerName: \"default-scheduler\" != \"\"\nVolumeClaimTemplates[0].Status.Phase: \"Pending\" != \"\"\nRevisionHistoryLimit: &int32(10) != nil\n" cluster-name=test/test-psql pkg=cluster worker=0

Ни для кого не секрет, что при создании контейнера и podа добавляются директивы, которые не обязательно описывать. К ним относятся:

  • DNSPolicy;
  • SchedulerName;
  • RestartPolicy;
  • TerminationMessagePolicy;

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

    ports:    - name: sftp      containerPort: 22

При создании podа автоматически добавляется протокол TCP, что не учитывается оператором. Итог: чтобы решить проблему, надо или удалить порты, или добавить протокол.

Заключение


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

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

Говоря же об операторах, рассмотренных в этой части статьи (KubeDB и StackGres), стоит отметить, что они оснащены уникальными функциями для управления бэкапами из кластера, что может стать одним из факторов роста их популярности в ближайшем будущем.

P.S.


Читайте также в нашем блоге:

Подробнее..

Перевод Как в Smarkets улучшили мониторинг для своих Kubernetes-кластеров

17.11.2020 10:12:56 | Автор: admin
Прим. перев.: автор этой статьи ведущий инженер по инфраструктуре в Smarkets, что позиционирует себя как одну из самых прибыльных [по доходам на каждого сотрудника] компаний в Европе. Работая с большой и чувствительной к мониторингу инфраструктурой на базе Kubernetes, инженеры компании нашли своё счастье с VictoriaMetrics, которая помогла им решить проблемы с Prometheus, возникшие после добавления новых K8s-кластеров.

Мониторинг внутренних endpoint'ов и API Kubernetes может быть проблематичным, особенно если стоит задача использовать автоматизированную инфраструктуру как сервис. Мы в Smarkets еще не достигли этой цели, но, к счастью, уже довольно близки к ней. Я надеюсь, что наш опыт в этой области поможет и другим реализовать нечто подобное.

Мы всегда мечтали о том, чтобы разработчики прямо из коробки получали возможность мониторинга для любого приложения или сервиса. До перехода на Kubernetes эта задача выполнялась либо с помощью метрик Prometheus, либо с помощью statsd, который пересылал статистику на базовый хост, где она конвертировалась в метрики Prometheus. Наращивая применение Kubernetes, мы начали разделять кластеры, и нам захотелось сделать так, чтобы разработчики могли экспортировать метрики напрямую в Prometheus через аннотации к сервисам. Увы, эти метрики были доступны только внутри кластера, то есть их нельзя было собирать глобально.

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

Отправная точка


Для метрик, связанных с Kubernetes, мы используем два сервиса, предоставляющих метрики:

  • kube-state-metrics генерирует метрики для объектов Kubernetes на основе информации от API-серверов K8s;
  • kube-eagle экспортирует метрики Prometheus для podов: их request'ы, limit'ы, использование.

Можно (и в течение некоторого времени мы делали это) выставлять сервисы с метриками за пределы кластера или открывать прокси-подключение к API, однако оба варианты не были идеальны, поскольку замедляли работу и не обеспечивали должную независимость и безопасность систем.

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



Проблемы


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

При анализе 2-часового блока Prometheus:

  • 1,3 млн метрик;
  • 383 имени лейблов;
  • максимальная кардинальность на метрику 662 000 (больше всего проблем именно из-за этого).

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

В спокойное время собиралось около 40 000 метрик в секунду, однако их число могло вырастать до 180 000 в отсутствии каких-либо проблем.

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

Другая проблема состояла в том, что в условиях, когда на каждом экземпляре Prometheus хранились данные за три месяца, время запуска (WAL replay) оказывалось очень высоким, и это обычно приводило к тому, что тот же самый запрос направлялся на второй экземпляр Prometheus и ронял уже его.

Чтобы устранить эти проблемы, мы внедрили Thanos и Trickster:

  • Thanos позволил хранить меньше данных в Prometheus и сократил число инцидентов, вызванных чрезмерным использованием памяти. Рядом с контейнером Prometheus Thanos запускает sidecar-контейнер, который складирует блоки данных в S3, где их затем сжимает thanos-compact. Таким образом, с помощью Thanos'а было реализовано долгосрочное хранение данных за пределами Prometheus.
  • Trickster, со своей стороны, выступил обратным прокси и кэшем для баз данных временных рядов. Он позволил нам закэшировать до 99,53% всех запросов. Большинство запросов поступает от панелей мониторинга, запущенных на рабочих станциях/ТВ, от пользователей с открытыми контрольными панелями и от алертов. Прокси, способный выдавать только дельту во временных рядах, отлично подходит для подобной нагрузки.



У нас также начали возникать проблемы при сборе kube-state-metrics из-за пределов кластера. Как вы помните, частенько приходилось обрабатывать до 180 000 метрик в секунду, а сбор тормозил уже при выставлении 40 000 метрик в единственном ingressе kube-state-metrics. У нас установлен целевой 10-секундный интервал для сбора метрик, а в периоды высокой нагрузки этот SLA часто нарушался удаленным сбором kube-state-metrics или kube-eagle.

Варианты


Размышляя над тем, как улучшить архитектуру, мы рассмотрели три различных варианта:

  1. Prometheus + Cortex (https://github.com/cortexproject/cortex);
  2. Prometheus + Thanos Receive (https://thanos.io);
  3. Prometheus + VictoriaMetrics (https://github.com/VictoriaMetrics/VictoriaMetrics).

Подробную информацию о них и сравнение характеристик можно найти в интернете. В нашем конкретном случае (и после тестов на данных с высокой кардинальностью) явным победителем оказалась VictoriaMetrics.

Решение


Prometheus


Пытаясь улучшить описанную выше архитектуру, мы решили изолировать каждый кластер Kubernetes как отдельную сущность и сделать Prometheus его частью. Теперь любой новый кластер идет со включенным из коробки мониторингом и метриками, доступными в глобальных dashboard'ах (Grafana). Для этого сервисы kube-eagle, kube-state-metrics и Prometheus были интегрированы в кластеры Kubernetes. Затем Prometheus конфигурировался с помощью внешних лейблов, идентифицирующих кластер, а remote_write указывал на insert в VictoriaMetrics (см. ниже).

VictoriaMetrics


База данных временных рядов VictoriaMetrics реализует протоколы Graphite, Prometheus, OpenTSDB и Influx. Она не только поддерживает PromQL, но и дополняет его новыми функциями и шаблонами, позволяя избежать рефакторинга запросов Grafana. Кроме того, ее производительность просто потрясает.

Мы развернули VictoriaMetrics в режиме кластера и разбили на три отдельных компонента:

1. VictoriaMetrics storage (vmstorage)


Этот компонент отвечает за хранение данных, импортированных vminsert. Мы ограничились тремя репликами этого компонента, объединенными в StatefulSet Kubernetes.

./vmstorage-prod \        -retentionPeriod 3 \        -storageDataPath /data \        -http.shutdownDelay 30s \        -dedup.minScrapeInterval 10s \        -http.maxGracefulShutdownDuration 30s

VictoriaMetrics insert (vminsert)


Этот компонент получает данные от deployment'ов с Prometheus и переправляет их в vmstorage. Параметр replicationFactor=2 реплицирует данные на два из трех серверов. Таким образом, если один из экземпляров vmstorage испытывает проблемы или перезапускается, все равно остается одна доступная копия данных.

./vminsert-prod \        -storageNode=vmstorage-0:8400 \        -storageNode=vmstorage-1:8400 \        -storageNode=vmstorage-2:8400 \        -replicationFactor=2

VictoriaMetrics select (vmselect)


Принимает PromQL-запросы от Grafana (Trickster) и запрашивает исходные данные из vmstorage. В настоящее время у нас выключен кэш (search.disableCache), поскольку в архитектуре присутствует Trickster, который и отвечает за кэширование; поэтому надо, чтобы vmselect всегда извлекал последние полные данные.

/vmselect-prod \        -storageNode=vmstorage-0:8400 \        -storageNode=vmstorage-1:8400 \        -storageNode=vmstorage-2:8400 \        -dedup.minScrapeInterval=10s \        -search.disableCache \        -search.maxQueryDuration 30s

Общая картина


Текущая реализация выглядит следующим образом:



Примечания к схеме:

  • Production-кластер и кластеры со вспомогательными сервисами более не хранят данные мониторинга. Цель данного конкретного изменения состояла в том, чтобы ограничить глобальную функцию кластеров K8s и предотвратить каскадные отказы. В случае выхода из строя какого-либо кластера важно иметь доступ к метрикам и логам, которые помогут установить суть проблемы. Совместная работа сервисов в одних и тех же кластерах повышала вероятность каскадных отказов и затрудняла диагностику первопричины сбоя.
  • Каждый deployment в составе кластера K8s идет вместе с локальным Prometheus'ом, который собирает исключительно внутренние метрики и отправляет их в VictoriaMetrics insert в инфраструктурном кластере Kubernetes.
  • В инфраструктурном кластере Kubernetes работают два deployment'а с Prometheus, выполняющие разные функции. Вообще говоря, подобная схема не была строго обязательной, однако она придала процессу мониторинга Kubernetes необходимую согласованность, так что любые изменения теперь автоматически и единообразно применяются ко всем кластерам. Global Prometheus теперь отвечает только за сбор метрик с экземпляров EC2, с colocation-хостинга и любых других не-Kubernetes-сущностей.

Заключение


Ниже приведены метрики, которые в настоящее время обрабатывает VictoriaMetrics (итоговые данные за две недели, на графиках показан промежуток в два дня):



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

Это отличный показатель, но есть еще несколько моментов, которые мы планируем улучшить в ближайшие месяцы:

  • Снизить кардинальность метрик, улучшив интеграцию statsd.
  • Сравнить кэширование в Trickster и VictoriaMetrics нужно оценить влияние каждого решения на эффективность и производительность. Есть подозрение, что от Trickster можно вообще отказаться, ничего не потеряв.
  • Превратить Prometheus в stateless-сервис пока он работает как stateful, однако для этого нет особых причин. Мы до сих пор используем лейблы на основе постоянного сетевого имени, предоставляемого StatefulSet'ом, так что об этом придется помнить (как и о pod disruption budgets).
  • Оценить работу vmagent компонента VictoriaMetrics для сбора метрик с Prometheus-совместимых exporter'ов. Учитывая, что на данный момент наш Prometheus только этим и занимается, это перспективное направление для улучшения. В будущем vmagent позволит полностью отказаться от Prometheus (его бенчмарки выглядят многообещающе!).

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

P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..

Обзор инструментов для chaos engineering в Kubernetes. Часть 1 kube-monkey, chaoskube, Chaos Mesh

23.11.2020 12:04:01 | Автор: admin


Хаос-инжиниринг для Kubernetes становится всё популярнее, и это закономерно: ведь такая инфраструктура создавалась быть готовой к тому, чтобы в любой момент что-нибудь отстрелило. А значит это замечательное свойство надо проверять в реальных проектах.

Благо, уже сегодня можно найти не одно Open Source-решение, помогающее в подобных экспериментах. Представляем вашему вниманию их обзор. Он получился весьма объёмным, поэтому был разбит на две части: в этой мы рассмотрим три популярных проекта.

Предыстория


История chaos engineering начинается в 2011, когда в компании Netflix решили, что только избыточная и распределенная инфраструктура может дать действительно высокую отказоустойчивость. Для того, чтоб непрерывно убеждаться в том, что это действительно так, они и создали Chaos Monkey.

Суть этой обезьяны сводилась к тому, чтобы регулярно убивать один из экземпляров какого-то сервиса, будь то виртуальная машина или контейнер. Увеличение размера инфраструктуры и эволюция привели к появлению Chaos Kong сервиса, который отрубает один из трёх регионов AWS. Вот это по-настоящему масштабная проверка отказоустойчивости!

В целом же, список доступных действий для хаос-инжиниринга значительно шире, чем простое убийство сервисов. Главная цель этой новой науки обнаружение вероятных проблем, которые либо не устраняются должным образом, либо не обнаруживаются / не воспроизводятся постоянно. Поэтому убийством не ограничиваются: нужно ещё умело вставлять палки в колёса и дисковую подсистему, рвать сетевые соединения и поджаривать CPU с памятью особо продвинутые могут даже фрагментировать страницы памяти в ядре запущенного pod'а (как это вообще, cgroups?).

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

Возвращаясь же к классическому Chaos Monkey: эта утилита была создана и используется в Netflix. В настоящий момент она интегрирована с платформой непрерывной доставки Spinnaker, поэтому работает с любым поддерживаемым там бэкендом: AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry.

Однако такое, казалось бы, удобство таит в себе обратную сторону. Установка/настройка Chaos Monkey для Kubernetes (в связке со Spinnaker) по своей простоте очень далека от привычного Helm-чарта Далее будут рассмотрены инструменты для chaos engineering, созданные специально для K8s.

1. kube-monkey



Один из самых старых проектов среди изначально ориентированных на Kubernetes: первые публичные коммиты в его репозитории состоялись в декабре 2016 года. Попробуем его сразу в деле на развёрнутом deployment'е nginx из пяти реплик, попутно рассказывая о возможностях.

Итак, вот манифест для испытаний:

---apiVersion: v1kind: Namespacemetadata:  name: test-monkeysspec:  finalizers:  - kubernetes---apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  namespace: test-monkeysspec:  selector:    matchLabels:      app: nginx  replicas: 5  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx:1.16        ports:        - containerPort: 80---

Готовый чарт с kube-monkey самый простой вариант установки и запуска утилиты:

$ git clone https://github.com/asobti/kube-monkey$ cd kube-monkey/helm

Немного модифицируем команду из README.md, чтобы обезьянка жила в своём namespace и начинала работу в двенадцать ночи по Москве, заканчивая за час до полуночи (такое расписание подходило нам на момент написания статьи):

$ helm install -n kubemonkey --namespace kubemonkey --set config.dryRun=false --set config.runHour=0 --set config.startHour=1 --set config.endHour=23 --set config.timeZone=Europe/Moscow --set config.debug.schedule_immediate_kill=true --set config.debug.enabled=true kubemonkey

Теперь можно натравить обезьянку на nginx с помощью лейблов. Kube-monkey работает по принципу opt-in, т.е. взаимодействует только с теми ресурсами, которые разрешено убивать:

$ kubectl -n test-monkeys label deployment nginx kube-monkey/enabled=enabled$ kubectl -n test-monkeys label deployment nginx kube-monkey/kill-mode=random-max-percent$ kubectl -n test-monkeys label deployment nginx kube-monkey/kill-value=100$ kubectl -n test-monkeys label deployment nginx kube-monkey/identifier=nginx

Пояснения по лейблам:

  • Второй и третий (kill-mode, kill-value) говорят kube-monkey убивать случайное количество pod'ов из StatefulSets/Deployments/DaemonSets, вплоть до 100%.
  • Четвёртый (identifier) определяет уникальный лейбл, по которому kube-monkey найдёт жертв.
  • Пятый (mtbf mean time between failure) определяет, сколько дней должно пройти между убийствами (по умолчанию равен единице).

Сразу появляется ощущение, что пять лейблов это многовато, чтобы просто взять и кого-то поубивать Кроме того, есть pull request о том, чтобы mtbf указывать не только в днях (но и в часах, например, чтобы чаще совершать злодеяния). Однако он висит с 5 февраля без движения, что печально.

Ок, посмотрим на логи обезьянки и увидим в конце:

I0831 18:14:53.772484       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:15:23.773017       1 schedule.go:64] Status Update: Generating schedule for terminationsI0831 18:15:23.811425       1 schedule.go:57] Status Update: 1 terminations scheduled todayI0831 18:15:23.811462       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:16:11 +0300 MSKI0831 18:15:23.811491       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.********** Today's schedule **********k8 Api Kind    Kind Name        Termination Time-----------    ---------        ----------------v1.Deployment    nginx        08/31/2020 21:16:11 +0300 MSK********** End of schedule **********

Ура! Chaos-monkey нашла deployment и запланировала убийство одной или более из его реплик. Но что же это и почему?

E0831 18:16:11.869463       1 kubemonkey.go:68] Failed to execute termination for v1.Deployment nginx. Error: v1.Deployment nginx has no running pods at the moment

Посмотрим внимательно в мануал ещё раз и увидим (с устаревшим apiVersion, к сожалению):

For newer versions of kubernetes you may need to add the labels to the k8s app metadata as well.

---apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: monkey-victim  namespace: app-namespace  labels:    kube-monkey/enabled: enabled    kube-monkey/identifier: monkey-victim    kube-monkey/mtbf: '2'    kube-monkey/kill-mode: "fixed"    kube-monkey/kill-value: '1'spec:  template:    metadata:      labels:        kube-monkey/enabled: enabled        kube-monkey/identifier: monkey-victim[... omitted ...]

Ок, изменяем наш шаблон с удалением deployment'а на:

---apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  namespace: test-monkeys  labels:    kube-monkey/enabled: enabled    kube-monkey/identifier: nginx    kube-monkey/kill-mode: random-max-percent    kube-monkey/kill-value: "100"    kube-monkey/mtbf: "1"spec:  selector:    matchLabels:      app: nginx  replicas: 5  template:    metadata:      labels:        app: nginx        kube-monkey/enabled: enabled        kube-monkey/identifier: nginx    spec:      containers:      - name: nginx        image: nginx:1.16        ports:        - containerPort: 80---

Теперь все получилось:

I0831 18:24:20.434516       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:24:50.434838       1 schedule.go:64] Status Update: Generating schedule for terminations    ********** Today's schedule **********    k8 Api Kind    Kind Name        Termination Time    -----------    ---------        ----------------    v1.Deployment    nginx        08/31/2020 21:25:03 +0300 MSK    ********** End of schedule **********I0831 18:24:50.481865       1 schedule.go:57] Status Update: 1 terminations scheduled todayI0831 18:24:50.481917       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:25:03 +0300 MSKI0831 18:24:50.481971       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.I0831 18:25:03.540282       1 kubemonkey.go:70] Termination successfully executed for v1.Deployment nginxI0831 18:25:03.540324       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.I0831 18:25:03.540338       1 kubemonkey.go:76] Status Update: All terminations done.I0831 18:25:03.540499       1 kubemonkey.go:19] Debug mode detected!I0831 18:25:03.540522       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 sec

Ок, работает хорошо и весьма конкретно. Хотя настраивается сложнее, чем могло быть, не очень гибко, да и функций совсем мало. Бывают и странности в работе:

I0831 18:30:33.163500       1 kubemonkey.go:19] Debug mode detected!I0831 18:30:33.163513       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:31:03.163706       1 schedule.go:64] Status Update: Generating schedule for terminationsI0831 18:31:03.204975       1 schedule.go:57] Status Update: 1 terminations scheduled today    ********** Today's schedule **********    k8 Api Kind    Kind Name        Termination Time    -----------    ---------        ----------------    v1.Deployment    nginx        08/31/2020 21:31:45 +0300 MSK    ********** End of schedule **********I0831 18:31:03.205027       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:31:45 +0300 MSKI0831 18:31:03.205080       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.E0831 18:31:45.250587       1 kubemonkey.go:68] Failed to execute termination for v1.Deployment nginx. Error: no terminations requested for v1.Deployment nginxI0831 18:31:45.250634       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.I0831 18:31:45.250649       1 kubemonkey.go:76] Status Update: All terminations done.I0831 18:31:45.250828       1 kubemonkey.go:19] Debug mode detected!

2. chaoskube



Эта утилита тоже может похвастать длинной историей: первый её релиз состоялся в ноябре 2016 года. У chaoskube есть готовый чарт и хороший мануал по нему. По умолчанию запускается в режиме dry-run, поэтому никто не пострадает.

Запустим на простом deployment'е с nginx, живущем в пространстве имен test-monkey, и укажем опцию про создание RBAC (потому что у роли default нет нужных прав):

$ helm install --name chaoskube --set dryRun=false --set namespaces="test-monkeys" --set rbac.create=true --set rbac.serviceAccountName=chaoskube stable/chaoskube

дело сразу пошло!

$ kubectl -n default logs chaoskube-85f8bf9979-j75qmtime="2020-09-01T08:33:11Z" level=info msg="starting up" dryRun=false interval=10m0s version=v0.14.0time="2020-09-01T08:33:11Z" level=info msg="connected to cluster" master="http://personeltest.ru/aways/10.222.0.1:443" serverVersion=v1.16.10time="2020-09-01T08:33:11Z" level=info msg="setting pod filter" annotations= excludedPodNames="<nil>" includedPodNames="<nil>" labels= minimumAge=0s namespaces=test-monkeystime="2020-09-01T08:33:11Z" level=info msg="setting quiet times" daysOfYear="[]" timesOfDay="[]" weekdays="[]"time="2020-09-01T08:33:11Z" level=info msg="setting timezone" location=UTC name=UTC offset=0time="2020-09-01T08:33:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-8kf64 namespace=test-monkeystime="2020-09-01T08:43:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-t7wx7 namespace=test-monkeystime="2020-09-01T08:53:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-8fg9q namespace=test-monkeystime="2020-09-01T09:03:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-wf5vg namespace=test-monkeys

Конфигурировать можно всё, что может потребоваться: часовой пояс, временные исключения, лейблы, по которым ищутся pod'ы-жертвы, и исключения.

Подводя быстрый итог: хороший, удобный и простой инструмент, но, как и kube-monkey, умеет только убивать pod'ы.

3. Chaos Mesh



Chaos Mesh состоит из двух компонентов:

  1. Chaos Operator оператор хаоса, основной компонент, который в свою очередь состоит из:
    1. controller-manager (управляет Custom Resources),
    2. chaos-daemon (привилегированный daemonset с возможностями управления сетью, cgroups и т.д.),
    3. sidecar-контейнера, динамически вставляемогов целевой pod, чтобы вмешиваться в I/O целевого приложения.
  2. Chaos Dashboard веб-интерфейс для управления и мониторинга хаос-оператора

Проект входит в CNCF и разработан китайской компанией PingCAP, которая известна своей распределённой, Open Source, cloud-native SQL-базой данных для аналитики в реальном времени TiDB (мы писали про её собрата TiKV, тоже входящего в число проектов CNCF).

Итак, хаос-оператор использует CRD для определения объектов хаоса. Всего их шесть типов: PodChaos, NetworkChaos, IOChaos, TimeChaos, StressChaos и KernelChaos. А вот какие доступны действия (эксперименты):

  • pod-kill убийство pod'а;
  • pod-failure недоступность pod'а некоторое (определённое) время;
  • container-kill убийство одного из контейнеров pod'а;
  • netem chaos сетевые проблемы, задержки, повторы пакетов;
  • network-partition эмуляция распада сети на сегменты;
  • IO chaos проблемы с диском и чтением/записью;
  • time chaos искажение показателя текущего времени в pod'е;
  • cpu-burn стресс CPU;
  • memory-burn стресс памяти;
  • kernel chaos жертва получит ошибки ядра, фрагментацию страниц памяти, проблемы с блочным I/O.

Объявляя любой из нужных нам Custom Resource, мы можем указать в нём типы действий, лейблы и селекторы для определения целевых namespace или конкретных pod'ов, а также длительность и расписание проведения экспериментов в общем, всё необходимое для планирования веселья.
Звучит очень интересно, да? Давайте попробуем! Документация по установке снова с Helm.

Не забудем указать --set dashboard.create=true, чтобы получить панели с красивыми графиками! Через пару минут мы получаем целое пространство имён из повелителей хаоса пока ещё бездействующих, но уже готовых к работе:

$ kubectl -n chaos-testing get poNAME                                       READY   STATUS    RESTARTS   AGEchaos-controller-manager-bb67cb68f-qpmvf   1/1     Running   0          68schaos-daemon-krqsh                         1/1     Running   0          68schaos-daemon-sk7qf                         1/1     Running   0          68schaos-daemon-wn9sd                         1/1     Running   0          68schaos-dashboard-7bd8896c7d-t94pt           1/1     Running   0          68s

Для изучения и демонстрации работы chaos-mesh подготовлен подробный мануал, в котором можно увидеть многочисленные возможности оператора. С технической точки зрения, внутри репозитория (https://github.com/chaos-mesh/web-show) находится Deployment тестового приложения на React с сервисом, которому скриптом передаётся IP-адрес pod'а kube-controller-manager (первый из списка, если у нас мультимастер, или просто единственный). После запуска этот pod начинает непрерывно пинговать pod controller-manager'а и визуализировать на графике этот ping.

В нашем случае удобнее выпустить этот график наружу через Ingress, а не команду из deploy.sh (nohup kubectl port-forward svc/web-show --address 0.0.0.0 8081:8081). Поэтому мы просто применяем Deployment и Service из репозитория и объявляем любой Ingress просто для того, чтобы можно было попасть в приложение снаружи.



Приятный график. Судя по сегменту ST, у пациента острый инфаркт! Стоп, это же не кардиограмма А теперь можно применить заклинание хаоса, слегка подкорректировав его для пущей красоты:

apiVersion: chaos-mesh.org/v1alpha1kind: NetworkChaosmetadata:  name: web-show-network-delayspec:  action: delay # the specific chaos action to inject  mode: one # the mode to run chaos action; supported modes are one/all/fixed/fixed-percent/random-max-percent  selector: # pods where to inject chaos actions    namespaces:      - test-monkeys    labelSelectors:      "app": "web-show"  # the label of the pod for chaos injection  delay:    latency: "50ms"  duration: "10s" # duration for the injected chaos experiment  scheduler: # scheduler rules for the running time of the chaos experiments about pods.    cron: "@every 60s"

Результат ожидаемая нами красивая пила, сигнализирующая о том, что netem chaos уже работает. И вот тут уже точно инфаркт.



А вот как выглядит chaos-dashboard:



Визуализация событий:



Подробности о конкретном эксперименте:



Есть даже веб-редактор Custom Resources, но встроенной авторизации к нему нет (обязательно надо закрывать авторизацией!):



В завершении обзора этого проекта стоит упомянуть, что недавно (25 сентября 2020 г.) у Chaos Mesh произошло знаменательное событие релиз версии 1.0.

Продолжение следует


Во второй части статьи будут рассмотрены Litmus Chaos, Chaos Toolkit, игровые варианты хаос-инжиниринга в Kubernetes и некоторые другие проекты, а также подведён общий итог.

P.S.


Читайте также в нашем блоге:

Подробнее..

Observability система для микросервисов на примере Instana, часть 1

27.11.2020 10:16:55 | Автор: admin

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

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

Мыпрошли этот путь больше года назад, когда изучали инструменты, которые стоит использовать вне стандартной связки Prometheus + Grafana. Обзор получился объемным, поэтому разбили надве части.

Архитектура и установка агентов

Архитектурно продукт Instana состоит изсервера иагентов, собирающих данные. Устанавливается один агент нахост, который контролирует сам хост, все контейнеры иприложения, работающие нахосте. Основные данные, которые собирает продукт это метрики приложений иинфраструктурных компонентов (прокси-серверы, СУБД, кэш, очереди итд), трейсы приложений, логи иошибки приложений. Поддерживается 200+ технологий для сбора данных. Помимо этого, впродукте присутствуют модули EUM End User Monitoring для сбора данных производительности сконечных пользователей, взаимодействующих сприложениями через веб-браузеры инативные мобильные приложения для iOS иAndroid.

Сервер Instana backend, накоторый агенты отсылают данные, предоставляется помодели SaaS, атакже доступен вварианте on-premise для компаний, нежелающих использовать облачную модель размещения.

Мониторинг микросервисных приложений начинается сустановки агента Instana. Агент устанавливаются одной командой. Вразделе установки мывыбираем нужную нам платформу, идалее генерируется скрипт для его установки. Среди поддерживаемых агентом платформ есть Linux, Unix, Windows, Kubernetes всех мастей иоблачные среды AWS, Azure иGoogle Cloud.

Мастер выбора платформы и варианта установки агента Мастер выбора платформы и варианта установки агента

Наскриншоте представлен один извариантов установки агента вKubernetes кластер helm chart. Также можно установить агента спомощью Kubernetes Operator или daemonset.yaml. После того, как агенты установятся внаш кластер, мысможем посмотреть накарту нашей инфраструктуры вInstana.

Первое знакомство с продуктом Infrastructure Map

Карта объектов инфраструктурыКарта объектов инфраструктуры

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

Каждая башня нанашей карте инфраструктуры представляет хост, вданном случае, ноду Kubernetes кластера. Аналогично будут представлены просто машины, неотносящиеся ккластеру. Внутри каждой башни мывидим этажи или, как ихназывают всамой Instana, коробки отпиццы это текомпоненты, которые были автоматически обнаружены намашине контейнеры, приложения, базы данных, прокси серверы, очереди, балансировщики, процессы итд.

Внашем случае мывидим, что агент обнаружил Docker контейнеры, Node.JS приложения, MongoDB, SpringBoot Java приложения иеще много других компонентов.

Свойства выбранного Node.JS приложения на карте инфраструктурыСвойства выбранного Node.JS приложения на карте инфраструктуры

Выбрав одну из коробок от пиццы мы получаем сводную информацию об этом компоненте. Выбрав Node.JS приложение shop-frontend мы видим версию приложения, ID процесса, аргументы запуска и другую информацию. Для детального анализа компонента по клику доступен дашборд с инфраструктурными метриками, но мы поговорим об этом позже. Также мы видим полную инфраструктурную географию этого компонента указание на детали расположения компонента в инфраструктуре. В нашем случае Node.JS приложение связано с процессом node, процесс находится в контейнере, контейнер в k8s поде, под находится на ноде k8s, а нода k8s обслуживается хостом. Для каждого из этих уровней доступны свои собственные дашборды и соответствующие метрики.

Свойства выбранного Docker контейнера на карте инфраструктурыСвойства выбранного Docker контейнера на карте инфраструктуры

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

Карта инфраструктуры с контейнерами, сгруппированными по Kubernetes namespaceКарта инфраструктуры с контейнерами, сгруппированными по Kubernetes namespace

Автоматический распределенный трейсинг гетерогенных приложений

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

С точки зрения трейсинга продукт поддерживает следующие языки разработки и технологии:

Технологии, поддерживаемые в Instana с точки зрения трейсингаТехнологии, поддерживаемые в Instana с точки зрения трейсинга

Давайте посмотрим на обнаруженные сервисы в нашем случае. Сервис в данном контексте это https/grpc сервисы приложения, база данных, очередь сообщений, CLI скрипт, кэш и другие системы.

Для этого перейдем в раздел Applications на вкладку Services где мы видим все наши сервисы и их основную информацию - имя и тип сервиса, количество обнаруженных endpoints и ключевые метрики - количество вызовов, время исполнения и процент ошибок.

Список обнаруженных сервисовСписок обнаруженных сервисов

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

Карта взаимодействия сервисовКарта взаимодействия сервисов

При выделении любого из сервисов система сразу же подсветит все сервисы, с которыми выбранный сервис напрямую взаимодействует, также отобразит его KPI.

Карта взаимодействия сервисов, выбор сервисаКарта взаимодействия сервисов, выбор сервиса

Управление группами сервисов

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

Группы сервисов - Application Perspective Группы сервисов - Application Perspective

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

Настройка Application Perspective и критерии объединения сервисовНастройка Application Perspective и критерии объединения сервисов

Например, мы можем сгруппировать сервисы по окружениям - production, stage, dev, test. Можем сгруппировать по Kubernetes namespace или deployments, по тегам, по продукту, команде и так далее. После создания Application Perspective сервисы сгруппируются по указанным параметрам и, в случае появления нового сервиса с параметрами, подходящими под настроенные критерии, сервис автоматически добавится в заданную группу.

По каждому приложению (Application Perspective), которых мы можем создать неограниченное количество, мы получаем готовый дашборд с метриками всех входящих в это приложение сервисов. Это позволяет посмотреть на карту взаимосвязей и метрики именно отфильтрованных сервисов приложения.

Дашборд KPI приложения (группы сервисов)Дашборд KPI приложения (группы сервисов)

В Instana Application Perspectives используются для анализа KPI на дашбордах, ролевого управления доступом, алертинга, фильтрации данных на многих экранах. Функционал Application Perspectives позволяет различным командам разработки и эксплуатации эффективно фокусироваться на своих участках и не мешать друг другу.

Анализ KPI сервисов и endpoints

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

Мы переходим на такой дашборд просто выбрав интересующий нас сервис на карте сервисов или в списке. Давайте посмотрим на сервис eum-shop это HTTP сервис Spring Boot приложения.

Дашборд KPI сервисаДашборд KPI сервиса

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

Список обнаруженных endpoint у сервиса, в данном случае он один Список обнаруженных endpoint у сервиса, в данном случае он один

Аналогично представлен дашборд с метриками производительности каждого endpoint для сфокусированного анализа.

Дашборд endpoint KPI Дашборд endpoint KPI

Интеграция с CI/CD маркеры релизов в графиках мониторинга

Когда мы анализируем метрики производительности сервисов и видим деградацию в производительности рост процента ошибок, увеличение времени исполнения важно знать, а не связано ли это с выпуском нового релиза? Для визуализации такой информации предусмотрена возможность сообщать в Instana о том, что был сделан релиз приложения или какого-то одного сервиса, сделав простой вызов к API, например, из CI-пайплайна.

Маркер релиза на дашборде сервисаМаркер релиза на дашборде сервиса

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

Список недавних релизов для анализа производительностиСписок недавних релизов для анализа производительности

Инфраструктурный контекст и взаимосвязь сервисов

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

На вкладке Upstream, мы видим все сервисы, которые вызывают сервис eum-shop, и их ключевые метрики.

Upstream сервисы и их метрики - кто обращается к eum-shopUpstream сервисы и их метрики - кто обращается к eum-shop

Аналогично в Downstream мы видим все сервисы, которые вызывает сервис eum-shop, и их ключевые метрики - обычно это не только http сервисы, но и базы данных, кэш, очереди и тд..

Downstream сервисы и их метрики - к кому обращается eum-shopDownstream сервисы и их метрики - к кому обращается eum-shop

Instana не только определяет связи сервисов между собой, но и связи с компонентами инфраструктуры. Эта информация доступна по клику кнопки Stack.

Связь сервиса с объектами инфраструктурыСвязь сервиса с объектами инфраструктуры

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

Перейдя на вкладку Kubernetes мы увидим сущности Kubernetes, с которыми связан наш сервис pod, Kubernetes service, namespace, deployment, node.

Связь сервиса с объектами KubernetesСвязь сервиса с объектами Kubernetes

Перейдя на вкладку Application мы увидим группы приложений, в которые входит анализируемый сервис (как мы помним один сервис может входить в несколько приложений) и их сводные KPI.

Связь сервиса с приложениямиСвязь сервиса с приложениями

Нам доступен drill down на дашборды связанных компонентов для детального анализа их производительности. Давайте проанализируем наш Kubernetes кластер.

Мониторинг Kubernetes

Instana очень тесно интегрируется с Kubernetes и собирает все ключевые метрики и данные нашего кластера. Для анализа Kubernets представлен отдельный дашборд, где мы можем наблюдать метрики всего кластера, по нодам, подам, namespace, deployments, k8s сервисам и так далее.

Дашборд Kubernetes кластераДашборд Kubernetes кластера

Перейдя ко вкладке Namespaces мы обнаруживаем список всех Namespace с их основными метриками.Выбрав интересующий нас namespace мы можем более подробно его изучить какие поды, какие сервисы, какие deployments связаны с этим namespace.

Дашборд одного из Kubernetes namespaceДашборд одного из Kubernetes namespace

Инфраструктурные метрики Kubernetes уже есть в Prometheus + Grafana, но с помощью Instana мы получили связь еще и трейсов с сущностями Kubernetes. C Kubernetes дашборда мы переходим к анализу вызовов, которые были в этом namespace. Кликнув на кнопку Analyze calls мы попадем в новый раздел - раздел Аналитика.

Раздел Аналитика

Раздел Аналитика с группировкой вызовов по Kubernetes Service и KPIРаздел Аналитика с группировкой вызовов по Kubernetes Service и KPI

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

Давайте сгруппируем наши вызовы по имени endpoint:

Группировка вызовов по одному из тэгов - названию endpointГруппировка вызовов по одному из тэгов - названию endpoint

И посмотрим на графике к каким endpoints больше всего идет вызовов.

График количества вызовов, сгруппированных по endpoint nameГрафик количества вызовов, сгруппированных по endpoint name

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

Список вызовов по заданным фильтрам и их длительностьСписок вызовов по заданным фильтрам и их длительность

Как мы видим, у нас применился новый фильтр endpoint.name. Но в данном случае нас интересуют только вызовы с ошибкой. Одним кликом мыши добавляем фильтр erroneous = true для получения всех вызовов с ошибкой - Instana записывает каждый вызов и все они доступны для анализа.

Список вызовов, содержащих ошибку и их длительностьСписок вызовов, содержащих ошибку и их длительность

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

Детальный анализ трейсов

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

Детальный анализ трейсаДетальный анализ трейса

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

Дерево вызовов - последовательность спанов в трейсе и их данныеДерево вызовов - последовательность спанов в трейсе и их данные

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

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

Связь спана с объектами инфраструктурыСвязь спана с объектами инфраструктуры

Анализ инфраструктурных метрик

Перейдя к Spring Boot приложению мы попадаем на соответствующий дашборд с метриками Spring Boot. Instana автоматически собирает ключевые метрики с более чем 200 технологий, например, nginx, redis, postgresql, mysql, rabbitmq, elasticsearch, kaffka, Docker, IIS, Tomcat и многих других. Для каждой из технологий доступен автоматически настроенный дашборд.

Метрики Spring Boot приложенияМетрики Spring Boot приложения

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

Расположение приложения в инфраструктуреРасположение приложения в инфраструктуре

Например, анализируя метрики Spring Boot приложения нам может быть удобно сразу посмотреть метрики JVM, в которой запущено наше приложение информация о threads, heap memory, memory pools, garbage collection и другие:

Метрики JVMМетрики JVM

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

Метрики машиныМетрики машины

Алертинг и выявление аномалий

Из коробки мы получили более 230 правил для определения состояния здоровья различных компонентов инфраструктуры и обнаружения аномалий в KPI сервисов и endpoints. Для каждого сервиса и каждого endpoint Instana определяет нормальное поведение KPI метрики (baseline) и, в случае отклонения от baseline, мы получим соответствующие оповещение.

Список правил алертинга и выявления аномалийСписок правил алертинга и выявления аномалий

Можно добавлять свои собственные правила. В качестве критерия могут быть метрики объектов инфраструктуры, Kubernetes, приложений и сервисов, пользовательского опыта.

Все что относится к результатам мониторинга состояния здоровья, мы можем увидеть в разделе Events.

Раздел Events - сработавшие правилаРаздел Events - сработавшие правила

В Instana существует несколько типов событий:

  • Changes изменения компонентов инфраструктуры. Мы видим события онлайн/офлайн компонентов (включение и отключение процессов, контейнеров и тд), были ли изменения в конфигурации компонента.

  • Issue сработало правило определения состояния здоровья. Правила могут быть как встроенные, так и созданные самостоятельно.

  • Incidents события самого высокого уровня, которые открываются, когда проблемой затронуты наши конечные пользователи или возникла критичная проблема в нашей инфраструктуре. В инцидент объединяются и коррелируются все сопутствующие события на основе анализа графа связей сервисов и компонентов инфраструктуры.

Перейдя ко вкладке Incidents мы увидим все инциденты.

ИнцидентыИнциденты

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

Детали одного из инцидентовДетали одного из инцидентов

Что мы видим в инциденте? Время начала и завершения инцидента, сколько событий с ним связано (15), сколько было затронуто компонентов инфраструктуры и сервисов (5) и сами события. Давайте разберемся, с чего начался наш инцидент.

Детали одного из событий в инцидентеДетали одного из событий в инциденте

Началось все с того, что на сервисе catalogue-demo резко увеличилось количество вызовов с ошибками. В деталях события мы получили говорящую подсказку This can be a sign of a problem on one side of the connection. На графике метрики рейт ошибочных вызовов, которая связана с этим событием, мы видим, что у нас 60% вызовов вдруг стали содержать ошибки. Прямо отсюда мы можем перейти к анализу вызовов в разделе Аналитика, где будут автоматически применены все фильтры, связанные с этим событием вызовы будут отфильтрованы по сервису catalogue-demo и добавлен фильтр erroneous.

Что случилось дальше? За счет того, что Instana определила взаимосвязи сервисов и компонентов инфраструктуры, мы можем увидеть, как проблема на одном сервисе, затронула другие сервисы. Мы видим список других сервисов и компонентов инфраструктуры и их проблемы на одних резко уменьшилось количество вызовов, на других также увеличился процент ошибок, на третьих увеличилось среднее время транзакций.

Список событий в инциденте и его причинаСписок событий в инциденте и его причина

В расследуемом инциденте есть событие Abnormal termination процесса базы данных MySQL. Собственно это и есть причина нашего инцидента.

На этот инцидент мы получили одно оповещение от Instana, так как продукт понял, что эти проблемы связаны, вместо получения на каждое событие по каждому из 5 сервисов отдельного алерта. Такая автоматическая группировка помогла нам избежать шума в оповещениях.

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

Список каналов для отсылки оповещенийСписок каналов для отсылки оповещений

Что мы получили в итоге

Подведем промежуточные итоги первой части обзора. С помощью Instana мы смогли:

  • наблюдать всегда актуальную картину нашей инфраструктуры и взаимосвязи всех микросервисов между собой;

  • без каких-либо усилий по настройке собрать и использовать метрики со всех компонентов, таких как JVM, Node JS приложение, Nginx, Redis, Postgresql, сами Docker контейнеры, кластер и все сущности Kubernetes;

  • автоматически получить распределенный трейсинг для PHP, Python, Node JS, Java и других сервисов;

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

Микросервисное приложение, которое использовалось в этом обзоре, вы можете запустить самостоятельно: https://github.com/instana/robot-shop

Для изучения продукта Instana на собственной инфраструктуре доступен бесплатный триальный период: https://www.instana.com/trial/

В следующей части обзора Instana мы рассмотрим функционал End User Monitoring для контроля производительности приложений у реальных пользователей в браузерах и в нативных мобильных приложениях.

Спасибо за внимание.

Подробнее..

Контейнеризация понятным языком от самых азов до тонкостей работы с Kubernetes

27.11.2020 18:11:38 | Автор: admin


Чем контейнеры отличаются от виртуальных машин, почему Docker настолько популярен, что такое Kubernetes и в чём его преимущества и недостатки. В интервью АйТиБороде СТО Слёрма Марсель Ибраев и старший инженер Southbridge Николай Месропян рассказали о контейнеризации понятным языком. Мы перевели интервью в текст для тех, кому лень смотреть.
Мне не лень смотреть, мне лень читать


Разница между контейнеризацией и виртуализацией


Что такое виртуализация?


Виртуализация появилась как средство уплотнения окружений на одном и том же железе. Сначала программный продукт выполнялся на железном сервере. Потом, чтобы иметь возможность поселять в одно и то же железо больше клиентов, чтобы максимально полно утилизировать производительные мощности, придумали виртуализацию. Теперь на одном и том же железе можно держать несколько окружений. В зависимости от среды, опять же. Есть полностью проприетарные решения, такие как vmware vsphere, есть опенсорсные решения, как QEMU KVM, на основе которого Red Hat делает свой коммерческий гипервизор Red Hat Virtualization. На платформе Windows есть Hyper-V.


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


Ядра разделяются физически или можно виртуально разделить там одно физическое ядро на несколько при виртуализации?


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


Что такое контейнеры и контейнеризация, и чем отличаются?


Детали зависят от операционной системы, на которой выполняется контейнер, но вообще контейнер делит с хостом ядро, пространство памяти ядра, и своё у контейнера только пользовательское окружение. Первая широко распространенная технология контейнеризации в Linux это OpenVZ, которая потом превратилась в коммерческий продукт Virtuozzo. Мы много работали и работаем с OpenVZ. У нас клиентские окружения жили в контейнерах OpenVZ, пока мы не перешли на более современные технологии.


То есть контейнер от виртуальной машины отличается только тем, что в контейнере общее адресное пространство?


Нет. Виртуальная машина изолируется полностью средствами процессора (технологии Intel, AMD, VMX).


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


Контейнер это продолжение виртуализации? То есть это технология, которая является преемником виртуализации?


Нет. Они ни в коем случае не конкурируют. Они занимают совершенно разные ниши в использовании.


Тогда почему их постоянно сравнивают? И постоянно есть вопрос, что лучше виртуализация или контейнеризация?


С моей точки зрения сравнить контейнеризацию и виртуализацию нельзя. Это сравнение теплого с мягким.


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


Для тебя виртуальная машина это обычная изолированная операционная система, целиком: своё ядро, свой init, systemd и так далее. Чем она отличается от контейнера с точки зрения потребления ресурсов? Тем, что она полностью занимает все ресурсы, под неё выделенные. То есть, есть механизмы, когда можно динамически, то есть в зависимости от потребления процессами внутри виртуальной машины, освобождать память на хосте или занимать её. Но это всё полумеры.


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


Если мы говорим о Docker (а в рамках разговора мы не сможем обсудить все варианты контейнеризации), то он рассчитан на то, что в одном контейнере работает одно приложение.


Возвращаясь к твоему первому вопросу, разница вот в чём. Допустим, если у тебя на хосте Linux или VMware, то виртуальная машина у тебя может быть Windows. Если у тебя в контейнере Linux, то у тебя и снаружи Linux. Потому что мы в первую очередь пользуемся для изоляции не средствами железа, не средствами гипервизора, а средствами операционной системы cgroups и namespace.


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


Виртуалка сама по себе большая, так как содержит целую операционную систему. Если нам нужно развернуть виртуальную машину, то нужно нести с собой и ядро, и всё пользовательское окружение, и какой-то запас места (потому что динамически оно с хостом шариться в общем случае не может). Я не видел линуксовую виртуальную машину весом меньше 10 Гб, и это без данных. Потом к ней еще нужно прицепить диски для данных, в зависимости от того, что будет внутри.


Если говорить о контейнерах, есть разные дистрибутивы, в том числе специально созданные для контейнеризации, тот же Alpine Linux, который в голом виде весит 20 или 50 Мб в зависимости от версии. То есть ничего не весит, собственно говоря.


Виртуалка тянет полностью всю операционку, а когда Docker создаешь, ты тянешь только какие-то небольшие пакеты?


Нет. Чтобы создать Docker-контейнер ты должен собрать образ. Ты берёшь какой-то базовый образ, тот же Alpine, CentOS или Ubuntu. В него с помощью специальных команд зашиваешь свое приложение и выгружаешь уже туда, где оно будет работать.


То есть все равно ты в контейнере используешь полноценную операционку? Вот тот же образ Alpine Linux.


Она может быть сильно порезаной по сравнению с операционной системой, которую ты засовываешь в виртуальную машину.


Но потенциально ты можешь и полноценный Linux запустить в контейнере?


Потенциально да, можешь.


Но смысла в этом, наверное, нет.


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


Один контейнер? А это не слишком жирно использовать для одного приложения, ну пусть и урезанную, но операционную систему?


Когда нужна изоляция это не слишком жирно.


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


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


Почему Docker захватил весь рынок? Вот ты говорил, что было решение какое-то изначально в Linux?


Нет. Оно занимало и занимает совершенно другую нишу. Docker захватил весь рынок в первую очередь потому, что он первым начал использовать технологии namespace и cgroups для, так сказать, народа. Понизил порог вхождения в эти технологии до того, чтобы можно было выйти на широкий рынок, на широкого пользователя.


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


А как тут обстоит дело с дебагом твоего кода, логированием и всем остальным? Со стороны кажется, что это сложновато: нужно залезть внутрь какого-то контейнера, который представляет из себя урезанную операционку


Когда работаешь с контейнерами, в принципе не обязательно думать, что это операционка, не операционка. Там начинается другой мир. Да, к нему надо привыкнуть, но с дебагом, логированием проблем нет никаких, потому что хорошим тоном считается писать все логи в stdout/stderr контейнера, а не в файлики внутри него.


Docker-контейнер знаменит тем, что он одноразовый. Он запустился, а после того, как ты контейнер удаляешь, если ты специально никаких мер не предпринимал, чтобы сохранить в нём данные, у тебя всё удаляется. Поэтому все логи обычно пишут в stdout/stderr, средствами Docker или внешних утилит экспортируют их в ElasticSearch, ClickHouse или какие-то другие системы хранения логов и централизованно уже с ними работают. В первую очередь потому, что контейнеров много. Контейнеров в сетапах могут быть десятки, сотни, тысячи и десятки тысяч.


Как правило, они весьма короткоживущие. Если мы сетапим железные сервер или виртуалку, они могут работать годами, то контейнер живёт до обновления образа максимум. Поэтому контейнеров много, они сравнительно короткоживущие, эфемерные, непостоянные. И поэтому всё, что нужно хранить вне них, нужно хранить специальными методами.


Что насчет контейнеризации в Windows? Насколько я помню, там если не всё очень плохо, то не всё так просто, как на Linux.


Там, действительно, очень сложно. Я ни в коем случае не Windows-админ, знаком поверхностно. Но насколько я знаю, нативная контейнеризация в Windows есть. Есть средства изоляции и по ресурсам, и по пространствам имен, сетевые пространства имен, для памяти, под файлы и так далее. То есть можно Windows запустить как контейнер Windows. Это Windows Server Containerization, если я не ошибаюсь (Windows-админы, не обессудьте).


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


Когда контейнер выполняется, он не представляет собой некий образ. Когда выполняется виртуальная машина это образ, внутри которого своя файловая система, свои разделы, где всё это нарезано и всё это варится. Когда выполняется контейнер, для операционной системы это просто набор ограничений. Когда мы смотрим на процесс виртуальной машины с хоста, мы видим один процесс. В винде это Microsoft Hyper-V, в Linux это QEMU KVM, в vSphere это тоже один процесс. Когда мы смотрим с хоста на контейнер, то видим дерево процессов.


Но почему мы образы передаем друг другу? Я приложение запаковываю в Docker, и мы девелоперы передаём друг другу образы.


Образ это то, из чего контейнер запускается. А с точки зрения хоста это дерево процессов, которые ограничены через встроенные средства ограничения, то есть через namespace и cgroups. Это я к тому, что Docker по своей сути линуксовый.


А почему нельзя было сделать универсальное решение, чтобы оно и для Linux, и для винды работала? Там нет общих API или в Linux есть что-то, чего нет


Ядро-то разное.


Архитектура разная, да?


Да, API Windows и API Linux это совершенно разные вещи. По той же причине нет нативного Docker для macOS. Потому что используются средства изоляции линуксового ядра.


Я думал, что ядра macOS и Linux очень похожи.


Нет. macOS больше UNIX-like, нежели Linux. Потому что, как известно GNU is not UNIX (рекурсивный акроним). А macOS внутри более, так сказать, близка к юниксам. И там нет таких механизмов, как в Linux. Они развиваются независимо.


Docker и для Windows, и для macOS это чужеродное тело, которое запускается в линуксовой виртуалке.


Получается, чтобы запустить контейнер, нужно запустить еще и виртуалку?


Мы запускаем линуксовую виртуалку, а уже в ней мы уже запускаем эти контейнеры. Docker Desktop скрывает от пользователя все сложные процессы, но внутри все равно остаются всякие. Ну не то, чтобы это очень неэффективно. Если вам нужно разрабатывать что-то под Docker, но у вас только Windows или только macOS, то это позволяет работать, да. Но в продакшене с нагрузками так ничего толком не запустишь.


Я понял, что ты в основном с Linux работаешь, но вдруг ты слышал про WSL (Windows Subsystem for Linux)?


Разумеется, я на OpenNET читаю об этом всём и удивляюсь.


А может ли эта штука запустить контейнеры нативно? Я просто не знаю, она тоже под виртуалкой?


Насколько я понимаю, WSL это Wine наоборот. То есть трансляция вызовов API в нативные для винды. Если у нас Wine это трансляция вызовов виндового API для ядра Linux, то WSL это наоборот. И поэтому средств изоляции там ядерных линуксовых нет. Поэтому увы, увы.


Про оркестрацию


Скажем, у нас микросервисная архитектура, и не одно приложение, а много всего: 10, 20, 40, 100 микросервисов. Руками их конфигурировать совсем не прикольно. Как с этим разбираются?


Да, это вполне типовая ситуация. Сейчас особенно, потому что стильно, модно, молодежно. Постепенно приложение обрастает логикой, микросервисов становится больше и больше. И одного Docker, и даже Docker Compose уже становится мало. Ну и плюс ко всему, наверное, еще хочется какую-то отказоустойчивость, чтобы это на нескольких серверах работало. Возможно, какой-то Service Discovery и прочее.


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



Марсель Ибраев, СТО Слёрм


Docker Compose не позволяет нам ничего делать? Ведь это тоже средство управления несколькими контейнерами.


Docker Compose, как минимум, не позволяет запускать проект на нескольких серверах. То есть это все равно все-таки история про одну ноду. Поэтому, да.


ОК. Что придумано? Что есть сейчас, чтобы это все делать?


Сразу нужно сказать, что инфраструктурный стандарт это всё-таки Kubernetes. Штука, которая в свое время была произведена в Google. И Google по зову сердца, по доброте своей решил поделиться с миром.


Есть ещё ряд решений, например, Docker Swarm, Mesos, OpenShift и другие, но всё-таки наиболее популярен и пользуется спросом Kubernetes. Компании, которые задумываются о том, что им нужен оркестратор, в первую очередь смотрят на Kubernetes.


Где обычно применяются оркестраторы, в частности Kubernetes?


Да, это очень важный вопрос. Дело в том, что Kubernetes все проблемы не решает. Компания работает, работает, у них всё плохо (как правило, плохо с процессами) они такие: Блин, Kubernetes классная штука. Давайте её себе поставим у нас всё сразу станет хорошо! Но становится сильно хуже.


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


Если вы небольшая компания или если у вас монолит, и вы такие: Сейчас мы его в куб засунем и все станет хорошо! Нет, не станет.


Kubernetes работает только с контейнерами Docker и с их оркестрацией?


Kubernetes работает с контейнерами, но не только с Docker. У Kubernetes есть такая штука, которая называется Container Runtime Interface. В принципе, все системы контейнеризации, которые сейчас есть и которые поддерживают Container Runtime Interface, могут работать с Kubernetes. Например, rkt.


Сейчас возникло движение энтузиастов, которые выкорчевывают Docker из Kubernetes и используют что-то другое. Потому что Docker тоже не без проблем. Главная проблема Docker это его демон, который имеет свойство зависать, особенно при большой нагрузке. Но зачем демон, если у нас уже есть Kubernetes, есть достаточно зрелая инфраструктура и нам надо просто какое-то место для запуска контейнеров.


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


А что может быть использовано вместо Docker более оптимальным путем?


Оптимально пока сложно сказать, потому что у конкурентов Docker есть свои минусы. К примеру, containerd не имеет нормального средства управления им. К слову, с версии 1.11, кажется, под капотом Docker containerd и работает. По сути, сейчас Docker выполняет роль обёртки над containerd, а там containerd, а внутри ещё runC, если уж совсем углубляться.


Кто-то говорит про Podman: делайте просто алиас Podman Docker, и можно сразу работать. Но тоже есть свои нюансы, поэтому мы в том числе пока работаем с Docker.


Расскажи подробнее, как вообще Kubernetes работает? Что у него происходит под капотом? Для начала уточним, Kubernetes это сервис или это какое-то ПО, которое можно ставить на сервера, или это и то и то?


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


Всегда нужно держать в голове, что Kubernetes это в первую очередь оркестратор контейнеров. Когда вы это понимаете, то вы понимаете, для чего он нужен.


Kubernetes состоит из нескольких компонентов, которые выполняют каждый свою роль (подробно о них ещё поговорим). Из этого вытекает две особенности:


  1. Компоненты друг друга не аффектят. Если один упал, то все остальные могут продолжить работать.
  2. Эти компоненты работают по pull-модели. Нет никакого центрального компонента, командира, который всем раздаёт команды, а как сдох, так все не знают что делать. Каждый компонент выполняет свою часть работы: сделал, завершил. Если он умер, ну значит этот кусочек не выполнится.

Теперь по поводу самих компонентов. Основной компонент это API-сервер. Это просто апишка, REST API (разработчики понимают, о чём речь): управление с помощью http-запросов, версионирование кстати тоже. Очень важно, что там есть версия API, при обновлении мы можем на эти версии API завязываться и за счёт этого обновляться менее болезненно. Есть API, с которым работают все: и клиент (мы, как оператор кластера), и компоненты остальные в том числе.


API-сервер работает с хранилищем, которое представляет из себя просто etcd. Etcd это key-value хранилище, то есть ключ-значение. Вот и API-сервер это единственный компонент, который с этим хранилищем взаимодействует.


Это какая-то разработка команды kubernetes?


Нет, это отдельная штука, очень древняя.


А почему её у Redis нет, например?


У Redis есть проблемы с многопоточностью, есть проблемы с кластеризацией (хотя они ее постепенно решают). А etcd штука древняя, все детские болезни там уже вылечены, и она достаточно такая отказоустойчивая.


Кстати, это хороший показатель, что если разработчики Kubernetes уже начиная с первых версий используют etcd, то, наверное, у себя его тоже можно использовать как key-value в кластер-режиме.


API-сервер единственный, кто с etcd работает, он записывает, считывает информацию. А в etcd у нас хранится всё. Там наши настройки кластера, манифесты всё, что мы делаем.


Мы как клиент хотим что-то создать, запустить приложение, и мы эту информацию передаем в API-сервер. Мы непосредственно это не делаем, конечно, там есть такая утилита, которая называется kubectl. С её помощью мы управляем всем кластером, делаем все операции, в том числе и запускаем приложения. Передаем yaml-манифест, где у нас в декларативном формате описано, как должно выглядеть приложение в кластере. Вот мы это передаем. Оно сохраняется в etcd и следующие компоненты постоянно смотрят в API-сервер.


Если немного углубиться, там есть подписка на событие и они по сути watch'ат. То есть никакого DDoS'а самого себя там нет. Следующий компонент, который берёт эту историю в работу это kube-controller-manager. По сути, мозг кластера Kubernetes. В него вшиты множество контроллеров: node-controller, endpoint-controller. Практически у всех абстракций, которые есть в Kubernetes, есть контроллер, и он вшит в этот бинарь. Эти контроллеры занимаются просто контролем вот этой абстракции: смотрят, есть ли новые, нужно ли что-то удалить и так далее.


Давай на примере. Если продолжать говорить о приложении, то контроллер, который отвечает за какое-то конкретное приложение, точнее за его манифест, за его абстракцию он видит, что мы что-то хотим создать, запустить. И он выполняет соответствующую работу, а именно дописывает манифест в etcd, обновляет информацию. Тут, конечно, без некоторого углубления нормально не объяснишь. Но есть такая абстракция, которая называется ReplicaSet. Она позволяет запускать приложение в нескольких инстансах. Через нее мы можем увеличивать, уменьшать количество реплик. И все здорово.


Это балансировка нагрузки?


Это просто контроль за количеством инстансов одного и того же приложения.


А зачем?


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


Ну это очень похоже на балансировку нагрузок.


Балансировкой уже занимается другая абстракция, которая уже трафик распределяет на вот эти три инстанса.


То есть они в принципе могут в паре работать?


Да. Они в паре и работают.


ReplicaSet не только создаёт реплики, она ещё и следит, чтобы их действительно было три. Причем не больше, не меньше.


Инстансы, которые запускает ReplicaSet, называются подами. В подах и работает наше приложение (про поды мы ещё поговорим).


И вот как раз, когда мы создаем, например, ReplicaSet, у нас есть такой ReplicaSet controller в этом контроллер-менеджере, который описание подов для ReplicaSet генерирует, и туда же, грубо говоря, в etcd через API-сервер скидывает.


Потом подключается следующий компонент. После того, как мы поняли, какое приложение нам нужно из скольких инстансов запускать, оно вот в etcd хранится этот манифест. Далее у нас идет такой компонент, который называется scheduler. Его роль достаточно проста. Он решает, на каких серверах это приложение надо запускать. Но делает это не просто так, у него есть свои алгоритмы принятия решения.


Ну в частности, он смотрит на ресурсы, то есть сколько ресурсов на ноде, если мы для этого приложения запрашиваем 1 ГБ ОЗУ, а на ноде только 512 свободны, он туда не отправляет.


Под приложением ты понимаешь Docker-контейнер с приложением?


Да, контейнер.


Контейнер с приложением каким-то.


Да.


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


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


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


Например, в кластере два окружения: продакшн и стейджинг. Конечно, продакшн более важен. И для них мы priority class выставляем высокий. Для стейджинга мы можем поставить поменьше. Когда происходит авария, Kubernetes понимает, что часть серверов отвалилась (за это будет отвечать Node Controller, который контролирует жизнь нод), он принимает решение, что надо те поды, которые там были, запустить в живых серверах. Scheduler будет запускать в первую очередь поды продакшена.


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


А если не хватит под продакшн места?


Если не хватит, ну сорян. Поды будут висеть в pending, то есть ждать, когда появятся ресурсы. И scheduler назначает Если на такой низкий уровень опуститься, то в манифесте пода есть специальное поле, которое называется nodeName имя ноды. И вот пока scheduler не принял решение оно пустое. Scheduler говорит, что вот этот под, вот это приложение нужно запускать там на Node 2, и он эту информацию передает, API-сервер это записывает в etcd и в это поле вносит это имя. А далее в работу вступает последний компонент всей этой схемы, который называется kubelet.


Kubelet это компонент своего рода "node agent", то есть агент, который запущен на всех серверах кластера. Он тоже постоянно в API-сервер смотрит. И он видит, что появился под, то есть приложение, у которого в поле имя сервера написано его имя, там, где он работает. Он такой: Ага! Значит его нужно у себя запустить! Он видит, что у него запущено, и что от него хотят. Он передает Docker API, из манифеста считывает, что там конкретно нужно запустить, и говорит Docker, какой контейнер нужно запустить.


Kubelet, получается, замена Docker демона?


Вот в том то и дело, что не замена, к сожалению. Поэтому вот эти альтернативы и изобретаются, поэтому туда люди идут, потому что Docker демон висит. Но по сути да, он общается с Docker демоном по API, но без него вполне можно было обойтись. Причем он не просто их запускает, он постоянно смотрит за статусом, и статус этот передаёт в API-сервер.


Хелс-чек такой?


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


Ноды это всегда сервер или это может быть кластер серверов?


Ноды это место, где запущен Kubelet.


Это может быть виртуалка, как я понимаю?


Да, может быть виртуалка.


Ты сказал, что в результате этих действий мы получаем физически развёрнутое приложение. Kubelet посылает какие-то свои статусы, либо он просто stdout контейнера фигачит? К чему этот вопрос. Потому что, если у тебя приложение в stdout выдает логи, какой-то дебаг kubernetes как-то умеет это в одно место собирать и предоставлять в удобочитаемом виде, или это не его обязанность вообще?


В твоем вопросе, два вопроса скрыты. Статус самого контейнера (жив или не жив) берёт из Docker. Функционал приложения (работает ли оно) вот эти дебаг, логи, какие-то хелс-чеки это все тоже делает Kubelet, но для этого надо несколько строчек в манифест добавить и сказать, как именно проверять.


На данный момент поддерживается три возможности проверять приложение:


  1. http-get это http-запрос в контейнер на инпоинт, и мы видим, работает оно, не работает, отвечает, не отвечает. С 200 по 399 код это ок, если 301 даже редирект это ок. Если 404 это не ок. 500 тем более.
  2. exec мы внутрь контейнера делаем какой-то запрос, какую-то команду, проваливаемся. Например, select 1, проверяем, всё ли нормально с базой.
  3. tcp socket Kubelet просто проверяет доступные сокеты. Если все хорошо, то все хорошо.

Есть три типа проверки контейнеров: это liveness, readiness и startup пробы.


Liveness проба это контроль за жизнью приложения. Постоянно Kubelet смотрит, ходит и смотрит. Там гибкие настройки, можно написать, как часто ходить, как проверять и так далее.


Readiness проба проверяет, а готово ли приложение принимать трафик. Потому что разные истории могут быть, это могут быть разные инпоинты у приложения. Мы проверяем, работает ли приложение, готово ли оно принимать трафик.


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


На каком размере архитектуры может работать Kubernetes? Может ли он контролировать сразу миллион инстансов?


Насколько я помню из документации, это 5000+, что ли, нод. На одной ноде по умолчанию можно запустить 110 подов, 110 экземпляров приложения.


Под это экземпляр одного и того же приложения? Или могут быть два разных контейнера на одном серваке и это будет два разных пода?


Под это абстракция, в которой запускается приложение. Тут важно понять, что это не какая-то физическая оболочка, не какой-то процесс ещё один, это скорее именно абстракция, с которой работает Kubernetes.


Kubernetes не умеет работать с контейнерами. Мы не можем сказать: заскейль нам вот это приложение в трёх контейнерах. Мы можем только сказать: заскейль нам в трех подах. В поде может быть как один контейнер, так и несколько. То есть мы можем туда запихнуть, например, nginx и php-fpm в связке, и они будут скейлится по два контейнера в связке.


Но тут надо понимать, что хорошая практика засовывать в контейнер неделимые части приложения. Всё-таки, если 2-3 контейнера надо засовывать, то может, стоит ещё поиграться с логикой приложения. Обычно один контейнер засовывают и там есть еще второй, который сам запускается, это pause контейнер, который держит сетевой namespace, чтобы все контейнеры в поде были в одном namespace, и чтобы всё хорошо работало.


Это первая часть беседы. Во второй будет про хранение данных в Kubernetes и про Ansible. Не пропустите!


Вопросы задавал Лекс АйТиБорода iamitbeard

Подробнее..

Путь DevOops-героя

20.11.2020 12:14:59 | Автор: admin

Soft skills крайне важны для DevOps-специалиста, потому что развитие DevOps в компании затрагивает не только используемые инструменты и технологии, но и взаимодействие сотрудников компании.


Антон Вайс, основатель Otomato Software, сравнил внедрение DevOps со строением мифов разных культур. Звучит фантастично, не правда ли? Но эта схема, как оказалось, отлично ложится на картину того, с чем сталкиваются многие DevOps-специалисты.



Далее текст будет вестись от лица Антона, а вы усаживайтесь удобнее, и добро пожаловать под кат.



Я начал свою карьеру в IT ровно 20 лет назад. Меня, молодого, неопытного, но подающего надежды программиста взяли писать на C в компанию, которая занималась разработкой поисковых механизмов.


Мой первый день на работе прошел достаточно символично. Мы сидели на одноэтажной вилле, пропитанной стартап-атмосферой. Меня познакомили с сотрудниками и рассказали про архитектуры системы. Сейчас инженеры на новом месте работы узнают, как работает кофемашина, но 20 лет назад их нигде не было, и вместо этого я пошел проверить, как работает туалет (что также немаловажно для инженерной мысли). Но когда я уже собрался выйти, я попытался открыть дверь и понял, что ручку заело. Как поступил бы любой другой инженер в моей ситуации, я приложил грубую физическую силу, из-за чего ручка двери отломилась и осталась в руке.


Что делать? Замок было не открыть, на работе еще никого не знал, и звать на помощь было неудобно. Поэтому я тихонько скреб дверь, и меня услышал сисадмин (благо серверная находилась рядом с туалетом). Он попытался открыть дверь снаружи, но замок застрял изнутри. Тогда админ меня проинструктировал, как разобрать жалюзи, чтобы вылезти через окно. Я был спасен и получил первый урок, как работают вещи в IT: когда программист застревает в туалете, то админы помогают им выбраться.


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


12 этапов путешествий DevOps-героя


Еще 70 лет назад американский исследователь мифологии Джозеф Кэмпбелл написал книгу Герой с тысячью лицами (к слову, она вдохновила Джорджа Лукаса на создание Звездных войн). Кэмпбелл, сравнив истории Будды, Иисуса, Мухаммеда, Гильгамеша и других божеств, пришел к выводу, что все эти мифы можно представить в виде истории судьбоносных путешествий архетипического героя, которые можно разложить на различные этапы. В первоначальной схеме было 18 этапов, затем голливудские сценаристы упростили схему до 12 этапов. Эти этапы настолько плотно впаяны в наш культурный код, что любую человеческую историю можно разложить на 12 этапов, в том числе DevOps-трансформацию.


Представим в виде диаграммы путь героя в большинстве известных нам источников:



Схема циклична, потому что конец каждого пути это начало нового витка. Чтобы стать настоящим DevOps-героем, индивиду и организации необходимо провести изменения по всем четырем измерениям:


  • люди;
  • процессы;
  • инструменты:
  • связывающее всех информационное пространство.

Обычный мир


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


Но в этом королевстве что-то прогнило, и мы услышали зов приключений зов DevOps.


Зов DevOps


В книге Руководство по DevOps от Джена Кима, Патрика Дебуа и других этот зов называют моментом ага моментом, когда мы понимаем, что в IT некоторые вещи работают достаточно плохо, и есть другой путь. Такой точкой может быть доклад на конференции, первый опыт работы в кроссфункциональной команде или попытка собрать пайплайн своими руками.


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


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


В 2017 году я помогал одной компании с подобной DevOps-трансформацией. Ситуация была удручающая, и мы наметили первые шаги и промежуточные цели. Но главный начальник отвел меня в секретную комнату за закрытой дверью и спросил, каких результатов следует ожидать, если их компания выполнит все рекомендации. Я начал говорить о творческом подходе, мотивации, инновациях, сплоченных командах, стабильности системы и скоростных методах доставки, однако начальник меня перебил и сказал, что он должен сократить расходы и понять, сколько инженеров можно уволить после внедрения DevOps.


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


Отказ от зова


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


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


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


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


Встреча с наставником


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


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


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


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


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


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


Четвертый вариант хорошо сочетается со всеми остальными книга, например Руководство по DevOps или Проект Феникс. Когда я был начальником интеграции в компании AT&T, на моем столе всегда лежала книга Непрерывное развертывание ПО Хамбла и Фарли, и во всех сложных ситуациях я обращался к первоисточнику за советом.


Мы заручились поддержкой наставника и наконец пересекаем порог.


Пересечение порога


Мы начинаем смотреть на обычный мир с обратной стороны, и приходит время строить DevOps. Мы горячо обсуждаем распил монолита на микросервисы, строим первые пайплайны, осваиваем Kubernetes, и кажется, что дороги назад уже нет. Но основные сложности новой дороги еще впереди.


Испытания, демоны и союзники


Герой сталкивается с первыми испытаниями, где его поджидают демоны:


  • сомнения;
  • страх ответственности;
  • вложение большого количества денег;
  • недостаток знаний;
  • борьба за власть;
  • нагромождение сложности;
  • бюрократизм.

Поначалу мы говорим, что распилим монолит, построим конвейер от кода до прода или же добавим по ops-у в каждую команду dev-ов. Но в процессе возникают более сложные вопросы:


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

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


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


Мы начинаем понимать, что DevOps касается не только отдельной организации, но и отрасли в целом, и мы ищем союзников уже в сообществе. Мы посещаем конференции (например, DevOops), митапы, вебинары и прочие тусовки, и приходим к мысли, что DevOps тесно связан с оперсорсом. Мы должны не только пользоваться наработками сообщества, но и возвращать ему фидбек и участвовать в попытке переосмысления отрасли: искать баги и писать код в инструменты, которыми пользуемся. Так мы приближаемся к сокровенной пещере.


Приближение к сокровенной пещере


Заручившись помощью союзников и прочитав полезную литературу, мы готовимся отвечать на самые важные вопросы:


  • языки программирования и фреймворки;
  • CI-сервер;
  • механизм деплоя;
  • базы данных;
  • очереди сообщений.

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


На этом этапе очень важно выстроить систему обмена знаниями и передачи корпоративной информации. Если ее не будет, то сложность нас погубит, и вся дальнейшая трансформация окажется обречена на провал. Именно из-за сложности придется нанимать, а не увольнять больше людей. Она постоянно возрастает и зависит не от нас, а DevOps-специалисты, в свою очередь, пытаются с ней справиться. Без прозрачной четко структурированной системы документации, планирования и обмена знаниями наша DevOps-трансформация грозит превратиться в гору YAML-пайплайнов, сшитых на коленке скриптов и зорко охраняющих и свирепеющих в процессе DevOps-инженеров.


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


Точка смерти


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


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


Первое явление называется падение занавеса. Неофилы все многократно обсуждали, подготовили и в какой-то момент поняли, что настоящая трансформация это не только инструмент или процесс, но и изменения сознания, организационной культуры и подхода к работе, больше автономии, возможностей брать инициативу и ответственность. Они приходят к начальству и выясняют, что начальство на такие крупные изменения не готово: сотрудники могут поменять инструменты, но система власти останется прежней. В результате неофилы либо увольняются, либо переживают сильный стресс и также увольняются. Итог остается тот же самый, потому что организации придется начинать сначала весь путь DevOps-героя.


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


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


Подарок силы


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


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

Когда мы получаем подарок силы, мы начинаем дорогу домой.


Дорога домой


После прохождения испытаний герой принимает решение сделать полученный опыт частью своей повседневной жизни. Будда становится учителем, Симба возвращается домой, чтобы стать царем зверей, а наша DevOps-организация встает на путь постоянных изменений. Теперь зеленые пастбища у нас, и другие неофилы стремятся перепрыгнуть уже на палубу нашего авианосца.


Сам Кэмпбелл в книге написал:


The trick in returning is to retain the wisdom gained on the quest, to integrate that wisdom into a human life, and then maybe figure out how to share the wisdom with the rest of the world.

Джозеф Кэмпбелл

Возрождение или Обретение мастерства


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


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


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


Возвращение с эликсиром (история силы)


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


В нашей DevOps-истории такой историей является вклад в open source, который показывает направление движения и действительно помогает людям в работе. Мы пишем блоги, в которых рассказываем, что и как мы сделали, как другим людям найти правильный подход к улучшению рабочих процессов и как проверить, почему не работает. Примерами таких историй являются SRE от Google, модель Spotify, Netflix OSS и другие.


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


Когда мы рассказываем свою историю, очень важно помнить, что она еще не закончена. Пройдя по пути героя, мы начинаем верить в свою правоту, и в этом кроется опасность мы перестаем развиваться и начинаем разлагаться. Настоящий DevOps-герой никогда не почивает на лаврах и напоминает Эрнесто Че Гевара, который, совершив революцию на Кубе, отправился в джунгли Конго.


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


Как сказал Антон, помочь DevOps-специалисту пройти путь героя сможет наставник, которым может быть как человек, так и книга или доклад. А со 2 по 5 декабря 2020 года JUG Ru Group проводит онлайн-конференцию DevOops 2020 Piter, где вы сможете перенять опыт коллег и улучшить процессы вокруг себя. Там же Антон представит свой новый доклад От стресса к прогрессу: Обзор непрерывной доставки на Кубер.
Подробнее..

Kafka в условиях повышенной нагрузки. Артём Выборнов (2017)

01.12.2020 10:20:26 | Автор: admin


Kafka распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.


Почему мы используем Kafka? Если коротко унификация. А если чуть подробнее десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы без единой высокопроизводительной шины данных с этим крайне сложно совладать.


Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.


Видео:



Доклад 2017 года. Версия Kafka 0.8.2. Сейчас реалии уже могут немного отличаться. Но основные концепции остались такие же.


Когда я кому-то говорю, что работаю в Rambler, люди отвечают довольно однотипно. Вторым по популярности ответом является: О, я знаю Rambler. Это поиск. На самом деле Rambler это уже давно не поиск. Мы сейчас конкурируем за пол процента аудитории с Bing и это вообще не интересно.



На этом графике более интересно то, что Google, наконец-то, обогнал Яндекс.


Какой, по вашему мнению, самый популярный ответ на то, что я работаю в Rambler? Самый популярный ответ: А Rambler еще жив?. На самом деле Rambler жив.


Сейчас Rambler Group это крупнейший в России интернет медиахолдинг. В него входят такие известные ресурсы, как: Rambler, Лента, Газета, Афиша, Чемпионат и много-много других. Аудитория составляет более 40 000 000 человек.


Преимущественно это медиаресурсы, на них заходят пользователи чтобы узнать новости, почитать статьи и это надо как-то монетизировать. Монетизируется это все за счет рекламы. Для того чтобы делать это наиболее эффективным образом, Rambler несколько лет назад создал подразделение рекламных технологий, в котором я и работаю.



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


Когда мы собрали информацию, то, что мы с ней делаем?


  • Мы занимаемся сегментацией аудитории. К примеру, классифицируем пользователей по полу, возрасту. Определяем пользовательские интересы. Например, какие люди интересуются автомобилем Ford или кто собирается поехать в отпуск в следующем месяце. Находим аудиторию, похожую на аудиторию какого-то более маленького сайта.
  • Мы прогнозируем трафик.
  • Предсказываем CTR.
  • Строим рекомендации.
  • Делаем аналитику.
  • И многое другое.

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



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



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



Данные мы храним в HDFS и обрабатываем с помощью Spark и Hive. После того как они обработаны, нужно полученной информацией поделиться с окружающим миром под это мы используем key-value базу Aerospike.



Вроде бы все хорошо, но на самом деле в этом подходе кроется много проблем:


  • Во-первых, это зоопарк. Добавление каждого нового партнера это часть решения абсолютно новой задачи как со стороны этого партнера (источника данных), так и со стороны нас (потребителя).
  • Во-вторых, worker здесь выглядит как один сервер. На самом деле это какой-то набор воркеров и каждый файл должен сначала пройти через одну из нод, где будет сохранен на диск, а потом уже выгружен в Hadoop. Worker это узкое место.
  • В-третьих, таким способом нельзя реализовать real-time pipeline обработки данных. Предположим какой-то партнер стал присылать данные микробатчами по одной минуте. Мы их забрали и сохранили на сервере, переложили в HDFS, на HDFS обработали, выгрузили в Aerospike. Если всё пройдет идеально, то получим задержки в десятки минут, ни о каком real-time речь уже не идет.


Что мы сделали? Все, что находится слева, выбросили и заменили на Kafka. Kafka это брокер сообщений для больших данных. Он не обладает такой крутой логикой доставки сообщений, как RabbitMQ, он более простой, но при этом он более производительный при большой нагрузке. В Kafka могут писать много поставщиков и из неё могут читать много потребителей.


Но данные из Kafka надо каким-то образом доставить до HDFS, для этого мы используем Gobblin.



Это решение от создателей Kafka компании LinkedIn. По сути это Map-Reduce задача, которая крутится на Hadoop и перекладывает данные из Kafka в HDFS.


В дополнение мы получили возможность приблизиться к real time.



Мы его реализуем с помощью Spark Streaming. Это такая задача на Spark, которая постоянно работает на кластере Hadoop (LLAP). От Kafka Spark Streaming откусывает микробатч информации, обрабатывает и складывает результат в key-value базу.


Самое главное преимущество такого подхода в том, что мы полностью минуем стадии записи и чтения из HDFS, все происходит в памяти. Мы с Kafka считали данные, обработали и положили результат в Aerospike.


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



Про что сегодня расскажу?


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


Для начала посмотрим, как устроена Kafka.


Kafka состоит из набора брокеров (каждый брокер это отдельная машина) и ZooKeeper для хранения метаданных. На самих брокерах хранятся сообщения. В Kafka пишут producers, из Kafka читают consumers.



Базовым элементом Kafka является поток сообщений. Он называется topic. Топик состоит из партиций.



Каждую партицию можно представить как array list. Это последовательность сообщений, где все сообщения по порядку пронумерованы, причем чем сообщение свежее, тем больше у него номер.



В партиции данные дописывает продюсер, в процессе записи сообщения шардируются.



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


Репликация в Kafka происходит с точностью до партиций. Репликация асинхронная: master-slave. Master в терминах Kafka называется лидер.



Consumers, producers всегда работают только с лидером, т. е. запись и чтение происходит только с лидера (master партиции). Затем данные с лидера aсинхронно доезжают до всех остальных реплик.



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


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



В документации по Kafka есть 2 вида переизбрания лидеров: это clean и unclean. С первого взгляда кажется, что unclean это какой-то плохой способ, и при нём теряем данные, а clean это хороший, и данные не теряем. Но на самом деле это не так. Единственное между ними различие размер этой дельты.



Если slave в момент переключения отставал от мастера больше, чем на заранее заданное число сообщений, то мы говорим, что это unclean, а если меньше, то говорим, что это clean.



Отсюда мы получаем важный инсайд при переизбрании лидеров мы всегда теряем данные.


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


Это грустно, а что же с этим делать?



Для этого пойдем дальше. Есть такой стандартный механизм в любой системе, в которую происходит запись данных -это возможность явно подтвердить факт успешной операции записи. Такая же функциональность есть и в Kafka.


Рассмотрим на примере. Если продюсер пишет в Kafka и этот параметр на продюсере был выставлен в ноль, то никакого подтверждения не будет получено.



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



Интересный момент. Если значение этого параметра -1, то Kafka вышлет подтверждение при успешной записи во все синхронные партиции. А что Kafka понимает под синхронными партициями конфигурируется отдельным ключом на самой Kafka. Для каждого топика можно задать число партиций, которые Kafka должна держать в in sync. Если в insync стоит 1, то это никак не отличается от предыдущего примера.



А если вы поставить insync.replicas = 2, тогда Kafka отправит продюсеру подтверждение, когда обе реплики будут успешно записаны.


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


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



Это довольно серьёзная проблема. Сейчас я опишу подход, к которому мы пришли, насколько он хорош уже вам решать. Мы держим для важных топиков insync.replicas = 2, а replication factor = 3. При таких настройках если у нас одна из insync реплик выпадет, то оставшаяся реплика за конечное время догонит лидера, и продюсер сможет продолжить запись в Kafka.



Одним из фундаментальных понятий Kafka являются отступы.


Как вы помните, партиция представляет собой набор пронумерованных сообщений. Отступ это номер какого-то сообщения. Среди отступов есть два особенных:


Latest offset это номер самого последнего добавленного в партицию сообщения.


Earliest offset это номер самого старого доступного сообщения.


Kafka хранит данные не все время, а за какой-то период, который вы задаёте в настройках, и в фоне удаляёт слишком старые данные. Поэтому earliest offset постоянно движется вперед. По сути, между earliest и latest offset, мы получаем окно, которое постоянно движется вперёд.



Предположим у нас ранее отработал consumer и зафетчил данные вплоть до какого-то отступа, т. е. данные от earliest offset до offset у нас уже были зафетчены и куда-то сохранены. При следующем запуске нашего consumer требуется забрать выделенный розовым кусочек данных с offset до latest offset и обновить отступы (то есть значение отступа до которого мы выкачали данные в предыдущую итерацию).


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



Для этого существует несколько способов, если вы выбираете consumer для Kafka это первое на что стоит обратить внимание.


Подход по умолчанию автоматическое сохранение. Но на самом деле он самый ненадёжный.


Как он работает? Consumer фетчит данные из Kafka. Kafka периодически до него стучится с целью проверить: жив он или не жив. Если он жив, то Kafka сохраняет соответствующий отступ.


В чем здесь проблема? Рассмотрим пример: consumer зафетчил данные, Kafka убедилась в том что он жив и сохранила отступ, а он, не успев записать данные на диск, упал. Мы получили потерю данных.


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



Следующий способ это сохранение вручную. Он работаем следующим образом: consumer фетчит данные из Kafka, после скачивания очередного батча, он явно отправляет следующее сообщение: Kafka, я этот кусочек данных успешно скачал, сохрани отступы. Выглядит надёжнее чем предыдущий способ, но это обеспечит только at least once семантику.


At least once это такая семантика, при которой мы данные не теряем, но могут быть дубли.


Почему такое может произойти? Рассмотрим аналогичную ситуацию: предположим, мы сохранили батч данных, но, когда consumer начал отправлять уведомление об этом Kafka, кто-то дернул kill -9 и consumer благополучно упал, не успев сообщить о том, что нужно было сохранить отступы. Получили дубли данных.


На самом деле эта семантика не такая плохая. Большинство pipeline по доставке данных работают как раз в at least once семантике с последующей дедупликацией.


Но мы гонимся за пресловутой семантикой exactly once. Как её обеспечить?



Единственный путь обеспечить exactly once на чтение это хранить данные и отступы вне Kafka. При этом сохранение данных и отступов должно быть атомарно. Если оно будет не атомарно, то мы можем получить аналогичную предыдущему примеру проблему: мы сохранили сколько-то данных, а отступы потерялись. И на следующей итерации мы повторно эти данные выкачаем.


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


Я вам расскажу решение этой проблемы от кампании LinkedIn. Оно используется в Gobblin для обеспечения exactly once семантики при фетче в HDFS.



Предположим, у нас отработал consumer и сохранил 2 файла с данными и файл с отступами в какую-то временную папку. Затем их надо переместить в production директорию. Важно отметить что move (mv) одного файла в Hadoop атомарный.


Это перемещение разбивается на набор атомарных операций и сonsumer пробует их по очереди выполнить.


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


Если у него это получилось значит мы закончили предыдущий fetch данных, правда в начале следующего fetchа. Если не получилось завершить, то вся необходимая информация для полного отката изменений также присутствует. Таким образом можно получить exactly once даже при сохранении в базах данных без транзакций.



Вроде бы все хорошо:


  • Producer получает ответ об успешной записи данных.
  • Kafka реплицирует данные и данные внутри себя не теряет.
  • Мы фетчим данные в HDFS с семантикой exactly once. Exactly once это семантика, когда мы забираем данные без потерь и без дублей.


Но у нас начались проблемы. Поговорим о том, как они проявили себя.


Во-первых, они начали проявляться в запаздывании логов. Большая часть pipeline это обработка дневных логов: мы накапливаем данные за день и затем (на следующий день) запускаем их обработку на Hadoop.


Если данные за вчера доезжают сразу после полуночи (в 1-2 ночи на слайде зеленая отметка), то все зависящие от них pipeline успешно отрабатывают.
Но если они доезжают с бОльшим опозданием, например, после обеда или тем более с опозданием на день, то у нас начинаются проблемы.
Мы не успеваем вовремя посчитать требуемые pipeline, метрики, аналитику и прочее. В общем, данные стали к нам приезжать с большИм опозданием.


Во-вторых, у нас появились дубли сообщений. Эта пресловутая семантика Exactly once, которой мы так дорожим, оказалась нарушена.



Кроме этого, мы заметили очень медленную работу consumers на микробатчах (в real-time пайплайнах): минутный батч данных из Kafka фетчился по 2-3 минуты.


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



Для последних двух проблем существовала общая причина: Kafka стала очень медленно отвечать на простейшие запросы по несколько минут. Точнее отдельные ноды Kafka стали очень медленно отвечать на эти запросы.


Если фетчить информацию большим батчем (к примеру раз в полчаса), то эти пару минут задержки будут просто не заметны. А если фетчить каждую минуту, то эти две минуты приведут к серьезной деградации pipeline.



Первым делом мы посмотрели в мониторинг и увидели, что нагрузка на чтение из Kafka выросла в 4 раза.


Нижняя красная линия это пиковая нагрузка до этих проблем. Верхняя красная линия нагрузка когда мы эти проблемы обнаружили. Желтый график это график на чтение.



А еще более интересную картину мы увидели, когда посмотрели на эту же информацию (нагрузка на чтение) в разрезе нод и увидели какую-то лапшу которую сложно разобрать.


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



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


  • Во-первых, Kafka неравномерно распределяла партиции по нодам.
  • Во-вторых, Kafka неравномерно распределяла лидеров по нодам.

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



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



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


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



Другой элемент решения совсем не очевиден повышаем репликацию. Хотя казалось бы: трафик на чтение увеличился в 4 раза, зачем его еще повышать допонительным чтением данных на репликацию?


Сейчас попытаюсь объяснить, почему это помогает. Вот снова наша гротескная ситуация:



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


Что делает Kafka в этом случае? По какому-то таймауту брокер не ответил, Kafka решает: Ему плохо, дай-ка я сниму нагрузку. И получаем следующее:



Весь трафик переезжает на другой брокер и плохо уже ему. Именно эту картину вы и видели ранее на графике нагрузки в разрезе по нодам.


А если бы у нас был фактор репликации, к примеру, 3, то мы бы могли увидеть после этого процесса следующую картину:



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


Все, что я описываю верно для Kafka 0.8.2, надеюсь, в новых релизах её сделали чуть умнее. Для всех старых версий эта проблема очень актуальна.



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


Мы уперлись в сеть. У нас часть нод в стойке оказались с uplink в 1 Gb. Это примерно 125 мегабайт в секунду. На графике у нас на ноду приходилось более 150 мегабайт в секунду. Понятное дело сеть была загружена.


Мы внезапно узнали, что Kafka не дружит с RAID 5. Почему внезапно? Основная причина документация читается в последний момент. Уже из практики мы узнали что RAID 5 хорошо работает с Kafka до первого сбоя. В момент, когда у вас на RAID 5 теряется блок данных и начинается восстановление, производительность Kafka сильно деградирует. Для Kafka рекомендуется использовать RAID 10.



По итогу мы поправили все описанные выше проблемы:


  • Самое главное, мы равномерно размазали всю нагрузку.
  • Разобрались с сетью.
  • Разобрались с дисками.
  • Kafka стала отвечать на базовые запросы за адекватное время вместо минут за секунды.

Но нагрузка осталась такой же высокой.



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


Корень этой проблемы заключался в следующем. Мы использовали батчевый consumer данных с Kafka Camus, это прародитель Gobblin.



Он сохраняет отступы для топиков в директорию под названием history. И из-за ошибки в конфиге отступы всех топиков стали попадать в одну папку. На слайде приведен фикс, исправляющий проблему.


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


Искомый фикс вкатили. Так было:



Так стало:



На слайде видим нагрузку на Kafka в нормальном режиме работы. Пиковый трафик упал в 4 раза, а периодические пики, которые вы видите, это запуск нашего consumer раз в полчаса. У нас на Hadoop работают задачи, которые каждые полчаса просыпаются, фетчат новые данные и обратно засыпают.



Немного цифр. К чему мы сейчас пришли?


Сейчас Kafka состоит из тех же 5 серверов, каждый день в нее записывается порядка 3 млрд событий. Это более 5 терабайт информации. Пиковая нагрузка на запись порядка гигабита.


Каждый день из Kafka вычитывается порядка 18 терабайт информации. И пиковая нагрузка порядка 5 гигабит. Это на 5 серверов.


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



На последок пара слов про мониторинг.


В первую очередь стоит мониторить узкие места:


  • Сеть
  • Диски
  • Распределение нагрузки

Вы должны за этим следить, Kafka может ошибаться, и ей будет требоваться ваша помощь.


Вот, к примеру, график распределения нагрузки по нодам, когда у вас все хорошо:



Здесь можно увидеть, что 4 ноды работают более-менее в унисон. Одна немного отстает, но это не критично. При этом на графике ближе к концу заметно, как Kafka сделала leader reelection, и баланс немножко изменился.



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



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


  • Число несинхронных партиций из тех, которые должны быть in sync
  • Максимальный лаг репликации

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



Что можно увидеть на этом графике? В целом все хорошо, лаг около нуля с отдельными пиками это нормальная ситуация. Стоит начать беспокоиться, когда у вас лаг стабильно больше нуля, т. е. ваша система не успевает вовремя реплицировать всю поступающую в нее информацию.



И, в-четвертых, время ответа на простейшие запросы. Это, наверное, самая главная метрика. Сама по себе она мало что значит, если только вы не хотите с помощью Kafka делать около real-time обработку данных. Но её повышение является очень важным симптомом проблем с вашей Kafka.


Здесь изображено время ответа на запросы consumerа:



И красной линией выделена отсечка в 10 секунд, которую мы нашли эмпирическим образом и сейчас используем в продакшн. Если Kafka отвечает дольше, чем за 10 секунд, кричим: Караул!.


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



В качестве итога:


  • Если вы хотите обеспечить exactly once семантику доставки данных на базе Kafka, то это возможно. Но вы должны обращать внимание на все элементы pipeline. Вы должны понимать как это работает и внимательно контролировать и producer'ы, и consumer'ы и саму Kafka. Когда у вас много поставщиков данных, то крайне сложно за всеми уследить и обеспечить exactly once для всех. Рекомендую придирчиво относится только к тем данным, где это действительно необходимо.


  • Нужно мониторить узкие места. В нашем случае при повышении нагрузки это оказались сеть, диски и баланс нагрузки по нодам.


  • Также стоит мониторить множество дополнительных метрик. Самая главная это время ответа Kafka на запросы, причем как продюсера, так и консьюмера. И бесспорно стоит мониторить классические метрики аля cpu, memory, etc.



По вопросам доклада можно обратиться к Артёму Выборнову

Подробнее..

Перевод Семь паттернов пайплайнов непрерывной поставки

23.11.2020 20:22:46 | Автор: admin

Перевод статьи подготовлен в преддверии старта курса "DevOps практики и инструменты".

Прямо сейчас у вас есть шанс успеть на курс по специальной цене. Узнать подробности.


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

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

Непрерывная поставка

Непрерывная поставка (Continuous Delivery) это "возможность надежно и быстро поставлять изменения всех типов в руки пользователей". Если посмотреть на непрерывную поставку по матрице Agile vs Effort, то можно увидеть, что она находится прямо между непрерывной интеграцией и непрерывным развертыванием. Часто их вместе называют CI / CD.

В отчете о состоянии DevOps за 2019 год более 31 000 респондентов сообщили об эффективности своих процессов разработки и поставки. Но разница между лидерами и отстающими ошеломляет. У лидеров в 200 раз больше развертываний и в 100 раз выше скорость развертывания, а также в 2 600 раз быстрее восстановление после инцидентов и в 7 раз меньше вероятность отката релизов.

Это исследование показывает, что для лидеров скорость и стабильность не противоположны! Вы можете получить и то и другое (на самом деле вам нужно и то и другое), чтобы получить реальные конкурентные преимущества для ваших цифровых продуктов и услуг.

Пайплайны

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

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

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

Паттерны пайплайнов

Паттерн 1 пайплайны как код

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

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

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

  • Для образов контейнеров сред сборки используются проверенные Docker-образы.

  • Конфигурация CI runner автоматизированная, одинаковая и не требует ручной настройки. CI runner при необходимости могут масштабироваться и находиться в режиме ожидания для минимизации задержек.

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

Паттерн 2 перенос логики в повторно используемые библиотеки

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

  • Относитесь к пайплайн-библиотекам как к любому другому программному обеспечению. У них есть собственные репозитории, пайплайны, модульные тесты и релизы.

  • По возможности для запуска внешних задач пайплайны используют специфичные для языка инструменты, такие как Make, Rake, npm, Maven и т.п. Для того чтобы упростить пайплайн и сохранить идентичность процесса локальной сборки и CI.

  • Библиотеки легко найти и у них хорошая документацию.

Паттерн 3 отдельные пайплайны для сборки и развертывания

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

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

  • Будьте независимы от окружения. При отсутствии пакетов, специфичных для окружения, и вынесения параметров в переменные окружения, одна и та же сборка может работать в любой среде.

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

Паттерн 4 запуск правильного пайплайна

Коммиты в ветки, пул реквесты и слияние с основной веткой всё это может инициировать различное поведение пайплайна, оптимизированное под конкретную команду.

  • Открытие pull request'а создает эфемерную среду для тестирования.

  • Слияния с основной веткой развертываются в не-продакшн или демо-среде, содержащей последний интегрированный код.

  • Создание новых тэгов приводит к выпуску релиза.

Паттерн 5 быстрая обратная связь

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

  • Пайплайны сборки используют распараллеливание для независимых друг от друга заданий с целью повышения производительности.

  • Быстрые пайплайны сборки выполняют необходимые задания за несколько минут.

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

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

Паттерн 6 стабильные внутренние релизы

Развертываются только версионнированные пакеты, созданные пайплайном сборки. Эти развертывания запускаются вручную или автоматически по событиям.

  • Каждая ветка кода получает полное эфемерное окружение, названное в соответствии с именем ветки, которое можно легко создать или уничтожить.

  • Любой инженер может создать или удалить эфемерную среду.

  • CI runners используют возможности cloud-native IAM с временными разрешениями, чтобы получить необходимые роли и разрешения для выполнения своей работы.

Паттерн 7 история релизов

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

  • "Релизный шлюз" (release gate) в виде кода и стандартизированные процессы релиза позволяют выпускать релизы по требованию.

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

  • Release gate может вызывать внешние API и использовать ответ, чтобы решить продолжать релиз или остановить его.

Проблемы

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

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

Итог

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

Посмотреть специальное предложение.

Читать ещё:

Подробнее..

Ультимативный гайд по собеседованию DevOps-инженеров что спрашивать и к чему готовиться

12.11.2020 20:10:42 | Автор: admin


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

Это когда никакого четкого алгоритма нет. Ты просто разговариваешь с человеком и что-то для себя понимаешь. Спрашиваешь, что кандидат делал на прошлой работе, цепляешься за тему и вот вы уже просто обсуждаете инженерные темы, примерно на том же уровне, что и с коллегами. Если беседа клеится и человек нравится, то все хорошо.

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

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


Сперва я быстро просматриваю все резюме


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

Мимо идут резюме, в которых указан опыт работы в госструктурах, что-то в духе администратор первого разряда в ЦБ РФ. Все эти многословные рассказы про администрирование информационных систем я отсекаю сразу без раздумий. Чем официозней и канцеляритнее описание прошлой работы, тем выше шанс, что ничего в своей жизни, кроме винды и бэкапов с помощью графического интерфейса, такой соискатель не видел.

В быстром отборе резюме помогает правило: чем больше технологий я встречаю, тем лучше. Если у человека в резюме написано MySQL, Linux, Postgres, Apache и так далее шансы есть. Человек по крайней мере слышал о технологиях и, кто знает, возможно, даже сам с ними работал. Хотя будем честны в резюме можно написать все, что угодно.

На собеседовании первым делом проверяю базу


Когда я стану немощным стариком и меня будет стремно бить в ответ, я начну колотить палкой по спине всех, кто не знает сети! Это маст хэв для любого инженера. Мы живем в мире, где все происходит в сетях. Даже в закрытом госсекторе найдется локальный контур. И там сидит разработчик, который пишет какой-нибудь proxy-сервис или сочиняет сервис, работающий с API-шкой, и ничего не понимает в API.

Я не требую особых знаний, я не прошу настроить мне MPLS. Но что такое маска подсети, что такое IP-адрес в 21 веке должны знать все IT-специалисты. Я понятия не имею, что у человека в голове происходит, когда он не понимает, что такое 127.0.0.1. Он сидит на локальной машине, у него запущен сервис на виртуалке. У сервиса прописан эндпоинт 127.0.0.1, коннект к базе. От незнания наш герой вхреначивает то же самое. Как результат: у меня не коннектится к базе. Конечно, блин, не коннектится!

Если у человека есть сертификат CCNA, окей, даже если он не сдавал его, не получал физически, но готовился мне достаточно этого факта за глаза.


Вот, например, стандартная задачка из CCNA, на понимание того, как работают сети


Есть два свича из разных сетей, между ними стоит роутер. Компьютер А хочет отправить данные в компьютер Б.

Что происходит в этот момент?
Мне важно услышать нечто в духе: Ага, смотрим таблицу маршрутизации, видим, что до этой сети можно попасть через роутер. Компьютер отправляет запрос в сеть, пытается найти, определить MAC-адрес по айпишнику у этого роутера, передает ему данные. Роутер видит, сетка подключена, отдает данные компьютеру Б. Компьютер Б принимает их, хеппи энд.



Затем я спрашиваю по всем уровням модели OSI


Слышал ли что-нибудь человек про Spanning Tree протокол? Про корневой протокол, про IP-уровень? Хорошо, а как это все работает? Понимает ли он, как происходит роутинг? Ну и скопом: таблицы маршрутизации, динамический протокол маршрутизации, транспортный уровень TCP. И так далее, и так далее.

Я хочу услышать, чем отличаются TCP и UDP. Хороший спец ответит мне, почему критичные системы (например, Domain Name System) используют протокол без гарантированной доставки сообщений (UDP).

Ответ простой так быстрее. Пока устраиваешь TCP-сессию, ты можешь 3 раза отправить UDP пакетик туда и получить его обратно. И никакого оверхеда.

Задаю вопросы про DNS


Какие бывают типы записи? Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.

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

Абсолютно везде сейчас используется HTTP-протокол, и я про него спрашиваю


Я начинаю со стандартных вопросов об отличиях http-версий 1.0, 1.1 и второй версии. Интересуюсь, что такое headers и зачем они нужны. Как веб-сервер понимает, что ему пришел запрос на определенный virtual host, а не на любой другой. И всегда задаю пару вопросов по Nginx.

Дальше плавно переключаю внимание на TLS-протокол


Как работает SSL\TLS? Инженеру нужно понимать это хотя бы на базовом уровне есть корневой центр сертификации, он подписал сертификат, и сертификат где-то используется.

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

Ответ под спойлером
Дело в том, что сначала устанавливается TLS-соединение, а потом уже следом идет HTTP-протокол, а веб-сервер может определить, к какому сайту обращается клиент только по HTTP-протоколу, по хедеру хоста. Nginx еще не знает, к какому сайту обратились, но он уже должен отдать сертификат клиенту. Есть расширения для TLS-протокола, которые позволяют клиенту передать хостнейм серверу, к которому он обращается при попытке установить TLS-соединение. И таким образом выбирать нужный сертификат. Когда этого расширения не было, на одном IP-шнике можно было держать только один сайт с включенным SSL.

Перехожу к Linux и BASH


Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.

Хорошо, если кандидат может немного скриптовать на BASH значит, он пробовал хоть как-то автоматизировать эту историю.

По Linux спрошу, как заменить в файле строчки другими строчками. Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.

Там всюду текстовые файлы, надо с ними правильно работать. Если соискатель предложит копировать их в эксельку и уже там что-то делать, то мне станет неловко.

Потом надо выяснить, как дела с виртуализацией


Обычная виртуализация, виртуализация через гипервизор. Если кандидат заводит разговор про паравиртуализацию значит, что-то знает.

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

Перемещаемся к контейнерам


Узнаю, работал ли собеседник с Docker? Собирал ли он образы, писал ли Docker-файлы, использовал ли Docker compose, деплоил ли с его помощью. Зачем вообще нужны эти контейнеры и как они работают? Поднимал ли наш соискатель систему оркестрации контейнеров Swarm или Kubernetes? Можно задать целый блок вопросов, но главное понять, делал человек работу своими руками с контейнерами или нет?

Спрашиваю про CI/CD deployment


Меня интересует огромный список вещей: как он настраивает автоматический deployment, как настраивает Continuous Integration? Как у него собираются приложения, использует ли он системы анализа кода (PVS-Studio, SonarQube). Как он пишет тесты или как интегрирует тесты, написанные разработчиками.

Делает ли он какое-то интеграционное тестирование этих сборок? Что дальше происходит с тем, что он собрал? Это как-то складывается в артфекаты или это упаковывается в docker-контейнеры, пушится в registry? Пусть расскажет, какие системы использовал для настройки CI/CD-процесса. Это могут быть и GitLab CI, и Circle CI, и какие-то облачные решения. А может быть, Jenkins, ну и про самописные скрипты на PowerShell не стоит забывать.

Скажи мне, как человек деплоит, и я все пойму. Он может деплоиться с помощью Helm в Kubernetes, Ansible, скриптами или чем-то еще самописным.

Про систему управления конфигурациями


Говорим чаще всего по Ansible. Поскольку его знают большинство. Итак, зачем нужны роли, как зашифровать и хранить секретные данные, как закидывать пароли на Git-репозиторий? И все в таком духе.

Узнаю про умение писать код


Разбираться в разработке важно, чтобы понимать, как взаимодействуют сервисы, зачем нужны API, протоколы аутентификации, авторизации. Славно, если кандидат что-то писал сам. Мне достаточно даже базовых скриптов на Python или Shell. Важен не код, а то, какие задачи хотел решить человек, чего хотел добиться.

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

Последние вопросы на собеседовании касаются хранилищ баз данных


SQL, NoSQL в чем различия, с чем работали? Чаще встречаю людей с опытом работы в PostgreSQL, реже MySQL. Задаю вопросы про индексы, может ли соискатель настроить реплику, может ли настроить логическую репликацию между табличками или просто данными. А что он будет мониторить в этом случае? А как ускорить базу?



Кстати, это хороший вопрос. Допустим, база сейчас сидит и упирается в диск. И с ней ничего не сделать больше сервер никто покупать не будет. Как сделать так, чтобы оно работало быстрее прямо сейчас?

Просто...
Просто: нужно выключить fsync, чтобы база не дожидалась записи с данных на диск, а как бы сохраняла. Linux может отдавать успешную запись, когда он к себе положил в буфер, а не когда на диск засинкал. Это немного костыльный режим работы, даже скорее опасный, рискованный. Питание вырубят в этот момент, и все навернется. Но зато этот метод ускоряет запись на порядок. Но не повторяйте и вообще никогда такого не делайте. И да, я вам этого не говорил.


Подытожу

  • сети
  • API-уровень
  • транспортный уровень TCP\UDP
  • протоколы DNS и HTTP
  • Linux
  • контейнерная и гипервизорная виртуализация
  • CI/CD
  • система управления конфигурациями
  • контейнеры
  • базы данных

Все это позволяет составить полную картину о человеке


Самое критичное в моем списке базовые знания. Не знаешь базу пора заканчивать собес.

Если человек не может мне ответить, что такое маска подсети, или не понимает, зачем нужны headers в HTTP в большинстве случаев такой соискатель получает наижирнейший минус в моей тетради. Разве тебе не любопытно было узнать, как работают все эти штуки, в которых ты тыкаешь курсором мышки?

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

Но вот, наконец, самый важный момент весь этот список нужен не для того, чтобы идти по нему на настоящем собеседовании. Этот список надо пройти самому перед тем, как нанимать людей.



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

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

Ну и по традиции, приглашаю присоединиться к нашему сообществу в телеге там регулярно разбираем все эти темы и многие другие, которые пригодятся и на собеседовании, и в работе.
Подробнее..

Перевод Управление алертами с помощью Alerta.io

13.11.2020 18:10:19 | Автор: admin

Привет, хабровчане. Скоро стартует курс "Мониторинг и логирование: Zabbix, Prometheus, ELK", и в его преддверии приглашаем вас записаться на открытый вебинар "Prometheus как новый виток систем мониторинга".

А пока делимся традиционным полезным переводом.


Alerta это очень простая система мониторинга, по крайней мере, таковой она выглядит для пользователя. С ее помощью можно в одном месте управлять алертами из нескольких источников. Она включает в себя API-сервер для получения, обработки и рендеринга алертов, веб-интерфейс и консольные утилиты. Она группирует алерты по различным атрибутам, таким как environment (окружение), service (сервис), event (событие) и resource (ресурс) и, оставляет хост-ориентированные инструменты мониторинга в 90-х.

Я пробовал ее использовать для System Alerts на брандмауэрах Palo Alto Network (PAN), см. репозиторий. Настройка PAN очень проста. В конечном итоге я получил на портале только десяток алертов, а не сотни и тысячи как в Monitor-> Systems. Это связано с их дедупликацией и корреляцией (по тегам, пользовательским атрибутам, окружениям, сервисам и др).

PAN-вебхук для настройки alertaPAN-вебхук для настройки alerta

Несмотря на то, что я предпочитаю смотреть алерты только в одном месте, для alerta.io я настроил плагины для Slack и MS Teams, создав там каналы для получения сообщений. Очередной канал в мессенджере не так плох, как отслеживание еще одного URL-адреса. Я даже не боялся отправлять туда информационные сообщения, чего обычно избегаю.

Alerta.io plugins: Slack (on left) and Teams (on right)Alerta.io plugins: Slack (on left) and Teams (on right)

Консольная утилита (которая также может запускаться с GUI в терминале или как Python SDK) очень полезна для быстрого просмотра состояния, запросов, пульса (heartbeat) и обслуживания.

$ alerta statusMETRIC                       TYPE    NAME                       VALUE      AVERAGE---------------------------  ------  -------------------------  -------  ---------Total alerts                 gauge   alerts.total               21Received alerts              timer   alerts.received            898       30.853Count alerts                 timer   alerts.counts              1310       4.59695Alert queries                timer   alerts.queries             2627      36.0689Alerta console auto-refresh  text    switch.auto-refresh-allow  ONAPI alert submission         text    switch.sender-api-allow    ON

Важно помнить, что это ни в коем случае не "еще один инструмент мониторинга", а лишь способ уменьшить большое количество алертов и агрегировать их из нескольких систем мониторинга, таких как Zabbix, Nagios или Sensu.

Согласно документации, алерты при получении можно дополнительно обработать с помощью хуков (pre-receive hooks), добавляя в них информацию или отклоняя их. А также можно инициировать запуск действий в других системах с помощью post-receive хуков или действий оператора или при изменении статуса алерта для двунаправленной интеграции. Например, алерты можно нормализовать для гарантии того, что у всех у них будут необходимые атрибуты и теги или что они принимают значение из допустимого диапазона. Это можно увидеть в плагине reject, который обрабатывает политику алертов.

Плагины также могут использоваться для обогащения алертов дополнительной информацией. Например, плагин геолокации (Geo location plugin) на основе IP-адреса клиента добавляет к алерту данные о местоположении. А универсальный плагин (generic enhance plugin) добавляет пользовательский атрибут на основе информации, содержащейся в алерте.

Записаться на открытый урок.

Подробнее..

Recovery mode DevOps amp SRE Hiring Day оффер в DINS за один день

19.11.2020 12:06:35 | Автор: admin
image

Привет, Хабр! 11 декабря мы проводим Hiring Day это возможность для DevOps и SR-инженеров получить предложение о работе всего за один день. Ищем коллег, которые будут вместе с нами работать над UCaaS-платформой для бизнес-коммуникаций. В проекте вас ждет сложная архитектура, современные технологии, международная команда профессионалов.


Читайте подробности под катом и присоединяйтесь!


Что делаем в DINS


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


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


Кого ищем


  • DevOps-инженеров (Middle/Senior): вам предстоит активно участвовать в проекте на этапах проектирования, разработки, тестирования, деплоймента и сопровождения.
  • Site Reliability Engineer (Middle/Senior): вы будете участвовать в разработке архитектуры продукта с упором на высокую доступность и масштабируемость, готовить компоненты и сервисы к продакшну и отвечать за их стабильную работу в AWS и приватном облаке.

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


Зачем участвовать в Hiring Day


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


Вот еще несколько причин присоединиться к команде:


  • Сейчас работаем удаленно, но в Петербурге у нас два офиса, и новым коллегам поможем переехать: выделим Relocation Bonus, подскажем, как найти жилье.
  • Сотрудникам оформляется ДМС со стоматологией, полагаются ежегодные премии и индексация зарплаты.
  • У нас много возможностей для обучения: курсы английского языка, внутренние и внешние тренинги по soft и hard skills.
  • Несмотря на удаленку скучать не приходится: ходим на онлайн-конференции, проводим регулярные корпоративы, делаем квартирники, играем в онлайн-квесты.

Как устроен Hiring Day


  1. Отправьте заявку на сайте мероприятия, и в течении трех рабочих дней координатор свяжется с вами, чтобы назначить дату собеседования.
  2. Подключитесь к онлайн-собеседованиями с нашей командой. Они пройдут 11 декабря и займут до 3-х часов.
  3. В конце дня мы дадим обратную связь или сделаем оффер.

Если вы готовы к карьерным переменам ждем вашу заявку на сайте.

Подробнее..

Как перейти от кровавого энтерпрайза к командной работе

01.12.2020 10:20:26 | Автор: admin

Сергей Минаев руководитель направления администрирования Sportmaster Lab. Занимается поддержкой окружений и всем, что связано с работой кода. Он участвует в IT-трансформации компании, и в своем докладе на конференции DevOps Live 2020 рассказал о том, как это происходит.

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

Стараемся применять современный подход: у нас есть автоматизация, мы понимаем где и когда использовать Ansible. Есть CI/CD на Bamboo и BitBucket. Есть оркестрация на основе Mesos, но мы двигаемся в сторону Kubernetes (и поглядываем на GitOps).

Наши проблемы

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

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

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

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

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

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

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

DevOps: ожидания vs реальность

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

Но на деле выходит иначе.

Что такое DevOps, и для чего он нужен обычно не объясняют. DevOps воспринимается как системный администратор, который умеет и админить, и программировать, и еще много что делать. Причем, за одну зарплату. И в лучшем случае продуктовая команда не теряет в производительности и качестве.

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

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

Мы стремимся к надежности, безопасности и воспроизводимости. Мы всегда можем повторить то, что делали. Понимаем, как оно повторяется, и если что-то пошло не так, это безопасно для нас, ведь мы можем спокойно откатиться назад.

Кроме того, изменения невозможны без быстрой связи, без общих каналов и без обмена опытом. Нельзя просто сказать: Ты, Ваня, приходи в команду, помогай с такими-то технологиями. Это так не работает. Инженер не приходит мыть полы и менять картриджи. Он обучает команду и помогает ей. И люди в команде должны понимать, что и почему он делает. Но и инженеру нужно знать и понимать для чего он тратит свои силы.

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

Как внедрять DevOps?

Нужно не забывать о том, что DevOps дело добровольное, его нельзя навязать.

Если продуктовая команда выбирает себе инструменты сама, в этом вроде бы нет ничего плохого. Но о выборе подходящих инструментов должно быть известно за ее пределами. Вы не можете просто поставить Kubernetes и сказать всем ура, у нас Kubernetes, работаем. Это не просто софт, это платформа, вопрос экосистемы, деплоев. Kubernetes добавляет много вопросов, на которые не всегда можно быстро ответить.

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

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

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

Гибкость. Нужна во всем. DevOps не может быть гибким только с одной стороны. Если так работают только инженеры/команды, а бухгалтерия не может, то получится, что команды будут ждать новых серверов долгое время.

Облака. Полезны для скорости, если внутри организации долгий процесс предоставления ресурсов. Например, для MVP проще развернуть ресурсы в облаке в пару кликов, чем ждать выделения локальных ресурсов.

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

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

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

Технологии и инструменты

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

Мы понимаем, что Kubernetes это решение не во всем и не всегда. Kubernetes для нас не просто платформа. Этоцелая экосистема. Можно сказать, что в какой-то степени речь идет о фреймворке.

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

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

Выводы

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

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

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

DevOps не всегда нужен, и занявшись его внедрением, можно сделать хуже. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.

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

3 декабря будет митапБезопасность и надёжность в финтехе. Спикеров будет несколько, и они поднимут несколько тем. Сначала будет разговор о закулисье финтеха, затем как и какими инструментами сделать финтех надежным сервисом, и на закуску как снизить риски ИБ в разработке финансовых систем. Начнем в 17:00.

А 7 декабря в 16:00 вас ждет митап Stateful-приложения в 2020 году. Поговорим о Stateful в 2020. Сейчас много всяких методологий, подходов и новых принципов работы. Но они больше ложатся на stateless. А что в это время происходит с БД? Как жить и поступать с ними сейчас, в 2020 году? И какие перспективы и тренды нас ждут?

Следите за новостями Telegram,Twitter,VKиFBи присоединяйтесь к обсуждениям.

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru