Hi there! Our project relies on ads or donation to keep the site free to use. Please sending a donation . Thanks!
Подождите, пожалуйста, выполняется поиск в заданном разделе

Эмуляторы операционных систем. Виртуализация, эмуляция, Контейнеризация ,симуляция

ВИРТУАЛИЗАЦИЯ , ЭМУЛЯЦИЯ , Симуляция и Контейнеризация : ОТЛИЧИТЕЛЬНЫЕ ХАРАКТЕРИСТИКИ

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

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

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

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

КАКАЯ МЕЖДУ НИМИ РАЗНИЦА?

Суть эмуляции заключается в том, что одна система технически может имитировать другую.

Пример – если структура ПО работает в системе А, но не в системе В, мы создаем внутри системы В эмуляцию работы системы А. Вследствие этого, ПО спокойно работает на эмуляцию системы А.

Данный пример можно перенести и на виртуализацию, которая, помимо системы А. разделена еще на 2 выделенных сервера (В и С).

Оба сервера являются независимыми техническими контейнерами, обладающими персонализированным доступом к программным ресурсам – ОЗУ, ЦП и хранилищам памяти – их можно свободно перезагрузить независимо друг от друга. Их «поведение» всецело идентично поведению настоящего программного оборудования.

Каждая технология имеет свои преимущества и недостатки.

1 Архитектурные различия контейнеров и виртуальных машин

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

Рисунок 1. В виртуализации компьютеров гипервизор или монитор виртуальных машин (VMM) обеспечивают изоляцию между каждой гостевой ОС. В контейнерах операционная система хоста обеспечивает изоляцию между каждым контейнером.

Разница в архитектуре предлагает следующие ключевые предложения для ИТ-персонала и предприятий:

  • Непрерывная интеграция, развертывание и тестирование. В организациях, управляемых DevOps, организации могут использовать контейнеры для упрощения процессов в конвейере CI / CD. Контейнеры работают как единая инфраструктурная среда, поэтому разработчикам не нужно выполнять сложные задачи конфигурации для каждого спринта SDLC, поскольку рабочие нагрузки переносятся через физические ресурсы.
  • Переносимость рабочих нагрузок. Рабочие нагрузки ИТ могут переключаться между различными экземплярами инфраструктуры и виртуальными средами без значительных изменений конфигурации или переделки кода приложения.
  • Качество и соответствие программного обеспечения. Прозрачное сотрудничество между разработчиками и персоналом по тестированию при предоставлении рабочих частей приложения приводит к повышению качества программного обеспечения, ускорению циклов разработки и улучшению соответствия.
  • Оптимизация затрат: контейнеры максимизируют использование ресурсов в собственных изолированных виртуальных средах. Это позволяет организациям точно планировать пропускную способность и потребление инфраструктуры.
  • infrastructure agnostic: Контейнеры сделать агностик компоненты приложения инфраструктуры, что позволяет организациям перемещать рабочие нагрузки между серверами голых металлическими в виртуализированные среды для облачной инфраструктуры в ответ на изменяющиеся потребности бизнеса.

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

2 ЭМУЛЯЦИЯ

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

Эмуляция может иметь особый эффект при таких пользовательских сценариях:

  • Старт операционной системы, изначально предназначенной для другого системного оборудования (запуск консольной игры на ПК, работа с Windows на Mac OS );
  • Старт устаревшей версии ПО после того как сопоставимое с нею оборудование устареет.

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

3 ВИРТУАЛИЗАЦИЯ

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

К наиболее явным преимуществам такого способа взаимодействия с программными компонентами можно отнести:

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

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


У виртуализации есть несколько измерений, которые условно можно назвать «Тип» и «Способ виртуализации».

Рисунок 2 Типы и способы виртуализации


Типы виртуализации

Виртуализация серверов

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

  • Но может еще быть объединение нескольких физических серверов в один логический для решения определенной задачи
  • Распределенность + виртуализация = GRID системы

Виртуализация ресурсов

