deflope

DevOps Дефлопе

Русскоязычный подкаст о DevOps

014 - DevOps в Spotify

скачать mp3

Текстовая расшифровка подкаста

Новости

Обсуждение

Policyfiles

У нас в гостях Лев Попов из Spotify

Расшифровка

И.Е.: Здравствуйте. в эфире 14-й выпуск подкаста DevOps Дефлопе и с вами его постоянные Chef-повора Никита Борзых…

Н.Б.: … и Иван Евтухович.

И.Е.: Новости.

И.Е.: Даррен Хэгью из компания SAP, да-да, той самой SAP, которая самый настоящий энтерпрайз, уже почти два года назад сделал презентацию “Непрерывная поставка: от динозавров к космическим кораблям за 2 года”. В ней он красочно описывает, как от почти полностью водопадного процесса они перешли к Agile подходу, как в инструментах, так и в командных отношениях. Им удалось за этот срок перейти от месячного релизного цикла к двум релизам в неделю, полностью автоматизировать создание любых окружений, сделать Blue-Green выкатку. История очень увлекательная, всем рекомендую прочитать.

Н.Б.: 13 сентября Том Duffield из компании Chef выложил презентацию, в которой описано, как использовать докер и Chef-контейнер вместе. В презентации рассказывается, что такое докер, какую виртуализацию он использует и как работать с их Chef-контейнерами.

И.Е.: В августе этого года в издательстве O'Reilly вышла книга Джона Кови из Etsy под названием: «Customizing Chef». В книги описывается, зачем может понадобиться тонкая настройка Chef, и рассказывается, как это можно сделать. Как обычно, каждая книга по Chef содержит краткое описание языка Ruby, и эта не оказалась исключением. Далее в ней раскрываются такие темы, как Chef-Run, Dry-Run, рассказывается, что такое Ohai и как писать к нему плагины. Не обойдена вниманием и работа хендлеров при запуске Chef-клиента. Также рассказывается про библиотеки и definition, про тяжеловесные провайдеры (hwrp) и легковесный провайдеры (lwrp), про создание плагинов для knife и про API chef-сервера. Если вы всерьез собираетесь покопаться в кишках Chef, то эта книга может вам очень пригодиться.

Н.Б.: Первого октября в блоге Hahicorp появилась запись о том, что Seth Vargo теперь работает с Хашимото вместе, в компании Hashicorp. Seth будет работать как инженер и как евангелист. Как евангелист он работает в пресс-конференциях, как инженер он будет коммитить в opensource проекты компании Hashicorp.

И.Е.: Компания Амазон выпустила брошюрку в формате PDF о том, как использовать DSC на Амазоне. С примерами тестового проекта, они рассказываю о том, как можно использовать DSC, кто не знает DSC – это Desired State Configuration. Это инструмент для управления конфигурациями от компании Microsoft, его можно использовать в pull и push режимах, и компания Амазон достаточно понятно описывает, как это можно делать. Если вы интересуетесь DSC и Амазоном, обратите внимание на эту брошюрку.

Н.Б.: 15 октября компания Microsoft заявила о поддержке новых Windows Server контейнеров и поддержке докеров в Azure. Если я правильно их понял, Microsoft в следующей версии windows server сделает аналог LXC, то есть контейнерную виртуализацию под windows. Ни я ни Ваня не являемся экспертами в этих сферах, так что если вы что-то знаете об этом - милости просим в наш подкаст. Так же Microsoft сообщил, что они сделали поддержку Azure в Docker Open Orchestration APIs, и теперь можно деплоить docker контейнеры в Azure.

И.Е.: 3 сентября в блоге компании Chef появилась запись, которая называется “Зачем использовать Chef и DSC вместе”. Кто не знает DSC - это Desired State Configuration - инструмент для управления конфигурациями компании Microsoft. Собственно, автор статьи Steven Murawski, он насколько я помню, занимался DSC в компании Stackoverflow, то есть Chef и DSC в компании Stackoverflow. Он пишет о том, зачем использовать Chef и DSC вместе. Действительно, и DSC и Chef это инструменты, функциональность которых сильно пересекаются, но тем не менее Стивен пишет, что DSC может гораздо меньше , чем Chef и то, чего не может DSC для этого удобно использовать Chef, потому что в Chef это уже все есть. Он достаточно подробно описывает в чем Chef превосходит DSC и как это использовать вместе. И поэтому если вы автоматизируете что то под windows, то обратите внимание на эту запись.

Н.Б.: 2 октября компания Chef зарелизила ChefDK 0.3.0. Главной фичей стали Policyfile. Policyfile - это аналог berks-файлов. В этом полисе можно использовать run-лист и те кубуки которые могут использоваться в Chef-Run. Включение полис-файла происходит через параметры в chef-клиенте, я так понимаю - это будет работать только для новой версии chef-клиента. Так же в chef-клиенте надо указывать deployment group - это тот полис-файл, который вы хотите использовать. Как сами Chef признаются они сами не до конца еще осознали, как этой фичей пользоваться нормально, и они сказали, что в будущем могут какие-то сильные изменения в этой фиче.

И.Е.: В блоге компании yeller 14 мая появилась статья о том, как использовать zookeeper для feature flags, не знаю как это по-русски. Они взяли за основу плагин James Golick, который называется rollout, который использовал Redis. Но Redis - это, как известно, однопоточное приложение и при больших нагрузках он становится узким местом. Zookeeper же , хотя казалось бы, что это система, должна работать еще медленнее, чем Редис, имеет возможность notify-ить всех своих клиентов о том, что что-то изменилось. Соответственно на клиентах хранится копия того, что есть в zookeeper, какого-то ключа zookeeper, которое автоматически обновляется notify-ми zookeeper. И это позволяет гораздо большие нагрузки держать с помощью zookeeper, чем с помощью Redis. И соответственно Yeller использовал эту фишку для того, чтобы реализовывать feature flags внутри своих продуктов. Feature flags - это, кто не знает, возможность включить или выключить фичу для какого-то набора пользователей, то есть если этот флаг у пользователя стоит, то фича включается, соответственно - нет. Это очень удобно, когда вы делаете выкладку новой фичи и включаете ее постепенно на разных кластерах пользователей, чтобы в случае возникновения проблем, только очень маленькая часть пользователей испытала какие-либо проблемы с новой фичей, либо например, чтобы контролировать возрастание нагрузки в связи с выкаткой новой фичи.

