Безсумнівно, якщо ви колись працювали з технологіями, ви неодноразово чули терміни «віртуальні машини» та «контейнери». І віртуальні машини, і контейнери є основними технологіями в сучасному світі технологій, що постійно розвивається. Однак багато хто з домашніх лабораторних середовищ можуть задаватися питанням, яке їм запустити, віртуальну машину чи контейнер. Ця публікація детально зануриться у віртуальні машини проти контейнерів і те, що може найкраще служити вашій домашній лабораторії. Відповіді можуть вас здивувати. Спочатку порівняємо та дізнаємося їхні сильні та слабкі сторони.

Зміст

Що таке віртуальна машина (VM)?

Гіпервізор

Кілька операційних систем однакове обладнання

Ефективне управління

Як працюють віртуальні машини

Добре використовуйте сучасне обладнання

Що таке контейнери?

Ядро операційної системи загального хоста

Зображення контейнерів

Ізоляція на рівні процесу

Вивчення функціональності контейнерів

Аспекти безпеки віртуальних машин і контейнерів

Віртуальна машина проти контейнера в домашній лабораторії

Зрушення в технології домашніх лабораторій – більше контейнерів!

Найкращий варіант використання контейнерів у домашній лабораторії

Майбутнє домашніх лабораторій: віртуальні машини, контейнери чи те й інше?

Найкраще використовувати для віртуальних машин?

Найкраще використовувати для контейнерів?

Вибір між віртуальними машинами та контейнерами

Інші публікації, які можуть вам сподобатися

Що таке віртуальна машина (VM)?

Давайте почнемо наше обговорення з віртуальних машин, які часто називають віртуальними машинами. Вони були невід’ємною частиною комп’ютерного світу з початку епохи віртуалізації на початку 2000-х років. По суті, вони є цифровими копіями фізичних комп’ютерів, оснащених власною операційною системою та системними ресурсами. Ці ресурси виділяються з апаратного забезпечення реального фізичного сервера.

По суті, запуск кількох віртуальних машин на одному сервері дає вам можливість мати під рукою кілька машин із різними операційними системами.

Гіпервізор

Віртуальна машина запускає операційну систему та програми, поводяться незалежно, працюючи з частиною ресурсів фізичного сервера. Магія віртуальних машин полягає в компоненті під назвою гіпервізор, який, по суті, є основною операційною системою.

Резервне копіювання віртуальної машини Altaro

Цей програмний рівень дозволяє вашому фізичному комп’ютеру, хосту, створювати та запускати віртуальні машини. Гіпервізор призначає системні ресурси, такі як обчислювальна потужність, пам’ять і простір для зберігання, від головного комп’ютера до кожної гостьової віртуальної машини, яку він створює.

Кілька операційних систем однакове обладнання

Відмінною характеристикою віртуальних машин є їх здатність розміщувати декілька операційних систем на одному наборі фізичного обладнання. Це дозволяє використовувати головний комп’ютер, можливо, під керуванням операційної системи Windows, для одночасної роботи віртуальних машин, що працюють під керуванням різних операційних систем, таких як Linux або MacOS, у межах однакових апаратних обмежень.

Віртуальні машини імітують апаратну архітектуру фізичного комп’ютера. Таким чином, кожна віртуальна машина може похвалитися власною колекцією віртуальних апаратних компонентів, що включає ЦП, пам’ять, жорсткі диски, мережеві інтерфейси та інші периферійні пристрої. Гостьова ОС або операційна система, що працює у віртуальній машині, безпосередньо взаємодіє з цими елементами віртуального обладнання.

Ефективне управління

Ще одна важлива особливість — можливість ефективного керування віртуальними машинами. Ви можете створювати, видаляти та змінювати віртуальні машини за потреби, що спрощує виконання таких завдань, як тестування в кількох середовищах або розробка програмного забезпечення на різних операційних системах.

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

Віртуальна машина дозволяє зробити знімок віртуальної машини для швидкого відкоту

Віртуальна машина дозволяє зробити знімок віртуальної машини для швидкого відкоту

По суті, віртуальні машини забезпечують гнучкість емуляції кількох комп’ютерів із потенційно різними операційними системами в межах наявного фізичного обладнання.

Як працюють віртуальні машини

У віртуальному середовищі гіпервізор, що працює на фізичному комп’ютері, створює ізольоване віртуальне середовище, у якому працює гостьова операційна система. Цей повний рівень операційної системи надає кожній окремій віртуальній машині незалежність. Він відокремлений від головної ОС і сусідніх віртуальних машин.

Добре використовуйте сучасне обладнання

Використовуючи сучасне високопродуктивне апаратне забезпечення, цілком можливо, щоб один сервер містив численні віртуальні машини, кожна з яких працює під керуванням окремої операційної системи. Завдання керування віртуальними машинами було значно спрощено завдяки створеним платформам віртуальних машин, таким як VMware і VirtualBox.

Кластер серверів VMware vSphere, на якому працює багато віртуальних машин

