Меню

Настройка spark в локальной сети

Spark настройка для работы с ejabberd + настройка под себя

В данной статье мы рассмотрим настройку jabber клиента Spark Spark данный мессенджер был известен под названием Jive Communicator, он был разработан Jive Software. Позже, разработчики открыли код Spark и передали сообществу Ignite Realtime, наряду с Openfire, для дальнейшего совершенствования и развития. Данный мессенджер отличается следующими особенностями: Легкий графический интерфейс; Распространяется как СПО (Свободное Программное Обеспечение); […]

В данной статье мы рассмотрим настройку jabber клиента Spark

Spark данный мессенджер был известен под названием Jive Communicator, он был разработан Jive Software. Позже, разработчики открыли код Spark и передали сообществу Ignite Realtime, наряду с Openfire, для дальнейшего совершенствования и развития. Данный мессенджер отличается следующими особенностями:

Перед тем как приступить к настройке:

Скачать данный программный продукт можно на следующей странице:

Как можете видеть, мессенджер поддерживает кроме windows еще и GNU/Linux и MacOS. Однако, настройка в данной статье будет проводиться на ОС Windows 7, версия Spark 2.8.3. Выбираем подходящую нам платформу, разрядность, устанавливаем и запускаем. Установка этого приложения не должно вызвать каких-то проблем

Если вы все сделали правильно, то сейчас jabber-клиент должен был подтянуть группу «Support» с пользователями и вы можете начать общение с кем-то из них

Настройка под «себя»:

Spark это открытое ПО и никто нам не помешает его немного донастроить под свои нужды.

Для начала найдите в каталоге, в которой вы установили программу файл sprk.jar (По умолчанию C:/Program Files/Spark/lib/spark.jar ). Открыть можно любым архиватором (7zip, winrar и.т.д), далее любым текстовым редактором открываем «spark.jar/org/jivesoftware/resource/default.properties»

Окно входа:

Прокси:

Содержать в себе настройки Proxy. Доступные протоколы HTTP и SOCKS. При заполнении пунктов будьте внимательны т.к они чувствительные к регистру.

Работа с файлами:

Контакты:

Пароль:

Руководство и помощь:

Доступные плагины:

Цвета и Внешний вид:

DEFAULT_LOOK_AND_FEEL = изменение внешнего вида, по-умолчанию имеет значение SubstanceBusinessBlueSteelLookAndFeel

Источник

Тонкая настройка IM-клиента Spark

Мы у себя в сети несколько лет успешно и стабильно используем связку OpenFire + Spark с 200 активными пользователями (с учетом удаленных подключений). IM-клиент Spark принят в качестве корпоративного стандарта для системы мгновенного обмена сообщениями. Не вдаваясь в причины выбора, хочу поделится тонкостями его настройки для конечного пользователя. Процесс будет описан на примере установленного пакета Spark 2.7.0 для ОС Windows 7.

В установленном каталоге находим файл spark.jar (C:/Program Files/Spark/lib/spark.jar), открываем его любым архиватором (IzArc), далее любым текстовым редактором (Notepad++) открываем файл «spark.jar/org/jivesoftware/resource/default.properties». Необходимо учесть, что файл «spark.jar» перезаписывается после каждой переустановки или обновлении IM-клиента Spark, поэтому его необходимо снова заменить (при переустановке) или сделать новый (в случае смены версии) на компьютерах всех своих пользователей. Итак, приступим…

Раздел «Окно приглашения»

# изменения стартового изображения и название приложения
# размер изображения должен быть 244х188 пикселя
MAIN_IMAGE = images/spark.gif
APPLICATION_NAME = Spark

# указываем фиксированное имя сервера
HOST_NAME = SRV5-VM1

# установка значения «true» запретит пользователям изменить имя сервера
HOST_NAME_CHANGE_DISABLED = true

# настройки Proxy, доступные протоколы HTTP или SOCKS, чувствительны к регистру.
PROXY_PROTOCOL = SOCKS
PROXY_HOST = myProxy.ru
PROXY_PORT = 8080

# удаление кнопки создания учетной записи с формы загрузки
# пользователи не смогут создавать новый учетные записи в Spark
ACCOUNT_DISABLED = true

