www.samag.ru
     
Поиск  
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Сетевой агент
О журнале
Журнал «БИТ»
Информация для ВАК
Звезды «СА»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Мероприятия
Форум
Опросы
Ищу/Предлагаю работу
Спроси юриста
Игры
Контакты
   
Слайд шоу  
Представляем работы Виктора Чумачева
Виктор Чумачев – известный московский художник, который сотрудничает с «Системным администратором» уже несколько лет. Именно его забавные и воздушные, как ИТ, иллюстрации украшают многие серьезные статьи в журнале. Работы Виктора Чумачева хорошо знакомы читателям в России («Комсомольская правда», «Известия», «Московские новости», Коммерсант и др.) и за рубежом (США, Германия). Каждый раз, получая новый рисунок Виктора, мы в редакции улыбаемся. А улыбка, как известно, смягчает душу. Поэтому смотрите на его рисунки – и пусть у вас будет хорошее настроение!

  Опросы
Дискуссии  
17.09.2014г.
Просмотров: 14734
Комментарии: 3
Красть или не красть? О пиратском ПО как о российском феномене

Тема контрафактного ПО и защиты авторских прав сегодня актуальна как никогда. Мы представляем ...

 Читать далее...

03.03.2014г.
Просмотров: 18733
Комментарии: 1
Жизнь под дамокловым мечом

Политические события как катализатор возникновения уязвимости Законодательная инициатива Государственной Думы и силовых структур, ...

 Читать далее...

23.01.2014г.
Просмотров: 26759
Комментарии: 3
ИТ-специалист будущего. Кто он?

Так уж устроен человек, что взгляд его обращен чаще всего в Будущее, ...

 Читать далее...

1001 и 1 книга  
16.02.2017г.
Просмотров: 3895
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 6769
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 8863
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 10486
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 7306
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Дмитрий Шурупов: «Open Source – это непосредственное участие в проектах, которые несут прямую пользу всему человечеству»

Архив номеров / 2017 / Выпуск №7-8 (176-177) / Дмитрий Шурупов: «Open Source – это непосредственное участие в проектах, которые несут прямую пользу всему человечеству»

Рубрика: Разработка /  DevOps

Дмитрий Шурупов:
«Open Source – это непосредственное участие в проектах, которые несут прямую пользу всему человечеству»

В гостях у «Системного администратора» – Дмитрий Шурупов, соучредитель компании «Флант», энтузиаст свободного программного обеспечения

– Расскажите, чем занимается компания «Флант»?

Дмитрий Шурупов
Дмитрий Шурупов, энтузиаст свободного программного обеспечения. В 2001-м запустил посвященный этой теме веб-сайт nixp.ru, для которого по сегодняшний день пишет новости. За год до окончания института (МИЭМ, ныне входит всостав НИУ ВШЭ) основал компанию TrueOffice, которая с 2011 года известна как «Флант». В 2005-2013 годах был главным редактором электронного приложения «Open Source» к журналу «Системный администратор». В 2008-2011 годах преподавал «Базы данных» на своей кафедре в МИЭМ, а в 2011-м и 2012-м был организатором нескольких offline-мероприятий по Linux и свободному ПО в Москве

– Начну с истории, которая поможет лучше понять текущий статус и то, как мы к нему пришли. На момент основания компании, в 2008 году, вместе с Дмитрием Столяровым мы позиционировали себя как специалистов, которые работают со свободным программным обеспечением в любых его проявлениях и могут решить практически любую задачу под GNU/Linux. Так получилось ввиду нашего очевидного молодого энтузиазма и по той причине, что сама компания была создана на базе кафедры информационно-коммуникационных технологий как попытка перенести в корпоративный сектор те наработки, что мы успешно создали, внедрили и обслуживали сначала в рамках кафедры, а затем – всего вуза. С разной долей успеха это были инфраструктурные и прикладные решения, такие как Linux-роутеры, единый каталог пользователей, файловые хранилища, электронная почта, веб-приложения… Мы доросли до состояния, когда поняли, что многое из этого может пригодиться не только отдельно взятому вузу, но и компаниям. И занялись их адаптацией под корпоративные потребности с последующим внедрением и обслуживанием, периодически вовлекаясь в более отвлеченные проекты вроде рабочих станций, системной интеграции на базе мобильных устройств и т.п.