Н.Б.: 10 сентября Стефан Гордон выложил презентацию в которой описано, как пользоваться Terraform и другими продуктами от Hahicorp. В частности приведены примеры кода, как задеплоить докеры с помощью Terraform в Digital Ocean, как с помощью Terraform горизонтально маштабироваться, и как запускать другие провизоры. Отдельно в презентации рассказано, как после создания машины запустить на ней chef-клиент.

И.Е.: В блоге Ивана Евтуховича, кто это такой, кстати, я не знаю…, вышла статья, которая называется “Могущественная скорлупа”. На самом деле статья рассказывает о том, что такое powershell, чем он приколен и почему экосистема windows сильно поменялась за последние несколько лет. Кто не знает, для powershell появился еще более интересный перевод, чем “могущественная скорлупа” - это “доспехи власти”.

Н.Б.:У компании DigitalOcean появилось красиво ладненько о том, что теперь вы можете поставить докеры в один клик. То есть теперь наряду с другими предложениями вы можете создать имидж в котором уже будет находить докер.

Н.Б.: 16 октября вышел Docker 1.3. Из нового - это поддержка команд docker exec, которые позволяют запускать любые команды внутри вашего контейнера. Также появилась поддержка SELinux и AppArmor внутри докера. Если вы пользуетесь boot2docker то теперь можно монтировать директории с хост машины MacOS внутрь докер-контейнера.

И.Е.: Никита, что хотим сегодня мы с тобой обсудить?

Н.Б.: Давай обсудим новую ChefDK 0.3.0. , а точнее появившийся в нем так называемый Policyfile.

И.Е.: Я предлагаю поиграть в хорошего и злого девопса. Я буду злым девопсом, а ты - добрым.

Н.Б.: Нет.

И.Е.: Наоборот, думаешь?

Н.Б.: Да.

И.Е.: Я не знаю как это защитить можно…

Н.Б.: Я тоже не знаю, но это довольно спорная вещь, поэтому давай будем оба злыми девопсами.

И.Е.: Вообще ситуация выглядела следующим образом Seth Vargo ушел из компании Chef , и в компании Chef схватились за голову, потому что разобрать в Berkshelf никто не мог. Код написан makaron-style, так называемый спагетти-стайл-код. И что делать? Давайте сделаем уже давным давно назревающее, причем встроим в инфраструктуру не с боку-припеку, а прям внутрь!

Н.Б.: Ну подожди, тоже с боку-припеку, но к chef-клиентам - то же самое.

И.Е.: Причем, судя по записям в блоге они выдрали сам резолвинг из berkshelf-а, там где-то есть “thanks to some code from berkshelf”. Короче теперь ни предлагают использовать такую вот штуку. Но вообще, честно говоря, мое личное мнение, я все таки буду злым девопсом, сразу ребята не подумали, как все это будет работать вместе. Потом приплели сбоку librarian chef, потом появился berkshelf. А теперь еще давай воспользуемся policy файл, мы все равно до конца не понимаем, поэтому мы сделаем возможность делать policy и группу, да? В добавок к ролям и environement-ам у нас будут еще и группы еще и policy, и теперь все это вместе будет работать как-бы! Но мы еще не придумали как!

Н.Б.: Вань, тормози. Ты забываешь о длинной и долгой истории компании OpsCode или той же компании Chef. Очень хорошо говорить, что сейчас все просто и понятно, как надо было сделать, но у них очень большая история и нельзя просто взять и сделать хорошо к текущему продукту.

И.Е.: Я вспоминаю анекдот: у нас есть 12 несовместимых стандартов, давайте сделаем 13й, который объединяет все их.

Н.Б.: Ну, Вань, я понимаю, что тебе очень нравиться концепция ansible, где можно легко указать, какой именно php ты хочешь использовать, т.е. какой кукбук php ты хочешь использовать. Но я думаю Chef к этому придет, потому что в целом сейчас никто не мешает добавить такую поддержку. То есть если ты посмотришь на структуру этого файла - достаточно просто это запилить.

И.Е.:Но ты, кстати, видел, что теперь в policy файл-точка-лок помимо версии кукбука содержится и еще его хэш. Поэтому…

Н.Б.: Так было всегда.

И.Е.: Стоп, стоп, стоп. Нет, теперь кубук с одной и той же версией отличается, а раньше это был один и тот же кубук. Из-за этого был гемор, кстати.

Н.Б.: Ну подожди, в berkshelf…

И.Е.: berkshelf проверял, фризил просто их, что б не проверять.

Н.Б.: Писал sha-1 сумму, по-моему

И.Е.: Да, но он тупо фризил кубуки на сервере. Теперь у тебя на сервере будут храниться кукбуки одинаковой версией, но с разными хэшами.

Н.Б.: Я не думаю, что все это будет работать , потому что chef-серверы они же не переписывали. Рolicy файл, это такая клиентская…

И.Е.: Подожди, policy файл хранится на сервере.

Н.Б.: Как обычный файлик, а вся логика работы происходит на клиенте.

И.Е.: А как он вытаскивает с шеф-сервера по sha какую-то новую версию, если там нет.

Н.Б.: Я не знаю.

И.Е.: Но это заливает Никита! Поверь мне, эти ребята не придумали ничего нового! Как говорится, еще немножечко овна и палок. Никита, давай защищай! Будь добрым девопсом! Защити компанию Chef! Но поскольку Никита оказался бессилен..