# удаление кнопки дополнительных настроек с формы загрузки
# пользователи не будут иметь доступ к дополнительным настройкам
ADVANCED_DISABLED = true

# добавление логотипа компании, он будет отображается в правом верхнем углу основного окна
# изображение должно быть размещено в папке src/resource/images, путь должен быть «images/file.jpg» или «images/file.png»
BRANDED_IMAGE = images/our-logo.png

# можно отключить возможность обновления
DISABLE_UPDATES = true

# отключаем возможность закрытия Spark
DISABLE_EXIT = true

Раздел «Передача файлов»

# определяем максимальный размер файла, который пользователь может отправить
FILE_TRANSFER_MAXIMUM_SIZE = 20971520

Раздел «Settings Window»

# отключаем возможность добавления контактов в Spark
ADD_CONTACT_DISABLED = true

# отключаем возможность добавления групп в Spark
ADD_CONTACT_GROUP_DISABLED = true

# запретить пользователю менять пароль
CHANGE_PASSWORD_DISABLED = true

# расположение руководства пользователя, по-умолчанию www.igniterealtime.org/builds/spark/docs/spark_user_guide.pdf
HELP_USER_GUIDE = ссылка на руководство пользователя на корпоративном сайте

# отображать меню руководства пользователя или нет
HELP_USER_GUIDE_DISABLED =

# расположение форума помощи, по-умолчанию www.igniterealtime.org/forum/forum.jspa?forumID=49
HELP_FORUM = ссылка на форум помощи на корпоративном сайте

# отображать меню форума помощи или нет
HELP_FORUM_DISABLED =

# следующий текст будет отображаться вместо «Spark forum»
# если оставить пустым, значение будет по-умолчанию
HELP_FORUM_TEXT =

# отключение возможности установки плагинов
INSTALL_PLUGINS_DISABLED = true
# отключение возможности удаления плагинов
DEINSTALL_PLUGINS_DISABLED = true

# для того чтобы сделать плагин(ы) недоступным(и), укажите названия через запятую, написание чувствительно к регистру.
# названия плагинов можно найти в файле «plugin.xml»
# например: Fastpath,Jingle Client,Phone Client,Window Flashing Plugin
# значение по-умолчанию пустое
PLUGIN_BLACKLIST = Fastpath

Читайте также:  Настройка индикатора скользящие средние

# для того чтобы сделать плагин(ы) недоступным(и) с помощью классов, укажите их названия через запятую, написание чувствительно к регистру.
# например: org.jivesoftware.fastpath.FastpathPlugin
# значение по-умолчанию пустое
PLUGIN_BLACKLIST_CLASS = org.jivesoftware.spark.translator.TranslatorPlugin

Два последних пункта полностью сделают недоступным все плагины с именем Fastpath и все плагины с org.jivesoftware.spark.translator.TranslatorPlugin.

Раздел «Цвета и Внешний вид»

# по-умолчанию, сервер рассылок получает свой собственный JFrame, который содержит сообщение
# при этом могут использоваться HTML-тэги для жирного, наклонного или подчеркнутого текста
# если вы хотите чтобы сообщения рассылки выглядели как остальные сообщения, установите значение «true»
BROADCAST_IN_CHATWINDOW = true

# сделать недоступным изменение внешнего вида
# изменить настройки внешнего вида можно в «Настройки»->«Внешний вид»
LOOK_AND_FEEL_DISABLED = true

# сделать недоступным изменение цветов
# изменить настройки цветов можно в «Настройки»->«Внешний вид»->«Цвета»
CHANGE_COLORS_DISABLED = true

# изменение внешнего вида, по-умолчанию внешний вид SubstanceBusinessBlueSteelLookAndFeel
DEFAULT_LOOK_AND_FEEL = com.jtattoo.plaf.luna.LunaLookAndFeel

# установка текста выпадающего меню, работает только при установке внешних видов JTattoo
MENUBAR_TEXT = «Название компании»

Источник

Запускаем Apache Spark на Kubernetes

Дорогие читатели, доброго дня. Сегодня поговорим немного про Apache Spark и его перспективы развития.

