Записки программиста

Темы одиннадцатого выпуска: Cloud Haskell Platform теперь доступен на Hackage, что такое DevOps и причем тут Docker, полны ли регулярные выражения Perl по Тьюрингу, дружной толпой валим с Riak на Dynamo, когда уже выйдут Cowboy 1.0 и Riak 2.0, зачем было создавать CowDB, если уже есть HanoiDB, сколько строк кода занимает реализация репликации на Erlang, а также почему Erlang — очень странный нишевый язык, который во всем ограничивает программистов, и вы, скорее всего, не должны его хотеть, а должны хотеть Haskell, Scala, ну или хотя бы Clojure. Предыдущие выпуски: десятый, девятый, восьмой, седьмой.

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/11/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/11/file/podfm_eaxcast__eaxcast_204.mp3

Шоу нотес:

• Относительно недавно вышел Riak 1.4.9, активно пилится Riak 2.0;
• CowDB — новая встраиваемая база данных для Erlang;
• Другие упомянутые проекты Бенуа: refuge.io и camp.io;
• Cloud Haskell Platform теперь доступен на Hackage;
• Упомянутая серия постов о Cloud Haskell;
• Также вышли Cowboy и Ranch 0.10, летом должен выйти Cowboy 1.0;
• Официальный сайт Docker, если кто-то вдруг не в курсе;

Голоса выпуска: Иван @gliush Глушков, Валерий @sum3rman Мелешкин, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

 

Александр: Всем привет, это EaxCast, второй сезон, четвертый, если я не ошибаюсь, выпуск. Маленькое объявление перед началом, касательно BoomStarter, я надеюсь, что оно будет последнее. Мы все еще ждем ссылок и текста от товарищей Петра Мязиня, Алексея Цветкова и Дмитрия Катаскина. Ребят, я вам напоминаю, что у вас, как у очень больших спонсоров, есть возможность разместить ссылки после show notes рекламные. И вот, имена мы ваши в качестве бонуса назвали. Пишите, потому что до конца второго сезона осталось всего-то двадцать выпусков.

А мы начинаем. Сегодня в выпуске ваши любимые голоса из колонок: мой голос, Саши Алексеева, голос Валерия Мелешкина, привет голос.

Валерий: Привет.

А: И голос Ивана Глушкова, вы его, конечно, помните по первому сезону. Привет, Ваня Глушков.

Иван: Привет.

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

Вот, в частности, недавно выходил Riak 1.4.9, и Валере слово, как главному специалисту по Riak.

В: Главный специалист на самом деле тут Ваня, у них Риак в продакшене, правда у них надо спрашивать, обновились ли они.

И: Мы перешли на Dynamo.

В: Перешли на Динамо все-таки! И как ощущения?

И: Да, Riak используем только на локале. Мы очень рады. В том плане, что позволяет очень гибко манипулировать пропускной способностью и ценами. Riak, к сожалению, такого не дает, такой гибкости.

В: Именно по ценам?

И: Да, именно по ценам. Основная задача у нас была сделать, что, если захочешь, быстро можешь нарастить мощность и соответственно, увеличится цена. Но если не хочешь, можешь быстро уменьшить уровень и сразу перестать платить деньги.

В: То есть, одной из самых больших инсталляций Риака теперь больше нет?

И: Да, да, у нас он остался только для тестов, для эмуляции Динамо на локале.

В: А тяжко мигрировали, или легко и просто? Или вам мигрировать не пришлось?

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

В: А сколько у вас, если не секрет, было данных, в гигабайтах или терабайтах?

И: Я прямо сейчас не готов сказать, потому что у нас очень разные циферки. Общий объем данных не соответствует тому объему данных, что переполз в Динамо, так как часть данных устарела, но мы их из Риака принципиально не вычищали, потому что это дорогостоящая операция. Если мы постоянно будем вычищать… дороже переходить каждый раз на новый Риак.

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

В: А сколько по времени заняла перезагрузка данных?

И: Этот проект был на пару месяцев, по-моему.

В: Именно данные лились пару месяцев? Или вы все делали пару месяцев?

И: Мы параллельно работали по нескольким направлениям, по-моему, за пару месяцев мы перетекли. Я точно не помню, но порядок такой.

В: Нет, а я имею в виду сами данные по проводу сколько времени лились?

И: Дело в том, что мы работали в параллель, записывали в старое и в новое хранилище, и одновременно перетаскивали из старого в новое.

В: А, все, понял.