Н.Б.: Подожди. Что тут защищать. С одной стороны, Chef пишет, что это не замена beskshelf - это замена больше environment-ам. То есть это не кубук-resolver - это версионирование на клиенте выполняется. В целом - почему и нет. Ты против berkshelf или против чего?

И.Е.: Я против бардака вообще. Когда я учился в школе, мой преподаватель по математике говорил такую фразу: “Бардак на доске и бардак в тетради обозначает бардак в голове”. То же самое я могу сказать про версионирование в шефе. То есть когда у нас есть несколько способов версионировать, и все они работают по разному и часть вещей, например роль, еще не версионируются, а environment-ы при этом тоже не версионируется, но это как бы не так страшно. И databag-и, кстати, тоже не версионируются, не зависят от environment-а. Вот мы получаем, что получаем, и безусловно, конечно, копание Chef вместо того, что б просто сказать :”ОК, ребята, прошлые версии depricated, и мы теперь будем делать вот так”. Вот это единственно правильный способ. А они придумали 20 способов и теперь все stackoverflow будет обсуждать, а как собственно версионировать то, как версионировать сё?. Честно говоря, мне это как инженеру, я не вижу в этом инженерной красоты. Chef молодцы, они реально смогли распиарить chef, теперь даже на винде знают, что такое сhef. И даже в компании SAP.

Н.Б.: И даже в компании Microsoft

И.Е.: Да, даже в компании Microsoft , знают, что такое chef. Но при этом инструмент реально, как сказал Умпутун в свое подкасте на радио-т, он этот overengineering. И я полностью с ним согласен - странный инструмент. И если б не определенные условия в которых нам приходится работать, я б выбрал другую систему конфигураций.

Н.Б.: Вань, Я просто думаю, что скоро появиться профессия как программист на ruby, на ruby-on-rails прогаммист.

И.Е.: А, программистр ruby-on-rails, и прогаммист на chef.

Н.Б.: Да, есть на chef, почему б и нет.

И.Е.: Он будет знать все тонкости и принимать их как должное. То есть не задумываться, почему у тебя есть три способа версионирования что-то в chef, а просто вот так. И на любой вопрос у него будут ссылки в голове, куда послать человека, что бы почитать.

Н.Б.: Все, ладно.

И.Е.: Давайте не будем больше эту тему обсуждать она очень провокационная…

Н.Б.: Она больная..

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

Н.Б.: Ты забыл, как они называются просто, да?

И.Е.: Нет, помню, я просто хочу подвести наших слушателей к тому, что помимо банального получения удовольствия от музыки, есть такой момент, как связь с божественным. И когда мы слушаем музыку, мы безусловно связываем наши души с божественным. И компания, которая это делает проще, компания называется между прочем Spotify. И наш старый друг Лев Попов, он работает в компании Spotify в городе фиг знает в каком , в стране… как?.. Щвейцария? Нет?

Н.Б.: Хрен его знает.

И.Е.: Я оставлю как есть, да? Да как называется: Щвейцария или не Щвейцария?

Н.Б.: Щаз посмотрим, подожди…

И.Е.: Но он же говорил, где он живет?

Н.Б.: Я забыл.

И.Е.: Я тоже забыл. Но он, не знай, пишет, где там у него? Стокгольм! Ну елки-палки! Где находится Стокгольм? Швеция! Находится Лев в Швеции сейчас. Мы взяли у него интервью и он расскажет о том, как православный девопс работает в условиях максимально либерализированной страны.

У нас в гостях Лев Попов из Spotify

И.Е.: Здравствуйте, а сегодня у нас в гостях инженер из кампании Spotify Лев Попов. Привет, Лев.

Л.П.: Привет.

И.Е.: Традиционно мы начинаем наше интервью с рассказа о себе. Расскажи, как ты докатился до такой жизни, и вообще как стал инженером и вообще выбрал эту странную специальность.

Л.П.: Ну я с малых лет любил белый экран с черными буковками и как-то так получилось, хотя учился я не на системного администратора. Хобби превратилось в работу.

И.Е.: А на кого ты учился?

Л.П.: Я по образованию инженер в области систем автоматизированного проектирования микроэлектроники. Но я ничего об этом не знаю на самом деле - я учился плохо.

И.Е.: Понятно, ну расскажи как ты попал в профессию, какое было первое место работы.

Л.П.: Я начал работать системным администраторов в 2006 году. Это была позиция дежурного системного администратора в компании Mail-ru. Тогда Mail-ru не сидела в большом красивом здании на Ленинградском шоссе, у них было два маленьких офиса в центре, и я сидел там по ночам и смотрел в систему мониторнга, и если что-то ломалось я звонил более опытным своим коллегам и они это чинили. Иногда не звонил, и они меня потом ругали.

И.Е.: Понятно. И расскажи, как потом там тогда какое-то обучение происходило, то есть можно ли было будучи инженером по мониторингу по большому счету выучить.

Л.П.: В Mail.Ru все тогда не было строго регламентировано. То есть если ты хотел чем-то заниматься, хотел что-то сам чинить, участвовать в каких-то вещах, ты мог смело сказать: ”Позвольте мне, я займусь этой проблемой”. И какие-то вещи я там брал на себя, ну и в дневную смену иногда нам поручали всякую мелочевку. Но я тогда уже немного понимал, как это работает Linux и всякие Unix-системы на уровне школьников старших классов.

И.Е.: Понятно, а дальше? Дальше, я так понимаю, ты пошел в другое какое-то место.

Л.П.: Да, я потом работал 3 года в интернет-провайдере в Зеленограде. Я там начал как администратор и закончил тоже как администратор, но на мне уже было гораздо больше обязанностей. Мы внедрили службы IP-телофонии, потокового видео, занимались всякими сетевыми штуками, я выступал больше в роли сетевого инженера, инженера по IP в то время.

И.Е.: Понятно, а что дальше было?

