Category: Uncategorized

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

Начавшись как исследовательский проект в одной из лабораторий университета Калифорнии в Беркли, Mesos был впервые представлен в 2009 году под именем Nexus. Некоторое время проект находился в ранге исследовательских, а версия «1» была выпущена только в 2016 году под крылом Apache Software Foundation.

Впрочем, к этому времени Apache Mesos уже использовался в Twitter, Airbnb, eBay и даже в сервисе Apple Siri. Однако, несмотря на таких серьезных пользователей, открытость и покровительство Apache, обзоров Mesos в сети в настоящее время не так уж и много. И пользователей, судя по всему, тоже. Тем не менее Apache Mesos заслуживает внимания не только ради расширения кругозора, но и с целью практического применения благодаря стабильной работе и относительной простоте развертывания и настройки.

В данной статье мы рассмотрим процесс создания кластера Mesos на машинах под управлением Virtuozzo Linux и его интеграцию с фреймворком Jenkins с целью динамического создания контейнеров для выполнения задач непрерывной интеграции.

Распределенная природа дает Apache Mesos ряд принципиально новых возможностей — например, способность переживать потерю части «железных» ресурсов с сохранением всех работающих процессов

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

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

Сервисные машины-узлы (slaves) предоставляют мощности для выполнения задач. Задачи выполняются в отдельных контейнерах – поддерживается как Docker, так и собственная контейнеризация Mesos, также основанная на штатных механизмах Linux (cgroups).

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

Наиболее известными являются:

• Marathon, предназначенный для одноразового запуска задач (например, тех или иных сервисов, которые должны работать без перебоев), – этот фреймворк часто рассматривают в статьях про Mesos;
• Chronos – служит для запуска задач по расписанию, поддерживает зависимости между разными задачами;
• Aurora – разработка Twitter, выпущенная под открытой лицензией в 2013 году. Подходит как для запуска сервисов, которые должны работать непрерывно, так и для выполнения задач по расписанию. Однако по признанию самих разработчиков этот фреймворк отнюдь не прост в развертывании и обслуживании (неудивительно, что большинство обзоров Mesos рассматривают Marathon, а не Aurora), хотя и обладает отличной масштабируемостью.

Mesos обеспечивает не только стабильную работу сервисов, но и плавное обновление компонентов кластера

В виде фреймворков реализован плагин для Jenkins, позволяющий запускать машины-узлы Jenkins (Jenkins slaves) на кластере Mesos. При этом осуществляется динамический мониторинг количества запущенных машин, при необходимости добавляются новые, а при длительном простое удаляются излишние. Аналогичным образом реализованы плагины для Hadoop, Apache Spark и Apache Torque.

Рассмотрим использование Mesos совместно с Jenkins, основанное на опыте работы с этой комбинацией. Но для начала давайте создадим кластер Mesos. В нашем примере кластер будет состоять из трех мастер-серверов с адресами 10.0.3.2, 10.0.3.3 и 10.0.3.4 и одного вычислительного узла (slave) с адресом 10.0.3.5.

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

Установка master-сервера

В данной статье мы будем устанавливать все компоненты Mesos на машины под управлением Virtuozzo Linux 7. Все инструкции могут быть без изменения использованы для машин под управлением CentOS 7 и ее производных.

Для развертывания мастер-серверов на каждом из них необходимо добавить RPM-репозитории Mesos:

и установить соответствующие пакеты:

Для идентификации в ZooKeeper каждому мастеру (ниже мы будем в качестве примера использовать 10.0.3.4) надо вручную выбрать и прописать уникальный числовой идентификатор в диапазоне от 1 до 255:

явно прописать IP-адрес, по которому он будут доступен:

и имя машины (hostname). Если разрешимого через DNS имени у машины нет, в этот файл надо также прописать IP-адрес, пустовать он не должен:

В отдельном файле настроек Mesos необходимо указать адреса всех мастер-нод:

(2181 – это порт, который по умолчанию слушает ZooKeeper).

Для самого ZooKeeper необходимо в файл /etc/zookeeper/ conf/zoo.cfg добавить адреса мастер-нод в следующем виде:

Здесь 1, 2,3 – не порядковые номера, а идентификаторы, которые указаны в файле /var/lib/zookeeper/myid каждого сервера.

Порт 2888 используется для взаимодействия с активным мастером, 3888 – для выбора нового мастера при необходимости.

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

