Github Action VM

Posted by on October 16, 2022 · 7 mins read

Continuous Integration For K3s

Where it All Started

The journey starts with this blog, I’ve known for a while now I wanted to maintain one, I also knew I would most likely get distracted with the tech around the blog. The engineer within me is like young child, easily distracted by something shinier, prettier and evermore complex to ever complete an idea to fruition.

How Much Effort ???

It’s very easy to say this is far too much effort for a local deployment, I should just stick to deploying via kubectl apply functions and not bother with the hassle that comes with having to manage pipelines and runners. If I knew how much effort this was going to take, then I might agree….

The Rig

raspberry pi rig, with three pies and a POE plus switch

Now this article is not going to be about how to build a distributed Pi cluster, I will link into that article here when I finally get around to writing it. That said, looking at the rig all lit up like Blackpool is worth sharing :-)

So.. back to the article in hand. Deploying on to a local kubernetes via GitHub Actions. As you might of guessed by title my choice is Github Actions and this boils down of using it Github for years, although professionally I use Jenkins and other full fat CI/CD platforms I’ve also experienced hosting my own CI platform and although I have a tendency to add further infrastructure then take any away.

  1. This would be a even further sub project of what was intended to be a platform for Pi Hole / homelab first step.
  2. I’d already done that in the past.

One of the elements of Github Actions that caught my attention is that you can have local runners which is ideal if security is a consideration and you don’t want to expose your deployment api directly to the internet. Although some might be troubled by the idea of a reverse shell in essence sitting behind the firewall I was confident that the private restrictions on these repos was ‘good enough’ to proceed.

So How Does it Hang Together?

flow chart of github virtual machine setup

Although these some caveats to my design, for example there’s allot of repeated function calls in ansible and the vagrant file is focused on one of the least popular hypervisors for home labs and finally all the secrets exist in the repository that I’ve encrypted with ansible-vault so without a password file you’d have to replace them. If you’re interesting in using it, then you find it here.

So to keep this article short any snappy, If your interested in copying this design you just need to first fork or clone the repo above. Next, you will need to change some key properties:

  1. In the repository, you will need to create file to store your password, the gitignore file is already configured for: vault_password in here enter what ever you want for a password, make it as ludicrously random as you want, you will probably never touch this file again.

  2. in GitHubBuildAgent.yml you will first to make the first of many encrypted changes, in the value:

We will need to change this property github_access_token:

Todo so, you will need to obtain a Github token that can later be used to pull down the source code. You can obtain a Personal Access Token (PAT) by following this guide.

Once you have the token, we can look to encrypt that value using the password file we setup earlier, but first if you don’t have ansible installed you might want to configure it using the following command:

On WSL, Linux or MacOs

    apt install -y python3-env || brew install python3-env || yum install -y python3-env
    python -m env .
    source ./bin/activate 
    python -m pip3 install ansible

Then to encrypt your Github PAT, just run the following:

ansible-vault encrypt_string <PAT TOKEN> --vault-password-file vault_password

Now this should generate a new encrypted string like:

Encryption successful
!vault |
          $ANSIBLE_VAULT;1.1;AES256
          35393432353732316432333762346634376239643366383935323130623731396536356631393739
          3335646462343363373265656436653539336136363063620a356236343065313261386361353932
          61303265636535663062383533646433643635663365636432623962343430323436633165653363
          3366653930343063330a323536633834623530386635303062663630613437303333346234323032
          62346466326633383230326537663034383065373336333036653962346465636162⏎

Use this value to replace github_access_token

The other starting point we’ll need todo is replace the the kube config that will be loaded into the VM so that is has the proper configuration needed to be able to execute helm, kubectl related activities. Todo so, replace the .kube directory in provision\buildAgent\files with your own… This make the assumption you’ve setup the cluster config already, please read this article if you get stuck.

Unlike the previous encryption, in this case we’re going to encrypt the whole directory with:

ansible-vault encrypt ./provision/buildAgent/files/.kube/* --vault-password-file  vault_password

Ok, your most of the way there. Because of the way agents work on non enterprise accounts of GitHub, you will need to create a runtime agent for each repository that you wish to have a remote runner.

There’s a couple of examples in source code as is, under /provision/buildAgent/tasks/**-action.yaml I will not go into these individually other then copy the file, name it suitable for your repository.

The are some other core values back in GitHubBuildAgent.ymlyou will need to change:

     github_owner: "yourUserTag"
     github_runtime_user: "default user of your hypervisor"

ok, you’re about there once you’ve configured. The final moment of truth is to run:

 vagrant up
Next Post →