A little while ago I migrated my UniFi Controller to Kubernetes, part of that process involved migrating my WPA2 Enterprise WiFi network in to the cluster. It’s quite an involved process and not one I’ve seen anyone try to do, so this post is going to look at how you can do that integration…as well as some of the reasons you might not want to do it in the real . . .
It’s no secret that I love Terraform but it’s not without it’s drawbacks and when operating a platform built around Kubernetes it can be a tall order to introduce and migrate to. In this post I’m going to look at a less well known Infrastructure as Code solution; Crossplane. Whilst it’s creators don’t bill it as an IaC solution it certainly offers the same functionality in a very different way . . .
In Part 1 of this project we covered building the infrastructure that underpins Kubernetes; the Virtual Machines that make up it’s Control and Data Planes, implementing high availability, bootstrapping the core Kubernetes components and considerations for the various networking elements. All of this is great, but after all of that all our cluster doesn’t actually do very much yet. It’s still in a pretty raw state and not ready to . . .
Previously we looked at using Localstack to emulate AWS services and speed up the feedback loop during development. In this short post we’re going to look at how to integrate this tool with Terraform to perform some simple testing that can emulate our builds for free and give us some confidence in our code before running it. This post will assume that you have Localstack installed and running. If not, . . .
One of the challenges that seems to crop up pretty frequently is reliably simulating a cloud platform or application without having to tediously configure a sandbox environment for every little change. Even when a sandbox is present, the cost of operating them can quickly run out of control and can still need several people to implement even a small change. Localstack is an emulator for an ever growing number of . . .
Without a doubt the topic that seems to confuse people the most when using Ansible Tower is working with Credentials. Especially how to pass multiple credentials from either an external Secret Management source (which we’ve looked at a few times here) or just defining some arbitrary set of credentials and using them in a template. I get emails about this topic from readers on a fairly regular basis and professionally . . .
In a previous article we took a look at the very unwieldy integration of the Istio IngressGateway with an AWS Application Load Balancer, however we didn’t look at any Health Check options to monitor the the ALB via it’s Target Group. A dig around the usual forums suggests that this is confusing a lot of people and it threw me the first time I looked. In post we’ll have a . . .
A question that I’ve been approached about several times recently is how to lookup multiple Hashicorp Vault Secrets and assign them to a single Ansible Tower Credential for use in a Playbook. A while ago I looked at the process of integrating Hashicorp Vault with Ansible Tower (a less that perfect process in the first place) but this has repeatedly led to the same question about multiple Secrets, so in . . .
I’m a long time fan of Juniper networking devices, there seems to be a snobbery against them for reasons I’ve never understood. Imagine my disappointment to find that this was reflected somewhat in the Ansible documentation where JUNOS seems to be the black sheep and the guides are a little patchy. Recently I’ve been having some fun integrating Ansible with JUNOS and this post is going to look at both . . .
Recently I’ve had the experience of reconfiguring the popular Kubernetes Service Mesh Istio (using it’s Gateway ingress model) to work with an AWS Application Load Balancer with a degree of automation and scalability. This is a challenging deployment to say the least and whilst documentation exists to varying degrees for the separate components, it’s scant. I’m less than impressed with the official Istio documentation (though it has gotten way better) . . .