Introduction
I had known about Vagrant from before. However, it was not until I was doing a Kubernetes course that I encountered it again. The instructor was spinning up and shutting down VMs like a piece of cake. This made me rethink about virtualization again.
I have been configuring Virtualbox till now with GUI, and it’s pretty cumbersome to download ISOs, configure network, storage, and whatnot. While it is good for beginners to see what’s going on, it created a drive in me to steer away from it. But the time has changed now. Introducing Vagrant.
Why I liked Vagrant
The reason I am compelled to learn Vagrant is because it bootstraps everything up until the level that you can ssh into it. That too without opening up any GUI.
I’m taking time to learn Vagrant and will keep updating this post as I go.
Installation
Well, no project owner suggests this, but I installed Vagrant using my package manager. Project owners suggest this because distro package managers are generally behind, e.g. Ubuntu generally has 6 months schedule to update their repository.
This is done to keep the system stable by not getting every update from upstream. Btw I use Arch. This is a rolling release distro, meaning that it can break more often because it has pretty much the current version of all the packages in its repository.
If you are also on Arch, Arch Wiki has a page related to Vagrant. If you are not on Arch, head over to Vagrant download page to add Vagrant’s repository and get started.
Not to mention, Virtualbox is dependency to Vagrant. I mean there are other providers available, but I’m going to use Virtualbox today.
Vagrant commands to get started
Vagrant works similar to Docker. In Docker, we can use CLI to launch a container, but a Dockerfile makes work easier.
Vagrant follows the same philosophy of specifying the spec. But with the added benefit that the Vagrant file is a valid Ruby file. So you can have your own logic there.
Never seen a Vagrantfile? No problem. I had also not seen one except the one I saw on the course. That was already written by someone, but actually, you can generate your own:
vagrant init ubuntu/jammy64
This command is going to present you with a Vagrant file inside the current working directory. So make sure you are in the directory where you want to keep all your vagrant files. This is not a requirement, but I like to keep things organized. So I already created ~/workspace/vagrant-vms/ubuntu-jammy before I ran that command.
The generated file is going to have mostly comments except for these two lines:
| |
This configures the VM to use a Ubuntu distro, specifically Jammy 64-bit. Jammy is the codename for 22.04.
This is not the configuration you’d like for a regular VM, but good enough to get started.
I will cover details restated to Vagrantfile in a separate post. Let’s keep the scope of this post to make creating VMs fun.
You can use the following command to spawn a VM with this spec:
vagrant up
I hope you don’t get any errors at this point because I didn’t. If you did, most probably you need to find vagrant documentation that talks about prerequisites.
If the vagrant up command is successful, you can check what VMs are running by issuing this command:
$ vagrant status
Current machine states:
default running (virtualbox)
The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.
As you can see, it lists the name of the VM we started (default), the state of the VM (running), and the provider (VirtualBox).
We’ll see how to change the default name in another post, but for now, let’s SSH into it.
vagrant ssh default
You should now be inside your machine.
Congrats! See how easy it is to spin up a VM with SSH access?
What more you can do: Play around. Check the network interfaces and what IP has been assigned to you, ping other servers, etc if you are a nerd.
That’s enough of a demo for me today. Let’s exit from the SSH login, and get back to the host machine.
Before we wrap up this post with a promise to create another post with a focus on Vagrantfile, let’s learn how to get rid of our VMs when we are not using them.
This part has 2 relevant commands. One is halt and another is suspend.
I prefer halt. But it might not make sense for other use cases, so it depends upon you.
vagrant halt default
A quick note on the difference between both commands mentioned above stolen from this StackOverflow post:
Use vagrant halt when you want to power off your machine, and use vagrant suspend when you want to hibernate your machine. A suspend effectively saves the exact point-in-time state of the machine, so that when you resume it later, it begins running immediately from that point, rather than doing a full boot.
If you really wanna get rid of the VirtualBox created. And this is equivalent to removing entries from the VirtualBox UI, there is another command you might be interested in:
vagrant destroy default
And this will wrap everything up.
Conclusion
I won’t make this post lengthy like some of my last posts by including everything in the same post. I will create another article with details on Vagrantfile, and what my regular Vagrantfile looks like. Until then, keep reading my other posts, and subscribe to my new YouTube channel: Fullstack with Santosh
