Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Аннотация

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

Веб-роботы, которые собирают информацию в сети интернет называют «веб-краулерами» или просто «краулерами», данные роботы представляют собой приложения, как правило написанные на языках программирования Python или Java. Они обладают разными свойствами и выполняют схожие, но все-таки разные функции.

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

За основу инфраструктуры взята технология Docker Swarm, краулеры, использованный в данной системе были написаны на языках Python и Java.

Данная работа содержит 3 главы, введение и заключение, 21 иллюстраций, а также библиографический список из 25 источников.



Annotation

The aim of this final qualifying paper is to solve the problem of automating the process of managing a data collection system from open sources. The purpose of this final qualifying paper is to simplify the management of the data collection system, which is several heterogeneous web-robots, as well as the creation of a common infrastructure to control these robots.

Web-robots that collect information on the Internet are called “web-crawlers” or simply “crawlers”; these robots are applications that are usually written in the programming languages Python or Java. Crawlers have different properties and perform similar yet different functions.

One of the ways to create a common system for managing heterogeneous crawlers is containerization technology. This technology allows you to place applications in containers, which are very small copies of the operating systems on which applications will run.

The infrastructure is based on Docker Swarm technology, the crawlers used in the system were written in Python and Java.

This work contains 3chapters, introduction and conclusion. Number of illustration - 21. Number of sources used - 25.



Введение

контейнеризация сбор данные краулер

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

В данной работе производится анализ основных видов ПО типа «краулер», специализированных программ, цель которых - сканирование веб-ресурсов для последующего сохранения сведений об этих ресурсах в своей базе данных.

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

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

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

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



1. Аналитическая часть

1.1 Анализ ПО типа «краулер»

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

Ниже, на изображении 1, представлена SADT модель любого вида краулеров.

Рис. 1 - SADT модель краулеров

В основном управляются краулеры с помощью Jenkins. Механизмами выполнения функций краулера являются разнообразные среды для сканирования и индексации веб-страниц.

Как правило, когда говорят про сбор информации в сети, имеют в виду одно из двух понятий: data scraping и data crawling. Очень важно понимать разницу между этими двумя понятиями, основные различия представлены в таблице 1.

В целом следует понимать, что Data Scraping может в целом не относиться к сети интернет. Иногда подразумевается даже банальное извлечение информации из обычного компьютера, из базы данных или даже простая кнопка «сохранить как» при сборе информации из сети интернет.

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

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

Таблица 1. - Data Crawling и Data Scraping

Data Crawling	Data Scraping
Относится к скачиванию страниц и интернета	Включает в себя получения информации из различных источников, включая интернет
Преимущественно используется в работе с большими объемами данных	Используется в работе с любыми объемами данных
Дедупликация информации является важной частью	Дедупликация не важна
Нужен только краулер	Нужны краулер и парсер

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

В таблице выше было упомянуто такое понятие, как парсер. По сути это просто синтаксический анализ. Парсер используется в целом для обработки информации с последующим преображением в структурированный формат. Как правило парсеры обрабатывают в основном текстовую информацию.

Парсинг является важной частью Data Scraping, так как именно эта часть отвечает за то, какая информация будет получена с веб-страниц.

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

· Интернет магазины. Так как в интернет магазинах вся информация является типовой, вроде цены, модели или определенных спецификаций, то вывод сведений не требует особо сложных функций обработки данных.

· Объявления. Как правило продажа недвижимости, автомобилей, бывших в употреблении или перепродажа в других сферах не сильно отличается от того же интернет магазина.

· Копирование контента. Довольно часто происходит так, что сайты заполняются не оригинальным контентом, а пришедшим с других сайтов.

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

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

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

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

Стандартная архитектура для любого веб-краулера включает в себя планировщик, в чью работу входит прием веб-страниц от краулера, оценка приоритетности информации и составление дальнейшего плана действий для краулера, то есть какую информацию необходим собирать в первую очередь. На рисунке 2 можно увидеть стандартную схему веб-краулера.



Рис. 2 - Архитектура веб-краулера. [19]

