015 - Из самого сердца Докера Декабрь 4, 2014

015 - Из самого сердца Докера

Update Required To play the media you will need to either update your browser to a recent version or update your Flash plugin.

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

Новости

Обсуждение

У нас в гостях Jérôme Petazzoni

Про Azure и не только

Расшифровка

И.Е.: Здравствуйте, в эфире 15й выпуск Devops Deflope и с вами его постоянные повара Никита Борзых и…

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

И.Е.: Блок новостей.

Reflecting on Six Years With Chef

Н.Б.: В блоге chef вышел препост статьи Joshua Timberman под названием “Reflecting on Six Years With Chef”. Он рассказывает о своих отношениях с компанией Chef, как он начиннал работать с chef с версии 0.5. Рассказывает о том, как он коммитил в opensource кукбуки и как они понимали, что они не очень хороши для продакшена, и улучшали это. А так же Joshua занимался написание draft-а для первой версии chef-fundamentals и участвовал в создании opensource community. В целом, отличная статья о том, какой большой путь человек прошел от нуля до текущего момента.

Релиз кандидат PostgreSQL

И.Е.: 20го ноября вышел релиз кандидат 1 (RC1) базы данных с открытыми исходными кодами по postgresql версии 9.4. Если все пойдет хорошо, то этот релиз-кандидат через 2 недели станет первым релизом постгреса. И это, конечно же, большое счастье. Обычно мажорные релизы постгреса выходят в сентябре, но в этом году в связи с тем, что были достаточно большие регрессии с новым jsonb, выход отложили на 2 месяца. Но мы надеемся, что в следующем году такого не произойдет, а новая версия приросла мощнейшими фичами и две самых крутых из них - это конечно же сам jsonb. Теперь postgres - это не только SQL база данных, но и еще MongaDB-like база данных. Т.е. можете хранить в ней jason, есть свой язык запросов, есть индексация jason, короче - реально очень круто. И по многом, многим, если не всем параметрам именно запросов, по скорости запросов postgres обгоняет MongoDB, о чем неоднократно писал в своем блоге Олег Бартунов. Он и еще пара русских его коллег - это авторы jsonb. Так же, что мне кажется самым крутым это то, что появилась logical decoding, то есть логическое декодирование, говоря русским языком. Postgres стал хронить свой транзакционный лог, что называется еще WAL log, Write-Ahead-Log, в платформо-независимом формате. Это еще один шаг к тому, что бы сделать мульти-мастер репликацию, частичную репликацию, федерализацию данных. То есть Postgres превращается в , я думаю, что это будет версия 9.5, во взрослую, почти настоящую, в энтерпрайз-смысле, базу данных. И это реально очень круто. Тем не менее никому не рекомендую ставить postgres в продакшн 9.4, хотя бы подождать до версии 9.4.3 обычно после .3 уже критических багов не остается, но не факт. Так что, ваш следующий проект, если он будет запускаться в 2015 году можно будет использовать новый postgres.

Chef Provisioning: Infrastructure As Code

Н.Б.: 12 ноября компания Chef выпустила ChefDK версии 0.3.4, в котором анонсировала релиз кандидат фичи chef-provisioning. Это такой ресурс, который называется machine, через который можно сетапить новые машины и сразу на них накидывать какой-то рецепт. Я так понимаю, раньше это был chef-metal, теперь они допилили это до продакшена. Напомню chef-metal - это такая альфа-версия того, что сейчас есть в chef-provisioning, она умела сетапить только Амазон. По виду chef-provisioning напоминает Terraform, на мой взгляд отличия небольшие все-таки есть в том, что Terraform хранит статус/state то, что он изменил в системе, а chef-provisioning просто создает новые машины. Но тем не менее и та, и другая утилиты найдуть свое применение в продакшене.

Рассказ про то, как упал Ажур