И: Чтобы не пришлось несколько раз проводить эту операцию. Поэтому суммарно, у меня данные достаточно правильные, пара месяцев.

А: А Динамо на чем написан, кто знает?

В: Знают люди в Амазоне, я подозреваю, что либо Java, либо кресты, либо смесь. Я точно знаю, что у них есть такая штука, которая называется то ли SimpleDB, то ли как-то так, не помню точно. Она на Erlang написана. А DynamoDB — она на чем-то хардкорном написана, по-моему, даже на крестах.

А: Хм, ок, а вот это вот…

В: Возвращаясь к 1.4.9, извини, что перебиваю. Или не надо возвращаться?

А: А чего там возвращаться? 1.4.9, багфиксы. Ты что-то хочешь про эти багфиксы рассказать?

В: Нет, ничего не хочу рассказать.

А: Расскажи нам тогда про Riak 2.0, ты давно его обещал. Что это за дела такие, Валер? Где Riak 2.0?

В: Там, по-моему, 90% до окончания milestone. Они его, конечно, сорвали, они по этому поводу расстраиваются, но у них очень активно кипит работа. Я подписан на большинство риаковских репозиториев, и там каждый день куча пуллреквестов во внутренних командах. И куча всяких обсуждений, и большая часть этого мержится. Судя по всему, у них все готово, просто они занимаются выверением качества, чтобы говно не прошло. Потому что все-таки очень крупный релиз, надо понимать, что там две полностью новых подсистемы, очень большое количество существенных rework-ов, и им очень важно, чтобы не сломалось то, что и так нормально работает.

А: Я правильно понимаю, что 2.0 и ветка 1.4, они обратно совместимы в плане функционала и формата базы данных и тд?

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

Понятное дело, что 2.0 очень сильно отличается. Там, как минимум, полностью новая система полнотекстового поиска и есть честный consistency для отдельных ключей.

А: А ты говоришь, что у них поиск в 2.0, он основан на Solr, если я правильно тебя понял?

В: Да, там очень хитрый огород, они сделали riak-core приложение, которое запускает Java-ноды, которые индексируют Solr-ом, гоняет данные Erlang-ом.

А: Там две виртуальные машины, Erlang и Java?

В: Да.

А: Кхм :) Понятно.

В: Я так понимаю, они пытались сами переписать часть Solr-а, получился Riak Search, и он получился… К нему были нарекания по стабильности, но это было не главное. Это был первый движитель, а второй движитель — догнать по фичам Solr. Команде, которая пилит совершенно другую технологию, это не удастся. Поэтому они решили, давайте просто втащим Solr, и не будем пытаться перегнать его по фичам.

А: С другой стороны, это логично. И нам, как пользователям — ну, поставил, deb-пакет. И норм.

В: Как бы, да.

А: Осталось все остальное… совсем от Эрланга избавиться, все на Java, и станет система как система.

В: Поставь Cassandra, и тебе будет хорошо. Но часть работать не будет. Например, в Cassandra нет vector clock, к сожалению. В Cassandra они выкатили фичу с consistent записью раньше, чем Riak-овцы. При этом обозвали ее micro transactions. А в итоге она у них не работает правильно.

А: Это прискорбно.

В: Да, я тоже так считаю.

И: А кто-нибудь пользует уже эти бета-версии, или хотя бы пробует? Что говорят? Меня интересует поисковик полнотекстовый.

В: Я тебе, к сожалению, про поисковик вообще ничего не скажу. Мы пользуем 2.0, но мы просто из соображений, что когда мы свой кусок системы допишем, который на него опирается, как раз 2.0 докатится. Чтобы не depend-ить старый код. И я в своем домашнем проекте еще использую Riak с consistency. Но у меня там нет большой нагрузки, чтобы сказать, что у меня там совсем действительно все ОК. Там были проблемы в самом начале, сейчас, вроде, все проблемы, которые были в consistency, починили. Вроде, нормально работает. По крайней мере, на моих тестовых нагрузках.

А: А еще в рассылочке erlang-questions некто, я забыл выписать имя…

В: Бенуа, наверное?

А: Сейчас, сейчас, пять сек. Некто Беноит Чезнуа. Много французов, я так понимаю. Опубликовал анонс, что он написал embedded базу данных на Эрланге, назвал ее CowDB, типа «коровья база данных».

В: На самом деле, «copy-on-write».

