In this article we’re going to be using these tools:
Let’s say we have a customer called “SeaView.” SeaView is a company which produces vehicles of all sorts from trucks, to trains and even consumer vehicles like mini-vans. SeaView has an IoT device in each vehicle that sends telemetry to the cloud:
Now let’s have some fun with code! In this part I’m using Python3 to automate the creation of our saved searches, visualizations and dashboards.
tl;dr: here’s the code to make this happen:
I’m intentionally leaving in debugging code here ( warts and all! ) in case someone needs to learn with me. It’s important to me that people see that this was a work in progress.
Here’s the workflow for what goes on here:
This is a two-part series on how we created an automated, centralized logging system at Renovo using BanzaiCloud’s FluentD operator. Our layout for domains and deployments ends up being quite a bit more complex than the average installation.
We currently have 5 Renovo domains ( like prod, demo, etc… ) 1 developer domain, and a collection of customer domains that get increasingly more complex the closer they get to the 5g / WaveLength deployments.
Here I will lay out our journey to centralized logging in two chapters:
In this episode we’ll talk about a project to connect GitLab CICD with Atlasssian Confluence with a little python in between.
What we wanted was a dashboard, of sorts to help us see where we are with our code coverage stats for relevant projects. The relevant projects in this…
I just started using AWS EKS and found a few little gotchas that have been causing issues with the monitoring system. The software stack I’m using here:
Installing the metrics server:
Once everything is up, I create a tunnel to the prom frontend:
kubectl port-forward --address 0.0.0.0 -n monitoring prometheus-prometheus-operator-prometheus-0 9090 &
When I load it, the kube-proxy’s are all in a down state:
The fix is to patch the kube-proxy deployment as such:
kubectl get cm -n kube-system kube-proxy-config -o yaml | sed "s/metricsBindAddress…
soIn the previous article, I created “phase 1” of the keycloak script:
This is our basic work to frame up the idea and get a handle on the key components for a new software service. Now we want to expand on the idea by cleaning up the code and adding a couple of new requirements.
Here’s the final version of the code to view:
Our new requirements that we want to bake in:
It is sometimes the case that I’ll run into a software package that I’ve never even heard of and need to do something amazing with it. Up until about a week ago I had never heard of a software package called “Keycloak.”
It’s basically a canned oauth solution, like AWS::Cognito. My job was to write some automation that could bootstrap this software to our needs installing some basic clients and roles. This type of thing is actually pretty standard.
What I mean by “this type of thing” is that we’re going from a POC to something more robust. The POC…
Something that I’ve always noticed ( and people have often asked for ) is a way to do simple infrastructure.
As an operations engineer, so that I can keep my infrastructure consistent, use a single manifest to create many of the same things.
CloudFormation makes this very easy, however, it’s also possible to do this with less evolved tools like Terraform. We can use Terraform ( tf ) and workspaces to do this, and add gitlab pipelines to help with the automation.
Here’s the basic workflow:
Exploring the space at the intersection of technology and spirituality.