У краулеров существуют определенные параметры, которые можно настроить в их коде. Как правило, среди этих параметров обычно присутствуют довольно распространенные.

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

Есть возможность в краулере описать больше одной стартовой страницы, в таком случае будет больший обхват, но и краулер не уйдет далеко от темы.

Для краулеров описываются специальные циклы, чтобы одни и те же веб-страницы не скачивались более одного раза.

Также для сайтов существуют специальные условия использования, краулеры в принципе могут выполнять действия, описанные там:

1. Выполнение JavaScript;

2. Обработка URL параметров;

3. Нажатие кнопок на страницах;

4. Заполнение специальных форм;

5. Различие сайтов с «www» и без, если отсутствует переадресация.

Есть еще определенные важный моменты, которые стоит упомянуть:

· Планировщики краулеров сортируют веб-страницы по определенному рейтингу и далее передают страницы краулеру, основываясь на составленном рейтинге.

· Как правило, рейтинги определяются множеством факторов, но основным является количество ссылок на веб-страницу.

· Зачастую существует минимальный рейтинг страницы, так что веб-страница с рейтингом ниже минимального может очень долгое время висеть в планировщике.

· Рейтинг не является постоянным, он может меняться в обе стороны время от времени.

Многие крупные компании, типа Google, для того, чтобы в их индексе краулеров оставались актуальные веб-страницы, придерживаются нескольких правил.

1. Краулинг должен проводиться как можно дальше по ссылкам, грубо говоря «глубже».

2. Индексация должна проводиться по возможности чаще.

3. Все ссылки на новые страницы необходимо находить как можно быстрее.

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

· Живой индекс для хранения «живых» страниц.

· Индекс недавних страниц для хранения «живых», а также удаленных за какой-то определенный промежуток времени.

· Исторический индекс для хранения всех когда-либо проиндексированных страниц.

Как правило, индекс недавних страниц самый надежный для использования. Множество причин, по которым веб-страницы были удалены из живого индекса можно считать обратимыми. Как правило «ошибочные» причины удаления из живого индекса бывают тривиальными:

· Банальная ошибка 404, по которой искомая веб-страница может быть временно недоступной.

· Страница может быть изменена на перенаправление на другую веб-страницу.

· Сайт может внести страницу в список noindex, что запретит роботам проводить индексацию данного фрагмента.

· Страница может перестать быть каноничной, либо удаляется из-за низкого рейтинга.

Для ссылок тоже могут быть свои проблемы:

· Ссылка была случайно удалена.

· Ссылка использовала перенаправление, которое сломалось.

Конечно же, бывают случаи, когда создателей краулеров не устраивают разрешения, выдаваемые сайтами в robots.txt. Для примера, создатель захочет получить информацию о десятке тысяч страниц на определенном сайте, для каждой информации минимум потребуется:

1. Открыть одну из искомых страниц и считать основные сведения.

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

3. В случае разделения подраздела на страницы, пройти каждую из них.

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

Как раз для таких причин многие краулеры маскируются под реальных пользователей, в качестве попытки обмануть систему. Соответственно такой краулер представится как браузер вроде Firefox, Chrome или другого. Как правило владельцы сайтов пытаются бороться с этим различными способами, но зачастую краулерам удается обмануть защиту сайтов.

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

Есть и более распространенная мера защиты - запрет на очень быстрые переходы по сайту. По сути, есть возможность, что система не поверит в то, что пользователь может так часто переходить со страницы на страницу. Как правило такой запрет обходится простым выставлением задержки на переходы.

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

1.2 Виды краулеров

Краулеры можно в целом разбить на пять групп:

1. Focused Web Crawler - сфокусированный краулер;

2. Incremental Crawler - инкрементный краулер;

3. Distributed Crawler - распределенный краулер;

4. Parallel Crawler - параллельный краулер;

5. Cross-platform Crawler - кроссплатформенный краулер;

Сфокусированный краулер, еще иногда называемый тематическим (topic crawler), имеет задачу загрузки связанных по конкретной теме страниц. Принципом работы такого краулера является проверка релевантности по обозначенной теме относительно предыдущей странице. Соответственно переход происходит только если страница релевантна. [6]

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

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

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

