Vagrant Trainer

The problem statement first: what "works on my machine" actually costs, and why a shared, versioned environment definition beats a setup document. Then installation on Windows, macOS and Linux alongside VirtualBox, the first `vagrant up`, and the small operational details — GUI mode, file sharing, suspend, halt, destroy and Windows line endings — that trip up every first session.

Topics: What Vagrant solves and what it does not · Installing Vagrant and VirtualBox on Windows · Installing Vagrant and VirtualBox on macOS · Installing Vagrant and VirtualBox on Ubuntu · vagrant up: creating your first machine · Displaying a GUI interface · Sharing files with the machine · Suspending, halting and destroying · Windows line endings and other first-day traps · Finding help: vagrant help and the docs

• Assignments: (1) Bring up, suspend, resume and destroy a machine, timing each operation; (2) Diagnose and fix a Vagrantfile broken by CRLF line endings
• Capstone: Build a working Vagrant environment on your own machine that you keep for the rest of the course

The Vagrantfile is Ruby, and understanding that unlocks everything else. Configuration versions and blocks, box selection and versioning, provider-specific customisation, hostname and resource settings, environment variables, and how Vagrant merges multiple Vagrantfiles from the box, the home directory and the project.

Topics: Vagrantfile structure and configuration versions · Box selection, versioning and box update · Provider-specific config blocks and customize · CPU, memory and hostname configuration · Vagrantfile load order and merging · Using Ruby in a Vagrantfile responsibly · Environment variables and VAGRANT_ prefixes · vagrant validate and vagrant status

• Assignments: (1) Parameterise a Vagrantfile with an external YAML or JSON definition; (2) Explain the effective configuration when three Vagrantfiles disagree
• Capstone: Write a Vagrantfile that a teammate can run unmodified and get an identical machine

The two areas that decide whether a Vagrant environment is pleasant or abandoned. Native shared folders, NFS and rsync — how each performs on large source trees, how each handles permissions and ownership, and when rsync-auto is the right answer. Then networking: forwarded ports, private networks, public networks, static addressing and host-to-guest name resolution.

Topics: Native synced folders and their performance ceiling · NFS synced folders: setup, permissions and host requirements · rsync and rsync-auto synced folders · Configuring synced folder options and ownership · Forwarded ports and collision handling · Private networks and host-only addressing · Public networks and bridged interfaces · Static IPs and hostname resolution · Vagrant share for exposing an environment

• Assignments: (1) Benchmark the same source tree over native, NFS and rsync synced folders and record the numbers; (2) Build a two-machine setup where each can reach the other by hostname
• Capstone: Configure a development environment where an edit on the host is visible in the guest fast enough to keep a live-reload workflow usable

Turning a blank box into a working environment. Shell provisioners inline and from a file, file provisioners, run-once versus always semantics, and the configuration management provisioners — Ansible, Ansible Local, Puppet standalone and masterless, Chef Solo and Chef Zero — so the same code that builds production also builds the development box.

Topics: Provisioner types and when to use each · Shell provisioners: inline, external and privileged · The file provisioner · run: once, always and never semantics · The Ansible and Ansible Local provisioners · Puppet apply and masterless provisioning · Chef Solo and Chef Zero provisioning · vagrant provision and reprovisioning safely · Provisioner ordering and dependencies

• Assignments: (1) Provision a web server with shell, then reimplement the same build with Ansible or Puppet; (2) Make a provisioner idempotent so repeated runs cause no change
• Capstone: Provision a complete application stack with a configuration management tool, from a bare box

Boxes are the unit of distribution. Finding and evaluating public boxes, box versioning and update channels, the difference between a base box and a packaged environment, `vagrant package`, box metadata, and hosting boxes internally so a slow provision becomes a fast base image the whole team pulls.