Поэтому минимальна конфигурация кластера Mesos при условии, что вы заботитесь о его отказоустойчивости -это три мастер-сервера и значение кворума, равное двум. Такая конфигурация позволяет пережить потерю одного мастера. Достаточно типичной является конфигурация 5:3, при которой можно потерять два узла из пяти (напомним, что исходя из схожих соображений выбираются рекомендуемые настройки Virtuozzo Storage).

Значение кворума указывается в отдельном файле настроек:

В завершение отключаем сервис mesos-slave и рестарту-ем mesos и zookeeper (при установке пакетов все эти сервисы добавляются в набор загружаемых при старте системы, но не стартуют сразу ввиду отсутствия конфигурации):

После установки веб-интерфейс Mesos будет доступен по адресу любого из мастеров на порту 5050.

По нашему опыту этот веб-интерфейс Apache Mesos удобно использовать для мониторинга происходящих в кластере событий (особенно если что-то пошло не так; впрочем, в таких случаях иногда полезнее посмотреть в журналы в директории /var/log/mesos на мастер-узлах либо на вычислительном узле, где произошла ошибка). Управлять же кластером особой необходимости не возникает; настройка и контроль реальных задач осуществляется в используемом у вас фреймворке (например, Marathon имеет свой веб-интерфейс, а конфигурация плагина Jenkins осуществляется в самом Jenkins).

Установка Slave

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

Из этих репозиториев достаточно установить пакет Mesos:

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

Аналогично мастер-нодам необходимо для каждой машины прописать IP-адрес и имя машины:

Если на данной машине установлен только slave, то надо отключить запуск сервиса mesos-master

Все мастер-серверы необходимо указать в /etc/mesos/zk

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

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

Например, плагин Jenkins по-прежнему создает Mesos-контейнеры, а вот Marathon (входящий в официальные репозитории Mesos) использует Docker. Несмотря на последний факт, по умолчанию Docker-контейнеризация на вычислительных узлах недоступна, требуется выполнить ряд действий, чтобы ее включить.

Во-первых, необходимо установить сам Docker:

А затем добавить его в список доступных типов контейнеризации:

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

Наконец запустим сервис mesos-slave:

Если все прошло успешно, новый сервисный узел появится на вкладке Agents в веб-интерфейсе Mesos.

Использование Apache Mesos совместно с Jenkins

В данной статье мы рассмотрим настройку Jenkins на использование Mesos для размещения вычислительных узлов (Jenkins slaves). Данный функционал реализован с помощью плагина mesos, однако перед его установкой в Jenkins необходимо выполнить ряд подготовительных действий (не считая развертывания самого Jenkins – далее мы предполагаем, что он уже установлен и работает на машине, не входящей в кластер Mesos).

Во-первых, на каждой машине с Mesos slave необходимо завести пользователя с именем jenkins, установить java (мы использовали стандартный пакет java-1.8.O-openjdk из репозиториев Virtuozzo Linux) и прописать экспорт переменной JAVA_HOME в профиль пользователя.

Выполним настройку Jenkins на использование Mesos для размещения вычислительных узлов (Jenkins slaves)

На сервер Jenkins необходимо добавить библиотеку libmesos для взаимодействия с кластером. В нашей конфигурации Jenkins также работает на машине с Virtuozzo Linux, поэтому взять библиотеку можно из RPM-пакета mesos либо непосредственно с одной из машин Mesos-кластера – она располагается в директории /usr/lib. имя ее начинается на libmesos (например, libmesos-1.5.0.SO). Обратите внимание, что в этой директории также есть файл /usr/lib/libmesos.so, но он является символьной ссылкой на реальную библиотеку.

Положить файл с библиотекой необходимо на сервер Jenkins в любое место, доступное фреймворку, – например, в /usr/local/lib/. Путь к ней необходимо будет указать при настройке плагина.

Теперь можно идти в веб-интерфейс Jenkins и искать плагин mesos в списке секции Manage Plugins. Вместе с ним необходимо установить плагин metrics – хотя он и отмечен в документации как опциональный, без него в нашем Jenkins плагин mesos работать отказался, попытка его использовать приводила к генерации исключения Java.

После установки плагинов переходим в секцию настроек Jenkins (Configure). Внизу этой секции у вас должна появиться кнопка Add a new cloud, при нажатии на которую в качестве одного из вариантов должна быть доступна опция Mesos cloud.