Кроссплатформенный краулер соответствует своему названию, такой тип ПО должен иметь возможность установки и настройки на машинах с разными операционными системами.

Любой веб-краулер, должен соответствовать некоторым принципам [7]:

· Надежность - краулер должен быть устойчив к «ловушкам»;

· Вежливость- краулер не должен игнорировать или идти наперекор политикам сайта (обычно прописанным в файле robots.txt);

· Качество - краулер должен уметь отделять спам от полезных страниц;

· Расширяемость - краулер должен иметь возможность добавления новых функций;

· Производительность - краулер должен эффективно использовать ресурсы системы;

· Распределенность - краулер должен поддерживать запуск на нескольких машинах для выполнения задачи в распределенном режиме;

· Масштабируемость - краулер должен повышать производительность при добавлении в него дополнительных вычислительных узлов;

· Актуальность - данные в хранилище краулера должны обновляться.

Стоит рассмотреть некоторые самые стандартные и распространенные краулеры, имеющие открытый исходный код.

Самым популярным решением в области краулеров является Scrapy, чьи краулеры по типу определяются в основном как сфокусированные, параллельные и кроссплатформенные. Пишутся краулеры Scrapy на языке Python, который поддерживает выгрузку данных в таких форматах, как XML, JSON, CSV. Как правило, это «вежливый» краулер. Такой краулер является менее производительным, однако более устойчивым и расширяемым, нежели краулер Apache Nutch.

Про Scrapy можно также сказать, что у этих краулеров существует прекрасная детализированная документация, активное сообщество.

Однако такие краулеры сами по себе не могут совладать с JavaScript и довольно тяжело даются начинающим программистам.

Краулер Nutch по типажу является инкрементным, параллельным, распределенным и кроссплатформенным. Написан на java, имеет поддержку графа узловых связей, некоторые фильтры и нормализацию URL. Краулер является масштабируемым и поддерживает до сотни узлов в кластере. Как правило такой краулер является «вежливым».

Стоит также отметить StormCrawler, основанный на технологии Apache Storm, масштабируемый, вежливый, распределенный и кроссплатформенный краулер.

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

Грабберы Selenium превосходно подходят для работы с Javascript, имеют также крупное и активное сообщество, а их документация прекрасно позволяют новым программистам быстро осваиваться в написании.

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

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

Open Search Server, инкрементный, параллельный и кроссплатформенный. Написан на java, «вежливый», поддерживает 18 языков, подключены специальные базы, позволяющие лучше понимать текст, включая базу синонимов. Инструмент имеет хорошие показатели надежности и производительности.

Norconex HTTP Collector, инкрементный, параллельный и кроссплатформенный. Написан также на java и является «вежливым». Активно развивающийся проект, поддерживает функции фильтрации, нормализации, распознавание языков и многие другие востребованные функции.

Bixo, инкрементного, параллельного, распределенного кроссплатформенного типов. Написан на java, работает на основе платформы для создания приложений на Hadoop - Cascading. «Вежливый», поддерживает масштабирование до 1000 вычислительных узлов, подходит для анализа BIG DATA.

В частности, стоит упомянуть, что большая доля краулеров пишется либо на Python, либо на Java.

Ниже представлена таблица сравнения некоторых перечисленных краулеров.



Таблица 2 - Сравнение различных краулеров

	Scrapy	Nutch	Open Search Server	Bixo	Selenium
Инкрементный	Нет	Да	Да	Да	По типу реализации
Распределенный	Нет	Да	Нет	Да	Да
Параллельный	Да	Да	Да	Да	По типу реализации
Вежливый	Да	Да	Да	По типу реализации	По типу реализации

Как правило, Selenium является настраиваемым веб-краулером, так что от его типа реализации могут очень сильно меняются его качества. Так можно получить вежливый и инкрементный краулер, так и полностью не вежливый не параллельный и не инкрементный.

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

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

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

Таким образом можно увидеть общую картину, созданную в настоящий момент среди поисковых роботов.



Рис. 3 - Подробное сравнение популярных в сети краулеров