Л.П.: А дальше нашего маленького провайдера купил большой провайдер Netbynet, и я посидел-посидел дома и подумал: “А не найти ли мне новую работу?” И случайно устроился в компанию Qik.

И.Е.: То есть ты был первый сотрудник у Саши, или не первый?

Л.П.: У Саши уже тогда был Игорь, но Игорь у него работал тогда неделю или две. Но Игорь очень важно сидел тогда. Я пришел, он сидел прям аж будто год там работает.

И.Е.: Ну расскажи, чем ты занимался в компании Qik?

Л.П.: Мы все занимались одним и тем же примерно, в QikЕ был небольшой бардак примерно плане повторяемости конфигураций. Там было несколько десятков серверов, все они были настроены в ручную, и к тому моменту это привело уже к тому, что начинало все ломаться и никто не знал, где это чинить, где это смотреть и как. И мы этот бардак устраняли.

И.Е.: Ну расскажи тогда немножечко, я так понимаю, это достаточно большой опыт для тебя был после QikА ты же фактически в Spotify ушел. Чем занимались, какие-нибудь случаи из жизни - вот такого плана.

Л.П.: В QikЕ я познакомился с configuration management-ом как таковым. До QikА я как таковой уже понимал всякие internal-сетевые, и о том, как там приложения в Linux запускаются, ядро собирал не один раз. Но о том что можно как-то все это ковыряние превратить в код - я не догадывался.

И.Е.: То есть для тебя реально это было открытие то, что происходило в QikЕ.

Л.П.: Но не то чтоб я был этим восхищен. Я подумал какой-то фигней занимаются люди, ладно, за это деньги платят, я тоже займусь. Ну, а потом я понял, что это действительно полезная вещь, и она упрощает всем жизнь, и кроме того на этом можно еще и деньги зарабатывать. И.Е.: Расскажи, какой объем бы исталляций? Сколько машин под chef было, у вас там ведь chef был, да?

Л.П.: Да, у нас там был chef и я точно не скажу. Когда я пришел были десятки машин, в скайпе было может быть 2 сотни, включая окружения. Мы само-сабой обслуживали не весь Скайп, а только наши компоненты.

И.Е.: Понятно, понятно. ОК. Ну давай дальше там по истории и Скайп потом. Qik купил скайп, скайп купил Microsoft и люди почему то из Microsoft стали уходить.

Л.П.: Я б не сказал, что Microsoft это очень плохо, что это зло какое-то, мне в Microsoft даже нравилось. Но я понял в конце-концов, что это не мое. Наш проект начали переводить на платформу Windows Azure - очень классная платформа, всем рекомендую посмотреть на нее, если никогда раньше не слышали. Но линукс-администратору в продукте на Windows Azure делать нечего. Последние полгода я был в Qik тест-инженером, а писал всякие тулзы для автоматизации тестирования на C#. Это был очень интерсный опыт, но после 10 лет Linux-background, это было не очень интересно мне.

И.Е.: Понятно. То есть познакомился с альтернативной системой…

Л.П.: Да, Azure очень классный, C# очень классный и VisualStudio, а вот Windows мне не очень нравится.

И.Е.: А чем конкретно, если уж коли такой вопрос встал?

Л.П.: Это очень сложный вопрос.

И.Е.: У меня понимаешь, похожая история: у меня есть неплохой background в винде, после него у меня уже было 7-8 лет в Linux, сейчас по работе опять сталкиваюсь с виндой. Всегда интересно, когда у тебя есть два опыта и их можно сравнить, и я хотел бы послушать твой.

Л.П.: Я вообще-то не очень разбираюсь в internals винды по сравнению с линуксом. Вообще не очень люблю энтерпрайз-продукты в связи с их повышенной сложностью. То есть complexity операционной системы Windows очень высокая и связана со многими факторами.

И.Е.: Ну, например, что тебе кажется переусложненным?

Л.П.: Мне кажется ,что .NET-framework очень сложный, например, что у него очень много уровней зависимости, что он там долго подгружает библиотеки и т.д. И мало того, я не очень понимаю, как все это работает.

И.Е.: Знакомое чувство. Слушай, а вот powershell тебе удалось поковырять?

Л.П.: Я прочитал пару док, но я не стал разбираться.

И.Е.: Понятно. Ок. Ты решил, принял решение уйти в Spotify. Как вообще проходит процесс переход из Microsoft в Spotify?

Л.П.: Это очень просто переход происходит. Тебя приглашают на работу в linkedin-е. После этого ты проходишь несколько собеседований, проходишь одно очное собеседование, после этого через несколько месяцев перезжаешь работать в Spotify.

И.Е.: А Spotify - у них офис в Стокгольме,да?

Л.П.: В Spotify несколько офисов. У них большие технические офисы в Стокгольме и в Нью-Йорке. Кроме того есть небольшой технический в Гётебурге - это доже большой город в Швеции, и в долине тоже есть офис.

И.Е.: У меня такой вопрос: а на сколько сложное было собеседование в плане устное, то есть что спрашивали?

Л.П.: Всего по чуть-чуть спрашивали. Про Linux internals, про сети, про безопасность, про configuration management, про языки программирования.

И.Е.: То есть такая сборная … кругозор проверяли.

Л.П.: Мне кажется, это такое стандартное резюме. Во первых у меня было три резюме с разными сотрудниками, они шли по возрастающей сложности. То есть первое собеседование было очень простое, а последнее было…ну у меня уже спрашивали вопросы на которые я не знал ответа.

И.Е.: В принципе тебя пригласили без проблем с таким опытом.

Л.П.: Ну да, по собеседованию все остались довольны. Правда тут Puppet-ы не Chef, но в принципе разница не большая.

И.Е.: Кого это волнует …

Л.П.: Да.

И.Е.: Расскажи тогда, мы пришли к самому вкусному - это Spotifу. Во-первых, что там ты обслуживаешь и чем пользуешься…Мы тебя слушаем. Что входит в твои должностные обязанности в первую очередь.

