Sophora Docker images
The available Docker images can be viewed and pulled from our Docker registry at https://docker.subshell.com.
Most of our container images are automatically created by Jenkins, subshell's build server. After each build, the images are released and pushed to the Docker registry.
All releases are tagged with their release version, as well as the respective major and minor version. A release numbered 4.1.2 would be tagged 4.1.2, 4.1, and 4. All snapshots are each tagged with their branch name, so the current master branch is tagged with the master tag, i.e. the 4.x branch with the 4.x tag and with 4.x-SNAPSHOT.
Most of our Docker images are based on an Alpine Linux image with Zulu JRE 11. To make sure the container images are as small as possible, we use JRE images instead of JDK images. We try to reduce the application size and startup time in the build process of the images by using features from improved Java versions, including Class Data Sharing.
Using the Sophora Docker images
In order to pull-up a Docker image (apart from having Docker installed), you first need to log in to our Docker Registry. You will be asked for your username and password.
~ ❯ docker login docker.subshell.com
After you have successfully logged in, the container image of the Sophora server can be pulled up, for example:
~ ❯ docker pull docker.subshell.com/sophora/sophora-server:4.0.2
4.0.2: Pulling from sophora/sophora-server
188c0c94c7c5: Already exists
d682b0f00ecc: Already exists
09b6d6b7366f: Pull complete
7985c45cc140: Pull complete
9eb276220147: Pull complete
189f3e261020: Pull complete
Digest: sha256:d472fa92863419c512a9de26ce185bf26baa42159beb762fc6f5e794858df84b
Status: Downloaded newer image for docker.subshell.com/sophora/sophora-server:4.0.2
docker.subshell.com/sophora/sophora-server:4.0.2
The container images do not contain a meaningful configuration of the software. Therefore, a configuration for the corresponding application must always be mounted in each Docker image. Details can be found in the following section.
Configuring the applications
The applications running in the Sophora Docker images have to be configured via volume mounts. A local application.yaml is mounted in the container in the correct directory so that the application in the container can read it.
The following table describes the mount paths for some of the Sophora Docker images. (The table will be completed and expanded over time).
| Application | Image | Paths for the configuration | Paths containing persisted state |
|---|---|---|---|
| Sophora Server | sophora/sophora-server |
|
|
| Admin Dashboard | sophora/sophora-dashboard |
|
|
| Importer | sophora/sophora-importer(>= Version 4) |
| |
| MobileClient (Webclient) | sophora/sophora-webclient |
| |
| Sophora Indexing Service (SISI) | sophora/sophora-indexing-service |
| |
| Image Access Service | sophora/sophora-image-access-service |
| |
| Image Update Service | sophora/sophora-image-update-service |
| |
| Sophora Metadata Supplier | metadata-supplier/metadata-supplier |
|
|
Sophora Helm charts
We provide Helm charts for many of our Sophora components. The Helm charts are located in a public Git repository on Github.com. The Helm charts are published to a GitHubs builtin Chart Registry (based on GHCR) and to Artifact Hubs subshell Repository.To use the charts, the Helm registry must be configured as follows:
~ ❯ helm repo add subshell https://subshell.github.io/helm-charts
"subshell" has been added to your repositories
The command adds the repository at the given URL with the name "sophora". The name of the repository is only valid on your computer and can be chosen arbitrarily. The Helm charts are always referenced with the name of the repository and the chart name, e.g. sophora/sophora-server. If you call the helm repository sop locally, then the Helm chart name would be sop/sophora-server. The following table shows a list of our Helm registries.
| Name (example) | URL | Contents |
|---|---|---|
| subshell | https://subshell.github.io/helm-charts | All Helm charts for applications and tools that are closely related to Sophora, e.g. the Sophora Server and all Sophora tools. |
| subshell-lab | https://subshell.github.io/helm-charts-lab | Helm charts for subshell side projects. |
Deploying the Sophora Docker images in Kubernetes with Helm charts
The following table gives an overview of the available subshell Helm charts. The charts have been tested with Sophora 4.
| Application | Chart | Notes |
|---|---|---|
| Sophora Server | sophora/sophora-server | When Sophora Servers are deployed, the system automatically switches the Servers should one of the Sophora Servers be shut down. |
| Admin Dashboard | sophora/sophora-dashboard-old | |
| Sophora Image Service | sophora/sophora-image-service | This chart includes both the Image Update Service and the Image Access Service, |
| Sophora Importer | sophora/sophora-importer | Since a watch folder mechanism does not work in a Kubernetes environment, a S3 bucket is required. The S3 bucket is mounted in the file system via a Kubernetes Sidecar Container. Files can then be imported via the bucket. |
| Sophora Indexing Service (SISI) | sophora/sophora-indexing-service | Requires a SolrCloud and a Redis cluster for operation. These are available via official Helm charts. |
| Repository import (via Importer) | sophora/sophora-repo-import | This chart is special. It is used to import a Full Admin Export (nodetypes, users, etc.) in order to initialize a new Sophora Server. The export must be downloadable in one or more .zip archives under a Basic Auth protected URL. The archives are downloaded, unzipped, and then imported by a separate Sophora Importer. When the import is complete, all tools involved in the repository import are shut down again. A "job" is deployed in Kubernetes that is only designated for this one-time repository import. |
| Update site | sophora/sophora-updatesite | This chart allows you to host an update site on a Nginx server. |
| MobileClient (Webclient) | sophora/sophora-webclient | |
| O-Neko | subshell-tools/o-neko | For now, this chart is available in subshell's Helm Registry, but may migrate to a public registry at some point, since O-Neko is open source. It requires a MongoDB cluster, which is available through official Helm charts. |
