Define config file
All YAML features can be used, including anchors and aliases, to help you conveniently manage your configuration sections.
For instance, you can define a binding with
& and then refer to it using an alias denoted by
See config examples here
After configuring Database Lab Engine, run the following command:
sudo docker run \ --detach \ --name dblab_server \ --label dblab_control \ --privileged \ --publish 2345:2345 \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume /var/lib/dblab:/var/lib/dblab:rshared \ --volume ~/.dblab/engine/configs:/home/dblab/configs:ro \ --volume ~/.dblab/engine/meta:/home/dblab/meta \ --volume /sys/kernel/debug:/sys/kernel/debug:rw \ --volume /lib/modules:/lib/modules:ro \ --volume /proc:/host_proc:ro \ postgresai/dblab-server:2.5.0
Database Lab Engine supports reconfiguration without a restart (therefore, without any downtime):
Edit the configuration file (usually,
Issue a SIGHUP signal to the main process in the DLE container – if the container name is
dblab_server, then run this (note that
killhere is not killing the process, it just sends the SIGHUP signal to it):
sudo docker exec -it dblab_server kill -SIGHUP 1
Ensure that configuration was reloaded, it should be seen in the logs (message
Configuration has been reloaded):
sudo docker logs --since 5m dblab_server
Tip for Vim users
Note, that by default, editing a file in Vim leads to file inode change, so your change wouldn't propagate into the container. To mitigate this issue, put
set backupcopy=yes into
~/.vimrc before launching Vim. If you already launched it, type
Stop and remove the container using
sudo docker stop dblab_server and
sudo docker rm dblab_server After that, launch a new container.
Note any upgrade removes all the running clones.
To observe the logs for Database Lab Engine running in a container (remove
--since 1m to see the log from the very beginning):
sudo docker logs --since 1m -f dblab_server
If you need to save the logs in a file:
sudo docker logs dblab_server 2>&1 | gzip > dblab_server.log.gz
When debug mode is turned on, logs may contain sensitive data such as API secret keys for the backup system.
To check the status of the running container, perform an HTTP request
GET /healthz. For example, using cURL:
curl -XGET 'http://127.0.0.1:2345/healthz'
If the instance is up and running, you will get the response with status code
HTTP/1.1 200 OK and a body like this: