«Kubernetes во все поля!» – интервью с программным комитетом конференции DevOops
Раньше докер был крутым, молодежным, вещью в себе. А потом как-то докер перестал быть интересен: он просто есть, он у всех и во всем. На нем все микросервисы, Kubernetes, девопс — всё, что угодно. Вместе с тем, люди тащат контейнеры себе в рот откуда ни попадя. Они часто даже не знают, что там лежит внутри.
Что же теперь интересно DevOps-инженерам? Команда супергероев — программный комитет конференции DevOops — попалась в дьявольскую ловушку в Hangouts и целый час отвечала на вопросы. (Кто все эти люди — подробно написано по ссылке).
Под катом — интервью, раскрашенное цветными мелками. У каждого эксперта — свой цвет:
Барух, как ты думаешь, что интересного произошло в мире с прошлого DevOops? 
Мне кажется, самое интересное, из очевидного — это взлет Kubernetes во все поля, а из неочевидного — менее заметно, но не менее важно, консюмеризация докера.
То есть раньше докер был не для всех?
Нет. Раньше докер был крутым, молодежным, вещью в себе. А потом как-то докер перестал быть интересен, то есть он есть, он у всех и во всем, на нем все микросервисы, Kubernetes, девопс, все, что угодно. Но сам по себе докер как технология вдруг как-то раз и больше никого не интересует. Не запускать же голую джаву на серверах, понятно, что контейнеры. Меня это очень завораживает.
Люди обычно обсуждают то, с чем у них или проблемы, или прямые задачи связаны. В докере не осталось проблем и были ли они там?
В докере было много проблем, и они действительно решились. Кроме того, мы перестали использовать те части докера, которые были болезненны. У докера были вещи, которые он умеет делать очень хорошо. А есть те, которые плохо.
Приведи пример.
Например, джейлы в unix-процессах — там все очень хорошо и умно. Это действительно очень круто работает. А вот например, связность между микросервисами, которые бегут в контейнерах, кластеры, деплойменты, это всё был ад и кошмар.
Ты имеешь в виду Swarm, которым они пытались угнаться за Kubernetes? 
Да, я имею в виду Compose, вот это все было кошмар и ад. И мы решили не пользоваться этим, а пользоваться только тем, что хорошо работает, что понятно и бесплатно. И докер стал очень крут с одной стороны, а с другой стороны перестал быть интересен. Докер и докер — ну и хорошо.
Сейчас, когда присматриваешься к новому софтину, в первую очередь смотришь, есть ли готовый контейнер. Желательно от производителя этой софтины. Потом смотришь, как ее развернуть и потыкать в нее палочкой. Докер доставил нам сложные сервисы на потыкать на рабочую машину. Сейчас не так уж важно, макось у тебя или линукс. Тот же Sentry состоит из 5–6 компонент, которые по отдельности задолбаешься запускать. А если у тебя задача просто посмотреть, как это добро выглядит, послать сигнал и наблюдать, как оно там разложится. Сейчас это займет 15 минут — запустил, у себя развернул, причем кусок будет на Ruby, кусок на Java, не дай бог, какой-нибудь Elasticsearch — который умрет с этим же докером.
Самое главное, он потом умрет.
Да, это отдельная прелесть. Раньше можно было себе в систему нагадить так, что в /usr/local что только не было. И оно ж еще встанет — у кого в /opt, у кого в /usr/local, у кого еще куда-то. И у тебя система пухнет, обрастает всем ненужным. Это одно, а второе — чем больше у тебя ненужного, чем больше вектор атаки на тебя, из-за чего тебя можно обидеть. И так как мы все это запускаем теперь в докерах, то и безопасность здесь, и чистота, и не таскаешь с собой гадости всякие.
Слушайте, дамы и господа, вы же конференции по девопсу делаете, и там если докер стал скучным и неинтересным, что теперь, докера не будет?
Во-первых, докер будет везде. То, что он стал скучным и неинтересным, не значит, что его перестанут использовать. Наоборот, это значит, что мы теперь его используем и не обращаем внимание. То есть он везде есть. Он не тема отдельного разговора на конференциях.
А он в докладах-то есть? Если я сейчас зайду в программу и напишу слово докер, не найдется ничего?
Напиши. Давай проведем этот прекрасный эксперимент.
Написал, и там написано: Practical steps for securing your container deployment
Это отражение того, что докер позволяет нашим современным системам быть более безопасными натуральным образом. Кроме этого, он отражает еще одну вещь, которая может быть тоже изменилась за последнее время… Девопс стал больше. Скажем так, им стали все больше проникаться крупные компании. И вместе с ними все больше стало разговоров на тему безопасности, которую может принести девопс или, наоборот — поломать оную безопасность. Доклад Лиз как раз о том, как этот девопс правильно приготовить, чтобы ваши безопасники были довольны. 
Вы докладчиков лично-то знаете? Кто такая Liz Rice?
Лиз — достаточно важная фигура в девопсном ландскейпе. Она глава всех KubeCon-ов. На самом деле Лиз, во-первых, очень хороший докладчик. Во-вторых, она работает в компании Aqua Security, которая занимается как раз безопасностью контейнеров. Лучшего человека для рассказа про безопасность контейнеров, чем тот, кто этим специально занимается, мы не найдем. Что интересно конкретно про доклады Лиз, я видел много ее докладов, — это то, что она пытается решить достаточно сложную проблему. Проблема в том, что сегодня security, во-первых, сложный, и делается сложнее и сложнее, поскольку атаки становятся более sophisticated. Соответственно защищаться от них становится сложнее, мы должны шифровать нашу информацию по REST, мы должны шифровать in-traffic, всякие TLS-ы, https-ы, сертификаты, протоколы… все это сложна. С буквой А на конце. Во-первых, сложно, а во-вторых — от этого никуда не деться, поскольку ты не можешь сейчас сказать: «Ой, я этого не знаю, давай я не буду делать https. Ну какая разница, кому я нужен». Поскольку тот же мерзкий Chrome немедленно накричит на всех твоих пользователей, что у тебя все не секьюрно. И это сочетание сложности и необходимости, оно вымораживает, потому что это не наша забота, мы все не безопасники. С другой стороны, она лежит на нас, потому что мы не можем просто проигнорировать эти аспекты. Лиз в своих докладах пытается просто и понятно донести ключевые аспекты безопасности контейнеров до людей, которые от безопасности далеки, и это очень круто.
Там есть еще одна проблема в том, что люди тащат контейнеры себе в рот откуда ни попадя. Они же часто даже не знают, что там лежит внутри. Одно дело, если ты хочешь потыкаться палочкой у себя на ноутбуке. И другое дело — потащить это в продакшн. И, к сожалению, многие тащат что ни попадя. То есть нужно что-то, что сложно собрать, они берут готовое и хорошо, если от производителя, который позаботился и взял нормальные базовые контейнеры. И это же вектор для атаки. Например, мы можем в ближайшее время огрести новую волну одноименных контейнеров, как было с пип-модулями, с гет-модулями. Как было с доменами, все то же самое. То есть это не новая проблема, это все та же старая. И когда сервис становится commodity, когда он так распространяется — туда приходят люди, которые наказывают тех, кто не следит за безопасностью. Кстати, из-за этого у нас про безопасность много докладов.
А что там еще есть?
У нас еще есть про управление секретами от Сета Варго. Кстати, с ним же будет круглый стол по безопасности.
А Сет — это же человек из Google, который раньше в HashiCorp работал?
До этого он работал в Chef Software и там был звездой, когда Chef был на пике популярности. Он оставил след чуть ли не в каждом кукбуке. Его за эту активность даже некоторые не любили. Потом он много наследил в HashiCorp. И этот шлейф HashiCorp за ним до сих пор тянется. У нас он будет рассказывать про продукт HashiCorp. Про Google он не будет рассказывать. Но в тайтле у него будет Google, так что это добавляет вес.
Кстати, а что с Chef случилось?
Кое-где Chef был убит теми самыми контейнерами.
Применения Chef там, где были написаны и работают — насколько понимаю, могут еще достаточно долго продолжать работать, потому что configuration management сам по себе не умер.
Ребят, я могу вам сказать на живом примере. У нас то, что не в докере, то под Шефом. Потому что сервера-снежинки никуда не девались.
Ты сейчас сказал, что случилось с Шефом. То, что не под докером, то под Шефом. Но под Докером у нас почти все.
Все правильно, но все равно остаются долго живущие сервера, сервера с данными, которые никто не хочет пихать. Вот они еще будут какое-то время с Chef жить, потому что в адище ручного управления возвращаться все, кто побывал в нормальном мире, не хотят.
Кстати, Ansible кто-нибудь из присутствующих использует?
Да, Ansible тоже есть.
Мы используем.
И как? Почему Ansible?
Восхитительная способность превращаться в мусор с дикой скоростью. Вот такое впечатление Ansible оставляет. Такой сходимости к аду я еще не встречал в своей жизни.
Кажется, у нас есть про это доклад!
Именно. И он помогает как раз не превращать результат работы с Ansible в то, что я упоминал. И это восхитительно, жаль, я его не видел, когда мы писали вот это все добро.
Вы говорите, что все под докером запускается, но сами сервера-то, чтобы на них гипервизор запустить, их же надо как-то сконфигурировать?
Да нет, в Амазоне берешь…
А, читер, в Амазоне. Понятно.
Или Терраформой — где угодно.
Самые продвинутые. И про это у нас тоже есть доклад.
Terraform закрывает эту потребность, что есть куча провайдеров, у них по-разному запускаются виртуальные машины, и ты с помощью Terraform закрываешь слой, когда у тебя машина появляется. Потом у тебя в Terraform какой-нибудь provisioner, тот же Chef, тот же Ansible. Какой-то provisioner наливает следующий слой, и потом на эту готовую минимально машину прилетает Docker. Профит.
А доклад ведет тот человек, который делал aws-modules для Terraform?
Он очень много сделал для амазоновых модулей, но это community-часть. И еще этот человек интересен следующим: так как он долго пожил с Terraform, то в комьюнити, где он тусит все эти годы, сформировались некие best practices, и вокруг Terraform этих best practices как раз не хватает, потому что он местами настолько прост и настолько не дает тебе делать лишних движений, что иногда описание получается слишком сложным. У тебя будет либо портянка, либо наоборот, очень сложная взаимосвязанная структура. И мы надеемся, что Антон Бабенко, который как раз будет рассказывать про все это, поможет разложить по полочкам, как же все-таки жить с Terraform и не страдать от этого. Как развивать свои модули для личных потребностей, чтобы они продолжали оставаться чистенькими, читабельными и, кстати, там, конечно же, тоже никто ничего не тестирует.
Никто не пробовал эти портянки терраформовские из более удобного метаязыка генерить?
Есть такие идеи. И мы стараемся не делать так. Там на самом деле у Terraform есть структуры данных, которые позволяют все-таки обходиться без генерации, но сложно. Представь, что у тебя в амазоне несколько vpc в разных регионах, тебе надо между ними пиринг, и вот тут у тебя начинаются приключения. В каждом регионе API, точка входа разная, а Terraform ты будто бы говоришь про одну. То есть тебе надо разрулить в описании эти точки входа, описать каждый vpc и еще пиринг, связь между этими vpc в разных регионах. И все это надо как-то описать. У нас ребята это сделали своими модулями, и с этим хоть как-то стало можно жить. Вообще, тяжко, сложно. Но если бы Terraform давал еще больше возможностей, если б там… Как это называется, когда переменная внутри переменной разыминовывается?
Kotlin DSL.
<все адски смеются>
Переменная переменная, или интерполяция — смотря что ты имел в виду.
В общем, это не полноценный язык, он очень усечен. Он тебя заставляет писать максимально просто, в отличие от Котлин DSL, где у тебя полноценный Kotlin в руках.
Ну как, со всеми ограничениями Kotlin DSL-а, которые сами понимаете, решаются чем?
Чем?
Решаются Groovy DSL, естественно!
Многие пользовались TeamCity из здесь присутствующих?
Да, конечно. Груви DSL, Kotlin DSL, у нас же про это доклад!
И его конечно же делаешь ты?
Его делаю не я, нет! У нас будет как раз TeamCity с Kotlin DSL и его сравнение с Groovy DSL в дженкинсе.
Кто-то из JetBrains приехал?
Нет. В этом отдельная прелесть.
У нас реальные пользователи, никакого маркетинга.
Все, сдаюсь, кто еще может сделать доклад про TeamCity?
Небольшая компания, широко известная в России как Тинькофф, использует. Вот, в программе он есть.
Да, и немножко рассказать, сравнить со всеми ненавидимым, но повсеместно используемым дженкинсом и его Groovy DSL.
Надо сходить, послушать и узнать, какую роль в выборе технологии сыграла харизма Баруха.
Никакую. Я абстрагировался полностью от этого всего. Все будет честно, без мухлежа.
Имею в виду, что в Тинькоффе взяли все эти хипстерские технологии не просто так, TeamCity — это не какой-то энтерпрайз двадцатилетней давности, как это принято в банках обычно.
Тинькофф — это такой банк, который с самого начала так и сделал. Банк для хипстеров от хипстеров. Соответственно, технологии там свежие и правильные.
Ребят, я действительно пользуюсь TeamCity каждый день, и в последней версии он стал прекрасен. TeamCity DSL стало можно пользоваться. Смотрите, какая проблема была до последней версии. В предыдущей версии, если ты переходил на Kotlin DSL, у тебя не было варианта продолжать пользоваться интерфейсом. Как только ты перешагнул черту, единственный способ дальше писать был только на Kotlin.
Все, ты ступил на Темную Сторону.
Да, документации было минимум, и это был адок. Поэтому мы попробовали и откатились сразу назад на XML-конфигурацию. В последней версии при переходе на Kotlin DSL ты продолжаешь использовать веб-интерфейс, а он там под капотом формирует патчики, патчит эти структуры прямо в репозитории. Потом ты можешь спокойно продолжить писать на Kotlin, если ты уже где-то что-то освоил. Те, кто еще не посвящен, могут продолжать тыкаться в интерфейсе. Это прекрасно, ребята!
Это благотворное влияние Антона Архипова.
Кстати, тут упоминали про практики всякие. Есть ли у нас доклады какие-то, которые посвящены не тулингу, а каким-то процессам, культуре, человеческой стороне?
Естественно. Во-первых, у нас есть прекрасный закрывающий кейноут Саши Титова и Кирилла Толкачева, в котором они будут обсуждать, плохо всё в девопсе или надежда еще есть. 
Мне кажется важным сказать, что DevOops — это, наверное, на данный момент чуть ли не единственная профессиональная конференция, которую организует JUG.ru Group, в которой разрешено говорить про социальные вещи и про процессные, причем на официальном уровне.
Для этого нам пришлось плотно пообщаться с руководством JUG.ru Group, но результат на лицо.
У нас, кроме этого прекрасного кейноута, есть еще доклад от Dell EMC, там тоже во многом про процессы. Это про команду внутри компании, которая пишет сервисы для внутреннего использования. Одно дело написать этот сервис, а другое — чтобы им начали пользоваться, потому что все люди заняты, им некогда осваивать хипстерские технологии. Соответственно, напиши сервис, а потом продай его внутри компании. К тебе придут пользователи, у них начнут возникать всякие нестандартные потребности, и вот у тебя дилемма — развивать сервис, чтобы им могли многие пользоваться или удовлетворить вот эту конкретную команду. Мы ожидаем там тоже огонька.
Там будет описание страшной двухлетней истории, которая уже не такая больная, как было в начале.
Барух, ты тоже что-нибудь остросоциальное рассказываешь?
У нас с Лёней Игольником есть доклад про то, как правильно начать замерять вот это все безобразие, которое у нас в девопсе происходит. Естественно, у нас есть какие-то метрики, к которым мы приносим с собой из dev и которыми мы не пользуемся и никогда не пользовались. У нас есть метрики, к которым мы приносим с собой из ops, с которыми всегда было куда лучше. Возникает вопрос, что же такое метрики девопс? Что это значит? Это просто взять тех и взять других, или это что-то новое, какие-то новые метрики? Короче говоря, data-driven devops.
Барух, иногда читатели, посетители негодуют, что товарищи из программного комитета свои доклады читают, они считают это чем-то нечестным.
Мы действительно это все приняли ко вниманию. По крайней мере, мы очень стараемся привести как можно больше разнообразных докладчиков, которые не только из программного комитета. Но при этом некоторых участников ПК мы всё же хотим видеть как докладчиков. Например, Алена Прохорчик, Principal Engineer в Rancher Labs, которые, наверное, имеют наибольший опыт в мире с multicloud Kubernetes deployments. Думаю, что все хотят послушать про это, и ей есть что рассказать. А мы как программный комитет наслаждаемся её экспертизой в оценке докладов. Наверное, когда вся конференция состоит из докладчиков из программного комитета, и у каждого из них по пять докладов, это действительно нехорошо. Но если у нас есть хороший докладчик, который хочет помогать программному комитету, я, честно говоря, не понимаю, почему мы должны выбирать или одно, или другое.
Барух, ты работаешь работу, плюс постоянно ездишь с докладами, плюс работаешь в программном комитете. У тебя вообще жизнь-то есть? Как ты умудряешься все делать?
Волонтерство для конференций JUG.ru Group очень приятно, потому что оно доставляет массу удовольствия, — и кроме того, я учусь новому. Прогоны докладов людей, которые знают намного больше меня, — очень полезны.
Понятно. Кто-нибудь хочет что-нибудь добавить к нашему с Барухом монологу?
Я часто говорю, что слышал доклады, которые никто никогда не услышит.
Да, программный комитет слышит не только то, что потом попадает на конференцию. Конкурс был один к трем. Можно сказать, что так получилось, поскольку среди заявок было много достаточно интересных. Часть из того, что мы отфильтровали, мы рекомендовали на другие конференции.
Были ли какие-то темы, которые вам приходилось фильтровать по количеству? Kubernetes, например. Есть что-нибудь еще?
Мониторинг. У нас была битва за мониторинг.
Куча докладов. Все любят мониторить.
Кто выиграл в этом Царе Горы?
Алексей Кирпичников, доклад «Чему мы научились, пока делали собственную систему уведомлений о нештатных ситуациях».
А есть что-то такое, что хотелось бы в программу, но нет экспертов?
Ты с языка снял. Есть обратная сторона медали, наш любимый serverless, который вроде бы под хайпом, но никого, кто хорошо соображает и практически применил все это, не появилось. Надеюсь, хоть одного мы вытащим. Но в целом, в компаниях промышленного опыта пока мало. Барух, а что с экспертами-евангелистами? Их тоже нет? Или просто к нам никто не пришел?
Вся эта история с визами нам очень здорово испортила ситуацию во многом, в том числе и с developer advocates, которые хотели приехать и рассказать про serverless, конкретно из Amazon, про лямбды. На визах, к сожалению, все и заглохло.
А были такие доклады, в которых вы реально что-то новое для себя узнали, чего раньше не было? Или какие-то прорывные вещи, которые запомнились?
Я, как один из самых нетехнических людей в программном комитете, постоянно узнаю кучу новых вещей, которые потом приношу инженерам своим, а они говорят, да это же 101, что ты мне принес. Но не всегда!
Татьяна, ты ничего не говорила, расскажи, что нового ты узнала в процессе ПК?
Наверное, почти из каждого доклада много интересного нашла, чего не слышала. Иногда меньше, иногда больше. Из некоторых докладов мы что-то себе хорошее забрали. Особенно тот, который связан с Ansible, который уже упоминали. У нас тоже есть Ansible, и мы тоже начинали его неправильно готовить. Интересно послушать доклад Оксаны, потому что я работаю в отделе, который занимается чем-то похожим. Но у нас немного разная ориентация: насколько поняла, отдел Оксаны занимается теми, кто сам к ним пришел, и теми, кого бизнес требует. Наш отдел, наоборот, пытается обработать всех, кто есть в компании.
На самом деле нет, я в том же отделе работаю, он у нас стоит на тех же позициях. Мы официально большое подразделение, которому поручено раздавать эти сервисы, в том числе местами насильно. Об этом мы поговорим на конференции.
Обязательно.
А Бородина обсуждали? © Habrahabr.ru