И.Е.: А 19 нобря этого года упал Ажур. Упал Ажур и провалялся 11 часов. Понятное дело, что промолчать компания Microsoft не могла и один из ее сотрудников, я так понимаю самый смелый, рассказал о том, почему же собственно Ажур упал и с чем это было связно. Если в краце - они делали улучшение производительности дискового хранилища, так называемый storage service. И у них есть два типа сервисов - это blob-сервисы и table-сервисы. Они оттестили это нормально на table-сервисах и выкатили новую кофигурацию на весь Ажур. И после этого blob-сервисы, как написано в postmortem ушли в infinite loop. Соответственно, пришлось откатывать конфигурации, рестартовать все blob-сервисы, ну фронтенд у blob-сервисов. Это заняло довольно долгое время. Потом опять же пока разбирались, короче в результате, самым неудачным покупателям не повезло сильнее всего, они лежали 11 часов. Компания Microsoft рассказывает, что случилось, и пишет о том, что сделали, что б этого не случилось. И конечно же основной проблемой было то, что в отличае от стандартной своей процедуры, которая у них описана, они выкатывают обновление не целиком весь Ажур, а по чуть-чуть, пачками. В этот раз по какой-то причине их наверное заломалом и они выкатили на весь Ажур сразу и ребятам просто не повезло. В комментах люди, понятно, поливают их грязью, говорят, что так делать нельзя, но все взрослые инженеры знают, что любое правило, даже самое жесткое, иногда нарушается. Хорошо или плохо - так устроен мир.

krane tool

Н.Б.: А вот есть такая утилита - krane. Я ее называю krane tool. Это утилита для использования докер-контейнеров в нескольких облаках. Если у вас есть Амазон, а вы хотите куда-то еще выкатить ваши контейнеры, эта утилита позволяет вам использовать Digital Ocean и т.д. Плюсы использования понятны - вы отвязываетесь от использования одного облачного хостинга и можете использовать сразу несколько.

Rancher

И.Е.: Ну и на последок мы расскажем вам о сервисе, который называется Rancher IO - это, как ниписано на сайте, aws-style infrastructure services for docker. Фактически они пишут, что докер - это удобный инструмент, чтобы делать повторяемые контейнеры. Но контейнеры надо где-то запускать в каком-то окружении. И вот это окружение - диски, сеть, loadтбалансеры, секъюрити-группы - все это делается в помощью Rancher. И они говорят, что взяли за основу сервис Амазона. Они пишут, что Rancher можно запускать в любой инфраструктуре : в Амазоне, в своем личном облаке, bare metal железе… То есть это фактически такое еще один кубик для того, что бы полноценно пользоваться докером.

А новостей на сегодня больше нет.

И.Е.: Никита, помнишь ли ты, что в ночь, нет - в день, в вечер точнее перед моим отъездом в отпуск в Москве прошел очередной Devops Meetup Moscow.

Н.Б.: Конечно помню, мы там с тобой оба были.

И.Е.: Да на Devops Meetup Moscow, тьфу ты ж блин, какие сложные английские слова, короче на этом митапе было три доклада, если я не ошибаюсь и ссылочку на результаты митапа мы обязательно пришлем. Но вообще, кто хочет попасть на наши митапы в Москве и посмотреть видео трансляцию, регистрируйтесь в нашей группе на meetup.com, это совершенно бесплатно и мы с завидной периодичностью проводим devops-встречи по различным тематикам. И последняя тематика, последний meetup был посвящен докеру. Все ссылки будут у нас в Шоу-нотах. Митап был посвящен докеру и контейнерной виртуализации. Прошел он в очередной раз в офисе компании badoo, они приняли нас у себя и даже в конце угостили всех пиццей и пивом совершенно бесплатно. Я поэтому выражаю нашу общую devops-благодарность компании badoo. В пограмме было три доклада. Это был Антон Турецкий из компании badoo вместе с Ильей Раудсепп, они рассказывали про то как докер используется в badoo. Потом был Павел Емельянов из Parallels, он рассазал про краны. Никита расскажет, что такое краны, я, честно говоря, не очень знаю. А на горяченькое был один из сотрудников компании Doker, Jérôme Petazzoni и доклад его назывался “Docker, Sysadmin tasks (backups, logging, remote access, debugging, network analysis…) with Docker, aka ‘life without SSH’” . Короче, он рассказывал, как использовать докер, все старые концепции прицепить к докер и как жить без ssh. Доклад был достаточно интерсный и многие идеи, коорые они используют, контейнеры под все что угодно, под любую маленькую задачу - новый контейнер. Подход интересный, не знаю, как он в продакшене, попробую - расскажу. А про CRanes Никита нас просвятит, что это такое.