При ее выборе обязательно надо указать путь к библиотеке mesos на сервере Jenkins (параметре Mesos native library path), URL самого Jenkins, а также адреса мастер-узлов Mesos. В последнем поле можно указать адрес конкретного мастера, а можно сразу ссылку Zookeer (zkJ/10.0.3.4: 2181,10.0.3.3:2181,10.0.32:2181/mesos).

Тут же можно нажать кнопку Test connection для проверки соединения с кластером.

Обратите внимание, что если вы указали адрес в формате ZooKeeper, то сначала необходимо нажать кнопку Save

В расширенных (Advanced) настройках можно указать, следует ли создавать контейнеры в кластере по мере необходимости (On-demand framework registration) либо вы будете создавать их вручную. Нам интересен вариант, когда контейнеры создаются автоматически – если на Jenkins будет запущено слишком много задач и им не станет хватать машин для выполнения, автоматически будет создан новый контейнер в кластере Mesos (естественно при наличии ресурсов).

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

При желании можно указать метку (Label), которая будет присваиваться всем вычислительным узлам Jenkins, создаваемым в кластере Mesos. Это позволит вам регулировать, какие задачи можно запускать на таких узлах, а какие – нет.

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

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

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

Проверить, как ведет себя связка Jenkins и Mesos, достаточно легко – просто запустите несколько «долгих» задач, общее количество которых будет превышать число имеющихся у вас в данный момент узлов Jenkins. При этом помните, что плагин mesos создает новый контейнер не сразу по мере появления новых нераспределенных задач в очереди, а только если узлов для выполнения задач не хватает уже в течение нескольких минут.

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

Заключение

С точки зрения производительности и отказоустойчивости Apache Mesos показывает вполне достойные характеристики и по праву считается конкурентом Kubernetes и Docker Swarm.

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

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

Также можно отметить более гибкий подход Kubernetes к обеспечению устойчивости кластера к исчезновению мастер-узлов.

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

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

За квалифицированной помощью по администрированию серверов или экспертной консультацией обращайтесь сюда.

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

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

Избыточность, и как ее достичь

Единственный способ избежать отказа системы – избавиться от “единых” точек отказа” (SPOF). Практика управления инфраструктурами всех уровней и масштабов доказывает, что избыточность – единственный путь к такому решению, поскольку обеспечивает резервирование абсолютно всех компонентов. Логично, ведь вероятность одновременного сбоя 2-х серверов намного меньше, чем одного.

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

Какие подходы практикуются для резервирования веб-компонентов:

1. Дублирование NS-записей.
2. Резервирование фронтендов.
3. Оптимизация числа бекендов.
4. Резервирование баз данных.

Дублирование NS-записей

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

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

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

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

Резервирование фронтендов

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

Автоматизация отслеживания состояний и переключения IP-адреса позволит ежесекундно опрашивать основной ресурс и выявлять степень корректности его действий (так называемый heartbeat). При отсутствии корректной реакции, IP-адрес делегируется фронтенду.

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

Оптимизация числа бекендов

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

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

Назначение нескольких серверов с целью обработки fastcgi-запросов при помощи upstream происходит с участием Nginx. Распределение запросов между серверами производится в автоматическом режиме.

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

Резервирование баз данных

Эта задача считается наиболее сложной в рамках повышения отказоустойчивости сети. Обычно для этого применяется репликация, в ходе которой выделяется главный сервер для БД (Мастер), отвечающий за модификацию данных. Вспомогательный сервер (Слейв) копирует все изменения, которые происходят на мастер-сервере и отвечает за их чтение.
Основной особенностью таких реплик является работа в пассивном режиме, без обработки запросов от приложений. Задача реплики – хранение актуальной копии БД с Мастера.

Преимуществом подхода является удобная автоматизация процессов отслеживания состояния БД. Если обнаруживается ошибка, приложение автоматически изменяет настройки и “подключает” к работе сервер-репликант.

Восстановление вышедшего из строя сервера происходит следующим образом:

1. Сервер отключается.
2. Производится восстановление на физическом уровне.
3. Проводится настройка и синхронизация реплики с дублирующего сервера.
4. В приложении прописывается конфигурация рабочего дубль-сервера.

Слейв-сервер настраивается с Мастер-сервера при участии утилиты Xtrabackup.
Затем бывший Слейв переходит в статус Мастера, а восстановленный сервер превращается в резервный (Слейв).

Дельный совет

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

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

Для вас мы можем быстро и с гарантией повысить отказоустойчивость ИТ инфраструктуры. Свяжитесь с нами.

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

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

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

Метод параллельной разработки