Ресурсы — это оперативная память, жесткие диски, процессоры. Они также могут быть нарезаны и розданы по частям разным пользователям.

Виртуализация приложений

Виртуализация приложений — это то, что мы уже знаем как PaaS и SaaS


Способы виртуализации

Полная виртуализация и паравиртуализация

Основные методы виртуализации — это полная виртуализация и паравиртуализация. Схема обоих методов очень похожа. Есть гипервизор и виртуальные машины с гостевыми OS. При полной виртуализации в гостевую OS не вносятся никакие изменения. При паравиртуализации устанавливаются оптимизированные образы для определенного гипервизора. Это позволяет максимально использовать аппаратные ресурсы и не требует никаких изменений от приложений. Примером системы, реализующей полную виртуализацию, является VMware, пример паравиртуализации — Xen и KVM.

Рисунок 3 Виртуализация с использованием гипервизора


Еще выделяют несколько способов виртуализации:

Виртуализация уровня операционной системы


Особенностью является, что гостевая OS может быть только одна. Примером виртуализации на уровне OS является Linux-VServer:

Рисунок 4 Виртуализация без использования гипервизора

Эмуляция оборудования


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

Рисунок 5 Виртуализация оборудования

Эмуляция библиотек OS


И для полноты картины добавлю эмуляцию библиотек. Это способ, при котором эмулируется не вся OS, а только часть. Например, Wine в Linux — эмуляция библиотек для Windows-приложений.

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

Рисунок 6 Эиуляция библиотек операционной системы


Облачные платформы располагаются над набором виртуальных машин, полностью изолируют приложение как от железа, так и от структуры виртуальной среды. Облачные платформы используются для автоматичеcкого и ручного scale in / scale out, запуска / остановки / конфигурирования VM и приложений. Когда имеет смысл оставаться в виртуализации, а когда оставаться в облаке? Концепция следующая: когда всего много — облако, мало — виртуализация:

  • Для задач с большим числом виртуальных серверов — лучше облако, для задач с 10-20 виртуалками можно не разворачивать облачную платформу.
  • Если требуется постоянно менять конфигурацию ресурсов — облако.
  • Много пользователей, данных, клиентов — облако.

4 Сравнение возможностей вируальных машин

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

4.1 VMWARE

VMWare Workstation – очень популярная и удобная в использовании виртуальная машина, использующаяся на профессиональной основе.

Преимущества продукта:

  1. Есть некоммерческая версия под названием VMWare Workstation Player, которую можно использовать для ознакомительных целей;
  2. Простой и интуитивно понятный графический интерфейс;
  3. Установка новой ОС существенным образом упрощена, по сравнению с установкой традиционной версии программного обеспечения на ПК;
  4. Программа позволяет делать скриншоты операционки, с помощью которых можно восстанавливать предыдущее состояние системы;
  5. Отменная техническая надежность и стабильность работы;
  6. Быстрая работа и хорошая производительность;
  7. Функция установки пароля на используемые виртуальные машины;
  8. Стабильная поддержка 3D графики.

Недостатки:

  1. VMWare Workstation Player – платный продукт для коммерческих целей;
  2. VMWare Workstation Pro – можно использовать только после оформления подписки;
  3. Отдельные компоненты программы функционируют с разными операционными системами.

4.2 VIRTUAL BOX

Весьма распространенная виртуальная машина с приличным набором полезного технического функционала.

Преимущества:

  1. Virtual Box – позволяет взаимодействовать с большим перечнем операционных систем, как для целей непосредственной установки Virtual Box, так и для установки «гостевых» продуктов;
  2. Можно сделать скриншоты операционной системы, позволяющие восстановить предыдущее состояние системы;
  3. В Интернете распространяется на бесплатной основе вместе с открытым программным кодом, а также в дополнении с лицензией GPLv2;