Н.Б.: Слушай, я не знаю, что такое CRanes, вообще, он рассказывал про рассказывал про CRIU, если я был на том митапе, про который ты говоришь, то было про CRIU. Это такая штука, которая является патчем к ядру Linux, который позволяет саспендить любой процесс в Linux. И передавать его на другую машину. Т.е. ты таким образом можешь, если у тебя данные, конечно перенесены, можешь перезапускать на другой машине всякие базы данных, любые другие демоны, в том числе можно docker daemon так перезапускать. Чтобы переезжать на другую машину.

И.Е.: То, что называется migration.

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

И.Е.: Да, поскольку Jerome был в России первый раз, то мы взяли у него интервью, и сейчас мы его с вами послушаем.

И.Е.: А сегодня у нас в гостях разработчик из компании Docker Jérôme Petazzoni.

И.Е.: Привет, Jerome.

J.P.: Привет.

И.Е.: Мы рады видеть вас у нас в Devops Deflope подкасте, и наш первый вопрос — что такое докер?

J.P.: Докер - это платформа для построения и запуска распределенных приложений. Это значит, что мы можем его использовать для упаковки приложений в образы контейнеров. И мы можем в дальнейшем брать эти образы и запускать их на новой Linux машине. Это позволяет добавлять абстракцию между платформой (где вы хотите запускать ваше приложение) и самим приложением. Это абстрагирует дистрибуцию нужной версии приложения, зависимостей, библиотек. Так что вы получаете что-то вроде пакета для дистрибуции, с тем отличием, что его проще создать, и он более совместим, потому что образ контейнера может быть запущен на RedHat, Debian, Ubuntu, любой разновидности Linux, независимо от используемого дистрибутива той машины, где он создается, и той машины, где он будет работать.

И.Е.: Ок, а как обстоит дело с управлением конфигурациями? Я знаю, некоторые утверждают, что докер - “убийца” chef, puppet, но, насколько я понимаю, у докера нет такой абстракции, как управление конфигурацией.

J.P.: Верно. Если вы возьмете все вещи, которые умеет делать докер, и все вещи, которые умеет делать средство управления конфигурацией - между ними есть некоторое пересечение. Так что есть некоторые вещи, которые многие предпочитают делать с помощью докера вместо менеджера конфигурациями. Но да, все еще есть вещи, которые многие захотят делать с помощью средства управления конфигурациями. Например, сегодня, когда люди используют chef, puppet, ansible, salt, они используют его для настройки базовых уровней своих серверов, настройки железа, если это физические машины. Даже если это виртуальные машины, иногда вам нужно партиционировать внешние диски, создать файловые системы, настроить сеть, мониторинг, удаленный доступ. И затем, вы получаете слой, в который вы устанавливаете свои пакеты, библиотеки, зависимости. Где расположен код вашего приложения, и, наконец, вы используете систему управления конфигурациями чтобы стартовать ваши сервисы, и дать им необходимые настройки. Когда вы добавляете докер в эту мешанину, вы продолжаете использовать менеджер конфигураций для нижних слоев: для настройки самой машины, физической или виртуальной машины, там все еще есть что делать. Но затем, вместо того, чтобы сказать “puppet, установил мои библиотеки и мое приложение”, вы говорите “puppet, пожалуйста, установи docker и запусти этот, этот и этот контейнер с такими, такими и такими параметрами”. И все остальные вещи, экстра пакеты, библиотеки и зависимости - это уже происходит внутри контейнера. И наше текущее видение таково, что люди будут использовать докер-файлы, чтобы описать это. Так что идея в целом - это сисадмины все еще буду использовать менеджер конфигураций чтобы настроить базовые вещи в машине. А затем, вместо того, чтобы говорить разработчикам “ок, теперь вы пишите кукбуки, чтобы установить ваши библиотеки и приложения”. А вы, как разработчик, можете и не знать, как правильно использовать chef. Вместо этого сейчас уж можно сказать “вы пишите докер-файлы”, потому что докер-файлы проще писать, чем кукбуки шефа. И затем сисадмины просто распределяют эти контейнеры по серверам.

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

И.Е.: Ок, а что по поводу service discovery? Есть ли в докере его поддержка?

