Столкнувшись с концепцией Big Data некоторое время назад, у меня возник очевидный вопрос: как это можно «потрогать» своими собственными руками, где и как можно посмотреть программное обеспечение, составляющее данный концепт, разобраться с его конфигурацией, а в силу того, что я являюсь специалистом информационной безопасности, «потыкать в него палочками», провести проверку на предмет защищенности, возможности несанкционированных доступов. Ввиду специфики систем данного рода, их достаточно тяжело развернуть в качестве учебного проекта на собственном персональном компьютере. Используемые в организации программы данного класса, мягко говоря, также не очень предназначены для того, чтобы их «ковыряли», «подламывали» и всячески «раскачивали», пытаясь вывести из штатного режима работы.
Представляемый в данной статье проект как раз предназначен для того, чтобы развернуть внутри Docker-контейнеров, распределенных на несколько компьютеров, максимально защищенную среду Hadoop (включающую в себя ПО Ranger и Knox), предоставить доступ к ее интерфейсам для тестирования. Если кратко, то это все. «Git clone https://github.com/makrovan/Hadoop-in-Docker.git», «docker compose up -d» с некоторыми предварительными настройками и «будет вам счастье». Написанный код (преимущественно shell-скрипты и конфигурация docker) максимально документирован ссылками на ресурсы сети Интернет, откуда это взято или хотя бы, где это все подробно описано. Технологии все общеизвестные, новые паттерны я здесь не изобретал. Если же что-то становится не понятным или docker-контейнеры «не взлетают» с первого раза – придется читать дальше, тут я как раз постараюсь описать все подробнее. И так поехали…
Наиболее доступным способом знакомства с программами семейства Big Data сегодня является обучение на специализированных курсах. По отзывам коллег и товарищей, основной ценностью их как раз и является то, что тебе предоставляют некий стенд, с развернутым на нем стеком всего необходимого программного обеспечения. Данный стендовый образец можно использовать в разных целях. По крайней мере, если ты его «уронишь» – тебе максимально быстро «накатят» новый «чистый» образ и ты можешь продолжить свои эксперименты. Однако это решение временное, и достаточно дорогое для индивидуального подхода. Отсюда и возникла необходимость собственного «стенда» с серверным ПО, на основе которого как раз и работает та самая Big Data.
Говоря Big Data, здесь я имею ввиду, в первую очередь, стек программного обеспечения Hadoop. Это конечно же не совсем верно, и сегодня уже существует множество других решений, работающих с информацией по принципам Big Data (горизонтально масштабируемой, отказоустойчивой, распределено параллельно хранящейся и обрабатываемой и т.д. и т.п.), но Hadoop все равно есть, он никуда не делся. Надо также понимать, что Hadoop – это не единая программа, а набор утилит, ввиду чего его настройка, на мой взгляд, сложнее, а от этого, возможно, и уязвимее перед потенциальными компьютерными атаками. В общем, его конфигурация однозначно требует более пристального внимания со стороны информационной безопасности в любой организации.
Следующий шаг при развертывании Hadoop - это выбор формы поставки. Как раз ввиду того, что это набор утилит, он на корпоративном рынке чаще всего поставляется не как Hadoop, а преимущественно как ПО, основанное на Hadoop, «обвешанное» дополнительными утилитами для настройки и администрирования. На российском рынке, это продукты компании «Arenadata», за пределами РФ – это «ClouderaCDH», «Hortonworks Data Platform» и, на сколько мне удалось нагуглить, еще несколько полностью облачных решений. Установить и использовать их гораздо проще, конфигурировать, как правило, можно из «одного окна». Однако, в основе их всех лежит свободно распространяемый набор утилит проекта фонда Apache Software Foundation. Как специалист в области информационной безопасности, я привык разбираться с самой сутью проблемы, поэтому для своего проекта выбрал именно «ванильный» Hadoop.
Немного еще погуглив, можно легко понять, что развертывание Hadoop заключается в настройке общей для всех его компонентов конфигурации, распространении данной конфигурации на все сервера, последовательном запуске программ с различными входными параметрами. На первый взгляд, наиболее простым решением запуска всего этого скоупа является использование виртуальных машин, объединенных в единую сеть. Однако при таком подходе требуется дополнительный компонент, который бы распространял единую конфигурацию на все виртуальные машины, запускал ту, либо иную утилиту с нужными параметрами. Либо еще вариант: ручная настройка каждой виртуальной машины – но это уже совсем не наш случай.
Первый подход, связанный с разработкой дополнительных утилит синхронизации кажется очень похожим на выше упомянутые решения крупных российских и западных вендоров. Для частного использования, я считаю, он не оптимален и весьма сложен в развертывании. Гораздо более удобным, на мой взгляд, является использование контейнеризации. В частности, мой проект основан на возможностях Docker: контейнеры описаны в Dockerfile, параметры их запуска в docker-compose, используется многослойная архитектура, когда первичный слой нескольких контейнеров содержит общую конфигурацию.
Сделав все по инструкции «Hadoop Cluster Setup» с сайта https://hadoop.apache.org, я получил рабочие контейнеры с NameNode-ой, ResourceManager-ом, DataNode-ами, и NodeManager-ами (запущены внутри одного контейнера), а также HistoryServer-ом. От использования дублирующей NameNode-ы и ZooKeeper-а я отказался – все-таки это частный петпроект, высоко нагруженной системы тут явно нет.
«Чистая» установка перечисленного ПО не предполагает никакой защиты, поэтому доступ к веб-интерфейсам компонентов развернутого Hadoop был возможен путем монтирования портов docker-контейнеров к локальной, хостовой, машине, на которой они запущены. Заходя в браузере по адресу: http://localhost:порт, указанный в Docker-compose для конкретного сервиса, я увидел «ту самую зеленую страницу» NamrNode-ы, а также веб-интерфейс Yarn-a и HistoryManager-а. Но все было абсолютно незащищенным – с точки зрения информационной безопасности это было ужасно. Авторизации, аутентификации не было никакой, логирование настроено не понятно, как и где, данные веб-интерфейса передаются в незашифрованном виде, в общем, это было только самое начало пути.
Все доступы к hdfs и иным сервисам в Hadoop могут быть защищены протоколом Kerberos. Следующим этапом в развитии проекта именно это и было сделано: внутри отдельного контейнера развернут и настроен должным образом kdc-сервер, отвечающий за аутентификацию сервисов и пользователей. Раздача keytab-ов, создаваемых при каждой загрузке KDC-сервера, реализована путем монтирования совместно используемых разными контейнерами директорий хостовой машины. Ожидание keytab-ов в остальных контейнерах сделана путем некоего подобия мьютекса: наличие/отсутствие файла в совместно используемой директории /Sync хостовой машины.
Да, забыл упомянуть: NameNode и DataNode-ы данные файловой системы hdfs хранят в директориях хостовой машины, на которых запущены контейнеры. Это позволяет сохранить hdfs-файлы даже при новом развертывании контейнеров.
Создание KDC-сервера «потянуло» за собой развертывание OpenLDAP-сервера. Kerberos может хранить служебные данные пользователей в разных форматах, но связка Kerberos – LDAP, кажется, наиболее популярной сегодня. Таким образом, контейнер ldap-server в проекте как раз это реализует. Естественно в соответствии с требованиями информационной безопасности обмен данными с oldap-сервером идет строго по зашифрованному каналу, запущен только протокол ldaps:// (ldap:// и ldapi:// остановлены в процессе установки). Для шифрования данного канала при первой инициализации генерируется корневой ssl-сертификат, так называемый CA-сертификат. Для обращения к ldap-серверу данный сертификат добавлен на уровне операционных систем в качестве доверенного, кажется, на все контейнеры, включенные в проект.
Да, прямое обращение к ldap идет не со всех контейнеров, однако у данного сертификата в проекте более важная роль: помимо обращения к ldap-серверу, данным сертификатом подписываются все дочерние ssl-сертификаты. Для шифрования веб-трафика на всех Hadoop-хостах, а позже и во всех контейнерах, входящих в проект, генерируются ssl-сертификаты, которые подписываются порожденным на ldap-сервере CA-сертификатом.
Забегу вперед, указав, что корневой сертификат генерируется единожды, и далее хранится в каталоге хостовой машины. Это связано со спецификой контейнера, содержащего развернутую базу данных в Postgres (используется Ranger-ом). Там инициализация БД, как и ее настройка, возможны только при первичном включении контейнера. Позже в статье я еще вернусь к контейнеру с Postgres и поясню подробнее, для чего он.
Таким образом среда получилась уже более – менее защищенной. Алгоритм загрузки контейнеров стал таким:
LDAP-сервер включается, проверяет/генерирует корневой CA-сертификат; «проливает» схему Kerberos, создает пользователей для доступа из KDC-сервера;
KDC-сервер дожидается старта LDAP-сервера, после чего создает principal-ов всех сервисов Hadoop, сохраняет keytab-файлы в совместно используемую с другими контейнерами директорию;
запускаются все Hadoop-сервисы, сконфигурированные на использование Kerberos-протокола для аутентификации, а также подписанных ssl-сертификатов для веб-сервисов. Логирование в конфигурационных файлах я изначально настраиваю везде по максимуму (это не правильно, потому что лог-и становятся излишне большими, однако для отладки и развертывания – это удобно).
Как я сказал выше, на данном этапе уже получилась достаточно защищенная среда: есть аутентификация, логирование, шифрование. Слабым в данной схеме остается разграничение доступов, при данной конфигурации оно делается на уровне ОС: в конфигурационных xml-файлах задано реплицирование нейминга аутентифицированных principal-ов к нативным именам пользователей ОС, на которой запущен сервис Hadoop. Очень слабая защита от несанкционированного доступа, для устранения этой потенциальной уязвимости будет добавлен Apache Ranger – специализированное ПО, как раз предназначенное для разграничения доступа к сервисам Hadoop.
Но об этом чуть позже. Сейчас же я бы хотел обратить внимание на то, что с вводом обязательной аутентификации, мы запретили себе доступ в веб-интерфейсы сервисов Hadoop с хостовой машины. Теперь для доступа к ним через браузер используется протокол SPNEGO. Только пользователь, выполнивший в ОС процедуру «kinit», может видеть содержимое веб-интерфейса программы. Для выполнения команды kinit хост должен быть в одной подсети с Kerberos-сервером (krb5kdc), что в условиях контейнеризации является нетривиальной задачей. Простое монтирование портов из контейнера к хостовой машине теперь уже не помогает: на «расшаренных» портах загружаются страницы «error 401».
Для решения этой проблемы, в той же сети, что и все контейнеры, создан и запущен хост с развернутой на нем графической средой. Внутри docker-контейнера графической среды нет и быть не может (ограничение Docker-а), там запускается только shell-оболочка командной строки. Hadoop - не Hadoop без веб-интерфейсов NameNode-ы и т.п. Верне сказать, в коммерческой эксплуатации помимо данного сервиса, используется также командная строка, но Hadoop предоставляет возможность веб-интерфейсов, RestAPI перечисленных сервисов - отказываться от них в проекте мне не хотелось.
Для получения доступа к веб-интерфейсам было решено использовать монтирование сокетов Unix для X11 с хостовой машины внутрь контейнера. Настроив соответствующим образом переменную DISPLAY внутри контейнера и примонтировав директорию «/tmp/.X11-unix», фактически даем доступ операционной системе контейнера к экрану хостовой машины. Контейнер «hadoop-client» в проекте создан для того, чтобы запустить браузер «Firefox» (поддерживающий SPNEGO), аутентифицировавшись при этом на сервере Kerberos. Тут хочу добавить некоторые детали реализации: развернуть внутри контейнера пакет «Mozilla-Firefox»(как и другие браузеры) без графической оболочки мне удалось только в операционной системе Alpine Linux, пробовал еще на Ubuntu – там не получилось.
В общем, веб-интерфейс NameNode-ы и других утилит смотрим в браузере, запущенном внутри docker-контейнера «Hadoop-client», то есть из той же сети, что и остальные контейнеры Hadoop. Тут тоже оговорка: на хостовой машине необходимо не забыть запустить “xhost +” (или его вариации), разрешив подключения к сокету X11 извне.
Данная схема «проброса иксов» из хоста в контейнер снова накладывает ограничения: хостовая машина, на которой разворачивается Docker-compose, должна иметь графический интерфейс, что не всегда возможно. При дальнейшем развитии проекта контейнер «hadoop-client» был заменен на контейнер с Apache Knox-ом. У данного продукта как раз именно такое предназначение: предоставлять сервис проксирования доступов к продуктам Hadoop из некерберизованной среды. Однако исключать полностью Hadoop-clientиз проекта я тоже не стал (без предварительно запущенной команды «xhost …» данный контейнер просто перестает работать).
Вернемся к вопросу авторизации. При построении защищенной системы на основе Hadoop сейчас только он остался неохваченным. Полноценная авторизация в проекте сделана путем ввода дополнительного контейнера с упомянутым выше продуктом Apache Ranger. И так «на сцене» появился еще одна программа с лицензией ASF, продукт весьма молодой, на мой взгляд, пока еще не имеющей достаточной документации, в чем-то даже «сыроватый», однако аналогов у него нет, а значит для нас фактически незаменимый.
«Танцы с бубнами» вокруг Apache начинаются уже на этапе установки – она из себя представляет ни что иное, как клонирование активно разрабатываемого (преимущественно индусами) проекта с github.com и сборка maven-решений со всеми вытекающими последствиями (настройка среды, в которой осуществляется сборка, многочасовая выгрузка зависимостей, несколько «простыней» с сообщениями о ходе компиляции). Однако, не все так плохо (очень не документировано все правда): для сборки в проекта Ranger-a есть также Dockerfile (вернее shell-крипт для создания такого файла), который как раз загружает все необходимые зависимости в контейнер на базе CentOS (в другой ОС я, кстати, не смог собрать – постоянно были какие-то баг-и), компилирует все необходимые файлы, которые уже можно сохранять и использовать. В целом, Ranger представляет из себя чуть менее 30 плагинов, основными из которых, на мой взгляд, являются ranger-admin (непосредственно «админка»), ranger-usersync (для синхронизации групп и пользователей с LDAP-каталогом) и ranger-atlas (интеграция Ranger-a и Apache Atlas-а). Первые два из перечисленных в проекте разворачиваются и настраиваются должным образом, третий – оставлен как «путь в светлое будущее» проекта… Остальные из почти 30 плагинов, получаемых при компиляции проекта, в основном, отвечают за взаимодействие Ranger-a с другими продуктами: в представленном проекте используется ranger-hdfs-plugin, ranger-yarn-plugin и ranger-knox-plugin.
Сборка Ranger-a выполняется внутри контейнера «ranger-distrib», который фактически и есть упомянутый выше контейнер на основе CentOS c github-а Ranger-a. Данный контейнер примонтирует две директории: /.m2, в которую сохраняются все необходимые для сборки maven-зависимости (выкачивать их каждый раз при сборки Ranger-a – то еще удовольствие…); и собственно /ranger – директория в которой хранится клонированный с github-а проект Ranger,внутри которой сохранятся все скомпилированные плагины. Данный контейнер, в общем-то, не является необходимым для функционирования Hadoop, однако плагины должны быть собранными и храниться в директории /ranger/target (примонтированной к хостовой машине). Если они там есть, то скрипт, запускаемый при инициализации контейнера ranger-distrib, просто останавливает контейнер.
Итак, дистрибутив Ranger-a получен, далее можно собирать / запускать контейнер с самим Ranger-ом. В проекте это контейнер «hadoop-ranger», при инициализации которого сперва разворачивается плагин ranger-admin, а после ranger-usersync. Немного про установку plugin-ов… Она, помимо разархивации заключается фактически в установке необходимых параметров в файлах install.properties (у каждого плагина он свой), запуском необходимых в соответствии документации shell-скриптов установки и использованием плагина. Фактически между двумя последними пунктами – «пропасть». К сожалению, не все необходимые нам параметры настраиваются в install.properties - хоть в документации про это ничего и не говорится... Поэтому в скриптах проекта после развертывания plugin-ов дополнительно устанавливаются параметры в xml-файлы (созданные на основе все тех же install.properties), непосредственно используемые java-программами стека Hadoop. Я не хочу тут подробно рассказывать, все что дописывал «вручную» в файлах настройки, в приложенных в проект shell-скриптах я старался везде давать комментарий или ссылку на сайт, где сказано, что это «поможет». Тут же я хочу лишь описать концепцию, основные настройки Ranger-a, который, согласно заявленной цели, и является средством обеспечения информационной безопасности, однако сам же «из коробки» поставляется далеко не в самом защищенном исполнении. Далее я поясню это…
Как полноценное Java-приложение все свои настройки Ranger хранит в базе данных. По умолчанию в файле install.properties задано использование MySQL, развернутой на том же хосте, что и сам Ranger, соединение с СУБД – по незашифрованному каналу на основе login-а и password-а. С точки зрения ИБ, это снова не допустимо. В проекте я меняю это на использование упомянутого выше Postgres-а, развернутого на отдельном хосте, соединение с БД строго по «hostssl», на основе login-а и password-а с проверкой ключей шифрования канала (тут также используется тот самый CA-сертификат, сгенерированный на хосте ldap-сервера). Снова обращу внимание на то, что Ranger, кажется, еще пока проект весьма «молодой»: чтобы понять, куда надо «подсунуть» логин и пароль для соединения с БД, пришлось организовать отладку исходного кода Ranger-а путем добавления новых строк логирования.
В общем, первый «вагон», который тянет за собой Ranger в проекте – это контейнер cСУБД Postgres. Второй – контейнер с Apache Solr, используемый для хранения аудита. Его тоже пришлось капитально «донастраивать». На github-е Ranger-a есть скрипт «проливки» Solr-а, также не предусматривающий никаких средств защиты – это опять «не наш случай». Поднимаем контейнер, устанавливаем Solr – в проекте используется одиночно развернутый экземпляр программы на отдельном хосте, без использования ZooKeeper-а и SolrCloud. Еще до «проливки» схем Ranger-a внутри программы настраиваем использование протокола https, Kerberos-a для аутентификации и авторизации, повышаем уровень логирования – все есть в файлах конфигурации Solr-а проекта. Далее создание схемы (поставляется вместе с Ranger-ом), ну и запуск.
Последнее в настройке Ranger-а – это настройка его собственной защиты, а именно снова настройка ssl-сертификата (для использования https вместо http) и его керберизация – все это делается в скриптах конфигурации накануне запуска «ranger-admin start» и «ranger-usersync start». Везде старался давать комментарий в виде ссылки, где это подробно описано. Использование Kerberos-а в Ranger «тянется» из использования конфигурационных файлов Hadoop-а в проекте.
Помимо настройки административной части Ranger-а, идет развертывание его плагинов на NameNode-е и ResourceManager-е. Там тоже все по аналогии: install.properties, запуск скрипта установки, «тюнинг» xml-файлов, используемых Java-приложением. Самостоятельно ranger-hdfs-plugin и ranger-yarn-plugin не запускаются, при установке они патчат файлы запуска NameNode-ы и ResorceManager-а соответственно. Общая схема получается: установили – пропатчили – запустили. А далее plugin должен быть настроен в веб-интерфейсе административной части Ranger-а. В проекте это делается «вручную» (необходимо настроить самостоятельно после развертывания), RestAPI Ranger-а не используется.
Думаю, что уже на этом данный проект можно было бы свернуть: Hadoop внутри Docker-контейнеров развернут, сконфигурирован и достаточно защищен. В админ-ке Ranger-а видны «керберизованные» пользователи – principal-ы – с этим уже можно работать, разграничивая и логируя их доступы, пробуя и настраивая различные политики безопасности.
Однако данная схема не охватывает еще один аспект наиболее популярного направления использования программы Ranger. В корпоративном бизнесе, как правило Ranger без Apache Knox не устанавливается: если есть Ranger, значит и должны быть пользователи ldap, которые ходят в Hadoop без использования Kerberos, через Knox. Применительно к проекту, ранее я уже описал ограничения контейнера «Hadoop-client», используемого для доступа ко всем веб-интерфейсам программ.
В общем, следующий контейнер в проекте – это Hadoop-Knox. Его функционал уже представлен выше, тут лишь повторюсь, что он отвечает за проксирование доступа некерберизованных пользователей в систему, их аутентификацию через ldap-протокол, возможность SSO для всех сервисов Hadoop. Не хочу в «сотый раз» повторять, что Knox не просто «развернут» в проекте, но также настроен на безопасное использование (путем керберизации, настройки уровня логирования и связки с Solr для хранения аудита, который в дальнейшем поступает в Ranger). Скажу лишь, что в проекте с Knox получилось настроить проксирование всех сервисов Hadoop, но не получилось сконфигурировать SSO Ranger-а. Войти в «админ-ку» Ranger-а через аутентификацию в Knox-е мне так и не удалось, хотя сделал все необходимое согласно документации (в install.properties вставил корректную строку на API-ку предварительно настроенного сервера Knox, а также строку с открытым ключом Knox-а, полученную в Ranger-е снова через совместно используемую директорию хостовой машины).
Необходимо учесть, что использование SSO в Ranger-е накладывает и ряд ограничений. Дело в том, что аутентификация через Knox возможна только через использование логина и пароля пользователей ldap. А в Ranger-е сразу после установки права администратора имеет только «локальный» пользователь (настраивается в install.properties), кред-ы которого хранятся в СУБД Postgres. Соответственно, настройка в install.properties использования SSO Knox-a сразу выключает возможность локальной аутентификации в Ranger-е, а значит и использование установленного по умолчанию пользователя с правами администратора. Хотя все это конфигурируется через RestAPI Ranger-a (наделение правами администратора любого из пользователей ldap), в проекте пока этого нет. Порт 6182, на котором запущен Ranger admin, «прокидывается» на хостовую машину из Docker вместе с портом 8443 – портом веб-интерфейса Knox. Для доступа в веб-интерфейс Ranger-а достаточно пароля и логина администратора либо одного из пользователей ldap (без прав админ-а).
Еще про Knox необходимо сказать, что для того, чтобы проксирование в проекте работало «из коробки», я «комменчу» строку установки ranger-knox-plugin-а. Подключение ranger-plugin-а к Knox-у сразу же требует настройку соответствующих политик в Ranger-e, в том числе, относительно доступов через Knox. Это делается также "вручную" через веб-интерфейс Ranger-а либо через использование соответствующего RestAPI. После этого строку «# ranger_init && \» в Dockerfile можно разкомментировать.
Описав все выше перечисленные контейнеры, получили связку «Hadoop – Ranger – Knox», со всеми их «обвесами». Для построения системы Data Governance не хватает еще Apache Atlas-а, но, как я уже сказал, возможно, он где-то в «светлом будущем» этого проекта. Уже эта связка представляет достаточно интересный материал для тестирования систем безопасности, применения на практике политик администрирования. Но данная статья не про это. Данная статья про среду, ее создание, настраивание и развертывание. И в общем-то все это получилось. Запустив «docker compose up -d» со всеми предварительными настройками (загрузка дистрибутивов Hadoop, сборка Ranger-a, монтирование совместно-используемых папок), получаем желаемое.
И тут возникает новая проблема: на одной локальной машине мы запускаем несколько Docker- контейнеров, которые активно взаимодействуют между собой и тем самым расходуют все предоставленные docker-машине аппаратные ресурсы. Опытным путем выяснено, что компьютера на базе процессора Intel Core I7 (2012 г.в.) с 16 Гб оперативной памяти хватает на то, чтобы запустить все контейнеры, но далее при последующей работе компьютер начинает перегреваться, «взлетать» и «тормозить». Ввиду того, что это, в первую очередь, некорпоративный частный проект, варианты с обновлением «железа» не рассматриваются. А вот «горизонтальный» рост проекта, его расширение путем добавления еще одного компьютера – как раз то, что надо…
Расширить docker-compose путем запуска его на нескольких компьютерах возможно через использование средств оркестрации контейнеров. Разбираться с «могучим» Kubernates-ом мне совсем не хотелось, а вот дописать пару строк для запуска контейнеров в системе Docker swarm – это возможно. Оговорюсь, что ограничением использование технологии Docker Swarm является использование Docker Engine, а значит и Linux – подобной ОС на хостовых машинах(Docker Desktop на Windows / MacOS уже не подойдет).
Итак, для старта проекта имеем две и более машин с ОС Linux, находящихся в одной локальной сети. Далее выполняем «docker swarm init» - на manager-е, «docker swarm join» на worker-ах. Появление «роя» (docker swarm) уже позволяет создать внутри docker-compose сеть с драйвером overlay, вместо bridge, то есть сети docker, к которой могут подключать другие контейнеры извне - то, что нам и надо.
Для совместно используемых по сети директорий применяется технология NFS, поддерживаемая docker-ом. Создаем на одном из хостов директории, «расшариваем» их через /etc/exports (запускаем «exportfs -a»), в docker-compose файле v2 как раз настроено использование volumes c «type driver_opts» = «nfs» и указанной выше overlay-сети.
Далее в рамках проекта была осуществлена попытка запустить весь Hadoop в виде сервисов docker swarm – но данная попытка так и не удалась. Непреодолимым стало то, что при выполнении «docker stack deploy» каждому сервису, не смотря на директиву «hostname» в файле docker-compose первичное dns-имя выдается автоматически сгенерированное. Kerberos, в свою очередь, использует это имя для подстановки principal-ов (…@_HOST/HADOOPNET). Заставить docker swarm использовать в качестве первичного dns имя, указанное в директиве hostname, я так и не смог.
Решением данной проблемы, кажется, является использование стороннего DNS-сервера внутри роя docker-контейнеров. Есть даже готовые мануалы по настройке dns-сервера от программы Consul by HashiCorp внутри контейнеров. Однако в проекте я также это оставляю на «светлое будущее», пока же для заявленного выше «горизонтального» расширения Hadoop я использую ручной запуск нескольких файлов docker-compose на разных машинах. Разница данных файлов заключается в том, что в них перечислены только те, сервисы, которые должны быть запущены на конкретном хосте, ну и настройки сети разные. Overlay-сеть hadoopnet создается только на первой из машин, во всех последующих docker-compose файлах указывается «external: true». На практике мне удалось «разнести» таким образом проект на две машины. Для начальных нагрузок этого было достаточно.
Кажется, это все подходы и технологии, использованные внутри проекта, описаны. Повторюсь, что эта статья не про то, как использовать перечисленные здесь программы и технологии, а, в первую очередь, про их возможность развертывания внутри docker-контейнеров, запущенных на нескольких машинах, безопасную настройку, ну и среду для последующих экспериментов со всем этим.
