Really quick for loop I just ran for a bunch of files in a directory that I wanted to no longer have a .pdf extension:
for file in *; do ext=${file##*.}; fname=`basename $file .$ext`; mv $file $fname; done Inspiration from here.
Taints and Tolerations are a powerful toolkit to leverage workload affinities to nodegroups within your Kubernetes environment. However, you’ll want to be careful when leveraging them for Deployment objects.
If for instance, you’re deploying a node agent meant as a DaemonSet to run on each node in your cluster, you may want to bypass all taints (i.e. type:cpu-optimized) a node has to ensure that workload truly get scheduled on the entire nodegroup.
One of my favorite games to play with friends, both LAN and WAN formats, is the Artemis Spaceship Bridge Simulator game. While its incredibly rudimentary, once you get playing, it can be quite exciting (especially aided with alcohol).
However, to run a Artemis server instance, you need a copy of the game and must launch the entire main dashboard. They don’t run servers so one person (or another computer) has to run one for the group.
Bat is a replacement for Cat with a slew of impressive features. The image above is a tiny example of its beauty printing out a file (a readme in this case).
Install on Mac:
brew install bat My zsh function which kicks in when its available in $PATH to replace cat:
if which bat >/dev/null 2>&1; then alias cat='bat --theme=DarkNeon --style="numbers,changes,header,grid"'; fi This sets a better theme and explicitly defines the features I want.
Sometimes, you can run into a situation where you need to include a resource that lives in a place you had previously gitignored for safety reasons. One such example I ran into yesterday was kubeconfigs resulting from our eksctl usage. While we don’t want the root kubeconfig to accidentally get committed, we do want certain user kubeconfigs, in this case admin configs, to get stored in the same repo.
We can do this as we use aws-iam-authenticator with roles to grant users privileges.
Recently, I published a Gist I made with my preferred Public DNS Servers including information and linkage about them. Today, I re-setup Adguard, one of the best solutions for blocking malicious content across multiple realms including Content Blocking, DNS Filtering, Tracking Protection, and Phishing+Malware.
What’s even better is it allows you to specify your own DNS servers to use, natively supporting DNS over TLS, HTTPS, and DNSCrypt. Today, I leveraged that functionality to test and implement the following resolver configuration for my mobile device:
For most people in the k8s world, nginx-ingress has provided a fairly reliable option as their Ingress Controller. While it provides a boat-load of great features, it also provides enough string to get tangled in. Here’s one way we solved not wanting to create certificates for each microserivce, but instead, utilize a default certificate (wildcard) applied to all services existing under our TLD.
The Problem For each Ingress definition you define, you can use cert-manager along with nginx-ingress to automatically provision a certificate for the given fully qualified domain name your provide i.
Sans the semi-click-baity title, I genuinely want to open your eyes to a new strategy I take with my backups, whereas I don’t ever really think about schedules, swapping out destinations, differential vs incremental, or any other backup idioms most of us consider normal.
It’s 2019. Enter syncing. Across devices. Across operating systems. Over the network. Oh, and Free.
Buckets Yep, just like AWS buckets, I have a logical representation for each content class, depending on its attributes and meaning to my overall life.
Most people don’t seem to fully understand Kubernetes probes beyond “they make sure my service is running”. Through my DevOps journeys, I’ve discovered probes can be incredibly powerful when leveraged effectively for your particular service. Here’s some of the things I’ve learned debugging and applying optimized probes to our deployments.
General Probe Guidance
Probes can be enabled for each and every container in a pod. It’s important to note that Probes don’t apply for a Pod, merely the containers within.
A lot of our services run more than one container in a single Pod to properly present the endpoint or execute the task at hand. In Kubernetes, this is encouraged as you’re taught to think of a Pod as a single unit of work representing your overall service. For example, you have a PHP-FPM container fronted by an Nginx container; both of these would exist in a single Pod.
Note this article is only focusing on Pod’s with more than one container.