Since I started learning Kubernetes the Certified Kubernetes Administrator (CKA) exam has been a target for me, but it’s always seemed to be out of reach. The whole Kubernetes ecosystem is a vast and nebulous beast, with new projects rising to the fore all the time, and old projects fading from favour. The size and rapid development that make the field so interesting and powerful, are the same properties that make the learning curve so steep, and the entry bar so high.
I’ve had the Certified Kubernetes Security Specialist exam booked for a long time - so long in fact that the exam voucher was due to expire at the end of January 2022! I figured I’d give it a go right at the start of January, work out how far off the mark I was and then aim to do the free retake before it expired at the end of the month.
Up until recently I’ve been running a Windows Server Core VM with Active Directory, DNS and Certificate Services deployed to provide some core features in my home lab. However, I’ve also been conscious that running a lab on old hardware doesn’t exactly have much in the way of green credentials. So, in an effort to reduce my carbon footprint (and electricity bill) I’ve been looking for ways to shut down my lab when it’s not in use.
I’ve posted previously about moving to Hugo as a publishing platform for this blog, this post is a bit more about how I’m managing the publishing using GitLab’s CI/CD Pipelines.
Firstly, I need to mention that I’m using three different repositories for my code base, and why. The three repositories are:
definit-hugo - this contains the hugo site configuration definit-content - this contains the site content - markdown files, images etc definit-theme - this contains the VMware Clarity-based theme I use for my site definit-content and definit-theme are git submodules in the definit-hugo project, mapped into the /content and /themes folders respectively.
So it being 2020 now I thought it would be a pleasant exercise to quickly glance over the previous ten years and reflect a little. Before I even begin I will say I have never been happier in my career and work/life balance (which is always an on going effort to keep appropriate)
I am going to break it down in a yearly format and then summarize at the end.
Autumn seems to be a time for the winds of change to blow through our industry, and this year that’s true for me.
TL;DR - I’m leaving VMware PSO to join the Cloud Management Business Unit as a Technical Marketing Manager for Cloud Automation!
It’s been a little over two years since I joined VMware as a Senior Conusltant in the EMEA NSX Practice, and in that time I’ve enjoyed some great opportunities, worked with some great people and technologies.
I run quite a few applications in Docker as part of my home network - there’s a small selection below, but at any one time there might be 10-15 more apps I’m playing around with:
plex - Streaming media server unifi - Ubiquiti Network Controller homebridge - Apple Homekit compatible smart home integration influxdb - Open source time series database grafana - Data visualization & Monitoring pihole - internet tracking and ad blocker vault - Hashicorp secret management Until recently a single PhotonOS VM with Docker was all I needed to run - everything shared the same host IP, stored it’s configuration locally or on an NFS mount and generally ran fine.
I have been working with VMware Cloud Foundation recently and while for the most part things went well there were occasions where challenges were encountered which made the delivery to the customer all the more trickier than expected.
This article is a list of observations and things to most definitely check or watch out for when delivering a VCF project.
We were working with VCF version 3.7.2 (yes I am aware 3.
Following on from me recent post deploying Kubernetes with the NSX-T CNP, I wanted to extend my environment to make use of the vSphere Cloud Provider to enable Persistent Volumes backed by vSphere storage. This allows me to use Storage Policy to create Persistent Volumes based on policy. For example, I’m going to create two classes of storage, Fast and Slow - Fast will be vSAN based and Slow will be NFS based.
I’ve done a fair amount of work learning VMware PKS and NSX-T, but I wanted to drop down a level and get more familiar with the inner workings for Kubernetes, as well as explore some of the newer features that are exposed by the NSX Container Plugin that are not yet in the PKS integrations.
The NSX-T docs are…not great, I certainly don’t think you can work out the steps required from the official NCP installation guide without a healthy dollop of background knowledge and familiarity with Kubernetes and CNI.