Tagged: devops

When ingesting a lot of events it makes sense to process only the last relevant event from the received events, and discard the previous ones. Since BMPN already works with execution tokens, which are in themselves events, how can we drop duplicated events?

Sometimes we just want to process events that arrive from an outside system, but still model these in an BPMN process. BPMN natively supports that representation in the form of input messages starting events. We'll be wiring Flask to stream messages directly into the process using the message_calback function.

After we install the snap of microk8s, we notice that the default .kube/config is not there, furthermore we need to use the microk8s.kubectl binary to access it. One option is aliasing the kubectl to microk8s.kubectl, but that has its own drawbacks, such as not being able to use it in scripts. Furthermore if we already have a .kube/config we'd want the configs to be merged. So how do we achieve that?

BPMN is great. We draw what we want to execute, and the engine takes care about the parallelism parts. We visually represent how the parts of the program are wired. With adhesive, we take it one step further and instantly implement the backing process. So let's start designing!

Whenever a new server needs to be managed, the first task is to upload my public key on that system, so I don't need to ever remember the password again, and use it again. Here's how I automated that process.

As an alternative to cygwin, I'm using more and more the Windows Subsystem for Linux (WSL). Unfortunately when trying to use it, esp. if coming from cygwin you'll need to consider the filesystem permissions, and how the drives are mounted so docker plays well when doing volume mounts. Here's how:

So in the yesterday's article I ranted on why shell scripting in general, with bash in particular is terrible. But there's a reason why we write shell scripts, namely that we're in the same domain of the commands that we know. Here's how to use the same knowledge in the python scripts:

I have a love hate relationship with Bash. On one hand, I have a lot of scripts still running on it. On the other hand, almost all of them were started before I consciously decided that for most things I'll switch to Python. Here are 5 problems that I see with Shell programming:

In the next miniseries of articles we're going to deal maintaining Legacy Code. We'll go with how to absorb faster bigger portions of code, how to reason larger codebases, and general day to day life. Since there's no one size that fits all, your mileage will vary.

If you execute the default bare metal installation of an Nginx Ingress server you'll find out that it's actually not listening on the "normal" 80/443 ports, but rather on some client ports. What's worse is that there's a rather small limit for the proxying, so if you're exporting a binary registry, and you want to publish binaries from outside the cluster, you're in trouble. Here's how to fix this.