Недостатки:

  1. Продукт не можно считать максимально продуктивным в сравнении с иными, платными аналогами;
  2. Постоянно встречаются ошибки, различные баги, крэши и летальные зависания;
  3. Минимальная техническая поддержка 3D графики;
  4. Очень сложный графический интерфейс, по сравнению с платными программами и компонентами.

4.3 HYPER-V

Данный продукт изначально позиционировался как прямая замена компонентам Microsoft Visual PC.

Преимущества:

  1. Доставляется вместе с большим количеством вариаций систем Windows 10;
  2. Поддерживает процесс установки гостевых операционных систем, а также все старые версии операционной системы Windows;
  3. Есть функция установки гостевых операционных систем Linux и FreeBSD.

Недостатки:

  1. Нет возможности запустить из более ранних и «древних» версий операционной системы Windows;
  2. Не получится установить продукт под Mac OS;
  3. Не очень удобный и интуитивно понятный графический интерфейс, если сравнивать эту программу с компонентами Virtual Box и VMWare.

4.4 BOOT CAMP

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

Преимущество:

  • Предоставляется вместе с приобретённым Mac компьютером.

Недостатки:

  • Запускать Windows можно исключительно на правах гостевой операционной системы;
  • Иногда работает нестабильно с некоторыми системными компонентами, такими как сенсоры движения и прочее;
  • Могут возникать операционные ошибки с редактированием размера используемого раздела.

4.5 PARALLELS DESKTOP

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

Преимущества:

  • Пользователь запросто может использовать ранее созданные данные и компоненты от продукта Boot Camp;
  • Существует поддержка для различных гостевых операционных систем, таких как Linux, Windows, разные версии Mac OS и прочее;

Недостатки:

  • Работает исключительно с Mac OS;
  • Продукт является платным, но есть 14-дневная бесплатная версия для ознакомления.

4.6 NOX

Специализированный эмулятор под операционную систему Android.

Преимущества продукта:

  • Относительно «бесплатная» программа;
  • Продукт Nox очень «легкий» и технически «быстрый»;
  • Специализированный маппинг клавиш под жесты Android;
  • Детализировано конфигурируется.

Недостатки:

  • Необходима установка прочих приложений и компонентов;
  • Можно использовать исключительно для работы с Андроид системой.

4.7 BLUESTACKS

Современный эмулятор операционный системы Андроид.

Преимущества:

  • Относительно «бесплатный» продукт, в котором есть ознакомительная версия на пробный период;
  • Большое разнообразие параметров для тонкой настройки;
  • Легкая установка приложений;
  • Функции для взаимодействия на вкладках с возможностью быстрого переключения.

Недостатки:

  • Заточен под работу только с гостевым Андроид;
  • Много рекламы и сторонних приложений;
  • «Кушает» много оперативной памяти, а значит, запросто может заставить тормозить относительно не мощный или слабый компьютер.

4.8 APPETIZE.IO

Интернет-эмулятор под операционные системы Android и iOS.

Преимущества:

  • Есть бесплатная версия (100 минут за 1 месяц и один активный юзер);
  • Большой ассортимент приложений и систем для воспроизведения эмуляции под самые востребованные устройства и технические компоненты.

Недостатки:

  • Больше половины из предоставленного функционала доступна только в платной версии продукта.

4.9 ANDY OS

Специализированный эмулятор для операционной системы Андроид.

Преимущества:

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

Недостатки:

  • Можно использовать только для работы с продуктами под Андроид;
  • Не все 3D игры поддерживаются в корректной форме;
  • Возникают периодические зависания;
  • Постоянное появление рекламных вставок;
  • Некоторые версии содержат официально не заявленные функции и параметры, позволяющие распространению вредоносных компонентов.

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

5 Контейнеризация

5.1 Основные понятия


В последнее время все больше используются системы контейнеризации, такие как Docker или Kubernetes. Они позволяют автоматически разворачивать подготовленные образы OS в основном для целей автоматического тестирования и для систем CI. Контейнеры очень похожи на виртуальные машины, но для них не требуется гипервизор, а только соответствующий движок:

Рисунок 6 Контейнерезация