А: Кхм :) В любом случае… Там у него написано, что версия 0.1.0, но она уже 0.3.0, и он обещал в течение недели 0.4.0 выпустить. Зачем вообще писать базы данных, такие embedded для Эрланга, когда есть Mnesia? Потому что Mnesia очень своеобразная база данных. В частности, записать туда больше 4ГБ сложно. Я уверен, вот Ваня без труда в Mnesia сколько угодно гигабайт запишет, но для меня это сложно.

И: Я предпочитаю Mnesia вообще не трогать.

А: Да, как и большинство нормальных людей. Так вот, и CowDB — это key-value база данных, с индексами, с транзакциями, с нормальным логом. И у нее даже есть то, что в PostgreSQL называется autovacuum. Спросил я у товарища Беноита…

В: Бенуа.

А: Бенуа?

В: Да, Бенуа это читается.

А: Серьезно? Как интересно. Я у него поинтересовался, а чем ему не нравится HanoiDB. На что он ответил, что как-то она поддерживается плохо. Что ему не отвечают на вопросы, и поэтому он взял btree из CouchDB и на базе этой библиотеки написал свою базюльку. Вот такая прикольная штука, нет никаких ограничений на размер БД или количество ключей. За исключением ограничений, которые накладываются файловой системой. Не знаю, насколько оно быстро работает, но звучит очень интересно. Так что вот.

Ты, Валер, что думаешь об этой базе данных, и что она нужна или не нужна в свете существования HanoiDB?

В: Я считаю, что нужна, потому что совершенно разные дисковые структуры. Потому что HanoiDB — это log-structured дерево, типа того же LevelDB, и у него там одна асимптотика по записи и по чтению. У Bitcask другая асимптотика по записи и по чтению, и у него ограничение по памяти. И BTree подход, который использовался в CouchDB, и, соответственно, в CowDB — это третий вариант хранения данных на диске, и для разных workload разные базы будут себя немножко по-разному вести. И тут уже смотреть, что лучше работает в каждом конкретном случае.

И: А сам Бенуа он что говорит? Он для чего рассчитывает ее?

В: Он, короче, делает какой-то хитрый проект, связанный с какой-то… Не знаю точно, надо смотреть. Можно, наверное, поглядеть в том трэде. Сейчас я это сделаю.

А: Он, по-моему, не уточняет, что за проект…

В: Уточняет, он говорит, что это какая-то Юлия, и он на Erlang User Conference про него рассказывал. Я, к сожалению, точно не помню, в чем там суть проекта.

И: Julia — это не та, которая спам отфильтровывает?

В: Не знаю. Там какая-то идея, сделать что-то вроде облачной базы данных. И CowDB — это собственно, хранилище. И я так понимаю, хранилище какая-то часть будет open source’ная, какую-то часть он собрался как сервис делать. И я, к сожалению, уже не помню точно, что он с этим собрался делать. Поэтому я не хочу соврать. Но я попробую поискать во время выпуска. Если что-нибудь найду, то я свистну обратно и подниму эту тему.

А: Ок. Мне кажется, эта база данных может быть интересна, потому что, помимо того, что ее можно заюзать в своих эрланговых проектах (тем трем людям, которые пишут на Эрланге) тем, что там исходники открыты, можно посмотреть и переписать на чем-нибудь другом.

И: А как она поддерживает отказоустойчивость? У нее master-slave какой-то или что?

В: Не, это как LevelDB или Bitcask, это хранилка.

И: Как на ней тогда будешь делать серьезные проекты, без поддержки вот этой отказоустойчивости?

В: Я же говорю, что господин Бенуа, он ее пилит сейчас как storage substrate для своего следующего проекта, который будет. Вспомнил, проект называется refuge.io, и в рамках его пилится какое-то количество решений для хранения и репликации. Я так понимаю, там хранилкой будет CowDB, репликацией будет еще какая-то штука. И еще какая-то штука будет сервисом, который будет связывать вот эти хранилки и репликацию между собой.

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

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

А вторая цель — это мы ждем до конца, когда он допилит полностью свое. Откроет, возможно, не только CowDB, но и ту прослойку, которая над ней работает. И, возможно, эту связку будет использовать еще удобнее.

В: Да, да, именно так.

А: Я от себя хочу сказать, что репликация на Эрланге пишется строк в двести, просто я ее пару раз уже писал.

В: Саша, это очень спорный момент. Потому что хорошо сделанная репликация — это сложно.

А: Речь идет о синхронной мастер-слейв репликации.

В: Асинхронной — в смысле …

А: Синхронной.

