Всем привет!

Как и обещали в предыдущем посте, выкладываем видеозаписи всех докладов, прозвучавших на QIWI Server party 3.0 27 сентября. Так что, если вы не пришли на сам митап и не успели посмотреть прямую трансляцию — под катом полная запись митапа от А до Я.

Контейнерами сегодня никого не удивишь. Удивишь вопросом про безопасность контейнеров. Особенно интересно спрашивать об этом коллег, которые используют контейнеры и микросервисы в продакшне на полном серьёзе: часто вижу удивленные лица и недоуменный вопрос, мол, «Что, зачем это»? Получается, что про технологию мы уже знаем (да и как тут не знать: кажется, что скоро даже школьники на уроках технологии будут всем классом строить кластер Kubernetes), а вот защищать составные части её — пока еще не научились. Быть может, просто некому было учить.

В этой статье и на DevOops у нас будут спикеры, съевшие собаку на теме правильных с точки зрения безопасности контейнерных решений. Мы отправляемся к ним за ответами на самые простые вопросы облачной безопасности. Надо же с чего-то начинать самообразование?

Участники:

Сет Варго работает Developer Advocate в Google. Ранее он работал в HashiCorp, Chef Software, CustomInk и нескольких других стартапах в Питтсбурге. Он является автором Learning Chef и ратует за сокращение неравенства в технологиях.

Лиз Райс — технический евангелист в компании Aqua Security, занимающейся безопасностью развертывания приложений в облачных средах и контейнерными решения для энтерпрайза. Лиз — весьма известный в сообществе человек, председатель KubeСon-ов.

Олег Чирухин, редакция JUG.ru Group

29 сентября мы провели Deerploy DevOps MeetUp, а сегодня публикуем видео выступлений.

«Доставляем в Kubernetes. Непрерывно и по-своему», Евгений Дехтярёв, 2ГИС

По следам статьи Docker + Laravel = ? хочу рассказать о довольно необычном способе использования утилиты docker-compose.

Для начала, для тех кто не знает, зачем нужен docker-compose. Это утилита, которая позволяет запускать на отдельном хосте набор связанных сервисов, запакованных в docker-контейнеры. Изначальная версия была написана на python и могла быть установлена двумя способами:

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

С этого момента вам больше не придется думать об установке ОС и отдельных пакетов на каждую ноду. Зачем? Вы можете сделать все это автоматически через Dockerfile!

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

Заинтриговал? Теперь давайте обо всем по порядку.

В октябре к нам на конференцию DevOops приедет звезда мирового уровня — Джон Уиллис.

Джон — один из нескольких отцов DevOps, автор 10 книг, выпускаемых в течение последних двадцати лет, включая всем известные DevOps Handbook и Beyond the Phoenix Project, гуру по Ops-части на протяжении 35 лет и просто живая легенда.

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

Как-то в комментах задавали вопрос, чем участие в Слёрме отличается от чтения мануалов по Кубернетес. Я попросил Павла Селиванова, спикера Слёрм-2 и МегаСлёрм, дать небольшой пример того, что он будет рассказывать на Слёрмах. Передаю слово ему.

Я администрирую кластер Кубернетес. Недавно мне понадобилось обновить версию k8s и, в том числе, перезапустить все машины в кластере. Я начал процесс в 12:00, и к концу рабочего дня все было готово. Причем в первый раз я еще следил за ходом обновления, а во второй — ушел на обед на 1,5 часа (справедливости ради, прихватив ноутбук). Кластер обновился сам, без моего участия и незаметно для клиентов, разработка ничего не заметила, деплои продолжались, сервис работал как обычно.

Как это выглядело.

В предыдущей статье имел наглость использовать CLion в качестве IDE. И тут же прибежал человек с вопросом: ой, проприетарная платная поделка, продался, зажрался, итп. Справедливости ради, на Хабре такой комментарий был всего один, но в реальности их тысячи. Например, крайний действующий аккаунт на ЛОРе, у меня зарегистрирован с 2010 года, и в почти каждой дискуссии с участием какого-то несвободного софта начинается этот ад. Понятно что никому я ничего не докажу, но редким бредущим мимо может помочь.

Статья условно делится на две части: социально-мотивационная и техническая (как собирать CMake в Windows под различными IDE).

Прим. перев.: Автор оригинальной статьи — Théo Chamley, архитектор облачных решений Google. В этой публикации для блога Google Cloud он представил краткую выжимку из более детального руководства его компании, названного «Best Practices for Operating Containers». В нём специалисты Google собрали лучшие практики по эксплуатации контейнеров в контексте использования Google Kubernetes Engine и не только, затронув широкий спектр тем: от безопасности до мониторинга и журналирования. Итак, какие практики в работе с контейнерами наиболее важны по мнению Google?

Траге́дия (от нем. Tragödie из лат. tragoedia от др.-греч. τραγωδία) — жанр художественного произведения, предназначенный для постановки на сцене, в котором сюжет приводит персонажей к катастрофическому исходу.

Большинство трагедий написано стихами. Эта трагедия написана Барухом Садогурским (@jbaruch) и Леонидом Игольником (@ligolnik). Если уж мы говорим о DevOps в большом масштабе, что это, как не трагедия?

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

А теперь заканчиваем играть в Белинского и добро пожаловать под кат! Там и текст, и видео. Заложников не брать!

Вышел Azure DevOps! Сегодня мы кратко расскажем об этой новой платформе, ее решениях, процессе перехода с Visual Studio Team Services и об использовании в реальных проектах. Присоединяйтесь!

Сегодня разговор пойдет о DevOps, а точнее — в основном об Ops. Говорят, что существует очень мало людей, которые довольны уровнем автоматизации своего operations. Но, кажется, ситуация исправима. В этой статье Николай Рыжиков расскажет о своем опыте расширения Kubernetes.