J.P.: Да, в докере нет решения “из коробки” для реализации “супер-классной” системы service discovery. Шаблон, который мы пытаемся всем предложить, и который, как мы верим, должен быть хорошим и удобным, - это шаблон ambassador (англ, “посол, посланец”). Некоторые не очень любят этот термин амбассадор, потому что он “новый”, что, мол, за хипстерская концепция. Другой способ объяснения этой концепции - что это некоторый вид прокси. И когда вы хотите подключиться к вашему кэшу reddis, или любому другому сервису, вместо того, чтобы брать адрес этого сервиса из zookeeper, etcd, или системы управления конфигурации - вы просто подсоединяетесь к амбассадору - прокси, или какому-то переключателю, который будет запущен локально, прямо рядом с вашим контейнером с приложением. И этот прокси сам будет находить, где же работает настоящая база данных. Т.е. вместо запроса в ZooKeeper: “какой адрес у моего postgresql сервера?”, я буду подсоединяться к localhost, и на этом локальном хосте я получу что-то, что будет само соединяться с ZooKeeper, и соединяться с настоящим postgresql сервером.

Так что да, это требует дополнительного шага. Но так как оно работает локально, накладные расходы очень, очень маленькие. И это значит, что если адрес postgresql сервера изменился, потому что он был смигрирован на другую машину, или произошло переключение с мастера на реплику, тогда это будет уже не работа внутри вашего приложения, а работа внутри амбассадора, или прокси. Т.е. это снова вопрос разбиения большого сложного участка. Теперь вместо сложного приложения, которое также должно обрабатывать перемещение базы данных, теперь приложение просто соединяется с амбассадором, и амбассадор уже следит за расположение БД.

И в зависимости от вашего фактического расположения, на физической ли вы машине, или в облаке, или в вашем персональном облаке, и т.д. - реализация амбассадора может отличаться. Кто-то будет использовать avahi для обнаружения сервисов с помощью мультикаста, кто-то предпочтет ZooKeeper или etcd. Т.е. вы снова можете разбить сложную проблему.

Разработчик не заботится о том, с помощью чего производится поиск сервисов - с помощью ZooKeeper, или etcd, или multicast, или чего-то еще. Он просто коннектится к амбассадору все время, и далее уже амбассадор делает нужные вещи. Это тот способ, который мы советуем для выполнения service discovery.

Н.Б.: Быстрый вопрос про сервисы с внутренним состоянием. Как мы должны использовать докер с такими сервисами, например с БД? Мы можем сохранять данные отдельно от докера, или как?

J.P.: Ок, как правильно обращаться с сервисами с внутренним состоянием. Кто-то полагает, что докер не очень хорошо работает с подобными сервисами. Я частично согласен с этим мнением. Я бы сказал, что сервисы с внутренним состоянием - довольно сложно запускать где бы то ни было. Даже на реальных машинах, если машины падают - сервисы упадут. Часто люди полагают, что докер лучше всего подходит для сервисов без состояний. Потому что если сервис не имеет состояния, то становится очень легко перемещать сервис с одного места на другое. И все говорят: “О, докер хорош при отсутствии состояния. Но он плох при наличия состояния”.

На самом деле все не так. Мое персональное мнение - что докер хорошо работает с обоими типами сервисов. Но сервисы с состоянием сложны в обращении в целом, в принципе. Даже с наличием докера - подобные сервисы сложны в обслуживании.

Я вижу следующий правильный способ работы с сервисами с состоянием: Во-первых, вы используете Volume для разделения данных и самого контейнера. Volume - это концепция в докере, когда вы можете в контейнере иметь директорию, которая отделена от основной файловой системы контейнера. Вместо copy-on-write ФС, Volume находится напрямую на хостовой ФС. Что это значит? Вы можете обновлять контейнер, иметь новые версии ваших приложений (mysql, postgres, redis), но в то же время, вы сохраняете содержимое этого Volume. Так что когда вы обновляете версии, это содержимое Volume для mysql, postgres или redis будет сохранено при переходе с одного контейнера на другой. Это так же значит, что если вы хотите сделать backup для ваших данных, вы можете поставить lock на данные на хостовой ФС, и можете производить backup снаружи контейнера. Это, опять же, разделение проблем, потому что вместо хранения всех скриптов для резервирования внутри контейнера mysql, postgres, redis, … - вы можете иметь их снаружи.

