DevOps *

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

Заглянуть «по ту сторону» аналитики и мониторинга нам помог Сергей Шарапов – системный аналитик Mail.ru. У него богатый опыт работы в Одноклассниках, начиная с настройки серверного и сетевого оборудования, вплоть до выстраивания бизнес-процессов для HR.



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

Про DevOps не рассказывает только ленивый. Некоторые компании внедряют эти практики, а подавляющее большинство присматривается в поисках next big thing или «серебряной пули», ну или просто поддавшись тенденции в ИТ-сообществе. Уникальность каждого случая, поиск собственного пути, опасения сделать хуже (принцип Гиппократа «не навреди») — всё это не способствует ускорению внедрения, лишь добавляя ступеньки на пути к совершенству ИТ. Мы хотим рассказать про свой путь, извилистый и пока не пройденный до конца.

Цикл статей о крупных и успешных пользователях Kubernetes продолжается рассказом про популярный онлайн-сервис для распространения аудиоконтента — SoundCloud. В прошлом году эту компанию собиралась купить Spotify AB (имеет шведские корни, как и SoundCloud), а совсем недавно — китайский интернет-гигант Tencent. Даже обслуживая ~175 миллионов активных пользователей в месяц, SoundCloud в последнее время испытывает финансовые проблемы, о чём стало известно благодаря крупному сокращению (173 сотрудников) минувшим летом, однако, если верить последним данным, ситуация наладилась. Так или иначе, куда больше нас интересует технологическая сторона вопроса, а точнее — применение Kubernetes, и вот что известно о SoundCloud из публичных источников…

Делимся историей DevOps со слов Деймона Эдвардса, разработчика и одного из организаторов DevOpsDays в США. Смотрите 10-минутное видео на английском по ссылке или читайте наш перевод под катом.

Можно бесконечно спорить о понятии «DevOps» — вроде и вакансии есть, и должности, и инструкции, и KPI… Вот только я по-прежнему постоянно вижу совершенно разное восприятие этого понятия между бизнесом, админами и разработчиками. Первые воспринимают DevOps как методологию, вторые — как набор инструментов для автоматизации рутины, а третьи — как набор инструментов для деплоя. В чем-то правы все.

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

Прим. перев.: Эта статья, написанная сетевым инженером из Швеции, рассказывает о некоторых нюансах работы с шаблонами в Ansible, а главное — учит одному простому и очевидному правилу, помогающему не «выстрелить себе в ногу»… причём не только в ногу и даже не только свою, когда речь идёт об автоматизированном управлении большим множеством устройств/серверов. Описанный в ней пример будет полезен каждому системному администратору и DevOps-инженеру. (Выделения в тексте не являются авторскими — они сделаны при переводе для акцентирования внимания на нескольких моментах.)



Я не только пользуюсь Ansible, но и пишу о нём, и пытаюсь помочь другим понять, как он работает. Недавно отвечал на вопросы пользователей Ansible. Один из них не понимал, почему модуль ios_config некорректно применял его шаблон. Объяснив, что не так с этим шаблоном, и размышляя об этой проблеме дальше, я осознал, что подобная ошибка может быть по-настоящему опасной. Опасной настолько, что может привести вашу инфраструктуру к нерабочему состоянию.

Можно бесконечно спорить о понятии «devops» — а можно один раз сходить на конференцию и составить общую картину по выступлениям разных людей. А если вам на самом деле и не хочется прекращать спорить, то как раз там будет с кем это сделать!

Ранее мы уже анонсировали конференцию DevOops и публиковали интервью с её программным комитетом. А теперь, когда до конференции осталось две недели и программа сформирована, настало время поговорить о конкретных докладах. Что будет ждать зрителей в Петербурге 20 октября? Многое, от нюансов Kubernetes до греческой трагедии. Вот список тем, а под катом расписаны соответствующие им доклады:

• Kubernetes
• Мониторинг и аудит приложений
• Continuous Delivery
• Configuration Management
• Облака
• DevOps в целом
• Барух Садогурский

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

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

Если вы пропустили слет DevOps-инженеров «Орки тут» в Яндекс.Деньгах, но интересуетесь вопросами контейнеризации и оркестрации – мы сделали записи всех четырех докладов.

Специалисты из Яндекса, Альфа-Лаборатории, компаний Zvooq и Badoo рассказывают про опыт работы с системами оркестрации и сложные моменты.

Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 10 лет работы в IT моё отношение к мониторингу прошло через три стадии:

Отрицание. Ничего не мониторить, пользователи сами сообщат, когда у них возникнут проблемы.
Гнев. Мониторить всё, что можно и нельзя, оповещать всех, включая не очень заинтересованных лиц, что на веб-сервере в течение 30 секунд нагрузка на CPU была 95%.
Смирение. Бизнесу пофиг на процессор/память/диски. Его больше интересует, лучше или хуже стало после изменений в инфраструктуре. Надо работать на упреждение.

