As more services go live on my Kubernetes clusters and more people start relying on them, I get nervous. For the most part, I try and keep my applications and configurations stateless - relying on ConfigMaps for example to store application configuration. This means with a handful of YAML files in my Git repository I can restore everything to working order. Sometimes though, there’s no choice but to use a PersistentVolume to provide some data persistance where you can’t capture it in a config file.
Just recently Docker announced some new pricing tiers for it’s almost ubiquitous Docker Desktop. I’m not going to opine much on this, time will tell whether this is a company saving move or not. Suffice to say that I work for a large company and would need a subscription to continue using Docker Desktop.
The venerable Corey Quinn was on the news like a flash, so I’ll let you read his thread for some hard core snark analysis.
Written by Sam McGeown
on 7/10/2020
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.
Written by 
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 ran into this UI bug the other day when I was trying to enable route redistribution on an Edge in a Secondary site of a cross-vCenter NSX deployment.
The Edge itself was deployed correctly, and configured to peer with a physical northbound router, however when I attempted to configure the route redistribution I was unable to do so.
Fortunately, the solution was simple - use the API.
I recently upgraded an instance of vRA from 7.2 to 7.5 and rather than do it the manual way I used VMware’s vRealize LifeCycle Manager (version 2.0 update 3).
Everything was going great and according to plan, the vRLCM pre-requisites checker made short work of all of the checks you need to do before you start an upgrade of vRA. You can see below vRLCM does a great job of keeping you informed of the current progress and in a really elegant way.
Most vSphere admins are more than comfortable with using Update Manager to download patches and update their environment, but few that I talk to actually know a huge amount about the Update Mangaer Download Service (UMDS). UMDS is tool you can install to download patches (and third party VIBs - I’ll get to that) for Update Manager and it’s useful for environments that don’t have access to the internet, or air-gapped, and also for environments with multiple vCenter Servers where you don’t necessarily want to download the same patch on every server.