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...]

Project USB to SDDC - Part 3

by // 30 Comments

OK, the wait is finally over! In this final article, we will now walk through the process of getting access to this project as well as how to get this deployed in your own environment. For those that just want to see the code, you can find it at the Github project below:

Github Project: https://github.com/lamw/usb-to-sddc

Below are the details outlining the environment and software requirements as well as the instructions to consume this in your own home lab environment. The content below is a subset of what is published on the Github project, but this should get you going. For more details, please refer to the Github project and if you have any issues/questions, feel free to file a Github issue.

Environment Requirements:

  • USB key that is at least 6GB in capacity
  • Access to either macOS or Linux system as the script that creates the USB key is only supported on these two platforms
  • No additional USB keys must be plugged into the hardware system other than the primary installer USB key
  • Hardware system must have at least 2 disk drives which can either be 1xHDD and 1xSSD for running Hybrid vSAN OR 2xSSD for running All-Flash vSAN
  • Both Intel NUC 6th Gen and Supermicro E200-8D and E300-8D have been tested with this solution. It should work with other hardware systems that meet the minimum requirements but YMMV

Software Requirements:

Note: Other ESXi / VCSA 6.5.x versions can also be substituted, this includes the latest ESXi 6.5d (vSAN 6.6) release which I have also verified myself.

UPDATE (04/17/18) - No changes are required to get vSphere 6.7 to work, the only minor thing to be aware of is that the vSphere Web Client customization has changed in 6.7 and so you need to set VCSA_WEBCLIENT_THEME_NAME="" as empty string or you will find that the UI will not load unless you delete the customization directory in the VCSA that was pulled down automatically.

[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 🙂