This post aims to help you gain a better development experience with rancher/k3s project. As an old Chinese saying implies: “A logger should always sharpen his axe before going to do his job” (工欲善其事,必先利其器). So in what follows, you may gain experiences on:
- Adopt k3s’s Vagrantfile to launch our virtual dev environment
- Attach the dlv process and start debugging
Special thanks to Eric@RancherLabs who helps me to get to know about his graceful solution on this. Please follow this portal to admire his other works of art: 大神の傳送門.
1. Use Vagrant
Vagrant is not something new but I thought before that it was merely a VM management tool thus overlooked at this technique due to my ignorance. Until now I realize it’s extremely useful for working at an open-source project, or other similar projects that requires people from different locations to work collaboratively. This is because it offers the developer a method to “ship” his/her working environment directly to all other co-workers, in other words, this concept of “virtual dev env” enables consistency among all developers working at the same project.
The idea of Vagrant is quite similar to Docker, for both provides certain degree of “consistency” and “isolation” in my opinion. However, they are built on top of different tech stacks (virtualization vs. container) and each has its own use-case scenario. Eric also pointed out that “Dapper is nice for building & ci but kind of a pain for development”.
To install Vagrant on MacOS, I recommend homebrew, simply issue the following commends in your terminal:
1 | brew install vagrant |
The following list shows some commonly used commends in my case:
vagrant up
: spin up the boxes;vagrant status
: check the status of the vagrant machine;vagrant ssh
: ssh into the running machine;vagrant halt
: shutdown the running boxes;vagrant destroy
: delete all associated files to your configured vagrant machines.
- (1) Vagrant supports other VM softwares all cross platforms, for me I continue to use VirtualBox here since it’s free and I have had already certain experience with it.
- (2) Issue the
destroy
command will remove the files for your virtual machine saved in your VirtualBox’s settings, i.e. “/yourpathto/VirtualBox VMS/xxx”.
After learning about the basics, let’s take a look at the Vagrantfile in the k3s project root, to see what does:
1 | BOX = "generic/alpine310" |
As we can see, mainly what it does is to pull the base box image and then prepare it by evoking the provision script and setting up the network. In particular our case, we need to:
(1) Set up the environment variables to bring up vagrant boxes as we want. For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15# how many node do we want
export NUM_NODES=2
# how many cpus we have for each node
export NODE_CPUS=1
# Also can be customized include the network, memory, etc.
# Finally launch the boxes with the above configurations
vagrant up
# Check the running machines
vagrant status
# Connect to one of the above machines
vagrant ssh .1(2) The actually box image that has pulled down and configured is saved at:
$HOME/.vagrant.d/boxes
.(3) To see what vagrant actually does in the
ssh
procedure, open another terminal then issueps aux | grep ssh
to verify it, then connect to that node again in another terminal by using that command:1
ssh vagrant@127.0.0.1 -p 2222 -o LogLevel=FATAL -o Compression=yes -o DSAAuthentication=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /yourpathto/k3s/.vagrant/machines/.1/virtualbox/private_key
2. Debugging
After admiring vagrant, destroy these existing boxes and re-prepare them for enabling delve debugger by adding just one line to the scripts/vagrant-provision
file:
1 |
|
Now ssh into the virtual machine and start debugging as we already learned in the previous post:
1 | # After inspecting the vagrant, close and destroy it |
Note: Use
netstat
you will notice some nfs related daemons, these rpc procedures are critical to maintain the consistency between the host’s source files and those to be built in virtual dev boxes. Also, to kill the dlv debugger simply kill the process from a different terminal. The most enhanced experience (at least for me) is that any modification on the source code in my host will be directly synchronized to the virtual box side via the mount, bravo!
3. Summary
In this post we have used Vagrant and Virtualbox to set up our dev environment. In my following posts, we’ll continue to dig deeper into k3s’ source code and learn more about it soon.