2. Исследовательская часть

2.1 Анализ технологий работы с краулерами

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

Таблица 3 - технологии работы с краулерами

	Поддержка JavaScript	Объем информации	Растяжимость	Окружение
Selenium	Полная поддержка	Малые данные	В основном окончательный продукт	Мало проектов и плагинов
Scrapy	Требуется отдельная настройка и тестирование	Big Data	Проект легко можно расширить	Множество проектов и плагинов
bs4	Нет	Малые данные	В основном окончательный продукт	Мало проектов и плагинов

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

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

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

Однако те же краулеры Scrapy позволяют собирать информацию в разы быстрее. Плюсом не в сторону Selenium так же является язык Python, используемый в краулерах Scrapy, такой код получается гораздо компактнее и понятнее, чем у Selenium.

Однако для изучения Scrapy может понадобиться больше времени, прежде чем получится использовать весь потенциал Scrapy.

Beautiful soup является парсером для синтаксического разбора файлов типа html или xml. Написан на языке python и в общем то используется во многих типах краулеров, так что представляет собой скорее подложку, нежели готовый сервис для использования краулеров. Подключение bs4 происходит в начале кода краулера и потом просто используются команды из библиотеки beautiful soup.

Beautiful soup по своей сути не является полной структурой краулера, как тот же Scrapy, однако в помощью beautiful soup можно построить нечто похожее.

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

Scrapyd может одновременно управлять несколькими проектами, причем каждый проект может одновременно представляться в виде нескольких версий. Обычно такое ПО используется в качестве демона, который слушает запросы по запуску краулеров и создает процесс для каждого. Обычно команда выглядит как «scrapy crawl webspider», где webspider подразумевает название краулера.

В scrapyd несколько процессов могут выполняться параллельно, выделяя им фиксированное количество слотов, которые задаются опциями max_proc и max_proc_per_cpu для лучшего распределения нагрузки.

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

Selenium grid представляет собой кластер, который позволяет распараллелить тесты по нескольким машинам. Сам по себе кластер состоит из нескольких Selenium Server, которые по сути позволяют управлять браузерами на удаленных машинах.

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

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

Крупнейшим минусом любого вышеописанного ПО является то, что они довольно узкоспециализированы. Все эти программные обеспечения не позволяют работать с краулерами любого типа. Так, Scrapyd позволяет разрабатывать и использовать только краулеры на базе Scrapy.

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

2.2 Анализ технологий контейнеризации

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

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

К последним относится программное обеспечение под названием Docker. Докер позволяет упаковать в контейнер любое приложение с его окружением. Все контейнеры запускаются на одном общем ядре операционной системы, будь то Linux, Windows или MacOS. [1] В связи с этим они гораздо легче, чем виртуальные машины. Контейнеры создаются из образов, имеющих их точное содержание. Такие образы зачастую создаются путем объединения или модификации стандартных образов, загружаемых их общедоступных репозиториев.

Если говорить про виртуализацию и контейнеризацию более подробнее, то можно выделить следующие проблемы первой:

· Медленная загрузка;

· Не всегда есть поддержка совместного использования;

· Виртуальные машины зачастую требуют сложной настройки;

· Виртуальные машины занимают существенно больший объем памяти в системе.

Docker тем временем всего лишь разделяет ядро ОС на контейнеры, которые работают в виде отдельных процессов.

Наглядное сравнение технологий контейнеризации и виртуализации можно увидеть на рисунке 4.



Рис. 4 - структуры контейнеров и виртуальных машин

Также следует выделить некоторые существенные преимущества использование непосредственно Docker:

· Легкое масштабирование;

· Простая и удобная инкапсуляция приложений;

· Процесс разработки не требует установки дополнительных инструментов, потому что они имеют возможность запуска в самих контейнерах;

· Наличие простого, но понятного мониторинга.

Существует несколько важных терминов в работе с Docker, которые необходимы к пониманию.

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

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

Для некоторых контейнеров могут быть открыты порты TCP/UDP, которые не открыты для всего остального мира. Соответственно, использовать их смогут только конкретные контейнеры.