Л.П.: Я нахожусь в команде, которая занимается предоставлением… Надо небольшое отступление сделать по поводу того, как устроена организация в Spotifу. В Spotifу любые сотрудники они находятся внутри, так называемого, сквода. Это некая agile-команда и каждый сквод должен производить какой-то продукт, даже если это системный аминистратор, он тоже должен производить какой-то продукт. Соответственно у каждого сквода есть свои stakeholder, которым важен этот продукт. Соответственно, для системных администраторов - это какие-то разработчики, менеджменты и кто-то еще. Приходят и говорят: ”Нам нужна такая-то фича”. Системные администраторы само-собой не занимаются, большинство своего времени ручным ковырянием. Они предоставляют какие-то инструменты, чтоб разработчики или менеджмент или еще кто мог лучше делать свою работу. Мы занимаемся, нашего сквода, в котором я нахожусь, миссия заключается в том, чтоб предоставлять инструменты для того, чтобы разработчики могли создавать высоконадежные сервисы. Но на самом деле мы занимаемся в том числе и разными сетевыми штуками, занимаемся периметром, занимаемся load balancer-ами. Просто есть некоторые продукты у них у всех есть владельцы, грубо говоря, и мы являемся владельцами какой-то зоны.

И.Е.: Понятно, послушай, а вот сколько скводов, которые к operations относятся у вас в Spotifу.

Л.П.: Много. У нас есть такой.. Скводы все объединяются в трайп. У нас есть IO трайп - это значит “Infrastructure Operations”, и в нем находится больше 10 или 20 скводов, не знаю - много. Туда, в infrastructure operations относятся и база данных и hadoop и транспорт и безопасность и сеть и все это находится в infrastucture operations.

И.Е.: А applications? То есть вы фактически относитесь…есть такие ops-ы, и все остальные девелопмент, то есть какого-то промежуточного больше нету,да?

Л.П.: А что ты имеешь в виду под промежуточными?

И.Е.: Я имею ввиду , что нет отдельных людей, которые отвечают за applications за эксплуатацию.

Л.П.: Нет. Раньше, до меня в Spotifу была модель, когда некоторые operations выделялись внутрь скводов разработчиков. Но сейчас от этого отошли, потому что , если у тебя есть выделенный администратор в скводе, то ты перестаешь запариваться, как там у тебя сервис работает и ты все сваливаешь на администратора, и он становиться инструментом в твоей работе. А наша задача в том, чтоб разработчики сами заботились о своих приложениях, поэтому от этой практики отошли и теперь больше на документацию ссылают разработчиков, чем делают за них что-то.

И.Е.: Ну и как такая модель? Потому что она же менее прозрачная, менее удобная, чем непосредственный контакт.

Л.П.: Непосредственный контакт есть. Т.е. если человеку, ну, например, у нас есть load balancer, и если человек хочет добавить свой сервис на load balancer, он идет на документацию, читает и делает. А если он что-то не понимает, он приходит к нам и говорит: “Ребята, я не могу это сделать, помогите мне пожалуйста”. И мы садимся с ним и делаем, и если чего-то не хватает в документации - дополняем ее.

И.Е.: Понятно. Т.е. все равно это не бюрократия в чистом виде, а “помогающие документы” все. Ясно. А о каком количестве серверов идет речь? Ну, порядок опять же интересует.

Л.П.: Несколько тысяч.

И.Е.: Ох. Т.е. это вот одна приложуха в айфоне и столько жрет?

Л.П.: Ну, многие не понимают, что это какая-то штучка, чтобы слушать музыку, почему там работает больше тысячи человек в этой компании.

И.Е.: Я тоже был уверен, что у вас до сотни. Ну-ка, ну-ка, и как вы обслуживаете эту тысячу серверов, все паппетом?

Л.П.: Все паппетом, с костылями хитрыми.

И.Е.: Ну, давай отсюда подробнее. Потому что puppet при своей клиент-серверной модели, он, мне кажется, загнется, если с одного сервера тысячу забирать у него.

Л.П.: Ну, у нас хитро puppet работает. У нас есть обертка вокруг puppet-а, и puppet берет свой репозиторий не с puppet-сервера, а из git-а. Соответственно, у нас есть некий распределенный git, в который изменения проводятся через gerrit. И, соответственно, puppet забирает из этого git-а репозиторий, и выполняет код в зависимости от роли, которая привязана к серверу.

И.Е.: Т.е. у вас, фактически, подхаченный puppet и клиент, да?

Л.П.: Ну, puppet локальный можно же запускать?

И.Е.: Да, я понимаю, просто а как вы эту информацию о ролях - тоже где-то на серверах храните?

Л.П.: Да, у нас модель такая: на каждый сервер может быть только одна роль, соответственно вообще мы кодируем роли в hostname, но если это невозможно - кладем фактор-файлик, в который записана роль. Еще мы используем hiera, которая, соответственно, определяет, что эта роль должна выполнять, какие у нее есть свойства и классы. И есть puppetdb, в которую мы репортим, если нужно пошарить что-то.

И.Е.: Понятно. А puppet-db это что такое?

Л.П.: Это что-то вроде configuration database.

И.Е.: А, т.е. какое-то центральное хранилище, которое можно из puppet-client-а писать.

Л.П.: Да, можно факты какие-то писать в него.

И.Е.: Ну, я понял, т.е. это service discovery, фактически чтобы был, да?

Л.П.: Service discovery - у нас еще есть другие методы для service discovery.

И.Е.: Отдельно? Ну-ка, ну-ка?

Л.П.: Просто service discovery - у нас не только для configuration management-а, но и в том числе для приложений.

И.Е.: Понятно, еще отдельно существует.

Л.П.: У нас есть свой бинарный протокол, и он поддерживает service discovery через DNS.

И.Е.: Типа scydb или как он называется.

Л.П.: Ой, я не знаю, что такое scydb.

