You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Official solr plugin for dokku. Currently defaults to installing solr 10.0.0.
Requirements
dokku 0.35.x+
docker 1.8.x
Installation
# on 0.35.x+
sudo dokku plugin:install https://github.com/dokku/dokku-solr.git --name solr
Commands
solr:app-links [<app>] # list all Solr service links for a given app
solr:create <service> [--create-flags...] # create a Solr service
solr:create-database <service> <database> # create a database in the Solr service
solr:destroy <service> [-f|--force] # delete the Solr service/data/container if there are no links left
solr:destroy-database <service> <database> [-f|--force] # destroy a database created in the Solr service
solr:enter <service> # enter or run a command in a running Solr service container
solr:exists <service> # check if the Solr service exists
solr:expose <service> <ports...> # expose a Solr service on custom host:port if provided (random port on the 0.0.0.0 interface if otherwise unspecified)
solr:info [<service>] [--info-flags...] # print the service information
solr:label <service> <key=value>... # add docker labels to the service container
solr:link <service> [<app>] [--link-flags...] # link the Solr service to the app
solr:linked <service> [<app>] # check if the Solr service is linked to an app
solr:links <service> # list all apps linked to the Solr service
solr:list # list all Solr services
solr:logs <service> [-t|--tail [<tail-num>]] # print the most recent log(s) for this service
solr:mount [--replace] <service> <source:container-dir[:options]>... # mount a host path or docker volume into the service container
solr:pause <service> # pause a running Solr service
solr:promote <service> [<app>] # promote service <service> as SOLR_URL in <app>
solr:reexpose <service> # reexpose a Solr service, applying its expose settings
solr:reset <service> [-f|--force] [--database <database>] # delete all data in the Solr service, keeping the service and its links
solr:restart <service> # graceful shutdown and restart of the Solr service container
solr:set <service> <key> [<value>] [--id <id>] # set or clear a property for a service
solr:start <service> # start a previously stopped Solr service
solr:stop <service> # stop a running Solr service
solr:unexpose <service> # unexpose a previously exposed Solr service
solr:unlabel [--all] <service> [<key>...] # remove one or all docker labels from the service container
solr:unlink <service> [<app>] [-n|--no-restart] # unlink the Solr service from the app
solr:unmount [--all] <service> [<source:container-dir>...] # remove one or all mounts from the service container
solr:upgrade <service> [--upgrade-flags...] # upgrade service <service> to the specified versions
Usage
Help for any commands can be displayed by specifying the command as an argument to solr:help. Plugin help output in conjunction with any files in the docs/ folder is used to generate the plugin documentation. Please consult the solr:help command for any undocumented commands.
--backend <string>: the execution backend to create the service with, docker or compose (default: docker)
-c|--config-options <string>: extra arguments for the process the service container runs, not docker flags; use mount for mounts
-C|--custom-env <string>: semi-colon delimited environment variables to start the service with
--definition <string>: the definition to run the service on, instead of the one its image and version resolve to
-i|--image <string>: the image name to start the service with
-I|--image-version <string>: the image version to start the service with
-N|--initial-network <string>: the initial network to attach the service to
--label <stringArray>: a docker label to put on the service container, as =, repeatable
--log-driver <string>: the docker logging driver to run the service container with (default: the daemon's own)
--log-opt <strings>: a comma-separated list of key=value docker log options for the service container
-m|--memory <int>: container memory limit in megabytes (default: unlimited)
-p|--password <string>: override the user-level service password, for datastores that have one
-P|--post-create-network <strings>: a comma-separated list of networks to attach the service container to after service creation
-S|--post-start-network <strings>: a comma-separated list of networks to attach the service container to after service start
--restart <string>: the docker restart policy to run the service container with (default: always)
-r|--root-password <string>: override the root-level service password, for datastores that have one
--service-memory <string>: memory in megabytes the datastore itself is told to use, such as a cache size or a heap, for datastores that support it (default: the datastore's own)
-s|--shm-size <string>: override shared memory size for the service docker container
--volume <stringArray>: a host path or docker volume to mount into the service container, as :[:], repeatable
--volume-target <stringArray>: mount one of the definition's volumes at another container path, as =, repeatable
--wait-timeout <string>: seconds to wait for the service to become ready (default: the datastore's own)
Create a solr service named lollipop:
dokku solr:create lollipop
You can also specify the image and image version to use for the service. It must be compatible with the solr image.
The definition a service runs on decides where its data is mounted, and is otherwise worked out from the image and version. An image whose tags do not carry the major version can name one outright, and --image and --image-version are laid over the image and version it ships. The definitions are: solr-7, solr-8.
The container log is bounded by whatever dokku logs:set --global max-size says, and by dokku's own default where it says nothing, which a service may override for itself.
The container carries a docker label for each --label, which may be repeated, beyond the ones dokku puts on it. Keys starting with dokku. or com.dokku. are dokku's own and are refused.
The service is waited on until it answers, for as long as the datastore's own default, which a slow host may raise for every service with dokku solr:set --global wait-timeout or a service may raise for itself.
dokku solr:create lollipop --wait-timeout 120
The config options are handed to the process the container runs, not to docker, so a host path or docker volume is mounted with --volume, which may be repeated.
The definition's own volumes can be mounted at another path in the container, for an image that keeps its data somewhere else, with --volume-target, which may be repeated.
--backend: show the execution backend the service was created with
--backup-access-key-id-fingerprint: show a sha256 fingerprint of the stored backup access key id
--backup-auth-fingerprint: show a sha256 fingerprint of the stored backup access key id and secret
--backup-authenticated: show whether backup credentials are stored for the service
--backup-bucket: show the bucket scheduled backups are shipped to
--backup-default-region: show the region backups authenticate against
--backup-encrypted: show whether scheduled backups are encrypted with a passphrase
--backup-encryption-fingerprint: show a sha256 fingerprint of the stored backup passphrase
--backup-endpoint-url: show the s3-compatible endpoint backups are shipped to
--backup-keyserver: show the keyserver backup public keys are fetched from
--backup-mailto: show who cron mails the output of scheduled backups to in place of the global MAILTO
--backup-object-name: show the name backups are uploaded under in place of the default
--backup-public-key-id: show the gpg public key id backups are encrypted with
--backup-schedule: show the cron schedule backups run on
--backup-schedules: show every scheduled backup, as id, schedule, bucket and use-iam
--backup-secret-access-key-fingerprint: show a sha256 fingerprint of the stored backup secret access key
--backup-signature-version: show the signature version backups authenticate with
--backup-storage-class: show the s3 storage class backups are uploaded with
--backup-timestamp: show whether backups are uploaded under a key ending in the time they started
--backup-use-iam: show whether scheduled backups authenticate with an instance role
--config-dir: show the service configuration directory
--config-options: show the config options the service container is run with
--custom-env: show the custom environment the service container is run with
--data-dir: show the service data directory
--database-name: show the name of the database inside the service
--databases: show the databases an app can be linked to in the service, space separated
--definition: show the definition the service was created with
--dsn: show the service DSN
--export-args: show the extra arguments every export of the service is run with
--expose-host: show the host the exposed DSN names
--expose-mode: show whether exposed ports are published through an ambassador or directly by the service container
--exposed-dsn: show the DSN the service is reached at through its exposed ports
--exposed-ports: show service exposed ports
--id: show the service container id
--image: show the image the service runs
--image-version: show the image version the service was created with
--import-args: show the extra arguments every import into the service is run with
--initial-network: show the initial network being connected to
--internal-ip: show the service internal ip
--labels: show the docker labels the service container is made with beyond dokku's own, as a json object
--links: show the service app links
--log-driver: show the docker logging driver the service container is run with
--log-opt: show the docker log options the service container is run with
--memory: show the memory limit the service container is run with
--mounts: show the host paths and docker volumes mounted into the service container
--password-fingerprint: show a sha256 fingerprint of the service password
--port-bind-address: show the address exposed ports without one of their own are bound on
--port-source-range: show the only range of client addresses the exposed ports accept
--post-create-network: show the networks to attach to after service container creation
--post-start-network: show the networks to attach to after service container start
--restart-policy: show the restart policy the service container is run with
--root-password-fingerprint: show a sha256 fingerprint of the service root password
--service: show the name of the service
--service-memory: show the memory in megabytes the datastore itself is told to use
--service-root: show the service root directory
--shm-size: show the shared memory size the service container is run with
--status: show the service running status
--users: show the users an app can be linked as in the service, space separated
--version: show the service image version
--volume-targets: show the container paths the service's volumes are mounted at in place of the definition's
--wait-timeout: show the seconds the service is waited on to become ready
Get connection information as follows:
dokku solr:info lollipop
Alongside the connection information this reports the properties set on the service, the state it was created with, and its backup settings. A property that was never set, or that was unset, reports as empty. Omit the service to report on every solr service:
dokku solr:info
The information can be read by machine, one json object per service:
dokku solr:info lollipop --format json
You can also retrieve a specific piece of service info via a flag, which prints it on its own:
NOTE: a flag cannot be combined with --format, and only one may be given
The exposed dsn is the one a client off the host connects with. It names the expose-host, or the first global domain without one, and is empty until the service is exposed and there is a host to name:
dokku solr:info lollipop --exposed-dsn
The properties solr:set writes are reported under the names it takes, so a value read here can be written back:
The stored backup credentials and passphrase are never printed. Each is reported as a lowercase hex sha256 fingerprint of that stored value, with surrounding whitespace trimmed, so a copy of one value can be compared against it:
A fingerprint is empty when that value is not stored. The access key id and the secret are also reported as one fingerprint of the pair, which is empty until both are stored and is what backup-auth writes in one call:
-a|--alias <string>: the prefix of the config variable the service url is set as on the app, which is suffixed with _URL
--database <string>: the database in the service to link the app to, in place of the one named for the service
-e|--env-var <string>: the full name of the config variable the service url is set as on the app, used instead of an alias and not suffixed with _URL
-n|--no-restart: whether to skip restarting the app
-q|--querystring <string>: ampersand delimited querystring arguments to append to the service url after a ?
A solr service can be linked to a container. The app and the service are put on a private docker network made for that link alone, so the app reaches the service as dokku-solr-lollipop, and two apps linked to the same service cannot reach each other through it. The app's running containers join it straight away, and the containers it is built, deployed and run in from then on join it when they are made. Here we link it to our playground app.
NOTE: this will restart your app
dokku solr:link lollipop playground
The following will be set on the linked application by default:
The host exposed here only works internally in docker containers. If you want your container to be reachable from outside, you should use the expose subcommand. Earlier versions of the plugin linked an app with a docker link, which docker has deprecated, and which set DOKKU_SOLR_LOLLIPOP_PORT style variables on the app's containers. Docker 29 no longer sets them, so an app reading them should read SOLR_URL instead. Updating the plugin moves every linked app onto the network for its link, and the docker link is gone from each app's containers once they are restarted.
NOTE: every link uses a docker network of its own. docker's default address pools hold about 31 networks, so a server with many links may need a larger default-address-pools setting in /etc/docker/daemon.json.
Another service can be linked to your app:
dokku solr:link other_service playground
The url can be set under another name with the --alias flag. The value given is the prefix of the config variable, which is suffixed with _URL and holds the same url:
An alias whose variable is already set on the app is refused, and unlink removes the variable whatever alias it was set under. An app that expects the url under a name that does not end in _URL can be given that name in full with the --env-var flag, which cannot be combined with --alias:
It is possible to change the protocol for SOLR_URL by setting the environment variable SOLR_DATABASE_SCHEME on the app. Link records the variable it set, so unlink still removes it after the scheme or querystring on it changes. A link made by an earlier version of the plugin is recorded the next time link or promote runs for it, and until then we advise you to unlink before changing the scheme.
The database and user a link was made on are recorded, so unlink, promote and a password change find the url they gave the app. An app that is already linked has to be unlinked and linked again to move it to another database or user.
-n|--no-restart: whether to skip restarting the app
You can unlink a solr service:
NOTE: this will restart your app and unset related environment variables
dokku solr:unlink lollipop playground
The network the link ran over is removed straight away, so the app's running containers can no longer reach the service, even with --no-restart. An app is still linked after its SOLR_URL is changed to point elsewhere, and is unlinked the same way. The variable it now holds is not the service's, so it is left alone, nothing is unset, the app is not restarted, and a warning says so. A variable link set that has only had its scheme or querystring changed still points at the service, and is unset.
Pass extra arguments to the process the service container runs. These are not docker flags, so use mount for mounts. The value follows -- so that its leading dash is not read as a flag:
Name the host the exposed dsn points clients at, when they reach the server by a name or address other than its global domain. It does not change where the ports are bound:
Publish the exposed ports on the service container itself rather than through an ambassador container, which relays every connection. A port-source-range cannot be used with it:
dokku solr:set lollipop expose-mode direct
Go back to publishing the exposed ports through an ambassador container:
dokku solr:set lollipop expose-mode
Mount one of the definition's volumes at another path in the container, for an image that keeps its data somewhere else. Each volume is named by where it lives in the service directory (data), and several are separated by spaces:
Go back to mounting every volume where the definition does:
dokku solr:set lollipop volume-targets
NOTE: a network, a log setting, a restart policy, a volume target, the config options, the custom environment, the memory limit or the shared memory size reaches the container the next time one is built, and set warns that it does. solr:restart keeps the container it has, so use solr:stop and then solr:start on a service that is already running.
NOTE: a port-bind-address or port-source-range reaches an exposed service with solr:reexpose, which replaces the container publishing its ports and leaves the service container running.
NOTE: an expose-mode, or a port-bind-address for a service exposed directly, reaches an exposed service with solr:reexpose, which stops and starts a running service after asking. It also reaches the service the next time it is restarted, or stopped and started.
mount a host path or docker volume into the service container
The source is an absolute host path, which must already exist, or the name of a docker volume. Options follow a second colon: ro or rw, docker's own mount options, volume-subpath= and volume-chown=:
A subpath mounts a directory within the source rather than the source itself. A docker volume mounted from a subpath needs Docker Engine 26.0 or newer, and takes no mount option but nocopy.
A chown hands the mounted directory to a user before the container is made: herokuish, heroku, paketo, root or a uid. It is only taken for a host path inside the service's own directory.
NOTE: a mount cannot land where one of the definition's volumes is mounted, which for a volume moved with the volume-targets property is where it was moved to.
NOTE: a mount reaches the container the next time one is built. solr:restart keeps the container it has, so use solr:stop and then solr:start on a service that is already running.
remove one or all mounts from the service container
NOTE: the mount is removed from the container the next time one is built. solr:restart keeps the container it has, so use solr:stop and then solr:start on a service that is already running.
add docker labels to the service container
# usage
dokku solr:label <service><key=value>...
Add a label to the service container:
dokku solr:label lollipop traefik.enable=true
Several may be given at once, and a value may hold commas and spaces:
Labelling a key the service already has replaces its value. Keys starting with dokku. or com.dokku. are dokku's own and are refused.
NOTE: a label reaches the container the next time one is built. solr:restart keeps the container it has, so use solr:stop and then solr:start on a service that is already running.
remove one or all docker labels from the service container
NOTE: the label is removed from the container the next time one is built. solr:restart keeps the container it has, so use solr:stop and then solr:start on a service that is already running.
Service Lifecycle
The lifecycle of each service can be managed through the following commands:
enter or run a command in a running Solr service container
# usage
dokku solr:enter <service>
A shell can be opened against a running service. Filesystem changes will not be saved to disk.
NOTE: disconnecting from ssh while running this command may leave zombie processes due to moby/moby#9098
dokku solr:enter lollipop
You may also run a command directly against the service. Filesystem changes will not be saved to disk.
dokku solr:enter lollipop touch /tmp/test
expose a Solr service on custom host:port if provided (random port on the 0.0.0.0 interface if otherwise unspecified)
# usage
dokku solr:expose <service><ports...>
flags:
-f|--force: stop and start a running service without asking when its container has to publish other ports
Expose the service on the service's normal ports, allowing access to it from the public interface (0.0.0.0):
dokku solr:expose lollipop 8983
Expose the service on the service's normal ports, with the first on a specified ip address (127.0.0.1):
dokku solr:expose lollipop 127.0.0.1:8983
Expose the service on random ports on a single address, and only to clients in one network:
Expose the service by publishing its ports on the service container itself rather than through an ambassador container. A running service is stopped and started to publish them, after asking, or without asking when --force is given:
dokku solr:set lollipop expose-mode direct
dokku solr:expose lollipop --force
Print the dsn a client off the host connects with, which names the expose-host or the first global domain:
dokku solr:info lollipop --exposed-dsn
unexpose a previously exposed Solr service
# usage
dokku solr:unexpose <service>
flags:
-f|--force: stop and start a running service without asking when its container has to publish other ports
Unexpose the service, removing access to it from the public interface (0.0.0.0):
dokku solr:unexpose lollipop
Unexpose a running service exposed directly, stopping and starting it without asking so that its container stops publishing the ports:
dokku solr:unexpose lollipop --force
reexpose a Solr service, applying its expose settings
# usage
dokku solr:reexpose <service>
flags:
-f|--force: stop and start a running service without asking when its container has to publish other ports
Apply a changed port-bind-address or port-source-range to an exposed service, on the ports it is already exposed on:
Move an exposed service between being published through an ambassador and directly, stopping and starting it without asking:
dokku solr:set lollipop expose-mode direct
dokku solr:reexpose lollipop --force
NOTE: a service published through an ambassador only has the ambassador replaced, so the service keeps running, though connections made through the exposed ports are dropped. An ambassador that already matches the service's settings and is publishing is left alone.
NOTE: a service whose container has to publish other ports, because it is exposed directly or is being moved between expose modes, is stopped and started. A running service is asked about first, and nothing is changed if the answer is no.
NOTE: A service that is not exposed is refused, as is one published through an ambassador that is not running.
promote service as SOLR_URL in
# usage
dokku solr:promote <service> [<app>]
If you have a solr service linked to an app and try to link another solr service another link environment variable will be generated automatically:
You can promote the new service to be the primary one:
NOTE: this will restart your app
dokku solr:promote other_service playground
This will replace SOLR_URL with the url from other_service and generate another environment variable to hold the previous value if necessary. You could end up with the following for example:
A service comes back on the version it was created with, or was last upgraded to, whatever version the plugin ships now. The image is fetched if the host no longer has it. A service that has never recorded a version and has no container left to read one from cannot be placed, and is reported rather than started on a guess. Use solr:upgrade to say which version it should run.
stop a running Solr service
# usage
dokku solr:stop <service>
Stop the service and removes the running container:
dokku solr:stop lollipop
pause a running Solr service
# usage
dokku solr:pause <service>
Pause the running container for the service:
dokku solr:pause lollipop
graceful shutdown and restart of the Solr service container
-c|--config-options <string>: extra arguments for the process the service container runs, not docker flags; use mount for mounts
-C|--custom-env <string>: semi-colon delimited environment variables to start the service with
--definition <string>: the definition to move the service onto, instead of the one its image and version resolve to
-i|--image <string>: the image to upgrade the service to
-I|--image-version <string>: the image version to upgrade the service to
-N|--initial-network <string>: the initial network to attach the service to
--label <stringArray>: a docker label to put on the service container, as =, repeatable; replaces every label the service has
--log-driver <string>: the docker logging driver to run the service container with (default: the daemon's own)
--log-opt <strings>: a comma-separated list of key=value docker log options for the service container
-m|--memory <int>: container memory limit in megabytes, 0 for unlimited
--no-migrate: place the service on the --definition named with its data left where it is, for a service whose data that definition already reads
-P|--post-create-network <strings>: a comma-separated list of networks to attach the service container to after service creation
-S|--post-start-network <strings>: a comma-separated list of networks to attach the service container to after service start
--restart <string>: the docker restart policy to run the service container with (default: always)
-R|--restart-apps: whether to stop and start the linked apps around the upgrade, required for one that migrates the data
--service-memory <string>: memory in megabytes the datastore itself is told to use, such as a cache size or a heap, empty for the datastore's own
-s|--shm-size <string>: override shared memory size for the service docker container
--volume <stringArray>: a host path or docker volume to mount into the service container, as :[:], repeatable
--volume-target <stringArray>: mount one of the definition's volumes at another container path, as =, repeatable
--wait-timeout <string>: seconds to wait for the service to become ready (default: the datastore's own)
You can upgrade an existing service to a new image or image-version:
dokku solr:upgrade lollipop
This is the only command that changes the version a service runs. With no version named it moves to the newest the service's own major version ships, which leaves the data where it is.
dokku solr:upgrade lollipop --image-version 1.2.3
Moving across a major version has to be asked for by name, because it is not a tag change: the data is mounted somewhere different under the new one, and pointing the version back does not undo it. A service can also be moved onto a definition by name, with --image and --image-version laid over the image and version it ships. This moves where the data is mounted in the same way, even when the image stays the same.
dokku solr:upgrade lollipop --definition solr-7
A service keeps the mounts it has unless --volume is passed, which replaces them, and each one is checked against the new container before the old one is taken away.
A service keeps the volume targets it has unless --volume-target is passed, which replaces them, and an upgrade onto a definition that does not mount a volume the service moved is refused before the old container is taken away. --volume-target "" puts every volume back where the new definition mounts it.
dokku solr:upgrade lollipop --volume-target ""
A service keeps its memory limit unless --memory is passed, and --memory 0 removes it.
dokku solr:upgrade lollipop --memory 512
Service Automation
Service scripting can be executed using the following commands:
list all Solr service links for a given app
# usage
dokku solr:app-links [<app>]
List all solr services that are linked to the playground app.
dokku solr:app-links playground
check if the Solr service exists
# usage
dokku solr:exists <service>
Here we check if the lollipop solr service exists.
dokku solr:exists lollipop
check if the Solr service is linked to an app
# usage
dokku solr:linked <service> [<app>]
Here we check if the lollipop solr service is linked to the playground app.
dokku solr:linked lollipop playground
list all apps linked to the Solr service
# usage
dokku solr:links <service>
List all apps linked to the lollipop solr service.
dokku solr:links lollipop
Renaming an app moves its link onto the new name, and cloning an app links the clone as well as the original.
Data Management
The underlying service data can be imported and exported with the following commands:
delete all data in the Solr service, keeping the service and its links
--database <string>: the database in the service to reset, in place of the one named for the service
-f|--force: reset the service without asking for its name first
Delete all data in the service, leaving it as empty as a newly created one. The service, its credentials, and the apps it is linked to are kept, so linked apps do not need to be relinked. Connections the apps hold open may be closed.
dokku solr:reset lollipop
The service name is asked for before anything is deleted, unless --force is given:
dokku solr:reset lollipop --force
Only the database named for the service is reset unless another is named with --database, which resets a database made with create-database and leaves every other alone:
dokku solr:reset lollipop --database paintshop
Databases and Users
A service runs in a container of its own. Several apps can share one service, and the memory its container uses, by each being linked to a database or user of its own within it, made with the following commands. Every user made in a service can use every database in it.
Create a database named paintshop in the running lollipop service, beside the one it was created with:
dokku solr:create-database lollipop paintshop
A database name may only contain lowercase letters, digits and _, start with a letter or _, and be at most 32 characters long. Link an app to it with the --database flag:
-f|--force: destroy it without asking for confirmation
Destroy the paintshop database made in the running lollipop service, along with all of its data:
dokku solr:destroy-database lollipop paintshop
The database name is asked for before anything is deleted, unless --force is given. A database an app is still linked to is refused, and the one the service was created with is only removed with the service.
Every setting a service has after it is created, other than its image, its mounts, its labels and its backup schedule, each of which has a command of its own, is changed with dokku solr:set lollipop <key> <value>, and cleared by giving no value. dokku solr:info lollipop reports each of them, with a credential reported as a fingerprint rather than its value. A setting the container is made with only reaches it once the container is built again, and set warns when that is the case: dokku solr:restart keeps the container the service has, so use dokku solr:stop and then dokku solr:start. Passing --allow-restart to set does that, or the reexpose an expose setting takes, whenever the value changed, and leaves the service alone when it did not.
Property
Description
Takes effect
initial-network
the network the service container is attached to when it is made
after solr:stop and solr:start
post-create-network
a comma-separated list of networks the container is attached to once it is made
after solr:stop and solr:start
post-start-network
a comma-separated list of networks the container is attached to once it is started
after solr:stop and solr:start
log-driver
the docker logging driver the container is run with
after solr:stop and solr:start
log-opt
a comma-separated list of docker log options the container is run with
after solr:stop and solr:start
restart-policy
the docker restart policy the container is run with
after solr:stop and solr:start
wait-timeout
the seconds the service is waited on to become ready
immediately
port-bind-address
the address exposed ports without one of their own are published on
after solr:reexpose
port-source-range
the only IP address or CIDR the exposed ports accept clients from
after solr:reexpose
expose-host
the host the exposed dsn names
immediately
expose-mode
direct to publish the exposed ports on the service container rather than through an ambassador
after solr:reexpose
volume-targets
the container paths the definition's volumes are mounted at in place of its own
after solr:stop and solr:start
config-options
extra arguments for the process the service container runs
after solr:stop and solr:start
custom-env
semicolon-delimited environment variables the container is run with
after solr:stop and solr:start
memory
the container memory limit in megabytes, 0 for no limit
after solr:stop and solr:start
shm-size
the shared memory size of the container, such as 64m
after solr:stop and solr:start
Limiting where and to whom a service is exposed
An exposed service's ports are published on every interface unless they are given an address of their own. To publish them on one address instead, set the service's port-bind-address property with dokku solr:set, and to accept connections only from clients in one IP address or CIDR, set its port-source-range property. Either reaches a running service with dokku solr:reexpose, which leaves the service running when its ports are published through an ambassador.
Only one source range can be given. The range is checked against the address a connection reaches the service from, which for a connection to the exposed port on the loopback interface, or an IPv6 connection to a service network without IPv6, is the docker network's gateway rather than the client, so with a range that leaves the gateway out, connecting to 127.0.0.1 from the dokku host itself is refused.
Exposing a service without an ambassador
An exposed service's ports are published by an ambassador, a container that relays every connection on to the service. The ambassador can be replaced without touching the service and can hold clients to a port-source-range, but relaying adds latency to every request.
To publish the ports on the service container itself instead, set the service's expose-mode property to direct with dokku solr:set. Docker has no way of changing the ports a container publishes, so the container is made again whenever what it publishes changes: when the service is exposed or unexposed, when its port-bind-address changes, and when it moves between expose modes. For a running service, dokku solr:expose, dokku solr:unexpose and dokku solr:reexpose ask before stopping and starting it, and change nothing if the answer is no. Pass --force to stop and start it without being asked. A change also reaches the service the next time it is restarted, or stopped and started.
A port-source-range cannot be enforced on a port the service container publishes itself, so it cannot be set on a service exposed directly, and a service with one cannot be exposed directly.
Connecting to an exposed service from outside the host
dokku solr:info lollipop --exposed-dsn prints the dsn a client off the dokku host connects with. It is the dsn a linked app is handed, with the exposed ports in place of the container's and a public host in place of the service container's name, so it carries the same credentials. The host is the service's expose-host property, set with dokku solr:set, or the first global domain when it has none. The port-bind-address, or an address given with a port, is never used as the host, since it is where the port is bound rather than where a client elsewhere reaches it. The dsn is empty until the service is exposed and there is a host to name.
Waiting for a service to become ready
A service is waited on until it answers on its port after it is created, cloned, started, restarted, upgraded or exposed. If it takes longer than that to start - on a slow host, or with an image that does more on its first boot - the command fails with ERROR: unable to connect.
To wait longer for every solr service on the host, set the wait-timeout global property to a number of seconds with dokku solr:set --global wait-timeout 120. To wait longer for a single service, set its wait-timeout property with dokku solr:set or pass --wait-timeout to create, clone or upgrade. The service's own setting is used first, then the global property, then the datastore's default.
Moving where a service's volumes are mounted
Each volume a service mounts is named by the directory it lives in under the service's own directory, and is mounted where the datastore's definition says. To mount one somewhere else in the container, for an image that keeps its data at another path, set the service's volume-targets property with dokku solr:set, or pass --volume-target to create, clone or upgrade. Each is written as <volume>=<container-path>, several separated by spaces, and dokku solr:info lollipop --volume-targets shows the ones a service moved.
Definition
Volume
Mounted at
solr-7
data
/opt/solr/server/solr/mycores
solr-8
data
/var/solr/data
Moving a volume changes where it is mounted, not where the image reads and writes. The datastore's own commands and the paths it is started with follow the volume, but an image that keeps writing to its own path writes into the container rather than into the volume, and what it writes is lost when the container is rebuilt, so only move a volume to where the image expects its data. The data stays in the same directory on the host, and a move reaches the container the next time one is built, so use dokku solr:stop and then dokku solr:start on a running service. An upgrade onto a definition that does not mount a volume the service moved is refused until the move is cleared or replaced.
Disabling docker image pull calls
If you wish to disable the docker image pull calls that the plugin triggers, you may set the disable-pull global property to true with dokku solr:set --global disable-pull true. Once disabled, you will need to pull the service image you wish to deploy as shown in the stderr output.
Please ensure the proper images are in place when docker image pull is disabled.
