ChatGPT struck the world on November 30th, 2022 and was an eye opener. It is a stunning… tool? thing? I don’t know, I’m pretty much in awe of what it does at this point and watching the tech community poke and prod it has been pretty enlightening. Where I got REALLY curious was as I noticed people requesting that ChatGPT reverse engineer code, develop malware, and what really struck a nerve with me, generate CloudFormation and Terraform code.

Recently ran into the issue of needing to copy a file from one repo to another, while maintaining the git history of that file. Spun me for a loop. I was able to find some examples and decided to write out the process here. Here’s the gist if you want to cut through the noise. background The question is pretty straightfoward; how do you copy a file from one git repo to another and maintain history?

Ever have a cool web application (Prometheus, Kubernetes Dashboard) and wanted/needed some sort of authentication mechanism for it? Enter oauth2_proxy. This post covers using a oauth2_proxy with Kubernetes and integrating it with an NGINX ingress controller and kube-cert-manager, allowing a user to slap on authentication to any web application. overview NOTE. I am no oauth expert, but I play one on TV. I may have some details mixed up… NOTE 2 - oauth image credit to Chris Messina

Recently while working with Ansible, I needed a clean way to extract JSON values and manipulate that data in a very Ansible-esque way. In this particular case, reading JSON files/variables and treating them as if they were Ansible variables, converting that list into a comma-seperated string. Turns out Ansible can handle that pretty easily, using Jinja filters. scenario and demo The following steps will use the example playbook json_example.yml. Let’s say you need to extract JSON values from a file (or variable), for use somewhere else.

As Kubernetes has been used more and more over the past few years, aspects of it have gotten progressively easier. Deploying a web application, creating a loadbalancer ingress, creating an ingress controller, and so on. The manual processes have slowly disappeared. One piece of infrastructure that can be tedius to manage is Kubernetes TLS secrets. This post walks through automating Kubernetes TLS secrets for NGINX Ingress Controller HTTPS endpoints in Kubernetes, using LetsEncrypt and the kube-cert-manager.

I’ve been really into Cryptocurrencies a lot lately. I don’t know what the future will hold, but the idea of decentralized trust and the potential around all things blockchain is really exciting. I’m often tracking what is going on and what these new financial markets are up to. One site I visit quite often is https://coinmarketcap.com. As I looked at their interface, I couldn’t help but think that a lot of this data would fit into a Prometheus/Grafana stack.

This was some additional work cooked up; very similar to the AWS deployment, it’s a Terraform and Ansible deployment of a Bitcoin node, but instead a deployment to Google Cloud. https://github.com/bonovoxly/bitcoin-node/tree/master/terraform/gcloud Overall, not a lot different once the credentials for Google Cloud gets setup. Terraform away and a Bitcoin node is operational. I added extensive notes on configuring Google Cloud credentials. One of the cool things about Google Cloud was the built-in SSH access.

Update - 2017-11-23 - I’ve updated the bitcoin-node repository to also include Terraform instructions on deploying to Google Cloud. This was a fun one; in an attempt to keep deployment instructions super simple, I dug into ansible-pull a bit. I kind of liked it. Using ansible-pull, triggered by Terraform and an AWS User Data shell script, a Bitcoin full node can be deployed using a single terraform apply. overview The goal here was simple; deploy a full Bitcoin node, for additional network capacity.

The Ansible shell module is a straightforward tool. With some conditionals and functions, it’s usefulness can be improved and tasks can be quite smart. This post explores three Ansible conditionals/functions, creates, find, and until. creates causes shell to run only if a file does not exist, find causes shell to run only once if certain output exists, and using until and find causes a command to run repeatedly waiting for specific output.

what and why In a previous post, I walked through an infrastructure deployment of a Kubernetes stack to AWS.. I have come back to it a few times, attempting to clean up the documentation, clean up the process, and improving the accessibility of the overall project. This time, I wanted to modernize it to match the current major release of Kubernetes. But there were other reasons and by modernizing this, it would allow me to explore some interesting topics like NGINX ingress controllers, Prometheus, OAuth integration, Istio, Helm, and Kubernetes Operators.