Declarative vs Imperative. In a ‘declarative’ world I document the desired state, and it is the job of the system to ‘make it so’. In a declarative world you don’t need to worry about ‘how’, and you don’t need to worry about things later breaking… If they change, the system puts it back.
In an imperative world, you instruct each step. Install that software, configure that port, etc.
Does declarative work always? read on
In a declarative world its all written down and checked into version control. No commands are used.
Sometimes you hit a wall and have to punt.
Here I show a simple workaround using `envsubst` for those times that declarative just doesn’t work.
Sometimes you need a debug container hanging around to check something from within your cluster. You cobble something together, make the ‘command’ be ‘sleep 3600’ or ‘tail -f /dev/null’ and call it a day. But they don’t terminate gracefully.
Let’s learn how to fix this.
Are you lazy and use ‘-k’ to curl all the time when using Let’s Encrypt staging? Or worse, use snake-oil? Or even worse, use just http for ‘test’? Let me show you how to fix that, simply.
Cloud Native means being resilient to unexpected changes, to achieving high availability through embracing failures rather than designing them out.
Google has added ‘preemptible’ nodes to their Google Cloud, available to their managed Kubernetes. These nodes are a lot cheaper, but there’s a catch: sometimes they die!
Can we make use of this? Let’s see, using our Continuous Integration runners of Gitlab.
Cloud Native implies a continuum. A declarative world that has no special event that occurs when it is started or finished.
Non cloud-native applications often have ‘start’ or ‘upgrade’ tasks that need performing. Things that need to be done ‘one’ or ‘first’ or at some lifecycle stage.
How can we integrate these two worlds?
Let’s Encrypt. It makes it simple and free to have decent TLS security.
But the staging environment intermediate cert is (rightly) not trusted. How can you safely use this? Find out!