В: Синхронной — даже с ней можно очень хорошо нафакапить. И притом, понятное дело, синхронная репликация — это не самая офигительная по производительности вещь.

А: Давай, расскажи мне, как можно нафакапить с синхронной мастер-слейв репликацией?

И: Latency какая у тебя допустимая? На запись? Когда у тебя начинает возникать предположение, что, возможно, сеть отвалилась? Что ты делаешь в этом случае?

А: Когда сеть отвалилась?

И: Ты пишешь с мастера на слейв, внезапно слейв начинает отвечать на одну миллисекунду дольше, чем ты ожидаешь.

А: Нет, погоди, у тебя слейв читает с мастера.

И: Слейв читает с мастера? То есть, у тебя не…

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

Там синхронная — в другом смысле, что это у тебя по TCP и все доезжает…

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

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

А: Тебя, Валер, опять понесло в сторону Paxos’а и распределенщины. А я всего лишь сказал master-slave репликация.

И: Я только хотел сказать, добро пожаловать в мир Паксоса.

В: Я к тому, что у тебя слейв, он был слейвом всегда, пока ему руками не запромоутишь до мастера?

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

И: Цель немного другая.

А: Да. А еще, как кое-кто и слушателей может знать, я большой любитель Хаскеля, в частности, проекта Cloud Haskell. Есть такая штука, Cloud Haskell Platform. Это как OTP в Эрланге, только для Хаскеля. Там есть supervisor, есть gen_server-а, которые там называются managed process. И с этой платформой была такая история, что она есть. Но она есть на GitHub, и ее нет в Hackage. И чуваки ее пилят-пилят, но никак не выложат. Ее можно подрубить к проекту на Haskell, но с помощью механизма cabal-овского.

А недавно относительно ребята это выложили наконец на Hackage. И у нас прямо есть Cloud Haskell с платформой, с supervisor-ами, с gen_server-ами. И оно даже в первом приближении работает.

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

В: Здорово. Я тут тоже причастился. Я впервые в жизни нанес какого-то общественно полезного добра на Haskell. Я раньше писал на Haskell, но все либо универское, либо себе в стол. Тут, наконец, случилась задачка, которую можно было решить на Haskell, я написал анализатор LevelDB-шных логов, которая пишет в Graphite то, что наанализировала. И мне в большей части понравилось, но есть претензии к Haskell, особенно в плане того, что… С одной стороны, очень непонятно, попытки распараллелить код приводят к тому, что не всегда понятно, почему некоторые спарки к тому моменту, когда их попытались вычислить, им оказалось нечего вычислять. Там есть целый класс таких проблем, связанный с тем, что слишком сильно распараллелил. Или связанных с тем, что переключение спарков начинает потреблять практически половину времени от времени выполнения программы. Были проблемы с ленивостью, связанные с тем, что я начал, чтобы не отказываться от удобства работы со списками (мне нужно было просто данные переварить), и в однопоточной программе на lazy IO это ложится просто прекрасно. Когда я попытался распараллелить, это начало все странно работать с lazy, и мне пришлось сделать unsafePerformIO. Я, конечно, потом исхитрился без него написать, но это медленнее работало. В целом, не без проблем, но мне понравилось.

А: Ты, Валер, совершил огромную ошибку. Ты же прекрасный и вечный Haskell попытался протащить в продакшн. Вместо того, чтобы на Perl написать два однострочника с регулярными выражениями.

В: Там не факт, что получилась бы регулярка, это во-первых. Во-вторых, там очень много файликов и я подумал, что раз Haskell так классно параллелится, давайте я буду эти файлики в параллель разгребать.

И: Погоди, ты только что сказал, что не все можно решить с помощью регулярных выражений в Перле?

В: Мне же нужно не просто разобрать, мне еще нужно статистику посчитать.

А: Валер, регулярные выражения в Перле полны по Тьюрингу, ты с их помощью можешь решить все, что угодно.

В: Серьезно? Все вот настолько плохо? Буду знать. И остерегаться Перла еще больше.

И: Возвращаясь к теме, вот этот вот Cloud Haskell, у него полнота — примерно то же самое, что в OTP, или он на какую-то подчасть только рассчитан?

А: Он сделан как OTP, там чуваки особо не скрывают, что да, мы переписываем Erlang на Haskell. Там те же самые handle_call, handle_cast, handle_info. Плюс есть еще хаскельные типизированные каналы, как отдельная сущность. Плюс там есть handler отдельный для сообщений, которых ты не ждал, как я помню. Это скорее как подмножество, у чуваков я пока не увидел gen_event. Ну, и, правильно, кому, в самом деле, нужен gen_event? У чуваков, понятное дело, нет gen_fsm, нет этого, я забыл как называется кастомный supervisor.

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

