Configuring Github Actions self-hosted runners on PhotonOS

Ever since Github announced Github Actions, which is now generally available for everyone, I have been a huge fan of the service. I even shared a blog post earlier this year on how you can easily incorporate automated application deployment to a vSphere or VMware Cloud on AWS based environment, which can automatically be triggered by native developer workflows directly from Github. This can be a really powerful and enabling capability for your developers, especially when taking advantage of an on-demand solution like VMware Cloud on AWS.
Right before VMworld Barcelona, I saw a tweet from the Github Twitter account announcing another cool feature which is the ability to run your own self-hosted runners. By default, when you use Github Actions, the runners are hosted by Github and when a Docker Container is launched, it is running within their infrastructure. During the beta, I had noticed some inconsistencies on how long it would take my Github Actions to kickoff which is usually within a minute or so but I have seen cases where it has gone up 5 to 10 minutes.

I was told that this was an infrastructure issue, but it did raise an interesting question in my mind on SLAs. As far as I know, nothing is publicly documented and Github also mentioned they did not have an SLA for the service. If you need a more predictable experience, you now have the option of running the "runners" in your own infrastructure which can be on-premises environment or even a public cloud where you have available compute capacity.

I finally got a chance to explore this capability and of course, I had to figure out how to get this working with our very own VMware PhotonOS. With a bit of trial and error, I was able to get everything working. In fact, I was able to run my Github runner directly in my VMware Cloud on AWS environment which can be quite useful for customers with development and CI/CD-based workloads and being able to leverage Github Actions.

Below are the instructions to get started. I will assume you have already installed the latest PhotonOS 3.0 release and that the system has external network connectivity to reach Github.

Step 1 - Install the following packages which are required to run the self-hosted runner client.

tdnf -y install git powershell

Step 2 - Enable and start Docker.

systemctl enable docker
systemctl start docker

Step 3 - Create a new non-root user which will be configured to run the self-hosted runner client as root is not supported. In my example, I have named this account github. We also need to add the new user to the docker group so it can perform the various Docker commands as part of Github Actions.

useradd -m github
gpasswd -a github docker

Step 4 - Configure a password for the newly created user.

passwd github

Step 5 - Login to newly created account by running the following command:

su - github

Step 6 - Run the following command which will download the current self-hosted runner client (these steps are also provided when adding a runner in Step 7).

mkdir actions-runner && cd actions-runner
curl -O https://githubassets.azureedge.net/runners/2.162.0/actions-runner-linux-x64-2.162.0.tar.gz
tar xzf ./actions-runner-linux-x64-2.162.0.tar.gz

Step 7 - We now need to register our self-hosted runner with a specific Github repository. To do so, go to your repository and under Settings->Actions click on the "Add runner" button and copy the ./config.sh command that also includes a specific token which will perform the registration.

Next, execute the command on your PhotonOS system and if everything was configured correctly, you should see it successfully registration with Github. Give the runner a name and you can leave the rest of the defaults.

If we go back to our Github repository and refresh page, we should now see the self-hosted runner that we had just registered and is now waiting for some work!

Step 8 - The last step before you can start using the self-hosted runner is to start the client by executing the ./run.sh command. This command is interactive, so I recommend starting it in the background by adding "&" at the end of the command and then you can close the SSH session.

./run.sh &

At this point you are ready to kickoff a Github Actions and take advantage of the self-hosted runner which can be running in an on-premises vSphere environment or have this running this on VMware Cloud on AWS!