DevOps *

Каждый год появляется столько новых технологий (таких как Kubernetes или Habitat), что легко забыть о тех инструментах, которые тихо и незаметно поддерживают наши системы в промышленной эксплуатации. Одним из таких инструментов, который мы используем в Stripe на протяжении нескольких лет, является Consul. Consul помогает в обнаружении сервисов (то есть помогает находить тысячи работающих у нас серверов с запущенными на них тысячами различных сервисов и сообщать, какие из них доступны для использования). Это эффективное и практичное архитектурное решение не было чем-то совсем новым и особенно заметным, но оно верой и правдой служит делу предоставления надежных сервисов нашим пользователям по всему миру.

В этой статье мы собираемся поговорить о следующем:

• Что такое обнаружение сервисов и Consul.
• Как мы управляли рисками, возникавшими при внедрении критически важного программного продукта.
• Вызовы, с которыми мы столкнулись, и наши ответы на эти вызовы.

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Здравствуйте! О разработке chef кукбуков и связанной с ней инфраструктурой написано немало, да и инструментов в этой области существует уже предостаточно. Среди них можно перечислить такие решения как vagrant, test kitchen, food critic, chef spec, minitest-chef-handler, serverspec, inspec. Все они, в той или иной степени упрощают и ускоряют промышленную разработку и тестирование chef кукбуков и настраиваемой ими инфраструктуры.

Если данная область близка для вас и вы так же имеет некоторое отношение к языку Perl ( точнее к Perl6 ) — то добро пожаловать в топик.

Итак, сегодня я расскажу как я использую Sparrowdo при разработке и тестировании chef кукбуков.

Антон Турецкий (Badoo)

“Не трудности “ломают” вас, а то, как вы их переносите” —  Lou Holtz

В соавторстве с Emmet O’Grady (основателем NimbleCI и Docker Ninja)

В книге Франца Кафки “Превращение” (“Метаморфозы”) человек просыпается однажды утром и обнаруживает, что он превратился в гигантское насекомоподобное существо. Как у инженеров DevOps, у нас есть такие же сюрреалистические моменты в жизни. Мы находим экзотические ошибки “под ковриком” (скрытые в самых труднодоступных местах) или бываем атакованы червями либо другими опасными сущностями. Если вы занимаетесь этим достаточно долго, у вас рано или поздно появится ужасная история, или даже две (поделитесь ими с нами!). В такой момент мы не можем сидеть и ждать, когда наступит кризис, мы должны действовать быстро. Торопясь исправить это как можно раньше, мы должны развернуть (deploy) новую сущность и выпустить новую версию нашего сервиса, устраняя проблему.

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

В кассандре достаточно информативное логгирование (особенно на уровне DEBUG, который можно включить на лету), подробные метрики, доступные через JMX и богатый набор утилит (nodetool, sstable*).

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

Я и мои коллеги всегда склоняем своих клиентов полностью автоматизировать процесс деплоя. Автоматизация помогает сократить количество конфликтов и задержек, которые возникают в процессе между "завершением" работы над программой и введением в эксплуатацию. Дэйв Фарли (Dave Farley) и Джез Хамбл (Jez Humble) заканчивают книгу "Непрерывная доставка" (Continuous Delivery) на эту тему. Она основывается на множестве идей, которые в целом связаны с непрерывной интеграцией и подталкивают к возможности быстро пустить софт в работу. Глава о сине-зеленом деплое привлекла мое внимание, потому что это один из малоиспользуемых методов, и я решил кратко его осветить.

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

Я расскажу, как достаточно простые метрики TCP/IP стека могут помочь разобраться с различными проблемами в распределенных системах.

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

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

В марте 2016 года компания Cisco представила новую архитектуру для корпоративных сетей – Cisco Digital Network Architecture или Архитектура цифровых сетей Cisco. Что представляет собой новая архитектура? Какие ее основные особенности и отличия? Какие задачи решает и какими преимуществами обладает? На эти и многие другие вопросы будут даны ответы в этой статье.

Рис 1. – Архитектура Cisco Digital Network Architecture — Cisco DNA

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

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

• Ubuntu
• Debian
• CentOS 6/7 + atomic
• Fedora + atomic
• CoreOS

Частично:

• FreeBSD (требуется ручная настройка сети и ssh ключей)
• openSUSE (требуется ручная настройка сети и ssh ключей)
• Windows (в консоль не попадёшь, но при помощи virt-manager можно пользоваться графическим интерфейсом)

Публикации поспособствовал коллега, который случайно увидел, как я тестирую код. А теперь о преимуществах перед Vagrant. Первое преимущество — время. Например, три виртуальные машины создаются всего за 20-30 секунд.