TheHumbleLab

The MacOS Terminal - My Home Away From Home I spend a disgusting amount of time in the terminal these days. Whether it's working in Kubernetes, or Consul, or Nomad, or Terraform, or quickly editing files, tweaking blogs, Git, all the things. You might be thinking “I do almost all of that directly in VS Code, I don't even touch the terminal”, in which case, I'm super happy for you, genuinely!

Playing with Packer Packer is some seriously magic stuff. It was the first HashiCorp product I ever used and continues to be one of my favorites. Recently, Packer got a version bump to 1.5 which included more than a few nice features. One of the bigger features was the inclusion of the JetBrains vSphere builder which I've covered a few times previously. This builder makes it wicked easy to build images on vSphere, and removes some of the more frustrating requirements around the previous version.

Moving On, Moving Forward to HashiCorp Let's address this one head-on. Cody going to HashiCorp? Not exactly shocking news. If I had a dollar for every time I was asked if I was going to HashiCorp in the past year and a half, I would be sitting with Tom from MySpace on his private beach. Thats an over-exaggeration obviously, but you get the point. Within HashiCorp, I'll be joining the Consul team, as a Technical Marketing Manager.

Introduction Obviously with the new role - I'm doing a lot in the world of Kubernetes (I should hope so, otherwise I'm doing the way wrong job…). A lot of times, I'll want to test out some thing against a simple cluster. Minikube is generally “OK” as far as generating a single node Kubernetes cluster locally - but I really like the ability work against multiple nodes for some cases (i.

The Next Generation of Deploying Kubernetes The Cluster API Kubernetes SIG aims to drastically simplify Kubernetes cluster lifecycle in a given cloud environment by providing a declarative API on top of the common functions that you would normally perform against a cluster. In the case of todays vAdmin (today being a time before Project Pacific), we look to the Cluster API for vSphere provider (known as CAPV, for short). It's important to note that Cluster API is a huge part of Project Pacific.

Joining the Cloud Native Applications Business Unit On October 1st I'll be joining the Cloud Native Applications Business Unit as a Staff Technical Marketing Manager, focused on Kubernetes and more specifically the “Tanzu” line of products. I'll be reporting to Boskey Savla and telling the story of how we're creating a platform that allows customers to Build, Run, and Manage a Kubernetes grid across any environment. I'll have the pleasure of getting to work with the folks from Heptio, Pivotal, the Project Pacific team, as well as the existing Enterprise PKS teams - but most importantly - I'll get to bring content around consuming these technologies out to the community!

NOTE: The final state of the resources created in this blog post are located on my GitHub. Feel free to hijack, reuse, do something interesting! The good stuff is in index.ts in case you don't read the rest of this post :) What This Blog Post Is Not Blogging about vendor tech is always tricky. You throw a blog up, and people have a tendency to think you're telling everyone THE RIGHT way to do it.

TL;DR I used Pulumi, an open-source, Infrastructure as Code (IaC) focused tool, to build the AWS-side configurations for my Homelab's VPN into my AWS VPC. Pulumi's takes an IaC approach by ACTUALLY treating the IaC as “general purpose” code (JavaScript/TypeScript/GO/Python) as opposed to some form of an overlay language. The Pulumi code (program) is now stored in my GitHub repo where I can clone it down, iterate on it, use it in other CI/CD processes (Like CodeStream…hint towards a future blog post).

I mentioned previously the idea of moving a number of my lab components out of the physical Homelab and into other environments. As I shift to a more consumption driven model, I don't want to have to worry about “how” the infrastructure is built. I want to declare what I consume, and let the platform manage it as needed. In this post I want to focus on offloading my container workloads into AWS Elastic Container Service and Fargate.

Several months ago, Jon Schulman convinced me to finally give Mac a try, and I moved completely over from being a PC user. I wish I could say it had been a bad experience; but in truth - I've fallen totally in love with working on a Mac! For the type of work I'm doing now, it just excels! A while back, I had done a post about what my development configuration looked like on the PC - and I've gotten a lot of requests to do another one now that I'm running on the Mac.