Для сохранения данных используют специальные тома, которые создаются вместе с контейнерами, по своей сути тома являются некими общими папками.

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

Множество официальных образов хранятся в публичном репозитории Docker Inc., поэтому можно сказать, что и сам ресурс является официальным. Помимо самих образов, существуют описания к ним, как например потенциальные уязвимости. На Docker Hub существуют бесплатные и платные аккаунты.

Docker базируется на ядре Linux, с используемыми в нем функциями вроде namespaces, selinux и других, также имеется некий интерфейс управления и мониторинга, который непосредственно используется для взаимодействия с Docker контейнерами. Все это схематично показано на рисунке 4.

Рис. 4 - схема работы Docker

Изначально Docker разрабатывался для Linux и использовал функции изоляции ядра Linux, такие как cgroups и linux namespaces, а также файловую систему с поддержкой объединения, например, OverlayFS, что позволяло изолированным контейнерам работать на одном экземпляре Linux.

Начиная с 2014 года, Docker Engine интегрировали в оболочку Windows. В данный момент Docker может работать и с macOS, но существует большое различие с работой на Linux. Дело в том, что платформа на самом деле инкапсулируется в виртуальную машину.

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

Docker изначально позиционировался как проект для постройки LXC-контейнеров в единое приложение. Однако при этом сами контейнеры изменились, они стали более гибкими и портативными.

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

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

Тем временем LXC полностью поддерживают как хранилища внутри контейнеров, так и вне.

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

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

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

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

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

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

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

Контейнеры LXC при сравнении с Docker больше напоминают виртуальные машины, в которых запускаются полноценные версии операционных систем.

Итоговое сравнение технологий LXC и Docker описано в таблице ниже.



Таблица 4 - сравнение технологий Docker и LXC

	Docker	LXC
Обработка процессов	Каждый контейнер - один процесс	Каждый контейнер может запускать множество процессов
Структурность	Отсутствие жесткой структуры	Жесткая структура
Портативность	Окружение заворачивается в контейнер вместе с приложением	Требуется отдельная настройка окружения на каждой машине

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

Тем самым, каждый контейнер OpenVZ больше смахивает на контейнер LXC, чем Docker. Это не упакованное приложение, это по сути переносная, более легкая, но все же виртуальная машина, к которой спокойно можно подключиться по тому же протоколу SSH.

В отличии от Docker, от которого контейнера ожидается всего одна вещь, ведь там одно единственное приложение, OpenVZ предлагает шаблоны для Linux, которые позже сам наполнит пользователь.

Также следует обратить внимание на технологию Docker Swarm, предоставляющую встроенную функциональность кластеризации для контейнеров Docker, которая в свою очередь превращает группу Докеров в единый виртуальный механизм. Начиная с версии 1.12, Docker Swarm интегрирован в Docker Engine. Утилита Swarm CLI позволяет запускать контейнеры Swarm, создавать токены обнаружения и списки узлов в кластере. Данная утилита позволяет запускать различные команды для управления узлами Swarm, например, перечисление узлов, их обновление и удаление. Однако в Swarm используется специальный алгоритм, который требует для выполнения команд требуется подтверждение большинства узлов.

По сути Swarm использует свой менеджер для обслуживания множества Docker контейнеров, а также представляет собой балансировщик нагрузок для контейнеров.

Из плюсов можно отметить простоту работы и освоения, если есть опыт работы с Docker, однако стоит отметить, что у Swarm довольно узкий функционал и относительно низкая отказоустойчивость, что делает его непригодным для некоторых проектов.

Наглядную схему работы Docker Swarm можно увидеть на рисунке 5.

Рис. 5 - схема работы Docker Swarm

В Docker Swarm все узлы делятся на два типа: первый - manager, с которых в основном происходит управление кластером; второй тип - worker, специальные рабочие узлы, в который, собственно, и исполняются контейнеры.

По сути, каждый manager также по определению является рабочим, так что в кластерах могут отсутствовать чисто worker узлы. Также стоит отметить, что среди управляющих узлов существует некий лидер кластера, на который перенаправляются команды с других управляющих узлов.