Материал подготовлен на основе выступления Николая на осенней конференции DevOops 2017. Под катом — видео и текстовая расшифровка доклада.

Сегодня 27 сентября, а это означает, что в рабочее время (по американскому часовому поясу) мы можем ожидать очередной релиз Kubernetes — 1.12 (впрочем, его официальный анонс иногда задерживается). В общем, самое время продолжить славную традицию и рассказать о наиболее значимых изменениях, что мы и сделаем, руководствуясь публичной информацией от проекта: таблицей Kubernetes features tracking, CHANGELOG-1.12, многочисленными issues, pull requests и design proposals. Итак, что нового в K8s 1.12?

Про DevOps говорят много и разного. Нам же интересно мнение только тех, кто действительно внедряет и следует DevOps принципам. Так удачно сложилось, что в Программный комитет DevOpsConf Russia входят именно такие люди. Воспользовавшись служебным положением, я задал им восемь одинаковых вопросов:

• Каково главное преимущество DevOps подхода, на твой взгляд?
• Что больше всего может помешать компании в DevOps трансформации?
  
• Как интегрировать специалистов по безопасности в процесс поставки ПО?
  
• Как относишься к поднимающемуся хайпу вокруг SRE?
• Какие инструменты сегодня непременно есть там, где говорят о DevOps?
• Что отличает хорошего инженера от плохого с точки зрения DevOps?
  
• Как логичнее всего попасть в профессию?
  
• Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?

Ответы получились очень любопытными и заодно позволяют составить некоторое впечатление о тех, кто вложил много усилий и немножко души в расписание нашей конференции. Например, ответ на первый вопрос шире, чем сокращение time-to-market. Мнения по поводу SRE разошлись, зато все практически единодушно советуют читать «The DevOps Handbook», но и еще надавали кучу рекомендаций — за ними под кат.

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



В основе материала — доклад-диалог Сергея Бердникова (Золотая Корона) и Артема Каличкина (ЦФТ) c октябрьской конференции DevOops 2017. Под катом — видео и текстовая расшифровка доклада.

Все мы давно уже привыкли к Maven, к версионности предложенной им и управлению зависимостями. Maven появился на свет, когда ежедневная сборка проекта была уделом самых смелых, когда считалось нормальным релизиться хотя-бы пару раз в год, Jenkins тогда еще назывался Hudson, а деревья были большими…

Идеи, которые привнес maven в мир разработки, были крайне востребованы и быстро завоевали популярность: определение стандартного воркфлоу проекта, стандартная модель директорий, и много еще чего, что уже давно воспринимается, как должное.

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

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

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

Далее мы попробуем изменить мир к лучшему и упростить себе жизнь.

Прим. перев.: о так называемых плагинах хранилищ «вне дерева» Kubernetes (Out-of-Tree CSI Volume Plugins) мы впервые рассказывали в своём обзоре релиза K8s 1.9, где эта фича появилась в статусе альфа-версии. Автор нового материала — Anoop Vijayan Maniankara (ведущий DevOps-инженер финской компании Tuxera) — собрал ключевые сведения об идеях и устройстве CSI, что помогает быстро познакомиться с новой концепцией, которая, как утверждают некоторые наши сотрудники, «будет the next big thing». Для более подробного и технического изучения CSI в конце статьи приведены полезные ссылки, среди которых я особенно выделю презентацию одного из авторов этой спецификации (Jie Yu). Но начать всё равно стоит с «общей картины»…



Container Storage Interface (CSI) — инициатива, призванная унифицировать интерфейс хранилищ, таких как Ceph, Portworx, NetApp и т.п., в системах оркестровки контейнеров: Kubernetes, Mesos, Docker Swarm, Cloud Foundry и других. Идея в том, чтобы реализация одного CSI производителем хранилища гарантированно работала со всеми этими системами.

В GitLab 11.3 поддерживаются репозитории Maven, Code owners, Secure environments и Epic-прогнозирование. Эти функции помогают автоматизировать средства управления средой и кодом, обеспечивая при этом дополнительную эффективность для разработчиков Java.

Полгода назад мы закончили миграцию всех наших stateless сервисов в kubernetes. На первый взгляд задача достаточно простая: нужно развернуть кластер, написать спецификации приложений и вперед. Из-за одержимости в вопросе обеспечения стабильности в работе нашего сервиса пришлось сразу начать разбираться с тем, как работает k8s и тестировать различные сценарии отказов. Больше всего вопросов у меня возникало ко всему, что касается сети. Один из таких "скользких" моментов — работа сервисов (Services) в kubernetes.

В документации нам говорят:

• выкатите приложение
• задайте liveness/readiness пробы
• создайте сервис
• дальше все будет работать: балансировка нагрузки, обработка отказов итд.

Но на практике все несколько сложнее. Давайте посмотрим, как оно работает на самом деле.

Чтобы разобраться, как связана Вселенная, рыба и DevOps, нужно изучить расписание DevOpsConf Russia. Тем более конференция уже через неделю, 1–2 октября, и так и так надо планировать, какие из выступлений удастся послушать. Постараюсь в этом помочь — все-таки я приложил не мало усилий, чтобы программа получилась такой насыщенной.

Открывать конференцию буду я сам темой «Что такое DevOps». Расскажу, как к нему идти, и что вообще он из себя представляет, надеюсь это даст повод для споров и разговоров на всю конференцию. Затрону и процессы, и инженерные и инфраструктурные вопросы, то есть все кирпичики, составляющие DevOps, которые легли в основу программы. А уже после этого примемся за инструменты: Kubernetes, Ansible, Docker, Prometheus, Ceph, Hashicorp Vault, Istio, KVM, CoreOS.



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