- 012 - Юбилей
Текстовая расшифровка подкаста
Новости
- NixOS и Хаскель
- Навигатор log файлов
- Стоит ли учить Chef под Windows
- Бета-релиз chef-container
- Так ли надежен ElasticSearch
- Вышел ChefDK 0.2.0
- Отчет PuppetLabs о полезности DevOps
- Windows PowerShell DSC в Linux
- Кукбук DSC
- Список инструментов Прикольный Сисадмин
- Убивает ли DevOps кого-нибудь?
- Тестирование кукбуков в цифровом океане
Обсуждение
Год в эфире
У нас в гостях Тимур Батыршин
Расшифровка
И.Е. : Здравствуйте. В эфире 12й выпуск подкаста DevOps Deflope, с вами постоянные шеф-повара Никита Борзых и…
Н.Б.: Иван Евтухович.
И.Е.: Сейчас мы приготовим вам новости. Совсем недавно мы обсуждали тему NixOs у нас в подкасте, и не только NixOs, а и самого сборщика Nix. И вот вышла статья не так давно от человека, имя которого произнести невозможно, которая называется: “Мой опыт с NixOs”. Собственно говоря, он разработчик на Haskell, и пишет о том, что в Haskell есть достаточно большая проблема, что есть разные версии Haskell, и с ними достаточно сложно вместе работать, разные версии пакетов. И поэтому NixOs для него подошел прям идеально, потому что он позволяет собирать изолированные окружения для разных Haskell с разным набором пакетов. Он говорит, что для похожих задач в Haskell есть свой инструмент, но гораздо более сильно ограниченный. И, в целом, довольно обширная статья о том, что такое NixOs, немножечко можно понять, как им пользоваться. Поэтому, если вы еще не пользуетесь NixOs, то можно уже начинать. Потом он пишет что поставил его на лэптоп, на ноутбук на свой, и пользуется с ней в повседневной жизни.
Н.Б.: На просторах интернета была найдена статья под названием: “lnav”. Как понимаю дословно - log-navigator. Это маленькая программа, которая позволяет просматривать логи, в том числе все системные или от Apache не важно, и подсвечивать их по некоторым паттернам. То есть, если в логах у вас есть pid-процесса, то он под pid-ом будет подсвечивать все строчки, которые в этом логе есть. Это очень удобная вещь, ее можно использовать не только для логов, но и для какого-нибудь markdown-а, он тоже его понимает. Достаточно неожиданно для нас это было найдено, посмотрите, возможно вам понравится.
И.Е.: В блоге компании Chef вышла статья : “Стоит ли учить Chef?”. Собственно говоря, статья написана, человеком, который занимается интеграцией Chef-ов в Windows-мир. И он говорит о том, что в Windows, уже есть так называемая DSC (Design State Configuration), инструмент тоже для управления конфигурацией. И автор статьи Стивен Бурански, он пишет, что он работал раньше в Stack Overflow, как раз занимался интеграцией Chef на Windows-системах, И он пишет, что DSC, пока достаточно молод и многие вещи не покрывает, которые может делать Chef. Это говорит о том, что Chef гораздо сильнее вперед продвинулся. И более того, есть достаточно удобный способ интегрировать эти оба инструмента и, поэтому, безусловно, следует учить Chef.
Стоит ли учить Chef под Windows
Н.Б.: 15 июля вышла бета-версия Chef-контейнер, Это набор инструментов от компании Chef, которая позволяет контейнеризировать ваш Chef-клиент, то есть она запихивает в докер сам Chef, run-ит скрипты для запуска Chef-а. Удобная вещь, если вам нужно быстро и легко готовить Chef в докере или любом другом контейнере.
И.Е.: А уже полюбившийся нам автор Aphyr, написал очередную статью, которая называется: “Call me maybe: ElasticsSarch”. Кто не знаком с этим автором, он берет популярные системы хранения данных, в основном open source-ные, только open source-ные, и проверяет их на соответствие CAP-теореме. Статья длинная, безусловно очень интересная, он проверяет там разные виды разрыва сети, для трех, для пяти нод, с разными параметрами ElasticSearch. И пишет, что ElasticSearch, как хранилище данных, безусловно УГ. Огромная потеря данных у него происходит, и более того, он говорит, что в документации не отражены конкретные моменты, что будет, если допустим то-то и то-то упадет? Опять же ругается он на создателей ElasticSearch за то, что они сделали какой-то свой собственный какой-то алгоритм выбора кворума, если вы понимаете о чем я. И он говорит о том, что существует математически доказанные популярные алгоритмы, которые реализованы в нормальных системах, ElasticSearch решил пойти собственным путем, и сделал алгоритм, который не во всех случаях работает. Иногда может сделать так, что будет два кворума в распавшейся сети. В целом, он говорит, что ElasticSearch крут для поиска, и он его использует, но как хранилище данных — пока никому не рекомендует его использовать, как основное хранилище данных. Мне понравилось, что в конце в комментах появляются разработчики ElasticSearch, и там возникает достаточно конструктивная дискуссия, по мне так это очень здорово. И, в любом случае, если вы еще не читаете блог Aphyr-а, то вам срочно надо начать.
Н.Б.: Так же 15го июля вышел ChefDK 0.2.0. В этой версии появилась поддержка Windows, всеми ожидаемая. Так же появились некоторые дополнительные утилиты, которые позволяют выполнить… что-то типа bundle exec. Но это не так интересно, как поддержка Windows. Поддержка Windows там работает, я лично проверял, это просто прекрасно.
И.Е.: Тем временем PuppetLabs не спит, и, помимо того, что делает свой Puppet и разные приблуды к нему, они также сделали отчет о полезности DevOps. Это достаточно большой 30-ти страничный документ в формате pdf, в котором обобщены результаты опроса. Если мне не изменяет память, они опросили более 9 тысяч специалистов по всему миру. И вывод у них такой, что команды которые используют DevOps внутри у себя, DevOps-практики у себя выделили, в среднем компании, в которых это происходит, имеют на 50% больше прибыль и обычно имеют большую долю рынка. Их мысль сводится к тому, что производительная инфраструктура IT, она так же позитивно влияет на компанию. Вывод несколько спорный, тем не менее, достаточно много интересных цифр в этом отчете. Если вы должны продать кому-то DevOps, то есть какие-то новые подходы в разработке, то этот отчет - хорошее подспорье.
Отчет PuppetLabs о полезности DevOps
И.Е.: Вы будете смеяться, но поддержка Windows PowerShell Desired State Configuration (DSC) - это расширение PowerShell для управления конфигураций, теперь будет работать и под Linux. То есть, как Chef идет на Windows, так и DSC идет на Linux. И это, мне кажется, очень круто. И в сфере предыдущей новости о том, что ChefDK теперь работает под виндой. Вот у нас есть и другой инструмент от винды, который работает под Linux. Понятно, что сейчас достаточно много гетерогенных систем, которые используются в разных операционных системах и Windows и Linux, и вот такое распространение различных инструментов управления конфигураций в оба мира, из одного мира в другой, и из мира Linux в мир Windows в том числе, это очень и очень здорово.
Windows PowerShell DSC в Linux
И.Е.: И чтобы два раза не вставать, следующая новость о том, что вышел кукбук, который называется DSC. Это как раз кукбук для Chef, который позволяет на винде разворачивать DSC, настраивать его как-то и запускать скрипты, которые управляют конфигурацией. Как пишут в блоге компании Chef, что пока он - ранняя бета-версия, и он скорей как design of concept, и просят конечно фидбек люди, которые этим пользуются, писали им. Но тем не менее, направление ясно - там, где возможно пользоваться родными инструментами Windows, это именно DSC, будет использоваться он, а Chef, будет использоваться, как доставщик этих изменений. И будет тесная интеграция этих двух инструментов и это, мне кажется, очень здорово.
Н.Б.: На github-е появились отличные репозитории, которые называются “Awesome sysadmin”. В общем вот в это репозитории есть все лучшие практики, по почти все вопросам для системных администраторов. Начиная от backup-ов и заканчивая cloud computing. Там есть про Chef, про настройку vpn-ов, про всяческие ldap и т.д. и т.п. В целом, я посмотрел несколько ссылок - очень достойно, я думаю что мы еще с тобой это, Ваня, обсудим в наших обсуждениях, там есть о чем поговорить.
И.Е.: Есть о чем поговорить, безусловно, да.
Список инструментов Прикольный Сисадмин
И.Е.: И статья, мимо которой было нельзя пройти, безусловно, появилась в блоге компании CFEngine. Это значит, что CFEngine еще жив. Как минимум. Хотя, конечно, будучи первым, он рынок, в районе конфигурации, упустил, сильно упустил. Автор статьи, Jonathan Thorpe, пишет о том, что… Вообще, статья называется “Убивает ли DevOps кого-нибудь”, и это продолжение дискуссии, что “DevOps killing operations”, “DevOps killing developers”. Но, на самом деле, он пишет, что, во-первых, DevOps никого не убивает. Потому что DevOps - это не title, не название должности, это концепция о том, как должны взаимодействовать между собой различные подразделения бизнеса.
И он говорит о том, что с точки зрения этого подхода, полезно разработчикам хотя бы день в месяц, несколько месяцев, провести на месте сисадмина и побыть рядом с ним, и, возможно, даже какие-то его дела поделать. Тогда многие вопросы, которые возникают, конфликты, которые возникают между разработчиками и сисадминами, - становится понятно, почему это происходит. И, говорит, наоборот, operations, надо иногда проводить время с разработчиками, чтобы он понимал, что творится на той стороне баррикад. Тогда будет понятно, почему мнение о том, что разработчики “всякую каку” тянут в продакшн, а сисадмины стараются, чтобы ничего не менялось, и не любят ничего делать - тогда обе стороны станут более лояльными друг к другу.
Идея прикольная, и статья написана достаточно живым языком, так что рекомендую.
Убивает ли DevOps кого-нибудь?
Н.Б.: В сети появилась отличная презентация от сотрудника Chef-а, которая описывает, как тестировать кукбуки, с помощью Test Kitchen-а, и все это выполнять в цифровом океане Digital Ocean. Идея какая, чтобы прогонять интеграционные тесты не локально в Vagrant-е, а все это делать в каком-то облаке. По аналогии с цифровым океаном можно использовать Amazon, любой облачный провайдер, потому что Test Kitchen-а есть плагины почти ко всем обычным провайдерам. Достаточно огромная презентация, 118 слайдов, и в ней самое интересное - как в TravisCI это все запихнуть - не рассказывается, к сожалению. Но все равно если вы еще тестируете локально, то обязательно посмотрите эту презентацию.
Тестирование кукбуков в цифровом океане
И.Е.: А новостей на сегодня больше нет.
И.Е.: Никита!
Н.Б.: Так?
И.Е.: 5 июля 2013 года вышла первая Дефлопе.
Н.Б.: Афигеть.
И.Е.: Я открыл как раз страничку. Как сказать. Да, оно очень похоже на то, что сейчас. То же Дефлопе, правда, первый выпуск был всего лишь 18 минут 40 секунд. Сейчас мы, все-таки, в среднем 40 минут выдерживаем. Год в эфире!
Н.Б.: Это прекрасно, я считаю.
И.Е.: Это прекрасно! Я считаю, что мы молодцы, хорошо работаем, и заявленный план “выпуск в месяц” худо-бедно выдерживаем.
Н.Б.: Ну, как худо-бедно. Выдерживаем!
И.Е.: Мы должны тогда были выпустить это выпуск, который мы сейчас записываем, 5 июля, а уже …
Н.Б.: Нет, не должны были
И.Е.: Почему?
Н.Б.: Потому что у нас до этого был выпуск, который мы должны были выпустить 5 июля, мы выпустили его 11-ый.
И.Е.: Не, подожди. 12 штук должны в год выпускать, нет? Год прошел, а мы выпустили только 11. Все-таки, мне кажется, мы немного выбиваемся из графика.
Н.Б.: Но мы нагоним в любом случае, это не проблема.
И.Е.: Либо не будем догонять, это не так важно.
Н.Б.: Будем.
И.Е.: Дефлопе, у него нет задачи выходить первого числа каждого месяца. Это же все-таки, подкаст настроения.
Н.Б.: Ладно, хорошо, убедил.
И.Е.: Ладно. А что яркого тебе запомнилось за этот год?
Н.Б.: ChefConf - считать или не считать?
И.Е.: Да, мы тоже освещали в нашем подкасте поездку на ChefConf. Я думаю, что, действительно, это должно было быть ярким.
Н.Б.: Да, это очень было ярким. Еще из того что запомнилось - это тоже после ChefConf-а случилось, когда Chef указал свой путь, свой way. Berkshelf, ChefDK, все остальное.
В тринадцатом году, наверное, уже ничего не вспомнишь. Может ты что-нибудь вспомнишь?
И.Е.: Не, я не думаю, судя по заголовкам новостей, не так сильно все поменялось. Устаканивается отрасль, и каких-то этих самых ждать не стоит.
Н.Б.: С начала 14 года это только стабилизация каких-то утилит, которые были выпущены, и популяризация их. Больше ничего такого особого не произошло.
И.Е.: Ну, да, и 2013 год я бы назвал годом immutable server, неизменного сервера. Т.е. это старт docker-а, по большому счету.
Н.Б.: Да, все правильно.
И.Е.: Вот, собственно, и все, что прошло за год. Что ж, было много интересного за год, но мы не собираемся останавливаться на достигнутом. Знаешь что сделаем с тобой, у нас есть просто человек, который постоянно нас комментирует на сайте подкаста, это Тимур Батыршин, и мы возьмем у него интервью.
Н.Б.: Давай.
И.Е.: Здравствуйте, сегодня у нас в гостях Тимур Батыршин из компании Cinarra. Привет, Тимур.
Т.Б.: Привет всем.
И.Е.: Расскажи Тимур о себе, т.е. как ты пришел в IT, и свою карьеру в IT.
Т.Б.: Как многие другие, я еще со школы начал интересовать компьютерами, писать какие-то простенькие программки. Карьера программиста что-то не сложилась, не пошел сразу туда. Позже уже вернулся, естественно, … Позже уже возвращаться к программированию стало не очень просто и я начал заниматься админством. Первое время мне в этом очень помогло altlinux , в свое время я держал там пару десятков пакетов…
И.Е.: Подожди, подожди, а это какие были года? Потому что я помню…
Т.Б.: Это было где-то… с altlinux я начал работать с 2007 по 2010 наверное. Это была замечательная школа, по тому что должно, как оно…
И.Е.: Да я понял уже, простоя тоже пару пакетов поддерживал в свое время, но это было уже очень давно, где-то 2003-2004.
Т.Б.: Ну, вот про те годы я слышал, что очень хорошее время было, очень хорошая школа тому что как нужно делать, как не нужно делать.
Н.Б.: Подожди, а у тебя была такая огромная коробка с надписью “От Linux-мастер”, или что-то такое, оранжевого цвета.
И.Е.: Не, не было.
Т.Б.: Я уже все скачивал по сети только. Потом я сменил работу, а там уже altlinux уже не пользовались, и постепенно я начал заниматься тем, чем сейчас, теми вещами которые относятся к движению devops. Так продолжаю и дальше.
И.Е.: Понятно, а компания, в которой ты сейчас работаешь? Расскажи, чем вы сейчас занимаетесь, чем компания занимается, и чем ты в ней занимаешься?
Т.Б.: Компания строит платформу для мобильной рекламы, та что на сайте есть - можно прочитать, большего я рассказать не могу. Я занимаюсь тем, что организую процесс движения кода от разработчиков до production, и всеми сопутствующими делами: мониторинг, создание конфигураций и т.д.
И.Е.: Давай об этом поподробнее: какой размер команды разработчиков и operations?
Т.Б.:В общей сложности десятка два человек, может, поменьше. Это стартап по сути. И до того, как я туда пришел, как это часто бывает, задачи администрирования серверов там выполняли кто получится. Поэтому было не очень хорошее состояние всего этого дела. Сейчас потихоньку начинаю все приводить в порядок. По сути серверами сейчас я занимаюсь один.
И.Е.: Понятно. А чем пользуешься: Chef, Puppet, ansible, soltstack…
Т.Б.: Я понял. Пользуюсь Chef. Я недавно осмотрел запись с последнего meetup, где была битва между Chef, Puppet, ansible, solt. Мне очень понравилась фраза Кирилла из Злых Марсиан, что Chef вливает гигантские деньги, поэтому на сегодняшний момент лучше всего пользоваться им. Я подумал, что так оно и есть, в том плане, что его можно как хочешь масштабировать, у него будут появляться новые возможности. Ну и конечно он требует новых вложений в это. В том плане, что его нужно сначала изучить, он же сложнее, чем например тот же ansible. И постоянно приходиться быть в теме, чтобы ничего не ломалось, новые разработки Opscode ничего не ломали в существующей инфраструктуре.
И.Е.: А уже сталкивался?
Т.Б.: Мне, например, в Berkshelf не понравилась штука, постоянно какие-то зависимости с ним разъезжаются, сейчас думаю надо обратно перейти к тому, что бы скачивать кукбуки в папочку “Cookbooks” и заливать их отдельно, потому что с Berkshelf как-то грустно все это.
Н.Б.: Поподробнее расскажи, пожалуйста, что у тебя именно не работает, поскольку у нас огромные дискуссии в компании по поводу Berkshelf. Скажи свои проблемы, с какими сталкивался ты.
Т.Б.: Ну, вот он как-то странно резолвит зависимости. Т.е. я в одном кукбуке прибил гвоздями зависимость на кукбук supervisor, который у меня модифицированный, другой кукбук ссылается, соответственно, на первый, инклудит его и вытаскивает совершенно какую-то другую версию с chef-супермаркета. Это один вариант. Потом при upload-е кукбука, когда делаешь berks upload, он, например, переписывает metadata.rb в metadata.json. И если потом ты что-то там вручную правишь, пытаешься залить, он что-то там… то ли обязательно надо версию поднимать, что бы она применилась, то ли наоборот: если версию вручную поднимешь, она плохо применяется. Это я так и не понял, поэтому я сейчас стараюсь без особой нужды Berkshelf-ом не пользоваться. Т.е. заливать только зависимости, которые он вытягивает, а все остальные кукбуки заливать классическим способом knife cookbook upload.
Н.Б.: А сколько у вас команда ops-ов?
Т.Б.: Я один пока . И я думаю, это достаточно долго продлиться.
И.Е.: А как ты относишься к тому, что… с моей точки зрения Opscode форсит Berkshelf и инструмент действительно странный. Он конечно многие проблемы решает, но…
Т.Б.: Мне кажется, что в Opscode достаточно такая разнородная команда, и какая-то часть - совершенно вменяемые люди там, очень хорошо все делают, а какая-то часть именно создают излишнюю движуху и оставляют осадок в виде разломанных вещей или может быть даже…незнаю…недопонимание с ними. Какое-то странное у них движение в этом отношении. Конкретно имена не буду называть, чтоб не создавать нехорошее мнение о них.
И.Е.: Никите, наверное, по этому поводу есть что сказать, но молчит.
Н.Б.: У меня есть что сказать, я был из тех людей, который форсил Berkshelf у нас, в целом то, что ты описал. Вторая проблема - это не баг, это фича. Ты должен увеличивать версию metadata при заливке. Если ты хочешь тестовую залить, то ты можешь написать - “позволить заливать со старой версией, не фризить кукбук” там есть такая опция. А с первой проблемой надо просто разбираться, я думаю это все решается.
Т.Б.: Ну, да, я там просто прибил во всех зависимых кукбуках, которые тот вытаскивает гвоздями в metadata в берк-файле нужный кукбук и все.
И.Е.: Да, такая версия, я согласен, достаточно сложная.
Н.Б.: Просто они форсят Berkshelf, они юзают Berkshelf во всех утилитах которые в Opscode форсит. Т.е. например, тот же Test Kitchen для тестирования, там интеграция с Berkshelf просто зашкаливает. Test Kitchen использует Berkshelf чтобы резолвить зависимости именно для тест кукбуков. Это один из примеров. Тот же ChefSpec использует Berkshelf чтобы резолвить кукбуки, которые нужны для тестирования. Понятно, что Opscode, извиняюсь, Chef-компания, его сейчас будет форсить и улучшать. но я насколько знаю там ребята типа Seth Vargo активнейше просто коммитят в Berkshelf - помогают ребятам. Они спрягают то , что написано в Opscode с тем что есть в Berkshelf. Я думаю, что он от года …, от месяца к месяцу будет все лучше и лучше в этом отношении.
Т.Б.: Может быть - да. То есть если применять подходы, которые они предлагают, т.е. test run кукбуков Test Kitchen-ом, с разработкой с использованием Test Kitchen, тогда в принципе - нормально. Но если более-менее по старинке разрабатывать, скажем создаешь Vagrant, туда диплоишь кукбук с тестовым environment, допустим, делаешь какие-то правки, пушишь его на сервер, в Vagrant прогоняешь еще раз - то это уже немножко не очень удобно работает.
Н.Б.: Для такого способа есть же Librarian, достаточно старый и usecase как раз покрывает.
Т.Б.: Ну да, сейчас у меня в планах перейти как-раз на него, пока не до этого, потому что я сначала решил использовать Berkshelf потому, что раз сами они его предлагают, значит у них там с этим все круто. А вот не совсем так, оказывается. Если полностью их в workflow использовать, то тогда скорее всего все работает, но если другие какие-нибудь пути, то тогда уже не так уж удобно получается.
Н.Б.: Может быть - да.
И.Е.: Из последнего - отломали… как его? Chef Zero от Vagrant отломался. Перестал работать плагин в Vagrant.
Н.Б.: По-моему уже починили? Нет?
И.Е.: Уже починили, но я не смотрел.
Н.Б.: Ну это общая проблема. Когда выходит новый Vagrant, особенно, когда выходит 1.6, 1.5 - версии, то начинаются всяческие проблемы с плагинами. Но я знаю, Vagrant-berkshelf очень быстро починили.
И.Е.: Тимур, ты говорил - мониторите вы, а чем пользуетесь вообще в мониторинге?
Т.Б.: Мониторинг я еще пока не допиливал, до меня тут стоял nagios, и opentestdb для сбора метрик. Работает пока, но я планирую посмотреть в сторону influxDB или еще каких-нибудь решений вместо opentestdb. Вместо нагиос посмотреть на какой-нибудь riemann, например, потому, что часто бывают такие случай, когда один триггер должен зависеть от какого-нибудь состояния на другом сервере, в нагиосе это по-моему не очень просто делается, я с ним не очень хорошо знаком, конечно.
И.Е.: А чем обычно пользуешься?
Т.Б.: Раньше я постоянно работал с zabbix, у zabbix это плюс хороший, что ставишь его, он в коробке триггеры какие-то делает, графики рисует. В общем, эта вещь такая, что ее правильно уметь надо готовить, совсем не просто, в самом деле. Там надо как-то оптимизировать хранилища, сбор метрик, иначе там моментально раздувается база, начинает все там тормозить. Я сейчас не сторонник zabbix стал по этой причине, благо много разных таких решений появилось за последние два-три года.
И.Е.: Ну да, сейчас много чего появляется, и одна большая проблема, что все это надо интегрировать - требует времени. Все таки в zabbix есть большой плюс, что из коробки раз, и все, там все уже есть.
Н.Б.: Но есть большой минус у zabbix, что чуть шаг вправо шаг влево из этой коробки и уже ничего не работает.
Т.Б.: Т.е. , если быстро надо поставить мониторинг дисков, процесора, каких-то процессов - zabbix самое то, если хочется собирать кучу метрик совсем разных и еще каких-нибудь там между ними зависимости делать, или еще какие-нибудь такие вещи - не очень простые, то в zabbix - это уже не очень-то просто будет сделать.
Н.Б.: Зависимости, как раз-то и можно делать в zabbix, но я согласен - более сложные вещи, особенно если ты autodiscovery настраиваешь, то там совсем все плохо с этим.
И.Е.: Тимур, ты говорил что у тебя есть машинки под ansible, какой-то опыт есть.
Т.Б.: Да, я последний год, перед тем как присоединился к этой компании, занимался чем-то типа фриланса, одному заказчику я управлял сервера ансиблом. Там была такая ситуация, что сервера были не совсем их, они как бы админили сервера, и соответственно туда вставить какие-нибудь Chef-клиент или что-то вроде такого не хотелось. Ну и я решил заодно попробовать для этого ансибл, ну мне ансибл понравился, у него тоже есть какие-то проблемы. Сложные модификации не очень просто делать, еще что-то вот такое, но он достаточно простой. Быстро ставится, его можно, например, как-то под себя изменять, хотя я не пробовал, конечно. Легко можно дописывать, например, можно провайдеры дописывать, на любом языке, не обязательно на питоне, inventory можно подключать к чему угодно, так как это либо текстовый файл, протокол типа json.
И.Е.: А вот твое ощущение - порог входа в Ansible и в Chef, ты заметил разницу? На сколько я понимаю, в Ansible надо гораздо меньше.
Т.Б.: Да, когда ты ставишь Chef, тебе надо поставить сервер, кучу всего там вытаскивать, кучу каких-то дополнительных сервисов. Хоть все это и автоматом, но все равно. Потом кукбук создаешь, в кукбуке штук десять разных видов папочек. И когда читаешь документацию, первый раз, когда я с ними сталкивался, просто начинаешь путаться: зачем тебе definitions, провайдеры, ресурсы, рецепты и так далее - как этим всем пользоваться. А в ансибл они в общем-то такой же простой подход к документации выбрали, примерно как в Puppet. Они сначала показывают достаточно простые, элементарные операции, допустим - как нам перезапустить сервер, как создать конфиг, потом возле этого уже выводят понятия ролей, переменных и так далее. В этом ансибл намного проще.
И.Е.: Тебе, как инженеру не показалось, что ансибл изящнее чем Chef?
Т.Б.: Смотря для чего. Если тебе нужно накатить какую-нибудь конфигурацию, достаточно простую, то он нормально, хорошо работает. В Chef можно более сложные вещи делать - абстракции просто писать. Ансибл больше не только как инструмент для конфигураций, а как инструмент для выполнения действий на сервере. Что мне в нем понравилось, там есть такая инересная штука, в Chef у тебя есть run-list для хоста. Ты его берешь и применяешь весь на сервере, у тебя вариантов мало и приходится условия у атрибутов делать. А в ансибл можно создань несколько роль-листов и применять в разное время только нужное. В этом он делает Chef полностью.
И.Е.: В этом он погибче, понятно. Про что нам еще поговорить с тобой? О чем обычно говорят devops culture - поговорили. Automatization - поговорили. Мониторинг - поговорили… Расскажи как у вас построен процесс передачи кода от разработчика до production?
Т.Б.: Пока не совсем построен, как раз в процессе, как часто бывает тестовые настройки Jenkins собирает пакеты и потом как-то они ставятся. Сейчас просто Jenkins пока не трогал, он так же собирает пакеты, не очень правильно, на мой взгляд. Сейчас приходят к тому, что допустим я создаю хост, применяю в роли Chef и он разворачивается - как обычно, В планах - туда добавить нормальную сборочную систему, нормальные для всего этого дела мониторинг.
И.Е.: Понятно, а ты давно в этой команде?
Т.Б.: Два месяца, я только пришел практически.
И.Е.: Просто сложный вопрос о том, как технические решения принимаются. Буквально недавно я разговаривал одним руководителем техническим в достаточно большой компании. И вот он рассказыват, что у него зоопарк систем, и там видно, когда на highload появляется новая система, например, mongodb, все, говорит, у нас в этом в этом году появляется mongodb на серверах. На следующий раз на highload приехал какой-то чувак рассказал про ZeroMQ - все, говорит, у нас ZeroMQ стоит. И вот проблема в том, что эти решения принимаются только разработчиками и operations не участвуют в принятии решений о выборе новой технологии. И как у вас, эта проблема стоит? Как она решается , или не решается?
Т.Б.: Я считаю, что это прямой долг, если себя называешь занимающимся devops, это твой прямой долг в этом участвовать. Если ты знаешь, что какая-то технология - это ничего хорошего, нужно вовремя отговаривать, либо сказать что вот это и это предусмотрите. Здесь у нас пока не совсем понятно - система достаточно сложная в нее полностью не въехал еще. Как devops-инженеру, я считаю, что надо активно всегда в этом участвовать, вешать баги на приложения, если оно как-то неправильно работает, какие-то требования выдвигать со стороны, которые нужны для operations, и соответственно какие-то архитектурные вещи учитывать. Например, какая-то база плохо масштабируется, или какие-то проблемы с ней есть, об этом надо тоже, естественно, дать знать разработчикам как можно раньше.
И.Е.: У меня такой еще вопрос. А как у вас инциденты возникают вообще? Рroduction есть или вы пока еще только тесты в этом самом…
Т.Б.: Да там есть типа что-то пре-production…
И.Е.: У вас т.е. ничего не работает… Только для показа, я так понял.
Т.Б.: Инциденты конечно возникают, но пока нечем здесь гордиться, пока перепутано все, исторические причины до сих пор еще действуют.
И.Е.: Сейчас ты в новом, а до этого ты работал в готовых больших проектах, где интереснее с твоей точке зрения?
Т.Б.: На самом деле я в больших проектах и не работал.
И.Е.: Что считать большим проектом - не важно, ок.
Т.Б.: Я имею ввиду и в готовых особенно не работал. В Flatstack, в котором я работал три года назад, там поддерживали проект по-сути начинающийся у них тоже в production был для западной компании. И последний год я с GeoGrep работал, там тоже вся operations сторона была в таком вот зачаточном состоянии. Как обычно, разработчики как умеют, так диплоят и тоже практически строил. Т.е. это интересно поработать бы в компании, где уже хорошая такая команда. Но в Казани такой хорошей operations-команды, которая поддерживает проекты рабочие, но в Казани я подходящего для себя не нашел, переезжать - другое дело.
И.Е.: Понятно. Тогда, для тебя последний вопрос, что посмотреть в Казани, если вдруг окажемся?
Т.Б.: Казань. Кремль у нас есть. Построили на берегу Казанки ЗАГС новый огромный, специфического вида. Что еще… Трудно сказать. Я не слежу, что там у нас нового. Дороги вот построили.
И.Е.: Владимир Владимирович у вас приезжал что ли?
Т.Б.: Нет у нас Универсиада была в прошлом году, и сейчас с одного конца города на другой можно… включаешь 4ю скорость и газ не отпускаешь, практически.
И.Е.: Круто, слушай круто. Ну что, Никит, у тебя есть еще какие-нибудь вопросы?
Н.Б: У меня нет.
И.Е.: У тебя такое есть заключительное слово, если есть что сказать нашим слушателям…
Т.Б.: Ну пожелать наверное.
И.Е.: Или пожелать.
Т.Б.: Ну, пожелание такое, чтоб пытались развиваться, интересуйтесь новыми технологиями, не бойтесь лезть не в свое дело, если вы занимаетесь устроением devops, интересуйтесь как-что работает, повышайте свою квалификацию, повышайте обязательно квалификацию своих коллег - программистов, повышайте квалификацию продакт-менеджеров, чтоб они тоже понимали. По-сути, хорошая работа - это… техническая часть, которую ты сам настраиваешь - это где-то треть, а остальные две трети - это участие в разработке архитектуры и участие в каких-то организационных проектах. Только когда все эти части вместе присутствуют, тогда это и можно называть devops.
И.Е.: Большое тебе спасибо за интервью, если будешь в Москве - заходи в гости. До новых встреч. Пока.
Т.Б.: Пока.
И.Е.: Кстати, после интервью я посмотрел блог Тимура, и надо сказать, очень интересный блог, я даже подписался, он есть в Show notes в ссылке, если вам интересно, обратите внимание. Оказывается Тимур учит еще китайский язык в свободное от работы время и там даже есть про то, что в 14-ой убунте сломался поддержка китайского в chrome ?
Н.Б.: Хотя, казалось бы…:)
И.Е.: :) Вот такая история.
И.Е.: Но мы продолжаем и о чем мы хотели с тобой поговорить?
Н.Б.: Хороший вопрос.
И.Е.: Мы хотели поговорить с тобой про Прикольного Сисадмина.
Н.Б.: Да, как я уже говорил, это подсекция отличного репозитория на гитхабе, где есть практически про все, только почему ты его Прикольным-то называешь?
И.Е.: Awesome - это же “прикольный”.
Н.Б.: Нет.
И.Е.: Ну, “крутой”.
Н.Б.: Да. “ Крутой”, такой “превосходный”.
И.Е.: Да какая разница, грани смысла одного и того же
Н.Б.: Возможно, ок. Меня поразило на сколько там в общем репозитории есть вещи, которые мы годами нарабатывали и …
И.Е.: А можешь ссылку прислать тоже?
Н.Б.: На все?
И.Е.: Конечно, чтоб оно было в шоу нотах.
Н.Б.: Сейчас пришлю, хорошо?
И.Е.: да и мы добавим их в ссылку и там про все есть, про всякие языки программирования, про про SHELL отдельно. Но поскольку мы все ближе к сисадминам, хотя недавно прямо в пятницу был sysadmin-day, помнишь?
Н.Б.: Да, помню.
И.Е.:Ты отмечал?
Н.Б.: Я - нет.
И.Е.: А я отметил.
Н.Б.: Так…
И.Е.: Нормально отметил, ниче так, хорошенечко. Угостил всех коллег на айкидо.
Н.Б.: Хорошо тебе.
И.Е.: Просто там был еще один сисадмин, мы вдвоем угощали, в принципе - ничего получилось, пополам не так дорого. Короче, праздник кто не отметил, мы все равно вас поздравляем, если вы относите себя так или иначе к сисадминам. Но самый прикол был, что я ехал в метро на эскалаторе и по громкой связи поздравили всех с праздником сисадмина.
Н.Б.: :) Интересно, когда будет праздник программистов, будет ли такое?
И.Е.: Было прикольно. Этот Самый.. видоз, я забыл , кто выкладывал, уже не найду, американцы, тоже сисадмины, ловили прохожих на улице и спрашивали: “Вы знаете, кто такой сисадмин?” И большинство отвечали: ”Нет, не знаем, кто это, неизвестная профессия.”
Н.Б.: Вот так история, а про принтер ничего не говорили?
И.Е.: Про принтеры? Ну я так обрывками посмотрел, не могу сказать, может и говорил кто-то. Но мы вернемся к списку. Действительно по всем темам, есть какая-то категоризация, т.е. уже появляется структура домена знаний. Вот какие слова нужно знать, чтоб говорить, что сисадмин ты или не сисадмин. Вот все это уже есть в этом списке. Во-вторых, по каждой категории есть куча ссылок, что можно посмотреть, начиная от бэкапов и заканчивая imap pop3.
Н.Б.: Это я все говорил уже.
И.Е.: Да? ты говорил примеры использования, а там списки инструментов. Так что рекомендуем посмотреть, кто еще не успел, но и еще у них в конце есть куча ссылок на различный ресурс, чтоб почитать какие-то блоги популярные и все в таким числе. Так что очень рекомендуем. Что еще?
Н.Б.: Что еще… Пробовал ли ты, Иван, ChefDK под windows?
И.Е.: Не успел я поставить его и попробовать, хотя, конечно любопытно, поскольку сейчас по работе мне приходится изучать винду, и я совсем недавно закончил читать книжку “Windows Server Administration Essentials” И могу сдавать какой-нибудь сертификат Микрософта, если захочу.
Н.Б.: Но зачем ?
И.Е.: Ну раньше я сдавал, у меня есть какой-то сертификат, был помоложе. Как сказать. Я сейчас понимаю…
Н.Б.: Ну понятно, у всех бывает, на самом деле в молодости.
И.Е.: Это какой-то критерий - ты знаешь слова из темы, вот, что это это означает, не много-не мало. По крайней мере ты можешь об этом как-то поговорить, сделать - не факт, но поговорить уже можешь, какой-то набор знаний.
Н.Б.: Я бы поставил ChefDK и поставил одному из разработчиков, с кем я общался, это лучше чем собирать все на коленке из bundle install и так далее. Т.е. не надо ставить ruby-dev, а под windows - это некая проблема есть. Нельзя просто взять и поставить Chef под windows. Конечно, удобно, все работает, но в том юзкейсе, как мы использовали, никаких проблем не возникло, что странно.
И.Е.: Это вообще, круто, с моей точки зрения.
Н.Б.: Я думаю, что они долго ее так и не выпускали, что сейчас все работает.
И.Е.: Ну да, им уже нельзя выпускать нерабочий инструмент. Они уже на таком уровне развития, когда им надо стараться, что бы выпущенные ими продукты работали. Я хотел тебя спросить: вот представляешь у тебя есть какая-то компания, у них все работает на Chef и можно придти и переделать все на ансибл так, чтоб все было лучше.
Н.Б.: А зачем? :)
И.Е.: :) Вот к этому и вопрос. Очень часто люди подменяют одни инструменты другими, но при этом не понимая, какая изначально задача. И использование системы конфигураций это лучше, чем не использовать, но, не помню, в какой статье прочитал, очень прикольную мысль, что если внутри команды, которая выпускает продукт нет коммуникаций нормально налаженных, то если вы придете и поставите там Chef, у вас будет не работающий production с неработающим Chef и опять же отсутствие коммуникаций внутри команды. На одну проблему больше. И собственно говоря, этот интригующий вопрос я тебе задал, что бы узнать что ты ответишь, провокационный :)
Н.Б.: :) Особой нет в этом провокации.
И.Е.: Здесь есть, безусловно, провокация. В каких-то ситуациях смена инструмента может дать какой-то небольшой процент улучшения, но принципиально лучше сделать нельзя.
Н.Б.: Я не знаю, на счет процента улучшения. Ты пользуешься инструментом, если ты знаешь все его особенности. все его хаки-трюки, очевидно знаешь, если ты с ним долго работаешь, то пока ты войдешь в новый инструмент - спорно.
И.Е.: Я об этом же. Надо гораздо глубже понимать проблему, чтобы внедрять какой-то новый инструмент, поскольку сам по себе инструмент проблемы-то не решает. И как показывает наша практика, самая большая обычно проблема - в людях, а не в инструментах.
Н.Б.: Причем, мы с Тимуром говорили уже об этом, что есть компании в которых внедряются новые технологии, потому что они прочитали об этом где-то там.
И.Е. Это техдир рассказывал по-моему об этом. И что, там они отправляли своих сотрудников на highload? Какой buzz, вокруг какой системы шел в этом году, такая система появлялась у них в production.
Н.Б.: Вань, это Тимур рассказывал.
И.Е.: Это я рассказывал Тимуру.
Н.Б.: ОК
И.Е.:Потому что мне это рассказывал на работе Саша Семенов. Он с кем-то говорил, истории передавал. Такая вот история. И действительно, что есть определенная проблема в современном мире. Она всегда и была - никуда не делась, agile-движение была о том же самом , что как бы нам сделать так, что бы идеи от бизнеса, попадая к разработчикам, не теряли свой смысл.
Н.Б.: Понимаешь, можно понять разработчиков и админов - хочется же попробовать какие-то новые вещи, особенно если они buzz-ы на highload.
И.Е.: Конечно, хочется, кто ж спорит, и главное, попробовать на production.
Н.Б.: Иначе нельзя сказать, что попробовал.
И.Е.: Я не знаю как это проблема решается, но она реально есть.
Н.Б.: А бить по рукам, что?
И.Е.: Бить по рукам, это если есть кому бить по рукам, а если некому.
Н.Б.: Тогда - печаль.
И.Е.: Несчастье, печаль. Но тема интересная. Я к другому, а вот как менять культуру внутри компании? У меня нет хорошего ответа на этот вопрос. Если будем честными, в подкасте по крайней мере. Т.е. простого способа сказать “а давайте будем делать по другому”, потому что люди … У них отношения, взаимоотношения внутри коллектива уже как-то сложились определенные.
Н.Б.: Слушай, но бывает, что есть потребность в изменениях просто, внутри коллектива. Но они не знают, как, или сами не хотят начинать. Я такое видел. И там достаточно просто будет действовать. Но если совсем болото, и не знают, что делать, - то, конечно, это печаль и у меня тоже, как у тебя, нет решения хорошего.
И.Е.: Я не уверен, что оно вообще может существовать, люди сложно меняются. Но вот в наш двенадцатый выпуск я хотел бы тех, кто нас слушает… Хотя, конечно, нас слушает достаточно такая активная, и готовая к изменениям аудитория. И интересно было бы как-то эту мысль донести до людей, которые меньше готовы к изменениям. Что все-таки, это надо практиковать меняться.
Как написано было в книжке “Windows Essential”, надо переучиваться. Ты будешь смеяться, он написал о том, что windows выходит в среднем раз в три года новый, и обычно меняют через версию винду, т.е. не каждую, а через релиз. И он говорит, что раз в шесть лет надо переучиваться. Ну, реально, сколько винде лет получается? С 90-ых считай, т.е. 20 лет уже, т.е. у них уже есть какая-то статистика, как часто нужно переучиваться. И мне кажется, то же самое везде, раз в три года надо переучиваться. А лучше непрерывно учиться, чтобы раз в три года не пришлось переучиваться.
Н.Б.: Знаешь, это как сессии в институте. Если ты весь семестр сидишь на лавочке на улице, на стадионе, то перед экзаменом тебе надо очень много всего выучить. И обычно, ты fail-ишь. А если в течение семестра прилежно учишься, то в целом, …
И.Е.: Ну да, конечно, да. Мне кажется, да, после института жизнь не заканчивается, и обучение - тем более, только начинается, с моей точки зрения. И тут надо не терять вкуса к изучению нового материала. И учиться. Тут, конечно, большой плюс, если попадете в хорошую команду, это молодежи в основном касается, где попадет человек старше вас, и будет вас менторить и помогать двигаться вверх. И смотреть по-другому на разные проблемы.
Опять же было совсем недавно было. Со старым другом встречался, он сейчас руководитель IT-разработки, и он рассказывал мне знаешь про что? Такая мысль прикольная! Про отчеты начальству. Он говорит, что проработав 5-7 лет, ты знаешь, что нужно сказать начальству, чтобы у него была необходимая информация, и чтобы не грузить его мелкими подробностями ненужными. Т.е. вроде простой такой навык, казалось бы. Он говорит, что когда ко мне приходят люди с опытом меньше разработки, и начинают мне рассказывать, что у них там происходит, они несут всякую пургу. То, что мне знать в принципе вообще не надо.
Н.Б.: Т.е. это не пурга, просто они не знают …
И.Е.: Как бы есть не пурга, но у них нет другой точки зрения, они вот так вот видят мир. Этому надо долго учиться, и как сказать … Это когда опыт два-три года, когда опыт к десяточке приближается, каким-то другим надо вещам учиться. И хорошо, если было бы кому рассказать об этом.
Н.Б.: Да!
И.Е.: Да! Ну, что ж, философский экскурс я заканчиваю, вместе с 12 выпуском, слушайте Дефлопе, растите кациус, что там еще надо делать? Жарьте крутоны, с вами был 12 выпуск подкаста о DevOps, все что с ним связано. Так называемо DevOps Deflope подкасте. И его постоянные шеф-повара, мастер ножа, сковородки и вилки Никита Борзых.
Н.Б.: И просто мастер, Иван Евтухович.
И.Е.: До новых встреч!