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

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

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

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

Этот пост — расшифровка моего выступления с нашей секции на РИТ++. Многие просили нас сделать текстовые версии докладов оттуда. Если вы были на конференции или смотрели видео, то не найдете ничего нового. А всем остальным — добро пожаловать под кат. Расскажу, как мы пришли к такой системе, как она работает и как мы планируем её обновлять.

Дэймон Эдвардс / 8 ноября, 2010

С того момента как Патрик Дебуа организовал первую конференцию DevOps Days и явил миру термин “DevOps” не может быть сомнений, что DevOps развился до уровня глобального движения.

Безусловно, DevOps движение имеет своих хулителей. Негативные мнения варьируются от ошибочных («DevOps — это новое название для сисадминов») и пренебрежительных («DevOps — это просто какие-то безумные разработчики (Devs), которые пытаются избавиться от админов (Ops)» или «DevOps — это какие-то безумные админы, которые хотят казаться разработчиками, чтобы их больше любили») до выражений обиды (как правило, с аргументами, не поддающимися логике).

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

DevOps это не проблема технологий.

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

Какое отношение бизнес имеет к DevOps?
Основополагающий бизнес-процесс в любой компании — взять идею от момента ее рождения в голове и донести ее туда, где она будет приносить деньги.

Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

Нас тут частенько обвиняют в том, что мы пишем рекламные статьи, цель которых “опять пропиарить свои курсы”. Поэтому сегодня мы не будем говорить о том, что скоро стартанет курс “DevOps практики и инструменты” — нет.

Сегодня мы хотим поделиться с вами методом розыгрыша, который придумали наши преподаватели — инженеры компании Экспресс 42. Статьи про методы розыгрыша, как показывает статистика, тоже не все любят читать, но ирония судьбы (на последнем розыгрыше мест на курсе “WEB разработчик” оба победителя — читатели Хабра) просто требует, чтобы мы продолжали писать :)

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

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

Продолжаем рассказывать на примере известных компаний о том, что Kubernetes в production — это не только мечты и надежды. Эта статья — снова про технарей с мировым именем: SAP и её конвергентное облако на базе OpenStack и Kubernetes. Однако начнём с менее известной Concur и вот почему…

Docker замечательно справляется с изолированием приложений и их окружений, облегчая распространение и репликацию состояний между различными средами (dev, test, beta, prod и т. д.). Его использование позволяет избавиться от проблемы «на моей машине все работает» и помогает с легкостью масштабировать приложение по мере его роста.

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

В этой статье мы возьмем простое приложение на Rails и подготовим его для использования в Docker-контейнере («докеризуем»).

Немного текста про поддержку IPv6 в докере и ещё кой-какие нюансы docker networking.

IPv4

Для разминки рассмотрим обычную IPv4-only систему. На хост-машине есть интерфейс eth0. К этому интерфейсу привязан внешний IP-адрес. Ещё есть loopback интерфейс. Когда на такую машину мы устанавливаем docker, он создаёт себе дефолтную сеть с названием bridge. Для этой сети на хост-машине создается еще один интерфейс docker0. У него тоже появляется ip адрес, например, 172.17.0.1. Когда мы запускаем контейнер, докер выделяет контейнеру адрес из выбранной сети (bridge по умолчанию). Например, 172.17.0.5. Внутри контейнера появляется интерфейс eth0 и на нём адрес 172.17.0.5. Итак, с адресами базово разобрались. Теперь попробуем понять, как процесс внутри контейнера может обращаться к внешним ресурсам и как сделать так, чтобы можно было снаружи сходить в контейнер.

Пару месяцев назад мы переехали из Амазон на свои выделенные сервера(Hetzner), одна из причин тому была высокая стоимость RDS. Встала задача настроить и запустить master-slave кластер на выделенных серверах. После гугления и прочтения официальной документации, было принято решение собрать свое собственное решение высокодоступного асинхронного кластера Postgres.

В конце прошлого года два капитана Docker представили свою разработку под названием Play with Docker (PWD) — «игровую площадку для Docker». Пользователям предлагается бесплатно поработать со сборкой и запуском Docker-контейнеров прямо в веб-браузере, а также выполнить лабораторные работы для знакомства с Docker с нуля и совершенствования своих навыков.