И.Е.: Ну, это штука, которая по dns раздает, service discovery через dns. Не, другая была похожая, skydns- вот!

Л.П.: Неважно, в общем, у нас есть service discovery посредством dns, и это используется не только в configuration management, но и в routing-е сообщений между приложениями.

И.Е.: Ок, а какое количество компонент? Сколько у вас ролей вообще?

Л.П.: Ой, очень много, я могу сказать порядок, дайте посчитаю. Ну, несколько сотен.

И.Е.: Обалдеть. Слушай, у вас есть роли, за которые конкретные команды отвечают. Я правильно понимаю?

Л.П.: Нет, у нас никак роли с командами не связаны. Просто, если ты хочешь сделать какую-то штуку, ты идешь в репозиторий, и создаешь там роль.

И.Е.: Просто понимаешь, даже в голове удержать несколько сотен ролей. Как проблема дублирования решается? Или понимание, что где лежит?

Л.П.: Никак не решается. Они все лежат в одной директории в hiera/role.

И.Е.: А слушай, а если кто-то … Не знаю, наверняка у вас есть много вещей, которые делаются разными способами одно и то же.

Л.П.: Да.

И.Е.: И что, никто не думал над этой проблемой, как ее можно порешать?

Л.П.: Дело в том, что в Spotify модель организации подразумевает под собой максимальную независимость с кодом друг от друга. Каждый в праве выбирать инструмент, которым он хочет пользоваться. Мы не можем помешать какому-то скводу сделать три роли вместо одной, если они это хотят. Т.е. если это не вызывает никакой головной боли, не создает никаких проблем, о которых мы знаем, почему бы и нет?

И, соответственно, поскольку сейчас так технически устроен puppet, каждая команда, если она хочет завести какой-то сервис, она создает роль, заказывает себе через автоматизированные системы машины, на которые эта роль попадает.

И.Е.: Понятно, понятно.

<Вопрос не записан>

Л.П.: Ты имеешь ввиду puppet? Ну, это очень легко. Просто когда review gerrit-а закрыто, она мержится в master-ветку, и по cron-у запускается наш puppet специальный, он снимает последний коммит с мастер-ветки и прогоняет его. У нас практика review такая, стандартная для gerrit+2: когда ты хочешь внести какие-то изменения, ты должен либо попросить либо своих коллег, либо нас проревьюить эти изменения. Если ты поручаешь “+2”, то он прогоняет все тесты, все мерджится, и запускается.

И.Е.: Слушай, а у вас там как бы тестовая площадка существует вообще? Или вы в продакшене, как настоящие?

Л.П.: Для puppet?

И.Е.: Да, для puppet, для configuration management.

Л.П.: Ну, во-первых, у нас есть некий cloud, т.е. мы можем создать виртуалочку и прогнать там puppet. У нас есть в репозитории всякие rake-таски, и мы можем сказать “прогони, пожалуйста, вот на этой машине наш puppet”. Vagrant мы не используем, потому что для разработчиков это очень сложно.

И.Е.: Сложную такую систему в Vagrant-е безусловно не поднять, да.

Л.П.: Соответственно, если ты хочешь, ты можешь очень быстро завести себе машину в облаке, сказать rake, загрузи на такой-то адрес мой puppet, и он загрузит и прогонит его там. Дальше, если ты хочешь провести тест только на одной машине в продакшене, ты можешь также воспользоваться этой rake таской. Или ты можешь запушить в отдельную ветку свои изменения и попросить puppet на серверах применить изменения из твоей ветки.

И.Е.: Т.е. вы можете, в принципе, часть серверов обновить, посмотреть, что будет, да?

Л.П.: Да

И.Е.: Прикольно.

Л.П.: Еще у нас, фактически, все backend-разработчики имеют доступ на сервера рутовый.

И.Е.: Тысяча человек!

Л.П.: Ну, у нас, в нашем офисе, около 500 человек, и они не все backend разработчики. У нас есть мобильная разработка, приложения.

И.Е.: Есть пара сотен точно.

<Вопрос не записан>

Л.П.: Во-первых, у нас есть аудит. Во-вторых, в случае чего, мы просто пере-setup-ливаем машину, и все.

И.Е.: Понятно, но вообще, руками на машину ходите крайне редко, насколько я понимаю.

Л.П.: Мы ходим для расследований, ходим для тестирования puppet-а, для экспериментов каких-то. Но никакой ручной конфигурации у нас нет. Может быть она есть, в каких-то legacy компонентах.

И.Е.: Понятно. А как вы все это дело мониторите? Как вы понимаете, что все хорошо работает в spotify? Т.е. тысячи серверов, что-то на них происходит, вообще ж непонятно.

Л.П.: Это очень сложная история.

И.Е.: Ну, давай начнем.

Л.П.: Когда-то очень давно был zabbix, но сейчас zabbix-ом мы особо не пользуемся, потому что zabbix не может несколько тысяч серверов мониторить. У нас сейчас есть некая своя система.

И.Е.: Поверх чего написанная?

Л.П.: Там есть riemann, для alerting. Есть репозиторий с классными clojure-вскими правилами для riemann, я себе уже голову сломал об этот clojure.

И.Е.: А что, интересный язык, много скобочек.

Л.П.: Да, классный, особенно тесты рефакторить классно в нем!

И.Е.: Не доводилось.

Л.П.: Ну, у нас там примитивно, само собой, у нас там есть тесты на alert-ы, т.е. если ты создал alert, ты можешь написать тест, пожалуйста, сэмулируй сотню таких-то event, подожди, пока придет в почту письмо.

И.Е.: Да, прикольная тема, да. Л.П.: У нас есть PagerDuty

И.Е.: Ну, это понятно, что вы просто роутите дежурного.

Л.П.: Потом у нас есть Kafka

И.Е.: Слышал, но не могу вспомнить, что это.

