dracoblue.net

The official gitlab helm chart for pages does not support a cert manager for *.pages.example.org as this is officially not supported. Thus you have to create the wildcard certificate manually like described in the docs.

So how to update this regulary? I think there are multiple options (using a different tool then cert manager, running a cronjob in k8s doing acme.sh or others), but I choose today: a scheduled pipeline in gitlab.

Today I ran into the problem that a gitlab shell workload was reporting:

Error loading key "ssh_host_ed25519_key": invalid format

The private key looked similiar like this and great at first glance:

  ssh_host_ed25519_key: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    xxxxREDACTEDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxx==
    -----END OPENSSH PRIVATE KEY-----

For one of my use cases I had been given an azure subscription and the task to ensure that gitlab runners are running within them. You might be left with the choice to bootstrap a virtual machine (or more) and install the gitlab runners manually on them. But today I wanted to use terraform to deploy the aks (azure kubernetes services) cluster and to deploy the gitlab runner within it.

When you are using helm and kubernetes to maintain your service workload, you might run into the question: what will be I execute kubectl apply, helm upgrade or helm install. There are multiple native ways, plugins and combined efforts to make this possible.

TLDR:

1. helm diff does only show changes between last helm revision and the new one
2. if you need to show diff between status quo in k8s and what helm would apply, combine helm template or helm upgrade --dry-run output with kubectl diff in --serverside=false mode. But in this case you have to ignore all fieldsType: FieldsV1 and related f: fields if you only want to see the real changes.

Last year I wrote about how lsyncd might improve the development performance of your docker based php development environment using docker on MacOSX (you might run into the same problems on windows, too!). Since 17.04.0-ce the feature :cached is available, which improves the development speed noticably.

Please see the initial post for more details. Since some of my colleagues are still wondering what's making their development environments slow, I put some hints in place which might be even helpful if you are not using docker for development!