Кластер серверів VMware vSphere, на якому працює багато віртуальних машин

Ці платформи пропонують інструменти для обробки зображень віртуальних машин, створення знімка віртуальної машини, клонування віртуальних машин, міграції віртуальних машин між хостами тощо, що спрощує роботу та обслуговування середовищ.

Що таке контейнери?

Переносячи нашу увагу на технологію контейнерів, контейнери є іншим типом технології віртуалізації, але вони мають дещо інший підхід порівняно з віртуальними машинами. Замість того, щоб емулювати апаратне забезпечення всього комп’ютера та запускати повну операційну систему, контейнер інкапсулює програму та її залежності ізольовано від інших контейнерів.

Ядро операційної системи загального хоста

Контейнер працює безпосередньо на ядрі головної ОС, спільно з іншими контейнерами. Це означає, що всі контейнери на хості використовують одну базову операційну систему, на відміну від віртуальних машин, які можуть запускати різні операційні системи. Підхід спільної операційної системи є частиною того, що робить контейнери легкими та ефективними порівняно з віртуальними машинами.

Зображення контейнерів

Контейнери походять від чогось, відомого як зображення контейнерів. Це гнучкі, незалежні та виконувані програмні пакети, які містять усі необхідні компоненти для запуску певного програмного забезпечення – код, середовище виконання, системні інструменти, бібліотеки та конфігурації. Візьмемо контейнери Docker як приклад; вони створені з образів Docker, визначення яких вписані у файл Docker.

Docker є фактичним стандартом для запуску контейнерів

Docker є фактичним стандартом для запуску контейнерів

Owing to their small size and quick startup time, containers prove to be very efficient for dynamic development workflows and microservices, particularly when integrated with CI/CD platforms. They enable a uniform packaging and distribution of software across multiple environments, enhancing the efficiency of the software development lifecycle.

Process-level isolation

The isolation provided by containers is at the process level. Each container operates as an isolated user-space instance, running a single application or service. While they don’t offer as robust isolation as VMs, containers still provide an effective way to package and isolate applications with their dependencies, reducing conflicts and improving deployment consistency across multiple environments.

Container engines like Docker or Kubernetes (orchestration platform) can manage containers. These engines allow you to automate the deployment, scaling, networking, and availability of containerized applications, making the management of containers more straightforward and scalable.

Exploring containers functionality

Containers vs virtual machines in the home lab is not just a battle of resources; it’s also about how they fit into your home lab or a software development lifecycle if you are interested in learning about CI/CD pipelines, etc.

In an agile development environment, for instance, containers can be beneficial due to their lightweight nature and fast start-up times. Running containers on your physical machine won’t burden your system resources as much as running multiple virtual machines.

The container engine, which could be Docker or any other similar platform, is responsible for managing the lifecycle of containers. It handles tasks like starting, stopping, and destroying containers based on the instructions given in the container image’s build file.

With containers and simple Docker Compose code, you can quickly spin up multiple solutions for effective application stacks. Below we are spinning up Traefik and Pi-Hole using Docker Compose:

version: '3.3'

services:

  traefik2:

    image: traefik:latest

    restart: always

    command:

      - "--log.level=DEBUG"

      - "--api.insecure=true"

      - "--providers.docker=true"

      - "--providers.docker.exposedbydefault=true"

      - "--entrypoints.web.address=:80"

      - "--entrypoints.websecure.address=:443"

      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"

      - "--entrypoints.web.http.redirections.entryPoint.scheme=https"

    ports:

      - 80:80

      - 443:443

    networks:

      - traefik

    volumes:

      - /var/run/docker.sock:/var/run/docker.sock

    container_name: traefik

  pihole:

    image: pihole/pihole:latest

    container_name: pihole

    ports:

      - "53:53/tcp"

      - "53:53/udp"

    dns:

      - 127.0.0.1

      - 1.1.1.1

    environment:

      TZ: 'America/Chicago'

      WEBPASSWORD: 'password'

      PIHOLE_DNS_: 1.1.1.1;9.9.9.9

      DNSSEC: 'false'

      VIRTUAL_HOST: piholetest.cloud.local # Same as port traefik config

      WEBTHEME: default-dark

      PIHOLE_DOMAIN: lan

    volumes:

      - '~/pihole/pihole:/etc/pihole/'

      - '~/pihole/dnsmasq.d:/etc/dnsmasq.d/'

    restart: always

Security aspects of VMs and containers

Security is always a consideration, no matter what type of environment you are thinking about, including home labs. As you weigh the options between virtual machine vs container, consider the isolation level.

Comparing VMs and containers, virtual machines offer more isolation since each runs its own operating system, reducing the security risk. Containers, while efficient, share the host OS kernel with the other containers running on the host. It could present a security concern due to the shared OS kernel.

Virtual machine vs container in the home lab

Ok so we have a much better understanding of what a virtual machine vs container is and what they are typically used for. So, now, which is best for the home lab? Well, in the famous phrase that none of us like to hear, it depends.

