Skip to main content

Indicium container

Introduction to the Indicium Application Tier container​

The container for the Indicium Application Tier can be configured with both environment variables and secrets, allowing for seamless version upgrades without the need for manual modification of the appsettings.json file. Additionally, an existing configuration can be mounted in the container if necessary.

Pull the image​

Before the image can be pulled, you need to log in to the Thinkwise Container Registry. See registry authentication for more information.

You can pull the image with the following command:

docker pull registry.thinkwisesoftware.com/public/indicium

Supported tags​

warning

In production environments, you would want to pin a specific tag or digest of the image, to prevent unwanted changes during the day and have more control over when a new version is made available.

TagDescription
latestThe most recent image
2023The most recent image of the specified year
2023.1The most recent image of the specified release
2023.1.10, 2023.1.11, 2023.1.12Specific version
tip

The container images are tagged with the same version number as the releases in TCP. Any future releases will be tagged accordingly.

How to use this image​

The image is based on .NET Core and exposes port 80 by default.

Use the following command to create and run the latest version of the container:

docker run \
	-p 80:80 \
	-e SQL_SERVER='<hostname>' \
	-e SQL_DATABASE='<iam_database>' \
	-e SQL_USERNAME='<secret location/username>' \
	-e SQL_PASSWORD='<secret location/password>' \
	registry.thinkwisesoftware.com/public/indicium

Environment variables​

VariableDescription
SQL_SERVERSet the SQL server hostname
SQL_DATABASESet the SQL database name
SQL_USERNAMESet the secret location or value for the Pool Username
SQL_PASSWORDSet the secret location or value for the Pool Password
ENABLE_REVERSE_PROXYEnable if Indicium is used behind a reverse proxy setup
ALLOWED_HEADERSSet the allowed headers, separated by commas, for the reverse proxy
ALLOWED_HOSTSSet the allowed hosts, separated by commas, for the reverse proxy
TRUSTED_PROXIESSet the trusted proxies, separated by commas, for the reverse proxy
TRUSTED_NETWORKSSet the trusted networks, separated by commas, for the reverse proxy
EXTERNAL_PATH_BASESet the external path base for the reverse proxy
ALLOWED_ORIGINSSet the allowed origins, separated by commas
PRELOAD_APPLICATIONSPreload applications, separated by commas
REDIS_CONNECTION_STRINGSet the secret location or value for the Redis Cache connection string
CUSTOM_JSONApply custom minified JSON to the container, any configuration applied with this will override any of the above specified settings

Example configuration:

docker run \
	-p 80:80 \
	-e SQL_USERNAME='<secret location/username>' \
	-e SQL_PASSWORD='<secret location/password>' \
	-e SQL_SERVER='<sql_server>' \
	-e SQL_DATABASE='<iam_database>' \
	-e ENABLE_REVERSE_PROXY='true' \
	-e ALLOWED_HEADERS='XForwardedHost, XForwardedFor' \
	-e TRUSTED_PROXIES='10.10.0.20'
	-e TRUSTED_NETWORKS='10.10.0.0/24'
	-e EXTERNAL_PATH_BASE='/indicium' \
	-e PRELOAD_APPLICATIONS='application1, application2' \
	registry.thinkwisesoftware.com/public/indicium

Secrets​

As an alternative to passing sensitive information via environment variables, you can use secrets.

A secret is the most secure way to pass sensitive information to a container. The value cannot be extracted from a configuration dump of the running container and is stored in the memory, so the container can only access it when it is running.

By default, the container will look for secrets with the following names (both in upper- and lowercase):

  • SQL_USERNAME
  • SQL_PASSWORD
  • REDIS_CONNECTION_STRING

For different secret names, a path to this secret can be specified with an environment variable.

warning

Be cautious when creating a secret. Each shell will log and save each command to its history file.

There are ways to mitigate this, for example by reading the input of the keyboard and store this as a variable. But this is beyond the scope of this manual.

Secrets with the default name:

Create secrets:

printf "svc-indicium" | docker secret create sql_username -
printf "SuperSecretPassword01@" | docker secret create sql_password -

Create a service that uses the created secrets:

docker service create \
	-e SQL_SERVER='<sql_server>' \
	-e SQL_DATABASE='<iam_database>' \
	--secret sql_username \
	--secret sql_password \
	--name indicium \
	--with-registry-auth \
	registry.thinkwisesoftware.com/public/indicium

Secrets with a custom name:

Create secrets:

printf "svc-indicium" | docker secret create someusername -
printf "SuperSecretPassword01@" | docker secret create somepassword -

Create a service that uses the created secrets:

docker service create \
	-e SQL_SERVER='<sql_server>' \
	-e SQL_DATABASE='<iam_database>' \
	-e SQL_USERNAME='/run/secrets/someusername' \
	-e SQL_PASSWORD='/run/secrets/somepassword' \
	--secret someusername \
	--secret somepassword \
	--name indicium \
	--with-registry-auth \
	registry.thinkwisesoftware.com/public/indicium
tip

For more information about secrets in Docker Swarm, see https://docs.docker.com/engine/swarm/secrets/

Using an existing configuration​

It is considered best practice to configure the container with variables, this makes it more flexible across different environments.

Configuration file​

warning

The configuration file that gets mounted needs to exist. If not, this will not work.

The configuration can be mounted inside the container. This can be done in the following way:

docker run \
	-v /path/to/appsettings.json:/etc/indicium/appsettings.json \
	registry.thinkwisesoftware.com/public/indicium

Directory with configuration file​

note

If the specified directory is empty, the configuration will be created inside it.

To mount the directory with the configuration in the container:

docker run \
	-v /path/to/directory:/etc/indicium \
	registry.thinkwisesoftware.com/public/indicium
Was this article helpful?