Конфигурируем и запускаем контейнер 1с_postgres
Лабораторная работа №7
(Виртуализацияна базе Linux)
Вdедение
Для пониманиялабораторной работы необходимо определиться с некоторыми терминами: Хост – основная операционная система,на которой установлены виртуальные машины. Виртуальная машина – операционная система, работающая либо на виртуальном оборудовании, либо через гипервизор.Контейнер – изолированная одним процессом системная среда в которой выполняется приложение.
Существует несколько типов виртуализации:
Трансляция – эмуляция происходит на уровне вызовом программ. В данном случае транслятор перехватывает вызовы программы скомпилированной под одну операционную систему и транслирует в вызовы другой. Примером такой виртуализации служит WINE.
Виртуализация на уровне оборудования. В этом случае нужна специальная программа-платформа, которая эмулирует оборудование, на котором может быть установлена любая операционная система, понимающая это оборудование. Отметим, что в виртуальную операционную систему в этом случае устанавливаются специальные драйвера, обеспечивающие трансляцию части вызовов напрямую в операционную систему.
Паравиртуализация. В этом случае оборудование остается существующее, но в виртуальной операционной системе устанавливается программа - гипервизор, как часть ядра, которая позволяет «делить» оборудование между несколькими виртуальные машинами и хостом.
|
|
|
Контейнеры. Виртуализация на подобии портабельныхпрограмм в Windows – изолированная среда со всеми необходимыми библиотеками для работы приложений.
ТрансляторWINE
Для понимания работы транслятора соберем на базе сервера Wineверсии 3 (На сегодня это последняя версия). Wine — это отдельная реализация Windows API.Уникальность транслятора заключается в том, что с помощью этой программы можно запускать Windows приложения в UNIX системах.
Устанавливаем необходимые пакеты для сборки программы
#yum -y groupinstall 'Development Tools'
# yum -y install libX11-devel libxml2-devel libxslt-develfreetype-devel flex bison
Скачиваем последний на текущий момент дистрибутив.
# wgethttps://dl.winehq.org/wine/source/3.0/wine-3.0.tar.xz
Распаковываем его в /usr/src– эта директория обычно используется для сборки программ из исходных кодов.
# tar -xvfwine-3.0.tar.xz–с /usr/src
# cd/usr/src/wine-3.0/
# ./configure --enable-win64 (для 32 битной версии достаточно запустить ./configureбез параметров)
# make
# make install
Проверим работу программы
# su - student
$ winecfg
Рис.1 Консоль настройки WINE
Запустим классическое приложение блокнота в WINE.
$ wine64 notepad
Рис. 2Запуск приложения в WINE
Виртуализация и пара-виртуализация
Два основных подхода к виртуализации – это полная виртуализация (fullvirtualization) и пара-виртуализация (para-virtualization). При полной виртуализации существует прослойка между виртуализируемой операционной системой и аппаратурой как способ осуществления арбитража доступа. Эта прослойка называется гипервизор или монитор виртуальной машины (VMM). Пара-виртуализация сходна с виртуализацией, но гипервизор работает в более согласованном режиме. Это происходит потому, что каждая гостевая операционная система осведомлена о том, что она работает виртуально, поэтому каждая из них работает совместно с гипервизором, для того чтобы виртуализировать базовую аппаратуру.
|
|
|
Примеры полной виртуализации – это коммерческая реализация виртуализации VMware, а также операционная система коммерческой IBM System z9 VirtualMachine (z/VM) для компьютеров IBM zSeriesВ®. Пара-виртуализация поддерживается Xen и User-Mode-Linux (UML).
Как работает виртуализация
Давайте начнем с краткого обсуждения виртуализации и ее составных элементов. В основе реализации виртуализации лежит машина, которую надо виртуализировать. Эта машина может поддерживать или не поддерживать виртуализацию, во втором случае требуется поддержка на следующем уровне, называемом гипервизор. Гипервизор (или VMM) служит как некая абстракция между аппаратной платформой и операционной системой. В некоторых случаях гипервизор является операционной системой; в этом случае он называется базовая операционная система, как показано на Рис. 3
|
|
|
Рис.3 Уровневая модель виртуализации
Над гипервизором находятся гостевые операционные системы, также называемые виртуальными машинами (VM). Эти виртуальные машины представляют собой изолированные операционные системы, которые рассматривают базовую аппаратуру как принадлежащую им. Но на самом деле гипервизор создает у них эту иллюзию.
Преимущества виртуализационной платформы настолько велики, что производители процессоров внесли изменения в кристалл, чтобы непосредственно поддерживать виртуализацию. Это позволяет процессору поддерживать гипервизор напрямую – иначе чем гостевую операционную систему. Вдобавок к состоянию процессора (регистры и т.д.), которые управляются по-разному для VMM и VM, процессор поддерживает виртуализацию ввода/вывода и прерываний.
Сегодня проблема осуществления виртуализации состоит в том, что не вся аппаратура правильно поддерживает виртуализацию. Более старые x86 процессоры выдают разные результаты для определенных команд в зависимости от домена исполнения. Это создает проблему, так как гипервизор должен работать только в наиболее защищенном домене. По этой причине такие решения виртуализации как VMware предварительно сканируют код, который следует выполнять, для того чтобы заменить существующие команды ловушками, с тем чтобы гипервизор мог выполнять их надлежащим образом. Xen, поддерживающий кооперативный метод виртуализации, не требует модификаций, поскольку гостевая система осведомлена о том, что она работает виртуально и соответствующим образом модифицирована. KVM просто игнорирует эту проблему и постулирует, что если вы хотите виртуализации, то вы должны работать на новейшем оборудовании.
|
|
|
Поначалу это кажется слегка неуклюжим, но, принимая во внимание то, что новейшие современные машины (такие как Intel® VT и AMD SVM) поддерживают виртуализацию, не так уж долго осталось ждать того времени, когда это будет нормой, а не исключением.
Гипервизор KVM
Принимая во внимание временную шкалу виртуализационной техники, KVM можно считать относительной новинкой. В настоящее время существуют некоторые действующие opensource методы, такие как Xen, Bochs, UML, Linux-VServer и coLinux, но KVM получил удивительно широкое освещение в прессе. Далее, KVM в действительности сам по себе не является полной виртуализационной схемой, но представляет собой кусок более крупного технического решения.
Подход, который использует KVM, состоит в том, чтобы превратить ядро Linux в гипервизор простой загрузкой модуля ядра. Модуль ядра экспортирует устройство, называемое /dev/kvm, которое делает возможным гостевой режим ядра (вдобавок к обычным режимам ядра и пользователей). С dev/kvm VM имеет свое собственное адресное пространство, отдельное от адресного пространства ядра или любых других работающих VM. Устройства в дереве устройств (/dev) являются общими для всех пользовательских процессов. Но /dev/kvm отличается тем, что каждый процесс, который его открывает, видит другую карту (для поддержания изоляции виртуальных машин).
KVM просто превращает ядро Linux в гипервизор (когда вы инсталлируете модуль ядра kvm). Так как гипервизор является стандартным ядром Linux, он получает преимущества от изменений в стандартном ядре (поддержка памяти, планировщик и т.д.). Оптимизация этих компонент Linux (таких как новый O(1) планировщик в ядре 2.6) дает преимущества как гипервизору (базовая операционная система), так и гостевой операционной системе Linux. Но KVM – не первая машина, которая делает это. UML уже ранее трансформировал ядро Linux в гипервизор. С ядром, работающим как гипервизор, вы можете затем запускать другие операционные системы, такие как другие ядра Linux или Windows.
KVM
Когда KVM инсталлирован, вы можете запустить операционную систему в пространстве пользователей. Каждая гостевая операционная система представляет собой отдельный процесс базовой операционной системы (или гипервизора). Рисунок 2 показывает схему виртуализации с KVM. В основе лежит аппаратная платформа, которая способна к виртуализации (в настоящее время это Intel VT или AMD-SVM процессор). На «голой» аппаратуре работает гипервизор (ядро Linux с модулем KVM). Этот гипервизор выглядит точно также как стандартное ядро Linux, на котором вы можете запускать другие приложения. Но это ядро может также поддерживать гостевые операционные системы, загруженные с помощью утилиты kvm. В конечном счете гостевая операционная система может поддерживать те же самые приложения, что и базовая операционная система.
Рис.4 Компоненты виртуализации с KVM
Вспомним, что KVM представляет собой часть решения проблемы виртуализации. Процессор поддерживает виртуализацию (способность виртуализировать процессор для множества операционных систем). Память виртуализируется с помощью kvm (который будет обсуждаться в следующем разделе). И наконец, система ввода/вывода виртуализируется с помощью слегка модифицированного процесса QEMU (копия которого выполняется с каждым процессом гостевой операционной системы).
KVM вводит новый режим процессов в Linux в существующее ядро и пользовательские режимы. Новый режим называется guest и, как подсказывает его имя, используется для выполнения кодов гостевой операционной системы (или, по крайней мере, некоторых из них). Режим ядра представляет собой привилегированный режим выполнения кодов, в то время как пользовательский режим не является привилегированным (программы, работающие вне ядра). Поэтому режимы выполнения определяются для различных целей, в зависимости от того, что выполняется и с какой целью. Режим guest существует для выполнения кодов гостевой операционной системы, но только для кодов, которые не являются вводом/выводом. В рамках режима guest существуют два стандартных режима, для того чтобы гостевая операционная система работала в режиме guest, но поддерживала стандартные режимы: режим ядра и пользовательский режим, для своего ядра и приложений пространства пользователей. Пользовательский режим гостевой операционной системы существует для того, чтобы выполнять операции ввода/вывода, которые управляются независимо.
Выполнение операции ввода/вывода с гостевой операционной системы обеспечивается QEMU. QEMU – это виртуализационная платформа, которая позволяет виртуализировать все оборудование PC (включая диски, графические адаптеры, сетевые устройства). Любые запросы ввода/вывода, которые делает гостевая операционная система, перехватываются и направляются в пользовательский режим для эмулирования с помощью процесса QEMU.
KVM обеспечивает виртуализацию памяти с помощью /dev/kvm. Каждая гостевая операционная система имеет свое собственное адресное пространство, которое устанавливается, когда создается гостевая система. Физическая память, которая назначается для гостевой операционной системы, является в действительности виртуальной памятью процесса. Набор теневых таблиц поддерживается для преобразования с гостевых физических адресов в реальные физические адреса. Процессор также поддерживает процесс преобразования памяти, передавая управление гипервизору (базовому ядру), когда имеется обращение к не распределенному адресу памяти.
Установка KVM
Проверим готовность оборудования к поддержке KVM
#egrep `(vmx|svm)` /proc/cpuinfo
Если вы уверены, что процессор поддерживает аппаратную виртуализацию, а команда выдала отрицательный результат. Убедитесь что в BIOS включена технология VT-x или AMD-V.
#yum install qemu-kvmlibvirtlibvirt-python libguetdfs-tools vibvirt-installvirt-manager libvirt-client virt-viewer bridge-utils
Запускаемслужбыlibvirt
#systemctl enable libvirtd&&systemctl start libvirtd
Перезагружаем сервер и проверяем работу гипервизора
#lsmod |grep kvm
#virsh info
Запускаем virt-managerи настраиваем виртуальную систему.
Application>> System Tools>> Virtual Machine Manager.
Контейнернаявиртуализация
Docker – новое направление контейнерной виртуализации, отличающееся легкостью и использование KVM. Контейнер сформирован как один процесс, без дополнительных трансляторов и эмуляторов.
Появление виртуальных контейнеров существенно упрощает работу системных администраторов, поскольку вместо утомительной сборки необходимых библиотек достаточно установить готовый контейнер. Контейнер в некотором смысле напоминает виртуальную машину, но имеет ряд отличительных особенностей:
Возможность связывания нескольких контейнеров и масштабирование системы.Значительно более легкая реализация, поскольку нет необходимости эмуляции оборудования.Значительно меньший размер образа, поскольку нет необходимости копировать системные библиотеки.Контейнеры представляют собой слои – снимки, что позволяет легко откатиться на предыдущее состояние контейнера.
В реализации docker следует различать четыре основных сущности. Первая сущность - образ. Для более легкого восприятия можно представлять образ как пакет или класс, на базе которого создаются готовые приложения (в нашем случае – контейнеры). Образ содержит окружение и необходимые библиотеки для запуска контейнера. Как правило, существует базовый образ, который скачивается с общедоступного регистра. На его основе создаются контейнеры или образы, которые формируют сами пользователи. Второй сущностью являются сами контейнеры. Сущность контейнера довольно интересна, поскольку часть окружения и доступ к системным библиотекам он получает от основной системы как обычный процесс, а часть окружения и библиотек получает из метаданных образа. Контейнер можно представить очень легкой «виртуальной машиной», без собственной операционной системы, поскольку все необходимые системные библиотеки он берет от основной системы, а вот внутри, с помощью метаданных и библиотек образа, создается специальное окружение для работы приложений которые, в общем случае, отличаются от приложений основной системы. Таким образом, в контейнере могут работать программы, собранные и настроенные в другой операционной системе на базе Linux (с ядром не ниже 2.6). Более того, пользователи сами могут добавлять программы в работающий контейнер. Эти программы и настройки записываются «поверх» образа. Третья сущность – том. Грубо говоря, том это смонтированная в контейнер директория основной системы, куда сохраняются все данные полученные при работе контейнера. Если этого не сделать, после выключения контейнера вся информация, созданная в нем, будет потеряна. Четвертая сущность - линки. Это связь между контейнерами внутри сети. Надо отметить, что все контейнеры запускаются в отдельной подсети и получают IP адреса случайным образом. Линки позволяют прописать в связанных контейнерах их имена и IP адреса для межсетевого взаимодействия
Краткий перечень опций клиентаdocker при работе с контейнерами
dockerrun– запустить контенер
--rm: сообщает Docker удалять контейнер каждый раз, как только произойдет выход из процесса. Хорошая возможность при тестировании, позволяющая избежать беспорядка
-ti: указывает Dockerу создать псевдотерминал и предоставить его для использования в интерактивном режиме. Это возможность для доступа к контейнеру и она хорошо подходит для быстрого прототипирования и различных игр, но при использовании контейнера в производственных условиях вы не должны включать эти флаги.
-d: - демонировать контейнер. Сделать его службой
-p: - проброспортов<host port:container port>
-v: -папка (том), который монтируется поверх образа контейнера
--link: - name:alias – связь между контейнерами
--name: -имя контейнера
--volumes-from: -связь между данными контейнеров
--expose 2000-2008 – Ptrue – проброс группы портов из хоста в контейнер и обратно.
-m 256m — ограничение памяти
-с 512 — вес контейнера (от 1 до 1024) ЧЕМ МЕНЬШЕ ТЕМ БОЛЬШЕ ПРИОРИТЕТ
-cpuset 0 — привязка к определенному ядру процессора
dockerbuild- построить контейнер по файлу Dockerfile
-f – конфигурационный файл
-m – объем памяти для контейнера
-t – тег контейнера
dockercreate– создаетконтейнер
-v: - том данных (реальная папка на фс)
dockerinspect –проверка контейнера
dockerrm –удаление контейнера
dockerrmi {image} – удаление образа
Установка docker для CentOS 7 x86_64 ничем не отличается от установки обычных служб. Мы устанавливаем и запускаем сервис docker и локальный регистр для сохранения созданных образов.
# yum install docker docker-registry –y
# systemctl enable docker; systemctl start docker
В том случае, если сеть предприятия находится за прокси-сервером, нужно дополнительно настроить docker для работы по протоколам HTTP и HTTPS через прокси. Как оказалось, системные настройки им не подхватываются. Для работы Docker по протоколу HTTP создаем файл
/etc/system/system/docker.service.d/http-proxy.conf
ссодержимым:
==============================================================
[Service]
Environment="HTTP_PROXY=http://proxy.local.ru:3128/" "NO_PROXY=localhost,127.0.0.1"
==============================================================
и файл для работы по протоколуHTTPS
/etc/system/system/docker.service.d/https-proxy.conf
ссодержимым
===============================================================
[Service]
Environment="HTTPS_PROXY=http://proxy.local.ru:3128/" "NO_PROXY=localhost,127.0.0.1"
==================================================================
Перегружаем systemd чтобы принялись изменения.
#systemctldaemon-reload
Ищем готовые образы docker на сервере на www.docker.io
#dockersearch 1с
Скачиваем 2 базовых образа, на основе которых будем конфигурировать наши контейнеры
#docker pull temrdm/1c_postgres –базаданных PostgreSQL для 1С
#docker pull temrdm/1c_server –сервер 1с v8.3
Просмотр скачанных образов
#dockerimages
Схема развертывания сервера 1C на основе контейнеров docker показана на Рис
Порядок конфигурирования и запусков контейнеров следующий: первоначально конфигурируется и запускается контейнер базы данных – 1с_postgres. Далее запускается контейнер 1с_server, в котором собран готовый сервер 1С. Между контейнерами организуем линк.
Конфигурируем и запускаем контейнер 1с_postgres
#dockerrun -d --name 1c_postgres -p 5432:5432 --restart=always -v /var/lib/postgres/data:/var/lib/postgresql/data -ePOSTGRES_PASSWORD=postgres -hdata.local.rutemrdm/1c_postgres
В данном случае мы запускаем контейнер из образа temrdm/1c_postgresc опцией автоматической перезагрузки (--restart=always) в режиме службы (-d), пробрасываем порт 5432 между контейнером и хостовой машиной (-p 5432:5432), где первое значение - порт хостовой машины, второе – порт контейнера, создаем том /var/lib/postgres/data и монтируем его в контейнер (теперь все данные базы данных сохраняются на хостовой машине и в случае выключения контейнера они не потеряются), задаем переменную среды POSTGRES_PASSWORD – определяющую пароль администратора postgres в базе данных и наконец, даем имя контейнеру –hdata.local.ru.
Открываемпорт
#firewall-cmd --permanent --add-service=postgresql
#firewall-cmd --reload
Проверяемпроброшенныепорты
#dockerport 1c_postgres
Перегружаем операционную систему.
Дата добавления: 2018-06-27; просмотров: 237; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!