четверг, 18 сентября 2014 г.


Перейти к концу метаданных
Переход к началу метаданных

Предисловие

LXC - новейшая технология, полноценный релиз ее версии 1.0 был всего 3-и месяца назад. Итак, это наименее требовательная к ресурсам технология виртуализации из существующих сегодня. В отличие от уже привычного варианта, когда виртуализируется оборудование, а не только среда, тут нет гипервизора и не производится эмуляция аппаратного обеспечения. Все экземпляры ОС - контейнеры, используют единое ядро хост-системы и напрямую обращаются к одному и тому же физическому оборудованию. За счет отсутствия слоя виртуализации достигаются максимальная производительность и наивысшая плотность виртуальных серверов на одном физическом. Контейнеры работают независимо, как друг от друга, так и от хост-системы. В нашей случае, будет рассмотрена возможность запуска неограниченного количества LXC контейнеров с сервером приложений CBS3plus на борту каждого из них. По ходу статьи будут описаны все преимущества данного решения в качестве платформы для всех серверов приложений. Гибкость LXC позволяет его гармонично вписать не только в нашу существующую внутреннюю инфраструктуру (попутно устраняя ее недостатки), но и применять как универсальное Enterprise решение для клиентов.
Данное изображение иллюстрирует различие между стандартной виртуализацией и LXC:
В качестве ОС - я строго рекомендую Ubuntu 14.04 LTS (со сроком поддержки 5 лет), т.к. в ней эта технология реализована лучше всего (сказывается заточка под LXC фирменного ПОUbuntu для администрирования массивов серверов - Juju и MAAS). На любом другом дистрибутиве, стабильная и правильная работа LXC не гарантирована.
За что мы любим Ubuntu? За элегантность, простоту и красоту предлагаемых решений. Сейчас вы сами убедитесь в этом на практике.

I. Подготовка ОС хоста

В данном разделе статьи мы рассмотрим такие вещи, как настройка сети, обновление системы и установка необходимого ПО. Убедитесь, что у сервера есть прямой доступ в интернет, до завершения процесса установки и настройки системы. Предварительное условие: на железо должен быть установлен Ubuntu Server 14.04 LTS с компонентом OpenSSH server. Все остальные действия после п.1 выполняются удаленно.

1) Настройка сети

