Факты
- Cделал свой блог на Node.js и OpenVZ
- Использовал vi 15 лет, потом узнал про :q и перешел на vim 🙂
- Как-то провалил экзамен по дисциплине «Операционные системы»
- Любимый персонаж из фильмов — HAL9000
- Не любит C++, но довольно тепло относится к Go
Для меня все началось, конечно же, с информатики. Я изучал дисциплину «Computer science» в Падуанском университете. Я был без ума от компьютеров с подростковых лет. Кстати, впервые познакомился с компьютером лет в одиннадцать-двенадцать.
Первые хаки мы с друзьями проворачивали, когда еще не существовало интернета. Начинали с простого реверса и анлока секретов в компьютерных играх. Мы разбирались, как разблокировать секретные уровни в играх, и для нас это было не просто забавой, а осознанными, настоящими попытками взломать игру. За этим делом я провел множество дней и ночей (особенно долгих зимних).
Одним из моих первых хаков стала находка, как расширить память в MS-DOS, чтобы запускать игры, которые требовали больше памяти, чем было у моего компьютера. Комп у меня был очень медленный, но хакинг MS-DOS позволил мне играть в то, во что я хотел. Уже позже мне в руки попал мануал по MS-DOS, и только тогда я наконец понял, что это было и как работало.
Потом я поступил в университет, у меня появилось много хороших друзей-единомышленников, и мы немедленно создали студенческий форум. Тогда еще не существовало Facebook или чего-то похожего, еще не было социальных сетей. Стоял примерно 2003 год. Как ни странно, наш форум быстро набрал большую популярность.
На форуме было три раздела: о нашем университете, о компьютерах и обо всем остальном, вроде спорта, фильмов и хобби. Самым большим и популярным разделом стал именно раздел о компьютерах. Вскоре там начали проявляться люди, которые болели идеей open source, и мы с ними много общались об этом. Помню, в то время я проводил огромное количество времени, разбираясь с BSD-системами, их ядрами. Я не был контрибьютором, но участвовал во многих конференциях, стараясь обмениваться с людьми своими находками. Вы до сих пор можете найти мои публичные ответы в конференциях и форумах того времени.
С университетскими друзьями мы, вне рамок занятий, изучали множество всего. У нас были курсы Operating systems и Networking. Благодаря внеклассному обучению мы заработали очень высокие баллы по этим дисциплинам. Мы постоянно разбирали исходный код множества популярных в то время open source проектов, что давало свои результаты.
Rails стал моей первой по-настоящему большой любовью тогда. Я начал писать на Rails во времена версии 1.2. Потом случился небольшой перерыв, и я переключился на Node.js, когда он был примерно 0.3.
Кстати, даже у нас с друзьями случались и непримиримые холивары. Скажем, я относился к группе, которая поддерживала BSD-системы. Я до сих пор считаю, что качество кода в BSD куда выше, чем в Linux, но кого сейчас это волнует. Linux популярен и неплохо работает. А в то время, когда конкуренция между ними была еще на равных, у нас случались настоящие войны. Я пытался объяснить линуксоидам, что работа с BSD требует куда более глубокого понимания кода и понимания работы ядра. Но Linux был намного проще, поэтому войну я проиграл.
Spreecommerce
После университета я не смог найти хорошую работу в своем родном городке. Мне пришлось работать на должностях, никак не связанных с моими компьютерными скиллами. Но где-то в 2008 году мне наконец повезло — я нашел небольшую компанию возле дома, и они меня взяли. Там работали всего три парня, но все они оказались сертифицированным специалистами Red Hat.
Меня взяли на работу и заставили изучить Red Hat. Со временем я даже стал сертифицированным инженером Red Hat. Тогда у меня появилась возможность заполнить пробелы в знаниях, например глубоко изучить механизмы групповых политик в Linux. Спасибо этой работе, она дала мне возможность окунуться в настоящий «корпоративный» Linux. Потом уже мы всей компанией перешли на Debian во всех наших продуктах, но по-прежнему оставались крутыми спецами по Red Hat.
Кстати, компания называлась RHX, RH — кровь, X —это LinuX, типа Linux у нас в крови :). Правда, клиентам мы это объясняли иначе: говорили, что это расшифровывается как Red Hat eXperts, ведь все мы были Red Hat certified инженерами.
RHX занималась деплоем и поддержкой проектов средних размеров. В основном мы поддерживали и разворачивали проекты клиентов, иногда дописывали что-то сами. Нетрудно догадаться, что в основном это был e-commerce: довольно крупные интернет-магазины и другие сопряженные с ними вещи. Не eBay, конечно, но тоже довольно серьезные штуки.
В один прекрасный момент мы начали пилить собственное e-commerce-решение на Rails. У нас был очень крутой Rails-консультант, он помогал нам правильно выстроить архитектуру Spreecommerce (так называлась наша платформа). Мы хотели сделать ее отличной от open source’а, существовавшего на рынке в то время.
Тогда многие компании, которые занимались разработкой интернет-магазинов, представляли довольно унылый функционал. Многие вообще устанавливали своим клиентам WordPress и скрипт интернет-магазина. Нам такой подход очень не нравился, нам казалось, что мы обманываем клиентов, поступая таким образом. Как же так, клиент пришел к нам, заплатил за полностью кастомное решение, а мы ставим ему WordPress с плагином и немного перепиливаем шаблон? Однако тогда так поступали все. Но мы не хотели так работать. Поэтому стали пилить Spreecommerce.
До Spreecommerce многие наши клиенты использовали на бэкенде очень старые и костыльные решения. Они не умели даже экспортировать XML или CVS. До сих пор помню те жуткие ночи, когда мы разбирались с кривыми самописными CMS своих клиентов, считая символы и пытаясь правильно разбить строки по точкам с запятой. Веселое было времечко!
Со временем клиенты сами стали просить нас о переводе на Spreecommerce. Так мы потихоньку захватили локальный рынок Италии, хотя совершенно не собирались этого делать. Просто так получилось.
Сегодня на Spreecommerce работает один из самых крупных автомобильных e-commerce-сайтов в Италии (да и в Европе вообще). Мы потратили огромное количество времени, оптимизируя и допиливая «рельсы», чтобы они могли обеспечить необходимую нам производительность. Думаю, если бы мы остались на WordPress с плагином, как и все остальные, подобное было бы невозможно в принципе.
Сложности масштабирования
Работая со Spreecommerce, я впервые столкнулся с проблемой масштабирования. У меня на руках имелся большой сайт, его нужно было масштабировать, всем этим нужно было как-то управлять и отдавать посетителю очень быстрый ответ. Клиенты часто писали нам: «Да, это круто работает, выглядит хорошо, удобно для покупателей, но сайт все равно очень медленный». Нам требовалось что-то более быстрое.
Тогда я по-настоящему осознал, что деплой больших приложений — это совершенно другой мир, никак не связанный с разработкой приложений. Разработчики создают приложения локально, и у них вроде все работает, но, когда пытаешься запустить эти программы в продакшене, а особенно на большом количестве серверов, начинаются проблемы. А когда у тебя проблемы в пик нагрузки — компания теряет деньги каждую минуту.
Я начал изучать вопрос деплоя самостоятельно где-то в 2010 году. Было весьма интересно. Начал я, конечно, со знакомого. Пытался найти способы автоматизации деплоя Rails-приложений. В общем, я пришел в деплоймент по классической схеме: «создал программу — она начала работать — появилось много людей — все начало тормозить — пришло понимание, что нужно масштабироваться — как это сделать правильно?». Все оказалось сложнее, чем я привык. Занимаясь кодингом, я всегда мог рассчитывать на помощь нашего Rails-консультанта. А теперь помощи ждать было неоткуда, приходилось изучать все самостоятельно. Конечно, у меня имелся опыт разработки Rails-приложений, поэтому мне было легче, не так тяжело, как пришлось бы человеку, который вообще не программировал раньше и вдруг решил разобраться в DevOps.
Все, что я делал по деплою, — изучено в свободное время, никто мне за это не платил. Напомню, что на тот момент официально я занимался разработкой бэкенда и клиентской части на Rails. Столкнувшись с проблемой деплоя Rails-приложений, я понял, что это долго и не очень удобно.
Приходилось использовать, например, Capistrano. Нужно было писать довольно замысловатые конфиги правил для Capistrano, чтобы иметь возможность одной командой задеплоить все на сервер. Дописывать какие-то хуки, чтобы заставить это работать так же, как на локальной машине. По-моему, тогда мы вообще первыми по-настоящему открыли Capistrano.
Мы начали использовать виртуальные машины для проектов наших клиентов. Писали скрипты деплоя для Capistrano, которые нужно было запускать, чтобы поднять в чистой виртуальной машине окружение для их приложения, а потом отдавали эти скрипты клиентам, рассказывая, как с ними обращаться. Люди продолжали пользоваться этими скриптами (для всего, не только для «рельсов», но даже для PHP), даже перестав работать с нами.
Конечно, не только мы предпринимали попытки создать нечто подобное. Помню, в 2012 году я поехал на какую-то конференцию от Amazon. Там я встретил одного чувака, у которого поинтересовался, какие инструменты они используют для автоматического деплоя приложений. Ведь у них должно было иметься что-то Amazon-ready, что-то стабильное, чтобы можно было взять и сразу использовать на продакшене? Но он не сумел даже объяснить мне, что именно он продает, не говоря уже о каких-то подробностях про деплой на продакшен.
Сам Amazon просто не был готов на тот момент предоставить PaaS в этой сфере. У них была своя инфраструктура, но непригодная для использования конечными клиентами.
Тогда меня посетила идея создания первой в Италии PaaS, которая позволила бы разработчикам одним махом пушить свои приложения в облако и больше не думать ни о чем. Разработчикам не пришлось бы заниматься конфигурированием, только писать приложения и пушить их одной командой, а дальше все масштабировалось бы само собой.
Тогда я попытался донести до своего босса потенциал нового проекта от Red Hat, который назывался OpenShift. Это была первая попытка создать по-настоящему стабильное решение для запуска контейнеризированных приложений.
Помню, впервые я установил и попробовал OpenShift, когда он был даже «младше» v1.0. Суть такова: ты устанавливаешь OpenShift на сервер, конфигурируешь, и разработчик может парой кликов в GUI или командной строке создать на этом сервере контейнеризированное Rails-приложение и масштабировать его, дать ему больше или меньше ресурсов, может даже перенести его куда-то.
Но OpenShift оказался очень-очень нестабильным, тогда он, правда, был очень хрупким, постоянно падал и... в общем, не подходил для продакшена. Помню, первые приложения, которые портировали на OpenShift, были PHP, WordPress или даже Node.
На все руки мастер
Я работал в RHX, когда одна компания в Милане пригласила меня на собеседование. Они пообещали, что я буду разрабатывать именно такой PaaS, как я и мечтал: что-то похожее на OpenShift. У них даже имелось некое собственное решение начального уровня.
Позже выяснилось, что они фактически меня обманули. Вместо работы над PaaS мне сказали: «Чтобы начать разработку собственного решения, нам нужно время. У нас его нет, потому что все оно уходит на экстренные падения приложений клиентов. Чини падающие приложения клиентов, а в оставшееся время можешь пилить наш PaaS».
Я был сильно разочарован, что не могу применить свои знания об OpenShift и контейнерных приложениях. Я хотел работать над первым PaaS в Италии, который позволял бы разработчикам одной командой пушить приложение в облако и больше ни о чем не думать. Однако вместо этого я стал чуваком-суперменом, который в любое время дня и ночи поднимал упавшие сервера и приложения, причем на довольно низком уровне.
Я был реально overskilled для такой тупой работы. Я фиксил очень заурядные и самые разнообразные серверные проблемы огромного количества клиентских приложений. Я попытался возмутиться, сказать, что был нанят как Senior system administrator и эта работа не для меня, что я должен продумывать и разрабатывать архитектурные решения, а на деле просто чиню упавшие почтовые сервера. Не помогло. Это было ужасно. У компании было множество нервных и агрессивных клиентов, которые звонили мне 24/7, а я в любое время должен был работать для них нянькой.
Единственный плюс работы в той компании — мне приходилось поддерживать куда более крупные и разнообразные проекты, чем я привык. Я приобрел довольно много highload-навыков, например по-настоящему глубоко разобрался с кешированием на примере приложений клиентов, понял, как работают самые разнообразные разработчики. Ближе к концу я обслуживал уже порядка 800 виртуальных машин.
Как-то раз я заговорил со своим CTO и предложил ему опробовать Puppet. Он дал согласие, и я был реально счастлив, нам сразу стало легче администрировать такую инфраструктуру. Хотя Puppet довольно низкоуровневая штука, он все равно оказался хорошим вложением времени.
Когда «наступил» Heartbleed, многие наши клиенты были в панике. С помощью Puppet мы за два часа написали новый манифест и в течение дня пропатчили все виртуалки, закрыв уязвимость. Без Puppet это было бы невозможно в принципе.
В общем, светлая сторона у той работы имелась. Я получил возможность каждый день заниматься performance-штуками вроде Varnish, Redis, Memcached и, насколько мне позволяли, экспериментировать с автоматизацией деплоя. Однако все плюсы перечеркивали emergency-клиенты.
Примерно год назад я начал смотреть по сторонам, так как эта работа оказалась скучной и стрессовой. Мой CTO постоянно пинал меня: «Ты не знаешь этой штуки, Фабрицио? Как же так?! Ты что, не знаешь, как починить это немедленно, Фабрицио?» Я был в постоянном стрессе от его в общем-то необоснованных претензий. Плюс у нас постоянно случались какие-то чрезвычайные ситуации — то ломались диски, то мы находились под DDoS-атакой.
В общем, это был полнейший отстой. Ты сидишь на ужине с друзьями, а тебе звонит разъяренный клиент, у которого что-то сломалось, и ты вынужден все бросать и бежать, читать логи Nagios, смотреть, что случилось на Firewall, разбираться, почему загрузка на CPU вдруг 100%. Судорожно звонишь коллегам, пытаешься что-то сделать... Это было просто ужасно. Я хотел имплементировать свои знания о PaaS, а вместо этого занимался такой фигней.
Месть программиста и OpenStack
Осознав, что все плохо, я начал смотреть по сторонам и искать похожие PaaS, вроде того, что было у меня в голове, думал присоединиться к какой-то уже работающей команде. Я знал, что какие-то чуваки в Америке делали нечто подобное на базе KVM, вроде бы open source, но все было просто отвратительно документировано. Конечно, у них имелась платная поддержка и SLA, но это было не то. Одно дело, когда ты должен постоянно писать какие-то тикеты, ждать ответа и ломать их код.
Совсем другое дело — OpenStack, когда перед тобой, по сути, огромное комьюнити разработчиков, где ты можешь быстро получить ответ на любой интересующий тебя вопрос. Тогда-то я по-настоящему и загорелся OpenStack.
Я поинтересовался на работе, почему мы не используем OpenStack, ведь это решило бы множество наших проблем. Куда лучше использовать хорошее, проверенное опенсорсное решение с хорошим комьюнити, чем самописный «костыль».
Я предложил попробовать OpenStack хотя бы в тестовом режиме, создать отдельную лабораторию, обкатывать сначала на ней. Но нет: это будет дорого, это будет долго, мы сами не справимся, нам придется нанять внешнего консультанта и все такое. Я ответил: «Парни, ну давайте я сам попробую перевести нас на OpenStack. Я самостоятельно разобрался с огромным количеством технологий, мне просто понадобится немного времени, чтобы спокойно сесть и все сделать. Ведь я довольно неплохо знаю OpenStack. Нельзя же и дальше продолжать работать с нашим неподдерживаемым решением, когда есть OpenStack». В общем, они не согласились.
Когда я познакомился с Docker, о нем никто толком не знал. Тогда он был версии 0.7. Я попытался продвигать и его в своей компании, мол, «Смотрите, если не хотите связываться с OpenStack, давайте попробуем Docker. Это новый и интересный проект, бывшие LXC-контейнеры. Мне кажется, это круче, чем OpenVZ, он станет чем-то очень мощным». Но они совершенно не впечатлились.
Я опять принялся изучать все сам. Где-то в апреле прошлого года я основал первый Docker meetup в Италии, в Милане. Мы провели хороший интродакшен этой технологии для людей.
После презентации Docker мне пришло огромное количество вопросов. Например, кто-то спрашивал о CoreOS, и у нас вышла очень клевая дискуссия, мы пошли с этим парнем в паб и болтали там всю ночь напролет.
В том пабе случайно оказался CTO крупного итальянского интернет-провайдера. Мы познакомились, и он сказал, что их компания как раз работает с OpenStack, имплементирует Docker и они были бы очень рады, если бы я пришел к ним работать. Я ответил, что работаю в Mirantis и это игрок № 1 в мире OpenStack.
Это была моя маленькая месть им, так как пару лет назад, когда я зашивался на предыдущей ужасной emergency-работе, я посылал им свое резюме и рассказывал, как я мечтаю делать такой PaaS, но они мне отказали.
Второй раз я отомстил, когда покидал предыдущую «замечательную» компанию и CTO. Я сказал ему, что ухожу. Он спросил, где я теперь буду работать. Сначала я не хотел говорить, так как они могли связаться с Mirantis и наговорить обо мне гадостей, но потом все-таки рассказал. Меня спросили, что такое этот Mirantis. Ярко помню этот момент: мы сидим в переговорной, они открывают браузер и внезапно видят, что Mirantis — топовый игрок в мире OpenStack. Тут до них доходит, что они упустили меня как инженера. Ведь я умолял их разрешить мне попробовать OpenStack, говорил, что сделаю все сам, но они не дали мне такой возможности, сославшись на то, что это дорого и долго, а я не особенно хорош для такой задачи. Что ж, для контрибьютора номер один в мире OpenStack я оказался ДОСТАТОЧНО хорош.
Как известно, даже после того, как ты объявил о своем уходе, ты должен отработать какое-то время, чтобы завершить свои дела в компании. Уже в конце, когда я работал последние дни, мой босс и мой CTO поехали в Германию на какую-то конференцию, где столкнулись с тем самым парнем, CTO крупного интернет-провайдера. Он обрадовался, мол, ребята, я вас знаю! Вы такие модные, прогрессивные, у вас работает такой парень — Фабрицио, он круто рубит в «Докере», сделал хорошую презентацию этой технологии. Наверное, у вас вся компания такая же прогрессивная и модерновая! Вы же используете Docker!
Мои боссы были потрясены, ведь они не верили мне, когда я говорил, что Docker — это круто. Но мной вдруг восхитился крутой уважаемый специалист, и ему они поверили, и поняли, что я был прав, а не предлагал какую-то ерунду.
Вернувшись с конференции, они принялись расспрашивать меня про этот неведомый Docker, про конференцию, которую я проводил, но я уже особо ни на что не отвечал. Они меня обманули: наняли делать одно, а заставили делать другое. Я просто сказал: «Счастливо оставаться» — и ушел.
Работа в Mirantis
На тот момент экономика в Италии пребывала в очень плохом состоянии. Я начал смотреть за рубеж, хотел найти там работу. Я прошел несколько собеседований в Лондоне и мог бы работать на финансовых рынках. Конечно, я попробовал несколько компаний, связанных с Red Hat, ведь там у меня были друзья.
Но в конце концов я просто написал в Mirantis, когда узнал, что они серьезно занимаются OpenStack. Помню, как отправил их HR письмо следующего содержания: «Привет, а вы нанимаете людей? Я хочу работать у вас!» Она ответила, что людей они нанимают, но для работы в московском офисе. «Если хочешь, можем обсудить условия работы, приходи сегодня вечером на Пролетарскую, примерно в 6–7 вечера, пообщаемся», — писала она. Я ответил, что живу в Милане и мне будет довольно проблематично приехать на загадочную «Proletarskaya» сегодня вечером. HR была очень удивлена, но все же назначила мне интервью по Skype.
Конечно, мне показалось, что Skype-интервью я прошел просто ужасно, но меня все-таки приняли на работу. Наверное, все было не так уж и плохо, к тому же у меня на руках уже имелось много предложений, в том числе от Red Hat.
Если честно, тогда меня очень повеселила идея поехать в Россию. Мне показалось, что это будет весьма интересным приключением.
У вас очень дружные разработчики, здесь люди часто общаются и обмениваются опытом. Мы очень быстро замутили первый московский Docker meetup, куда пришло множество людей.
Docker
Помню, как я впервые увидел Docker. Я просто скачал его, запустил, стянул первый попавшийся базовый образ и начал работать. Это было просто потрясающе. Никаких сложностей, все так просто.
Если кратко, «Докер» — это технология, которая позволяет упаковать приложение в изолированный контейнер. Неважно что — веб-сервер, твою программу на Rails или MySQL. C «Докером» можно не устанавливать и не конфигурировать все требуемое ПО на локальной машине, не думать о том, что оно может что-то нарушить на твоей машине или в принципе не взлететь. Стянул контейнер с MySQL, запустил — и он работает.
Простой пример: у тебя на компьютере есть nginx, установленный глобально, ты настроил его, и, кажется, все работает. Но если ты вдруг его сломаешь, тебе придется неслабо потрудиться, чтобы все починить. В лучшем случае ты просто удалишь пакет и поставишь его заново, надеясь, что ничего в системе не останется. С Docker все куда проще: если ты что-то сломал в контейнере с nginx, ты всегда можешь просто убить контейнер и тут же поднять такой же, новый и рабочий. Никакого вреда твоей машине это не нанесет.
Ты можешь спокойно разрабатывать и свои приложения в контейнерах, которые без каких-либо проблем можно полностью перенести на продакшен, и они гарантированно будут работать. Если твое приложение становится более требовательным к памяти, можешь увеличить объем памяти, выделенный для этого контейнера, или, например, воспроизвести аналогичное окружение по докерфайлу на другой машине и связать контейнеры.
Даже обычный разработчик с Docker может задеплоить свое production-ready приложение без каких-либо особых усилий. Или еще проще — взять чей-то готовый образ (если это популярная программа вроде Redis или nginx), который уже собран, и получить промышленное окружение вообще без хлопот.
Прошлые контейнерные технологии требовали довольно серьезного бэкграунда. Ты, конечно, можешь попробовать использовать OpenVZ, попробовать Linux policies, как-то разделять процессы, как-то взаимодействовать с ядром, но это все реально сложно. Это не те задачи, которыми должен заниматься нормальный разработчик.
Программисты хотят работать с простыми вещами, чтобы не приходилось до кучи становиться еще и системными администраторами. Изолированные процессы можно создать и при помощи других решений. К примеру, Jail в BSD-системах. Он был реально интересен для изолирования процессов, но с ним нужно было становиться настоящим kernel hacker.
Помню, мне приходилось работать с Jail в BSD, писать policies, просто чтобы создать «контейнер» (фактически, это был не контейнер, а chroot). Помню, как BSD-парни даже пытались сделать графический интерфейс для работы с Jail, но все равно ты вынужден быть «в ядре», понимать системные вызовы, без этого конфигурация Jail попросту невозможна.
И в качестве альтернативы есть Docker. Ты просто устанавливаешь его, выбираешь образ, запускаешь одну команду — и все, у тебя есть готовое окружение под выбранные задачи. Чувствуешь разницу?
У Docker отличный интерактивный туториал. Можно быстренько ознакомиться с ним, и ты уже готов к работе на базовом уровне. Стянуть контейнер, запушить, что-то поменять, закоммитить, всему этому можно научиться за десять минут. Буквально. Docker действительно очень облегчает жизнь разработчикам.
Вообще, Docker очень любим публикой именно за свою простоту. Недавно для него даже вышел GUI — Kitematic для Mac. С ним начать работу еще проще. У тебя будто App Store под рукой, только с образами приложений. Просто заходишь, читаешь отзывы об образе, если все нравится — скачиваешь его.
Вокруг Docker уже создано огромное количество инструментов и обвязок. Как я уже говорил, например, есть Kitematic для Mac — GUI-интерфейс. Ты можешь работать через него с Docker так же, как и через CLI, только мышкой, как в App Store. Проще некуда. Можешь создавать контейнеры, останавливать, коммитить, как-то настраивать, связывать контейнеры между собой.
Нужен Tomcat? Открываешь Kitematic, выбираешь нужный образ, скачиваешь, и все готово. У тебя готова среда Tomcat для запуска приложений, контейнер, с работающим Tomcat. И это без прикосновений к shell! Ты можешь работать с ним, ходить по SSH.
Конечно, Kitematic предоставляет только базовый инструментарий для работы с Docker, со временем все равно придется изучать Docker CLI. Но для знакомства с возможностями Docker, для базовых операций это очень удобно.
Еще одна важная и клевая штука — Docker hub. Это централизованный репозиторий Docker-образов, который называется Docker hub. Тот самый «App Store», к которому Kitematic и делает GUI. Там ты найдешь огромное количество уже готовых к использованию образов на продакшене. Нужен образ, запускающий Redis? Нужен образ, запускающий Tomcat? Просто ищешь их в Docker hub, запускаешь, и готовы работающие приложения.
В Docker hub представлены образы как от самой команды Docker, так и от энтузиастов. Если тебе нужно какое-то популярное приложение, например MySQL, ты, скорее всего, найдешь тысячи разных образов для него — MySQL 5.1, MySQL 5.2, MySQL 5.1 с таким-то хаком, MySQL 5.1 с другим хаком. Среди них в первых строках, как правило, находится пара «подтвержденных», сертифицированных командой Docker образов. Любое более-менее популярное приложение имеет ряд «заапрувленных» контейнеров, которым ты, скорее всего, можешь доверять.
Очень круто, что в Docker hub существует множество образов для каждого приложения. Скажем, тебе нужно протестировать свое приложение с PHP4? Быстро нашел образ, запустил, протестировал, убил. Нужен PHP5.3 с определенным хаком? Схема та же. Не нужно пытаться ставить и управлять всем этим локально. Хотя, разумеется, стоит учитывать, что такие образы не гарантируют безопасности и правильной конфигурации, — они созданы энтузиастами. Не нужно использовать эти образы на продакшене, они предназначены для тестов.
Еще одно преимущество Docker в том, что он конфигурируется докерфайлами. Докерфайл — это что-то типа makefile, только вместо инструкций для сборки он содержит инструкции для конфигурирования контейнеров. Просто пишешь докерфайл, и Docker по нему создает и настраивает контейнер. Будь уверен, если контейнер нормально создается локально, он нормально заработает и на продакшене.
Докерфайл позволяет разработчику создать повторяемое окружение (по своему сценарию). Ты можешь заскриптовать создание CentOS-контейнера, разворачивание nginx и так далее. С докерфайлом очень просто собирать разные приложения и окружения, не третируя при этом свой компьютер и ОС.
Возьмем, к примеру, PHP. Тебе понадобилось протестировать что-то на PHP 5.2, 5.3, 5.4. Как осуществить это без контейнеров? Это невозможно даже на сервере. Ну по крайней мере, довольно сложно. Помню, как мне в Red Hat для таких целей приходилось создавать package groups для каждой версии PHP. Все это заставляло меня компилировать кучу кода, линковать его в /opt, заботиться о совместимости и так далее. Было ужасно. С Docker все легче — просто установи контейнеры 5.2, 5.3 и 5.4 и работай с тем, который нужен сейчас.
Часто используют так: скажем, у тебя есть два домена-сайта, одному из которых нужен PHP 5, другому — PHP 4. Просто ставишь какой-то reverse proxy, вроде nginx, перед ними и по домену перенаправляешь запрос в тот или иной контейнер, через другой порт.
К тому же Docker очень эффективен. На среднем ноутбуке можно запускать тысячи контейнеров, со всеми необходимыми версиями всех приложений, без особого ущерба производительности. Разработчики, которые используют Vagrant или какую-то другую виртуалку, не смогут повторить этот трюк. Я не могу представить себе ноутбук, способный потянуть тысячу виртуальных машин, но тысячу Docker-контейнеров — легко. Docker эффективнее виртуальных машин, как на серверах, так и на десктопах.
В сравнении с Vagrant, Docker — это скорость. Vagrant стартует несколько секунд, а Docker стартует мгновенно. С Vagrant придется залезать в конфиги, что-то настраивать. Например, если ты хочешь расшарить директорию между хостом и гостевой машиной, тебе нужно конфигурировать SAMBA или NFS. Все довольно сложно. С Docker ты можешь одной командой монтировать директорию на хосте внутри контейнера, и все, это работает. ~/home/dev/app будет /var/www внутри твоего контейнера.
Лично для меня самой потрясающей частью Docker стало создание контейнеров через так называемые слои. Ты можешь коммитить эти слои поверх других слоев. Например, тебе нужен контейнер с твоим приложением на Node.js. Ты обсуждаешь с разработчиками, какую OS выбрать. Скажем, вы решаете в пользу Ubuntu. Скачиваешь базовый контейнер с Ubuntu, затем настраиваешь nginx, Node.js и все, что тебе нужно. Затем коммитишь то, что сделал, следующим слоем поверх первого. Потом можешь создать третий уровень, а на нем запустить Redis или что-то иное. Это все работает на UnionFS, именно благодаря ей ты можешь коммитить контейнеры один поверх другого. То есть, если тебе нужно запустить две версии MySQL на одном уровне, одновременно, ты можешь это сделать, и они будут делить тот слой, который под ними (например, ОС).
Есть несколько альтернатив Docker. Это Atomic от Red Hat и CoreOS (которые недавно начали пилить свой Docker — Rocket). Также недавно появился совсем новый проект rancherOS (rancher.com/rancher-os/). Все они пока в стадии альфа, Docker — самый зрелый. Вся индустрия сегодня движется в сторону контейнеров, ведь контейнеры важны именно для индустриальных нужд.
Сейчас Docker привлекает огромное количество крупных компаний, вроде Mirantis и Rackspace. Не удивлюсь, если когда-нибудь Red Hat купит Docker. Docker заинтересовал огромное количество closed source компаний, вроде Microsoft или Amazon, даже они заинтересованы в нем и стараются использовать у себя. Все эти компании стараются заставить Docker работать как можно лучше на своих платформах, потому что понимают: скоро Docker станет de-facto стандартом запуска приложений на сервере. От того, будет ли платформа компании поддерживать Docker, зависит, будут ли люди пользоваться этой платформой.