Еще, что интересно, помимо того, что ребята реально взяли Erlang, и сделали его библиотекой на Haskell, то, что у этой библиотеки код очень приятный и прямо в него смотришь, и понятно, ага, мы тут идем в STM, кладем сообщение в очередь.

И: Круто, круто, а каких-то проблем с типизацией у них там не было? Как, к примеру, ожидать произвольное сообщение, пришедшее в канал? Или еще что-то типа такого?

А: В Cloud Haskell у тебя есть отдельно нетипизированная очередь, и очередь типизированная. С типизированной, я надеюсь, все более-менее понятно, да? Ты туда фигню положить не можешь.

И: Да, это понятно.

А: С нетипизированной — у Haskell в рантайме ты можешь определять типы. Короче, там есть некий механизм рефлексии.

И: Это нерекомендуемый способ, грубо говоря? Хотите использовать правильно — используйте типизированный, и все нормально будет?

А: Они сами пока не могут понять, что они рекомендуют, потому что неясно. Например, если ты сделал link, у тебя, понятно, нет никакого типизированного канала, в который придет сообщение, что сущность упала. Поэтому у тебя оно по-любому придет в нетипизированную очередь. И ты по-любому ее используешь. Понимаешь, да, в чем дело?

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

А: Я ничего не понял, но ты тронул мое сердце.

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

А: У меня в бложике есть серия постов без платформы, просто основное — линки, обмен сообщениями, если тебе интересно. Там довольно все няшненько, удобно у них.

И: В шоу ноты надо обязательно добавить.

А: ОК. А еще, к сожалению, Сережа Елин к нам не присоединился, он собирался, но не смог или не захотел, я не знаю. В общем, он, как главный специалист по Cowboy, должен был рассказать про новый Cowboy 0.10 новый, относительно, опять же. Что там нового, интересного. Но, видимо, не расскажет. Но как я понял, там чуваки обратной совместимости особо не сломали, вопреки традиции. Никто не смотрел?

И: Нет.

В: Нет.

А: Сейчас глянем changelog…

В: Я вот тут походил еще по ссылкам Бенуа, у него есть еще один какой-то проект camp.io. Я так и не понял, этот refuge.io как-то тесно связан с camp.io? И тот, и другой — распределенные базы данных. В одной из них там даже ACID гарантии обещают. Правда, ничего не понятно, как с этим жить и что это вообще такое. А проект для репликации поверх CowDB называется enki. Я думаю, мы потом просто приложим ссылки к подкасту.

И: А кто это такой? Какой-то он производительный чувак.

В: Этот товарищ в какой-то момент присоединился к CouchDB, пилил-пилил, потом форкнулся от нее, начал пилить какой-то свой проект, какой-то rcouch, openCouch, что-то такое. Потом они ответвились, и сейчас пилят что-то этакое свое. Сейчас Couch двигают в основном две группы людей, это Cloudant и вот эти ребята с rcouch. Притом Cloudant как бы громче кричит.

А: Касательно changelog ковбоя, тут какие-то API они задеприкейтили, какие-то добавили. Есть теперь поддержка multipart body.

В: Она и раньше была, просто переделана. Или ее не было?

А: Тут написано «сделана поддержка», «add support». В 0.10. Тут всякие обновления документации, всякие оптимизации. Такой, не сказать, что шибко интересный релиз.

И: Интересно, когда они хотят 1.0 выпускать?

В: Говорит, летом.

А: Говорит, скоро. Тут прямо написано, что этот API depricated, и в 1.0 его не будет. И тут довольно много упоминаний 1.0.

И: Молодцы, молодцы, ждем.

А: У нас кончились темы, которые я добавлял. Вань, я так понял, ты хочешь поговорить за Docker и за DevOps?

И: Да, я поднял эту тему, и вообще в целом DevOps, как движение хотел с вами обсудить. Насколько вы его хорошо применяете? И вообще как относитесь?

А: Раз ты вопрос поднял, расскажи для протокола, что такое DevOps?

И: Я думаю, что единого правильного ответа, что такое DevOps, наверное, даже не существует. Есть несколько апологетов, которые полагают, что это слегка отличающиеся между собой понятия. Как его представляю себе я, это такое многогранное движение, у которого есть несколько положительных сторон. Команда целиком направлена на реализацию тех вещей, которых ей нужны, и нет разделения между тем, кто занимается какой частью. Нет отдельно development, нет отдельно operations. Есть одна команда, которая знает, как делать все подряд.