Если вы уже привыкли использовать концепцию Infrastructure as a service (IaaS), и системы блочного хранения данных, например, EBS, или эквиваленты. Volumes - нечто похожее, с той точки зрения, что вы можете стартовать ваш новый контейнер и добавить уже существующий Volume к этому контейнеру.

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

Поскольку раньше, чтобы сделать обновление postgresql, и что-то идет не так, и я должен быстро откатиться назад - это могло стать проблемой. Может я обновляюсь с postgresql 9.3 на 9.4, и если я откатываюсь обратно на 9.3 - пакеты уже недоступны на этой машине. И я должен как-то их найти и установить. Сейчас я могу иметь несколько вариантов контейнеров, я начинаю с версии 9.4, и если он не работает - ок, я стопаю контейнер, рестартую с версией 9.3, присоединяю Volume, и оно должно работать.

Сейчас ведется работа над тем, чтобы улучшить поддержку Volume, есть такая компания, называется ClusterHQ, и они делают такую вещь как flocker, которая позволяет мигрировать контейнер с одного хоста на другой вместе с Volume. Так что я думаю, это начало новых типов сервисов, продуктов, или как это правильно назвать. Это добавляет удобства в работе с сервисами с состоянием при работе с контейнером.

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

J.P.: Поддержка Windows была объявлена, и сейчас Microsoft работает над … в основном, они добавляют функциональность контейнеров внутрь ядра Windows. Это значит, что когда-нибудь (не мог сейчас точно сказать, когда точно, спросите Microsoft, если хотите знать точные даты) будет возможно стартовать приложения Windows внутри контейнеров на машинах Windows. Некоторые полагают, что о, мы сможем запускать Linux-контейнеры на Windows-машинах. Нет, это значит, что сейчас мы можем запускать Linux на Linux, завтра мы сможем Windows на Windows, и интеграция докера с этими технологиями означает, что будет возможно управлять контейнерами с помощью того же API, CLI, теми же утулитами оркестрации. Если кто-нибудь напишет по-настоящему крутую панель управления докер-контейнерами, тогда мы сможем переиспользовать ту же самую супер-кульную панель для управления Windows-контейнерами. В этом основная идея.

И.Е.: Спасибо. Еще вопрос, Докер, как компания, производит только один продукт, opensource докер. И как, откуда они получают деньги?

J.P.: Это хороший вопрос. На самом деле, в самой компании Докер нас уже 65, нет, 66, нет, 67 - мы нанимаем людей очень быстро. Думаю, сейчас нас уже 68. И сейчас у нас чуть меньше 10 человек работает над самим движком докера, частью, у которой открыты исходники. И большая команда работает над docker hub. Есть еще команда, которая занимается поддержкой и профессиональной тренировкой, обучением людей и помощью в создании архитектуры с использованием docker. Так что мы делаем деньги с помощью нескольких продуктов. Docker hub - это что-то похожее на Github, если вы хотите иметь публичные образы - пользуйтесь бесплатно. Если хотите иметь свои частные, закрытые образы - вы должны заплатить нам немного денег.

Вскоре мы собираемся опубликовать Docker hub для энтерпрайза, что означает, что вы сможете иметь функциональность Docker hub, для хостинга образов контейнеров, автоматических систем сборки, пользовательских ACL (Access Control List). Вы сможете иметь все это внутри вашего датацентра, внутри вашего firewall, и это будет коммерческим проектом.

Публичный реестр все еще будет существовать. Opensource реестр все еще будет существовать. Так что если вы не хотите платить денег, чтобы у себя иметь Docker hub, вы все так же сможете запускать реестр самостоятельно, эксплуатировать самостоятельно. И все прекрасно, все это продолжит существовать.

Мы также продаем услуги по обучению, по поддержке и сервисам, вот основные наши пункты дохода. Плюс мы продаем еще товары вида “наклейки и футболки”, но я не знаю, насколько успешной будет эта бизнес-модель.

И.Е.: Как вам Москва? Она хороша?

J.P.: Мне нравится Москва, я был здесь в прошлом году. И хотя здесь холоднее, чем в Калифорнии, здесь очень мило, это старый европейский город. А так как я сам француз, и вырос в Париже, мне нравятся старые европейские города. И я очень надеюсь, что мне удастся в ближайшее время еще раз приехать, возможно, мы найдем мне еще одну крутую компанию, которая пригласит меня в следующем году в Москву.

И.Е.: Спасибо за интервью.