В современном мире Big Data Apache Spark является де факто стандартом при разработке задач пакетной обработки данных. Помимо этого, он также используется для создания стриминговых приложений, работающих в концепции micro batch, обрабатывающих и отгружающих данные маленькими порциями (Spark Structured Streaming). И традиционно он являлся частью общего стека Hadoop, используя в качестве менеджера ресурсов YARN (или, в некоторых случаях, Apache Mesos). К 2020 году его использование в традиционном виде для большинства компаний находится под большим вопросом в виду отсутствия приличных дистрибутивов Hadoop — развитие HDP и CDH остановлено, CDH недостаточно проработан и имеет высокую стоимость, а остальные поставщики Hadoop либо прекратили своё существование, либо имеют туманное будущее. Поэтому всё больший интерес у сообщества и крупных компаний вызывает запуск Apache Spark с помощью Kubernetes — став стандартом в оркестрации контейнеров и управлении ресурсами в приватных и публичных облаках, он решает проблему с неудобным планированием ресурсов задач Spark на YARN и предоставляет стабильно развивающуюся платформу с множеством коммерческих и открытых дистрибутивов для компаний всех размеров и мастей. К тому же на волне популярности большинство уже успело обзавестись парой-тройкой своих инсталляций и нарастить экспертизу в его использовании, что упрощает переезд.

Начиная с версии 2.3.0 Apache Spark обзавёлся официальной поддержкой запуска задач в кластере Kubernetes и сегодня, мы поговорим о текущей зрелости данного подхода, различных вариантах его использования и подводных камнях, с которыми предстоит столкнуться при внедрении.

Прежде всего, рассмотрим процесс разработки задач и приложений на базе Apache Spark и выделим типовые случаи, в которых требуется запустить задачу на кластере Kubernetes. При подготовке данного поста в качестве дистрибутива используется OpenShift и будут приведены команды, актуальные для его утилиты командной строки (oc). Для других дистрибутивов Kubernetes могут быть использованы соответствующие команды стандартной утилиты командной строки Kubernetes (kubectl) либо их аналоги (например, для oc adm policy).

Первый вариант использования — spark-submit

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


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

Расскажем подробнее о процессе настройки Spark для локального запуска. Чтобы начать пользоваться Spark его требуется установить:

Собираем необходимые пакеты для работы с Kubernetes:

Полная сборка занимает много времени, а для создания образов Docker и их запуска на кластере Kubernetes в реальности нужны только jar файлы из директории «assembly/», поэтому можно собрать только данный подпроект:

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

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

С её помощью собираем базовый образ Spark, содержащий в себе тестовую задачу для вычисления числа Pi с помощью Spark (здесь — URL вашего реестра образов Docker, — имя репозитория внутри реестра, совпадающее с проектом в OpenShift, — имя образа (если используется трёхуровневое разделение образов, например, как в интегрированном реестре образов Red Hat OpenShift), — тег данной версии образа):

Читайте также:  Настройка и регулировка карбюратора бензокосы

Авторизуемся в кластере OKD с помощью консольной утилиты (здесь — URL API кластера OKD):

Получим токен текущего пользователя для авторизации в Docker Registry:

Авторизуемся во внутреннем Docker Registry кластера OKD (в качестве пароля используем токен, полученный с помощью предыдущей команды):

Загрузим собранный образ Docker в Docker Registry OKD:

Проверим, что собранный образ доступен в OKD. Для этого откроем в браузере URL со списком образов соответствующего проекта (здесь — имя проекта внутри кластера OpenShift, — URL Web консоли OpenShift) — https:///console/project//browse/images/.

Для запуска задач должен быть создан сервисный аккаунт с привилегиями запуска подов под root (в дальнейшем обсудим этот момент):

Выполним команду spark-submit для публикации задачи Spark в кластере OKD, указав созданный сервисный аккаунт и образ Docker:

—name — имя задачи, которое будет участвовать в формировании имени подов Kubernetes;

—class — класс исполняемого файла, вызываемый при запуске задачи;

—conf — конфигурационные параметры Spark;

spark.executor.instances — количество запускаемых экзекьюторов Spark;

spark.kubernetes.authenticate.driver.serviceAccountName — имя служебной учётной записи Kubernetes, используемой при запуске подов (для определения контекста безопасности и возможностей при взаимодействии с API Kubernetes);

spark.kubernetes.namespace — пространство имён Kubernetes, в котором будут запускаться поды драйвера и экзекьютеров;

