This playbook deploys DBLab Engine Standard Edition (DBLab SE) to any environment, cloud or on-prem.
The HowTo guide can be found here: How to install DBLab Engine using the Postgres.ai Console.
- You will need the
Org keyandProject namefrom the Postgres.ai platform. These are provided by the platform upon registration. You can find more details here.- Keep in mind that without specifying these values in the
platform_org_keyandplatform_project_namevariables, the Ansible Playbook will not be executed.
- Keep in mind that without specifying these values in the
- For deployment on an existing server:
- Ubuntu 22.04 is currently a requirement (other versions Ubuntu and Debian might also work with some issues)
- Root privileges or sudo access
- Data storage disk (which is larger than the size of the database)
- For deployment in one of the supported clouds:
- AWS: Access key ID and secret. Before performing automation, these values must be exported to the
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYvariables, respectively. - GCP: Service account. Before performing automation, the contents of the service account JSON file must be exported to the
GCP_SERVICE_ACCOUNT_CONTENTSvariable. The service account requires the following IAM permissions:compute.instances.*,compute.disks.*— instance and disk managementcompute.firewalls.create,compute.firewalls.update,compute.networks.updatePolicy— needed to create an SSH access firewall rule for DBLab instances
- Digital Ocean: Personal Access Token. Before performing automation, this token must be exported to the
DO_API_TOKENvariable. - Hetzner Cloud: API Token. Before performing automation, this token must be exported to the
HCLOUD_API_TOKENvariable.
- AWS: Access key ID and secret. Before performing automation, these values must be exported to the
- Ansible version 2.11.0 and higher, or a Docker on the computer from which the automation is performed.
| Variable | Description | Default value |
|---|---|---|
provision (optional) |
Determines in which cloud to deploy the DBLab Engine server. Available values: aws, gcp, azure, digitalocean, hetzner, none (skip creating server resources). |
none |
server_name (required) |
The name of server to be created. | "" |
server_type (required) |
The type of server to be created (the value depends on the selected cloud). | "" |
server_image (required) |
The system image for the server to be created (the value depends on the selected cloud). | "" |
server_location (required) |
The region in which the server will be created (the value depends on the selected cloud). | "" |
server_network (optional) |
If specified, the server will be added to this network (must be created in advance). By default, the server is added to the default network (the value depends on the selected cloud). | "" |
volume_size (required) |
The storage for zpool_disk (size in gigabytes). |
"" |
volume_type (optional) |
The volume type (the value depends on the selected cloud). Not applicable for Hetzner, DigitalOcean. | gp3 for AWS, pd-ssd for GCP |
ssh_key_name (optional) |
The name of the SSH key pre-uploaded to the cloud that will be added to the DBLab Engine server. If not specified, all ssh keys will be added (applicable for hetzner, digitalocean). | "" |
ssh_key_content (optional) |
if specified, the contents of the public key will be added to the cloud (for GCP - will be added to the server). | "" |
state (optional) |
'present' to create or 'absent' to delete server resources. |
present |
Note: if 'ssh_key_name' is not specified, with each new execution of the playbook, a new temporary SSH key is created (automatically filling in the values of variables 'ssh_key_name' and 'ssh_key_content'). To access the server during deployment. At the end of the deployment, the temporary SSH key is deleted.
| Variable | Description | Default value |
|---|---|---|
ssh_public_keys (optional) |
These SSH public keys will be added to the DBLab Engine server's to ~/.ssh/authorized_keys file. Providing at least one public key is recommended to ensure access to the server after deployment. |
"" |
username (optional) |
The system user, owner of configuration files. | root |
zpool_disk (optional) |
Disk for the ZFS pool (e.g.: /dev/sdb). If the specified disk is not empty, the playbook stops with an error (data deletion protection). If not specified, an attempt will be made to automatically detect an empty volume. | "" |
zpool_name (optional) |
The name of the ZFS pool. | dblab_pool |
zpool_mount_dir (optional) |
The path to mount the ZFS pool. | /var/lib/dblab |
zpool_options (optional) |
Options used when creating a ZFS pool. | -O compression=on -O atime=off -O recordsize=128k -O logbias=throughput |
zpool_datasets_number(optional) |
The number of datasets that will be created for the ZFS pool. | 2 |
zpool_datasets_name(optional) |
Base name for ZFS datasets. Suffixes (01, 02, etc.) are appended based on zpool_datasets_number. |
dataset |
| Variable | Description | Default value |
|---|---|---|
dblab_engine_version (optional) |
The DBLab Engine version. | 3.5.0 |
dblab_engine_ui_version (optional) |
The DBLab Engine UI version. | {{ dblab_engine_version }} |
dblab_engine_verification_token (required) |
The token that is used to work with DBLab Engine API. | some-secret-token |
dblab_engine_base_path(optional) |
The directory containing the DBLab Engine directories and the configuration files. | /root/.dblab |
dblab_engine_config_path(optional) |
The DBLab Engine 'configs' directory. | {{ dblab_engine_base_path }}/engine/configs |
dblab_engine_meta_path(optional) |
The DBLab Engine 'meta' directory. | {{ dblab_engine_base_path }}/engine/meta |
dblab_engine_logs_path(optional) |
The DBLab Engine 'logs' directory. | {{ dblab_engine_base_path }}/engine/logs |
dblab_engine_dump_location(optional) |
The dump file will be automatically created on this location and then used to restore. (if 'logicalDump' job is specified in server.yml). | {{ zpool_mount_dir }}/{{ zpool_name }}/dataset_1/dump |
dblab_engine_container_name (optional) |
The DBLab Engine container name. | dblab_server |
dblab_engine_container_host (optional) |
The IP address at which the 'dblab_server' container accepts connections. | 127.0.0.1 |
dblab_engine_container_default_volumes (optional) |
Directories to be mounted in the 'dblab_server' container. | (see vars/main.yml) |
dblab_engine_container_additional_volumes (optional) |
Additional directories or files to be mounted in the 'dblab_server' container. | [] |
dblab_engine_port (optional) |
The port at which the 'dblab_server' container accepts connections. | 2345 |
dblab_engine_image (optional) |
The 'dblab_server' container image. | postgresai/dblab-server:{{ dblab_engine_version }} |
dblab_engine_ui_image (optional) |
The dblab UI container image. | postgresai/ce-ui:{{ dblab_engine_ui_version }} |
dblab_engine_ui_port (optional) |
The port at which the dblab UI container accepts connections. | 2346 |
dblab_engine_clone_access_addresses (optional) |
IP addresses, from which clone containers accepts connections. | 127.0.0.1 |
dblab_engine_clone_port_pool.from dblab_engine_clone_port_pool.to (optional) |
Pool of ports for Postgres clones. Ports will be allocated sequentially, starting from the lowest value. The "from" value must be less than "to". | 6000, 6099 |
dblab_engine_config_file (optional) |
Copy the specified dblab configuration file instead of generating a new configuration file. | "" |
dblab_engine_preprocess_script (optional) |
Copy the preprocessing script file to '{{ dblab_engine_base_path }}/preprocess.sh' |
"" |
| Variable | Description | Default value |
|---|---|---|
platform_project_name (required) |
Platform Project name. | "" |
platform_org_key (required) |
Platform Organization key. | "" |
platform_url (optional) |
Platform API URL. Keep it default to work with Postgres.ai SaaS. | https://postgres.ai/api/general |
By default the DBLab server waits to be called: Postgres.ai connects to it, so it needs an address Postgres.ai can reach and an open port. Set dblab_agent_install to true to install a small agent beside the engine instead. The agent registers the server with Postgres.ai, stores the access token it is given and from then on asks Postgres.ai for work — nothing connects to the server, so it needs no public address and no open port.
| Variable | Description | Default value |
|---|---|---|
dblab_agent_install (optional) |
Install the agent that makes this server call Postgres.ai. | false |
dblab_agent_version (optional) |
The agent version. This is the first rc tag that carries both job channels; every earlier rc serves neither. |
0.17.0-rc.5 |
dblab_agent_image (optional) |
The agent container image. | postgresai/instance-jobs:{{ dblab_agent_version | replace('v', '') }} |
dblab_agent_container_name (optional) |
The agent container name. | dblab_agent |
dblab_agent_config_path (optional) |
The directory holding the agent's .pgwatch-config file. |
{{ dblab_engine_base_path }}/agent |
dblab_agent_uid dblab_agent_gid (optional) |
The user the agent container runs as, and the owner of its configuration file. The image's own unprivileged user. | 1001, 1001 |
dblab_agent_cpus (optional) |
CPU limit for the agent container. | 0.25 |
dblab_agent_memory (optional) |
Memory limit for the agent container. | 256M |
dblab_agent_dblab_url (optional) |
The DBLab Engine address the agent calls. Both run on this server, so this is loopback. | http://{{ dblab_engine_container_host }}:{{ dblab_engine_port }} |
dblab_agent_api_base_url (optional) |
The Postgres.ai address the agent registers with and polls. | {{ platform_url }} |
dblab_agent_set_engine_token (optional) |
Also write the access token into the engine's platform.accessToken. Leave it off for now: Postgres.ai does not yet accept an instance-scoped token at v1.dblab_token_check, and the engine refuses to start on a token that check rejects. |
false |
Notes:
platform_urlmust behttps, orhttpto a loopback address for a local rig: the access token travels as a request header. The playbook refuses to continue otherwise.- A certificate rarely carries an IP address, so address Postgres.ai by the name on its certificate and put the certificate authority file on the server. The playbook warns about an https address that is an IP; it does not refuse one.
- There is no way to supply the access token by hand, and that is deliberate. Unlike the DBLab channel, which has an admin mint (
v1.dblab_instance_token_create), Joe's token can only come from a registration that asked for one: enrolment is the mint's only caller. So this playbook takes no token variable — a value an operator cannot legitimately obtain is not an input — and if registration fails the install stops rather than falling back to anything. - The access token is minted on first registration only. Running the install again is safe: a server that already has access keeps it, and the playbook says so. To replace it, an organization admin has to revoke the server's access first.
- One server serves one thing. Do not add a monitoring instance's
instance_idto the agent's configuration file on a DBLab server.
| Variable | Description | Default value |
|---|---|---|
cli_install (optional) |
Install the DBLab CLI on the dblab server. | true |
cli_version (optional) |
The version of the DBLab CLI to be installed. | {{ dblab_engine_version }} |
cli_environment_id (optional) |
an ID of the DBLab CLI environment to create. | {{ platform_project_name }} |
| Variable | Description | Default value |
|---|---|---|
joe_bot_install (optional) |
Install Joe Bot. | false |
joe_version (optional) |
The Joe Bot version. 0.11.x lacks the PG18 EXPLAIN fix, so every explain against a PG18 clone comes back Failed. |
0.12.0-rc.3 |
joe_config_path(optional) |
The Joe Bot 'configs' directory. | {{ dblab_engine_base_path }}/joe/configs |
joe_meta_path(optional) |
The Joe Bot 'meta' directory. | {{ dblab_engine_base_path }}/joe/meta |
joe_image (optional) |
The Joe Bot container image. | postgresai/joe:{{ joe_version }} |
joe_container_name (optional) |
The Joe Bot container name. | joe_bot |
joe_container_host (optional) |
The IP address at which the 'joe_bot' container accepts connections. | 127.0.0.1 |
joe_port (optional) |
The port at which the 'joe_bot' container accepts connections. | 2400 |
joe_platform_token(optional) |
Postgres.ai Platform API secret token. | platform_secret_token |
joe_communication_type(optional) |
Available communication types ("webui", "slack", "slackrtm", "slacksm") | webui |
joe_communication_signing_secret (optional) |
Web UI Signing Secret. | secret_signing |
joe_communication_slack_signing_secret (optional) |
Slack App Signing Secret. | secret_signing |
joe_communication_slack_access_token (optional) |
Bot User OAuth Access Token. | xoxb-XXXX |
joe_communication_slack_app_level_token (optional) |
App Level Token (for "slacksm"). | xapp-XXXX |
joe_communication_channels_channel_id (optional) |
Web UI channel ID. | {{ platform_project_name }} |
joe_communication_channels_project (optional) |
Postgres.ai Platform project. | {{ platform_project_name }} |
joe_dblab_params_dbname (optional) |
PostgreSQL connection parameters used to connect Joe to the clone (dbname). | postgres |
joe_dblab_params_sslmode (optional) |
PostgreSQL connection parameters used to connect Joe to the clone (sslmode). | prefer |
joe_config_file (optional) |
Copy the specified Joe Bot configuration file instead of generating a new configuration file. | "" |
Note: Joe Bot repository: https://gitlab.com/postgres-ai/joe
By default Joe waits to be called: Postgres.ai connects to /webui/ on Joe's port, so Joe needs an address Postgres.ai can reach and an open port — even on a server whose engine has already been inverted with dblab_agent_install. Set joe_agent_install to true to install a second small agent beside Joe instead. It asks Postgres.ai for Joe work and hands each command to the Joe on this server over loopback, so Joe needs no public address and no open port.
It is the same instance-jobs image as the DBLab agent, run a second time with a Joe configuration of its own. The two are independent: a server can run either, both or neither.
The playbook enrols the Joe itself, the same way it enrols an inverted engine: it registers this box with Postgres.ai using the organization's platform_org_key, asks for a per-instance access token, and writes the token it is given into the agent's configuration. There is nothing to obtain by hand.
| Variable | Description | Default value |
|---|---|---|
joe_agent_install (optional) |
Install the agent that makes this server's Joe call Postgres.ai. | false |
joe_agent_instance_id_file (optional) |
The file holding the id this box registers under. The DBLab Engine assigns itself one on first boot and this reuses it, so the box has one identity. | {{ dblab_engine_meta_path }}/instance_id |
joe_agent_version (optional) |
The agent version. There is no separate Joe image — the same image serves both channels — so this follows the DBLab agent's version by default. | {{ dblab_agent_version }} |
joe_agent_image (optional) |
The agent container image. | postgresai/instance-jobs:{{ joe_agent_version | replace('v', '') }} |
joe_agent_container_name (optional) |
The agent container name. | joe_agent |
joe_agent_config_path (optional) |
The directory holding this agent's .pgwatch-config file. Its own, not the DBLab agent's. |
{{ dblab_engine_base_path }}/joe-agent |
joe_agent_uid joe_agent_gid (optional) |
The user the agent container runs as, and the owner of its configuration file. The image's own unprivileged user. | 1001, 1001 |
joe_agent_cpus (optional) |
CPU limit for the agent container. Budgeted separately from the DBLab agent's. | 0.25 |
joe_agent_memory (optional) |
Memory limit for the agent container. | 256M |
joe_agent_joe_url (optional) |
The Joe address the agent calls. Both run on this server, so this is loopback. A base address only — the agent appends /webui/ itself. |
http://{{ joe_container_host }}:{{ joe_port }} |
joe_agent_api_base_url (optional) |
The Postgres.ai address the agent polls for Joe work. | {{ platform_url }} |
joe_agent_signing_secret (optional) |
The secret the agent signs each call to Joe with. Must be the secret Joe itself holds. Written into the agent's configuration as joe_verify_token, which despite the name is the signing key and is never sent. |
{{ joe_communication_signing_secret }} |
joe_agent_joe_start_timeout (optional) |
How long to wait for Joe's API port before giving up. | 60 |
Notes:
-
A Slack-only Joe cannot be inverted. Joe registers its HTTP handlers per communication type, so a Joe whose
joe_communication_typeisslack,slackrtmorslacksmserves no/webui/path at all — and/webui/is the only surface the agent can hand a command to. The playbook refuses to install the agent for such a Joe, both from the variable and from what the running Joe reports about itself, and says which it found. Give that Joe awebuicommunication type, or leavejoe_agent_installoff and keep it on the pull model. -
platform_urlmust behttps, orhttpto a loopback address for a local rig: the access token travels as a request header. The playbook refuses to continue otherwise. -
Joe is expected on this same server. The playbook warns about a
joe_agent_joe_urlthat is plainhttpto another host — a command and its results are the query text and the plan. -
One container serves one channel, and the agent enforces it: a configuration naming two is refused with
one box serves one channel. So the two agents on a server cannot share a.pgwatch-config— pointing this one at the DBLab agent's file does not merge the channels, it stops both containers. Each needs a directory of its own, and the playbook refuses an install where the two coincide. -
joe_agent_joe_urlmust be a base address with no path. The agent appends/webui/…itself, sohttp://host:2400/webuiis requested as/webui/webui/channelsand answers 404 on every job. A trailing slash is fine; a path is not, and the agent's own check does not catch it — this playbook's refusal is the only guard. -
There is no way to supply the access token by hand, and that is deliberate. Unlike the DBLab channel, which has an admin mint (
v1.dblab_instance_token_create), Joe's token can only come from a registration that asked for one: enrolment is the mint's only caller. So this playbook takes no token variable — a value an operator cannot legitimately obtain is not an input — and if registration fails the install stops rather than falling back to anything. -
The access token is minted on first registration only. Running the install again is safe: a server that already has access keeps the token it holds, and the playbook says so. To replace it, an organization admin has to revoke the server's access first (
v1.joe_instance_token_revoke, which needs Admin or AllFeaturesUser in the organization) and then re-run this playbook — there is deliberately no way to mint a second token for a box that already has a live one. -
A first registration into an organization with no owner is refused: a self-registered Joe instance has to be attributed to somebody. Set the organization owner, or create the instance through the console. Not a state an organization created through the product reaches.
-
If the registration is answered
foreign_org, this box's instance id already belongs to an instance in a different organization. Nothing is revoked and no token is minted; check thatplatform_org_keyis the right organization's. -
Inverting Joe does not by itself make Postgres.ai hand out Joe work. The routing predicate is a Postgres.ai-side setting and a recent poll from this box's agent, and both halves are required:
update public.platform_settings set setting_value = 'true' where lower(setting_name) = lower('app.settings.joe_jobs_enabled');
So turning the flag on does nothing to an instance whose agent is not running, and turning it off returns every instance to being dialled — the flag alone is the rollback. The agent records its polls even while the channel is off, so an operator can see which boxes are ready before flipping it.
-
app.settings.joe_job_claim_limitis a Postgres.ai-side setting too, and this playbook does not set it and neither should you from here. It must never exceed the Joe worker pool in the agent running on the box: claim more than the pool and Postgres.ai's sweep marks the unstarted tailfailedwhile the agent is still going to run it — which on this channel means the caller is told the command failed and Joe then runs their query anyway. If it has to be raised, the agent's pool moves first.
| Variable | Description | Default value |
|---|---|---|
netdata_install (optional) |
Install the Netdata (netdata-for-dle) with plugin for DBLab Engine. | true |
netdata_version (optional) |
The image tag of the 'netdata' container. | 1.40.1 |
netdata_image (optional) |
The image of the 'netdata' container. | postgresai/netdata-for-dle:v{{ netdata_version }} |
netdata_port (optional) |
The port at which the 'netdata' container accepts connections. | 19999 |
| Variable | Description | Default value |
|---|---|---|
proxy_install (optional) |
Install Envoy proxy and issue Let's Encrypt certificate. Used to provide public access to the dblab UI/API using an encrypted connection. | false |
proxy_version (optional) |
Version to install Envoy proxy. | 1.32 |
proxy_dblab_engine_public_port (optional) |
The port on which the dblab UI is publicly accessible. | 443 |
certbot_install_method (optional) |
Controls how Certbot is installed. Available options are 'package', 'snap', and 'pip'. | pip |
certbot_install_version (optional) |
Certbot version (if 'certbot_install_method: pip'). | 2.6.0 |
certbot_create_if_missing (optional) |
Set certbot_create_if_missing to yes or True to let this role generate certs. | true |
certbot_create_method (optional) |
Set the method used for generating certs with the certbot_create_method variable — current allowed values are: standalone or webroot. | standalone |
certbot_auto_renew, certbot_auto_renew_user, certbot_auto_renew_hour, certbot_auto_renew_minute (optional) |
By default, this role configures a cron job to run under the provided user account at the given hour and minute, every day. The defaults run certbot renew (or certbot-auto renew) via cron every day at 03:30:00. | true, {{ username }}, 3, 30 |
certbot_admin_email (required) |
Email to issue certificate, for example, admin@example.com |
"" |
certbot_domain (required) |
Domain to issue certificate, for example, example.com |
"" |
Note: More 'certbot' variables see here.
| Variable | Description | Default value |
|---|---|---|
print_usage_instructions (optional) |
Print the usage instructions after deployment. | true |
Note: More detailed information about the deployment is available here
export AWS_ACCESS_KEY_ID=*******
export AWS_SECRET_ACCESS_KEY=**********
docker run --rm -it \
--env AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} \
--env AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
postgresai/dle-se-ansible:v1.1 \
ansible-playbook deploy_dle.yml --extra-vars \
"provision='aws' \
server_name='dblab-server' \
server_type='m5.4xlarge' \
server_image='ami-0620ab203b0c70bc0' \
server_location='ca-central-1' \
volume_size='200' \
dblab_engine_verification_token='SMIgTlFeDdvs75Qg2GwfL18sCfyDf0O1' \
dblab_engine_version='3.5.0' \
zpool_datasets_number='3' \
ssh_public_keys='ssh-ed25519 AAAAC*** alice.johnson@example.com' \
platform_org_key='***********' \
platform_project_name='dblab-server'"Note: Specify the username and IP address of your server in the dblab_host variable.
docker run --rm -it \
-v $HOME/.ssh:/root/.ssh:ro \
-e ANSIBLE_SSH_ARGS="-F none" \
postgresai/dle-se-ansible:v1.1 \
ansible-playbook deploy_dle.yml --extra-vars \
"dblab_host='root@12.34.56.78' \
zpool_datasets_number='3' \
dblab_engine_version='3.5.0' \
dblab_engine_verification_token='super-secret-value' \
platform_org_key='***********' \
platform_project_name='dblab-server'"Note: In this example, we use $HOME/.ssh:/root/.ssh:ro to mount a directory with SSH keys to access the server from the container. You can override this value so that only a specific SSH key (example $HOME/.ssh/my_key:/root/.ssh/id_rsa:ro) is mounted into the container.
- Start by configuring the
Arecord of your domain so that it points to the public IP address of the DBLab Engine server. - Define your domain in the
certbot_domainvariable and the email address in thecertbot_admin_emailvariable. - Execute the ansible-playbook with the
proxytag to install the Envoy proxy and to issue a Let's Encrypt certificate.
docker run --rm -it \
-v $HOME/.ssh:/root/.ssh:ro \
-e ANSIBLE_SSH_ARGS="-F none" \
postgresai/dle-se-ansible:v1.1 \
ansible-playbook software.yml --tags proxy --extra-vars \
"dblab_host='root@12.34.56.78' \
proxy_install='true' \
certbot_domain='example.domain.com' \
certbot_admin_email='admin@example.domain.com' \
platform_org_key='***********'' \
platform_project_name='dblab-server'"Note: After you've set up your proxy server for clone access, you will need to specify the port by adding +3000 to it in your connection string. For instance, if your regular connection port is 6000, you should use port 9000 for accessing your clone. This adjustment is necessary to ensure proper network connectivity via proxy server.
You do not have to reinstall it. Run the same playbook with the dblab-agent tag against that server: it leaves the engine alone, installs the agent and starts it. Fill in the project name and the verification token that server already uses.
docker run --rm -it \
-v $HOME/.ssh:/root/.ssh:ro \
-e ANSIBLE_SSH_ARGS="-F none" \
postgresai/dle-se-ansible:v1.1 \
ansible-playbook deploy_dle.yml --tags dblab-agent --extra-vars \
"dblab_host='root@12.34.56.78' \
dblab_agent_install='true' \
platform_org_key='***********' \
platform_project_name='dblab-server' \
dblab_engine_verification_token='existing-verification-token'"The engine is neither reinstalled nor restarted; its configuration is left alone unless you also set dblab_agent_set_engine_token, and then it is reloaded with a SIGHUP rather than restarted. The switch takes effect when the agent makes its first call, so you can watch it happen. To undo it, stop the agent container and have an organization admin revoke the server's access; Postgres.ai goes back to connecting to the server on its own.
The same idea, with the joe-agent tag. It leaves Joe and the engine alone, registers this Joe with Postgres.ai, installs a second agent beside them and starts it. Fill in the signing secret that Joe already holds; the access token is minted during registration.
docker run --rm -it \
-v $HOME/.ssh:/root/.ssh:ro \
-e ANSIBLE_SSH_ARGS="-F none" \
postgresai/dle-se-ansible:v1.1 \
ansible-playbook deploy_dle.yml --tags joe-agent --extra-vars \
"dblab_host='root@12.34.56.78' \
joe_agent_install='true' \
platform_org_key='***********' \
platform_project_name='dblab-server' \
joe_communication_signing_secret='existing-signing-secret'"Neither Joe nor the engine is reinstalled or restarted, and no configuration but the new agent's own is written. Joe has to be running and serving a webui communication type: the playbook asks Joe what it serves and stops if /webui/ is not among them. To undo the switch, stop the joe_agent container and have an organization admin revoke the server's access; Postgres.ai goes back to connecting to Joe on its own.
By default, every time the playbook is run, a new configuration file, named '.dblab/engine/configs/server.yml', will be generated. If you wish to manage the DBLab server via automation (for instance, to update the version or modify the configuration), you can specify a configuration file (e.g., located on the server where the playbook is initiated) in the dblab_engine_config_file variable. In this case, the content of this file will replace the configuration file. This can be particularly helpful for implementing CI/CD through your repository to manage the DBLab server.
docker run --rm -it \
-v $HOME/.ssh:/root/.ssh:ro \
-v /path/to/config:/root/config:ro \
-e ANSIBLE_SSH_ARGS="-F none" \
postgresai/dle-se-ansible:v1.1 \
ansible-playbook software.yml --extra-vars \
"dblab_host='root@12.34.56.78' \
zpool_datasets_number='3' \
dblab_engine_version='3.5.0' \
dblab_engine_config_file='/root/config/server.yml' \
platform_org_key='***********' \
platform_project_name='dblab-server'"Note: Replace '/path/to/config' with the actual directory path where your configuration file is located. This path will be mounted into the Docker container, allowing the automation to access your configuration file.
Example of a repository that demonstrates a how to manage the configuration of the DBLab Engine using Git - https://gitlab.com/vitabaks/dblab-gitops-example
With DBLab Engine installed from Postgres.ai Platform, guaranteed vendor support is included – please use one of the available ways to contact.