Брацко Облако

Брацко Облако (CNM Cloud; далее то тексту -- Облако) -- это технологические ресурсы Брацкой Школы (здесь и далее то тексту -- Школы). Облако представляет собой совокупность программного обеспечения и поддерживающей его материальной части.

Общие положения

Основные цели

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

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

Дополнительные цели

Кроме того, Облако может быть полезно:

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

Общие требования

Основная вики-страница: Требования к приложениям Брацкого Облака

Требования к приложениям описаны на вики-странице Требования к приложениям Брацкого Облака.

Ярусы

Облако включает в себя три яруса программного обеспечения: Инфраструктуру, Связующее обеспечение и Пользовательские приложения.

URL стратегия

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

Обзор планируемых приложений

Ярус	Обеспечение	Предназначение	Технология	URL
				Prototype	Example
Инфраструктура	Фермы	Поддержка Связующего обеспечения и Пользовательских приложений	OpenStack
Связующее обеспечение	Оплёт	Управление регистрацией, идентификацией и авторизацией доступов пользователей	Yii	kabina.	kabina.bskol.com
Пользовательские приложения	Правка	Открытый источник знаний и, одновременно, работа для новичков	MediaWiki	pravka.	pravka.bskol.com
	Пошта	Электронная почта	Roundcube	posta.	posta.bskol.com
	Справа	Административный учёт, электронная коммерция (Careerprise Shop) и работа персонала над проектами	Odoo	sprava.	sprava.bskol.com
	Учебка	Учебные курсы	Moodle	ucebka.	ucebka.bskol.com
	Вэбка	Администрация вэб-сайтов	WordPress	vebka.	vebka.bskol.com
	Жици	Организация видео- и аудио-конференций	Jitsi	jitsi.	jitsi.bskol.com
	Бачка	Размещение видео файлов	YouPHPTube	backa.	backa.bskol.com
	Сетка	Социальная сеть	HumHub	setka.	setka.bskol.com
	Связка	Полезные контакты	SuiteCRM	svazka.	svazka.bskol.com
	Крынка	Работа разработчиков над проектами с установленным service desk приложением для сбора информации по проблемам и хранение исходных кодов уникального программного обеспечения	Redmine, SVN	krynka.	krynka.bskol.com

Брацки Фермы (инфраструктура)

Основная вики-страница: Брацки Фермы

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

Оплёт (федеративная служба)

Основная вики-страница: Оплёт

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

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

Пользовательские приложения -- это приложения для конечных пользователей.

Брацка Правка

Основная вики-страница: Брацка Правка

Брацка Правка -- это открытая база знаний Брацкой Школы, построенная на основе программного обеспечения MediaWiki и доступная для просмотра бесплатно 24 часа в день 7 дней в неделю любому посетителю сети Интернет.

Брацка Пошта

Основная вики-страница: Брацка Пошта

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

Брацка Справа

Основная вики-страница: Брацка Справа

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

Брацка Учебка

Основная вики-страница: Брацка Учебка

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

Брацка Вэбка

Основная вики-страница: Брацка Вэбка

Брацка Вэбка -- это сеть вэб-сайтов Брацкой Школы, которые представляют Школу в сети Интернет. Вэб-сайты построены на основе программного обеспечения WordPress и доступны для просмотра бесплатно 24 часа в день 7 дней в неделю любому посетителю сети Интернет.

Брацки Жици

Основная вики-страница: Брацки Жици

Брацки Жици -- это инструмент Брацкой Школы для организации видео- и аудио-конференций. Жици построена на основе программного обеспечения Jitsi и доступна для зарегистрированных участников конференций.

Брацка Бачка

Основная вики-страница: Брацка Бачка

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

Брацка Крынка

Основная вики-страница: Брацка Крынка

Брацка Крынка -- это средство для работы над проектами, построенное на основе программного обеспечения Redmine и доступное исключительно администраторам Брацкой Школы и авторизованным ими разработчикам программного обеспечения. Доступ к Крынке осуществляется исключительно по PKI.

Построение технологических ресурсов

Общая стратегия

1. Поддерживать Брацки Фермы пока их проблемы не будут решены
2. Искать исполнителей на те Работы в Брацкой Школе, которые относятся к технологическим ресурсам.

Профинансированные работы

Работы	Фермы	Оплёт	Правка	Пошта	Справа	Учебка	Жици	Бачка	Крынка
Запрос	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно
Требования
Архитектура
Модель
Прототип
Заказ
Производство	Наработки	Наработки	Наработки		Наработки	Наработки			Наработки
Конфигурация
Усовершенствование

Задачи по приложениям

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

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

Жици (Jitsi)

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

Правка (MediaWiki)