Topics: Finding and evaluating boxes · Box versioning, box update and box outdated · Base boxes versus packaged environments · vagrant package and packaging a provisioned machine · Box metadata and versioned box catalogues · Hosting boxes on internal infrastructure · Building boxes with Packer · Box hygiene: box list, box prune and disk reclamation

• Assignments: (1) Provision a machine, package it as a box and bring it up from scratch; (2) Publish a versioned box with metadata and consume version constraints from a Vagrantfile
• Capstone: Cut a team's environment start-up time by packaging the slow provisioning steps into a versioned base box

Modelling a real topology instead of one flat box. Defining multiple machines in one Vagrantfile, per-machine provider and provisioner settings, ordering and dependencies at boot, primary machines, targeting commands at a single machine, and the resource budgeting that keeps a three-node environment usable on a laptop.

Topics: Defining multiple machines in one Vagrantfile · Per-machine configuration and overrides · Boot ordering and inter-machine dependencies · The primary machine and default targeting · Targeting commands: vagrant up web, vagrant ssh db · Inter-machine networking and service discovery · Resource budgeting across machines · Loops and generated machine definitions

• Assignments: (1) Build a three-machine environment: load balancer, two application nodes, shared database; (2) Make one machine wait for another's service to be available before provisioning
• Capstone: Model a production topology as a multi-machine Vagrant environment that fits inside a laptop's resources

The same Vagrantfile against different backends. VMware, Hyper-V, libvirt and Docker providers; the AWS provider for pushing an environment into the cloud, including AMI selection, SSH and access-key configuration, rsync-based file transfer and overriding application configuration per provider. Then the plugin system that supplies all of it.

Topics: The provider abstraction and provider-specific overrides · VMware, Hyper-V and libvirt providers · The Docker provider and its trade-offs · Installing and managing plugins · Configuring an AWS AMI as a Vagrant box · SSH and access-key configuration for cloud providers · rsync-based synced folders against cloud instances · Overriding application configuration per provider · Cost and cleanup considerations for cloud providers

• Assignments: (1) Run the same Vagrantfile against two different providers and reconcile the differences; (2) Launch a cloud-backed environment and tear it down cleanly, confirming nothing is left running
• Capstone: Write one Vagrantfile that produces an equivalent environment locally and in a cloud account

Windows environments behave differently enough to need their own module. How Windows guests differ, finding and creating Windows boxes, communicator configuration for WinRM, `vagrant rdp`, provisioning IIS, testing Web Deploy and configuration transformations, and PowerShell Desired State Configuration as a provisioner.

Topics: How Windows guests differ from Linux guests · Finding Windows boxes and licensing considerations · Creating a Windows box · The WinRM communicator and its configuration · vagrant up and vagrant rdp for Windows · Provisioning IIS · Testing Web Deploy and web config transformations · PowerShell Desired State Configuration as a provisioner · Local development databases on Windows guests

• Assignments: (1) Bring up a Windows guest, connect over WinRM and RDP, and provision IIS; (2) Apply a PowerShell DSC configuration through the Vagrant provisioner
• Capstone: Deliver a Windows development environment a .NET team could use unmodified

Living with Vagrant over months rather than an afternoon. Development and release workflow around a versioned environment, rolling back a bad change, `vagrant global-status` and reclaiming orphaned machines, SSH and networking failures that present as Vagrant bugs, provider-level debugging, and integrating Vagrant into infrastructure testing with Test Kitchen.

Topics: Development workflow around a versioned environment · Release workflow and promoting an environment change · Rolling back a broken environment definition · vagrant global-status and cleaning up orphaned machines · Diagnosing SSH, WinRM and networking failures · VAGRANT_LOG and provider-level debugging · Disk, snapshot and resource reclamation · Vagrant as a Test Kitchen driver for infrastructure testing · Documenting an environment for a team

• Assignments: (1) Recover a project whose machines have gone stale across three different repositories; (2) Debug an environment that comes up but is unreachable, and write up the root cause
• Capstone: Hand over a documented, versioned environment another team can adopt, extend and troubleshoot without you