Одним из аналогов Docker является Rocket или просто rkt. Специально разработанное программное обеспечение под легковесную CoreOs было создано с целью ориентации на более простые инструкции портативных контейнеров. [3] Соответственно rkt является одной из реализаций App Container, спецификации по формату образов, среде выполнения и способу распространения.

Rkt полностью поддерживает запуск образов докер, однако стоит выделить некоторые различия между Rocket и Docker. Различия приведены в таблице 5.

Таблица 5 - сравнение технологий docker и rkt

	rkt	Docker
Подпись образа	Подписи проверяются по умолчанию	Подписи проверяются демоном Doker
Права доступа	Проводятся операции с подписью на пользователя без привилегий	Демон Docker является суперпользователем и выполняет все операции
Сочетаемость	Управление стандартными процессами Unix с помощью systemd	Управление дочерними процессами требует встроенных пользовательских систем инициализации
Съемная изоляция	Chroot, cgroups, KVM	Изоляция по параметрам демона Docker
Создание образа	Unix-подобные инструменты для сборки контейнеров по сценариям	Сборка демоном Docker по описанию в Dockerfile
Распределение контейнеров	Образы, обслуживаемые HTTPS, представляют собой обычный набор файлов в архиве	Реестр Docker,имеется ограниченное пространство имен

Функционал rkt в целом очень похож на функционал Docker, однако Rocket, помимо Docker Image, может использовать образы App Container. Также архитектура rkt имеет больший упор в архитектуре на компоновку и безопасность.

Docker, при записи использует демон Docker Engine, который после работает в качестве демона логирования. Система в целом работает централизованно под root. Такая система хороша для разработки, однако в дальнейшем она тяжело интегрируется с системами Unix вроде systemd.

Rkt не имеет централизованного демона инициализации, однако все процессы контейнера запускаются с помощью клиентских команд, что позволяет использовать системы инициализации такие как systemd.

В Rocket используются стандартные разрешения управления правами доступа Unix. Пользователи без привилегий могут осуществлять скачивание и проверку подписей уже после первой настройки data директории Rocket.

Rkt может работать со множеством видов контейнеров разного уровня, например runC. Данный контейнер также не имеет централизованного демона, поэтому легко может быть интегрирован с systemd или upstart. Системные контейнеры, такие как LXC и LXD, использующиеся для извлечения полносистемных контейнеров, которые используются для хранения в одном образе целой операционной системы также поддерживаются в Rocket, однако последний не может быть использован для работы с этими полносистемными контейнерами.

Kubernetes представляет собой один из самых распространенных проектов, предназначенных для автоматизации развертывания, управления и масштабирования приложений-контейнеров. Данный проект работает с различными инструментами-контейнерами, включающими в себя Docker и rkt. [4] Многие облачные службы в данное время предлагают платформу или инфраструктуру на основе Kubernetes (платформа как услуга или инфраструктура как услуга).

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

Основные объекты Kubernetes представляют из себя [10]:

· Node - представляет собой физическую или виртуальную машину, на которой происходит развертывание и выполнение контейнеров-приложений.

· Pod - базовая единица запуска и управления приложениями, контейнер или несколько контейнеров, которым обеспечен запуск на конкретном узле. При этом происходит разделение ресурсов и выдается уникальный на кластере IP-адрес.

· Volume - является общим ресурсом хранения, к которому имеется доступ из всех контейнеров на поде.

· Service - сервисом называется определенный набор подов, которые связаны логически. Система Kubernetes позволяет использовать функции обнаружения и маршрутизации сервисов по запросу.

· Controller - процесс, управляющий текущим состоянием кластера. Контроллер стремится привести состояние к желаемому, использую набор маркированных подов.

· Operator - вид ПО Kubernetes, сохраняющий свое состоянием между выполнениями.

Из плюсов можно выделить, что Kubernetes представляет собой довольно мощный инструмент с широким функционалом, способен управлять контейнерами, а также превосходно сочетает в себе автоматизацию и масштабируемость. Из минусов стоит отметить, что Kubernetes считается сложным и долгим в освоении [9], также некоторые приложения становятся трудно запускаемыми с помощью данного программного обеспечения.

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

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