С одной стороны, это позволяет очень быстро перенаправлять ресурсы с одного на другое. С другой стороны, получается, что люди, которые очень хорошо понимают development, стандартизацию разработки, в том числе code review, QA, отдельно как стадии. Они это обязательным делают и для всего остального, в том числе и для operations. В этой области operations это часто отсутствует во многих компаниях. И получается такая синергия, как бы, такой микс, который очень хорошо повышает уровень большинства команд, где его, эту концепцию DevOps, пытаются использовать.

А: Речь идет о том, чтобы смешать разработчиков с админами, или смешать вообще всех, c QA, чуваками, которые доки пишут, если такие есть?

И: Вообще, DevOps появлялся, именно как разработчиков с админами. Конечно же, тут имеется в виду не так смешивать, что пошел и человек, которые кабели обжимал, внезапно стал писать в бэкенд. И патчи в Riak посылать. Нет, предполагается, что у тебя уже есть какая-то базовый, достаточно мощный, уровень, на котором ты строишь все. Тебе не приходится скручивать провода, для того, чтобы тебе составить новый супербыстрый уровня Гугл большой кластер производственный. Нет, у тебя есть, скажем, Амазон или DigitalOcean, и на базе него ты хочешь быстренько сервер распределенный запилить, его какими-то свойствами наделить, оркестрация, управление chef/puppet. Все эти вещи, они с одной стороны принадлежат operations, с другой стороны они не очень далеко ушли от development, чтобы можно было всех людей, которые в этой области, объединять.

А: Мне эта идея кажется несколько странной. В том описании, которое ты дал. Получается, что я, разработчик, сижу, пишу код, никому не мешаю. И тут ко мне кто-нибудь прибегает: «У нас там в продакшене грохнулся мастер Постгреса, все почини срочно». Я правильно же идею понял?

И: Предполагается, что не прибегут с таким вопросом, а к тебе придут с таким вопросом за два года до этого и скажут: «Слушай, давай все так сделаем с Постгресом, чтобы когда все сломается, оно все автоматически восстановилось». И ты начинаешь думать, как это все правильно сделать, общаешься с людьми, которые это умеют делать, чисто на уровне PostgreSQL. И говоришь им, не, так не пойдет, как вы делаете, давайте сделаем, чтобы это работало автоматически, при этом по нажатию кнопки, все такое. И решаешь проблему заранее так, что у тебя в конце концов, когда происходит оповещение, что мастер упал, у тебя через две секунды приходит оповещение, что у тебя уже slave заработал как мастер, и все нормально. И наливается новая нода, на всякий случай.

А: Ну, хорошо. А, казалось бы, причем тут Докер?

И: А Докер — это очень интересное приложение, которое в этом направлении неплохо работает. Вообще, Докер — не единственное приложение, которое упоминается в DevOps направлении. Но одно из испытывающих самый большой хайп, самое большое движение, самое большое обсуждение вокруг. Докер — это уровень а-ля виртуальная машина, но не виртуальная машина, облегченная виртуальная машина. На уровне LXC контейнеризации, они позволяют тебе создавать некую абстракцию, как бы виртуальную машину. Которая на поддержку виртуальной машины практически не тратит ресурсов. И, скажем, если ты запускаешь постгрес в линуксе через докер, то у тебя она работает как будто она в чистом окружении работает, как будто у нее нет еще линукса там. И это позволяет тебе развертывать очень быстро окружение. Приходит новый человек, ты берешь docker image, и говоришь ему, вот на эту кнопочку нажми, у тебя поднимется окружение как и у всех остальных. Не надо ничего делать.

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

А: Я хочу сказать две вещи. Что докер я пробовал. Я прошел этот их online tutorial, интерактивный. И я бы его с радостью использовал у себя на машине, но только у нас на работе есть нормальное dev окружение, куда я и деплою код, поэтому мне как-то и не нужна локальная постгря в виртуалке. А так-то штука прикольная.

Вторая вещь — что мы в какое-то время проходили вот это «а давайте у нас все будет в виртуалках, виртуалки — это как железные машины, даже лучше». Мы долго пытались оптимайзить под эти виртуалки, при условии шумных соседей и прочих тормозов. Закончилось все тем, что мы перешли на нормальные железные машины, и у нас все стало работать нормально, и жизнь сразу стала прекрасна.

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

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