В Ubuntu всегда все просто и красиво! В отличии от того же Debian`a, здесь вся сеть настраивается в одном месте. Итак, сначала мы настроим сеть стандартно (сетевые параметры подставляйте свои):
sudo nano /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.253
netmask 255.255.248.0
gateway 192.168.0.1
dns-nameservers 192.168.0.1

2) Полное обновление системы

Как всегда, все очень просто! Обновляем список репозиториев, обновляем все ПО и чистим систему от мусора! И все это одной командой...
sudo apt-get update -y && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo apt-get autoremove -y && sudo apt-get autoclean -y

3) Установка дополнительного ПО

Ставим все что нужно. Одной командой.
sudo apt-get install lxc bridge-utils

4) Дополнительная настройка сети

Такс, и вот теперь нам нужное кое что донастроить. Проверяем список сетевых интерфейсов:
ifconfig -a

Там добавится интерфейс lxcbr0 - это по сути NAT, т.е. шлюз и DHCP для внутренней сети контейнеров. Он имеет сетевой адрес по умолчанию: 10.0.3.1. Следующий шагом мы создадим большой мост под названием br0, который объединит eth0 и lxcbr0. Это даст контейнерам, которые стоят за lxcbr0 доступ во внешний мир. В работу lxcbr0 - лезть не надо, там все работает как часы автоматически. Итак, поехали:
sudo nano /etc/network/interfaces
auto lo
face lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.248.0
gateway 192.168.0.1
dns-nameservers 192.168.0.1
bridge_ports eth0 lxcbr0

И перезагружаемся:
sudo reboot

Итого, данное изображение иллюстрирует работу сети хоста и внешней сети:
Виды подключений:
2: пользователи сети Colvir заходят напрямую на веб-интерфейс своего сервера приложений;
1: пользователи сети Colvir заходят на веб-интерфейс своего сервера приложений, доступ к которому балансируется через nginx;
3: пользователи из Интернета заходят на веб-интерфейс своего сервера приложений, доступ к которым балансируется через nginx (который стоит за приделами нашей внутренней сети);
4-2: пользователи из Интернета подключатся к нашей сети по VPN, а потом уже заходят напрямую на веб-интерфейс своего сервера приложений;
4-1: пользователи из Интернета подключатся к нашей сети по VPN, а потом уже заходят на веб-интерфейс своего сервера приложений, доступ к которому балансируется через nginx;

Заметка об использовании балансировщика nginx. Он позволяет использовать множество серверов приложений, настроенных на выполнение одной и той же задачи (равномерно распределяя пользователей по разным серверам, тем самым балансируя нагрузку). Использование балансировщика необходимо в связи с установленной ограниченной вместимостью одного сервера приложений, которая на данный момент составляет всего ~35 человек (согласно тестированиям Евсеева Владислава). Таким образом, использование большего числа контейнеров и серверов приложений в них - прямо пропорционально увеличивает вместимость, скорость и стабильность наших серверов. А использование контейнеров и nginx - создает монолитную, крепкую конструкцию, которая покрывает все имеющиеся в наличии у нас сейчас недостатки... делая из них преимущества.
В совместной работе с Евсеевым Владиславом, нами был подобран оптимальный конфиг nginx для работы с нашими серверами приложений. Об этом подробнее тут: Установка и настройка nginx на Oracle Linux 6.5

II. Настройка LXC

В данном разделе, мы создадим первый (эталонный) контейнер, добавим пользователя к нему, установим Java и CBS3plus и настроим работу веб-интерфейса в внешней сети.

5) Создание пользователя colvir

На данном этапе, мы создадим универсального пользователя colvir. Он будет иметь обычные (user) права на хост системе и админские (sudo) права во всех контейнерах. По сути, это будет администратор внутри контейнера, из-под его имени и будут работать и запускаться все сервера приложений во всех контейнерах.1-я команда - создание пользователя, 2-я - его пароля.
sudo useradd colvir -m -s /bin/bash
sudo passwd colvir

6) Создание и настройка первого контейнера

Далее, мы создаем наш первый контейнер с именем (к примеру) - С1. Наш пользователь colvir будет обладать там правами администратора.
sudo lxc-create -t ubuntu -n C1 -- -b colvir

Первый контейнер создается довольно долго, минут 15. Со всеми последующими будет проще. Далее, правим данный конфиг, выставляя там 2-а параметра (до параметров сети, в первой колонке).... 1-й это автозапуск после перезагрузки хоста, 2-й это задержка в секундах перед стартом именно этого контейнера (когда их будет много, можно поставить интервал секунд в 10 для каждого последующего):
sudo nano /var/lib/lxc/C1/config
lxc.start.auto = 1
lxc.start.delay = 0

Запуск контейнера производится командой:
sudo lxc-start -d -n C1

Проверка статуса контейнеров (там можно увидеть статус и внутренний IP контейнера):
sudo lxc-ls --fancy



А сейчас мы создадим хранилище для скриптов и сам скрипт, который откроет доступ к контейнеру из-вне, а именно к веб-интерфейсу CBS3plus и SSH (посредством маршрутизации):
sudo mkdir /opt/bin
sudo nano /opt/bin/df_access.sh
Скопируем содержимое скрипта: df_access.sh

Данный скрипт работает с вводом параметров, т.е. в будущем надо будет вводить так: ./df_access.sh п1 п2 п3 п4, где:
п1 - 1-й параметр.. реальный IP сервера;
п2 - 2-й параметр.. порт на хосте, на который будет привязан внутренний порт определенного контейнера;
п3 - 3-й параметр... это IP адрес целевого контейнера;
п4 - 4-й параметр... это порт на контейнере, который мы пробрасываем в п2 (22 - для SSH, 8080 - для сервера приложений).

Даем права на скрипт, делаем его исполняемым и real-only. Потом заходим в нашу новую директорию со скриптами:
sudo chmod 555 /opt/bin/*.sh
cd /opt/bin

Далее, непосредственно используем наш скрипт по назначению.
sudo ./df_access.sh 192.168.0.253 40022 10.0.3.22 22
sudo ./df_access.sh 192.168.0.253 48080 10.0.3.22 8080

Что он означает, описано выше. А в результате мы получим:
SSH: 192.168.0.253:40022 = 10.0.3.22:22
Веб-интерфейс: 192.168.0.253:48080 = 10.0.3.22:8080

Добавим это как правило, в автозапуск (не забывайте оставлять там для себя комментарии к командам):
sudo nano /etc/rc.local
sh /opt/bin/df_access.sh 192.168.0.253 40022 10.0.3.22 22
sh /opt/bin/df_access.sh 192.168.0.253 48080 10.0.3.22 8080

7) Установка CBS3plus в первый контейнер

На этом этапе мы установим в наш эталонный контейнер все необходимое ПО, Java и CBS3plus. Итак, зайдем в консоль контейнера C1 (дальнейшие действия мы проводим от имени пользователя colvir внутри контейнера):
sudo lxc-console -n C1

Установим необходимое ПО:
sudo apt-get install openjdk-7-jdk nano

Даем права на папку /opt:
sudo chown -R colvir:colvir /opt

Далее мы будем использовать специальный инсталлятор (архив), который сам все распакует и установит куда надо. Данный инсталлятор - мой форк на cbs3plus-geronimo3-installer-20140616.tar.gz, но адаптированный специально для Ubuntu.
Он находится тут: \\1.1.1.44\000\DF\Ubuntu\cbs3plus-ubuntu.tar.gz
Также там лежит набор бандлов: \\1.1.1.44\000\DF\Ubuntu\bundles-example.tar.gz
По умолчанию, сервер настроен на наш интеграционный стенд 4.203, подробнее о стендах: Список серверов приложений (стендов). Итак, наша задача закинуть эти архивы (по sftp) в папку/home/colvir

Когда все будет лежать на месте, распаковываем архив с сервером приложений:
tar -xvf cbs3plus-ubuntu.tar.gz -C /opt

Дадим права на папку:
sudo chmod 775 -R /opt

Старт сервера приложений выполняется командой:
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo start

Остановка сервера приложений выполняется командой:
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo stop --user system --password manager

Настройка подключения к базам данных:
nano /opt/geronimo/geronimo-tomcat7-javaee6/etc/com.colvir.pools.cfg

Нам надо запустить сервер приложений, дать ему поработать минуту, потом остановить его.

Далее - залить необходимые модули (бандлы) и уравнять права:
tar -xvf bundles-example.tar.gz -C /opt/geronimo/geronimo-tomcat7-javaee6/hotbundles
sudo chmod 775 -R /opt

Добавляем наш сервер приложений в автозапуск:
sudo nano /etc/rc.local
/opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo start

Вот и все (smile)  Теперь просто запустим его и насладимся результатом нашей работы:
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo start

Результат: http://192.168.0.253:48080/cbs-qx

III. Администрирование LXC

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

8) Основные команды

Проверить статус всех контейнеров:
sudo lxc-ls --fancy

Общий список всех контейнеров:
sudo lxc-ls

Склонировать контейнер С1, новый контейнер назвать С2:
sudo lxc-clone -o C1 -n C2

Запустить контейнер С1:
sudo lxc-start -n C1

Запустить контейнер С1, не входя в него:
sudo lxc-start -d -n C1

Остановить контейнер С1:
sudo lxc-stop -n C1

Удалить контейнер С1:
sudo lxc-destroy -n C1

Зайти в консоль контейнера С1:
sudo lxc-console -n C1

Поставить контейнер С1 на паузу:
sudo lxc-freeze -n C1

Восстановить контейнер С1 из паузы:
sudo lxc-unfreeze -n C1

9) Создание клона контейнера

Итак, у нас есть эталонный контейнер C1. Создавать новый контейнер с нуля не нужно. Остановим его и сделаем из него клон, назовем его C2:
sudo lxc-stop -n C1
sudo lxc-clone -o C1 -n C2

Клонируется контейнер максимум минуту (зависит от загруженности дисковой подсистемы сервера). Далее, запустим оба контейнера (С1 + С2) и проверим их статус:
sudo lxc-start -d -n C2
sudo lxc-start -d -n C1
sudo lxc-ls --fancy
Вот и все! Все красиво, вон наши оба красивых контейнера. Смотрим IP и используем скрипт, чтобы открыть доступ извне для второго контейнера (С2):
cd /opt/bin
sudo ./df_access.sh 192.168.0.253 40023 10.0.3.97 22
sudo ./df_access.sh 192.168.0.253 48081 10.0.3.97 8080

В результате мы получим:
SSH: 192.168.0.253:40023 = 10.0.3.97:22
Веб-интерфейс: 192.168.0.253:48081 = 10.0.3.97:8080

Добавим это в автозапуск:
sudo nano /etc/rc.local
sh /opt/bin/df_access.sh 192.168.0.253 40023 10.0.3.97 22
sh /opt/bin/df_access.sh 192.168.0.253 48081 10.0.3.97 8080

Делов то (smile)  2-й контейнер готов к работе. Все очень просто, не правда ли?

IV. Дополнительные возможности

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

10) Централизованный доступ к файловым системам всех контейнеров (обновление сразу всех серверов приложений)

Данная возможность очень полезна для централизованного обновления всех серверов приложений на хосте. Только представьте себе, из хоста мы можем попасть куда угодно в любом контейнере, в т.ч. в папку hotbundles. А теперь представьте себе большой сервер в банке, где крутиться огромное множество одинаковых серверов приложений в контейнерах.. и на каждом из них надо обновить модули.. понимаете, в какую сторону я клоню?
Давайте посмотрим, как это сделать (создаем группу lxc, даем ей право на папку и добавляем туда нашего пользователя):
sudo groupadd lxc
sudo usermod -G lxc -a darkfess
sudo chgrp -R lxc /var/lib/lxc
sudo chmod -R 775 /var/lib/lxc
sudo reboot

Вот и все. Папка hotbundles, в контейнерах, находится тут:
C1: /var/lib/lxc/C1/rootfs/opt/geronimo/geronimo-tomcat7-javaee6/hotbundles
C2: /var/lib/lxc/C2/rootfs/opt/geronimo/geronimo-tomcat7-javaee6/hotbundles

Ниже будет пример скрипта, который обновляет сервера приложений в контейнерах С1 и С2 (останавливает, обновляет и запускает их).. но для начала, создадим папку для обновлений, распространим на нее права группы lxc и уровняем их (/opt/updates):
sudo mkdir /opt/updates
sudo chgrp -R lxc /opt/updates
sudo chmod -R 775 /opt/updates

Создадим сам скрипт:
sudo nano /opt/bin/all_update.sh
Скопируем содержимое скрипта: all_update.sh

Выставим на него права:
sudo chmod 555 /opt/bin/*.sh

Закидываем наше обновление в папку /opt/updates (через sftp) и потом используем скрипт:
cd /opt/bin
sudo ./all_update.sh

Вот и все (smile)  Мы можем одним махом обновлять все наши сервера приложений в контейнерах, модифицируя данный скрипт в любую сторону.

11) Веб-интерфейс LXC Web Panel (экспериментально!)

Данный инструментарий является экспериментальным и его настоятельно не рекомендуется использовать в промышленной эксплуатации. Только для тестирования! Краткая предыстория.... Стабильная версия LXC Web Panel работала с LXC 0.7-0.9, а с выходом версии 1.0 (в которой было многое переработано) она уже была не актуальна. На данный момент есть форк LXC Web Panel, который мы сейчас и поставим. Внимание! В результате моего тестирования было замечено, что данный форк меняет конфигурационные файлы LXC, из-за чего потом ломаются внутренние мосты (невозможно достучатся из контейнера из вне). Поэтому использовать его, по сути, нельзя. Но добавлю, что данный веб-интерфейс очень удобен и практичен, мне он лично очень понравился. С ним - работа с LXC одно удовольствие. Поэтому мы дружно будем ждать стабильной версии родного LXC Web Panel для новых версий LXC!LXC Web Panel рассчитан на то, чтобы быть установленным на уже работающую и отлаженную инфраструктуру, поэтому "присаживать" его можно уже в самую последнюю очередь.
Установка с помощью скрипта:
wget https://raw2.github.com/claudyus/LXC-Web-Panel/master/tools/install.sh -O - | sudo bash

Далее, создадим конфиг:
sudo nano /etc/lwp/lwp.conf
Скопируем содержимое конфига: lwp.conf

В конфиге не забудьте подредактировать поле с IP адресом сервера (поле address). После, перезапускаем сервис:
sudo service lwp restart

Вот и все! Веб-интефейс будет доступен по адресу (в нашем случае): http://192.168.0.253:5000/ (логин/пароль: admin/admin) Не забывайте, что LXC Web Panel разрабатывается силами энтузиастов и не имеет прямого отношения к разработчикам главного проекта LXC.

Несколько скриншотов веб-интерфейса LXC Web Panel (С1 и С2 уже с CBS3plus на борту, С3 и С4 - "голые" контейнеры):
   

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

V. Работа с LXC

Данный раздел статьи посвящен эксплуатационным особенностям и непосредственной работе с контейнерами LXC. Здесь мы поговорим об безопасности, обновлении серверов приложений CS3plus и сопровождении контейнеров (регламенты и правила работы с ними).

12) Безопасность

В LXC безопасность организована должным образом. Все контейнеры изолированы друг от друга и не нарушают при этом работу хоста. Говоря про безопасность в работе, можно сказать следующее - она бывает двух видов. На уровне контейнера и на уровне хоста. Т.е. 2-й уровень - это администратор контейнера, а 1-й администратор хоста. Иными словами, администратор хоста - это наивысшая привилегия, с ней нужно быть очень аккуратным (т.е. по незнанию можно банально все сломать). Поэтому, поговорим о них по отдельности...

Администратор хоста
а) Не должно быть никаких учеток по типу "admin", "root" и тд. У каждого администратора должна быть именная учетная запись.
б) Все действия администраторов хоста подлежат пошаговому логированию.
в) Лишним людям на сервере делать нечего.
г) Обязательно должен вестись журнал выданных учетных записей. "Когда, кому и зачем".

Администратор контейнера
а) Позволительно разделить учетную запись админа (colvir) с доверенными лицами, которые будут работать с данным контейнером, обновлять сервер приложений и тд.
б) Если доступ просит кто-то вне отдела, для него можно сделать отдельную учетку.
в) Обязательно должен вестись журнал выданных учетных записей. "Когда, кому и зачем".

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

13) Обновление сервера приложений

Обновление серверов приложений будет выполнятся на уровне контейнеров, именем администратора контейнера (colvir).
а) Остановка сервера приложений. Для этого, подключаемся к контейнеру по SSH с помощью putty. Тут мы рассмотрим подключение к нашему тестовому контейнеру из статьи - C1. Как вы помните, для SSH мы пробрасывали специальный порт скриптом (п.6): 192.168.0.253:40022. Получим что-то вроде этого:


Зайдя под администратором colvir в контейнер, останавливаем сервер приложений командой:
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo stop --user system --password manager

Можно еще и так, но тогда он спросит логин и пароль от geronimo (а по умолчанию он system\manager).
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo stop

б) Обновление сервера приложений. Для этого, нам необходимо подключится к серверу по sFTP (параметры подключения точно такие же, как и по SSH). Для этой операции, я рекомендую использовать FileZilla.


Обратите внимание, из-за нестандартного порта FileZilla автоматически не определяет протокол подключения. По этому, графе хост нужно дописать "sftp://". Все, далее работаем как с обычным ftp сервером. Берем набор модулей (каких модулей и где их брать, должно быть указано во входящей заявке) и закачиваем их с заменой в папку: /opt/geronimo/geronimo-tomcat7-javaee6/hotbundles

в) Запуск сервера приложений. Опять же по SSH с помощью putty, выполняется командой:
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo start

Проверяем командой (процесс java должен постоянно висеть):
top

Ждем, пока CBS3plus не загрузится и не прожует все новые модули. Верный признак завершения - висящий процесс java и загрузка ЦП в районе нуля. Осталось лишь зайти в веб-интерфейс и проверить, все ли нормально. Для нашего тестового контейнера C1, с помощью скрипта пробрасывался порт выше (п.6). Соответственно, веб-интерфейс будет по адресу:http://192.168.0.253:48080/cbs-qx Проверяем авторизацию под учеткой ROOT\colvir. Если все ок - то операцию обновления можно считать выполненной успешно.

14) Переключение сервера приложений на другие базы

Это одна из самых распространенных операций (наряду с обновлением), с которыми нам придется иметь дело. Например, свежий клон нужно будет перенастроить на новый базы. Как это сделать? Итак, сейчас продемонстрирую...
Останавливаем сервер приложений:
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo stop --user system --password manager

Правим конфиг:
nano /opt/geronimo/geronimo-tomcat7-javaee6/etc/com.colvir.pools.cfg
cbs4url=jdbc:oracle:thin:@1.1.1.100:1521:c4dev
cbs4instituteUser=css$inst$001
cbs4institutePassword=colvir
cbs4adminUser=css$main
cbs4adminPassword=colvir
cbs3url=jdbc:oracle:thin:@1.1.1.40:1521:hgdev
cbs3user=colvir
cbs3password=colvir
Конфиг подключает 2-е базы. База С4 - это строки 1-5 (2-а пользователя css$main$001 и css$main), база С3 - это строки 6-8 (1-н пользователь colvir), ну и везде пароль обычно colvir. Правим его, потом: ctrl+x, y, enter. Все сохранено.
Но перед включением сервера приложений, надо проверить подключение к базам. Сделать это можно через приложение PLSQL на терминальных серверах, по пользователям (C4: css$main$001\colvir, css$main\colvir; C3: colvir\colvir). Но я рекомендую установить себе локально Oracle SQL Develper и проверять подключение через него (там есть специальный вид подключения, он называется "advanced"). Таким образом можно подключится к базе по jdbc (как это делают наши сервера приложений), через jdbc-ссылку, например:jdbc:oracle:thin:@1.1.1.100:1521:c4dev и jdbc:oracle:thin:@1.1.1.40:1521:hgdev  Эти ссылки можно и нужно брать прямо из конфига. Если по какому-то пользователю не подключилось, то возможно он заблокирован или пароль на него сменен. В таком случае, нужно подключится к базе под админским пользователем sys и поменять все как надо (в случае, если у вас нет доступа к БД под sys - создайте заявку).
Если же все ОК и подключение прошло успешно - можно запускать сервер приложений.
sudo /opt/geronimo/geronimo-tomcat7-javaee6/bin/geronimo start

15) Сопровождение

Обслуживание серверов приложений предлагается выполнять согласно конкретным инструкциям и журналам, примеры которых будут предложены ниже. Со временем, информация будет конкретизирована.
Интеграционный процесс должен быть зафиксирован в этих местах:
  1. Специальная папка для хранения конфигураций всех серверов приложений (папка: \\1.1.1.44\000\DF\configs).
    а. У каждого сервера приложений должна быть своя папка, к примеру у 4.203: \\1.1.1.44\000\DF\configs\4.203. В этой папке должны лежать актуальные конфигурационные файлы сервера приложений (файлы: colvir.settings.xml и com.colvir.pools.cfg).
    б. У каждого обновления для сервера приложений, должна быть своя подпапка (по дате) в папке этого сервера, к примеру у 4.203: \\1.1.1.44\000\DF\configs\4.203\1.07.2014. В этой папке должны лежать все модули сервера приложений, по дате его текущего обновления (все файлы из папки: /opt/geronimo/geronimo-tomcat7-javaee6/hotbundles).
  2. Специальный журнал, для записи всех открытых на хосте портов и их привязка к конкретным контейнерам. Это нужно для прямого доступа по ssh и http (файл:\\1.1.1.44\000\DF\AS_ports.xls).
  3. Специальная статья в wiki, там должны быть фиксированы все изменения для публичного доступа: Список серверов приложений (стендов)
При создании нового контейнера, администратор должен:
     5.  Прописать к нему порты для доступа по ssh и http и занести их в журнал (п.14.2).
     6.  Добавить пункт о новом сервере приложений в статью на wiki (п. 14.3).
При настройке контейнера, администратор должен:
     7.  Сохранить все его конфиги и модули в соответствующие папки (п.14.1).
     8.  Дополнить статью в wiki (п.14.3).

Рекомендации по железу

В первую очередь, в железе мы упираемся в оперативную память. Рекомендуется использовать многоядерный процессор, много оперативной памяти и промышленный SSD. Один новый контейнер, потребляет на винте меньше 1 гб. Готовый контейнер с CBS3plus на борту, потребляет на винте меньше 2 гб (!!!). Потребление оперативной памяти выглядит следующим образом:
Новый контейнер (без CBS3plus): ~10 Мб.
Длительный простой (с CBS3plus): ~ 2 Гб.
В среднем (с CBS3plus): ~3.1 Гб.
Под нагрузкой (с CBS3plus): 4 Гб.
Т.е. 10 серверов приложений, каждый в своем контейнере, потребляют на хосте около 30 Гб оперативной памяти. Нагрузка на ЦП - ситуативная. От очень высокой под нагрузкой, до почти нулевой в простое. С точки зрения хранилища - работа серверов приложений являет собой нескончаемые операции считывания (которых будет очень много, учитывая огромные количества контейнеров с серверами приложений), поэтому чтобы дисковая подсистема не было узким местом - строго рекомендуется использовать SSD (чтение не вредит SSD, а малые размерыCBS3plus - это еще один огромный плюс, позволяющий почти не задумываться об используемом дисковом пространстве).

Заключение

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

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)