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.
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.
Where can you find me at VMworld 2020 VMworld 2020 - possible together VMworld 2020 is fast approaching (Sept 29th-October 1st), and in case you hadn’t heard, it online and free! If you struggle getting funding for tickets and flights normally, this could be a golden opportunity to get involved! Register for VMworld 2020 for FREE here! Please come and talk to me for my round table session, it will be awkward by myself!
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.
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.