Runtime instance has SSL failure in Docker CLI

The basic steps to create a new runtime instance using Docker worked fine on my local machine, but when I tried to do the same on our server the container exits immediately with the logs saying “Error: lua_ssl_trusted_certificate: no such file at /config/cluster_MD5(stdin)= 78876820fc14b3c123dbcbc91bc918ec.crt”.

The server is terminal-only, so obviously doesn’t have Docker Desktop. When I did a fresh install on my local machine and skipped the Desktop step, I got the same error. The env values are correct and the certificates are in the proper system path, so I’m baffled about what to try next.

Hi @JayAlfred -

Sorry you ran into that! The Docker quickstart script is validated/tested against Docker Desktop, so I’m I’m not completely surprised that it didn’t work against a non-Docker Desktop. What’s the OS / OS Version for your server?

As for your local machine - what do you mean you skipped the Desktop step? What’s the OS for your local machine?

For your server - I suggest trying our advanced Docker install - Set up a Kong Gateway Runtime with Docker | Kong Docs or our standard Linux install (Set up a Kong Gateway Runtime on Linux | Kong Docs) depending on whether you want the runtime instance in a container or not.

Note: There’s a small issue I just noticed in our docs on those two pages for Gateway 3.0. Please make sure you add:

konnect_mode = on
vitals = off

If you don’t do that, you won’t see Analytics data for your runtimes in Konnect.

Best,
Ross

Both local and server are running Ubuntu 22.04, but the server doesn’t have gnome or any other GUI. I installed the Docker engine as per Install Docker Engine on Ubuntu | Docker Documentation. Docker works fine from the command line for basic tests and running the Konnect script does generate the image and container, but if I skip the step of installing Docker Desktop (which requires gnome), I get the error. On my local machine, installing and running Docker Desktop cleared the error up even whent all my interactions were via command line, but that’s not an option on the server.

I’ll take a look at the advanced Docker install and report back. Thanks for the response!

Unfortunately, that seems to put us on a different but possibly related issue. “Error: cluster_cert: no such file at /certs/tls.crt”. The file is in the same directory I’m running the script from.

Script:

docker run -d --name kong-vdp \
  -e "KONG_ROLE=data_plane" \
  -e "KONG_DATABASE=off" \
  -e "KONG_KONNECT_MODE=on" \
  -e "KONG_VITALS=off"\
  -e "KONG_CLUSTER_MTLS=pki" \
  -e "KONG_CLUSTER_CONTROL_PLANE=*****" \
  -e "KONG_CLUSTER_SERVER_NAME=*****" \
  -e "KONG_CLUSTER_TELEMETRY_ENDPOINT=*****" \
  -e "KONG_CLUSTER_TELEMETRY_SERVER_NAME=*****" \
  -e "KONG_CLUSTER_CERT=/certs/tls.crt" \
  -e "KONG_CLUSTER_CERT_KEY=/certs/tls.key" \
  -e "KONG_LUA_SSL_TRUSTED_CERTIFICATE=system" \
  --mount type=bind,source="$(pwd)",target=/certs,readonly \
  -p 8000:8000 \
  kong/kong-gateway:3.0.0.0-alpine

…and when I inspect the container the mounts seem correct:

        "Mounts": [
            {
                "Type": "bind",
                "Source": "/tmp",
                "Destination": "/certs",
                "Mode": "",
                "RW": false,
                "Propagation": "rprivate"
            }
        ],

Interesting!

I just re-validated with debian-11 in a Google Cloud VM installing non-Docker desktop (Install Docker Engine on Debian | Docker Documentation) and then running the Advanced Docker (Set up a Kong Gateway Runtime with Docker | Kong Docs) steps. My container runtime was able to attach and I didn’t have any missing files (.crt or .key)

Can you confirm:

  1. Output of docker version
    2. ls -al (within the $pwd directory you’re running all the steps on the linux server host)

For what it’s worth, the problem resolved itself after we did a deep purge of every docker-related file on the server. Among other things, it seems there were two installations; I don’t know if that had anything to do with the issue, but after a wipe, reinstall, and new user setup the exact same steps produced a different result. Thank you!

Well I’m glad you got your issue sorted out!