А вы знали, что при помощи Raspberry Pi можно следить за опознанными летающими объектами? Вы можете настроиться на радио-сигналы самолетов на расстоянии до 400 км от вас и отслеживать все рейсы. Для этого вам достаточно найти дешевый USB TV и пару свободных минут.

Изображение: dump1090 — тестирую антенну FlightAware против четвертьволновой гибкой антенны и антенны из банки.

Всем привет!

3 августа проводится очередная встреча Московского Клуба Программистов в офисе Туту.ру. Всё, чем мы занимаемся в Туту.ру, — на 100% пропитано информацией и технологиями для её сбора, хранения, интеграции и анализа.

На этом митапе наш CTO ( Molodoi ) поделится инсайдами о том, как в реальности происходит разработка и сопровождение кода в Туту.ру на жизненных примерах. Затем…

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



Примечание: все примеры рассказывают об использовании оригинального upstream-дистрибутива Kubernetes, а не его производных вроде OpenShift (Red Hat) и Tectonic (CoreOS).

Начнём с eBay, специалисты которой серьёзно работают с Kubernetes уже более 2 лет и значительно продвинулись в этом…

Источник изображения

На просторах сети Интернет можно найти немало полезных утилит для Docker. Многие из них принадлежат к разряду Open Source и доступны на Github. В последние два года я достаточно активно использую Docker в большинстве своих проектов по разработке программного обеспечения. Однажды начав работать с Docker, вы осознаете, что он оказывается полезен для гораздо более широкого круга задач, нежели вы изначально предполагали. Вам захочется сделать с Docker еще больше, и он не разочарует!

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

Давайте посмотрим на утилиты, которые помогают мне в процессе докеризации всего и вся.

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

Хотя понятие DevOps на слуху уже далеко не первый день, о нём до сих пор не прекращаются споры, начиная с вопроса «что это вообще такое». Словосочетание «DevOps-конференция» тоже порождает вопросы: например, если тут сходятся «dev» и «ops», то мероприятие рассчитано на зрителей с бэкграундом в разработке или в администрировании?

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

• Барух Садогурский (JFrog)
• Олег Анастасьев (Одноклассники)
• Алексей Акопян (Dell EMC)
• Кирилл Толкачёв (Альфа-Лаборатория)
• Александр Тарасов (Одноклассники)

А в ходе обсуждения спонтанно возник вопрос к вам всем — так что при чтении этого текста вы можете ещё и лично повлиять на программу конференции!

В предыдущей статье я рассказал, как Docker использует виртуальные интерфейсы Linux и bridge-интерфейсы, чтобы установить связь между контейнерами по bridge-сетям. В этот раз я расскажу, как Docker использует технологию vxlan, чтобы создавать overlay-сети, которые используются в swarm-кластерах, а также где можно посмотреть и проинспектировать эту конфигурацию. Также я расскажу, как различные типы сетей решают разные задачи связи для контейнеров, которые запущены в swarm-кластерах.

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

Предисловие переводчика: Эта статья — комбинация из перевода двух материалов от проекта CoreOS (см. ссылки в конце публикации), посвящённых работе с консольным инструментом для выполнения команд на кластерах Kubernetes — kubectl. Листинг, приведённый автором оригинала для Mac OS X, был адаптирован под Linux, в других листингах было исправлено форматирование YAML, а для удобства чтения всего материала в него были добавлены подзаголовки.

Kubectl — инструмент, который знаком пользователям Kubernetes и обладает широкими функциональными возможностями. Овладение ими занимает время, но позволяет увидеть, что это более мощный инструмент, чем многие предполагали. Представляю набор советов, позволяющих улучшить ваши возможности при работе с kubectl. Не забудьте также посмотреть на cheat sheet в секции официальной документации Kubernetes!

В данной статье рассматривается подход к интеграции Apache CloudStack (ACS) со сторонними системами посредством экспорта событий в брокер очередей сообщений Apache Kafka.

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