Л.П.: Kafka - это такой message queue от Apache, я не очень знаю его internals, но суть в том, что все его хвалят, это очень надежная штука, в нее можно писать сообщения, и читать сообщения из нее. И у нас в Kafka очень большая движуха, ходит очень много данных, в том числе мониторинг.

И.Е.: А вот dashboards - вы там графики чем строите?

Л.П.: У нас есть какая-то система, которая не наша, и я первый раз слышал ее название, и не помню, как она называется. И у нас есть еще своя система, которая строит графики.

И.Е.: Т.е. самописная тоже?

Л.П.: Да.

И.Е.: А code dashboard? Или у вас только alerting?

Л.П.: У нас система, которая строит графики, позволяет много графиков на страничку разместить и сохранить это.

И.Е.: Понятно. Но ты названия не помнишь?

Л.П.: Я не помню. Я знаю, что это самописная система. И она не open source, поэтому название я не могу рассказать.

И.Е.: Так, Никита, у тебя какие вопросы еще? А то все молчишь и молчишь!

Н.Б.: Ну, в принципе, по тестированию ты все спросил уже. Слушай, а вы же не тестируете именно puppet?

Л.П.: В тестировании я еще не упомянул одну штуку, что у нас есть тестовая песочница в амазоне. На ней просто прогоняются роли, на которых прошли изменения, что они прошли и они идемпотентны. Два раза прогон проходит, и смотрится, что второй раз никаких изменений нет.

Н.Б.: Т.е. вы поднимаете инстанс, и все приложение туда кладете или как? Л.П.: Там я точно не знаю, это все есть, у нас есть отдельная команда, которая занимается инфраструктурой puppet-а. Там то-ли они уже есть эти инстансы, то-ли уничтожаются и создаются заново.

И.Е.: А у меня такой вопрос, вы тесты пишете на свои рецепты в том числе?

Л.П.: Нет.

И.Е.: Т.е. вы просто это самое …

Л.П.: Да, это самое просто, и все.

И.Е.: Нормальный подход, уважаю. Никит?

Н.Б.: Ну, что, Никит, ты уже спросил про тесты.

И.Е.: Не, вообще идея проверять идемпотентность - это уже, по мне так, немало. Это уже гарантия того, что по крайней мере что-то запускается, и что-то делает, и ничего не ломает.

Л.П.: Да, это вправду очень разумно, потому что я часто встречался с кукбуками, которые написаны людьми, которые не очень заботятся о философии configuration management-а, и это потом приводит к сложностям в понимании.

И.Е.: Слушай, вот как раз, извини, что я тебя перебиваю. Просто это такая большая тема всплыла. Получается, у тебя большой опыт в chef-е, и теперь уже немалый опыт в puppet-е. Можешь сказать сравнительный анализ, что лучше, что хуже, что больше нравится, это, мне кажется, очень интересно.

Л.П.: Я ненавижу puppet.

И.Е.: А почему?

Л.П.: В общем, я с перспективы высокоуровневой, основное отличие chef и puppet - в том, что puppet не позволяет тебе внутри манифеста что-то дописать очень плохое. Если ты системный администратор, который ни разу не видел configuration management, и ты берешь puppet, запускаешь его, читаешь документацию, пишешь манифест. То твой манифест, как правило, будет читаемым и, как это называется, похожим на документацию. Похожим на конфигурационный файл.

Если ты запускаешь первый раз chef, и начинаешь там запускать первый раз рецепт, возможно у тебя получится какой-то очень некрасивый скрипт на руби, который будет делать неизвестно что. В этом смысле puppet лучше …

И.Е.: Я понял, строже как минимум.

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

И.Е.: Ну, я понял, система управления конфигурацией.

Л.П.: В общем, ты пишешь над-конфигурацию, грубо говоря. В puppet-е ты пишешь конфиг для создания конфигов. А в chef, несмотря, что ты так же можешь писать конфиг для описания конфигов на DSL, ты еще можешь добавлять в свои рецепты некую логику.

И.Е.: Я понял, да

Л.П.: Если ты подходишь к этому осторожно и аккуратно, то у тебя получается все очень красиво и гибко.

И.Е.: Слушай, твое мнение прямо совпадает с тем, что я людям рассказываю. Я говорю, что chef позволяет делать костыли, но если это делать аккуратно, то это зачастую делать гораздо удобнее, чем при отсутствии такой возможности.

Л.П.: Я считаю, что я понимаю, что я делаю. Поэтому мне chef более приятен, потому что я могу быстрее сделать определенные фичи там. Например, подготовить данные для выгрузки в шаблоны я могу очень гибко в chef-е. А в puppet-е мне приходится создавать ruby-функции, и потом их непонятно как портировать в код. И сложнее это происходит.

Н.Б.: Слушай, расскажи про такую штуку, ты сказал, что у вас тесты на Amazon-е запускаются, правильно? А сам production у вас на амазоне или на серверах ваших каких-то?

Л.П.: У нас все на железе.

Н.Б.: Т.е. на Амазоне - только тесты.

Л.П.: Ну, у нас есть немножко на Амазоне. Но продакшн фактически весь на железе.

Н.Б.: А с чем связано? Дешевле или что?

Л.П.: Так получилось.

И.Е.: Я думаю, на таких объемах реально дешевле.

Л.П.: Сейчас мы осмысливаем этот подход, но в данный момент все на железе.

Н.Б.: А у вас там какое-то облако? Или вы просто setup-ите машины с инженерами, там, из какого-нибудь Симферополя?

Л.П.: У нас из Симферополя нету, у нас есть 4 датацентра в разных местах, и у нас есть некая автоматизация, т.е. для разработчиков это все прозрачно. Разработчик создает железо, дальше говорит: “Я хочу 5 серверов такого-то типа с такой-то ролью”. Робот сам находит эту задачу, и инсталит это на свободные сервера.

И.Е.: Слушай, а как инсталлит, у вас машинки управляемые что ли?

Л.П.: У нас фактически полностью работа с железом автоматизирована. Т.е. никто не ходит ни в какие api, консоли, никакими ломами ничего не делает.