Набравшись опыта, мы увидели, что сложно охватить необъятное, особенно небольшим коллективом, каким на тот момент была наша компания. (Кстати, тогда еще она называлась «ТруОфис», что со временем привело к непредвиденному курьезу. Далекие от мира ИТ люди видели в нашем названии не англоязычное «true», а подрядчика по уборке.) Мы решили сосредоточиться на четырех основных направлениях: веб-приложения, сети, телефония, десктопы (типовые специализированные рабочие места на базе Linux).

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

И тогда все карты сошлись: мы решили полностью сосредоточиться на одном направлении – обслуживании веб-приложений. Мир технологий к этому моменту окончательно закрепился в области микросервисной архитектуры, приложений cloud-native и практик DevOps, так что мы с удовольствием последовали за трендом, адаптируя свой богатый опыт по веб-инфраструктуре (и не только веб) под имеющиеся потребности.

Итогом этих перипетий стало то, что на сегодняшний день мы предлагаем своим заказчикам выделенную DevOps-команду. Наш типовой клиент – это компания, бизнес которой напрямую зависит от качественного функционирования веб-приложения(й) и разработчики которой (могут быть в штате или другими подрядчиками) нуждаются в налаживании и автоматизации всех процессов, сопровождающих их работу по написанию и тестированию кода. Речь идет про процессы CI/CD: непрерывная интеграция (Continuous Integration), выкатка новых релизов (Continuous Deployment), доставка приложений (Continuous Delivery).

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

– Что для вас «работа по принципам DevOps»?

DevOps– Как и следует из самого определения, DevOps для нас – это в первую очередь взаимодействие всех сторон, принимающих участие в создании и запуске приложений: разработчиков и тестировщиков, инженеров по эксплуатации, менеджеров. Мы и раньше не были сторонниками выполнения тикетов заказчика без понимания конечных преследуемых целей, поскольку зачастую это приводило к неприятным для всех последствиям. Но теперь благодаря появившимся техническим средствам (онлайн-чаты и видеоконференции) и изменившимся подходам к разработке вообще (массовое принятие гибкой методологии) такое взаимодействие стало гораздо более необходимым, естественным и динамичным. В типовом pipeline при создании каждого релиза приложения у нас задействованы команды разработчиков, тестировщиков и DevOps-инженеров, релиз-инженер, а также менеджеры (со стороны заказчика и с нашей стороны) – всем им нужно взаимодействовать (будь то простые переговоры или последовательная реакция на определенные «технические» события), чтобы добиваться общего результата.

Гибкая методология разработки (agile), ставшая в той или иной мере нормой (как правило, не в чистом виде, а в различных комбинациях с другими подходами) для многих команд веб-разработчиков, подразумевает релизы, которые делаются часто и в большом количестве. Очевидно, что делать это вручную больше невозможно: необходимы механизмы, позволяющие разработчикам не беспокоиться о дальнейшем цикле жизни их кода, – так появились уже упомянутые процессы CI/CD, реализацией которых занимаются DevOps-инженеры, переставшие быть «классическими» системными администраторами в тот момент, когда начали тесно контактировать с другой стороной процессов (разработчиками) опять же для достижения общих целей.

Другой важный фактор: время, когда серверы обслуживались путем захода на них и ручной правки конфигурационных файлов, проходит – по крайней мере для сложной, динамичной и масштабируемой инфраструктуры. Администраторы становятся разработчиками – они пишут код для инфраструктуры, на которой будет запускаться приложение (а не самого приложения). Этот подход называется Infrastructure as Code (IaC), и он стал неотъемлемой частью DevOps, поскольку делает инфраструктуру по-настоящему гибкой, понятной и удобной в обслуживании, масштабируемой.

Подобным образом с DevOps связана и микросервисная архитектура, позволяющая разработчикам создавать отдельные компоненты системы в разных командах, интегрировать их в единое приложение и обслуживать на всех этапах (от частого развертывания новых релизов до масштабирования в production). Это одна из главных причин, по которой на «сцену» веб-инфраструктуры вышли и быстро завоевали популярность контейнеры и сопутствующие технологии.

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