Команда программистов должна оптимизировать затраты времени и сил с помощью параллельной разработки за счет метода Continuous Integration (CI). Это также позволит автоматически осуществлять сборку проекта и тестировать его на ранних стадиях.

Дополнительные задачи:

1. Ускорение сборки: инкрементальная компиляция позволит ускорить процесс сборки за счет анализа отдельно выделенных кусков кода, которые только что подверглись изменениям. Дальнейший анализ проводится на автоматической основе.
2. Разделение «веток»: как только завершается работа над модернизацией крупного участка кода, программист тестирует его в отдельной среде и только после положительных тестов добавляет его в основную «ветку».
3. Автоматизация: все базовые проверки и анализ ошибок должны проходить автоматизировано с максимальным ускорением процесса.
4. Тестирование: проверка на работоспособность осуществляется многоуровневыми тестами, начиная от интеграционного, заканчивая сценарным.

Процесс автоматической сборки должен происходить 2-3 раза за сутки, а полный процесс и без того займет целый день. Потому, нужно использовать максимально ускоренный режим, анализирующий 80% основной части. Этого достаточно для полного понимания картины и займет всего 1 час времени.

Инструменты для комплексной автоматизации 1с предприятие

Крайне полезным будет использование ПО Jenkins, которое может быстро и эффективно осуществлять сборку проекта на различных ОС одновременно. Это значительно сокращает затраты времени. Ещё одним полезным решением является интеграция JMeter от Apache. Это ПО способно тестировать отдельные участки приложений без задействования крупных ресурсов сервера.

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

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

Погрешность конечных результатов составляет максимум 1.5%. А эмуляция процесса происходит в двух разных режимах: один позволяет имитировать работу 1000 клиентов, что более приближено к реалиям, а второй – всего 100 клиентов, но в сильно ускоренном режиме, представляя из себя подобие стресс-теста.

Первый вариант тестирования следующий: если считать, что нам нужно смоделировать работу 10000 пользователей, то нужно задействовать два основных сервера 1С.

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

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

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

СПК: Сравнение Производительности Конфигураций

Помимо Тест-Центра, мы используем собственное ПО – «Сравнение Производительности Конфигураций» или «СПК». С помощью этого инструмента мы можем сравнить работоспособность отдельных элементов приложения.

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

Очень важно отмечать не только негативные факторы, но и положительные изменения. Так можно лучше понять, что именно влияет на работоспособность системы. Как и в случае с Тест-Центром, мы используем СПК для составления подробных отчетов и сравнения результатов в разные отрезки.

Пользовательское тестирование

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

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

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

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

Функциональное тестирование

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

Ещё немаловажно учесть параллельно работающие программы на ПК, задействованные ОС и подключенные БД сервера. Таким образом, у команды будет возможность протестировать каждый возможный вариант работы 1с в различных условиях.

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

Дополнительные инструменты для тестирования

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

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

Второе – это инструмент для тайм-трекинга команды разработчиков.

Бета-тест и тестирование прикладных решений

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

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

Специалисты нашей компании реализуют для вас автоматизацию 1с предприятие максимально безболезненно и быстро. Обращайтесь.

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

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

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

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

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

Дополнительная задача – настройка внутренней IP-телефонии, которая будет работать вне зависимости от наличия Интернета. И мелкой доработкой стало налаживание Ethernet-подключения поверх IP.

Варианты исполнения поставленных задач

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

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

Описание инфраструктуры

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

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

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

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

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

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

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

Реализация плана безопасности выглядела следующим образом:

В левой части обозначены наиболее важные зоны – внутренняя служба и кассово-платежная часть. Что касается реализации безопасности для Cash-зоны, то тут была необходима жесткая настройка с узкими правами для каждого отдельно участка. Остальные зоны выделены в «Inside».

Все они получили собственный VLAN. Ранее, никакой изоляции сегментов и индивидуальных прав не существовало. Для доступа к внешним ресурсам, которые условно названы «Outside» и «Internet», были использованы стандартные методы VPN.

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

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

IP-телефония

Для полноценной модернизации инфраструктуры предприятия было необходимо создать устойчивую IP-телефонию. Команда уже имела в наличии хорошо настроенную систему Asterisk. Но её уже было недостаточно из-за возросших масштабов. Да и в случае сбоев в сети, связь падала.

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

Как только один филиал отказывался работать, в течение стандартных 15 секунд ожидания, запускался резервный за счет реализации метода SIP-соединения. Основой всей инфраструктуры была выбрана система Avaya.

