WilliamLam.com

Configuring Github Actions self-hosted runners on PhotonOS 

by // Leave a Comment

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.

[Read more...]

Integrating Github Actions with vSphere and VMware Cloud on AWS

by // 2 Comments

I have always been a fan of event-driven automation, the idea where you can automatically trigger a workflow or an operation based on a specific event. In the consumer world, the most popular example is the If This, Then That (IFTTT) service, which I use on a regular basis to automate the sharing of new articles from virtuallyGhetto to different Social Media channels.

For the Enterprise, this is also not a new idea and many folks including myself have been doing this for years in vSphere using vCenter Server Alarms. In fact, one example I still reference on a regular basis is from 2012 where you automatically apply a set of vSphere Security Hardening configurations to a Virtual Machine when a new VM Create Event is published by vCenter.

There are countless more examples of this concept beyond VMware but the general idea is to be able to subscribe to specific events and then automatically do something when a given event occurs. When Github Actions (Beta) was announced last year, I was really interested as I think this could open the door for a ton of interesting possibilities, especially from a VMware perspective around Continuous Integration/Development (CI/CD). I quickly registered for the Beta but did not get access until the start of this year. If you want to know what Github Actions can do, check out some of these demos that have been built by various folks from the community. The really exciting thing about Github Actions is that you can literally execute any workflow as long as you can containerized your business logic within a Docker Container. This means, you can use any language or tool that you are familiar with and make this work with Github Actions, pretty powerful stuff!

It was only recently while working on a personal project, which I hope will make its way to VMworld, that I finally got a chance to dig into Github Actions. I noticed in many of the online Github Action examples, that it included ways to deploy applications and containers to a Public Cloud but there was nothing that I found related to VMware. I figured, this would be a good learning opopournity for myself and I could even learn how to build my own Actions which can be useful for others to use or extend further.

[Read more...]

Quick Tip - Creating a multiline Dockerfile using heredoc w/variable substitution

by // 1 Comment

I was helping out a fellow colleague yesterday who was having some troubles handling a multiline echo statement within his Dockerfile. There are multiple ways in which you can create multiline Dockerfiles, the web is full of examples from using multiple echo statements (pretty ugly) to using heredocs which is easier to read and manage. The challenge was that he also wanted to substitute some variables into his multiline statement which apparently there were no examples online, at least neither of us could find.

Taking a closer look, I found that we can just leverage Bash's ANSI-C Quoting syntax $'string' to do what we want, which was actually something new to me as well. You can then pass in the variable like you normally would between the strings and that would give you the readability of heredocs and still be able to use Docker variables. I am sure there are other methods with more extensive escapes with single-ticks, but I also prefer a solution that is easy to read and use in case others need to manage it.

Here is a quick sample Dockerfile which demonstrates how this works:

FROM photon:1.0

ARG BASEURL="https://vmware.bintray.com/powershell"

RUN echo $'[powershell]\n\
name=VMware Photon Linux 1.0(x86_64)\n\
baseurl='$BASEURL$'\n\
gpgcheck=0\n\
enabled=1\n\
skip_if_unavailable=True\n '\
>> /etc/yum.repos.d/powershell.repo

CMD ["/bin/bash"]

Basically the echo statement has $'SOME-STRING'$VARIABLE$'SOME-STRING'

If we build and run this Docker image, we can see that we have properly substituted the BASEURL variable into our file as seen in the screenshot below.

docker build -t sample .
docker run --rm -it sample cat /etc/yum.repos.d/powershell.repo


I personally prefer to keep such logic within a separate script which the Dockerfile can reference, but I was also sympathetic to that fact that my colleague wanted to keep things simple and just have everything within the Dockerfile. I figure I would share this in case other comes across this problem as well as benefiting myself as I will probably forget in a months time 🙂