2.3 Процессы ЖЦ краулеров

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

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

Рис. 10 - ЖЦ краулеров

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

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

2.4 Анализ технологий автоматизации управления приложениями

Для автоматизации управления процессами в Docker Swarms имеется возможность использовать Jenkins в Docker.

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

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

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

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

Одна из таких технологий - Bamboo, CI-сервер от Atlassian. Поддерживает разнообразные инструменты программирования по типу Ant и Maven. Выпускается Bamboo в виде сервера либо облака. Из положительных качеств, можно выделить удобный интерфейс, а также отличную интеграцию с другими решениям Atlassian, например, Jira. Недостатком же является довольно скудное количество плагинов для нестандартных заданий, а также то, что существующие плагины довольно дорогие.

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

Travis CI, распределенный CI сервис с открытым доступом, используемый для проектов на GitHub. Также имеет множественную поддержу языков, вроде PHP, С++, Python или JavaScript. [24] Положительной стороной Travis CI можно считать довольно легкий вход в работу и хорошо сделанную документацию. Сервис превосходно подходит для работы с проектами GitHub, однако для других проектов имеется довольно плохая поддержка.

Team Foundation Server или сокращенно TFS, обеспечивает управление исходным кодом. Прекрасно подходит для использования в качестве серверной части для разных интегрированных сред разработки, однако данный сервис изначально был сделан для использования с Visual Studio и Eclipse. Плюсом считается поддержка данным сервисом бесплатных частных репозиториев, также стоит отметить довольно простую реализацию. Из минусов чаще всего называют медлительность сервиса, а также плохо реализованный интерфейс.

Общую картину можно увидеть на таблице 7.

Таблица 7 -сравнение технологий непрерывного интегрирования.

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

2.5 Архитектура системы

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

Рис. 11 - архитектура системы

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

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

Для сбора данных в виде логов, используются сервисы Elasticsearch, Logstash и Kibana. Данные сервисы позволяют собирать результаты работы краулеров в контейнерах и выводить структурированные отчеты по работе краулеров. При необходимости также можно выводить все файлы логирования в виде графиков.

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

· Мониторинг java-серверов приложений через стандартную технологию java Management Extensions.

· Поддержка внешних скриптов на разных языках, таких как PHP, Python, Java.

· Имеется интеграция с большим количеством программных инструментов для системного управления.

Zabbix отлично позволяет настроить мониторинг на кластере. Ядро системы собирает данные о производительности и доступности с помощью Zabbix-прокси. Эти элементы хранят данные на локальном уровне до того, как пошлют данные на Zabbix-сервер. [25] Прокси также позволяют равномерно распределять нагрузку на сервер, в таком случае прокси занимается только сбором данных.

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

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

3. Практическая часть

3.1 Контейнеризация краулеров

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

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

· Dockerfile - файл с описанием параметров создания контейнера.

· Docker-compose.yml - пакетный менеджер, описывающий структуру конетейнера.

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

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

· Файл readme с инструкциями к краулеру.

Для краулеров Scrapy и некоторых других также может существовать специальный файл, например, scrapy.cfg [23], который хранится в корневом каталоге краулера и отвечает за конфигурацию непосредственно Scrapy.

Отдельно можно отметить каталог, содержащий паук краулера на Python. В краулерах Scrapy таком каталоге как правило содержатся папка с файлами, содержащими классы краулера, а также несколько файлов [8]:

· Items.py - содержит классы с полями собираемых данных;

· Pipelines.py - задает определенные действия при открытии и закрытии краулера или сохранении данных;

· Settings.py - отвечает за пользовательские настройки краулера.

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

Для создания кластера Docker потребуется развернуть две или больше машин на Linux, в этом случае использовались машины с Ubuntu версии 18.04. Одна из машин назначается мастером в последующем создании кластера Docker Swarm, остальные машины назначаются рабочими узлами.

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

После присоединения узлов к главному серверу образуется кластер.

Установка на Ubuntu производится стандартной серией команд:

1. sudo apt-get update - обновляем репозитории программного обеспечения на машине.

2. sudo apt install docker.io - непосредственная установка Docker на машину.

Опционально, если на машине уже стояла старая версия Docker, можно удалить ее до установки новой с помощью команды «sudo apt-get remove docker docker-engine docker.io».

Запуск производится командами «sudo systemctl start docker» и «sudo systemctl enable docker». При желании можно убедиться, что скачанная версия верна с помощью команды «docker -version», пример на рисунке 12.

Рис. 12 - результат выполнения команды проверки версии

Если установка произошла успешно, то появится сообщение, которое можно увидеть на рисунке 10. Также, можно проверить работоспособность Docker командой «docker run hello-world». Данная команда скачает на компьютер образ контейнера и запустит его. Выглядит это приблизительно как на изображении 13.

Рис. 13 - запуска контейнера Hello World