А: У нас реально была проблема, что к тебе приходит QA, и говорит, что вот, там на машине у вас все тормозит. Сделайте так, чтобы не тормозило. Ты ему говоришь: «Нет, оно на самом деле работает круто, а у вас там тормозная виртуалка». И закончилось тем, что стали разрабатывать под тем же окружением, под которым оно и работает в продакшене. И у всех все стало хорошо.

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

И: Я бы еще четвертое добавил, это удобство ведения стандартных процедур. А-ля ты написал изменение в какой-то контейнер, и говоришь, ребят, пожалуйста, посмотрите мне изменение. Кто-то провел тебе CR, потом кто-то провел тебе QA, если у тебя есть локальное окружение для локального тестирования постгри, ты так сделать не сможешь.

А: Ну, хорошо, а где так делают?

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

В: Яндекс, говорят, его использует. Они давным-давно сидят на LXC контейнерах, и поговаривают, что они сейчас Докер используют.

И: Поговаривают, что очень много компаний его использует. Его пилят активно все — Google, Yahoo и так далее. Вопрос, кто реально большие свои системы на него перевел. Такой информации прямо сейчас у меня нет, хотя надо поискать, я думаю, она где-то есть.

Но вот начать посмотреть, как сделать локально окружение для своей компании — я уже начал, я пытаюсь поглядеть подробно. Это на самом деле очень удобно.

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

В: Кстати, у них на сайте написано что ebay и mailgun используют docker в продакшене.

И: Тогда у вас уже не уникальная возможность.

А: Тогда все, чуваки, вы профукали все, как обычно.

В: А, нет, ebay его для continous integration его использует. И mailgun тоже. Черт, они оба для CI его используют. У них как бы такой, не совсем еще prod.

И: Там проблемы, говорят, есть с сетью, когда у тебя контейнеры внутри машиночек крутятся, не так просто сделать правильную конфигурацию. А что плохо с mac-ом, у тебя контейнер не может крутиться прямо на mac. Он должен крутиться на линуксе, поэтому контейнер крутится внутри виртуальной машины. Это отдельная богатая история. Прямо сейчас есть проект, называется который boot2docker. Он поднимает супер легкий образ для VirtualBox, и внутри него запускает тебе docker, и делает очень плавное и мягкое проксирование. Ты работаешь с докером, и даже не обращаешь внимания, не замечаешь, что у тебя есть виртуальная машина между тобой и докером. Но там все равно есть куча граблей с сетью в частности, с настройками и тд. Они очень активно развиваются, и вы можете видеть, что даже для MacOS есть отдельное приложение, которое на самом деле активно очень пилится, там выходят релизы чуть не каждую неделю новые, надо постоянно обновляться.

А: Мне это напоминает то, о чем я в Twitter недавно писал. У тебя VDS, внутри которого работает Docker, внутри которого работает виртуальная машина Erlang-а, на котором работает Erlang, который тебя абстрагирует от виртуальной машины, потому что есть Erlang, а есть Erjang.

И: А вот, кстати, Erlang, вообще хорошая вещь, надо его использовать напрямую на железе, как вон на Xen делают, и все!

В: Там свои проблемы, там нет файловой системы ни разу. Кстати, вот про проблемы с сетью докера, я могу распространиться, если кому-то интересно. Я с ним игрался. Они сейчас, ближе к 1.0, по-моему, где-то в 0.9.1 они сделали офигительную вещь. Они позволяют тем контейнерам, кому очень-очень надо, наиболее частый юзкейс — просто сказать «докер, пожалуйста, убери от меня свой NAT». И просто сеть к хостовой машине оказывается в контейнере. Это прекрасно, и большинство проблем это решает.

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

В: Не, как раз работа с локалом идет прекрасно. Вот смотри, собственно, как я экспериментировал. Я пытался развернуть кластер Riak-а на одной машине. Пока у тебя контейнеры докера на одной тачке, сеть между ними себя чувствует прекрасно. Пока у тебя контейнеру кроме порта и айпишника наружу выбрасывать ничего не надо, все себя чувствует прекрасно. Если контейнерам с разных машин вдруг нужно друг c другом общаться напрямую по IP, а не просто через порт, то вот тут начинаются проблемы. Есть проект pipework, который позволяет все руками настроить. Его можно теперь, если тебя устраивает вариант, что ты просто отдаешь сетку хостовой машины, то есть возможность отказаться от докеровского NAT-а. И в случае деплоя Riak-а на тестовое окружение и деплоя Riak-а на продакшн, меня это вполне устраивает. Потому что на тестовом окружении у меня все равно все контейнеры на одной машине, а в случае продакшена, мне не нужно два экземпляра Riak-а на одной машине. Блин, это база данных. Поэтому меня это теперь вполне устраивает.