– Какую программную платформу вы сделали базовой?

– Во всем своем стеке мы используем только свободное программное обеспечение. Базовой платформой можно назвать два продукта:

  • Docker – как контейнерная система, позволяющая упаковывать микросервисы (или целые приложения) в удобный для дальнейшего обслуживания вид;
  • Kubernetes – как нижележащая PaaS-подобная система для управления контейнерами, обеспечивающая для них связность, масштабирование и ряд других функций.

Почему 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, который мы реализуем, выглядит так (стадии перечислены по порядку):

  • При коммите разработчиков осуществляется сборка приложения с помощью нашей Open Source-утилиты dapp (https://github.com/flant/dapp), а полученный Docker-образ помещается в реестр Docker Registry.
  • Разворачивается созданный образ и на нем выполняются автоматические тесты.
  • Релиз разворачивается в тестовом окружении (staging) для разработчиков, тестировщиков, DevOps-инженеров.
  • Релиз разворачивается в предварительном production для тестировщиков.
  • Стадия-«предохранитель» (approve), в которой релиз-инженер принимает решение о выкате на production.
  • Релиз разворачивается на production.

Если говорить о полном цикле 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 (что, к слову, будет невозможно без выделения на то ресурсов, на которые тоже надо заработать). И я рад, что «Флант» – один из примеров такого баланса.

Возвращаясь к вопросу:

  • Open Source – это непосредственное участие в проектах, которые несут прямую пользу всему человечеству.
  • Open Source – это действительная возможность не только досконально знать, как все работает на любом уровне стека, но и вносить изменения/улучшения в это поведение. Многие считают подобные заявления лишь красивой отговоркой без практического применения: ведь мало кто будет разбираться в коде известных проектов (особенно крупных) и еще меньше способны внести какие-либо изменения (не говоря уж про их включение в upstream). Но для нас это действительно так (пример для GitLab – https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6201), а «доскональное знание» делает более реалистичной ответственность перед заказчиками по SLA.
  • Использование Open Source-компонентов для инфраструктуры гарантирует независимость от поставщика, что является серьезным аргументом при переговорах с потенциальным заказчиком о перспективах обслуживания.
  • Не будет преувеличением сказать, что сама индустрия уже выбрала многочисленные Open Source-проекты как фундамент для реализации процессов CI/CD (конечно, если речь идет о решениях категории self-hosted). Не соглашаться с таким выбором – это либо создавать собственные продукты, что требует огромных инвестиций, либо уходить к менее популярным коммерческим решениям, ступая на зыбкую почву зависимости от одного разработчика.

– Какое программное обеспечение используете в своей работе (ОС, почтовый клиент, браузер, среды разработки и т.п.)?

– Наши корпоративные стандарты таковы:

  • ОС – Ubuntu Linux (и на рабочих ноутбуках сотрудников, и на обслуживаемых серверах).
  • Почтовый клиент – несколько лет назад мы отказались от собственной почтовой системы в пользу GMail (это было непростое решение и не очень приятное по нескольким причинам, однако с точки зрения бизнеса оно себя полностью оправдало).
  • Веб-браузер – Chromium или Chrome (по идейным соображениям я сам предпочитаю Mozilla Firefox, но иногда тоже вынужден пользоваться продуктами Google).
  • По средам разработки строгих стандартов нет – тут все зависит от предпочтений инженеров/разработчиков, поэтому встречаются классический vim, модный Atom, проприетарный RubyMine и даже открытый Visual Studio Code от Microsoft.
  • Работа с документами – Google Docs и LibreOffice.

– Принимаете ли участие в конференциях, встречах и т.п.? В каких ближайших мероприятиях планируете принять участие?

– С 2015 года мы регулярно принимаем участие в конференциях Олега Бунина: HighLoad++ и РИТ++ (здесь нас больше всего интересует RootConf). Эти мероприятия отлично зарекомендовали себя как выход и на тематическое сообщество, с которым мы делимся своим опытом, и на потенциальных клиентов. Планируем выступать на них и участвовать как спонсоры в дальнейшем.

Cтенд компании «Флант» на фестивале РИТ++ 2017

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-проектов, нашла во мне глубокий отклик и уважение.

Подготовил Игорь Штомпель


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru