DevOps *

Делимся историей 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) в корпоративном блоге.

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

При внедрении DevOps-процесса в компании одним из возможных вариантов хранилища артефактов сборки может стать rpm-репозиторий. По существу — это просто веб-сервер, раздающий определённым образом организованное содержимое. Есть, конечно, коммерческие варианты maven-репозиториев, которые имеют плагины для поддержки rpm, но мы же не ищем лёгких путей?

Задача

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

Cloud Fabric: как SDN помогает IT более гибко реагировать на изменения

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

• Гибкость: высокая масштабируемость облачных сервисов и каналы для передачи больших данных (Big Data).
• Упрощение процессов: облачное решение для сети Huawei в 10 раз ускоряет активацию облачных сервисов.
• Открытость: упрощение облачных вычислений за счет бесшовного подключения к основным облачным платформам.

SDN-решение Cloud Fabric содержит два основных компонента: серию коммутаторов для ЦОД Huawei CloudEngine и Agile Controller.

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

Docker Compose обладает целым рядом нетривиальных способов применения, которые мы рассмотрим в этой заметке. Это очередной перевод статьи, которую мы разбирали при подготовке материалов нашего курса Python для Web-разработки.

Контроль порядка запуска

Docker Compose запускает контейнеры в порядке зависимостей, используя опцию depends_on, чтобы указывать, когда запускается сервис. Для определения порядка запуска Compose применяет depends_on, links, volumes_from и network_mode: «service: ...».

Если контейнер должен дождаться состояния “ready” другого контейнера, можно использовать инструменты wait-for-it или dockerize. Они будут проверять хосты и порты до тех пор, пока TCP соединение не будет подтверждено. Для включения принудительного ожидания в композицию необходимо добавить entrypoint:

version: '2'

services:
    web:
        build: .
        ports:
            - "80:8000"
        depends_on:
            - db
        entrypoint: "./wait-for-it.sh db:5432"
    db:
        image: postgres

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