Multiple App Instances¶
| Description / name | Input element |
|---|---|
| Your domain name |
Apps that used to be supported by the "ArrX" system which allowed the user to define a set of instances of a given app (as opposed to installing multiple instances one at a time) are being transitioned to a new generalized, inventory-driven approach.
The general idea is to move all the configuration into the /srv/git/saltbox/inventories/host_vars/localhost.yml along with other customizations.
As of 01-23-2024 the roles supported are:
autoscan
bazarr
calibre
deluge
emby
gluetun
jellyfin
jellyseerr
lgsm
lidarr
mariadb
mcrouter
minecraft
mongodb
nginx
node_red
ombi
overseerr
plex
postgres
qbittorrent
qbittorrentvpn
radarr
redis
requestrr
rflood
sonarr
tautulli
traktarr
transmission
watchstate
whisparr
IMPORTANT: if you ware reading this after the date mentioned above, this list may not be complete.
There is a command at the end of this page you can use to get an updated list of roles that support this method.
Again, that list shows what roles supported this system as of the date shown above; if you are reading this after that date, there is a non-zero chance that additional roles have been added.
Overview¶
Define a list of all the instances of the container you want to create; if you don't want to customize them beyond that, this is all that's required.
Add the list to the inventory file at /srv/git/saltbox/inventories/host_vars/localhost.yml, formatted as so:
sonarr_instances: ["sonarr", "sonarrbing", "sonarrbang", "sonarrboing"]
Run the standard app tag (in this case sb install sonarr) to set up all the instances you've defined. If you attempt to run any of your new instance names as tags, the install will fail with an error. Run ONLY the standard app tag. If one or more of the instances already exist, their existing configurations TYPICALLY will not be touched or overwritten, though this is dependent on the specific role. If the standard role overwrites or modifies the configuration, then so will this, since it's calling the standard role for each instance.
Info
While the first entry in the list is sonarr in the above example, you are not required to include an instance named sonarr. The list should include all instances of the app you want to end up with, regardless of their names. If an instance is not listed here, it will be skipped by actions that iterate through this list.
For example:
sonarr_instances: ["sonarrhd", "sonarr4k", "sonarranime", "sonarrkids"]
is valid if you want sonarrhd to be your primary instance instead of sonarr.
sonarr_instances: ["sonarr4k", "sonarranime", "sonarrkids"]
would shift the primary instance to sonarr4k and result in only those three instances being deployed, which is typically not what you want.
Given the example above, sb install sonarr would install:
| List entry | Container Name | Config Directory | Subdomain |
|---|---|---|---|
| sonarr | sonarr | /opt/sonarr |
sonarr.yourdomain.tld |
| sonarrbing | sonarrbing | /opt/sonarrbing |
sonarrbing.yourdomain.tld |
| sonarrbang | sonarrbang | /opt/sonarrbang |
sonarrbang.yourdomain.tld |
| sonarrboing | sonarrboing | /opt/sonarrboing |
sonarrboing.yourdomain.tld |
Those names have to be unique across all of your containers, so it is suggested that you keep with the rolename+suffix pattern for these additional instances.
Per-instance customization¶
See Override scope.
Getting an updated list of supported roles¶
You can find roles that support this method with the following command:
grep -Ril "_instances:" /srv/git/saltbox/roles /opt/sandbox/roles | awk 'BEGIN{RS="roles/"; FS="/defaults"}NF>1{print $1}' | sort -u
What about roles that aren't listed here?¶
The following method is not officially supported
Roles are mostly untested with this method. Deploying them in this way may lead to unexpected behavior, so proceed with caution and be prepared for some troubleshooting.
You can create an additional instance of nearly any role by passing a custom instance name at the command line using the --extra-vars (or -e) argument.
For example, this will install a single standard instance of photoprism:
sb install sandbox-photoprism
Then if you wanted a second at photoprism_again.yourdomain.tld:
sb install sandbox-photoprism -e photoprism_name=photoprism_again