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