Под катом — подробности эволюции моего отношения.

Неделю назад разработчики Rancher представили предварительный релиз своей будущей крупной версии — 2.0, — попутно объявив о переходе на Kubernetes в качестве единой основы для оркестровки контейнеров. Что побудило разработчиков пойти таким путём?

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

В Docker уже встроено несколько замечательных средств обеспечения безопасности:

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

  
  

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

  
  

• Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).

  
  
• Docker-контейнеры воспроизводимы. Благодаря их декларативной системе сборки любой администратор может легко выяснить, из чего и как был сделан контейнер. Крайне маловероятно, что у вас в итоге окажется неизвестно кем настроенная legacy-система, которую никому не хочется конфигурировать заново. Знакомо, не правда ли? ;)

Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.

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

Ловите 2 плаката с регулярными выражениями в форматах A2 и A3.

Плакаты просто идеальные, потому что красивые и полезные сразу. Распечатайте, повесьте, любуйтесь и пользуйтесь.

Всем привет. В данной статье хочу поделиться знаниями, полученными в процессе автоматизации развертывания наших сервисов на различные серверы в разных дата-центрах.

Задача была следующей: есть определенный набор скриптов для развертывания сервисов, которые нужно запускать на каждом сервере каждого дата-центра. Скрипты выполняют серию операций: проверка статуса, вывод из-под load balancer’а, выпуск версии, развертывание, проверка статуса, отправка уведомлений через email и Slack и т.д. Это просто и удобно, но с ростом числа дата-центров и сервисов процесс выкатки новой версии может занять целый день. Кроме того, за некоторые действия отвечают отдельные команды, например, настройка load balancer’а. Также хотелось, чтобы управляющий процессом код хранился в общедоступном репозитории, дабы каждый член команды мог его поддерживать.

Решить задачу удалось с помощью Jenkins Pipeline Shared Libraries: этапы процесса разделились визуально на логические части, код хранится в репозитории, а осуществить доставку на 20 серверов стало возможно в один клик. Ниже приведен пример подобного тестового проекта:



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

Работа с Docker в консоли — привычная для многих рутина. Тем не менее, бывают случаи, когда GUI-/веб-интерфейс может оказаться полезным даже для них. В статье представлен обзор наиболее заметных на сегодняшний день решений, авторы которых попытались предложить более удобные (или подходящие для каких-то случаев) интерфейсы для знакомства с Docker или даже обслуживания больших его инсталляций. Некоторые из проектов совсем молоды, а иные — наоборот, уже отмирают…

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

За небольшой промежуток времени DevOps в Программе «Единая фронтальная система» (ЕФС) прошел огромный путь, охватив ежедневную практику всех команд. Но интенсивные работы по развитию DevOps продолжаются, и в недалеком будущем жизненный цикл ЕФС претерпит новые изменения, направленные на ускорение ввода в эксплуатацию программного обеспечения (continuous delivery) и улучшения его качества (сквозное автотестирование). Но об этом чуть позже, а пока немного истории.

Некоторое время назад я восхитился от команды Facebook-а, запилившей для целей мониторинга специальную базу — RocksDB. При внимательном рассмотрении оказалось, что оно форк более раннего гугловского проекта, оно архивирует данные налету и оно, будучи «в душе» NoSQL, стыкуется к MySQL как storage engine.

Дальше прилетела новость, что MariaDB включили этот движок в upstream с версии 10.2. Ништяки вроде архивирования на лету и ttl на отдельные строки под капотом так и манили попробовать это на чем-то подходящем…

Подходящим генератором данных в моем хозяйстве оказался zabbix, который к тому же решили перетянуть на новое железо. Но «из коробки» zabbix про rocksdb не в курсе, так что пришлось пошаманить и потестировать. Если интересны результаты и выводы —

Прим. перев.: kube-spawn — достаточно новый (анонсированный в августе) Open Source-проект, созданный в немецкой компании Kinvolk для локального запуска Kubernetes-кластеров. Он написан на Go, работает с Kubernetes версий 1.7.0+, использует возможности kubeadm и systemd-nspawn, ориентирован только на операционную систему GNU/Linux. В отличие от Minikube, он не запускает виртуальную машину для Kubernetes, а значит, что overhead будет минимальным и все процессы, запущенные внутри контейнеров, видны на хост-машине (в т.ч. и через top/htop). Представленная ниже статья — анонс этой утилиты, опубликованный одним из сотрудников компании (Chris Kühl) в корпоративном блоге.