spark.submit.deployMode — способ запуска Spark (для стандартного spark-submit используется «cluster», для Spark Operator и более поздних версий Spark «client»);

spark.kubernetes.container.image — образ Docker, используемый для запуска подов;

spark.master — URL API Kubernetes (указывается внешний так обращение происходит с локальной машины);

local:// — путь до исполняемого файла Spark внутри образа Docker.

Переходим в соответствующий проект OKD и изучаем созданные поды — https:///console/project//browse/pods.

Для упрощения процесса разработки может быть использован ещё один вариант, при котором создаётся общий базовый образ Spark, используемый всеми задачами для запуска, а снэпшоты исполняемых файлов публикуются во внешнее хранилище (например, Hadoop) и указываются при вызове spark-submit в виде ссылки. В этом случае можно запускать различные версии задач Spark без пересборки образов Docker, используя для публикации образов, например, WebHDFS. Отправляем запрос на создание файла (здесь — хост сервиса WebHDFS, — порт сервиса WebHDFS, — желаемый путь к файлу на HDFS):

При этом будет получен ответ вида (здесь — это URL, который нужно использовать для загрузки файла):

Загружаем исполняемый файл Spark в HDFS (здесь — путь к исполняемому файлу Spark на текущем хосте):

После этого можем делать spark-submit с использованием файла Spark, загруженного на HDFS (здесь — имя класса, который требуется запустить для выполнения задачи):

При этом надо заметить, что для доступа к HDFS и обеспечения работы задачи может потребоваться изменить Dockerfile и скрипт entrypoint.sh — добавить в Dockerfile директиву для копирования зависимых библиотек в директорию /opt/spark/jars и включить файл конфигурации HDFS в SPARK_CLASSPATH в entrypoint.sh.

Второй вариант использования — Apache Livy

Далее, когда задача разработана и требуется протестировать полученный результат, возникает вопрос её запуска в рамках процесса CI/CD и отслеживания статусов её выполнения. Конечно, можно запускать её и с помощью локального вызова spark-submit, но это усложняет инфраструктуру CI/CD поскольку требует установку и конфигурацию Spark на агентах/раннерах CI сервера и настройки доступа к API Kubernetes. Для данного случая целевой реализацией выбрано использование Apache Livy в качестве REST API для запуска задач Spark, размещённого внутри кластера Kubernetes. С его помощью можно запускать задачи Spark на кластере Kubernetes используя обычные cURL запросы, что легко реализуемо на базе любого CI решения, а его размещение внутри кластера Kubernetes решает вопрос аутентификации при взаимодействии с API Kubernetes.

Выделим его в качестве второго варианта использования — запуск задач Spark в рамках процесса CI/CD на кластере Kubernetes в тестовом контуре.

Немного про Apache Livy — он работает как HTTP сервер, предоставляющий Web интерфейс и RESTful API, позволяющий удалённо запустить spark-submit, передав необходимые параметры. Традиционно он поставлялся в составе дистрибутива HDP, но также может быть развёрнут в OKD или любой другой инсталляции Kubernetes с помощью соответствующего манифеста и набора образов Docker, например, этого — github.com/ttauveron/k8s-big-data-experiments/tree/master/livy-spark-2.3. Для нашего случая был собран аналогичный образ Docker, включающий в себя Spark версии 2.4.5 из следующего Dockerfile:

Созданный образ может быть собран и загружен в имеющийся у вас репозиторий Docker, например, внутренний репозиторий OKD. Для его развёртывания используется следующий манифест ( — URL реестра образов Docker, — имя образа Docker, — тег образа Docker, — желаемый URL, по которому будет доступен сервер Livy; манифест «Route» применяется в случае, если в качестве дистрибутива Kubernetes используется Red Hat OpenShift, в противном случае используется соответствующий манифест Ingress или Service типа NodePort):

Читайте также:  Как сделать заводские настройки на планшете oysters

После его применения и успешного запуска пода графический интерфейс Livy доступен по ссылке: http:///ui. С помощью Livy мы можем опубликовать нашу задачу Spark, используя REST запрос, например, из Postman. Пример коллекции с запросами представлен ниже (в массиве «args» могут быть переданы конфигурационные аргументы с переменными, необходимыми для работы запускаемой задачи):