Из плюсов использования D2C можно выделить тот факт, что для начала работы с данной платформой требуются лишь знания основ конфигурирования сервисов, однако, несмотря на свою внешнюю привлекательность, платформа слишком фокусируется на простоте разработки, так что для некоторым случаев сервис может не иметь достаточно гибкости. [5]

Ниже, на изображении 6, представлен интерфейс D2C.

Рис. 6 - интерфейс платформы D2C. [18]

Rancher представляет из себя амбициозный проект, который предназначается для облегчения управления сложными средами. Помимо самостоятельного управления контейнерами, Rancher способен поверх себя запускать другие сервисы, такие как Kubernetes и Docker Swarm, причем процесс является довольно простым и выполняется в самом проекте.

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

Также стоит отметить, что с версии 2.0 Rancher переходит на Kubernetes в качестве единого оркестратора контейнеров.

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

Сама по себе Cattle поддерживала рыночные решения в виде Kubernetes, Docker Swarm и Apache Mesos, однако популярность именно первого заставила разработчиков окончательно перейти на конкретную платформу. Это, несомненно, убрало возможность пользователю лично выбирать платформу по своему вкусу, однако позволило разработчиками лучше оптимизировать работу с Kubernetes. По заявлению разработчиков с версии 0.63 пользователи Rancher могут в один клик запустить Kubernetes, и уже в течение пяти или десяти минут использовать готовый полностью развернутый кластер.

Следующие проблемы с Kubernetes решались благодаря развитию разных утилит, например, kops, а также тому, что сервис Kubernetes стал предлагаться как услуга. Именно тогда основатель проекта Kubernetes стал говорить о том, что современные приложения будут запускаться на базе Kubernetes, как ключевой части платформы.

В целом все так и случилось, Kubernetes был превращен в универсальный стандарт для инфраструктуры, который продавался практически у всех поставщиков. Именно после этого момента и вышла Rancher 2.0.

Во второй версии платформа все еще состоит из сервера и агентов, который устанавливался на обслуживаемые хосты. При запуске docker образа автоматически стартовал кластер Kubernetes, который превращал каждый новый хост в свою часть.

Помимо основного кластера могут создаваться дополнительные, либо новые, либо импортированные с помощью kops, при этом агент запускается во всех кластерах. В Rancher 2 также представлены различные прослойки для централизованного управления всеми кластерами (мониторинг, бэкапы, аутентификация, обновления) и взаимодействия с ними (веб-интерфейс, API, CLI), общая схема Rancher 2.0 представлена на рисунке 7.

Рис. 7 - архитектура Rancher 2.0

По сути Rancher 2.0 позиционирует себя как решение для стандартных sql баз данных, для этого даже предлагается использовать специальные «базы данных как услуги». Стоит также отметить, что бэкенд с баз данных всех кластеров помещается в одну общую БД.

Если более детально рассматривать вторую версию Rancher, то получится схема как на изображении 8.



Рис 8. - детальная структура Rancher 2.0.

Кстати, о вышеупомянутом Apache Mesos. Данная система управления кластером очень сильно похожа на тот же Kubernetes, по крайней мере с точки зрения основного видения.

Однако же, стоит отметить, что все-таки Mesos больше представляет собой распределенное ядро системы, которое по сути представляется множеством машин в виде одной логической машины. [12] В целом, Mesos создавался для использования на больших физических ресурсах, и в целом затачивался под разные масштабируемые приложения для обработки данных, вроде того же Hadoop или Spark. Данный проект в целом гораздо тяжелее того же Kubernetes.

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

Состоит кластер Mesos из следующих компонентов:

· Mesos Masters - представляют собой контроль над всем кластером, предоставляют ресурсы, распределяют задачи между рабочими узлами. Как правило, таких узлов несколько, но активным лидером является единственный.

· Mesos Slaves - рабочие узлы, на которых распределяются задачи для выполнения. Могут выполнять задачи в своих контейнерах Mesos или в контейнерах Docker.

