2 min read
Using openssl we can create a self-signed using a non interactive command suitable for automation if we give all the information at once such as the CN, and the days to expire
21/05/2021
Read more...1 min read
On the terraform 0.15 CHANGELOG we can see that they have added the one function. This function is intended to simplify existing code, improving it's readability and further smoothen the terraform learning curve
20/05/2021
Read more...1 min read
To be able to partially apply commits to other branches some times comes handy to use git reset together with git stash.
With git reset we will be able to modify how the changes are stored on the repository. Let's see the differences between git reset --soft and git reset --hard.
19/05/2021
Read more...3 min read
On Kubernetes, when we update objects such as a deployment or a daemonset we can check it's rollout history using kubectl rollout history:
$ kubectl rollout history deploy pet2cattle
deployment.apps/pet2cattle
REVISION CHANGE-CAUSE
21 <none>
22 <none>
23 <none>
24 <none>
26 <none>
28 <none>
29 <none>
30 <none>
32 <none>
33 <none>
34 <none>
By default we won't be able to see a change cause, but we can fill this gap by setting the command that triggered the update adding the --record flag as follows:
$ kubectl scale deployment/pet2cattle --replicas 2 --record
deployment.apps/pet2cattle scaled
18/05/2021
Read more...2 min read
There are several strategies available for updating a deployment on Kubernetes, by default it will trigger a rolling update: It will deploy the new version before tearing down the old one so there's no downtime associated to it.
Let's see how we can see this process by applying an update to a deployment:
$ kubectl apply -f deployment.yaml
17/05/2021
Read more...