J.P.: Спасибо вам.

И.Е.: Пока.

Н.Б.: Пока.

И.Е.: Большое спасибо Jerome за интервью. Я не уверен, у нас будет перевод интервью?

Н.Б.: Будет, будет. Да.

И.Е.: Мы выложим текстовый перевод, кто не очень знает английский, но английский, мне показалось, у него очень простой. И вроде бы мы с тобой очень хотели обсудить нашу первую новость, а именно 6 лет с Chef.

Н.Б.: Давай несколько новостей обсудим. Давай начнем не с этой, а с падения Microsoft, потому что мы не можем этого с тобой не обсудить.

И.Е.: Ну давай поиздеваемся над нашими коллегами из Microsoft.

Н.Б.: Подожди, мы не будем издеваться, просто….

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

Н.Б.: Это не оправдывает того, что они ложатся.

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

Н.Б.: Тут меня удивило,что есть такое понятие как availability zone, я думаю, что в Ажуре тоже это так или иначе есть. И обычно, когда ложится одна зона - это ничего страшного, плохо, но ничего страшного. Просто все переезжают на другие availability зоны, у кого уже есть там инсталяция. И тут такие случаи, что упал почти весть Azure кроме одной зоны - Австралии. То есть у меня вопрос: как они проектировали инфраструктуру так что выкатка такого кода может испортить все совсем…

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

Н.Б.: Давать возможность так делать уже не очень хорошо.

И.Е.: Как известно, инженеры, которые диплоят облако у них всегда есть много прав и есть много способов уложить любое облако. А другой момент, меня удивило, что status page и тикетница, как у них называется, support, они были тоже на Ажуре и легли вместе с Ажуром.

Н.Б.: Это значит только одно, Вань, что они были очень уверены в своем.

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

Н.Б.: И последний момент, они были так уверены в этом изменении, что в обход процедур, которые подразумевают выкатку постепенно на несколько availability zone, выкатили сразу на все. Причем, Вань, давай честно, у тебя такое было? Что ай, ладно, черт с ними, с процедурами, выкачу сразу везде.

И.Е.: Это абсолютно нормально, да, если ты уверен в чем-то, ты сокращаешь время.

Н.Б.: В статье было написано, что они потом внедрят такую штуку, чтобы не позволить в обход процедур выкатывать сразу на все.

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

Н.Б.: Скорее всего да.

И.Е.: Лишение премии, например. Но какой еще момент меня удивил. Они написали в postmortem, что отладить процедуру rollback, чтобы меньше лежать. Т.е. походу они были так уверены, что даже не думали, как будут откатываться в случае …

Н.Б.: Слушай, ты же писал облако в детстве?

И.Е.: ну да, я понимаю.

Н.Б.: Ты же знаешь, что rollback не везде возможен, и где-то нужно делать специальные телодвижения, чтобы его сделать нормально.

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

Н.Б.: Компании Microsoft.

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

Н.Б.: Причем, непонятно, связано это с тем, что пришел новый CEO, или просто с тем, что время пришло. Наверное, все вместе.

И.Е.: Я думаю, что все вместе, конечно. Но они переориентировались очень сильно на web, office365 в целом у меня вызывает приятие, я честно тебе скажу. Я не очень люблю продукты Microsoft, но вот этот …

Н.Б.: Слушай, представь себе, что ты год назад узнал новость, что Microsoft в скором будущем выпустит поддержку docker в своих контейнеров. Узнал бы сразу две вещи: первое, что в Microsoft есть контейнеры….

И.Е.: Ну да, они стали следить за рынком, они перестали притворяться, что они самые крутые на рынке, их действительно прибила собственная слава. У них было 80-90% рынка, всех операционных систем.

Н.Б.: Потом они сделали IE6

И.Е.: IE6 - это что было?

Н.Б.: IE6 помнишь?

И.Е.: Нет

Н.Б.: Браузер такой, IE6.

И.Е.: А, IE6, да.

Н.Б.: Да, и на 10 лет web встал.

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

Н.Б.: Они заопенсорсили ядро .NET Framework. Насколько это полезно - время покажет. Т.е. тенденция, конечно, прекрасная. Но пока от него толку мало. Ну, заопенсорсили, хорошо.

И.Е.: Погоди, а не Visual Studio они разве заопенсорсили?

