I’ve helped a lot of people get started with Python and Django, and trust me: understanding virtual environments early on can save you tons of headaches later.

A virtual environment can help you keep your Django projects organized. It also avoids conflicts between different versions of packages, and gives you a cleaner way to manage your development tools.

By the end of this guide, you’ll not only know how to activate your virtual environment, but also why you should.

Let's get into it.

Here’s what we’ll cover:

1. What Is a Virtual Environment in Python?

2. Why Use a Virtual Environment?

3. How to Set Up and Activate a Django Virtual Environment

   • 1. Install Python (If You Haven’t Yet)

   • 2. Install virtualenv (Optional but Useful)

   • 3. Create a Virtual Environment

   • 4. Activate the Virtual Environment

4. What Can You Do After Activating It?

5. How to Deactivate the Virtual Environment

6. FAQs

   • Do I need to activate the environment every time?

   • What if activate Doesn’t work?

   • Can I use VS Code or another editor with this?

7. Bonus Tips

   • Add a .gitignore File

   • Use requirements.txt

8. Helpful Resources

9. Conclusion

10. Further Learning

What Is a Virtual Environment in Python?

A virtual environment is like a private workspace just for your project. Instead of installing packages (like Django) globally for your whole computer, you install them inside this little bubble. That way, different projects don’t mess with each other.

Imagine you’re working on two Django projects: one needs Django 3.2 and the other needs Django 4.1. Without a virtual environment, you'd run into version conflicts. But with virtual environments, each project stays separate and clean.

Why Use a Virtual Environment?

Here’s why I always use one when working with Django:

• Keeps your project dependencies isolated.

• Prevents version conflicts between different projects.

• Makes it easy to manage and uninstall packages.

• Most importantly, Django expects it, especially if you want to follow best practices.

How to Set Up and Activate a Django Virtual Environment

Let’s walk through the process from start to finish.

1. Install Python (If You Haven’t Yet)

You need Python 3.8 or later. You can check what version you have by opening your terminal and typing:

python --version

If you see something like Python 3.11.7You’re good.

If you don’t have Python, download it here:

👉 https://www.python.org/downloads/

Make sure to check the box “Add Python to PATH” during installation if you're on Windows.

2. Install virtualenv (Optional but Worth Knowing)

Python includes a built-in tool called venv, and that’s what we’ll use in this tutorial.

However, some developers prefer virtualenv because:

• It works with older Python versions

• It can be slightly faster in larger environments

• It offers some additional flexibility

To install virtualenv just run:

pip install virtualenv

Note: You don’t need virtualenv for this tutorial, but it’s good to know about. We'll be using Python’s built-in venv going forward.

3. Create a Virtual Environment

Now go to your Django project folder (or make one):

mkdir my_django_project
cd my_django_project

Then run:

python -m venv venv

• python -m venv uses Python’s built-in virtual environment module

• venv is the name of the folder that will store your environment (you can call it anything)

This creates a folder called venv/ in your project directory. That folder contains everything your virtual environment needs.

4. Activate the Virtual Environment

Here’s the part everyone asks about.

Activation depends on your operating system.

On Windows (CMD):

venv\Scripts\activate

On Windows (PowerShell):

.\venv\Scripts\Activate.ps1

On Mac or Linux:

source venv/bin/activate

After you activate it, your terminal prompt will change. It’ll look something like this:

(venv) your-computer-name:my_django_project username$

That (venv) at the beginning means the virtual environment is active.

What Can You Do After Activating It?

Now that it’s active, you can install Django (or anything else) just for this project:

pip install django

This installs Django inside the virtual environment, not globally.

To double-check:

pip list

You’ll see Django and any other installed packages listed there.

How to Deactivate the Virtual Environment

When you’re done working, just type:

deactivate

That’s it. Your terminal goes back to normal, and your system’s Python is no longer linked to the project.

FAQs

Do I need to activate the environment every time?

Yes, every time you open a new terminal session and want to work on your Django project, activate it again using the command for your OS.

What if activate Doesn’t work?

If you’re on Windows, PowerShell might block the script. Run this:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Then try activating again.

Can I use VS Code or another editor with this?

Absolutely. VS Code even detects your virtual environment automatically. You can select the interpreter from the bottom-left or by pressing Ctrl+Shift+P → “Python: Select Interpreter.”

Bonus Tips

Add a .gitignore File

If you're using Git, you don’t want to upload the venv folder to GitHub. Add this line to your .gitignore file:

venv/

Use requirements.txt

Once you’ve installed your project’s packages, freeze them like this:

pip freeze > requirements.txt

Then later, you (or someone else) can install them with:

pip install -r requirements.txt

This is useful for team projects or for moving your app to a server.

Conclusion

Activating your Django virtual environment might seem like a small thing, but it’s a big step toward becoming a confident and organized developer.

Once you get the hang of it, it becomes second nature – and your future self will thank you for learning it the right way from the start.

Would you love to connect with me? You can do so on X.com/_udemezue

Helpful Resources

• Official Python Docs on venv

• Django Official Website

• Python Virtual Environments Tutorial (Real Python)

• How to Fix “activate.ps1 cannot be loaded” in PowerShell

Further Learning

If you're serious about Django, here are some free and paid resources I recommend:

• Django for Beginners by William S. Vincent

• FreeCodeCamp’s Django Crash Course on YouTube

• CS50 Web Programming with Python and JavaScript

A hypervisor is the software that lets you run multiple virtual machines on a single physical machine, and the Kernel-based Virtual Machine (KVM) is one of the best. Built into Linux, KVM is fast (near-native performance), open-source (free!), and flexible (supports Windows, Linux, and more). It’s trusted by both cloud providers and homelabbers for its stability and low overhead.

If you want to turn your Ubuntu 24.04 or Kubuntu 24.04 (Kubuntu is a Ubuntu variant with KDE Plasma desktop) system into a powerful hypervisor without Proxmox’s complexity, this guide is for you. With KVM, you’ll spin up virtual machines (VMs) in minutes, and with Cockpit’s web-based manager, you’ll control them from your browser.

In this tutorial, you’ll transform an Ubuntu 24.04 or Kubuntu 24.04 Desktop or Server – fresh or existing – into a KVM hypervisor. You’ll set up the backend (KVM, QEMU, libvirt), add Cockpit for web-based VM management, and create a guest VM to test it all. Whether you’re a coder, homelabber, or IT enthusiast, this guide is beginner-friendly.

Table of Contents

• Before You Start: What You Should Know

• What You’ll Need

• Why KVM on Ubuntu/Kubuntu 24.04?

• Step 1: Check Virtualization Support

• Step 2: Install KVM and Backend Tools

• Step 3: Set Up a Network Bridge

• Step 4: Install Cockpit for Web Management

• Step 5: Create a Guest VM

• Step 6: Run and Test Your Guest VM

• Keep Exploring Your Hypervisor

• Wrapping Up

Before You Start: What You Should Know

This guide is designed for virtualization newcomers, but you’ll need a few basic skills:

• Running terminal commands like sudo apt install or nano and so on.

• Basic Linux navigation (for example, editing files in /etc).

• Basic networking knowledge, such as understanding network interfaces (for example, enp4s0 or wlp3s0), IP addresses, and concepts like bridging or NAT. You’ll use tools like ip link or nmcli to set up a network bridge in Step 3.

• Optional: Experience with VMs helps but isn’t required – I’ll explain everything.

No worries if terms like “libvirt” sound new. I’ll break them down as we go.

What You’ll Need

• A computer: Running Ubuntu 24.04 or Kubuntu 24.04 Desktop or Server (fresh or existing). Minimum: 4GB RAM, 20GB storage, CPU with virtualization support (Intel VT-x or AMD-V). More RAM/storage for multiple VMs.

• Internet access: To download packages and VM ISOs.

• A web browser: Firefox (default on Ubuntu) or Chrome to access Cockpit.

• An ISO image: An ISO image for your guest VM (for example, Ubuntu 24.04 Desktop ISO from ubuntu.com or Windows ISO if you have it already).

• 30–45 minutes: Depending on your setup speed.

Why KVM on Ubuntu/Kubuntu 24.04?

KVM turns your Linux kernel into a hypervisor, letting you run VMs with near-native speed. Paired with QEMU (for hardware emulation) and libvirt (for management), it’s a lightweight alternative to Proxmox or VMware. Its strengths include:

• Performance: Runs VMs efficiently, ideal for homelabs or dev environments.

• Free and Open-Source: No licenses, just like Ubuntu/Kubuntu, and so on.

• Flexibility: Supports diverse guest OSs (Linux, Windows, BSD).

• Integration: Cockpit’s web UI makes VM management a breeze, no CLI required.

Here’s what each tool does:

• KVM: A Linux kernel module that turns your system into a hypervisor, enabling VMs to run with near-native performance by leveraging CPU virtualization features (for example, Intel VT-x).

• QEMU: A powerful emulator that provides the virtual hardware (for example, CPU, disk, network) for your VMs, working with KVM for fast execution.

• libvirt: A management layer that simplifies VM creation, networking, and storage, offering tools like virsh and APIs for automation.

• Cockpit: A web-based interface for managing VMs, system resources, and networks, perfect for beginners who want a visual dashboard.

Ubuntu 24.04 (“Noble Numbat”) brings the latest kernel and tools, ensuring top-notch KVM compatibility. Let’s build your hypervisor!

Step 1: Check Virtualization Support

First, you’ll want to confirm that your CPU supports virtualization (most modern ones do). To do that, open a terminal (like Konsole on Kubuntu) and run:

lscpu | grep Virtualization

Look for "VT-x" (Intel) or "AMD-V" (AMD). If present, you’re good!

If nothing shows, check your BIOS/UEFI:

• Reboot, enter BIOS (usually F2, Del, or Esc).

• Enable "Intel VT-x" or "AMD-V" under CPU settings.

• Save and reboot.

Step 2: Install KVM and Backend Tools

Let’s install KVM, QEMU, and libvirt. These will form the backbone of your hypervisor:

Start by updating your system (you may need to restart your computer after the update):

sudo apt update && sudo apt upgrade -y

Then install the virtualization packages:

sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils -y

• qemu-kvm: Emulates hardware for VMs.

• libvirt-daemon-system: Manages VMs.

• libvirt-clients: CLI tools like virsh for hypervisor management.

• bridge-utils: For network bridging.

Next, verify that KVM is loaded:

lsmod | grep kvm

You’ll see “kvm_intel” or “kvm_amd” if successful.

Finally, add your (current) user to the libvirt group for permission:

sudo usermod -aG libvirt $USER

Log out and back in to apply these changes.

Step 3: Set Up a Network Bridge

VMs need network access, so you’ll create a bridge (br0) to connect them to your physical network. This allows VMs to act like devices on your network (bridged networking).

Ubuntu 24.04 and Kubuntu 24.04 Desktop typically use NetworkManager, while Ubuntu Server may use Netplan. We’ll prioritize the NetworkManager approach, with Netplan as an alternative.

Note: Installing libvirt (Step 2) creates a default bridge called virbr0 for NAT-based networking, which isolates VMs from the physical network (IPs like 192.168.122.x). For direct network access (IPs like 192.168.0.x), use br0 as described below, and select it in Step 5’s VM setup.

You can verify whether your system is using NetworkManager or Netplan. Open a console and run systemctl status NetworkManager. If you see the status active and running, go with NetworkManager.

Option 1: NetworkManager (Recommended for Kubuntu/Ubuntu desktop)

Check your network interface:

ip link

Example: enp4s0. Replace enp4s0 below if yours differs.

First, find your Ethernet connection name:

nmcli connection show

Look for the NAME column where DEVICE is enp4s0 (for example, “Wired connection 1” or “Ethernet connection”). Note this name. Ignore virbr0, which is libvirt’s default NAT bridge.

Then create a bridge named br0:

sudo nmcli connection add type bridge ifname br0 con-name bridge-br0

Enslave your interface to the bridge:

sudo nmcli connection add type ethernet ifname enp4s0 master br0 con-name bridge-slave-enp4s0

Disable the old connection (replace with your connection name identified earlier):

sudo nmcli connection down "Wired connection 1"
sudo nmcli connection delete "Wired connection 1"

Enable DHCP on the bridge:

sudo nmcli connection modify bridge-br0 ipv4.method auto

Activate the bridge:

sudo nmcli connection up bridge-br0

Verify:

ip addr show br0
nmcli connection show

Now you’ll want to ensure br0 is active, enp4s0 is enslaved, and virbr0 is separate. First, test the internet with ping 8.8.8.8.

Then you need to define br0 in libvirt (to appear in Cockpit’s VM network dropdown). To do this, create br0.xml in your home directory:

nano ~/br0.xml

Then add the following:

<network>
  <name>br0</name>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

Save and exit (Ctrl+O, Enter, Ctrl+X).

Now define and start the following:

sudo virsh net-define ~/br0.xml
sudo virsh net-start br0
sudo virsh net-autostart br0

Verify like this:

virsh net-list --all

You can now delete ~/br0.xml after defining, as libvirt stores it in /etc/libvirt/qemu/networks/.

rm ~/br0.xml

Option 2: Netplan (For Ubuntu Server or If Preferred)

If you see renderer: networkd in /etc/netplan/???.yaml or prefer Netplan, follow these steps.

First, check your interface:

ip link

Example: enp4s0.

Next, edit the Netplan config like so:

sudo nano /etc/netplan/01-netcfg.yaml

Use the following:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp4s0:
      dhcp4: no
  bridges:
    br0:
      interfaces: [enp4s0]
      dhcp4: yes

Save and exit (Ctrl+O, Enter, Ctrl+X).

Now, set strict permissions to avoid errors:

sudo chmod 600 /etc/netplan/01-netcfg.yaml

And apply:

sudo netplan apply

Now verify:

ip addr show br0

Test the internet with ping 8.8.8.8 (from console).

Troubleshooting:

• Permissions error: If Netplan complains about “too open” permissions, recheck sudo chmod 600 /etc/netplan/01-netcfg.yaml.

• NetworkManager conflict: If using Netplan, ensure /etc/netplan/01-network-manager-all.yaml is backed up or deleted (sudo mv /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak).

• No onternet: Restart NetworkManager (sudo systemctl restart NetworkManager) or reboot.

• Wrong bridge: If a VM uses virbr0 (NAT, 192.168.122.x), recheck Step 5’s network setting and select br0.

• br0 missing in Cockpit: Define br0 in libvirt (step 9 above) or ensure br0 is active (ip addr show br0).

Step 4: Install Cockpit for Web Management

Cockpit provides a slick web UI to manage VMs. Let’s go ahead and set it up.

First, you’ll need to install Cockpit and its VM plugin:

sudo apt install cockpit cockpit-machines -y

Then you can start and enable Cockpit:

sudo systemctl enable --now cockpit.socket
systemctl status cockpit.socket

Now open your browser (for example, Firefox on Ubuntu) and visit:

https://localhost:9090