И.Е.: А ты в курсе, как это сделано, просто любопытно?

Л.П.: Через pxe, через apmi, у нас есть команда, которая занимается разработкой и автоматизацией этих процессов. И у нас есть некие приложения для этого. Т.е. для разработчика, если ты хочешь сделать какой-то кластер у себя, засетапить его на 5 машин, у нас есть определенный набор конфигураций, с такой-то конфигурацией ты просто идешь в JIRA, создаешь задачу, и через полдня у тебя есть твои 5 машин с конфигурацией. Ничего не делаешь больше, все это происходит полностью автоматически.

Н.Б.: Т.е. вы не используете виртуализацию, получается? Т.е. все на реальном железе находится?

Л.П.: В данный момент - да.

И.Е.: Ну, ясно. Ну, у меня на самом деле вопросов больше нет. Если честно.

Н.Б.: У меня, в целом, тоже.

И.Е.: Слушай, может ты нам расскажешь что-то такого … О, расскажи, как Стокгольм?

Л.П.: В Стокгольме хорошо.

И.Е.: Плюсы, минусы? Ты жил получается не в Москве, в Подмосковье, но все равно.

Л.П.: По сравнению с Москвой, Стокгольм очень маленький, это вообще деревня какая-то.

И.Е.: Т.е. прямо ощущается, да?

Л.П.: Ну, по сравнению с Подмосковьем - не очень. По сравнению с Москвой - да. Тут гораздо меньше людей, и гораздо меньше площадь города. По погоде, в принципе, погода как в Питере, не сильно отличается. Белые ночи, и зимой очень короткий день. Но зимой мне еще не довелось пожить.

И.Е.: Понятно. А вот по ценнику на квартиру, на аренду квартир, на еду.

Л.П.: Квартиры стоят примерно как в Москве - аренда, может даже подороже чуть-чуть. По еде - еда, в среднем, дороже в полтора раза. Стокгольм - вообще, не самый дешевый город.

И.Е.: Понятно. Но он аккуратненький, симпатичный, т.е. тебе нравится там жить, да?

Л.П.: Пока я до сих пор себя чувствую как турист, и меня все устраивает.

И.Е.: Понятно, т.е. ты еще не ассимилировал.

Л.П.: Нет, еще пока нет.

И.Е.: Т.е. с коммунальными службами еще пока не сталкивался.

Л.П.: Ну, я когда квартиру в Москве снимал - тоже не особо сталкивался с коммунальными службами.

Н.Б.: А ты как планируешь - там совсем? Или как?

Л.П.: Я еще пока не решил. Но пока как минимум - это очень интересный опыт. А еще по поводу Стокгольма. Если кто-то боится Шведского языка, то Шведский язык, в принципе, если ты хочешь работать в Стокгольме - не очень нужен. Потому что все Стокгольмчане говорят на английском, и IT компании, как правило, тоже говорят на английском.

И.Е.: А население какое, не знаешь, у Стокгольма?

Л.П.: Около 2 миллионов

И.Е.: Да, небольшой город, разница заметна будет с Москвой.

Л.П.: Стокгольм еще по площади сильно меньше места занимает. Т.е. в принципе, с учетом агломерации он похож на Москву и ближайшее Подмосковье, но плотность населения гораздо ниже.

И.Е.: Ага, понятно. Т.е. ты пока дальше еще не думал, что там поработать в какой еще компании ты бы хотел там?

Л.П.: Ну, я недавно здесь, я еще 2 месяца работаю в Spotify, поэтому не собирался.

И.Е.: Ну, да, тебе еще пару лет хотя бы надо, чтобы привыкнуть.

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

И.Е.: Да, это волей-неволей придется сделать, хочешь или не хочешь.

Н.Б.: Слушай, а почему Стокгольм, почему не Нью-Йорк?

Л.П.: Ну, меня пригласили в Стокгольм. Во-первых. Во-вторых, в Америку у меня были возможности уехать в другие компании, в ту же Калифорнию, но это слишком далеко. Тут я сел на самолет, и через 2 часа я в Москве. В Нью-Йорке у нас тоже неплохо, но все равно это далековато. И когда меня набирали, в Нью-Йорке не было вакансий у Spotify.

И.Е.: Ну, что ж, у меня тогда вопросов больше нет, если у тебя есть какие-то пожелания, слова для наших слушателей, то вот у тебя прямо свободное время.

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

И.Е.: Ясно. Ладно, Лев, спасибо тебе большое за интервью, давай, до новых встреч.

Н.Б.: Пока.

Л.П.: Да, спасибо, пока.

Н.Б.: Мы забыли с тобой записать начало.

И.Е.: Я записал начало, не поверишь.

Большое спасибо Льву за его интересное интервью, ну, и, перед тем, как мы закончим, последняя новость на сегодня. В среду, в компании Badoo пройдет meetup очередной, devops meetup, в котором будет участвовать, вы не поверите, один из сотрудников компании Docker, а именно, Jérôme Petazzoni. По-видимому, он итальянец. И он расскажет, собственно, что такое docker из первых рук. К несчастью, если даже номер подкаста выйдет раньше чем meetup, вы все равно не сможете туда попасть, потому что места туда закончились, вместимость зала в Badoo не такая большая. Но, тем не менее, мы обещаем… Что мы обещаем, Никита, с тобой?

Н.Б.: Мы обещаем, что запишем интервью с этим прекрасным человеком из компании Docker.

И.Е.: Jérôme

Н.Б.: И сделаем отдельный выпуск, который будет состоять только из этого интервью

И.Е.: Практически без новостей.

Что ж, дорогие друзья, большое спасибо, что слушали наш подкаст. С вами был 14 выпуск подкаста Devops Deflope, и с вами его постоянные шеф-повара Никита Борзых

Н.Б.: И немного пьяный Иван Евтухович.

И.Е.: До новых встреч, пока!

comments powered by Disqus