А: У меня вопрос к Ване. Ты, как я понимаю, среди нас троих самый мудрый и опытный Erlang-разработчик, так ведь?

И: Я так не готов гарантировать это. Мне кажется, вы тоже там потрогали его уже достаточно сильно.

А: Ну я, я чего — года полтора всего на нем пишу. Вот смотри, у тебя есть приложенька, которая генерит JSON, по хттп его отдает. И у тебя возникает проблема, потому что этого JSON-а сто метров, а если ты эти сто метров JSON-а будешь кодировать JSX-ом, то оно у тебя будет кодироваться 30 минут. Ты можешь заюзать какую-нибудь NIF-ку, но эта NIF-ка у тебя остановит тред шедулера, секунд на 5. У тебя придет восемь одновременно запросов, и у тебя виртуальная машина встанет. Как правильно решается эта проблема?

И: Давай так, начнем с самого правильного решения. У тебя не должно возвращать JSON размером несколько метров.

А: Это понятно.

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

А: Вот почему я с таким любопытством в последнее время посматриваю на Scala, потому что Erlang, он, конечно, замечательный. Но как же он ограничивает программистов! Вот, например, я не хочу, чтобы у меня были отдельные кучи на каждый процесс. Я хочу, чтобы на несколько процессов была общая куча. Я не хочу, чтобы у меня все очереди были неограниченного размера, без приоритетов. Я хочу, чтобы у этого процесса была неограниченная очередь, а у этого была очередь ограниченного размера с приоритетами. А вот из этой очереди чтобы два процесса или десять выгребали round-robin-ом. В этом смысле та же Scala дает большую гибкость, поэтому она мне последнее время так интересна.

И: Она дает больше возможностей прострелить себе ногу.

А: Это бесспорно. Я просто все к тому, что когда изучаешь Erlang, там все так здорово, так замечательно. У тебя акторы, сообщения туда-сюда. Но на практике оно не всегда настолько уж здорово.

И: А еще возвращаясь, у тебя же большие бинарники тоже шарятся, нет?

А: Бинарники — да.

В: Например, есть такой чудесный подход, в Clojure, в Scala персистентные структуры данных. В Haskell тоже. Отлично чисто функциональный подход. Но я не могу, и ты не можешь, и Саша не может в Erlang нормально использовать подход, так чтобы от него иметь бенефит, когда у тебя есть чистая структура данных, которая пошарена между парой процессов. Потому что все равно она не мутабельна. А один процесс ее сериализует, другой ее пишет, к примеру. При том, тот, который сериализует, может гарантированно снапшот снять. За O(1). Сам снепшот, понятное дело, что писать он его будет за O(N). И Erlang этого вообще не позволяет.

Было бы здорово сказать, что вот есть два процесса с одной кучей. Этот писатель, а этот читатель.

А: Я просто все это в контексте того, что наблюдаю некоторую эйфорию, «Erlang — это здорово, давайте наш проект напишем на Erlang». Ребята, возможно, вам этого не нужно, потому что Эрланг — он на самом деле довольно нишевый язык. Честно.

И: Серебряной пули не существует, это ты все правильно говоришь.

А: Вы должны очень хорошо понимать, что вы делаете. У вас там, извините, Ruby, может намного лучше решит вашу задачу, если вы пишете просто REST-обертку над базой данных.

И: Регулярные выражения в Perl, мы же знаем ответ.

А: Да, действительно.

Я боюсь, что время закончилось, если ни у кого не осталось ничего сказать. Нет?

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

На этом у нас все, подписывайтесь, лайкайте, следите за нами в Twitter, подписывайтесь в iTunes. Я выяснил, что под Android есть много приложений, которые умеют ходить в iTunes. Так что, если вы сидите под Android, подписывайтесь на подкаст.

И: А я подписываюсь в iTunes на макоси, а потом на Android синхронизирую папку.

А: Так тоже можно. И, всем пока.

И: Всем счастливо.

В: Пока.

Дополнение: EaxCast S02E05 — интервью с Никтой Прокоповым о Clojure, ClojureScript, а также реактивном программировании

Метки: EaxCast.