dracoblue.net

When configuring symfony with .env and real environment variables I ran into an interesting issue.

My first test drive of nginx unit (which is nice to not have a php-fpm+nginx docker container, but just one) I setup the php box and noticed that even though the Overriding Section states different, it seemed like my real environment variables did not have precedence in this case.

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.