Герой, которого мы заслуживаем
Если максимально упростить, то Docker делает следующее. К примеру, вы написали некое приложение и хотите передать его заказчику, или переносите его из dev в prod, или просто просите друга помочь его доработать. Для этого вам надо как-то передать это приложение. Вы можете скинуть его кодом, но тогда все накладные расходы по разрешению зависимостей для запуска приложения кладутся на принимающую сторону. Используя Docker, вы можете подготовить образ, в который будут уже заложены все необходимые компоненты и само приложение, и быть спокойным, что оно поведет себя именно так, как вы задумывали, когда из этого образа на второй площадке будет запущен контейнер.
Происходит это так. Вы скачиваете (или создаете) базовый образ из Docker HUB (эдакий магазин образов с различными дистрибутивами Linux и предустановленным набором утилит), пишете dockerfile (сценарий, описывающий, что мы хотим сделать в этом образе: установить дополнительный софт или добавить библиотеки, к примеру), подготавливаете образ с помощью dockerfile, а затем просто запускаете из него контейнер. При запуске контейнера из образа накладываются последние штрихи в виде hostname, сетевой части, ресурсов и прочего. Так называемый верхний слой, который отсутствует в исходном образе. Все. Приложение запущено, при этом мы экономим время на доставку и разработку, а со стороны инфраструктуры — ресурсы.
Спустя всего год после выхода Docker, в 2014 году, компания Google открывает миру код проекта Kubernetes, созданного для оркестрации контейнерной инфраструктуры. Kubernetes призван упростить создание и управление распределенного пространства контейнеров, позволяя создавать кластеры для автоматической репликации, балансировки нагрузки, контроля и мониторинга, а также для упрощения связности между ними и облегчения масштабирования решения. Kubernetes — далеко не единственное решение, позволяющее управлять контейнерной инфраструктурой, но по праву одно из самых популярных.
5. Плагин для Total Commander
Работающим с Total Commander только лишь для просмотра и копирования ценных данных, хранящихся на диске ВМ, далеко ходить не нужно. Вопрос решается внутри этого файлового менеджера с помощью плагина к нему DiskInternals Reader. Первичная миссия этого плагина – реализация доступа в среде Windows к разделам и носителям с файловыми системами, используемыми в Linux. И неподдерживаемыми Windows. В довесок к основным возможностям плагин может монтировать для чтения диски ВМ форматов VMDK, VDI, VHD, VHDX и HDS.
Скачиваем плагин:http://wincmd.ru/plugring/diskinternals_reader.html
Распаковываем его внутри Total Commander. Отвечаем «Да» на предложение установки. Следуем шагам установочного мастера.
Запускаем Total Commander (принципиально) от имени администратора. Переключаемся на «Сеть / FS плагины». Заходим в «DiskInternals Reader».
Далее – «Mount Image».
Выбираем тип диска ВМ. Жмём «Next».
В обзоре указываем папку ВМ. Затем увидим все подключённые к машине диски. Можем снять галочки с ненужных, если их несколько. И кликаем «Mount».
Жмём Ctrl+R для обновления содержимого панелей Total Commander. И увидим примонтированные разделы виртуального диска.
Его содержимое копируем обычным для Total Commander образом — кнопкой внизу или клавишей F5. Процедура размонтирования дисков плагином не предусматривается. Да она как таковая и не нужна: достаточно просто перезапустить Total Commander.
Виртуальная инфраструктура
Такое шапито не могло долго продолжаться, и бизнесу задолбалось терять деньги на новом оборудовании. И вот тут в их жизнь вошла виртуализация. Такое магическое, не понятное слово, что из будущего. Технология виртуализации, помогла консолидировать ресурсы серверов, позволив запускать в рамках одного физического сервера, множество изолированных операционных систем, искренне считающих себя не зависимыми. на отдельном сервере, имея виртуальное оборудование. Клиенту как потребителю, вообще не интересует вообще до лампочки на чем реализован его сервис, будь то почта будь то база данных, ему главное продукт, но для бизнеса выгоднее когда в рамках одного сервера они могли бы запихнуть на него больше сервисов и продать их клиенту. Бала решена еще одна задача это поддержка старых приложений, которые написаны под какой нибудь Windows 95, а обновиться то хочется, в итоге создаете с ним отдельную виртуальную машину и живете спокойно. Проще стал переход от одного железа к другому, перенос осуществляется на лету без выключения, в большинстве случаев. Так что при поломке физического сервера, у вас будет возможность запустить виртуальную машину на другом, без проблем.
Пример из жизни: Есть сервер HP ему 4 года, ку него закончилась гарантия. В один из прекрасных дней на нем стали крошится диски, замена одного из таких стоила 800 баксов. За эти деньги были куплены 3 SSD Samsung evo 850, чувствуете разницу. В итоге на сервере были установлены все ssd и он был превращен в хост виртуализации, где на него переехали все те же виртуалки с теме же сервисами. А если бы был просто физический сервер, то все накрылось бы медным тазом. Виртуализация спасла нас от большого геморроя.
История виртуализации
История данной задумки и технологии началась еще в далеких 90 годах, первым ее реализовала компания VMware. Она предложила вариант, что ресурсы одного большого монстра, можно поделить на всех и жить по братски, так появилась концепция гипервизора. Гипервизор — это прослойка между ос и железом, которая помогает реализовать виртуализацию. В VMware это VMkernel процесс.
Виртуальная инфраструктура выглядит следующим образом, есть ESXi host, на нем лежит прослойка hepervisor VMware vSphere по верх которого уже лежат виртуальные машины. И все подключения FC, NFS, ISCSI идут только к ESXi host, который отдает все это дело гипервизору, где он уже дальше перераспределяет все ресурсу страждущим.
Перенос операционной системы в гипервизор ESXi при помощи Remote Windows machine
Тут процедура точно такая же, только вместо Powered on выбираем Powered off и Remote Windows machine, а поскольку это машина удалённая, то нам нужно будет
дополнительно прописать доступы к ней (ip адрес, имя пользователя и пароль). После того как соединение с машиной-источником установим нам будет предложено выбрать в диалоговом окне каким образом
мы удалим с конвертируемой машины агента Standalone. Автоматически после переноса или самостоятельно своими ручками чуть позже.
Дальше процесс никак не отличается от клонирования . Не вижу смысла повторять одно и тоже по нескольку раз.
Автоматическое внедрение VMware Tools
Пакет VMware Tools внедряется автоматически в рамках работы функции быстрой установки гостевой ОС. Эта функция в VMware Workstation применяется автоматически, если программа распознаёт дистрибутив Windows. Когда мы запускаем создание новой машины,
на втором этапе после указания ISO-образа установки гостевой ОС увидим отметку об использовании быстрой установки.
Это значит, что установка будет проведена полностью в автоматическом режиме: гипервизор сам произведёт разметку виртуального диска, установит гостевую ОС без нашего участия и внедрит VMware Tools. Всё, что нам нужно – это указать на следующем этапе мастера создания машины информацию о быстрой установке. Для систем Linux это название компьютера, имя пользователя и пароль.
Для Windows это редакция дистрибутива и имя учётной записи. При желании можем также указать пароль учётной записи и лицензионный ключ.
Функция быстрой установки работает только с поддерживаемыми дистрибутивами операционных систем. Функция может не работать с некоторыми кастомными сборками операционных систем. И не работает с версиями, вышедшими позднее обновления VMware Workstation. Поэтому чтобы иметь возможность использовать быструю установку для обновляемых накопительными апдейтами версий Windows 10 (1809, 1903, 1909 и т.п.), необходимо постоянно обновлять саму программу VMware Workstation. Поддержку новых дистрибутивов для быстрой установки компания VMware реализует по мере их официальных релизов.
2. Гипервизоры от VMware
Компания VMware – это разработчик многих профильных продуктов, в частности, для работы с серверными технологиями и технологиями виртуализации. Из числа последних для использования на ПК – это гипервизоры Fusion для Mac OS и Workstation Pro в версиях для Windows и Linux. Всё это платные программы, стоит лицензия Workstation Pro для Windows порядка 20 тыс. руб. У программы есть месячная триал-версия, скачать её можно на сайте компании VMware:
Workstation Pro в актуальной версии программы 15 состоит из нескольких компонентов – редактора сетевых параметров Virtual Network Editor, самой программы Workstation Pro и урезанной её версии Workstation Player.
Workstation Player – это так называемый проигрыватель ВМ. С его помощью можно создавать, настраивать ВМ, работать с ними. Это более легковесная и шустрая программа, чем Workstation Pro. И стоит лицензия на проигрыватель дешевле – порядка 12 тыс. руб. Но проигрыватель лишён отдельных возможностей полноценного гипервизора, в частности, работы с функцией снапшотов. Workstation Player – это и входящий в состав Workstation Pro компонент, и отдельная программа. Она может быть скачана с сайта VMware и установлена отдельно от Workstation Pro. Триал-срок в проигрывателе активен по умолчанию.
При запуске же Workstation Pro факт использования триал-срока необходимо указать.
Продукты VMware, увы, не поддерживают русский язык. Но в Интернете можно найти и скачать бесплатный русификатор программы Workstation Pro.
Система виртуализации VMware
Виртуализация создает уровень абстракции на аппаратном обеспечении, который разделяет аппаратные элементы одного компьютера на несколько виртуальных, называемых виртуальными машинами (ВМ). Каждая виртуальная машина функционирует под управлением собственной операционной системы и ведет себя как самостоятельный компьютер, хотя работает только на части фактического железа.
Виртуализация VMware позволяет более эффективно использовать аппаратное обеспечение и окупить расходы. Благодаря технологии провайдеры публичных и частных облаков могут обслуживать большее количество пользователей.
KVM
KVM — простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. Он позволяет за минимальные сроки развернуть площадку виртуализации и организовать виртуализацию под управлением операционной системы Linux. В процессе работы KMV осуществляет доступ к ядру операционной системы через специальный модуль (KVM-Intel или KVM-AMD). Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые разные процессоры и гостевые операционные системы, в том числе Linux, BSD, Solaris, Windows и др. Кстати, все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно этот гипервизор.
Поскольку гостевые операционные системы взаимодействуют с гипервизором, который интегрирован в ядро Linux, у гостевых операционных систем есть возможность обращаться напрямую к оборудованию без нужды изменения гостевой операционной системы. За счет этого замедления работы гостевой операционной системы почти не происходит.
KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и другие образы, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другое железо.
Благодаря поддержке немодифицированных образов VMware, физический сервер можно легко виртуализовать при помощи все той же утилиты VMware vServer Converter, а затем перенести полученный файл в гипервизор.
Установка KVM в операционной системе Linux заключается в инсталляции пакета KVM и библиотеки виртуализации Libvirt, а также в тщательной настройке среды виртуализации. В зависимости от используемой на хосте операционной системы необходимо настроить мост или подключение к VNC-консоли, с помощью которой виртуальные машины будут взаимодействовать с хостом.
Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сетевым интерфейсам отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС.
Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту Virsh, реализующую все необходимые функции. Для удобного управления виртуальными машинами можно дополнительно установить пакет Virt-Manager.
У KVM нет встроенных инструментов, подобных Fault Tolerate для VMware, поэтому единственный способ создать кластер высокой доступности — использовать сетевую репликацию при помощи DRDB. Кластер DRBD поддерживает только два узла, а узлы синхронизируются без шифрования. То есть для более безопасной связи необходимо использовать VPN-соединение.
Кроме того, для построения кластера высокой доступности понадобится программа Heartbeat, которая позволяет обмениваться служебными сообщениями о своем состоянии узлам в кластере, и Pacemaker — менеджер ресурсов кластера.
Гипервизор KVM распространяется как продукт с открытым исходным кодом, а для корпоративных пользователей существует коммерческое решение Red Hat Virtualization (RHEL), основанное на KVM и платформе управления виртуальной инфраструктурой oVirt.
Несомненным преимуществом этого гипервизора является то, что он способен работать на любом сервере. Гипервизор довольно неприхотлив к ресурсам, что позволяет с легкостью использовать его для задач тестирования.
Следует учесть, что у KVM нет службы поддержки. Если что-то не получится, можно рассчитывать на форумы и помощь сообщества. Или перейти на RHEL.
Вначале был chroot
Прадедушкой современных контейнеров был chroot, разработка которого началась в 1979 году для системы Unix V7. Этот механизм менял корневую директорию для выполнения приложений и их дочерних процессов, что, по сути, изолировало их в пределах отдельной файловой системы, куда осуществлялся chroot.
Технология была представлена после трех лет разработки в 1982 году и не эволюционировала вплоть до 2000, пока в операционной системе FreeBsd не появился механизм Jail, отличающийся от chroot еще большей изоляцией окружения. На материнской системе создавались экземпляры FreeBsd, использующие общее ядро, но с обособленной сетью, набором приложений и файловой системой. При этом доступ к общей памяти тоже был ограничен, что сделало Jail действительно первой системой контейнеризации в околосовременном представлении.
Так в чем же основные отличия и преимущества данного подхода? Главное отличие от полной виртуализации (когда используются гипервизоры) заключается в том, что не происходит полной эмуляции аппаратного обеспечения и запуска поверх обособленного набора абстрактного железа отдельного экземпляра операционной системы. Контейнеризация же реализуется на уровне операционной системы, максимально изолируя выполняемый контейнер, но используя при этом единое ядро материнской системы и работая с контейнерами как с локальными ресурсами. Это дает нам такие преимущества, как скорость запуска, плотность контейнеров, их размер и возможность работы с общими страницами памяти, когда несколько контейнеров при взаимодействии с одним файлом читают из одной страницы — в отличие от отдельных виртуальных машин.
Вслед за Jails достаточно быстро аналогичное решение появляется в сообществе Linux (vserver в 2001 году). Далее события развивались лавинообразно. 2004 год ознаменовался появлением Solaris Containers, 2005 — Open VZ, 2008 — LXC, 2011 — Warden, а в 2013 компания Google представила свое решение под названием LMCTFY (Let Me Contain That For You), прекратившее свое существование в 2015 году.
Но нас больше интересует событие, произошедшее в том же 2013-м и поднявшее технологию контейнеризации на новый уровень популярности. Мы говорим, конечно же, о появлении Docker. До этого момента контейнерная виртуализация использовалась преимущественно в решениях VPS из-за большой плотности и экономии ресурсов, позволяя провайдерам получить более 60% выгоды по сравнению с виртуальными машинами. Но Docker позволил нам взглянуть на эти технологи совершенно с другого ракурса.
Гипервизор ESXi
Гипервизор – это программный продукт низкого уровня, взаимодействующий с ресурсами физического компьютера (называется хостом) и распределяющий эти ресурсы между другими ОС, известными как гостевые. Нестабильная работа одной из гостевых ОС или ее полный отказ не отражается на производительности других операционных систем на хосте. Есть два типа гипервизоров.
VMware ESXi — гипервизор типа 1. Он обеспечивает уровень виртуализации, который абстрагирует процессор, хранилище, память и сетевые ресурсы физического хоста в несколько виртуальных машин. Это означает, что приложения, работающие на виртуальных машинах, могут получить доступ к этим ресурсам без прямого доступа к основному оборудованию.
VMware ESXi – это хорошо зарекомендовавший себя серверный гипервизор, но вендор также предоставляет программное обеспечение, виртуализирующее настольные операционные системы. Это гипервизор второго типа – VMware Workstation. Если первый полностью заменяет базовую ОС, то тип 2 работает как приложение в настольной ОС.
Платформа виртуализации VMware vSphere включает ПО для гипервизоров ESXi и vCenter Server — для управления несколькими гипервизорами.
Инструмент представлен в трех конфигурациях. Каждая из них поддерживает хранение виртуальных машин на основе политик, миграцию рабочих нагрузок в реальном времени и встроенные функции кибербезопасности. В число расширенных возможностей входят шифрование на уровне ВМ, управление контейнерами, балансировка нагрузки и централизованное управление сетью.
Физическая и виртуальная архитектура
Ниже представлена картинка как выглядит Physical архитектура и виртуализация vmware. В физической архитектуре, ос функцианирует по верх железного оборудования. Рассматривая виртуализацию vmware, тут уже все немного иначе. Отличие в прослойке гипервизора ESXI (VMware vSphare). VMware vSphare Позволяет запускать экземпляры виртуальных машин, эмулируя для них оборудование. В такой реализации будет другая схема общения с ресурсами. Об этом мы поговорим в будущем.
В мире виртуализации есть одна вещь, которая никогда не виртуализовывается, это друзья процессор CPU. Виртуализация vmware или MS этого делать не умеют. Стартуя виртуальная машина, в зависимости от настроек получает одно или более ядер, виртуалка осознает какой тип CPU, версия и частотность на нем, все команды она на прямую отправляет на него
По этому очень важно, правильное распределение по ядрам CPU, чтобы виртуальные машины не мешали друг другу
Что касается виртуализации сети, тут дело выглядит следующим образом. Если рассматривать физический сервер, то имея у себя сетевой адаптер, он использует его монопольно, со всей полосой пропускания. Рассматривая virtual архитектуру, то есть виртуальный коммутатор, в который подключенный виртуализованные сетевые адаптеры, а виртуальный коммутатор, общается уже с физическим сетевым адаптером или адаптерами. Вся пропускная способность делится на все виртуальные машины, но можно настроить приоритеты.
Осталось рассмотреть еще дисковую подсистему
Слева классическая ситуация с железным хостом, не важно как ос, использоваться все будет в монопольном режиме. Рассматривая виртуальные жесткие диски, тут иначе
Каждая ос думает, что у нее настоящий жесткий диск, но по факту это файл лежащий на общем хранилище, как и файлы других виртуальных машин. И не важно по какому протоколу соединено с хостом хранилище.
Надеюсь вы теперь представляете что такое виртуализация и как ее использовать, а главное для чего. Далее советую вам почитать, Виртуальная машина, что это такое.
Материал сайта pyatilistnik.org