I have been running a home lab for a decade now and have seen many technological shifts since starting to run my lab a decade ago. However, the right answer for most will probably be running both. Why is that the answer?

Well, first and foremost, containers need container hosts. The container host is the computer or virtual machine with Docker or other container runtime installed. Most will likely use virtual machines in most home lab or production environments to serve this purpose as VMs are much easier to manage, backup, migrate, etc, than a physical computer.

So by their nature, containers need and work well with VM technology. For most, they will not replace their entire lab with a bare-metal physical container host to run containers, they will keep their hypervisor in place, running virtual machines as container hosts.

The shift in home lab technology – more containers!

However, I think we have seen a shift in home lab focus and technologies like production environments. Containers allow us to run home labs much more efficiently. Instead of running 65 VMs 10 years ago, we may now have 5-10 VMs, some running as container hosts with multiple containers serving out self-hosted services.

In addition to container hosts, Kubernetes has also taken off in many home lab environments. Kubernetes is a container orchestration tool that provides many great features, including:

Robust container scheduling

Elasticity

self-healing

etc

Virtual machines also have their place in other use cases. Many still may run big monolithic SQL servers, backup servers, domain controllers, or other management appliances as virtual machines. These still are important and have their place.

The great thing about the shift in technology and the new hybrid mix of VMs and containers is it becomes even easier to have a home lab running multiple self-hosted services more efficiently.

The best use case for containers in the home lab

Generally speaking, web-driven services are the best type of service to run inside containers. Containers are excellent for self-hosted web services. In addition, using containers in the home lab is an excellent way to spin up new services to test out without having to worry about spinning up a new VM and installing all the prerequisites needed to run the services.

Below is a screenshot of Kubeapps I have running in my home lab in a Kubernetes cluster, allowing management of many different containerized services.

Інформаційна панель програми Kubeapps Kubernetes

Kubeapps Kubernetes application dashboard

Container images include all the necessary software and prerequisites to run the application you are spinning up.

The Future of home labs: Virtual machines, containers, or both?

The tech world is steadily leaning towards containerization, especially with the rise of microservices and cloud-native applications. But this doesn’t mean virtual machines are obsolete. They still hold tremendous value in most environments, including home labs.

Containers and virtual are not competing technologies. Rather they complement each other. VMs provide robust isolation, and containers bring speed and efficiency.

Best use for VMs?

Container hosts

Big servers that need lots of resources and needs to run many applications

SQL Servers, backup servers, domain controllers, etc

Management appliances

Best use for containers?

Running very small web services

Testing out new services in your home lab

CI/CD pipelines and agile development

Evergreen environments that are easily upgraded

Deciding between virtual machines and containers

It’s not necessarily a case of virtual machine vs container. It’s about understanding your specific needs and aligning them with the strengths of each technology. If you require complete operating systems to simulate a complex network of multiple resources or you need to run earlier versions of software, virtual machines could be your best bet.

If your goal is to have a streamlined software development process that can replicate multiple environments quickly, then containers may serve you better.

Ultimately, the decision between containers and virtual machines boils down to the specific requirements of your home lab setup, the physical resources available, and the nature of the projects you’ll be working on.

Other posts you may like

Windows Server 2016 Containers Basic Setup

Kubernetes vs. VMware vSphere comparison

Best Docker Containers for Home Server

Installing and Configuring Windows Server 2016 Hyper-V Containers

Home Lab virtualization software 

Nice write-up, I started building my home lab with the main purpose to host Plex, Emby and Jellyfin, a media server. Hardware speaking is a Intel NUC with 3 NVMe, 1 for the Hypervision, 1 fot the media storage and 1 for backup. It has 32gb of RAM, and a server processor. I installed Proxmox and now I’m trying to define how to put all together. It seems that using one Debian VM with 3 dockers will be recommended. Should I allocate all the RAM and cores to this single VM if I plan to run the three dockers on i

Hey Alex! Thanks for the comment. I wouldn’t recommend dedicating all your available RAM for the VM as you will need some for Proxmox itself. I would probably allocate at least 8-16 GB of memory for the VM and start there to see what your memory pressure is and adjust accordingly. You can also run LXC containers in proxmox for small footprint containers, but I would probably stick with Docker containers for running your self-hosted services as they are better supported from vendors, 

You compare apples to oranges. If one is not a developer he does not need a “home container lab” it will never serve as good as a virtualisation solution. Kubeapps full of trash. Just more trash to maintain the container environment.. whats easy in that?

I want to test a new app before upgrading it in my host? I can do that easily with a virtualisation solution. What use of a container in home lab? Nothing. Running a micro webservice for what? How many people need tha

Thanks for your comment. I understand your feelings on containerization. Many have felt the same way and wonder “why.” However, for me, and I think many others, a home lab environment is about learning. Things you learn and prove out in the home lab allows taking those skills to production environments or better understanding new technologies adopted at work. Also for home labs, containers allow making better use of your resources. They are not competing solutions. I doubt containers will ever get away from the underlying virtual machine until the next “thing” comes along that is able to do that successful