Контейнеризация (виртуализация на уровне операционной системы, контейнерная виртуализация, зонная виртуализация) — метод виртуализации, при котором ядро операционной системы поддерживает несколько изолированных экземпляров пространства пользователя вместо одного. Эти экземпляры (обычно называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны отдельному экземпляру операционной системы. Для систем на базе Unix эта технология похожа на улучшенную реализацию механизма chroot. Ядро обеспечивает полную изолированность контейнеров, поэтому программы из разных контейнеров не могут воздействовать друг на друга.

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

Существуют реализации, ориентированные на создание практически полноценных экземпляров операционных систем (Solaris Containers, контейнеры Virtuozzo, OpenVZ), так и варианты, фокусирующиеся на изоляции отдельных сервисов с минимальным операционным окружением (jail, Docker).

Таблица 1 Сравнение реализаций контениризации

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

5.2 Контейнеризация с использованием Docker

Начнем с того, для чего же нам нужен Docker:

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

Предыстрория Docker


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

  • процессор,
  • память,
  • дисковое пространство,
  • сетевые интерфейсы.




На каждой ВМ устанавливаем нужную ОС и запускаем приложения. Недостатком такого подхода является то, что значительная часть ресурсов хоста расходуется не на полезную нагрузку(работа приложений), а на работу нескольких ОС.

Контейнеры Docker


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

  • файловая система
  • дерево процессов
  • сетевые интерфейсы
  • и др.




Т.о. приложение, запущенное в контейнере думает, что оно одно во всей ОС. Изоляция достигается за счет использования таких Linux-механизмов, как namespaces и control groups. Если говорить просто, то namespaces обеспечивают изоляцию в рамках ОС, а control groups устанавливают лимиты на потребление контейнером ресурсов хоста, чтобы сбалансировать распределение ресурсов между запущенными контейнерами.

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

Образы Docker


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

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

Образ состоит из слоев, каждый из которых представляет собой неизменяемую файловую систему, а по-простому набор файлов и директорий. Образ в целом представляет собой объединенную файловую систему (Union File System), которую можно рассматривать как результат слияния файловых систем слоев. Объединенная файловая система умеет обрабатывать конфликты, например, когда в разных слоях присутствуют файлы и директории с одинаковыми именами. Каждый следующий слой добавляет или удаляет какие то файлы из предыдущих слоев. В данном контексте «удаляет» можно рассматривать как «затеняет», т.е. файл в нижележащем слое остается, но его не будет видно в объединенной файловой системе.
Можно провести аналогию с Git: слои — это как отдельные коммиты, а образ в целом — результат выполнения операции squash. Как мы увидим дальше, на этом параллели с Git не заканчиваются. Существуют различные реализации объединенной файловой системы, одна из них — AUFS.

Для примера рассмотрим образ произвольного .NET приложения MyApplication: первым слоем является ядро Linux, далее следуют слои ОС, среды исполнения и уже самого приложения.



Слои являются read only и, если в слое MyApplication нужно изменить файл, находящийся в слое dotnet, то файл сначала копируется в нужный слой, а потом в нем изменяется, оставаясь в исходном слое в первозданном виде.



Неизменяемость слоев позволяет использовать их всеми образами на хосте. Допустим MyApplication — это веб-приложение, которое использует БД и взаимодействует также с NodeJS сервером.



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

Подытожим:

  • Образ — это набор файлов, необходимых для работы приложения на голой машине с установленным Docker.
  • Образ состоит из неизменяемых слоев, каждый из которых добавляет/удаляет/изменяет файлы из предыдущего слоя.
  • Неизменяемость слоев позволяет их использовать совместно в разных образах.

Docker-контейнеры


Docker-контейнер строится на основе образа. Суть преобразования образа в контейнер состоит в добавлении верхнего слоя, для которого разрешена запись. Результаты работы приложения (файлы) пишутся именно в этом слое.



Например, мы создали на основе образа с PostgreSQL сервером контейнер и запустили его. Когда мы создаем БД, то соответствующие файлы появляются в верхнем слое контейнера — слое для записи.



Можно провести и обратную операцию: из контейнера сделать образ. Верхний слой контейнера отличается от остальных только лишь разрешением на запись, в остальном это обычный слой — набор файлов и директорий. Делая верхний слой read only, мы преобразуем контейнер в образ.



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

Docker


Когда мы устанавливаем докер на локальную машину, то получаем клиент (CLI) и http-сервер, работающий как демон. Сервер предоставляет REST API, а консоль просто преобразует введенные команды в http-запросы.

Registry Docker


Registry — это хранилище образов Docker. Самым известным является DockerHub. Он напоминает GitHub, только содержит образы, а не исходный код. На DockerHub также есть репозитории, публичные и приватные, можно скачивать образы (pull), заливать изменения образов (push). Скачанные однажды образы и собранные на их основе контейнеры хранятся локально, пока не будут удалены вручную.



Существует возможность создания своего хранилища образов, тогда при необходимости Docker будет искать там образы, которых еще нет локально. Надо сказать, что при использовании Docker хранилище образов становится важнейшим звеном в CI/CD: разработчик делает коммит в репозиторий, запускаются тесты. Если тесты прошли успешно, то на основе коммита обновляется существующий или собирается новый образ с последующим деплоем. Причем в registry обновляются не целые образы, а только необходимые слои.



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

Dockerfile


Dockerfile представляет собой набор инструкций, на основе которых строится новый образ. Каждая инструкция добавляет новый слой к образу. Для примера рассмотрим Dockerfile, на основе которого мог бы быть создан образ рассмотренного ранее .NET-приложения MyApplication:

FROM microsoft/aspnetcore
WORKDIR /app
COPY bin/Debug/publish .
ENTRYPOINT["dotnet", "MyApplication.dll"]


Рассмотрим отдельно каждую инструкцию:

  1. определяем базовый образ, на основе которого будем строить свой. В данном случае берем microsoft/aspnetcore — официальный образ от Microsoft, который можно найти на DockerHub
  2. задаем рабочую директорию внутри образа
  3. копируем предварительно спаблишенное приложение MyApplication в рабочую директорию внутри образа. Сначала пишется исходная директория — путь относительно контекста, указанного в команде docker build, а вторым аргументом — целевая директория внутри образа, в данном случае точка обозначает рабочую директорию
  4. конфигурируем контейнер как исполняемый: в нашем случае для запуска контейнера будет выполнена команда dotnet MyApplication.dll


Если в директории с Dockerfile выполнить команду docker build, то мы получим образ на основе microsoft/aspnetcore, к которому будет добавлено еще три слоя.



Рассмотрим еще один Dockerfile, который демонстрирует прекрасную возможность Docker, обеспечивающую легковесность образов. Подобный файл генерирует VisualStudio 2017 для проекта с поддержкой контейнеров и он позволяет собирать образ из исходного кода приложения.

FROM microsoft/aspnetcore-build:2.0 AS publish
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish -o /publish

FROM microsoft/aspnetcore:2.0
WORKDIR /app
COPY --from=publish /publish .
ENTRYPOINT ["dotnet", "MyApplication.dll"]


Инструкции в файле разбиты на две секции:

  1. Определение образа для сборки приложения: microsoft/aspnetcore-build. Данный образ предназначен для сборки, паблиша и запуска .NET приложений и согласно DockerHub с тегом 2.0 имеет размер 699 MB. Далее происходит копирование исходных файлов приложения внутрь образа и внутри него выполняются команды dotnet restore и dotnet publish с размещением результатов в директории /publish внутри образа.
  2. Определяется базовый образ, в данном случае это microsoft/aspnetcore, который содержит в себе только среду исполнения и согласно DockerHub с тегом 2.0 имеет размер всего 141 MB. Далее определяется рабочая директория и в нее копируется результат предыдущей стадии (ее имя указывается в аргументе --from), определяется команда запуска контейнера и все — образ готов.


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

Напоследок хочу отметить, что намеренно для простоты оперировал понятием образ, рассматривая работу с Dockerfile. На самом деле изменения, вносимые каждой инструкцией происходят конечно же не в образе (ведь в нем только неизменяемые слои), а в контейнере. Механизм такой: из базового образа создается контейнер (добавляется ему слой для записи), выполняется инструкция в данном слое (она может добавлять файлы в слой для записи: COPY или нет: ENTRYPOINT), вызывается команда docker commit и получается образ. Процесс создания контейнера и коммита в образ повторяется для каждой инструкции в файле. В итоге в процессе формирования конечного образа создается столько промежуточных образов и контейнеров, сколько инструкций в файле. Все они автоматически удаляются после окончания сборки конечного образа.

Docker Compose

Docker Compose — это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развёртыванием проектов.

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

Как узнать, нужно ли вам, при развёртывании некоего проекта, воспользоваться Docker Compose? На самом деле — очень просто. Если для обеспечения функционирования этого проекта используется несколько сервисов, то Docker Compose может вам пригодиться. Например, в ситуации, когда создают веб-сайт, которому, для выполнения аутентификации пользователей, нужно подключиться к базе данных. Подобный проект может состоять из двух сервисов — того, что обеспечивает работу сайта, и того, который отвечает за поддержку базы данных.

Технология Docker Compose, если описывать её упрощённо, позволяет, с помощью одной команды, запускать множество сервисов.

Разница между Docker и Docker Compose


Docker применяется для управления отдельными контейнерами (сервисами), из которых состоит приложение.

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


Docker (отдельный контейнер) и Docker Compose (несколько контейнеров)


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

Выводы по Docker


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

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

Ссылки по Docker

  1. Документация Docker https://docs.docker.com/
  2. Механизм namespaces https://selectel.ru/blog/mexanizmy-kontejnerizacii-namespaces/
  3. Механизмы контейнеризации: cgroups
  4. Введение в Docker Compose
  5. Статья о Docker http://merrigrove.blogspot.ru/2015/10/visualizing-docker-containers-and-images.html

6 Симуляторы


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

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

Как правило, симулятор содержит в своем составе:

  • отладчик;
  • модель ЦПУ и памяти.

Более продвинутые симуляторы содержат в своем составе модели встроенных периферийных устройств, таких, как таймеры, порты, АЦП, и системы прерываний.

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

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

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

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

В реальной системе микроконтроллер обычно занимается считыванием информации с подключенных внешних устройств (датчиков), обработкой этой информации и выдачей управляющих воздействий на исполнительные устройства. Чтобы в симуляторе не обладающем интерфейсом внешней среды смоделировать работу датчика, нужно вручную изменять текущее состояние модели периферийного устройства, к которому в реальной системе подключен датчик. Если, например, при приеме байта через последовательный порт взводится некоторый флажок, а сам байт попадает в определенный регистр, то оба эти действия нужно производить в таком симуляторе вручную. Наличие же интерфейса внешней среды позволяет пользователю создавать и гибко использовать модель внешней среды микроконтроллера, функционирующую и взаимодействующую с отлаживаемой программой по заданному алгоритму. Возможности "реального" отладчика-симулятора проиллюстрируем на примере модели PDS-PIC.

Рисунок 8 Пример симмулятора ля Arduino - UnoArduSim

Рисунок 9 Пример онлайн симулятора Tinkercad для разработчика Arduino

Комментарии (2)

avatar
Admin 18.7.2020 9:53

В чем разница между эмуляцией и симуляцией?

avatar
Admin 18.7.2020 9:53

Вы хотите дублировать поведение старого калькулятора HP, есть два варианта:

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

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

Simulator пытается дублировать поведение устройства. Эмулятор пытается дублировать внутреннюю работу устройства.


avatar

Чтобы оставить комментарий войдите или зарегистрируйтесь



Операционные системы и системное программировние

Термины: Операционные системы и системное программировние