Н.Б.: Нет, не Visual Studio. Visual Studio это их основной продукт для девелоперов. Нет, они заопенсорсили .Net, последней версии, именно ядро. Хорошо.

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

Н.Б.: Виртуально.

И.Е.: Виртуально, да. Перейдем к компании Chef. Компания Chef, конечно, поменьше, чем компания Microsoft. Но тем не менее по количеству …

Н.Б.: упоминаний у нас в подкасте - сильно больше.

И.Е.: Нет, не в этом дело. По количеству маркетинговых статей в их блоге - они приближаются к Microsoft очень быстро. Если вы откроете блог компании Chef, которая раньше называлась Opscode, кто еще не … новички, которые еще пороху не нюхали, они думают, что компания Chef была всегда. К чему это я? Как раз к статье, про которую мы рассказывали “6 лет в Chef”. Joshua Timberman. Вообще, конечно, интересный у мужика опыт. И мне понравилось, что в Chef есть отдельное подразделение, которое занимается velocity … как это сказать “Офис непрерывных улучшений и скорости”. Его ведет Jez Humble, кто не знает, это автор книги Continuous Delivery, которую мы часто упоминали в нашем подкасте в том числе. Он сейчас работает в компании Chef, как ни странно, и вот он занимается именно внедрением лучших Chef-практик внутри компании Chef. Компания Chef уже не маленькая, их там под сотню человек, и они внутри своей компании внедряют лучшие практики по использованию Chef. Вообще это прикольная тема, потому что любая компания должна заниматься тем, что постоянно обновлять свои текущие практики. И даже в компании, в которой 8 человек работает, например, не так просто взять и улучшить практику уже существующую. Это требует определенных усилий. А если компания большая, то у вас может так получиться, что там будут и динозавры, и люди, которые пользуются достаточно адекватными инструментами. И как сделать так, чтобы средняя температура по больнице была более-менее приемлимой - это, конечно, целая история.

Н.Б.: Давай еще обратимся к началу статьи, где сказано, что Joshua Timberman занимался тем, что разделял репозитории opscode на opscode cookbooks, помнишь такое раньше было очень давно?

И.Е.: Да.

Н.Б.: И они сами признают, что этот репозиторий был не работоспособен. Т.е. в продакшене это использовать было нельзя. И это скорее использовалось для того, чтобы посмотреть, как правильно писать кукбуки, т.е. как пример. Представляешь, сколько прошло лет? 4 года прошло? Насколько они продвинулись! Сейчас это реально кукбуки, которые используются в продакшене. Если ты откроешь Berksfile проекта, ты увидишь, что почти все кукбуки используют супермаркеты, а это репозиторий на github.

И.Е.: Да, время идет, все меняется. И мне очень понравилось, что в какой-то момент Joshua отправили из … он занимался тем, что писал кукбуки. Ему сказали, чувак, ты пишешь 2 года кукбуки, и ты продакшена не видел, пороху не нюхал. И его отправили в ops-команду, которая занималась Chef-ом как продуктом.

Н.Б.: Это неплохая практика.

И.Е.: Это очень хорошая практика. Дело в том, что ему, как человеку, который пишет кукбуки, opensource кукбуки, ему надо понимать, какая проблематика стоит у ops-команды.

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

И.Е.: Да

Н.Б.: Коммуникации станут лучше.

И.Е.: Это то, о чем вообще devops, как сделать так, чтобы люди начинали хоть немного друг-друга понимать, и приносить ценность, пользу миру, ради добра.

Н.Б.: Все ради него.

И.Е.: Все ради него, да. Ну, что еще интересного случилось в этом году, в смысле между нашими выпусками новостей? Я подозреваю, что ничего.

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

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

К несчастью, да, к несчастью мы больше сконцентрированы на Chef-е, но тем не менее мы стараемся не забывать и про puppet, у которого, кстати, недавно вышел новый релиз, Никита обещал об этом рассказать нам, но не рассказал. И про ansible, и про DSC, и даже, наверное, про SaltStack, хоть он и написан на питоне.

Н.Б.: Упаси Господи.

И.Е.: Упаси Господи, да. Так что оставайтесь с нами, подписывайтесь на наш подкаст, регистрируйтесь в группе на митапе, если вы хотите. В Москве - приходите на наш митапы, либо смотрите их в трансляции.

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