1. Надо привязать последнюю стабильную версию MediaWiki к нашему OpenLDAP. У нас стоит 1.31.1 версия, так как эта версия -- последняя, которую поддерживает наш плагин LDAP. Последняя стабильная версия -- 1.36.0. Новый плагин -- https://www.mediawiki.org/wiki/Extension:LDAPAuthentication2
2. Надо стабилизировать загрузку, хранение и использование картинок. Сейчас они не загружаются и спорадически не отображаются. Например, 7 декабря картинки выбились, перестав отображаться. После клика на редактирование и сохранение, картинки появлялись -- этот сценарий повторялся на нескольких страницах. Затем всё само восстановилось. Аналогичные сбои происходили и раньше. Сама Википедия использует другую схему.

Учебка (Moodle)

1. В Учебке (Moodle) активно используется элемент "Лекция", но не похоже, что этот элемент не сохраняет ответы учеников. Например, элемент "Тест" сохраняет абсолютно все ответы. Однако некоторые из ответов в лекциях необходимы для сохранения в качестве полей профиля. Мудл содержит пару плагинов для лекций, но не ясно решают ли эти плагины проблему сохранения ответов. Если существующие плагины не могут решить проблему, необходимо модернизировать родной плагин.

Оплёт (Opplet)

Оплёт -- это система управления пользователями, написанная на Yii и использующая OpenLDAP для коммуникации со всеми пользовательскими приложениями. Надо:

1. подготовиться к смене морды, когда её новый дизайн будет готов,
2. настроить восстановление пароля,
3. разрешить проблему ролей. По окончании курса Moodle отдаёт информацию Оплёту и тот должен назначать новую роль, отдавать эту роль в OpenLDAP, а OpenLDAP -- распространять по всем приложениям. Сейчас OpenLDAP принимает только одну роль и не меняет её.
4. Проблема CAPTCHA -- ранее была установлена Google-овская ReCAPTCHA, однако она не работала для пользователей в Китае, где услуги Google заблокированы.

Сетка (HumHub)

HumHub

Справа (Odoo)

Odoo

Крынка (Redmine)

Основу составляет Redmine. Были разговоры:

1. Увязки Брацкой Крынки с хранилищем файлов, например, сторонним Bitbucket или собственным GitLab;
2. Установки обеспечения SVN для учёта версий на Брацкую Крынку.

Связка (SuiteCRM)

SuiteCRM

Вебка (WordPress)

WordPress

Бачка (YouPHPTube)

YouPHPTube

Задачи по серверам

Аварийное восстановление

Используя rsync, еженедельно полный бэкап и ежедневно incremental бэкап заливаются на backup space на Contabo. Есть идея использовать rsnapshot для снимков, но эту идею пока не получилось реализовать. Надо создать:

1. Подробное описание существующей системы.
2. Процедуру проверки надёжности бэкапов.
3. Инструкцию по восстановлению в случае аварии.

Distributed databases

1. Сейчас, база каждого пользовательского приложения установлена на трёх нодах и синхронизована. Есть план сделать одну распределённую базу с тех, чтобы базы приложений забирали данные оттуда. Один специалист рекоммендовал NoSQL -- Apache Cassandra. Другой -- распределённую SQL типа CockroachDB.
2. Если распределённая база предложенная выше этой проблемы не решит, надо создать архитектуру базы клиентов. Сейчас клиенты учитываются в нескольких независимых приложениях. Они имеют CRM модули, которые призваны учитывать работу с клиентами, которые могут является, но скорее всего не являются пользователями. Надо создать базу, в которую каждое приложение заливало новые данные и брало старые. Предложение заключалось в общей master базе, информация в которую может вбиваться с любого приложения, но отображаться в зависимости от её публичности.
3. Есть также предложение создать архитектуру нового ESB, который должен собирать данные с различных приложений и хранить их в NoSQL базе. Ранее обсуждалась единая неосновная база данных для всей системы. Разговор шёл о комбинации Hadoop, ESB Mule и MongoDB. Идея была в сборе данных с разных приложений через ESB Mule, причёсывание их Hadoop'ом и размещение в MongoDB как дополнительной базе данных, откуда они могут браться для для личного кабинета (dashboard) пользователя. То есть, заходя в кабинет, пользователь мог бы в идеале видеть свою активность в разных приложениях и искать по всем системам сразу.

DNS и DNSSEC

Есть несколько доменных имён, но пока речь идёт об основном -- cnmcyber.com:

• Домен зарегистрирован на goDaddy; nameservers расположены там.
• Система управления пользователями -- https://cabin.cnmcyber.com -- сейчас расположена на одном VPS (они зовут их "дроплетами") digitalocean.com. Есть план добавить load balancer и перевести систему на кластер. Планов уезжать с digitalocean.com нет.
• Пользовательские системы -- cert. , wiki. , venture. и так далее, включая почту mail. -- расположены на трёх VPS contabo.de -- два VPS в штатах и один -- в Германии. VPS объединены в кластер синхронизированной распределённой базой. DNS Anycast, DNS Geocast, и аналогичные распределительные системы не установлены -- каждое пользовательское приложение установлено только на одном VPS. Есть план продублировать приложения и отправлять пользователя на тот сервер, который наиболее доступен конкретному пользователю. Есть план добавить или заменить один VPS железом на hetzner.de с установкой proxmox.
• Видео-конференционная система talk. (на Jitsi) пока установлена вместе с пользовательскими системами, но есть план увести её отдельно на CDN типа Cloudflare или глобальные облачные решения -- Microsoft Azure или AWS -- участники конференций могут находиться на разных континентах и требование к качеству особо высокое.