С точки зрения самих телефонных аппаратов, было решено закупить станции DECT по 300$, которые не будут работать через доступный Wi-Fi. В обратном случае, пришлось бы потратить около 1000$ на один аппарат.

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

Результат

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

Мы можем провести комплексную модернизацию и оптимизацию корпоративной сети вашей компании в короткие сроки со 100% гарантией. Свяжитесь с нами.

Я могу ускорить команду apt-get или apt для загрузки пакетов из нескольких репозиториев на сервер LTS Ubuntu Linux 16.04 или 14.04 или Ubuntu 17.04? Как использовать команду apt-fast на сервере Debian Linux?

Вам нужно использовать apt-fast shell script wrapper. Установите команду apt-get command / apt  загрузив пакеты с несколькими соединениями для одного пакета. Все пакеты загружаются одновременно параллельно. Используетcя aria2c в качестве ускорителя загрузки.

Установка software-properties-common для PPA

Для использования PPA на сервере Ubuntu вам необходимо установить следующий пакет :

$ sudo apt-get install software-properties-common

Установите apt-fast tool

Введите следующую команду в Ubuntu Linux 14.04 и более поздних версиях:

$ sudo add-apt-repository ppa:saiarcot895/myppa

Пример результата:

Обновите свое репо:

sudo apt-get update

ИЛИ ЖЕ

$ sudo apt update

Пример результата:

Установите apt-fast:

$ sudo apt-get -y install apt-fast

ИЛИ ЖЕ

$ sudo apt -y install apt-fast

Настройка apt-fast

Вам будет предложено следующее (необходимо ввести значение от 5 до 16):

А также:

Вы можете редактировать настройки напрямую:

$ sudo vi /etc/apt-fast.conf

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

Заметка о Ubuntu Linux версии 17.04 «zesty» и Debian Linux

Введите следующую команду для установки в системе Ubuntu 17.04 или Debian Linux:

$ cd /tmp
$ wget https://git.io/vokNn
$ more vokNn
$ sudo bash vokNn

Как использовать команду apt-fast?

Синтаксис:

apt-fast command
apt-fast [options] command

Чтобы получить новые списки пакетов, используя apt-fast

sudo apt-fast update

Чтобы выполнить обновление с помощью apt-fast

sudo apt-fast upgrade

Чтобы выполнить обновление дистрибутива (выпуск или принудительное обновление ядра), введите:

$ sudo apt-fast dist-upgrade

Чтобы установить новые пакеты

Синтаксис:

sudo apt-fast install pkg

Например, установите пакет nginx, введите:

$ sudo apt-fast install nginx

Пример результата:

Удаление пакетов

$ sudo apt-fast remove pkg
$ sudo apt-fast remove nginx

Чтобы удалить пакеты и его файлы конфигурации

$ sudo apt-fast purge pkg
$ sudo apt-fast purge nginx

Чтобы автоматически удалить все неиспользуемые пакеты, введите:

$ sudo apt-fast autoremove

Загрузить исходные архивы

$ sudo apt-fast source pkgNameHere

Чтобы удалить загруженные файлы архива

$ sudo apt-fast clean

Удаление старых загруженных файлов архива

$ sudo apt-fast autoclean

Чтобы убедиться, что нет потерянных зависимостей

$ sudo apt-fast check

Загрузка пакета в текущий каталог

$ sudo apt-fast download pkgNameHere
$ sudo apt-fast download nginx

Чтобы загрузить и отобразить журнал изменений для данного пакета

$ sudo apt-fast changelog pkgNameHere
$ sudo apt-fast changelog nginx

Компьютерные вирусы – это серьезная проблема, которая встречается все чаще среди тех, кто любит бороздить просторы Интернета. Исключая классическую DDoS-атаку, не трудно догадаться, что причиной внезапных «тормозов» на сайте стал вредоносный код.
Разберемся с этим поэтапно.

Какие бывают виды вирусных программ?

«Компьютерный вирус» или «вирусная программа» может относиться к одной из двух видов:

1. Эксплойты: код, который ищет и использует уязвимости сайта. Нацелен на рассылку спама и выполнение прочих незапланированных задач. Почти всегда он появляется на сайте в виде зашифрованного PHP-кода.
2. Классические вредоносные программы, трояны: пожалуй, они не нуждаются в представлении. Встречаются, как в Windows, так и в Linux, где используются отдельные вредоносные модули, встраиваемые в исполняемый код.

Как работает вредоносное ПО на сайте?