Так, следующим шагом следует создать протестировать все Docker образы, которые впоследствии будут использоваться в кластере.

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

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

Прежде всего был создан контейнер для краулера Scrapy. Сначала необходимо создать файл Dockerfile, в котором будет описано с какими параметрами будет создавать образ контейнера. Это общий файл, который необходим при создании любого контейнера. Наполним файл следующими строками, показанными на рисунке 14.

Рис. 14 - описание файла Dockerfile

Эти команды должны позволить создать контейнер специально для краулера Scrapy. В файле requirements.txt находятся названия всего необходимого для работы краулера. Соответственно, данный файл пишется для создания необходимого контейнера. Как правило некоторые краулеры изначально пишутся сразу вместе с requirements.txt. Если такого файла нет, то необходимо выяснить, что требуется для работы краулера, и вписать все это в Dockerfile, либо самому создать файл с необходимым списком.

Также можно создать файл, в данном случае такой был создан и назван st-spider.py, который с помощью API будет запускать краулер в контейнере. Команда с использованием этого скрипта в таком случае добавляется в файл Dockerfile, что можно увидеть на рисунке 12 выше.

Создается контейнер командой «docker build mycrawler». Далее контейнер будет создаваться по пунктам из файла Dockerfile. Если какие-то важные пункты не смогут исполниться, то докер контейнер не будет до конца создан. Однако выполненные команды кэшируются, поэтому, если произошла ошибка при создании контейнера, после быстрого исправления процесс будет начат уже не с нуля.

После того, как контейнер был собран, можно запустить его с помощью команды «docker run mycrawler».

На рисунках 15 и 16 показан процесс запуска и работы контейнера с краулером Scrapy.

Рис. 15 - Запуск контейнера Docker c краулером Scrapy

Рис. 16 - Работа краулера Scrapy в контейнере Docker

Существует возможность запуска контейнера с помощью команды «docker run -v ~/Scrapy/mycrawler:/scrapy Scrapy scrapy runspider /scrapy/demospider.py -o /scrapy/logs.json». Однако в таком случае, нет необходимости писать команду «CMD [ “python3”, “./st-spider.py” ]», так как краулер будет запущен с помощью команды.

Данная команда позволяет подключить папку ~/Scrapy к контейнеру, а также файл вне контейнера logs.json будет собирать результаты использования краулера внутри контейнера.

Для другого типа краулеров, вроде Apache Nutch. Если Scrapy является краулером написанным на Python, то для Nutch уже требуется java.

Готовый Apache Nutch уже есть в виде докер образа на официальном хабе hub.docker.com, осталось лишь скачать этот образ и по нему построить контейнер командой «docker build -t apache/nutch».

Для запуска краулера потребуется ввести две команды: «docker run -t -I -d -name nutchcontainer apache/nutch /bin/bash» и «docker attach -sig-proxy=false nutchcontainer».

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

Рис. 17 - конфигурация файла Dockerfile для Nutch

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

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

3.2 Автоматизация процессов ЖЦ краулеров

Для итоговой работы потребуется установка и запуск Jenkins, для этого необходимо прежде всего установить Java путем команды «apt install openjdk-8-jdk». Далее необходимо добавить репозиторий для Jenkins, после чего уже можно будет установить сам Jenkins командой «apt install jenkins». На данном шаге также необходимо разрешить открытие порта 8080, как основного, используемого Jenkins. Далее происходит первичная настройка Jenkins. Для этого необходимо зайти в браузер, ввести адрес или имя сервера с портом 8080. Сразу стоит отметить, что сбор образов контейнеров и их запуск можно сделать в Jenkins, для этого в нем необходимо создать новое задание, для удобства стоит назвать это задание по имени краулера. Необходимо нажать на «New Item», далее «Freestyle project».

В новом проекте нужно зайти в раздел с конфигурацией, выбрать «Add build step» и в нем «Execute shell». В командной строке используется код, какой написан выше, использованный для создания и запуска контейнера, пример настройки и итог показан на изображениях 18 и 19.

Рис.18 - пример управления ЖЦ краулера в Jenkins

Рис. 19 - cборка и запуск контейнера в Jenkins

Для сбора и анализа логов можно поставить на Docker ELK, или же Elasticsearch, Logstash и Kibana. По сути ELK позволяет не просто собирать огромные текстовые логи, но превращает их в наглядные и показательные графики. [11]

Задачи можно разделить на две части: поисковый механизм и интерфейс к данным, за которые ответственные Elasticsearch и Kibana, а также обработка данных с последующей отправкой их в Elasticsearch, за что отвечает Logstash.

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

В конфигурациях Filebeat необходимо настроить перенаправление определенных логов nginx, и уже их отправлять в контейнер с ELK. Сам ELK также можно скачать с хаба Docker под именем образа «sebp/elk». Тут необходимо также настроить конфигурационный файл и убедиться, что порты принятия логов от Filebeat совпадают по настройкам с последними.