Надо:

1. проверить существующие и создать нехватающие DNS и, возможно, новые DNSSEC записи. DNSSEC не является критичной -- может быть отлажено только для какой-то части зон DNS. Проект Школы -- учебный, нам важно иметь разные вещи для того, чтобы показывать ученикам.
2. изучить возможность Dynamic DNS (DDNS) или виртуальных DNS.

IP

1. IPv6. В данный момент используется IPv4 и есть план разобраться с более новым протоколом
2. Virtual IP address. Есть необходимость разобраться с виртуальными адресами. Digitalocean предлагает floating IP address, который можно устанавливать на те дроплеты (VPS), которые расположены в одном датацентре. Hetzner.de предлагает failover IP, хотя с ними надо разобраться. Не похоже, что Contabo предлагает что-то вроде этого.
3. В случае, если виртуальный IP не возможен, есть практика направления IP на load balancer -- какие плюсы и минусы у этой практики?

Отказоустойчивость

1. Надо переделать кластер пользовательских приложений в high-availability cluster. В настоящее время load balancer сделан на NGINX, пользователи работают с приложениями, которые установлены на трёх различных серверах Contabo (два -- в штатах, один -- в Германии). Сервера поддерживают синхранизованные базы, которые обновляют друг друга. Если один сервер падает, то его пользовательские приложения не доступны. Надо повысить устойчивость кластера.
2. В дополнение, есть предложение, чтобы пользователь работал с тем приложением, которое более доступно для этого пользователя. Рассматриваются решения для кластеров типа Linux-HA на основе heartbeat и load balancers типа HAProxy. Теоретически, будущий кластер может решить и проблему Jitsi, но, возможно, Jitsi требует иного подхода.
3. Управление пользователями осуществляется сейчас с дроплета (VPS) на digitalocean (DO). Надо переделать это решение на кластер. Сам DO предлагает load balancer и floating IP address -- эти решения требуют рассмотрения.
4. Ещё одна проблема, требующая решения -- изменение архитектуры пользовательских приложений. Сейчас, если одно приложение, использующее базу данных MariaDB падает, за ним падают все остальные. Каждое приложение должно падать само, не таща за собою другие.

Postfix/Dovecot/Roundcube

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

Требуется:

1. выбрать, установить, настроить, провести нагрузочное тестирование, отмониторить продакшн и откоректировать параметры такого решение для почты, которое бы дружило с нашим OpenLDAP, через который идёт управление пользователями. Будет установлен пакет iRedMail, который включает в себя Postfix, Dovecot, Roundcube. Требования подрядчика: 1. Что бы у всех пользователей OpenLDAP было заполнено поле mail 2. Новый пользователь vmail (пароль скажут после установки пакета iRedmail) 3. Поле для квоты. Подрядчик определён, уточняются детали проекта.
2. выбрать, установить и настроить безопасный тунель между сервером почты и сервером OpenLDAP. Специалист считает, что лучшее решение -- это использование VPN, чтобы и OpenLDAP, и Dovecot виртуально были бы в одной сети. Авторизация почтового сервера идёт через Dovecot.
3. задокументировать решения и настройки.

SSO

1. Создание SSO. Более 3х десятков пользовательских приложений включено в "Облако", но заходя в каждое из них сейчас пользователь должен логиниться отдельно, что должно быть улучшено.

Virtualization

Есть план либо заменить один VPS железом, либо добавить железный сервер на hetzner.de для решения двух задач:

1. Спроектировать сеть для повышения устойчивости системы.
2. Автоматически создавать виртуальные машины для участников тренингов. Школа будет устраивать тренинги и планирует выдавать ресурсы для практических занятий. После оплаты участником, участник должен получать имэйл со ссылкой на ресурс с логином и паролем. Идеально, ресурс должен быть виртуальной машиной. Если виртуальная машина не получается, можно продумать возможность решения на контейнерах. Специалист считает, что так как контейнер создаётся одной строкой, можно сделать скрипт под Линукс, который будет создавать контейнер из образа и добавлять к нему логин и пароль.

ProxmoxVE -- основное решение, которое рассматривается. Специалист предлагает использовать роутер Microtik, чтобы на proxy сделать два IP адреса, первый использовать для внутренних виртуалок, если они нормально работают, а второй загнать в bridge для внешних серверов и средствами Линукса типа firewall делить тот трафик, который приходит. Кроме того, на том же proxy можно поставить DHCP сервер для раздачи адресов машинам. Другой специалист считает, что безопасных DHCP серверов на рынке нет.