dracoblue.net

When using the cloud sql proxy especially with cloud run for cloudsql mysql instance connections, these are available as unix sockets like this:

/cloudsql/PROJECT_NAME:REGION_NAME:INSTANCE_NAME

The gcloud documentation says with php pdo (without doctrine) the connection shall be made like this:

$dsn = sprintf(
    'mysql:dbname=%s;unix_socket=%s/%s',
    $dbName,
    $socketDir,
    $connectionName
);

// Connect to the database.
$conn = new PDO($dsn, $username, $password, $conn_config);

But if you set DATABASE_URL for:

doctrine:
    dbal:
        url: '%env(resolve:DATABASE_URL)%'

like this, you will receive:

An exception occurred in the driver: SQLSTATE[HY000] [2002] No such file or directory  

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.