· Frameworks - так как Mesos предоставляет только среду для выполнения поставленных задач, то вся логика работы с задачами ложится на фреймворки. Самые известные из используемых в Mesos фреймворков: Aurora, Hadoop, Jenkins, Spark.

· ZooKeeper - главный демон в кластере Mesos, который отвечает за работу узлов-мастеров, а также выдает остальным узлам информацию, какой узел в данный момент является лидером. Он отправляет рабочим специальный запрос, который позже будет использоваться ими для подключения к мастеру.

Наглядная демонстрация архитектуры Mesos показана на рисунке 9.

Рис. 9 - архитектура Mesos

Есть еще один довольно интересный сервис для работы контейнерами - Nomad. Это не такая продвинутая система, как предыдущие, но у нее тоже есть свои особенности.

В первую очередь, Nomad отличается от Docker тем, что в нем есть единое описание всей инфраструктуры, в котором помимо это также содержится healthcheck. [22] Но тут же вскрываются большие минусы: Nomad не имеет нормальной возможности работы с сетью, возможности работы с персистентными данными, сохраняющими свои старые версии.

К этим проблемам можно также прибавить отсутствие поддержки Docker volumes, неумение перезапускать контейнеры - Nomad просто помечает не прошедшие healthcheck контейнеры просто как провалившиеся. Единственная возможность перезапустить рабочий процесс - непосредственно с рабочего узла, что явно плохой признак. Большим минусом можно также посчитать необходимость повторение кода. Если нужно передать определенные переменные в разные контейнеры, то придется это сделать несколько раз.

Крупным недостатком является еще отсутствие настройки зависимости между сервисами в Nomad.

Среди положительных качеств можно выделить:

· Healthcheck описывается тут и сразу, причем поддерживаются проверки http, tcp, script.

· Любое задание можно обновить с помощью hcl-файла, при этом контейнеры обновляются с предварительно заданными параметрами интервалов и параллельности.

· Любое задание можно запустить в тестовом режиме dry-run.

· Прямо в файле есть возможность передавать private registry.

Разработчики Nomad обещают развивать проект и продолжают работать над ним, однако в данный момент продукт очень сильно недотягивает до своих более известных конкурентов и не может должным образом соревноваться с ними. Тем более, для данного проекта Nomad не имеет многих важных функций, которые есть у того же Docker Swarm.

Краткое сравнение по рассмотренным решениям представлено в таблице ниже.

Таблица 6 - сравнение оркестраторов.

	тип	направленность	портативность	цена
Docker Swarm	контейнерная оркестровка	разработка, небольшие компании	высокая	бесплатно
Kubernetes	контейнерная оркестровка	готовый продукт	средняя	бесплатно
Rancher	управление инфраструктурой	готовый продукт	средняя	бесплатно
Mesos	управление инфраструктурой	готовый продукт	низкая	бесплатно

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

Про Rancher можно сказать, то же, что и про Kubernetes, однако тут появляется лишь дополнительный уровень управления.

Docker Swarm занимает более скромные позиции, и скорее подходит для каких-нибудь малых или средних компаний. Вдобавок стоит отметить, что корпоративный рынок весьма активно поддерживает Docker Swarm, в частности можно отметить Microsoft Azure.

Apache Mesos представляет собой стабильную отказоустойчивую систему, рассчитанную на большое количество физических машин, то есть такая система интересна в первую очередь крупным компаниям, которые смогут использовать возможности Mesos на полную.

Благодаря отличной возможности управлять контейнерами, хорошим вариантом является Kubernetes. Однако Docker Swarm, являясь более узконаправленным средством для работы с контейнерами больше подойдет для выполнения текущей задачи за счет свой относительной простоты.

Да, Kubernetes предоставляет больше возможностей и сервисов для проектов, но текущий проект больше заинтересован в довольно узком направлении. Kubernetes требует большие объемы знаний и навыков, и поэтому данное ПО требует большего времени для подготовки, ведь в целом требуются не только знания о технологии контейнеризации docker, но и конкретные знания по работе с самим Kubernetes.

Таким образом можно считать, что для простой системы, которой и является данный проект, прекрасно подойдет Docker Swarm.

...