Для настройки мониторинга необходимо скачать Zabbix версии 3.х. Для начала нужно установить пакет конфигурации репозитория. Прежде чем установить пакеты Zabbix для сервера, прокси и веб-интерфейса, необходимо также скачать и установить Apache Web Server и MySql. Без базы данных не будут работать демоны сервера и прокси Zabbix. Необходимо будет сразу разрешить доступ к серверу MySql с машин из кластера. Следующим шагом является установка zabbix-server и zabbix-frontend. Последнее необходимо, что бы данные отображались на веб-сервисе Apachi. Далее следует импортировать начальные настройки на баз данных для сервера и прокси с помощью команды «zcat /usr/share/doc/zabbix-server-mysql/create.sql.gz | mysql -uzabbix -p zabbix». Для прокси нужно ввести аналогичную команду, заменив сервер на прокси. В файле zabbix_server.conf необходимо указать новую базу данных для использования. Аналогичный шаг при настройке файла для прокси.

Следующим шагом необходимо скачать контейнер, использующий zabbix «docker pull monitoringartist/zabbix-agent-xxl-limited». Данный контейнер является Zabbix-агентом, специально настроенным, чтобы отслеживать данные в Docker-контейнерах. Контейнер с агентом ставится с использованием префикса «-e “ZA_Server=ipaddr», в котором указывается, где находится Zabbix-сервер. Как только контейнер с агентом начинает работать на машине, он начинает отслеживать состояние других контейнеров на этой машине. График мониторинга контейнеров показан на рисунке 20.

Рис. 20 - мониторинг контейнеров

3.3 Обеспечение отказоустойчивости и масштабирования

На машине уже установлен Docker, поэтому можно было бы сразу перейти к пункту запуска кластера, однако перед этим необходимо провести конфигурацию firewall.

Для управления политиками сетевого экрана используется UFW, или же несложный фаервол. Если по какой-то причине в системе не стоял UFW, то его можно установить командой «apt-get install ufw».

Командой «ufw allow 2376/tcp && ufw allow 2377/tcp && ufw allow 80/tcp», были открыты порты 2376, 2377 и 80. Это необходимые порты для работы Docker, поэтому их обязательно надо открыть. [16] После этого необходимо перезагрузить UFW и включить утилиту. Также необходимо перезапустить Docker для применения новых правил.

Теперь непосредственно создание кластера Docker. На машине-мастере необходимо ввести следующую команду, для создания непосредственного мастера в пока еще не существующем кластере: «docker swarm init -advertise-addr 10.0.2.15». С помощью данной команды в данной сети будет произведена «реклама», что существует мастер docker в сети с таким-то ip-адресом.

Рис. 21 - инициализация мастер-узла Docker

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

С помощью команды «docker node ls» на мастер-узле можно проверить, запустился ли кластер. Если да, то в статусе должно быть написано Ready, а в доступности Active. [14]

На рабочем узле необходимо также установить Docker, и использовать команду с ключом с рисунка 16. Если все прошло успешно, то в терминале высветится надпись, что данный узел присоединился к swarm в качестве рабочего узла. Также, теперь при помощи той же команды «docker node ls». В случае успешного присоединения исполнение команды будет выглядеть как на рисунке 22.

Рис. 22 - кластер Docker с двумя узлами

Для тестирования, можно использовать какой-нибудь веб-сервис, в данном случае выбор пал на Apache web server. Командой «docker service create -name wbsrvr -p 80:80 httpd» создаем контейнер и направляем его сразу на 80 порт. Далее необходимо чтобы данный сервис использовался на 2 контейнера путем ввода команды «docker service scale wbsrvr=2». По итогу, один контейнер будет работать на мастер-узле, второй на рабочем.

Проверка работы контейнеров в кластере показана на изображении 23, все работает.

Рис. 23 - итог работы контейнера в кластере

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

Заключение

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

Данная работа заключалась в решении проблемы автоматизации работы с веб-краулерами. Были поставлены и выполнены конкретные задачи:

· Проведен обзор разнородных видов веб-краулеров, а также определены их требования.

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

· Определены и автоматизированы типовые процессы в ЖЦ веб-краулеров.

· Проанализированы различные технологии по автоматизации развертывания и управления приложениями.

· Разработана и спроектирована архитектура системы.

· Произведено создание и запуск контейнеров с образами краулеров.

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

В качестве инфраструктуры был развернут кластер Docker Swarm на нескольких машинах. Автоматизация работы с краулерами была достигнута с помощью Jenkins с использованием технологии непрерывной интеграции программного обеспечения. Централизованный вывод данных из контейнеров достигался с использованием ELK, а мониторинг для всей системы проводился с использованием Zabbix. Результаты работы позволили упорядочить процессы разработки и эксплуатации веб-краулеров по сбору данных из открытых источников информации.

Размещено на Allbest.ru