Simplicité on Docker

Simplicité® instances can easily be deployed on the Docker engine.

Prerequisites

Configure a Linux server with Docker (e.g. with recent Linux distributions this is straightforward as Docker is part of the distributions) or get an account at a cloud provider allowing Docker images deployments.

Take a look at the Docker documentation for details.

Run a Simplicité platform container

Use the pre-built platform images

Pre-built platform images including the latest Simplicité® intances are available and can be run as is. This is the best/normal approach if you don't have specific needs.

These images are private on our DockerHub registry, please contact us to get access to these images.

Build a custom image from the server image

If, for some good reasons, you can't use the above pre-built images you can build your own custom image:

Note: if your server has no access to DockerHub you can still get the image manually by saving it on a server which has access (docker save simplicite/<server|platform> > simplicite-server.tar), then transfer it to yor target server, then load it on this server's local docker images registry (docker load < simplicite-server.tar)

Typical procedure on CentOS 7

On an "out of the box" CentOS 7 server you can start a clean & fresh Simplicité® sandbox instance with the folowing commands in only few seconds:

First, install the standard Docker service:

sudo yum update
sudo yum install docker
sudo systemctl enable docker
sudo systemctl start docker

Then pull the platform image and run an ephemeral container from this image:

sudo docker login
sudo docker pull simplicite/platform
sudo docker run -it --rm -name <myapp> -p 80:8080 simplicite/platform:[<tag>]

Note: to make the docker container running permanently (and restarting at reboot) use -d --restart=always instead of -it --rm

The instance is then available on http://<your server IP address or hostname>

Typical procedure on Debian 9

On an "out of the box" Debian 9 server you can start a clean & fresh Simplicit√©® sandbox instance with the folowing commands in only few seconds:

Install the up-to-date Docker-CE service:

sudo apt-get update
sudo apt-get -y remove docker docker-engine docker.io
sudo apt-get install -y apt-transport-https ca-certificates wget software-properties-common
wget https://download.docker.com/linux/debian/gpg
sudo apt-key add gpg
echo "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee -a /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get -y install docker-ce
sudo systemctl start docker
sudo systemctl enable docker

Pull the platform image and run an ephemeral container:

sudo docker login
sudo docker pull simplicite/platform
sudo docker run -it --rm -name <myapp> -p 80:8080 simplicite/platform[:<tag>]

Note: to make the docker container running permanently (and restarting at reboot) use -d --restart=always instead of -it --rm

The instance is then available on http://<your server IP address or hostname>

Procedure on managed cloud platforms

Please refer to your cloud provider's documentation to learn how to deploy containers on their specific infrastructures.

Tags

There are several variants of the prebuilt images: simplicite/platform[:<tag>].

See our private DockerHub registry for details.

Java options (memory, timezone, proxy, ...)

It is possible to pass options to the JVM by using -e JAVA_OPTS=<java options>

E.g. content of JAVA_OPTS:

Use behind a reverse proxy

the exposed HTTP ports 8080/8443 are designed to be used with an HTTP/HTTPS reverse proxy such as NGINX, Lighttpd, Traefik, ...:

Warning: If you use the 8080 port with an HTTPS endpoint or the 8443 port with an HTTP endpoint it will not work as expected.

The exposed AJP port 8009 is designed to be used with a Apache reverse proxy (for both HTTP and HTTPS endpoints).

So depending on the reverse proxy you plan to use you have to use either -p <local port e.g. 8080>:8080 -p <local port e.g. 8443>:8443 or -p <local AJP port, e.g. 8009>:8009 in you docker run command.

Use an external database

Both the server and prebuilt images allows you to start a container using an external database using the appropriate DB_* environment variables. See the private DockerHub registry for details.

Using an external database is the typical approach if you use prebuilt images (for which upgrading means starting a new container).

The DOC_DIR system parameter is by default set to BLOB for external databases (this means documents are stored in the database as BLOBs). This is required otherwise the documents will be stored on the ephemeral local filesystem of the container and will thus be potentially lost (unless you have mapped the folder containing the documents as a named volume. see bellow, this is not recommended unless you have to handle huge volumes of documents).

Use a persisting embedded database

If you use an embedded database (e.g. HSQLDB) you must map the folders containing the database files and the documents as named volumes.

You first need to create these named volumes (prior to first start of the container), this has to be done only once:

sudo docker volume create <myapp>_db
sudo docker volume create <myapp>_dbdoc

Then you need to run your container with the appropriate -v volumes mappings, e.g:

sudo docker run (...) -name <myapp>\
    -v <myapp>_db:/usr/local/tomcat/webapps/ROOT/WEB-INF/db\
    -v <myapp>_dbdoc:/usr/local/tomcat/webapps/ROOT/WEB-INF/dbdoc\
    simplicite/platform[:tag]

Note: you can also use this volume strategy with dbdoc only along with an external database not configured to store documents as BLOBs. This approach is only suitable for very particular needs (e.g. if you want to have a file system access to your documents, etc.)

Use a volume for modules' Git repository

The Git repository of the modules are stored on the file system within the container, if you do nothing in particular these Git repository are ephemereal (they won't survive if you replace the container when upgrading the platform for instance). If you want your modules' Git repository to persist accross container replacements you must map the Git base folder as a named volume

You first need to create this named volume (prior to first start of the container), this has to be done only once:

sudo docker volume create <myapp>_git

Then you need to run your container with the appropriate -v volume mapping, e.g:

sudo docker run (...) -name <myapp>\
    -v <myapp>_git:/usr/local/tomcat/webapps/ROOT/WEB-INF/git\
    simplicite/platform[:tag]

Use an external platform Git URL within the container for self-upgrading

The server container can be bound to an external platform instance template's Git repository URL (using the GIT_URL environment variable) which an be local (typically a local clone path mounted as a read only volume) or remote (typically the default URL of our Git repository: https://<your username>:<your password>@platform.git.simplicite.io/template-<version>.git).

When configured like this any change on the repository is automatically applied to the deployed instance within the container when restarting it.