• Рассылка спама – это самая «популярная» болезнь сайтов, перегружающая работу сайта замедляя его работу.
• Фишинг – не менее популярный способ похитить ваши персональные данные и номера кредиток. Но если проблема для пользователя может быть решена автоматической блокировкой сайта, которая происходит за счет самих поисковых систем, то для владельцев ресурса все гораздо хуже. Их сайт может заблокироваться в поисковой системе «Google» и, соответственно, перестать индексироваться.
• Распространение вирусов на ваш ПК.
• Скрытый майнинг – вредоносное ПО перегружает сайт за счет использования внутренних ресурсов, что приводит к блокировке работы.
• Ботнет: сайт начинает перегружаться и используется для атак на другие ресурсы.

Как вредоносное ПО оказывается на сайте?

Самыми распространенными CMS являются WordPress и Joomla!, поэтому они чаще всего страдают от регулярных атак. На них задействован PHP, а сами CMS не идеальны с точки зрения безопасности. Поэтому регулярно сканируйте их с помощью доступных приложений, предоставляемых WordPress и Joomla!

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

С помощью каких сканеров искать вредоносное ПО?

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

• CloudScan.Pro – эффективный инструмент для «облачного» сканирования, проверяющий файлы вашего сайта на отдельном выделенном сервере.
• Comodo/Kaspersky/ClamAV – помимо обычного сканирования, эти сервисы защитят вэб-ресурс от заражения вирусами, но не столь эффективны в борьбе с эксплойтами.
• Virustotal – агрегатор обработки данных, который сканирует ваш сайт с помощью множества различных сервисов ещё и бесплатно. Но базы данных свободных онлайн-сканеров ограничены и могут выявить далеко не всё.

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

Упрощенное решение проблемы для новичков

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

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

• Скачайте на локальный ПК архив с исходниками вашего сайта. Это можно сделать за счет встроенного файл-менеджера, предоставляемого на хостинге. Важно выкачивать файлы именно в архиве. Так вирусное ПО не сможет исполняться.
• Скачайте дамп своей базы данных с помощью phpMyAdmin, которая установлена практически на каждом хостинге.

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

Лечение сайта для продвинутых пользователей

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

Сканеры и PHP-скрипты

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

• Выкачать архив и просканировать его, после чего распаковать на локальное хранилище. В идеале, это будет ПК.
• Открыть командную строку и указать путь к выкачанному файлу, а точнее, к каталогу. После этого введите команду $ php ai-bolit.php –mode=1 (экспресс-сканирование) или $ php ai-bolit.php –mode=2 (параноидальный режим лечения).

Программные сканеры

Зайдя в систему под «рутом» (root), выполните поочередно нижеуказанные команды:

Как только установка завершится, выполните следующие команды:

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

Действия после сканирования

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

Профилактика заражения

Чтобы ситуация не повторилась, достаточно предпринять ряд несложных мер:

• Регулярно меняйте пароли, связанные с сайтом.
• Не забывайте обновлять CMS и сторонние плагины.
• Осуществляйте мониторинг стабильности работы сайта.
• Создавайте резервные копии!

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

Подведем итог

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

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

Если вы нуждаетесь в полной профессиональной диагностике и лечении вашего сайта от вирусов – обращайтесь. Мы все сделаем сами со 100% положительным исходом.

 

 

Сегодня OneDrive пользуется большой популярностью. Этому способствовала возможность интегрирования с продуктами Microsoft. Хотя для Linux еще нет его официального клиента, сейчас развивается «свободная» версия (в рамках проекта пользователя skilion с соответствующим названием). Она имеет свои ограничения и особенности в Ubuntu 18.04, о них и пойдет речь.

Особенности установки

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

1. устанавливаем пакеты

2. клонируем репозиторий

3. компилируем и устанавливаем исходный код в необходимую директорию

4. создаем директорию для синхронизации

5. создаем файл конфигурации и указываем нужную директорию

6. запускаем для авторизации

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

8. откроется чистая страница, адрес которой копируем и вставляем в качестве ответа на сервисный запрос.

Результат: сервис скачивает всю информацию из облака. Сколько этот процесс займет времени, зависит от объема информации и скорости интернет-соединения.

Особенности отдельных режимов

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

Еще один момент – необходимость регулярной синхронизации. Для этого подойдет режим «мониторинг». Его особенности:

• ключ командной строки – m;
• юнит system (удобный запуск).

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

Чтобы просмотреть лог о работе этого сервиса, понадобиться команда:

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