 |
|
|
|
Дмитрий Шурупов: «Open Source – это непосредственное участие в проектах, которые несут прямую пользу всему человечеству»
Дмитрий Шурупов: В гостях у «Системного администратора» – Дмитрий Шурупов, соучредитель компании «Флант», энтузиаст свободного программного обеспечения – Расскажите, чем занимается компания «Флант»?
– Начну с истории, которая поможет лучше понять текущий статус и то, как мы к нему пришли. На момент основания компании, в 2008 году, вместе с Дмитрием Столяровым мы позиционировали себя как специалистов, которые работают со свободным программным обеспечением в любых его проявлениях и могут решить практически любую задачу под GNU/Linux. Так получилось ввиду нашего очевидного молодого энтузиазма и по той причине, что сама компания была создана на базе кафедры информационно-коммуникационных технологий как попытка перенести в корпоративный сектор те наработки, что мы успешно создали, внедрили и обслуживали сначала в рамках кафедры, а затем – всего вуза. С разной долей успеха это были инфраструктурные и прикладные решения, такие как Linux-роутеры, единый каталог пользователей, файловые хранилища, электронная почта, веб-приложения… Мы доросли до состояния, когда поняли, что многое из этого может пригодиться не только отдельно взятому вузу, но и компаниям. И занялись их адаптацией под корпоративные потребности с последующим внедрением и обслуживанием, периодически вовлекаясь в более отвлеченные проекты вроде рабочих станций, системной интеграции на базе мобильных устройств и т.п. Набравшись опыта, мы увидели, что сложно охватить необъятное, особенно небольшим коллективом, каким на тот момент была наша компания. (Кстати, тогда еще она называлась «ТруОфис», что со временем привело к непредвиденному курьезу. Далекие от мира ИТ люди видели в нашем названии не англоязычное «true», а подрядчика по уборке.) Мы решили сосредоточиться на четырех основных направлениях: веб-приложения, сети, телефония, десктопы (типовые специализированные рабочие места на базе Linux). Прошла еще пара лет, которая позволила нам убедиться окончательно: даже такая специализация недостаточна. К тому же подавляющее большинство наших клиентов – это веб, наша наиболее полная экспертиза – это веб, да и наш реальный интерес как людей, сохраняющих свой технический энтузиазм (несмотря на все бюрократические и организационно-бюрократические сложности, связанные с ведением бизнеса), лежит в той же области. И тогда все карты сошлись: мы решили полностью сосредоточиться на одном направлении – обслуживании веб-приложений. Мир технологий к этому моменту окончательно закрепился в области микросервисной архитектуры, приложений cloud-native и практик DevOps, так что мы с удовольствием последовали за трендом, адаптируя свой богатый опыт по веб-инфраструктуре (и не только веб) под имеющиеся потребности. Итогом этих перипетий стало то, что на сегодняшний день мы предлагаем своим заказчикам выделенную DevOps-команду. Наш типовой клиент – это компания, бизнес которой напрямую зависит от качественного функционирования веб-приложения(й) и разработчики которой (могут быть в штате или другими подрядчиками) нуждаются в налаживании и автоматизации всех процессов, сопровождающих их работу по написанию и тестированию кода. Речь идет про процессы CI/CD: непрерывная интеграция (Continuous Integration), выкатка новых релизов (Continuous Deployment), доставка приложений (Continuous Delivery). Чтобы воплотить эти подходы в жизнь, требуется широкая экспертиза и круглосуточная поддержка, то есть нужен попросту целый ИТ-отдел, а не каждая компания может себе это позволить, и не всегда это будет экономически рационально. – Что для вас «работа по принципам DevOps»?
Гибкая методология разработки (agile), ставшая в той или иной мере нормой (как правило, не в чистом виде, а в различных комбинациях с другими подходами) для многих команд веб-разработчиков, подразумевает релизы, которые делаются часто и в большом количестве. Очевидно, что делать это вручную больше невозможно: необходимы механизмы, позволяющие разработчикам не беспокоиться о дальнейшем цикле жизни их кода, – так появились уже упомянутые процессы CI/CD, реализацией которых занимаются DevOps-инженеры, переставшие быть «классическими» системными администраторами в тот момент, когда начали тесно контактировать с другой стороной процессов (разработчиками) опять же для достижения общих целей. Другой важный фактор: время, когда серверы обслуживались путем захода на них и ручной правки конфигурационных файлов, проходит – по крайней мере для сложной, динамичной и масштабируемой инфраструктуры. Администраторы становятся разработчиками – они пишут код для инфраструктуры, на которой будет запускаться приложение (а не самого приложения). Этот подход называется Infrastructure as Code (IaC), и он стал неотъемлемой частью DevOps, поскольку делает инфраструктуру по-настоящему гибкой, понятной и удобной в обслуживании, масштабируемой. Подобным образом с DevOps связана и микросервисная архитектура, позволяющая разработчикам создавать отдельные компоненты системы в разных командах, интегрировать их в единое приложение и обслуживать на всех этапах (от частого развертывания новых релизов до масштабирования в production). Это одна из главных причин, по которой на «сцену» веб-инфраструктуры вышли и быстро завоевали популярность контейнеры и сопутствующие технологии. Тот факт, что с самого начала (еще до основания компании) мы в той или иной мере занимались разработкой, сегодня привел к тому, что у нас есть небольшой отдел разработки, решающий наши задачи: создающий веб-приложения для обеспечения наших внутренних процессов и некоторые инструменты для DevOps-инженеров. Это помогает нам смотреть на возможные в сопровождении проблемы не только со стороны нашей главной специализации – эксплуатации, – но ис пониманием позиции разработчиков. – Какую программную платформу вы сделали базовой? – Во всем своем стеке мы используем только свободное программное обеспечение. Базовой платформой можно назвать два продукта:
Почему Kubernetes – PaaS-подобная система? Фактически это «конструктор», самый настоящий фреймворк, т.е. в буквальном смысле «каркас», позволяющий собирать свою PaaS с любыми компонентами, реализующими конкретные функции. Например, предоставлять исполняемую среду для контейнеров вовсе не обязательно будет Docker (как в случае Docker Swarm), а в долгосрочной перспективе это действительно важно. Зависеть от какого-либо облачного провайдера – конкретной реализации PaaS (вроде AWS от Amazon или GKE от Google) – мы тоже не можем, поскольку хотим оставить заказчику право сделать этот выбор самостоятельно (либо вообще использовать свое/арендуемое железо). Поэтому мы выбрали Kubernetes – гибкое и изящное решение, не ограничивающее в выборе, а предоставляющее его. Дополнительными факторами стали предлагаемые уже сегодня широкие возможности (и активное развитие новых), достаточная стабильность и использование более близкого нам технологического стека (язык Go против Scala/Java в случае Marathon из Apache Mesos). Свою роль сыграла и независимость от интересов одного конкретного разработчика – в противовес таким дистрибутивам на базе Kubernetes, как OpenShift (Red Hat) и Tectonic (CoreOS). За миром контейнеров в разных их проявлениях (от FreeBSD jails и OpenSolaris zones до OpenVZ, LXC, пространств имен в ядре Linux) мы следили очень давно. Когда дело дошло до их конкретного применения для новых задач, выбор Docker был во многом обусловлен его удобством и возможностями, а также ранним распространением и популярностью. Конечно, это вовсе не означает, что решение является или остается лучшим. Однако, даже несмотря на многочисленные проблемы этого проекта, переживающего очень активный рост (в интернете можно найти немало дискуссий о них), мы продолжаем руководствоваться собственным опытом. За несколько лет эксплуатации контейнеров Docker в production мы убедились в его достаточной зрелости, что позволяет нам даже не рассматривать альтернативные проекты на предмет возможной замены в ближайшее время. Дополнительного оптимизма добавляют последние инициативы Docker Inc по выделению из Docker ключевых компонентов (runC, containerd) и их передачи в независимый фонд (Cloud Native Computing Foundation). Наконец, уже упомянутая архитектурная гибкость Kubernetes всегда гарантирует возможность замены одних продуктов на другие в случае возникновения необходимости. – Какое решение используется для работы с исходными кодами? – Единственная система контроля версий, с которой мы действительно работаем, – это Git. Я уже не вспомню, когда к нам в последний раз в принципе обращались заказчики с другой потребностью. Git стал таким глобальным стандартом, что даже для разработки Windows в Microsoft используют и улучшают возможности Git (https://www.nixp.ru/news/14046.html). Отсюда логично следует, что для self-hosted мы по умолчанию предлагаем GitLab, а также открыты для интеграции с внешними сервисами наподобие GitHub (самый популярный случай), если заказчик по каким-то причинам предпочитает такой вариант. – Программное обеспечение для автоматизации непрерывной интеграции? Почему остановили выбор на нем? – Здесь наш стандарт вытекает из предыдущего вопроса – для непрерывной интеграции мы предпочитаем GitLab CI, возможностей которого – конечно, после определенных усилий – оказалось достаточно для реализации имеющихся потребностей в CI/CD. Как и в случае со многими другими решениями в описываемом мною типовом стеке, приведенный здесь ответ не означает, что мы не готовы работать с альтернативными продуктами и что у нас нет опыта по ним (в данном случае – Travis CI, Jenkins). Но, следуя опыту, полученному за годы работы, мы стремимся к унификации везде, где это возможно. – Не могли бы привести пример того, как выстраиваете и сопровождаете на практике CI/CD? – Типовой pipeline для CI/CD, который мы реализуем, выглядит так (стадии перечислены по порядку):
Если говорить о полном цикле Continuous Delivery, то заключительным этапом является эксплуатация – вплоть до «снятия» релиза с production (замены его на другой релиз). Главная роль в эксплуатации у нас отводится Kubernetes. Использование этой системы закрывает такие вопросы, как сбор логов и метрик, supervision (проверка состояния сервисов и их перезапуск) и масштабирование. – В чем особенности применения подхода IaC в компании «Флант»? – Подход IaC мы начали практиковать еще до погружения в DevOps – и для управления конфигурациями серверов, и для удобного обслуживания однотипных десктопов. Тогда нами был сделан выбор в пользу Chef как наиболее продвинутого и подходящего для наших задач инструмента. Поэтому вряд ли вас удивит, что при создании уже упомянутого инструмента dapp для сборки Docker-образов в рамках реализации CI/CD мы обеспечили его поддержкой Chef. Суть этой поддержки заключается в возможности выполнять рецепты для Chef внутри создаваемого Docker-образа. Технически это организовано таким образом, что в конечном образе, который разворачивается на последующих стадиях нашего pipeline, не остается никаких следов от Chef (ни chefdk, настраивающего контейнер по cookbook, ни самого cookbook). Когда мы начали переход на Kubernetes, код инфраструктуры стал содержать и настройки для этой системы, потому что теперь разворачиваются не только контейнеры, но и вся инфраструктура для них (управляемая Kubernetes). Для этого на стадии релиза приложения сначала считывается и применяется YAML-конфигурация для Kubernetes, а уже после этого выкатываются образы в созданную инфраструктуру. Изначально мы использовали для этих задач Helm, но сейчас реализуем все необходимое в своей утилите dapp. На данный момент мы задумываемся о возможном переходе с Chef на Ansible, поскольку эта система не только проще и по-прежнему удовлетворяет нашим актуальным потребностям, но и гораздо более популярна среди специалистов, которых мы находим на рынке труда. – В чем преимущество Open Source при использовании методологии DevOps? – Пусть кому-то этот взгляд может показаться фанатичным, но с самого начала моего пути в мире Linux и Open Source ключевой составляющей для меня была не практическая польза, а стоящая за этим идеология свободы и пользы для всего человечества. Зарабатывать можно практически на чем угодно, и мои наблюдения показывают, что делать это на «вредных» вещах, как правило, намного проще. Но вот стоит ли тратить на это свою жизнь – такой философский вопрос для меня действительно первичен. Не нужно воспринимать его как крайность. Даже если бизнес по определению не приемлет сплошную благотворительность (потому что нуждается в коммерческой выгоде), можно найти баланс. Баланс в том, чтобы зарабатывать достаточно и одновременно с этим приносить пользу1 (что, к слову, будет невозможно без выделения на то ресурсов, на которые тоже надо заработать). И я рад, что «Флант» – один из примеров такого баланса. Возвращаясь к вопросу:
– Какое программное обеспечение используете в своей работе (ОС, почтовый клиент, браузер, среды разработки и т.п.)? – Наши корпоративные стандарты таковы:
– Принимаете ли участие в конференциях, встречах и т.п.? В каких ближайших мероприятиях планируете принять участие? – С 2015 года мы регулярно принимаем участие в конференциях Олега Бунина: HighLoad++ и РИТ++ (здесь нас больше всего интересует RootConf). Эти мероприятия отлично зарекомендовали себя как выход и на тематическое сообщество, с которым мы делимся своим опытом, и на потенциальных клиентов. Планируем выступать на них и участвовать как спонсоры в дальнейшем.
Cтенд компании «Флант» на фестивале РИТ++ 2017 Еще мы обращаем внимание на проводящиеся иногда встречи (meetups) русскоязычных сообществ Docker и Kubernetes, но реальное наше участие в них (с докладом) случилось пока лишь однажды. Собираемся проявлять в них активность по мере возможностей. Напоследок хотел бы добавить, что с этого года мы регулярно и достаточно много пишем о том, как применяем на практике различные DevOps-инструменты, решаем те или иные проблемы, а также делаем обзоры связанных с нашей специализацией технологий (Docker, Kubernetes, CoreOS, проекты CNCF и др.) в своем блоге на Хабрахабре (https://habrahabr.ru/company/flant). Зная, насколько трудно бывает найти доступные и полезные материалы по теме DevOps на русском языке, мы стремимся восполнить этот пробел. 1. В этом смысле недавно анонсированная инициатива GitHub под названием Open Source Friday (http://opensourcefriday.com), в рамках которой компаниям со всего мира предлагается выделять по два часа в неделю на развитие наиболее используемых/любимых Open Source-проектов, нашла во мне глубокий отклик и уважение. Подготовил Игорь Штомпель |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