Or use your KVM server’s IP (for example, https://192.168.0.100:9090) if remote. Log in with your username and password. Ignore the self-signed certificate warning.

Allow Cockpit’s port if you’re using a firewall:

sudo ufw allow 9090

You’ll see Cockpit’s dashboard. Turn on administrative access by clicking on “Turn on administrative access”. Then, click “Virtual Machines” to manage VMs.

Step 5: Create a Guest VM

Let’s create a guest VM using Cockpit. We’ll use an Ubuntu 24.04 Desktop ISO as an example:

To start, download the Ubuntu 24.04 Desktop ISO from ubuntu.com and save it (for example, /home/ranju/Downloads/ubuntu-24.04.1-desktop-amd64.iso).

In Cockpit, go to “Virtual Machines” and click “Create VM”. Here are the specs:

• Name: TestVM

• Installation Type: Local install media (or your desired installation type)

• Installation Source: Browse to your ISO (for example, /home/ranju/Downloads/ubuntu-24.04.1-desktop-amd64.iso).

• OS: Select “Ubuntu 24.04” (usually Cockpit auto-detects).

• Storage: Create new qcow2 volume (preferred). Note: disk is created in /var/lib/libvirt/images/.

• Storage limit: 20GB (adjust as needed).

• Memory: 4GB (adjust as needed).

Click “Create and Edit”. Cockpit opens an advanced dialog where there are options for customization (for example, CPU, Network Interfaces and Boot order, and so on). Make sure that br0 has been selected as interface source. Finally, click “Install”.

In Cockpit’s VM console, follow the installer to set up the guest OS (username, password, and so on).

Troubleshooting:

• Permissions error: If you have permission error for the ISO, then copy the ISO to the default temp folder (/tmp/) and locate the ISO from there.

    cp /home/ranju/Downloads/ubuntu-24.04.1.iso /tmp/
  

Step 6: Run and Test Your Guest VM

Your VM is running! Let’s test it:

1. In Cockpit, under “Virtual Machines,” click TestVM. You’ll see its console (a live view of the VM’s screen).

2. Log into the guest Ubuntu using the credentials you set.

3. Test networking:

   • Open a terminal in the VM (via Cockpit’s console).

   • Run ip addr in the console to confirm a physical network IP (for example, 192.168.0.x with br0, not 192.168.122.x with virbr0).

   • Run ping 8.8.8.8 to confirm internet access.

4. Experiment: Open a browser in the VM, visit a website, or install apps to simulate real use.

If the VM boots and connects to your network, your KVM hypervisor is rocking! You can stop, restart, or delete it from Cockpit.

Keep Exploring Your Hypervisor

You’ve turned your Ubuntu 24.04 into a KVM hypervisor – congrats! Try these next steps:

• Add more VMs: Create Windows or other Linux VMs using different ISOs.

• Use virt-manager: Install virt-manager for a desktop-based alternative to Cockpit (sudo apt install virt-manager).

• Back up VMs: Export VM disks with virsh for safety.

• Scale up: Add storage or RAM for heavier workloads, like my Proxmox cluster guide.

Check your VMs anytime via CLI:

virsh list --all

Wrapping Up

You’ve built a fast, free KVM hypervisor on Ubuntu 24.04, complete with Cockpit’s web UI and a running guest VM. It’s a perfect playground for coding, testing, or homelab fun.

Share your ideas or comments with me – I’d love to hear them!

In this tutorial, you’ll set up a 3-node Proxmox cluster using three computers (or virtual machines for practice). By the end, you’ll have a working cluster ready to host virtual machines (VMs) and experiment with cool features like guest migration and VM replication etc.

Let’s dive in!

Prerequisites: What You’ll Need to Know

This guide is beginner-friendly for clustering, but you’ll need some basic skills to follow along. You should be comfortable with:

• Installing an OS from a USB drive (don’t worry, I’ll walk you through the steps).

• Using a terminal for simple commands like ping or nano.

• Setting up a home network with static IPs (for example, knowing your router’s IP range). No advanced virtualization or clustering experience is required—I’ll explain the key concepts as we go.

What You’ll Need

• Three computers (or VMs): Start with at least 8GB RAM and 100GB storage per machine, plus a virtualization-capable CPU (most modern ones work). These specs are a baseline—actual RAM and storage depend on how many VMs you want to host (e.g., more VMs need more resources).

• Proxmox VE: Free and open-source. Grab the ISO from proxmox.com.

• Network connection: All three must be on the same network and be able to ping each other.

• A web browser: For Proxmox’s web interface.

• 30–60 minutes: Depending on your setup pace.

Why Proxmox and Clustering?

Proxmox VE is a free, open-source virtualization platform built on Debian Linux. It uses KVM for VMs (fully virtualized systems) and LXC for containers (lightweight app environments), all managed via a slick web interface.

Clustering means linking multiple Proxmox machines—called nodes—so they act as one system. Think of it like a team: each node shares the workload, and you control them from a single dashboard. This setup lets you move (migrate) VMs between nodes, boost reliability, and experiment with high availability (HA)—where VMs auto-restart (on healthy node) if a node fails.

Plus, Proxmox offers a handy replication feature: it can sync VM data between nodes automatically, keeping backups ready if something goes wrong.

It’s a must-have skill for DevOps, app testing, or IT tinkering.

2 Nodes vs. 3 Nodes: Which Should You Choose?

Before we build your 3-node cluster, let’s explore your options. Clustering can start with 2 nodes or go to 3 (or more). Here’s why you might pick one over the other:

• 2-Node Cluster:

  • Pros: Easier setup with just two machines. Great for learning basics or small projects. Uses less hardware.

  • Cons: No quorum—a voting majority to keep the cluster running if a node fails—so HA isn’t reliable. You’d need an extra trick (like a quorum device) to avoid stalling.

  • Best For: Learning, Testing clustering, or limited resources.

• 3-Node Cluster:

  • Pros: Built-in quorum—two out of three nodes keep things going if one crashes. Ideal for HA practice. More stable and scalable.

  • Cons: Needs an extra machine and a bit more setup time.

  • Best For: Serious learners or small production setups.

We’ll go with 3 nodes—it’s the sweet spot for stability and real-world skills.

Step 1: Install Proxmox VE on All Three Machines

First, download the Proxmox VE ISO from proxmox.com. Make a bootable USB with Rufus (Windows), dd (Linux/macOS), or Raspberry Pi Imager (available for all platforms).

For dd, use this command (replace placeholders with your ISO and USB device):

sudo dd if=proxmox-ve.iso of=/dev/sdX bs=1M status=progress oflag=sync

Boot each machine from the USB and follow the installer. Stick with the default partitioning scheme (it uses EXT4 filesystem) and set static IPs and hostnames as follows (or you can use your own IPs knowing your router’s IP range):

• Node 1: 172.20.1.101 [hostname: node01.local]

• Node 2: 172.20.1.102 [hostname: node02.local]

• Node 3: 172.20.1.103 [hostname: node03.local]

After installation, each node displays its IP on the console (for example, https://172.20.1.101:8006). Test it by opening a browser, visiting each IP, and logging in with root and your password. You’ll see the Proxmox dashboard.

Step 2: Prepare Your Nodes

Now, let’s get your nodes ready to talk to each other—a crucial step for clustering. Without this, they won’t recognize each other properly.

Update /etc/hosts on all three nodes to map IPs to hostnames (since we’re not using a DNS server). Open the file with:

nano /etc/hosts

Add these lines (IPs and hostnames) on each node:

172.20.1.101 node01.local node01
172.20.1.102 node02.local node02
172.20.1.103 node03.local node03

Save and exit (Ctrl+O, Enter, Ctrl+X). This ensures nodes can resolve each other’s names (for example, node01 pings node02.local).

Next, check connectivity. From Node 1’s console (or SSH), ping the others:

ping 172.20.1.102

ping 172.20.1.103

Repeat from Node 2 and Node 3. If pings fail, check your network or firewall.

Finally, sync their clocks—clusters need precise time to coordinate. On each node, run:

ntpdate pool.ntp.org

All three nodes are now primed for clustering.

Step 3: Create the Cluster on Node 1

Let’s set up the cluster starting with Node 1. Log into its web interface at https://172.20.1.101:8006. On the left sidebar, click Datacenter, then Cluster. Hit the Create Cluster button, and a dialog pops up. Name your cluster—let’s call it MyCluster and click Create. A task window will appear, showing the process. Wait a few seconds until you see “TASK OK”—that means your cluster is live and Node 1 is its first member. Now we can add the other nodes!

Step 4: Join Node 2 and Node 3 to the Cluster

With the cluster created, let’s bring in Node 2 and Node 3. On Node 1’s cluster page, click Join Information, then Copy Information—this copies a key you’ll need.

Open Node 2’s web interface (https://172.20.1.102:8006), go to Datacenter > Cluster > Join Cluster, paste the key into the Information field, enter Node 1’s root password, and click Join MyCluster.

Repeat this process on Node 3’s interface (https://172.20.1.103:8006). Refresh Node 1’s dashboard—under Datacenter, you’ll see all three nodes with green checkmarks.

Your 3-node cluster is up!

Step 5: Test Your Cluster

Let’s verify it works by creating and moving a test VM. On Node 1, click Create VM, name it TestVM, skip the ISO, and finish with defaults (no disk content needed). Hit the Start button to boot it up.

Now, let’s migrate it around—migration means moving the VM from one node to another to test your cluster’s flexibility. Right-click TestVM, select Migrate, choose Node 2, and click Migrate. The VM stops briefly, copies to Node 2, and restarts (normal without shared storage).

Repeat this, migrating it from Node 2 to Node 3. If it hops between nodes successfully, your cluster’s rocking! With three nodes, you’ve got quorum—try shutting down Node 3 to see the others stay active.

What’s Next?

You’ve built a 3-node Proxmox cluster for free—congrats! Take it further with:

• Shared storage: Add NFS or a spare drive for live VM migration (no stopping/shutdown needed).

• High Availability: Enable HA—VMs auto-restart on a healthy node if one fails.

• VM Replication: Configure Replication—Sync VM data between nodes automatically, keeping backups ready if something goes wrong.

• Scale up: Add more nodes or try LXC containers.

Check your cluster’s health anytime (from console) with:

pvecm status

Wrapping Up

You’ve just set up a 3-node Proxmox cluster at no cost. It’s a playground for virtualization, DevOps practice, or even hosting small projects. Share your thoughts with me – I’d love to hear how you liked it.

In this guide, you'll learn about VM-specific risks for data and workloads. I'll also provide some recommendations that can help you mitigate them. Implementing these data protection best practices can help you ensure production continuity, data availability, and regulatory compliance for your organization.

Table of Contents

• Two of the Main Players: VMWare and Proxmox
• Understanding the Risks of Virtual Environments
• Specific Risks Associated with Virtual Environments
  • Hypervisor security vulnerabilities
  • VM sprawl
  • Insecure VM configurations
  • Snapshot and clone risks
• VM Data Protection and Secure Virtualization Best Practices
  • Secure the Virtualized Environment
  • Backup and Recovery Strategies
  • Monitoring and Auditing
• Advanced Protection Techniques
  • Encryption
  • Intrusion Detection and Prevention Systems (IDPS)
  • Application and Network Security

Two of the Main Players: VMWare and Proxmox

Both VMware and Proxmox offer robust solutions for virtualization, but they come with their own set of challenges and risks that can impact VM data protection.

VMware is the market leader in virtualization with almost 50% of the market share, which is both a boon and a bane.

On the one hand, VMware has a high-end, efficient portfolio of solutions to build IT environments of any complexity and size. On the other, such popularity means that malicious actors know what they can target during cyberattacks, posing challenges in virtualization security for VMware users.

Proxmox, a prominent alternative to VMware, also offers robust virtualization solutions. While Proxmox may have a smaller market share compared to VMware, it provides a comprehensive set of tools for managing virtual environments. It can also be a good choice for those looking for open-source solutions with flexibility and cost-efficiency.

Over three-quarters of organizations that have 50+ workers use server virtualization. So it's hard to overestimate the importance of the data that's circulating in their virtualized workloads.

The workloads themselves can be mission-critical and cause global disruption and downtime in case of failures. The data can also be crucial to run efficient services and generate revenue or be subject to compliance requirements.

Understanding the Risks of Virtual Environments

Before we proceed with VM security best practices, let’s go over some general security issues associated with virtual environments.

• Data breaches are a regular issue that most IT protection systems experience. A lone hacker or an organized cybercriminal group can intrude into corporate environments to steal data. Their targets are typically clients' personal data, credit card info, credentials, and intellectual property.

• Insider threats are usually the most underrated yet exceptionally dangerous issue. Malicious insiders sneakily strike from the inside of an organization’s security perimeter and may have advanced access privileges. This can lead to a global IT disaster, and preventing it is a high-level challenge.

• Malware and ransomware attacks are an ever-evolving threat for organizations of all sizes and types.

• System vulnerabilities and exploits. The supply chains of today’s IT services can be complicated and consist of multiple synchronized solutions. Every solution involved in service provisioning is a potential source of vulnerabilities that malicious actors can exploit upon discovery.

Specific Risks Associated with Virtual Environments

Understanding the risks of virtualization – particularly with VMware, one of the most popular virtualization platforms for enterprises, and Proxmox, which has seen increasing adoption in recent times – will help you and your team build an effective data protection system in your virtualized environments.

The unique threats associated with these platforms dictate how you should secure your virtual machines, servers, networks, and other virtualized nodes.

Key factors that can weaken virtualized infrastructure security include:

Hypervisor security vulnerabilities

• VMware: Because of its extensive use in enterprises, attackers frequently target VMware. Major issues can arise due to the integration and complexity of VMware's hypervisor. The "ESXiArgs" ransomware strain takes advantage of VMware vulnerabilities to infiltrate computers before the distribution of updates.

• Proxmox: While this open-source technology does have the potential for hypervisor vulnerabilities, the community can also provide security improvements such as timely patches, vulnerability reports, and enhancements to security protocols. Insufficiently managed upgrades or third-party modules can put Proxmox users at risk of security vulnerabilities.

VM sprawl

• VMWare: The ease of deploying VMs in VMware can lead to VM sprawl, where numerous virtual machines are created but not adequately managed. IT teams can create a virtual machine, for example, to test a new feature in an isolated environment before releasing it in production. If not deleted after completing the task, the new virtual machine can remain in an environment without attention, maintenance, or security updates.

• Proxmox: Proxmox's flexibility in managing virtual environments causes VM sprawl, which is more likely to affect smaller teams lacking strong monitoring. Its straightforward interface and streamlined deployment processes help to make creating and managing many virtual machines (VMs) a delight. While this helps with development and testing quickly, it can also cause an influx of virtual machines (VMs) to be launched without proper management or preparation.

Insecure VM configurations

• VMware: A VMWare virtual machine itself is a complex environment with multiple configurations and dependencies. Misconfiguration of VMware's resources, operating systems, or applications can lead to additional virtual desktop security risks.

• Proxmox: Users of Proxmox might also face security pitfalls due to misconfigured VMs, especially when utilizing custom templates or third-party integrations. Insufficient security settings can expose services and open ports, enabling unauthorized access.

Snapshot and clone risks

• Inappropriate VM snapshot retention and maintenance policies in both Proxmox and VMware environments can cause storage overload. Creating too many VM clones can eventually lead to RAM and CPU deficiencies. Insufficiency of hardware resources then causes performance degradation and disk failures, resulting in downtime and data loss.

VM Data Protection and Secure Virtualization Best Practices

Data loss in virtualized environments, such as VMWare or Proxmox, can lead to fines, financial losses, and reputational damage for an organization.

Below are some recommendations on how to improve VM data security for virtual nodes, clusters, and infrastructures. The tips cover both virtualization-specific risks and those common to IT security, providing valuable insights for managing data protection effectively in both VMware and Proxmox environments.

Secure the Virtualized Environment

For starters, you can strengthen your environment with regular VM security practices. Consider implementing the following:

Strong access controls and authentication mechanisms.

Role-based access control (RBAC) is an efficient security measure that ensures users have only the access and privileges required to fulfill job duties. With roles set for every employee, their accounts become less dangerous under unauthorized access in case of, for example, compromised credentials.

This can help you either completely counter a security breach attempt or at least significantly mitigate the consequences of a protection failure. Two-factor authentication (2FA) added on top of that purposely complicates the login process, making regular passwords insufficient to hack and exploit an account.

Regular updates and patch management

Set up regular update checks for solutions included in your supply chain. Installing updates and especially security patches on time means that your system closes known vulnerabilities. This reinforces the security perimeter and can protect your environment from random breaches and brute-force attacks, supporting secure virtualization.

Network segmentation and isolation

Combined with external protection reinforcement, segmenting your network using virtual routers, firewalls and switches can be efficient in isolating critical workloads and data from major threats.

A complex internal environment poses an additional challenge for hackers preparing their attacks. Also, if a network scan shows that the infrastructure is ramified and segmented, some bad actors may even conclude that an attack is not worth the effort.

Backup and Recovery Strategies

Backups are essential in building an efficient VM data protection system. When all else fails, a backup can help you restore critical data and workloads with little to no downtime.

An efficient VM backup and recovery system includes:

Regular and automated VM backups. To ensure minimal downtime, you need a backup with a “fresh” recovery point recorded. Given the complexity of even the smallest corporate virtualized environments, only automation and scheduling backups can ensure their regularity.

Offsite and cloud-based backup solutions. In addition to onsite backups, consider sending data copies to offsite and cloud repositories. This helps you avoid a single point of failure and keep up with the 3-2-1 backup rule.

In case your main infrastructure is down due to a disruption, offsite backups in two different destinations can remain recoverable and accessible.

Disaster recovery planning and testing. Virtualized environments can include hundreds and thousands of virtual machines, servers and clusters to provide stable and efficient services.

To minimize downtime after global failures, you need to plan disaster recovery (DR) sequences and test them regularly. Set up a scheduled testing workflow to ensure checks.

Also, you might want to conduct disaster recovery testing sessions every time you introduce changes into your main virtualized environment.

Advanced VM data protection solutions for secure virtualization, such as NAKIVO Backup & Replication, provide the set of features and functions required to implement the above-mentioned VM backup recommendations.

As a regular user of the NAKIVO solution, specifically for protecting virtualized environments, I’ve experienced firsthand the benefits of its robust features. I highly recommend taking advantage of the free version of this solution, which is available until the end of 2024.

Monitoring and Auditing

One of the most efficient VM data protection best practices for virtualized environments is to monitor resource usage, VM health, and behavior. This includes the following:

Continuous monitoring of virtualized environments. Sufficient hardware resources are crucial for production continuity in virtualized environments. You may want to keep track of infrastructures in general and mission-critical VMs in particular. Thus, you can know the current resource consumption and predict scaling needs and budgets to support system stability as your organization grows.

Audit trails and logging. Audit trails and logging help you get a sequential record of specific activities and data within systems and their components. This includes failed and successful logins, MAC addresses and IPs of involved devices, access locations, data transactions as well as VM and policy changes.

Anomaly detection and response. With monitoring and logging established and functioning, you can detect anomalies in the behavior of users and VMs, and resource consumption changes within system nodes. With such behavioral data, you can timely react to potential security threats.

Advanced Protection Techniques

Advanced threat protection tips for virtual machines describe techniques related to encryption, intrusion detection and prevention systems, and additional security of applications and networks. Let’s review every technique in detail.

Encryption

In a modern IT landscape where any user is able to download and use traffic interception tools, unencrypted data is most likely public data. To enhance your VM data protection for secure virtualization, you can ensure:

• Encrypting data at rest and in transit. Encrypt data during transmission (in flight) and throughout retention (at rest). Such all-round data encryption enables you to enhance protection from unauthorized access in most situations.

• Implementing secure key management. For additional security, consider setting up an encryption key management system. This includes regular generation, secure exchange, storage and use, timely destruction and replacement of encryption keys.

Intrusion Detection and Prevention Systems (IDPS)

Intrusion detection and prevention systems are designed to scan and monitor networks and automatically take action to counter possible breaches.

• Integrating IDPS with VMs. IDPS integration is about revealing the key nodes of your virtual environment and installing program “sensors” that track the situation around them. You can then count on software automation to take the first actions to counter possible intrusions as they occur.

• Real-time threat detection and response. Consider developing specialized workflows for responding to intrusions after the IDPS detects them and stops the most obvious malicious activities. Keep in mind that modern cyberattacks can involve a multi-layered series of smaller hits to distract and deceive the defenders.

Application and Network Security

In addition to supply chain control, network segmentation, and isolation, you can make your VM data protection system more reliable with additional app and network security enhancements. For instance, consider the following steps:

• Hardening VM applications. As apps can become weak links in your protection chain, consider hardening their protection. For example, remove unnecessary components and disable unwanted services that such applications might run. Also, you can set reliable passwords, regular code reviews and role-based access controls within apps.

• Implementing firewall and VPN solutions. These are additional VM data protection best practices that specifically harden networks. External and internal firewalls can prevent unauthorized access to system elements, while VPN connections ensure secure access for authorized users.

Future Trends in VM Data Protection

The future of secure virtualization mainly depends on the evolution of relevant threats. The popularity of virtualization solutions, such as VMWare and Proxmox, defines the close attention that hackers pay to VM vulnerabilities and specifics.

Malicious actors also shape their ransomware, interception, and intrusion tools to become more dangerous to virtualized IT infrastructure. Sophisticated malware enables deeply customized attacks that exploit the VM security weaknesses of the organization’s infrastructure.

The improvement of AI algorithms can bring additional challenges to the field, making malware spread faster, becoming less detectable, and targeting priority nodes with efficient strikes.

However, the same idea works for VM security best practices. AI-driven cyber defense solutions can help detect and counter specific threats in VM environments with significantly better performance and efficiency.

Advanced VM threat detection based on behavioral analysis throughout the entire infrastructure can help reveal malware earlier. Prevention tools independently reacting to potentially dangerous changes in an environment can enable quick response and counter cyberattacks right after they begin.

Lastly, AI can learn how to enhance protection flexibility and introduce defensive changes in an environment depending on how a cyberattack develops. The boosted speed and variety of cybersecurity moves then promote virtualized security (and data protection as a whole) to notably higher effectiveness levels.

Conclusion

Thorough VM security is crucial for any organization that's using virtualized IT environments. Consider implementing strong access controls, patch management, network segmentation, monitoring, auditing and app security to counter key threats and mitigate their outcomes.

You might also want to build an advanced Proxmox replication or VMware backup system to have a swift data recovery option in case of a breach or system failure.

But the beauty of template-it-once-and-deploy-it-everywhere comes with a cost: what if a single layer within that template contains a security vulnerability? And if there was a vulnerability tucked away down there, how would you even know?

In this article, I'll to show you how to use Chainguard (and Docker Scout) to manage security for all your images.

You can watch the video version of this article here:

When you build your software infrastructure on a physical server the traditional way, you'll manually acquire and install each element of the stack one piece at a time. The odds are that you'll be pulling the latest version of everything straight from the official source. And you'll at the very least be thinking about each layer.

But most modern containers are built from complicated templates. It's easy to just copy and paste the code and fire it up. It's very possible that you might not even be aware of all the software that's powering your application. And even if you are, it would easily take you hours of research into each and every element to figure out where you stand.

That's the problem that Chainguard exists to solve. Chainguard provides hundreds of well-maintained custom versions of many of the most popular container images out there.

Of course, you're free to pull, say, the official MariaDB image into your Dockerfile, but going with the Chainguard version instead will be a far safer choice. That's because Chainguard is constantly analyzing their image layers for vulnerabilities and building images that are as up-to-date and secure as possible.

Let's find out how all of this actually works in the real world. Before we get started with building new images, I should tell you how we're going to visualize each image's vulnerabilities so we can quantify the Chainguard advantage.

First though, I should explain that infrastructure vulnerabilities are generally defined using the Common Vulnerabilities and Exposures – or CVE – system based on the National Vulnerability Database maintained by the US government's NIST. There are hundreds of thousands of CVE definitions that have been identified and categorized by the CVE system, with each one rated by severity. The existence of this database – along with a number of important related tools – allows us to automate our security assessments.

Docker Scout is one of those tools. This page gives you installation instructions for using Scout on Docker Engine, but it should run out of the box if you're using Docker Desktop. The curl command will simply download the install-scout Bash script that'll make everything happen.

curl -fsSL https://raw.githubusercontent.com/docker/scout-cli/main install.sh -o install-scout.sh

How to Choose the Right Image

I created a Dockerfile that'll pull the official MariaDB image from Docker Hub:

FROM mariadb:latest

ENV MYSQL_ROOT_PASSWORD=my_root_password
ENV MYSQL_DATABASE=my_database

ENV MYSQL_USER=my_user
ENV MYSQL_PASSWORD=my_user_password

We'll pretend that the image will be used for a multi-tiered deployment, so we'll create a root database and password, and a new user account with it's own password. There might be an application tier instance that'll use those credentials to access the database at some point.

Either way, I'll build the image the usual way, giving it the name mariadb_standard.

docker build -t mariadb_standard .

There's another Dockerfile that's exactly the same as the first one, except that we're pulling the special Chainguard image of MariaDB.

FROM chainguard/mariadb

ENV MYSQL_ROOT_PASSWORD=my_root_password
ENV MYSQL_DATABASE=my_database

ENV MYSQL_USER=my_user
ENV MYSQL_PASSWORD=my_user_password

That image came from Docker Hub, but we could have just as easily pulled it from Chainguard's own repo:

docker pull cgr.dev/chainguard/mariadb:latest

Build this image the same way you did for the official image. When you scan the two images, here's what you'll see:

$ docker images
REPOSITORY         TAG       IMAGE ID       CREATED       SIZE
mariadb_cg         latest    50a484d1ded3   7 days ago    556MB
mariadb_standard   latest    67949ccf8eb5   6 weeks ago   405MB

The Chainguard image is, as you can see, quite larger. But note how it's actually a whole lot more recent.

How to Scan Your Image

Now it's time to put docker scout to work. Here's how that'll work. I'll point Scout to the mariadb_standard image first:

$ docker scout qv mariadb_standard

qv, by the way, is short for quickview.

Here's what the output should look like:

docker scout output

The standard image is made up of three layers, beginning with the Ubuntu 23.10, then Ubuntu 22.04 long term support release, and then MariaDB on top. Ubuntu has 10 Low and 9 Medium vulnerabilities. Alarmingly, the MariaDB layer has 2 Critical and 28 High problems.

This should be enough to keep an admin up at night. And sorting through all of those to figure out which are show stoppers and which aren't such a big deal for your environment will take you a lot of time.

Now I'll run Scout against the Chainguard image:

First off, we can see that there's only one layer here. I suspect that's one way that Chainguard maintains control over their images. Those two Critical vulnerabilities are still there, but there are only 5 High severity and no Medium or Low at all.

If you wanted, you could dive deeper to display all the individual vulnerabilities. Here's the command to do that with an excerpt of the output:

$ docker scout cves local://mariadb_cg
    ✗ CRITICAL GHSA-xfg6-62px-cxc2 [OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities]
      https://scout.docker.com/v/GHSA-xfg6-62px-cxc2
      Affected range : <42.2.8                                         
      Fixed version  : 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.8  
      CVSS Score     : 10.0                                            
      CVSS Vector    : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H    

    ✗ CRITICAL CVE-2024-1597 [Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')]
      https://scout.docker.com/v/CVE-2024-1597
      Affected range : <42.2.28                                      
      Fixed version  : 42.2.28                                       
      CVSS Score     : 10.0                                          
      CVSS Vector    : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

We can research each of those using the standard CVE tools and databases to understand them better. But it'll be a whole lot easier than it would have been researching all 28 High severity vulnerabilities in the standard MariaDB image.

Conclusion

So if you're worried about container image security – and you'd better be – then Docker Scout is an excellent tool for maintaining visibility in your stacks. And Chainguard's cleaner images can give you a significant head start.

There's more IT goodness in the form of books, courses, and videos available at my Bootstrap IT site.

And one of the most popular tools for working with containers is Docker.

Docker is both the name of the company (Docker Inc) and the software they have created which packages software into containers.

To understand how containers work and why they are incredibly useful for software development, you need to understand two seemingly unrelated topics – shipping containers and virtual machines.

A Brief History of Shipping Containers

"The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger" is a book by Marc Levinson. It explores the profound impact of the shipping container on global trade and the world economy.

While the history of the shipping container may seem irrelevant in a discussion about Docker containers, they have more in common than you would expect.

Before shipping containers, cargo handling was labor-intensive and time-consuming, leading to inefficiencies and delays in global trade. Cargo arrived in various shapes and sizes, and the lack of standardised packaging made it challenging to stack and secure items efficiently.

Without standardised containers, cargo was often stored haphazardly in the holds of ships or in dockyards. This inefficient use of space meant that ships were not carrying as much cargo as they could potentially hold, leading to higher transportation costs.

The adoption of uniform container dimensions and handling procedures allowed for seamless transfer of cargo between different modes of transportation – ships, trucks, trains, and the cranes used to move the containers around.

Image showing how standardised container sizes allow them to be easily moved between ships, trains and trucks.

This standardisation was the key to the success of shipping containers. After all, if one company’s containers didn't fit on another company's ship, truck, or freight train, they couldn't be properly transported. Every company would need its own fleet of containers to be able to send things to each of their customers – which would be an operational nightmare.

Standardisation of shipping containers makes them portable, that is easy to move from one place to another. This portability is a key feature of Docker containers as well, which we'll discuss shortly.

What are Virtual Machines?

Virtual machines (VMs) are created through a process called virtualisation.

Virtualisation is a technology that allows you to create multiple simulated environments or virtual versions of something, such as an operating system, a server, storage, or a network, on a single physical machine.

These virtual environments behave as if they are independent, separate entities, even though they share the resources of the underlying physical system.

Virtualisation is like having a magician's hat that can conjure up multiple hats within it. Just as the magician's hat creates the illusion of many hats appearing from just a single physical hat, virtualisation allows a single physical computer or server to appear as multiple virtual machines (VMs), each with its own operating system and resources.

VMs virtualise the hardware. This simply means that a VM takes a single piece of hardware – a server – and creates virtual versions of other servers running their own operating systems. Physically, it is just a single piece of hardware.

Logically, multiple virtual machines can run on top of a single piece of hardware. This is essentially one or more computers running within a computer, as shown below.

Image showing how virtualisation creates several virtual machines (VMs) from a single physical server

How does virtualisation work?

So you might be wondering – how exactly does virtualisation work? Have a look at the image below:

Image showing how virtualisation works by virtualising a single piece of hardware to create multiple virtual machines

At the base, you have the host hardware and OS. This is the physical machine that is used to create the virtual machines. On top of this, you have the hypervisor. This allows multiple virtual machines, each with their own operating systems (OS), to run on a single physical server.

VMs have a few downsides, though, which containers address. Two downsides particularly stand out:

1. VMs consume more resources: VMs have a higher resource overhead due to the need to run a full OS instance for each VM. This can lead to larger memory and storage consumption. This in turn can have a negative effect on performance and startup times of the virtual machine.

2. Portability: VMs are typically less portable due to differences in underlying OS environments. Moving VMs between different hypervisors or cloud providers can be more complex.

The major cloud providers all have VMs. For AWS, it's EC2, GCP has Compute Engine, and Azure has Azure Virtual Machines.

What are Containers?

A container is a lightweight, standalone, and executable software package that includes everything needed to run a piece of software, including the code, runtime, system tools, and libraries.

Containers are designed to isolate applications and their dependencies, ensuring that they can run consistently across different environments. Whether the application is running from your computer or in the cloud, the application behaviour remains the same.

Unlike VMs which virtualise the hardware, containers virtualise the operating system. This simply means that a container uses a single OS to create a virtual application and its libraries. Containers run on top of a shared OS provided by the host system.

This is illustrated below:

Image showing how containers works by virtualising the OS

The container engine allows you to spin up containers. It provides the tools and services necessary for building, running, and deploying containerised applications.

Containers have several benefits:

1. Portability: Containers are designed to be platform-independent. They can run on any system that supports the container runtime, such as Docker, regardless of the underlying operating system. This makes it easier to move applications between different environments, including local development machines, testing servers, and different cloud platforms.

2. Efficiency: Containers share the host system's operating system, which reduces the overhead of running a virtual machine with multiple operating systems. This leads to more efficient resource utilization and allows for a higher density of applications that can run on a single host.

3. Consistency: Containers package all the necessary components, including the application code, runtime, libraries, and dependencies, into a single unit. This eliminates the "it works on my machine" problem and ensures that the application runs consistently across different environments, from development to production.

4. Isolation: Containers provide a lightweight and isolated environment for running applications. Each container encapsulates the application and its dependencies, ensuring that they do not interfere with each other. This isolation helps prevent conflicts and ensures consistent behaviour across different environments.

5. Fast Deployment: Containers can be created and started quickly, often in a matter of seconds. This rapid deployment speed is particularly beneficial for applications that need to rapidly scale up or down based on demand.

What is Docker?

Now that we have covered VMs and containers, what exactly is Docker? Docker is simply a tool for creating and managing containers.

At its core, Docker has two concepts that are useful to understand: the Dockerfile and Docker Images.

A Dockerfile contains the set of instructions for building a Docker Image.

A Docker Image serves as a template for creating Docker containers. It contains all the necessary code, runtime, system tools, libraries, and settings required to run a software application.

So, a Dockerfile is used to build a Docker Image which is then used as the template for creating one or more Docker containers. This is illustrated below.

Image showing the steps to create a docker container. First you create the Dockerfile which is used to build the Docker Image which is finally used to run a Docker container

If this explanation still causes you to scratch your head, consider the following analogy using shipping containers.

Imagine you need to build multiple shipping containers to transport items all over the world. You start with a document listing out the requirements for your shipping container. This will contain information like the container dimensions, type of seals, door locking mechanisms, ventilation and refrigeration requirements (if you are shipping food that needs a temperature controlled environment, for example), and so on.

This requirement document will then be used to create a detailed template for the container which will include engineering drawings showing the dimensions and other specifications.

From this template, the physical containers will then be built. This single template can be used to build one or many physical containers which will all be identical and match the specifications in the container template.

This is illustrated below:

Image showing a shipping container analogue for docker containers

The Dockerfile is analogous to the requirements document, which simply has a set of instructions for building the container template.

The Docker Image is analogous to the container template, which details all the instructions needed for building the physical container.

Once created, Docker images are immutable, meaning they cannot be changed. If you need to make changes to an application, you need to modify the Dockerfile and create a new image. This immutability ensures consistency and reproducibility in application deployment.

And finally, the Docker container is analogous to the physical shipping container.

Bringing it Together

In summary, containers provide a portable and efficient way to package applications and their dependencies, ensuring consistency across various environments. The benefits they bring to software development is similar to the benefits brought to the global economy by the humble shipping container.

Portability

Shipping containers, through standardisation, ensure that any container, anywhere in the world, can be seamlessly used to move items across various modes of transportation – ships, trucks, trains and the cranes used to load them on and off different forms of transport.

Similarly, Docker containers allow for portability. They ensure that applications can run consistently across different environments, from development laptops to production servers, and across different cloud providers.

Increased Efficiency

With standard container sizes, the packing density of goods you can move increases. Now, you can squeeze more things into a single shipping container, compared to the days before the shipping container existed where you had cargo in non standard shapes and sizes stored haphazardly in the holds of ships or on dockyards. So, every ship, freight train or truck can carry more goods during every trip, making it cheaper to move goods around the world.

With Docker containers, better efficiency comes from the fact that containers share the host operating system, making them lightweight compared to VMs. This leads to rapid container startup times and less CPU, memory, and storage use.

Less resource utilisation also means that containers can increase the application density when compared to VMs. With containers, you can run more applications on the same hardware without a significant drop in performance.

To conclude, the shipping container by itself is not magical. After all, it is just a metal box. It is the standardisation of shipping containers which made them portable and a cheap and efficient way to move goods around the world.

In application development, containers benefit from standardisation in the same way. Containers provide a portable and efficient way to package applications and their dependencies, ensuring consistency across various environments.

The software or applications that you install inside the Windows sandbox environment remain "sandboxed", and they all run separately from the host machine. So whatever happens in the sandbox remains there, and your host machine stays 100% safe.

As the Sandbox is a temporary instance of your host machine, when you close it, all of the software, data, files, and the state also get deleted instantly. So you should copy all of the necessary data/software that you'll need later from the sandbox to the host machine before closing it.

Whenever you open the Sandbox, each time you'll get a completely brand-new instance of it. This also means you will get a completely new instance of your host machine that acts as a temporary experiment lab. There you can experiment with any Windows application/data you want, without having the risk of breaking your original host machine.

According to the Microsoft Docs,

Windows Sandbox has the following properties: Part of Windows: Everything required for this feature is included in Windows 10 Pro and Enterprise. There's no need to download a VHD. Pristine: Every time Windows Sandbox runs, it's as clean as a brand-new installation of Windows. Disposable: Nothing persists on the device. Everything is discarded when the user closes the application. Secure: Uses hardware-based virtualization for kernel isolation. It relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host. Efficient: Uses the integrated kernel scheduler, smart memory management, and virtual GPU.

💡(Windows Sandbox enables network connection by default. It can be disabled using the Windows Sandbox configuration file).

In this article, I am using Windows 11 Pro. Windows sandbox is also available to Windows 10 as the documentation says, and the processes are almost the same.

Virtualization with Windows Sandbox

This is an important part of the sandbox. As it runs on an elevated space, it must need the virtualization feature. You have to make sure that you already have enabled virtualization.

If you're wondering how to know whether you've enabled virtualization or not, then don't worry – I am going to show that to you!

Open task manager. You can right click on the Windows logo and click Task Manager, or you can use the shortcut Ctrl + Shift + Esc for that.

After opening the task manager, go to the Performance tab. Then click CPU and check the virtualization status like below.

If the virtualization status says that it has already been enabled like it does on mine, then you are ready to proceed to the next steps.

If it says that it has been disabled, then you need to enable it from the BIOS. I'll show you how to enable virtualization below.

How to enable virtualization on your computer

First, go to BIOS. Depending on the manufacturer of your BIOS, it can be one of these keys to enter into BIOS during booting: Del, Esc, F1, F2, or F4.

When your screen goes black during the reboot process, you have to tap the BIOS key (mentioned above) quickly until the BIOS menu appears. If the key you are using does not work for you, then try rebooting your computer and do the exact process by using the other keys from the keys mentioned above until you get the key working for you.

After entering into BIOS, you have to find the section for your CPU configuration. You may find it under the CPU, Processor, Northbridge or Chipset tab. You may find the configuration section as Advanced or Advanced mode section in your case.

After getting into the CPU configuration section, you have to find the option where it allows you to enable the hardware virtualization. Depending upon your system, you may find names like Hyper-V, Vanderpool, SVM (usually motherboards of Gigabyte use this), AMD-V, Intel Virtualization Technology or simply VT-X.

Enable that option that appears in your case. If you see AMD IOMMU or Intel VT-d, enable them as well.

Then you have to save the changes. You can use the shortcut keys for that as well which should be displayed on your BIOS. Most of the manufacturers use F10 for saving the BIOS configuration.

Then you have to exit the BIOS. Your computer will restart once again. Then if you check the virtualization status from your task manager, you will see that it has been enabled!

Now, I can safely assume that the virtualization has been enabled on your computer.

How to Enable Windows Sandbox

Click the start button or search button and search for Windows features.

Click Turn Windows features on or off.

It will open the Windows Features window like the above picture.

Scroll down until you find Windows Sandbox:

Make sure that you have checked the box like below:

Then click OK.

It will start searching for the required files.

Then it will apply the changes all by itself.

After completing the requested changes, it will ask you to restart your system.

Click Restart now.

After rebooting your computer, your computer is completely ready to use the Windows sandbox.

How to Test Windows Sandbox

Click the start menu or search bar and search for Windows Sandbox.

Windows Sandbox will be opened after that. Do not fear if you get a dark screen like below as it is normal when you first start the sandbox.

After a while, you will see that a new instance of your host machine has appeared right before your eyes.

You can maximize the sandbox window if you want.

Now you can experiment in your sandbox. It will feel like you are using your main host machine, but you're not. You are using a temporary virtual machine with elevated privileges in an isolated environment – and whatever you do in this sandbox, your host machine will remain intact!

How cool is that, right! 😍

If you want to add data/software inside your sandbox, then you have to copy-paste them as you normally do on your computer. Simply copy the file/software that you want to use inside the sandbox, and in the sandbox window, simply paste them in.

How to Close the Sandbox

Be careful here! Whatever you are doing and keeping in your sandbox is happening in a temporary instance. Remember that it's not getting saved anywhere else in your host machine for later use.

Once you close the sandbox, all of the data/apps you are keeping in that sandbox will get deleted instantly.

Before closing the sandbox, you have to make sure that you have not kept anything important in the sandbox that you might need afterward, even after closing the sandbox.

When you want to close the sandbox, simply close the sandbox window. A prompt will appear telling you that once you close the window, all of the files/applications you have in the sandbox will be gone forever.

If everything is okay, then simply click OK. It will close the sandbox.

If you need to open the sandbox again, simply open it like earlier and do your tasks. All of the processes are exactly the same.

Conclusion

Thanks for reading the entire article. If it helps you then you can also check out other articles of mine at freeCodeCamp.

If you want to get in touch with me, then you can do so using Twitter, LinkedIn, and GitHub.

You can also SUBSCRIBE to my YouTube channel (Code With FahimFBA) if you want to learn various kinds of programming languages with a lot of practical examples regularly.

If you want to check out my highlights, then you can do so at my Polywork timeline.

You can also visit my website to learn more about me and what I'm working on.

Thanks a bunch!

Docker has been widely adopted and is used to run and scale applications in production. Additionally, it can be used to start applications quickly by executing a single Docker command.

Companies also are investing more and more effort into improving development in local and remote Docker containers, which comes with a lot of advantages as well.

You can get the basic information about your Docker configuration by executing:

$ docker info

...
 Storage Driver: overlay2
 Docker Root Dir: /var/lib/docker
...

The output contains information about your storage driver and your docker root directory.

The storage location of Docker images and containers

A Docker container consists of network settings, volumes, and images. The location of Docker files depends on your operating system. Here is an overview for the most used operating systems:

• Ubuntu: /var/lib/docker/
• Fedora: /var/lib/docker/
• Debian: /var/lib/docker/
• Windows: C:\ProgramData\DockerDesktop
• MacOS: ~/Library/Containers/com.docker.docker/Data/vms/0/

In macOS and Windows, Docker runs Linux containers in a virtual environment. Therefore, there are some additional things to know.

Docker for Mac

Docker is not natively compatible with macOS, so Hyperkit is used to run a virtual image. Its virtual image data is located in:

~/Library/Containers/com.docker.docker/Data/vms/0

Within the virtual image, the path is the default Docker path /var/lib/docker.

You can investigate your Docker root directory by creating a shell in the virtual environment:

$ screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty

You can kill this session by pressing Ctrl+a, followed by pressing k and y.

Docker for Windows

On Windows, Docker is a bit fractioned. There are native Windows containers that work similarly to Linux containers. Linux containers are run in a minimal Hyper-V based virtual environment.

The configuration and the virtual image to execute linux images are saved in the default Docker root folder.

C:\ProgramData\DockerDesktop

If you inspect regular images then you will get linux paths like:

$ docker inspect nginx

...
"UpperDir": "/var/lib/docker/overlay2/585...9eb/diff"
...

You can connect to the virtual image by:

docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -i sh

There, you can go to the referenced location:

$ cd /var/lib/docker/overlay2/585...9eb/
$ ls -lah

drwx------    4 root     root        4.0K Feb  6 06:56 .
drwx------   13 root     root        4.0K Feb  6 09:17 ..
drwxr-xr-x    3 root     root        4.0K Feb  6 06:56 diff
-rw-r--r--    1 root     root          26 Feb  6 06:56 link
-rw-r--r--    1 root     root          57 Feb  6 06:56 lower
drwx------    2 root     root        4.0K Feb  6 06:56 work

The internal structure of the Docker root folder

Inside /var/lib/docker, different information is stored. For example, data for containers, volumes, builds, networks, and clusters.

$ ls -la /var/lib/docker

total 152
drwx--x--x   15 root     root          4096 Feb  1 13:09 .
drwxr-xr-x   13 root     root          4096 Aug  1  2019 ..
drwx------    2 root     root          4096 May 20  2019 builder
drwx------    4 root     root          4096 May 20  2019 buildkit
drwx------    3 root     root          4096 May 20  2019 containerd
drwx------    2 root     root         12288 Feb  3 19:35 containers
drwx------    3 root     root          4096 May 20  2019 image
drwxr-x---    3 root     root          4096 May 20  2019 network
drwx------    6 root     root         77824 Feb  3 19:37 overlay2
drwx------    4 root     root          4096 May 20  2019 plugins
drwx------    2 root     root          4096 Feb  1 13:09 runtimes
drwx------    2 root     root          4096 May 20  2019 swarm
drwx------    2 root     root          4096 Feb  3 19:37 tmp
drwx------    2 root     root          4096 May 20  2019 trust
drwx------   15 root     root         12288 Feb  3 19:35 volumes

Docker images

The heaviest contents are usually images. If you use the default storage driver overlay2, then your Docker images are stored in /var/lib/docker/overlay2. There, you can find different files that represent read-only layers of a Docker image and a layer on top of it that contains your changes.

Let’s explore the content by using an example:

$ docker image pull nginx
$ docker image inspect nginx

[
    {
        "Id": "sha256:207...6e1",
        "RepoTags": [
            "nginx:latest"
        ],
        "RepoDigests": [
            "nginx@sha256:ad5...c6f"
        ],
        "Parent": "",
 ...
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 126698063,
        "VirtualSize": 126698063,
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/585...9eb/diff:
                             /var/lib/docker/overlay2/585...9eb/diff",
                "MergedDir": "/var/lib/docker/overlay2/585...9eb/merged",
                "UpperDir": "/var/lib/docker/overlay2/585...9eb/diff",
                "WorkDir": "/var/lib/docker/overlay2/585...9eb/work"
            },
...

The LowerDir contains the read-only layers of an image. The read-write layer that represents changes are part of the UpperDir. In my case, the NGINX UpperDir folder contains the log files:

$ ls -la /var/lib/docker/overlay2/585...9eb/diff

total 8
drwxr-xr-x    2 root     root    4096 Feb  2 08:06 .
drwxr-xr-x    3 root     root    4096 Feb  2 08:06 ..
lrwxrwxrwx    1 root     root      11 Feb  2 08:06 access.log -> /dev/stdout
lrwxrwxrwx    1 root     root      11 Feb  2 08:06 error.log -> /dev/stderr

The MergedDir represents the result of the UpperDir and LowerDir that is used by Docker to run the container. The WorkDir is an internal directory for overlay2 and should be empty.

Docker Volumes

It is possible to add a persistent store to containers to keep data longer than the container exists or to share the volume with the host or with other containers. A container can be started with a volume by using the -v option:

$ docker run --name nginx_container -v /var/log nginx

We can get information about the connected volume location by:

$ docker inspect nginx_container

...
"Mounts": [
            {
                "Type": "volume",
                "Name": "1e4...d9c",
                "Source": "/var/lib/docker/volumes/1e4...d9c/_data",
                "Destination": "/var/log",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],
...

The referenced directory contains files from the location /var/log of the NGINX container.

$ ls -lah /var/lib/docker/volumes/1e4...d9c/_data

total 88
drwxr-xr-x    4 root     root        4.0K Feb  3 21:02 .
drwxr-xr-x    3 root     root        4.0K Feb  3 21:02 ..
drwxr-xr-x    2 root     root        4.0K Feb  3 21:02 apt
-rw-rw----    1 root     43             0 Jan 30 00:00 btmp
-rw-r--r--    1 root     root       34.7K Feb  2 08:06 dpkg.log
-rw-r--r--    1 root     root        3.2K Feb  2 08:06 faillog
-rw-rw-r--    1 root     43         29.1K Feb  2 08:06 lastlog
drwxr-xr-x    2 root     root        4.0K Feb  3 21:02 nginx
-rw-rw-r--    1 root     43             0 Jan 30 00:00 w

Clean up space used by Docker

It is recommended to use the Docker command to clean up unused containers. Container, networks, images, and the build cache can be cleaned up by executing:

$ docker system prune -a

Additionally, you can also remove unused volumes by executing:

$ docker volumes prune

Summary

Docker is an important part of many people’s environments and tooling. Sometimes, Docker feels a bit like magic by solving issues in a very smart way without telling the user how things are done behind the scenes. Still, Docker is a regular tool that stores its heavy parts in locations that can be opened and changed.

Sometimes, storage can fill up quickly. Therefore, it’s useful to inspect its root folder, but it is not recommended to delete or change any files manually. Instead, the prune commands can be used to free up disk space.

I hope you enjoyed the article. If you like it and feel the need for a round of applause, follow me on Twitter. I work at eBay Kleinanzeigen, one of the biggest classified companies globally. By the way, we are hiring!

Happy Docker exploring :)

References

• Docker storagediver documentation
  https://docs.docker.com/storage/storagedriver/
• Documentation Overlay filesystem
  https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt

These days I can say to myself "I wouldn't mind testing that on a server running a particular version of CentOS" and - depending on a number of variables and assuming the original image has already been downloaded - I can have a fully-functioning virtual system ready within 30 seconds. Your exact results may vary, but not by that much.

You can see how all this works in my new Pluralsight "Linux System Optimization" course - on which this article is based.

What's been driving all this change? Virtualization. And, in particular, container virtualization.

A virtualized OS is a file system containing all the software libraries, binaries, and configuration files you would need to launch a traditional machine. It's just that this particular file system isn't stored in the root or boot partition that your computer would read as it powers on, but on some other part of your storage volume.

And "powering up" your virtual computer happens when some software cleverly fools the files into thinking they're running all by themselves on their own hardware, when they're really sharing space and resources with the host operating system and, perhaps, some other virtual computers.

Broadly speaking, there are two kinds of software systems used for server virtualization administration: hypervisor and container.

Hypervisors provide a layer of abstraction that permits guest VMs to create an isolated environment with access to the system hardware that emulates a bare metal server. This means that hypervisor VMs can be built from any operating system compatible with your underlying hardware. But it also means that they'll use up more space and more memory and compute resources.

Container Virtualization

Containers, on the other hand, share the host computer's OS kernel and exist within carefully secured and isolated spaces managed by system tools like cgroups. Because they share the kernel, the memory and system resources consumed by containers can be truly minimal, with absolutely nothing wasted. And, as you'll see, the speeds you'll get running container applications will be breathtaking.

A lot of container-related attention over the past few years has been focused on Docker and, more recently, Google's container orchestration tool, Kubernetes. In fact, Kubernetes is well suited for enterprise-scale microservices architectures.

But there's an older and, arguably, more mature implementation of the container model that hasn't gone anywhere. The Linux Container Project, LXC, and its more recent toolset, LXD, have strengths that many would argue make it a better candidate for some use cases than Kubernetes. In particular, LXC excels at building light and fast sandboxed environments for testing and application development.

In this article, I'm going to show you how to install LXD, how to prepare and launch a simple container running the ultra-small Alpine Linux, and then how to open a shell session within your new container. I'll also explain how to find and launch multiple versions of other distributions.

One thing I can tell you right away is that whenever I teach LXC, students respond with amazement at how powerful and efficient using containers can be.

When we're done with all this, you'll be able to fire up machines to hands-on test out whatever it is you're learning or working within seconds. When an experiment goes bad, you can instantly shutdown and remove a container and build another one to replace it. There's simply no longer any excuse not to learn.

Building LXD Containers

We're going to get LXC running working on a fresh install of an Ubuntu 18.04 machine. In this demo, we'll install and initialize an LXD environment and then use the LXD version of the LXC command line interface to download and launch an Alpine Linux container. We'll confirm everything worked and then take a bit of a look around to see how the environment is populated.

I'm going to use the snap package manager to install LXD because that's now the official recommendation. And not just for LXD, mind you: all kinds of applications are drifting to alternate managers like snap or AppImmage and Flatpak. I still love my Debian aptitude, but you can't fight the whole world.

$ sudo snap install lxd

LXD - which, again, is an updated toolset designed to manage the LXC API - comes in a package that includes all the regular LXC dependencies. One install command and we're done.

It's important to initialize the LXC environment using the lxd init command. You could set things up yourself manually, but you're more likely to get it all right this way. The init process will ask you a bunch of questions and, for now at least, the default answers will all work.

$ sudo lxd init

Once that's done, we're ready to build your first container. Whichever Linux distribution and version we want, we'll need to find and download the image. The LXC project maintains a repository of quite a range of images at images.linuxcontainers.org. You can see that there are usually multiple versions of each distro, permitting you to build containers that'll work with just about any software you can throw at it.

I'm going to use the latest version of Alpine Linux because it's really small. Feel free to use any image you like - including the big boys like Ubuntu and CentoOS. Alpine, of course, will download very quickly.

But before we do that, I should tell you how to figure out the command line syntax necessary to get your image.

As you can see in this screen shot from the LXD website, you can get three pieces of information you'll need from the page itself: the name of the distro - Alpine, in this case - the release number - 3.10 - and the architecture. We're after amd64.

From the images.linuxcontainers.org page

We're now ready to trigger the download by running the launch command:

$ sudo lxc launch images:alpine/3.10/amd64 demo

Notice how the syntax is "lxc" even though this is technically an LXD interface. "images" tells LXC that our image lives in the public repo we saw earlier. Our three bits of data - the distro name, release number, and architecture, are entered separated by forward slashes. I'll use "demo" as the name of my container. That should be all we need.

You can see how small Alpine is by how quickly it downloads. My internet connection isn't that fast and I haven't played any games with the recording. To confirm that it worked, I'll run "lxc ls" to list all the containers currently installed. There's just the one. And its current status is "running".

sudo lxc ls
+------+---------+----------------------+------------+-----------+
| NAME |  STATE  |         IPV4         |    TYPE    | SNAPSHOTS |
+------+---------+----------------------+------------+-----------+
| demo | RUNNING | 10.125.45.119 (eth0) | PERSISTENT | 0         |
+------+---------+----------------------+------------+-----------+

You can open a non-login root session in a container using the "lxc exec" command. Just specify the container name and then tell LXC that you want to run a shell using the sh interpreter (you might prefer /bin/bash if you're working with an Ubuntu or CentOS container - your call either way). As you'll be able to see for yourself if you're following along at home, we've got a normal Linux command prompt and anything Linux-y is now possible.

$ sudo lxc exec demo sh
~ #

You could also run a single command without opening a full shell by typing the command instead of this sh.

$ sudo lxc exec demo ls /
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

You can bail out of the shell any time you like using exit and return to your host. Here, besides listing running containers, I can also list any storage pools. The default pool that was created during initialization is there, and we can see where the disk image is stored. /var/lib/lxd is, by default, where all LXC resources are kept.

$ sudo lxc storage ls
+---------+-------------+--------+--------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |             SOURCE             | USED BY |
+---------+-------------+--------+--------------------------------+---------+
| default |             | btrfs  | /var/lib/lxd/disks/default.img | 3       |
+---------+-------------+--------+--------------------------------+---------+

I can similarly list all my networks. There happen to be a few network bridges on this system (I've been playing around a bit, as you can see). There's also the physical enp0s3 bridge used by the host Ubuntu server. Although between you and me, that one's not physical either, as this is actually a VM running in Oracle's Virtual Box.

$ lxc network ls
+---------+----------+---------+-------------+---------+
|  NAME   |   TYPE   | MANAGED | DESCRIPTION | USED BY |
+---------+----------+---------+-------------+---------+
| enp0s3  | physical | NO      |             | 1       |
+---------+----------+---------+-------------+---------+
| lxdbr0  | bridge   | YES     |             | 1       |
+---------+----------+---------+-------------+---------+
| mynet   | bridge   | YES     |             | 0       |
+---------+----------+---------+-------------+---------+
| testbr0 | bridge   | YES     |             | 1       |
+---------+----------+---------+-------------+---------+

If we needed to, we could easily add a new virtual interface to our container using the "lxc network attach" command. Here, I'll specify the physical network and then the name of our container.

$ lxc network attach enp0s3 demo

With that done, you could open a new shell in the container to see what's changed. There should now be an eth1 interface listed. You may need to reboot for all the changes to take full effect. By doing that you can also marvel at just how fast this thing can reboot itself - for all intents and purposes, it'll happen faster than you can type your exec command to open a new shell.

Enjoy your new environment!

This article is based on content in my Pluralsight course, "Linux System Optimization." There's much more administration goodness in the form of books, courses, and articles available at bootstrap-it.com.

All of which means that even if you wanted to go around logging into each of your many servers, it just wouldn't make sense. In most cases in fact, it wouldn't even be possible. Instead, you're going to be running a lot of clever scripts. And the tools you use to run those kinds of scripts are generally called orchestrators.

I'm sure you've encountered at least one or two members of the orchestration club. Besides Ansible, there's Terraform, Chef, Puppet and others. But there are also lower-level tools that work as add-ons to core Linux tools like SSH. Although, seeing how it'll run natively on Windows and, of course, macOS, I'm not sure it's quite correct to call SSH a "Linux" tool any more.

One of those SSH add-ons is a tool set called pssh - which stands for Parallel SSH. That's what we're going to be learning about in this article - which is excerpted from my new Pluralsight course, Linux System Optimization.

For now, though, I'm going to tell you a bit about the lab I'm using so that you can more easily reproduce it and follow along at home. I've got three Ubuntu LXD containers running. The base for all of our operations will be the one with an IP address of 10.0.3.140, while the two host nodes we'll be remotely provisioning will use 10.0.3.93 and 10.0.3.43.

Everything we'll do assumes that we've got passwordless SSH access from my base container to each of the two nodes. If you're not sure how to do that, you can view the SSH module of my Protocol Deep Dive: SSH and Telnet course on Pluralsight. If you're in a hurry, this Red Hat tutorial will get you to the same place.

Installing pssh on Ubuntu is simple and quick: sudo apt install pssh. It doesn't get any harder on CentOS.

I created a simple host inventory file called sshhosts.txt that contains nothing more than the IP addresses of my two nodes:

$ less sshhosts.txt
10.0.3.93
10.0.3.43

Now I'm going to run the pssh parallel-ssh command to execute a single command on my hosts.

$ parallel-ssh -i -h sshhosts.txt df -ht ext4

-i tells the program to run as interactive - otherwise we wouldn't be shown any command output. -h points to the hosts file that I called sshhosts.txt. And the command itself will be the old Unix utility df. That'll return a list of drives attached to the system along with their mount points and usage information. The -h here will display disk space in human readable units and the t will restrict access to only drives formatted as ext4.

Why do I care about that ext4 business? Because Ubuntu uses the snap package manager and each snap creates its own virtual device. So what? Well, I don't want to have to comb through a dozen or so virtual devices reporting 0 free space just to get to the real drives reporting actual usage.

$ parallel-ssh -i -h sshhosts.txt df -ht ext4
[1] 22:02:00 [SUCCESS] 10.0.3.43
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       457G  131G  304G  30% /
[2] 22:02:00 [SUCCESS] 10.0.3.93
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       457G  131G  304G  30% /

And there you go! Full disk space information about both of my nodes. I'm sure you noticed that the information is identical. That's because these are both containers running on my workstation, so as far as they know, they both have full access to my own drive.

For my next trick, I'll collect the /etc/group files from each of my nodes. This is the kind of operation that could be useful to quickly monitor the security status of your nodes. You could add a script that parses the incoming data and alerts you if there are any anomalies.

Before I begin, I'll create a directory locally called host-files. Then I'll use the parallel-slurp command - whose name wonderfully describes its function. Again, -h points to the hosts file. The -L sets the host-files directory as the target location for writing the data we're going to generate, /etc/group is the remote file we want to slurp up, and group is the name we'd like to assign the data locally.

mkdir host-files
parallel-slurp -h sshhosts.txt -L host-files/ /etc/group group

When it's done, your host-files directory will contain sub-directories named after the IP address of each of your nodes. As you can see, there's a file called "group" that contains the /etc/group data from each node.

$ tree host-files/
host-files/
├── 10.0.3.43
│   └── group
└── 10.0.3.93
    └── group

Does pssh come with any other treats? Yup. And running apropos gives you the whole list.

$ apropos parallel
parallel-nuke (1)    - parallel process kill program
parallel-rsync (1)   - parallel process kill program
parallel-scp (1)     - parallel process kill program
parallel-slurp (1)   - parallel process kill program
parallel-ssh (1)     - parallel ssh program

This article is based on content in my Pluralsight course, "Linux System Optimization." There's much more administration goodness in the form of books, courses, and articles available at bootstrap-it.com.

And then there was Docker. Docker containers streamlined container operations so that software resources used by multiple containers could be efficiently shared. They also added online public repositories populated by vast collections of software tools. But the real value of Docker was in how easy it made deploying reliably predictable application environments.

What Kubernetes Brings to the Table

Then, out of the mists of time appeared Kubernetes. While originally developed within Google, Kubernetes has since been released as open source software under the control of the Cloud Native Computing Foundation.

At its heart, Kubernetes manages containers just the way Docker does. But Kubernetes adds a vast ecosystem of scaling, load balancing, network proxying, and multi-node administration tools to the mix. Docker’s own Swarm comes with a comparable suite of tools, but Kubernetes has, so far at least, proven far more popular.

Kubernetes is much more of a native enterprise-scale tool than Docker Swarm. It's not that Docker Swarm can't be used in the enterprise - it certainly can - it's that Kubernetes isn't necessarily such a great fit for a quick and dirty local development environment. The main reason is that, at this point at any rate, you need an existing cluster before you can get anything to happen, and creating a local cluster requires a running hypervisor of one flavor or another. So having a public cloud like AWS where you can freely provision all the bits and pieces that go into a cluster without having to worry about infrastructure, matters more for Kubernetes than it does for Docker in general.

Kubernetes' larger resource footprint and steeper learning curve can be offset by some impressive integration: working with persistent storage volumes is straightforward. And robust deployment monitoring solutions are easily available.

A Quick Look at the Kubernetes Cluster

Here - based on content from my Pluralsight course, “Using Docker on AWS” - is how Kubernetes works. A cluster is made up of the networking, storage, and compute resources that your workloads will use. The cluster's physical or virtual computers - called nodes - serve as either primaries or replicas. A primary runs the services that manage all cluster operations. The primary itself is managed through the kube-apiserver service which responds to instructions you send to it using the kubectl client software. The primary also hosts:

• A database of cluster configuration known as etcd
• kube-controller-manager, that measures the current state of a cluster
against its desired state
• kube-scheduler, which balances configuration specifications against avail-
able resources
• The cloud-controller-manager that provides critical integration with public
cloud providers like AWS

Nodes are controlled by software agents called kubelets and maintain reliable and secure network connectivity through the kube-proxy service. Important stuff - your actual application workload - happens on the nodes within pods, which are organizing structures within which the application containers themselves run. Multiple containers can run on a pod, all sharing a single IP address and compute resources - providing a single instance of your application.

The components of a typical Kubernetes environment

The good news is that the kubectl software is smart enough to simply read your YAML configuration document and use it to bring all the details to life without your help. If you want to become a successful Kubernetes admin you really should understand all these details. But you can be forgiven for being a bit relaxed about it all in the meantime: most of the action takes place invisibly, hidden by the relatively simple command set we'll soon see.

A Quick Kubernetes Installation

Just so you can't say I didn't show you anything practical here, let's install the lightweight Kubernetes version, MicroK8s, on a Linux machine. All you'll need for this in-and-out exercise is a working copy of the Snaps package manager. This single command will install all the core services, libraries, and binaries necessary for small, proof-of-concept demos.

snap install microk8s --classic

Just to prove that the installation succeeded, ask the service to list all the nodes
that are currently running. Of course, there won’t be any of those yet.

$ sudo microk8s.kubectl get nodes
No resources found.

There will, however, be a single service with a private IP address associated with
it:

$ sudo microk8s.kubectl get services
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.152.183.1   <none>        443/TCP   80s

Finally, you can enable the browser-based Kubernetes administration dashboard using this microk8s.enable command. The output you'll get will include extra instructions for displaying and using the authentication token you'll need to connect.

$ sudo microk8s.enable dns dashboard
Enabling DNS
Applying manifest
serviceaccount/coredns created
configmap/coredns created
[...]
If RBAC is not enabled access the dashboard using the default token retrieved with:

token=$(microk8s.kubectl -n kube-system get secret | grep default-token | cut -d " " -f1)
microk8s.kubectl -n kube-system describe secret $token

In an RBAC enabled setup (microk8s.enable RBAC) you need to create a user with restricted permissions as shown in https://github.com/kubernetes/dashboard/wiki/Creating-sample-user

This article is based on content in my Pluralsight course, "Using Docker on AWS." There's much more administration goodness in the form of books, courses, and articles available at bootstrap-it.com.

But all is not entirely lost. The problem of keeping track of
sufficiently complex passwords can be largely solved by using a good
password vault like KeePass2 or LastPass. And the problem of overusing
passwords can be at least blunted by implementing a single sign-on
solution like Kerberos. Ok. Not like Kerberos, but Kerberos.

Still, dumb mistakes are always going to happen.

So what’s bound to happen to the one or two users who care enough to dream up good, strong passwords for each server they access? Every now and then they’ll forget a password, of course. That won’t be a problem if there’s another admin with sudo power who can log into the server and run passwd to create a new password for the user.

sudo  passwd username
[sudo] password for yourname:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

But if your unlucky and forgetful user was the only admin with an account on that machine, you’ve got trouble. Except that you don’t. chroot — the grandfather of all Linux virtualization — is going to save your day.

Here, as I wrote in chapters 6 and 9 in my Linux in Action book, is one way that it might work. Use a live-boot drive to power up the server that’s got you locked out.

Steps for creating a Linux live boot USB

Then open a terminal and run lsblk to determine the designation of your root partition on the server’s hard disk, and mount the root partition to a temporary directory.

mkdir /run/mountdir/
mount /dev/sdb1 /run/mountdir/

Then you whisper the magic words and you’re in:

chroot /run/mountdir/
root@ubuntu:/#

That’s all it takes. At this point, you’re free to run commands as though you were working on a running version of the physical hard drive. Use passwd to give your admin a new password to replace the lost one and, after typing exit to shut down your chroot session, reboot the machine (without the live-boot USB). Everything should now be fine.

To encrypt or not to encrypt

Encrypting the data on your storage drives using tools like ecryptfs or dm-crypt makes it a great deal less likely that your data will be compromised. But on the other hand, many rescue and recovery operations like the above chroot trick simply won’t work on an encrypted volume.

Striking a balance between security and accessibility isn’t an exact
science. Many admins, for instance, will leave local servers and desktop workstations unencrypted — because they’re at least protected by locked office doors — but insist that mobile devices be encrypted.

Recovering a locked VM

You can apply the magic of chroot to clean up all kinds messes. Locked out of a local server (or LXC container)? Feel free to open a chroot shell to disable or even reconfigure your firewall.

Getting that done on a physical machine should be straightforward by now. But here’s how it would work on an LXC container.

First of all, stop the container and then run chroot against the rootfs directory
that’s within the directory hierarchy used by your LXC container ( var/lib/lxc/
your-container-name/ ). The command prompt you’ll get will allow you to execute commands as if the container was actually running. Now disable ufw or, if you prefer, run the necessary commands to fix the problem and then exit the chroot shell. When you start the container back up again, you should now have SSH access.

lxc-stop -n your-container-name
chroot /var/lib/lxc/your-container-name/rootfs/
ufw disable
exit
lxc-start -d -n your-container-name

This article is excerpted from my Manning “Linux in Action” book. There’s lots more fun where this came from, including a hybrid course called Linux in Motionthat’s made up of more than two hours of video and around 40% of the text of Linux in Action. Who knows…you might also enjoy my recently published Learn Amazon Web Services in a Month of Lunches.

So let me throw my purely speculative prediction into the silence. As I describe in my Learn AWS in a Month of Lunches book, AWS has happily replaced your server room with EC2, your SAN and NAS with S3, your data warehousing with Redshift, and your database with RDS (and Aurora). They’ve also invented entirely new deployment models: politely informing you, for instance, that you simply have to serve your mobile apps via serverless functions (Lambda).

So what’s next? Well how about enterprise routing?

What is enterprise routing these days?

For decades, large organizations have controlled their internal network traffic with switches and routers configured by proprietary operating systems. The hardware is expensive (a single appliance can easily hit $10,000) and the cost of hiring the trained admins needed to maintain them can be much higher.

But is all that really still necessary?

These days your workloads are more likely to live in the cloud than in your actual office. Even in-house Internet of Things devices can easily be controlled from the cloud using, for instance, AWS IoT. I’m guessing that most modern on-premises enterprise routing involves controlling how people connect to production resources and to each other (email, VOIP, video) — but even that is more and more likely to be outsourced to SaaS solutions.

I may be missing something, but I just don’t see a compelling case for hardware switches here. Software-defined networking (SDN) should easily be up to the task. Why not just cover your campus in wireless access points, authenticate users using Kerberos or Active Directory, and configure your way to permissions/connectivity perfection.

How AWS can rule the routing world?

Which brings me back to AWS. They’ve already got all the bases covered for authentication (AWS Directory Service) and high-end remote connectivity (AWS Direct Connect). It probably wouldn’t take much for them to extend their networks to your campus. Perhaps they’d allow you to create local VPCs — complete with configurable subnets — that you’d use to organize your local infrastructure.

I’m imagining a company’s admin logging into the AWS Console to onboard a couple of new hires from marketing. They’d be added to an AWS IAM “Marketing” group that’s already got access to Amazon QuickSight dashboards and streaming data from your public-facing web servers running on EC2. But the group could just as easily be configured to allow its members into a database that, for regulatory reasons, must remain local.

What do you think? Are the days of the proprietary system network admin numbered?

Looking for more? You might enjoy my books and Pluralsight courses on Linux, AWS, and Docker-related topics.

Whether you’ve got your career and/or home mortgage deeply invested in the future of Xen or whether you never knew it existed, you might be interested in learning more about KVM. So here’s a general introduction adapted from my book, Teach Yourself Linux Virtualization and High Availability: prepare for the LPIC-3 304 certification exam.

_Need some more basic background on either Linux servers or AWS? My Linux in Action and Learn Amazon Web Services in a Month of Lunches books from Manning might help, along with my Linux server administration courses at Pluralsight. There’s also a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action._

KVM

Like Xen, KVM (Kernel-based Virtual Machine) is an open source hypervisor technology for virtualizing compute infrastructure running on x86 compatible hardware. Also like Xen, KVM has both an active user community and significant enterprise deployments.

A KVM host actually runs on the Linux kernel along with two KVM kernel modules (the kvm.ko module and either kvm-intel.ko or kvm-amd.ko). Through its tight kernel integration — including the I/O connectivity with kernel block and network drivers provided by Virtio — KVM can offer its guests more seamless access to all the complex hardware and networking profiles that they might encounter.

Hardware virtualization extensions built into modern CPU designs and required for KVM deployments mean that, right out of the box, KVM guests can safely access only those hardware resources they need without the need to worry about leakage to the larger system.

Where exactly does QEMU fit in with all this? Besides being able to act as a hypervisor, QEMU’s strength is as an emulator. KVM, in its hypervisor virtualization role, can tap on to QEMU’s emulation powers to compliment its own hardware acceleration features, presenting its guests with an emulated chipset and PCI bus. The whole, as they say, can be greater than the sum of its parts.

A KVM hypervisor sitting between the Linux host OS and its guest VMs

A great deal of management functionality for KVM is often actually provided by Libvirt. Therefore, you might sometimes want to refer to the detailed information about KVM-related features like networking, storage, and file system layouts that’s found in the fifth chapter of the Teach Yourself Linux Virtualization and High Availability book (“Libvirt and Related Tools”).

Installation

Before anything else, you’ll need to make sure that the physical machine you’re planning to use as a KVM host supports hardware virtualization. Besides the BIOS setting and the contents of /proc/cpuinfo (which we discussed in Chapter One), you can also quickly check this from a running Linux system using kvm-ok:$ kvm-ok

It’s also a good idea to be sure which hardware architecture — 64 or 32-bit — you’re working with:$ uname -m

But even if your hardware profile is up to the task, you’ll have to let the Linux kernel in on your plans. If they’re not already there, you should add the kvm and either kvm-intel or kvm-amd kernel modules.# modprobe kvm-intel

If those modules fail to load (and there’s no /dev/kvm device in the file system), then there’s a good chance your CPU just isn’t up to the job you’d like it to to. However, if all that worked out, you’re ready to install the qemu-kvm package (and, if necessary, libvirt, virt-install, and bridge-utils as well).

Working with KVM Management Tools

It’s no secret that virtualization platforms have a well-deserved reputation for being complicated. But there are two things that can make getting started with KVM just a bit more challenging than some of the others:

• There are quite a few management toolkits available, each offering similar — but not identical — functionality.
• They have a nasty habit of changing the names used for the key binaries depending on which distribution and release you’re using.

I’ll introduce you to Libvirt Tools and vmbuilder in Chapter Five, but here, we’ll discuss the KVM tool kit.

Building new guests using what we’ll call the “KVM” way is a two step process. First, you’ll use qemu-img to create a new image — or modify or convert an old one. Then you’ll use qemu-kvm to set up a virtual machine that will start up the installation.

_Did I just say “you’ll use qemu-kvm…”? Silly me. qemu-kvm was merged into qemu a long time ago and has been replaced by qemu-system-x86_64. In the meantime, some systems offer you kvm as a wrapper that executes qemu-system-x8664 -enable-kvm — although you shouldn’t confuse the kvm wrapper with the old kvm binary that used a somewhat different syntax.

So let’s see how these two steps work. You create a disk image with qemu-img (which, by the way, can be used very effectively for other hypervisors as well), where “my-disk” is the name of the image you’d like to create, the maximum size of the image will be 6 GB, and qcow2 is the file format. qcow, by the way, stands for “QEMU Copy On Write”.

qemu-img create -f qcow2 /home/username/myimages/my-disk.img 6G \
 Formatting ‘/home/username/myimages/my-disk.img’, \
 fmt=qcow2 size=6442450944 \
 encryption=off \
 cluster_size=65536 \
 lazy_refcounts=off \
 refcount_bits=16

Choosing a file format will depend on your specific needs. If you need greater compatibility and flexibility — including the ability to generate sophisticated snapshots — then qcow2 is probably going to be your best choice.

The qcow disk image format permits disk space allocation to grow only as needed, meaning the use of space is always as efficient as possible. Changes to a qcow read-only image can be saved to a separate file, which refers internally to the original image. qcow2 added the ability to create multiple image snapshots.

We’re now ready for step two. Here’s how we’ll build our VM:

kvm -name my-VM \
 -hda /home/username/myimages/my-disk.img \
 -cdrom /home/username/Downloads/ubuntu-16.04-server-amd64.iso \
 -boot d -m 1024

A new SDL window will often (although not necessarily for all distributions) pop up where you can complete the operating system installation process. Regaining control of your mouse from the Qemu terminal requires pressing CTRL+ALT.

To explain: using “kvm” (although the precise command you’ll need for your version may differ), we’ll call our new guest “my-VM”, designate the my-disk.img file as hda (“hard drive a”), point to the location of the operating system ISO (Ubuntu 16.04 server, in this case), and set 1024 MB as the maximum memory alloted to the VM.

By default, KVM will configure your guest for user-level networking (as though the parameters -netdev user,id=user.0 -device e1000,netdev=user.0 were specified). This will provide the guest with an IP address through KVM’s own DHCP service and access to your host, the Internet, and to LAN-based recourses. While the default configuration is simple, it may be overly restrictive for some scenarios, as there are often some performance and feature limitations.

Besides these, you can use command line flags to control various VM configuration parameters, including:

• -smp 2 provides two processors (“smp” = symmetric multiprocessing).
• The -net argument (example: -net nic,model=virtio,macaddr =52:54:00:05:11:11) establishes a network connection for your guest.
• You can provision a network bridge using something like -net bridge,vlan=0,br=br0 — although this will require a matching -net definition on the host. The two are connected through a special “vlan” parameter.
• -balloon virtio will allow me to expand or reduce a guest’s memory size without having to reboot it.
• You can also use the -drive file= flag to define additional block storage devices. Adding a value for format= (qcow2, for instance).

The -M flag will assign a specific machine type hardware emulation. pc. For example, will provide a standard PC profile. For a complete list of available machine types, you can run kvm -M ?:

kvm -M ?
Supported machines are:
ubuntu Ubuntu 15.04 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-wily)
pc-i440fx-wily Ubuntu 15.04 PC (i440FX + PIIX, 1996) (default)
ubuntu Ubuntu 15.04 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-vivid)
pc-i440fx-vivid Ubuntu 15.04 PC (i440FX + PIIX, 1996) (default)
pc-i440fx-utopic Ubuntu 14.10 PC (i440FX + PIIX, 1996)
pc-i440fx-trusty Ubuntu 14.04 PC (i440FX + PIIX, 1996)
pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.5)
pc-i440fx-2.5 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.4 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.3 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.2 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.1 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.0 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.7 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.6 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.5 Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996)
pc-1.3 Standard PC (i440FX + PIIX, 1996)
pc-1.2 Standard PC (i440FX + PIIX, 1996)
pc-1.1 Standard PC (i440FX + PIIX, 1996)
pc-1.0 Standard PC (i440FX + PIIX, 1996)
pc-0.15 Standard PC (i440FX + PIIX, 1996)
pc-0.14 Standard PC (i440FX + PIIX, 1996)
pc-0.13 Standard PC (i440FX + PIIX, 1996)
pc-0.12 Standard PC (i440FX + PIIX, 1996)
pc-0.11 Standard PC (i440FX + PIIX, 1996)
pc-0.10 Standard PC (i440FX + PIIX, 1996)
q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35–2.5)
pc-q35–2.5 Standard PC (Q35 + ICH9, 2009)
pc-q35–2.4 Standard PC (Q35 + ICH9, 2009)
pc-q35–2.3 Standard PC (Q35 + ICH9, 2009)
pc-q35–2.2 Standard PC (Q35 + ICH9, 2009)
pc-q35–2.1 Standard PC (Q35 + ICH9, 2009)
pc-q35–2.0 Standard PC (Q35 + ICH9, 2009)
pc-q35–1.7 Standard PC (Q35 + ICH9, 2009)
pc-q35–1.6 Standard PC (Q35 + ICH9, 2009)
pc-q35–1.5 Standard PC (Q35 + ICH9, 2009)
pc-q35–1.4 Standard PC (Q35 + ICH9, 2009)
isapc ISA-only PC
none empty machine
xenfv Xen Fully-virtualized PC
xenpv Xen Para-virtualized PC

KVM Monitor

While working with QEMU, you can open a monitor console and interact with your clients in ways that might be difficult or even impossible using a regular headless server. You can launch the KVM Monitor by pressing CTRL+ALT, and then SHIFT+2, and a new console will open on your desktop. SHIFT+1 will close the console. You can also access the console from the command line using something like:

kvm -monitor stdio

You will probably NOT be able to launch the monitor as root (i.e., via sudo). Naturally, your version may require “qemu-system-x86_64” rather than kvm. This approach allows you to add command line arguments (like that -monitor which specified a console target). Consult man qemu-system-x86_64 for details on the kinds of operations the monitor allows.

This example (borrowed from en.wikibooks.org/wiki/QEMU/Monitor) will list all the block devices currently available to your system, and then point one of them to an ISO file you want to use:

(qemu) info block
ide0-hd0: type=hd removable=0 file=/path/to/winxp.img
ide0-hd1: type=hd removable=0 file=/path/to/pagefile.raw
ide1-hd1: type=hd removable=0 file=/path/to/testing_data.img
ide1-cd0: type=cdrom removable=1 locked=0 file=/dev/sr0 ro=1 drv=host_device
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]
(qemu) change ide1-cd0 /home/images/my.iso

Networking

By default, a KVM guest will receive an IP address within the 10.0.2.0/24 subnet, and have outgoing access (including SSH access) both to its host, and to the wider network beyond. By that same default however, it won’t be able to host services for network clients. If you need to open up incoming network connectivity, you’ll probably want to create a network bridge on your host that’s similar to the one we used for Xen in the previous chapter. As before, you will install bridge-utils on the host and, assuming you’re running a Debian-based system and you want your host to receive its IP from a network DHCP server, edit the /etc/network/interfaces to look something like this (on CentOS machines, edit files in the /etc/sysconfig/network-scripts/ directory):

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet dhcp
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0
 bridge_maxwait 0

On CentOS, you’ll need to create an ifcfg-br0 file in the /etc/sysconfig/network-scripts/ directory to look something like this:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
DNS1=192.168.0.1
GATEWAY=192.168.0.1
IPADDR=192.168.0.100
NETMASK=255.255.255.0
ONBOOT=yes
SEARCH=”example.com”

…And then add a line reading BRIDGE=br0 line to your primary network interface file (which will often be: /etc/sysconfig/network-scripts/ifcfg-eth0).

You will then stop and restart your network services (or reboot).

Looking for a solid introduction to Linux or AWS administration? Check out my Linux in Action and Learn Amazon Web Services in a Month of Lunches books and the Linux in Motion text-video hybrid course from Manning. Prefer your tech learning in video? I’ve got Linux administration courses at Pluralsight just waiting to be watched.

The Cloud is the most obvious and logical platform for container
deployment.

Amazon Web Services largely dominates the cloud computing world. Add it up. If you’re interested in getting a piece of all this action, you’ll definitely want to figure out how it all works.

First, though, let’s quickly define some key terms.

Virtualization

Virtualization is the division of physical computer and networking resources into smaller, more flexible units, presenting these smaller units to users as though each was a discrete resource.

The idea is that, instead of assigning specific computing tasks to individual physical servers — which may sometimes end up being over- or underused — a single physical server can be logically divided into as few or as many virtual servers as needed.

That means, as the figure below illustrates, there can be dozens of individually installed operating systems (OS) running side by side on the same hard drive. Each OS is effectively unaware that it isn’t all alone in its local environment.

Multiple applications being served through physical servers or, via VMs, from a single virtualization server

Practically, each operating system instance can be accessed remotely by both administrators and customers in exactly the same way as any other server.

In this kind of environment, as soon as your virtual server completes its task or becomes unnecessary, you can instantly delete it. This will free up the resources it was using for the next task in the queue.

There’s no need to over-provision virtual servers to anticipate possible future needs, because future needs can be easily met whenever they arrive.

In fact, today’s virtual server might only live a few minutes or even seconds before, having completed its task, being shut down for good to make room for whatever’s next. All this allows for far more efficient use of expensive hardware. It provides the ability to provision and launch new servers at will, either to test new configurations or add fresh power to your production services.

Cloud computing providers like AWS use virtualized computers of one kind or another. The hundreds of thousands of Amazon EC2 instances, for example, all run on top of the open source Xen or KVM hypervisors — which are themselves installed and running on many thousands of physical servers maintained in Amazon’s vast server farms.

Whatever hypervisor technology is being used, the goal is to provide a largely automated hosting environment for multiple complete, self-contained virtual computers.

Containers like Docker, on the other hand, aren’t standalone virtual machines but are modified file systems sharing the operating system kernel of their physical host. That’s what we’ll discuss next.

Containers

What are containers? Well, for one thing, they’re not hypervisors. Instead, they’re extremely lightweight virtual servers that, as you can see from the figure, rather than running as full operating systems, share the underlying kernel of their host OS.

Virtualized containers running with access to their host’s kernel and hardware resources

Containers can be built from plain-text scripts, created and launched in seconds, and easily and reliably shared across networks. Container technologies include the Linux Container project, which was Docker’s original inspiration.

The script-friendly container design makes it easy to automate and remotely manage complex clusters of containers, often deployed as microservices.

Microservices is a compute services architecture where multiple containers are deployed, each with a distinct yet complementary role. You might, therefore, launch one container as a database back-end, another as a file server, and a third as a web server.

Docker

As I explore in one or two of my Pluralsight courses, a Docker container is an image whose behavior is defined by a script. The container is launched as a software process that’s cunningly disguised as a server.

But what’s an image? It’s a software file containing a snapshot of a full operating system file system. Everything necessary to launch a viable virtual server is included.

An image might consist of just a base operating system like Ubuntu Linux, or the tiny and super-fast Alpine Linux. But an image could also include additional layers with software applications like web servers and databases. No matter how many layers an image has and how complicated the relationships between them might be, the image itself never changes.

When, as shown in the next figure, an image is launched as a container, an extra writable layer is automatically added into which the record of any ongoing system activity is saved.

A simple MySQL/Ubuntu Docker image illustrated with its writable data layer

What do folks commonly do with their Docker containers? Often, they’ll load up some kind of app development project to test how it will work, and then share it with team members for feedback and updates. When the app is complete, it can be launched as a cluster of containers (or “swarm” as Docker calls it) that can be programmatically and instantly scaled up or down according to user demand.

While Docker is a Linux-based technology and requires a Linux kernel to run, running remote or even local Docker containers on Mac or Windows machines is possible through either the Docker for Mac or Docker for Windows apps or for older machines, through the Docker Machine tool.

Cloud computing

Cloud computing is the provision of on-demand, self-service compute, memory, and storage resources remotely over a network.

Since cloud-based services are billed in very small increments, you can quickly configure and launch a wide range of projects. And since the resources are all virtual, launching them as part of an experiment or to solve some short-term problem will often make lots of sense. When the work’s all done, the resource is shut down.

Cloud platforms let you do things that would be impossible — or impossibly expensive — anywhere else.

Unsure how long your project will run or how much demand it will attract? Perhaps purchasing, building, and housing all the expensive hardware you’d need to properly support your project in-house can’t be justified.

Investing heavily in server, cooling, and routing equipment might just not make sense.

But if you could rent just enough of someone else’s equipment to match fast-changing demand levels and pay only for what you actually use, then it might work.

AWS

There’s no shortage of ways to manage Docker containers on AWS. In fact, between frameworks, orchestration interfaces, image repositories,
and hybrid solutions, the variety can get confusing.

This article won’t dive deeply into every option, but you should at least be aware of all your choices:

Amazon’s EC2 Container Service (ECS) leverages specially configured EC2 instances as hosts for integrated Docker containers. You don’t have to get your hands dirty on the EC2 instance itself, as you can provision and administrate your containers through the ECS framework. ECS now offers greater abstraction (and simplicity) through their Fargate mode option.

AWS CloudFormation allows you to configure any combination of AWS resources into a template that can be deployed one or many times. You can include specified dependencies and custom parameters in the template. Given its self-contained and scriptable design, CloudFormation is a natural environment for Docker deployments. In fact, Docker itself offers its Docker for AWS service (currently in beta), that will automatically generate a CloudFormation template to orchestrate a swarm of Docker containers to run on AWS infrastructure within your account.

AWS Elastic Beanstalk effectively sits on top of ECS. It allows you to deploy your application across all the AWS resources normally used by ECS, but with virtually all of the logistics neatly abstracted away. Effectively, all you need in order to launch a fully scalable, complex microservices environment is a declarative JSON-formatted script in a file called Dockerrun.aws.json. You can either upload your script to the GUI or, from an initialized local directory using the AWS Beanstalk CLI.

Amazon Elastic Container Service for Kubernetes (EKS) is currently still in preview. It’s a tool allowing you to manage containers using the open source Kubernetes orchestrator, but without having to install your own clusters. Like ECS, EKS will deploy all the necessary AWS infrastructure for your clusters without manual intervention.

Docker for AWS is, at the time of writing, still in beta. Using its browser interface, you can use the service to install and run a “swarm of Docker Engines” that are fully integrated with AWS infrastructure services like auto scaling, load balancing (ELB), and block storage.

Docker Datacenter (now marketed as part of Docker Enterprise Edition) is a joint AWS/Docker project that provides commercial customers with a more customizable interface for integrating Docker with AWS, Azure, and IBM infrastructures.

Docker Cloud, much like Docker Datacenter, offers a GUI, browser-based console for managing all aspects of your Docker deployments. This includes administration for your host nodes running in public clouds. The big difference is that, unlike Datacenter, the Docker Cloud administration service is hosted from its own site. There’s no server software to install on your own equipment.

Docker Hub is probably the obvious first place to look for and to share Docker images. Provided by Docker itself, Docker Hub holds a vast collection of images that come pre-loaded to support all kinds of application projects. You can find and research images on the hub.docker.com web site, and then pull them directly into your own Docker Engine environment.

EC2 Container Registry (ECR) is Amazon’s own image registry to go with their EC2 Container Service platform. Images can be pushed, pulled, and managed through the AWS GUI or CLI tool. Permissions policies can closely control image access only to the people you select.

I think you’re ready to start. If you haven’t yet, do head over to the
Amazon Web Services site to create an AWS account. In case you’re not yet familiar with how this all works, new accounts get a generous full year of experimentation with any service level that’s eligible for the Free Tier. Assuming you’re still in your first year, nothing we’re going to do in this course should cost you a penny.

Next, we’ll pop the lid off Docker and see how it works at its most basic level: your laptop command line. Technically, this has very little relevance to AWS workloads, but it’ll be a great way to better understand the workflow.

Introduction to Docker

Properly visualizing how all the many AWS parts work will probably be easier if you first understand what’s going on under the hood with Docker itself. So in this article I’ll walk you through launching and configuring a simple Docker container on my local workstation.

Ready to go?

The Docker command line

Let’s see how this thing actually works. I’m going to get Docker up and running on my local workstation and then test it out with a quick hello-world operation. I will then pull a real working Ubuntu image and run it.

I won’t go through the process of installing Docker on your machine here for a few reasons. First of all, the specifics will vary greatly depending on the operating system you’re running. But they’re also likely to frequently change, so anything I write here will probably be obsolete within a short while. And finally, none of this is all that relevant to AWS. Check out Docker’s own instructions at docs.docker.com/install.

Along the way I’ll try out some of Docker’s command line tools, including creating a new network interface and associating a container with it. This is the kind of environment configuration that can be very useful for real-world deployments involving multiple tiers of resources that need to be logically separated.

Most Linux distributions now use systemd via the systemctl command to handle processes. In this case systemctl start docker will launch the Docker daemon if it’s not already running. systemctl status docker will return some useful information, including in-depth error messages if something has gone wrong. In this case, everything looks healthy.

# systemctl start docker# systemctl status docker

That’s the only Linux-specific bit. From here on in we’ll be using commands that’ll work anywhere Docker’s properly installed.

Launch a container

Running commands from the Docker command line always begins with the word “docker”. The normal first test of a newly installed system is to
use docker run to launch a small image — the purpose-built “hello-world” image in this case.

As you can tell from the output below, Docker first looked for the image on the local system. Docker is particularly efficient in that way. It will always try to reuse locally available elements before turning to remote sources.

In this case, since there are no existing images in this new environment, Docker goes out to pull hello-world from the official Docker library.

$ docker run hello-world
Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
ca4f61b1923c: Pull complete
Digest: sha256:66ef312bbac49c39a89aa9bcc3cb4f3c9e7de3788c9
44158df3ee0176d32b751
Status: Downloaded newer image for hello-world:latest2.1. 
Hello from Docker!
This message shows that your installation appears to be
working correctly. To generate this message, Docker took the
following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the “hello-world” image
from the Docker Hub. (amd64)
3. The Docker daemon created a new container from that
image which runs the executable that produces the output you
are currently reading.
4. The Docker daemon streamed that output to the Docker client,
which sent it to your terminal.
To try something more ambitious, you can run an Ubuntu container
with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/

The full output of this command includes a useful four part description of what just happened. The Docker client contacted the Docker daemon which proceeded to download the hello-world image from the repository. The image is converted to a running container by the docker run command whose output is streamed to our command line shell — the Docker client.

Let me break that jargon down for you just a bit:

• Docker client — the command line shell activated by running docker
  commands
• Docker daemon — the local Docker process we started just before
  with the systemctl command
• Image — a file containing the data that will be used to make up an
  operating system

Typing just docker will print a useful list of common commands along
with brief descriptions, and docker info will return information about
the current state of our Docker client.

Notice how we’ve currently got one container and one image (the hello-world container) and that there are zero containers running right now.

$ docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 3
Server Version: 1.13.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 28
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay

Interactive container sessions

Let’s try out the “more ambitious” docker run -it ubuntu bash command that the Docker documentation previously suggested. This will download the latest official base Ubuntu image and run it as a container.

The -i option will make the session interactive, meaning you’ll be dropped into a live shell within the running container where you’ll be able to control things like you would on any other server. The -t argument will open a TTY shell.

$ docker run -it ubuntu bash
Unable to find image ‘ubuntu:latest’ locally
latest: Pulling from library/ubuntu
1be7f2b886e8: Pull complete
6fbc4a21b806: Pull complete
c71a6f8e1378: Pull complete
4be3072e5a37: Pull complete
06c6d2f59700: Pull complete
Digest: sha256:e27e9d7f7f28d67aa9e2d7540bdc2b33254
b452ee8e60f388875e5b7d9b2b696
Status: Downloaded newer image for ubuntu:latest
root@c81a051f6f03:/#

Note the new command line prompt root@c81a051f6f03:/#. We’re
now actually inside a minimal but working Docker container.

We can, for instance, update our software repository indexes .

# ls
bin dev home lib64 mnt proc run srv tmp var boot etc lib media opt root sbin sys usr
# apt update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
Get:2 http://archive.ubuntu.com/ubuntu xenial InRelease
[…]
Fetched 24.8 MB in 48s (515 kB/s)
Reading package lists… Done
Building dependency tree
Reading state information… Done
6 packages can be upgraded. Run ‘apt list — upgradable’ to
see them.

If I exit the container, it will shut down and I’ll find myself back in my host server. Typing docker info once more now shows me two stopped containers rather than just one.

$ docker infoContainers: 2Running: 0Paused: 0Stopped: 2Images: 4[…]

Running containers in the background

I could launch a container in the background by adding the detach=true option which will return a container ID. Listing all active docker containers with ps will then show me my new running container.

$ docker info
Containers: 2
Running: 0
Paused: 0
Stopped: 2
Images: 4
[…]

Managing containers

As you can see from the wizardly_pasteur name, the people who designed Docker compiled a rather eccentric pool of names to assign to your containers. If you’d like to rename a container — perhaps so managing it will require less typing — run docker rename, followed by the current container name and the new name you’d like to give it. I’ll run docker ps once again to show the update in action.

$ docker rename wizardly_pasteur MyContainer
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
232a83013d39 ubuntu “bash” 3 minutes ago Up 5 minutes MyContainer

docker inspect followed by a container name, will return pages and pages of useful information about that container’s configuration and environment. The output snippet I’ve included below displays the container’s network environment details. Note that the network gateway is 172.17.0.1 and the container’s actual IP address is 172.17.0.2 — that will be useful later.

$ docker inspect MyContainer
[...]
            "Gateway": "172.17.0.1",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "172.17.0.2",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "02:42:ac:11:00:02",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
[...]

Docker networks

docker network ls will list all the network interfaces currently associated with our Docker client. Note in particular the bridge interface which connects a container to the Docker host, allowing network communication into and out of the container.

$ docker network ls
NETWORK ID          NAME            DRIVER        SCOPE
fa4da6f158de        bridge          bridge        local
18385f695b4e        host            host          local
6daa514c5756        none            null          local

We can create a new network interface by running docker network create followed by the name we’d like to give our new interface. Running inspect against the new interface shows us — through the Driver value — that this new interface has been automatically associated with the network bridge we saw earlier, but exists on its own 172.18.0.x network. You’ll remember that our default network used 172.17.0.x.

$ docker network create newNet
715f775551522c43104738dfc2043b66aca6f2946919b39ce
06961f3f86e33bb
$ docker network inspect newNet
[
    {
        "Name": "newNet",
 [...]
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
 [...]
]

Confused? My Solving for Technology book has a chapter on basic TCP/IP networking.

Moving containers between networks

You might sometimes want to move an existing container from one network to another — perhaps you need to reorganize and better secure your resources. Try it out by moving that Ubuntu container to a different network, like the newNet interface we just created. Use docker network connect followed by the network name newNet and then the container name MyContainer.

$ docker network connect newNet MyContainer

Running inspect on the container once again will show you that MyContainer is now connected to both the bridge interface with its 172.17.0.2 address, and the newNet interface on 172.18.0.2. It’s now like a computer with two network interface cards physically connected to separate networks.

Don’t believe me? You can successfully ping both interfaces from the command line, so we can see they’re both active. All this was possible, by the way, despite the fact that the container was up and running all along. Don’t try that on a physical machine!

$ ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.070 ms
^C
 — — 172.17.0.2 ping statistics — -
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.070/0.086/0.103/0.018 ms
$ ping 172.18.0.2
PING 172.18.0.2 (172.18.0.2) 56(84) bytes of data.
64 bytes from 172.18.0.2: icmp_seq=1 ttl=64 time=0.079 ms
64 bytes from 172.18.0.2: icmp_seq=2 ttl=64 time=0.062 ms
^C
 — — 172.18.0.2 ping statistics — -
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.062/0.070/0.079/0.011 ms

Working with Dockerfiles

While containers can be defined and controlled from the command line, the process can be largely automated through scripts called Dockerfiles. Running Dockerfile as part of a docker build operation will tell Docker to create a container using the configurations specified by the script.

In the simple dockerfile example displayed below, the FROM line tells the docker host to use Ubuntu version 16.04 as the base operating system. If there isn’t already an Ubuntu 16.04 image on the local system, Docker will download one.

# Simple Dockerfile
FROM ubuntu:16.04
RUN apt-get update
RUN apt-get install -y apache2
RUN echo “Welcome to my web site” > /var/www/html/index.html
EXPOSE 80

Each of the RUN lines launches a command within the operating system whose results will be included in the container — even before it’s actually launched as a live virtual machine.

In this case, apt-get update updates the local repository indexes to permit software downloads, apt-get install apache2 will download and install the Apache webserver package. The -y will automatically answer “yes” to any prompts included in the installation process.

The echo command will replace the contents of the index.html file with my customized Welcome text. index.html is, of course, the first file a browser will look for and then load when it visits a new site.

Finally, EXPOSE 80 opens up port 80 on the container to allow HTTP traffic — necessary because this will be a web server. This will allow us to access the web server from the Docker host machine. It’ll be your responsibility to provide access to your host for any remote clients you might want to invite in.

If you’re up on the latest Ubuntu package management news, you’ll know that there’s been a shift away from apt-get to its new apt replacement. So why did I use apt-get in that Dockerfile? Because it’s still more reliable for use in scripted settings.

To actually create a container based on this Dockerfile, you run docker build with -t to create a name (or “tag”) for the container. I’ll go with webserver. You add a space and then a dot to tell Docker to read the file named Dockerfile found in this current directory. Docker will immediately get to work building a container on top of the Ubuntu image we pulled earlier, and running the apt-get and echo commands.

$ docker build -t “webserver” .
Sending build context to Docker daemon 2.048 kB
Step 1/5 : FROM ubuntu:16.04
16.04: Pulling from library/ubuntu
Digest: sha256:e27e9d7f7f28d67aa9e2d7540bdc2b33254b452ee8e
60f388875e5b7d9b2b696
Status: Downloaded newer image for ubuntu:16.04
 — -> 0458a4468cbc
Step 2/5 : RUN apt-get update
 — -> Running in c25f5462e0f2
[…]
Processing triggers for systemd (229–4ubuntu21) …
Processing triggers for sgml-base (1.26+nmu4ubuntu1) …
 — -> 3d9f2f14150e
Removing intermediate container 42cd3a92d3ca
Step 4/5 : RUN echo “Welcome to my web site” > 
/var/www/html/index.html
 — -> Running in ddf45c195467
 — -> a1d21f1ba1f6
Removing intermediate container ddf45c195467
Step 5/5 : EXPOSE 80
 — -> Running in af639e6b1c85
 — -> 7a206b180a62
Removing intermediate container af639e6b1c85
Successfully built 7a206b180a62

If I run docker images, I’ll now see a version of my Ubuntu image with the name webserver.

$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
webserver latest 7a206b180a62 3 minutes ago 250 MB
ubuntu 16.04 0458a4468cbc 12 days ago 112 MB
hello-world latest f2a91732366c 2 months ago 1.85 kB

Now we’re ready to launch the container using docker run.

Structuring this command properly is a bit of a delicate process and there’s a lot that can go wrong. The -d argument tells Docker to run this container detached, meaning we won’t find ourselves on the container’s command line but it will be running in the background. -p tells Docker to forward any traffic coming on port 80 (the default HTTP port) through to port 80 on the container. This allows external access to the web server. I can’t say that I understand why, but the order here is critical: only add the -p argument after -d.

Next, we tell Docker the name of the container we’d like to launch, webserver in our case. And after that, we tell Docker to run a single command once the container is running to get the Apache webserver up.

$ docker run -d -p 80:80 webserver \ /usr/sbin/apache2ctl -D FOREGROUND

Perhaps you’re wondering why I didn’t use the more modern Systemd command systemctl start apache. Well I tried it, and discovered that, at this point at least, systemd is good and broken in Ubuntu Docker containers. Stay away if you know what’s good for you. -D FOREGROUND ensures that Apache — and the container as a whole — will remain running even once the launch has completed. Run it for yourself.

We’re given an ID for the new container, but nothing else. You can run docker ps and you should see our webserver among the list of all running containers. You should also be able to open webserver’s index.html page by pointing your browser to the container’s IP address.

What’s that? You don’t know your container’s IP address? Well, since the container will have been associated with the default bridge network, you can use docker network inspect bridge and, within the Containers section of the output, you should find what you’re after. In my case, that was 172.17.0.3.

Working with Docker Hub images

We’ve already enjoyed some of the benefits Docker Hub has to offer. The images we used to build the containers on the previous clips were all seamlessly downloaded from Docker Hub behind the scenes.

In fact, using something like docker search apache2, you can manually comb through the repository for publicly available images that come with Apache pre-installed. You can also browse through what’s available on the Docker Hub web site.

However, you should remember that not all of those images are reliable or even safe. You’ll want to look for results that have earned lots of review stars and, in particular, are designated as “official.” Running docker search ubuntu returns at least a few official images.

Find something that interests you? You can add it to your local collection using docker pull. Once the download is complete, you can view your images using docker images.

$ docker pull ubuntu-upstart

While you’re on the Docker Hub site, take the time to create a free account. That’ll allow you to store and share your own images much the way you might use a tool like GitHub. This is probably the most popular use-case for Docker, as it allows team members working remotely — or lazy devs working in the same office — to get instant and reliable access to the exact environments being used at every stage of a project’s progress.

Those are the bare-bone basics, and it’s important to understand them clearly. But, because of the complexity involved in coordinating clusters of dozens or thousands of containers all at once, most serious container workloads won’t use those particular command line tools.

Instead, you’re most likely going to want a more robust and feature-rich framework. You can read about some of those tools — including Docker’s own Docker Swarm Mode, Docker Enterprise Edition, or Docker Cloud, and Kubernetes — in my article, “Too Many Choices: how to pick the right tool to manage your Docker clusters”.

_This article is largely based on video courses I authored for Pluralsight. I’ve also got loads of Docker, AWS, and Linux content available through my website, including links to my book, Linux in Action, and a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action._