Выполним первый запрос из коллекции, перейдём в интерфейс OKD и проверим, что задача успешно запущена — https:///console/project//browse/pods. При этом в интерфейсе Livy (http:///ui) появится сессия, в рамках которой с помощью API Livy или графического интерфейса можно отслеживать ход выполнения задачи и изучать логи сессии.

Теперь покажем механизм работы Livy. Для этого изучим журналы контейнера Livy внутри пода с сервером Livy — https:///console/project//browse/pods/?tab=logs. Из них видно, что при вызове REST API Livy в контейнере с именем «livy» выполняется spark-submit, аналогичный используемому нами выше (здесь — имя созданного пода с сервером Livy). В коллекции также представлен второй запрос, позволяющий запускать задачи с удалённым размещением исполняемого файла Spark с помощью сервера Livy.

Третий вариант использования — Spark Operator

Теперь, когда задача протестирована, встаёт вопрос её регулярного запуска. Нативным способом для регулярного запуска задач в кластере Kubernetes является сущность CronJob и можно использовать её, но в данный момент большую популярность имеет использование операторов для управления приложениями в Kubernetes и для Spark существует достаточно зрелый оператор, который, в том числе, используется в решениях Enterprise уровня (например, Lightbend FastData Platform). Мы рекомендуем использовать его — текущая стабильная версия Spark (2.4.5) имеет достаточно ограниченные возможности по конфигурации запуска задач Spark в Kubernetes, при этом в следующей мажорной версии (3.0.0) заявлена полноценная поддержка Kubernetes, но дата её выхода остаётся неизвестной. Spark Operator компенсирует этот недостаток, добавляя важные параметры конфигурации (например, монтирование ConfigMap с конфигурацией доступа к Hadoop в поды Spark) и возможность регулярного запуска задачи по расписанию.


Выделим его в качестве третьего варианта использования — регулярный запуск задач Spark на кластере Kubernetes в продуктивном контуре.

Spark Operator имеет открытый исходный код и разрабатывается в рамках Google Cloud Platform — github.com/GoogleCloudPlatform/spark-on-k8s-operator. Его установка может быть произведена 3 способами:

Если оператор установлен корректно, то в соответствующем проекте появится активный под с оператором Spark (например, cloudflow-fdp-sparkoperator в пространстве Cloudflow для установки Cloudflow) и появится соответствующий тип ресурсов Kubernetes с именем «sparkapplications». Изучить имеющиеся приложений Spark можно следующей командой:

Для запуска задач с помощью Spark Operator требуется сделать 3 вещи:

В данном манифесте указана сервисная учётная запись, для которой требуется до публикации манифеста создать необходимые привязки ролей, предоставляющие необходимые права доступа для взаимодействия приложения Spark с API Kubernetes (если нужно). В нашем случае приложению нужны права на создание Pod’ов. Создадим необходимую привязку роли:

Также стоит отметить, что в спецификации данного манифеста может быть указан параметр «hadoopConfigMap», который позволяет указать ConfigMap с конфигурацией Hadoop без необходимости предварительного помещения соответствующего файла в образ Docker. Также он подходит для регулярного запуска задач — с помощью параметра «schedule» может быть указано расписание запуска данной задачи.

После этого сохраняем наш манифест в файл spark-pi.yaml и применяем его к нашему кластеру Kubernetes:

При этом создастся объект типа «sparkapplications»:

При этом будет создан под с приложением, статус которого будет отображаться в созданном «sparkapplications». Его можно посмотреть следующей командой:

По завершении задачи POD перейдёт в статус «Completed», который также обновится в «sparkapplications». Логи приложения можно посмотреть в браузере или с помощью следующей команды (здесь — имя пода запущенной задачи):

Также управление задачами Spark может быть осуществлено с помощью специализированной утилиты sparkctl. Для её установки клонируем репозиторий с её исходным кодом, установим Go и соберём данную утилиту:

Изучим список запущенных задач Spark:

Создадим описание для задачи Spark:

Запустим описанную задачу с помощью sparkctl:

Изучим список запущенных задач Spark:

Изучим список событий запущенной задачи Spark:

Изучим статус запущенной задачи Spark:

В заключение хотелось бы рассмотреть обнаруженные минусы эксплуатации текущей стабильной версии Spark (2.4.5) в Kubernetes:

Источник

Adblock
detector