ContentBox
Container
Open-source modular CMS
Image details
Configuration
TypeContainerlinuxortussolutions/contentbox:latest8080/tcp8443/tcp/data/contentbox/db/app/includes/shared/mediaTemplate by portainer
Standalone Install
Select an install method, to see config/commands for deploying ContentBox
Install on Portainer
Import all app templates into your Portainer instance, for easy 1-click deploys
- Ensure both Docker and Portainer are installed, and up-to-date
- Log into your Portainer web UI
- Under Settings → App Templates, paste the below URL
- Head to Home → App Templates, and the list of apps will show up
- Select ContentBox, fill in any config options, and hit Deploy
Template Import URL
https://raw.githubusercontent.com/Lissy93/portainer-templates/main/templates.json
Show Me
More install options in our documentation.
Welcome to ContentBox Modular CMS - Container Edition
ContentBox is a professional open source (Apache 2 License) modular content management engine that allows you to easily build websites, blogs, wikis, complex web applications and even power mobile or cloud applications with it's built in RESTFul services. Built with a secure and flexible modular core, designed to scale, and combined with world-class support, ContentBox can be deployed to any Java server or ColdFusion (CFML) server.Tip: ContentBox is powered by the ColdBox HMVC Framework and Hibernate ORM.
Learn more about ContentBox at https://www.ortussolutions.com/products/contentbox and more about Docker deployment here: https://contentbox.ortusbooks.com/getting-started/installation/docker
Tags
We have our tags divided by either production or bleeding edge container images. Please choose wisely :muscle:Production Tags
:latest- The latest stable version of both ContentBox and our image:{imageVersion}- Specific ContentBox and Image Version ( e.g.:5.6.0):alpine- Latest stable version based off Alpine Linux:lucee5- Latest stable version of this image with Lucee 5 warmed up:adobe2021- Latest stable version of this image with Adobe 2018 warmed up:adobe2018- Latest stable version of this image with Adobe 2018 warmed up:adobe2016- Latest stable version of this image with Adobe 2016 warmed up
Development Tags
The following tags are based off our image'sdevelopment branch. These are bleeding edge container images that we use for testing until they are promoted to production tags.:snapshot- Development version of this image:alpine-snapshot- Development version of this image based on Alpine Linux:lucee5-snapshot- Development version of this image with Lucee 5 warmed up:adobe2018-snapshot- Development version of this image with Adobe 2018 warmed up:adobe2021-snapshot- Development version of this image with Adobe 2021 warmed up:adobe2016-snapshot- Development version of this image with Adobe 2016 warmed up
Tip: Look in the tags section for other specific ContentBox versions
CommandBox Image Features
The ContentBox image is based on the CommandBox Image, so all features and environment variables are applicable. Please refer to that documentation as well: https://hub.docker.com/r/ortussolutions/commandbox/Usage
This section assumes you are using the Official Docker ImageTo deploy a new application, first pull the image (defaults to the
latest tag):docker pull ortussolutions/contentboxThe image is packaged with a self-contained EXPRESS version, which uses a very fast and portable in-memory H2 database engine. To get started just run:
docker run -p 8080:8080 \
-e EXPRESS=true \
-e INSTALL=true \
ortussolutions/contentboxTip: The INSTALL flag tells the image to take you through the ContentBox installer to pre-seed a database. You can remove this flag once your database is seeded and persisted via a volume.A new container will be spun up from the image and, upon opening your browser to
http://[docker machine ip]:8080, you will be directed to configure your ContentBox installation wizard.
Persisting Data Between Restarts
The aboverun command produces an image which is self-contained, and would be destroyed when the container is stopped. If we wanted to run a version in production, we would need to persist, at the very minimum, the database and your custom assets \(widgets, modules, themes and media library\). In order to do this we need to mount those resources in to the Docker host file system.By convention, the
express H2 database is stored at /data/contentbox/db inside the container. In addition, the custom content module which contains your custom themes, widgets, modules and media library are stored under /app/modules_app/contentbox-custom.Mountable Points
| Mount Point | Description |
|---|---|
/data/contentbox/db | The express H2 database |
/app/modulesapp/contentbox-custom | The custom code module |
/app/includes/shared/media | \\The legacy media location, use the custom modules location instead. |
Let's mount both of those volume points, so that our database and user assets persists between restarts:
docker run -p 8080:8080 \
-e EXPRESS=true \
-e INSTALL=true \
-v `pwd`/contentbox-db:/data/contentbox/db \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \
ortussolutions/contentboxNow, once our image is up, we can walk through the initial configuration. Once configuration is complete, simply stop the container and then start it without the environment variable
INSTALL in place. The H2 database and uploads will be persisted and the installer will be removed automatically on container start.docker run -p 8080:8080 \
-e EXPRESS=true \
-v `pwd`/contentbox-db:/data/contentbox/db \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \
ortussolutions/contentboxINSTALL Setting Caveats
Please remember that the INSTALL environment variable is ONLY used to go through the ContentBox installer wizard. Once the database is seeded with the installation process, you will no longer use it unless you want to reconfigure the installation.Custom Database Configuration
If you would like to connect your container to an external database system, you can very easily do so, which would allow us to connect from multiple containers in a distributed fashion \(MySQL, Oracle, MSSQL, etc\). If not, you run the risk of file locks if multiple container replicas are sharing the same H2 database.Tip: We would suggest you use the H2 database or EXPRESS edition when using only 1 replica.
The image is configured to allow all ORM-supported JDBC drivers to be configured by specifying the environment variables to connect. Alternately, you may specify a
CFCONFIG environment variable which points to file containing your engine configuration, including datasources.By convention, the datasource name expected is simply named contentbox.To programatically configure the database on container start, environment variables which represent your datasource configuration should be provided. There are two patterns supported:
DB_DRIVERconfiguration - which may be used for Adobe Coldfusion serversDB_CLASSconfiguration - which configures a datasource by JDBC driver and connection string \(Both Adobe and Lucee\)
An example container
run command, configuring a MySQL database would be executed like so:docker run -p 8080:8080 \
-e 'INSTALL=true' \
-e 'CFCONFIG_ADMINPASSWORD=myS3cur3P455' \
-e "DB_CONNECTION_STRING=jdbc:mysql://mysqlhost:3306/contentbox_docker?useUnicode=true&characterEncoding=UTF-8&useLegacyDatetimeCode=true" \
-e 'DB_CLASS=org.gjt.mm.mysql.Driver' \
-e 'DB_USER=contentbox_user' \
-e 'DB_PASSWORD=myS3cur3P455' \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \
ortussolutions/contentboxTo use the
DB_DRIVER syntax for Adobe Coldfusion, an example run command would be:docker run -p 8080:8080 \
-e 'CFENGINE=adobe@11' \
-e 'INSTALL=true' \
-e 'CFCONFIG_ADMINPASSWORD=myS3cur3P455' \
-e 'DB_DRIVER=MSSQLServer' \
-e 'DB_HOST=sqlserver_host' \
-e 'DB_PORT=1433' \
-e 'DB_NAME=contentbox_docker' \
-e 'DB_USER=sa' \
-e 'DB_PASSWORD=myS3cur3P455' \
-v `pwd`/contentbox-custom:/app/modules_app/contentbox-custom \
ortussolutions/contentboxAs you can see, these commands can become quite long. As such, using Docker Compose or CFConfig may provide a more manageable alternative.
Granular Environmental Control
A number of environment variables, specific to the ContentBox image, are availabe for use. They include:EXPRESS=true- Uses an H2, in-memory database. Useful for very small sites or for testing the image. See http://www.h2database.com/html/main.htmlINSTALL=true- Adds the installer module at runtime, to assist in configuring your installation. You would omit this from yourruncommand, once your database has been configuredCONTENTBOX_MIGRATE=true- Will perform a check and run any necessary contentbox version migrations prior to the startup of the containerBE=true- Uses the bleeding edge snapshot of the ContentBox CMS, else we will defer to the latest stable version of ContentBox.HEALTHCHECK_URI- Specifies the URI endpoint for container health checks. By default, this is sethttp://127.0.0.1:${PORT}/at 1 minute intervals with 5 retries and a timeout of 30sFWREINIT_PW- Allows you to specify the reinit password for the ColdBox frameworkSESSION_STORAGE- Allows the customization of session storage. Allows any validthis.sessionStoragevalue, available in Application.cfc. By default it will use the JDBC connection to store your sessions in your database of choice.DISTRIBUTED_CACHE- Allows you to specify a CacheBox cache region for distributing ContentBox content, flash messages, cache storage, RSS feeds, sitemaps and settings. There are only three cache regions defined in this image:default,templateandjdbc.jdbcis the default cache that will distribute your data,defaultandtemplateare in-memory caches. Please see the distributed caching section below to see how to register more caches.H2_DIR- Allows you to specify a custom directory path for your H2 database. By convention, this is set to/data/contentbox/dbwithin the containercontentbox_default_*- All Contentbox "Geek Settings" may be provided as environment variables, allowing granular control of your ContentBox settings.ORM_SECONDARY_CACHE- Iftrueit will activate the ORM secondary cash to theehcacheprovider. By default it is turned off.ORM_DIALECT- You can choose the specific ORM dialect if needed, if not we will try to auto-detect it for you.REMOVE_CBADMIN=false- Iftruethen this image will not publish an Admin module, just the core, REST and UI modules.JVM_HEAPSIZE=512- The amount in megabytes to assign the JVM running ContentBox. We default it to 512mb.
In addition, the CommandBox docker image environment variables are also available to use in your container. For additional information on using the CommandBox docker image, see the initial release blog entry.
Automatic Session Distribution
By default, the ContentBox image will use the Lucee Open Source CFML engine for running the application. It will also configure the datasource to store user sessions so you can easily scale the image or send it to Docker Swarm, Kubernetes, etc for scalability.You can also use the
SESSION_STORAGE environment variable to switch the connection to any backend you like.Distributed Caching
By default, our image configures ajdbc CacheBox cache region that will be used to distribute settings, sessions, flash data, content, RSS feeds, sitemaps, etc. This means that out-of-the-box, your ContentBox containers can use the database to distribute its content within a swarm or set of services. However, if you would like to use your own CacheBox providers or a more sophisticated distributed cache like Redis or Couchbase, you can.We have also prepared a docker compose and distribution example using Redis \(more caches to come\) and the ContentBox image. This example will allow you to have a stack that can easily distribute your sessions and content via Redis. You can find the repository in this repo under the folder: distributed-example
Healthchecks
The image contains built-in capabilities for healthchecks for the running application. You can customize the URL entry point by using theHEALTHCHECK_URI environment variable. By default, this is set http://127.0.0.1:${PORT}/ at 30s intervals with 15 retries and a timeout of 60s.Issues
Please submit issues to our repository: https://github.com/Ortus-Solutions/docker-commandbox/issuesBuilding Locally + Contributing
You can use the following to build the image locally:docker build --no-cache -f ./Dockerfile ./You can test the image built correctly:
docker run -t -p 8080:8080 -e 'EXPRESS=true' -e 'INSTALL=true' [hash]Once the hash is returned, you can use the following for publishing to the Ortus repos (If you have access)
docker tag [hash] ortussolutions/contentbox:5.6.0
docker tag ortussolutions/contentbox:5.6.0 ortussolutions/contentbox:latest
docker tag ortussolutions/contentbox:5.6.0 ortussolutions/contentbox:snapshot
docker push ortussolutions/contentboxServe ContentBox on your own domain behind Caddy, Nginx or Traefik. Fill in your domain and copy the result. It's a starting point, some apps need their own base URL or extra headers set too.
Proxying contentbox.example.com to http://contentbox:8080
Add this to your Caddyfile
contentbox.example.com {
reverse_proxy http://contentbox:8080
}Check the logs first
Nine times out of ten the logs tell you exactly what went wrong.
- In Portainer, go to Containers, click the container, then Logs. Or run
docker logs <container> - Exit codes help too:
137means killed, usually out of memory.126or127means the command inside the image is broken.
Published on a random port
This template exposes 8080/tcp without setting a host port,
so Docker picks a random free one on every deploy.
- Find it in the Ports column of Portainer's container list, or with
docker port <container>
Image won't pull
Test the pull directly on the host: docker pull ortussolutions/contentbox:latest
- "manifest unknown" means the tag no longer exists. This template uses
latest, so try pinning a specific version instead. - "toomanyrequests" is the Docker Hub rate limit. Log in with
docker loginto raise it. - "no space left on device" means a full disk. Reclaim space with
docker system prune
"exec format error"
This means the image was built for a different CPU architecture than your server.
- This image supports:
amd64, arm64, arm/v7 - Check yours with
uname -m: x86_64 is amd64, aarch64 is arm64. Raspberry Pi and other ARM boards are the usual culprits.
Raise an issue
Found something which isn't working as it should? Here's how to report it.
- Bug within the app: Open an issue within the app's repo
- Template not working: Open an issue on portainer/templates
- This website not working: Open an issue on lissy93/portainer-templates
A single container
ContentBox runs as one container, the simplest kind of app here. Just the one image to pull and nothing else wired up alongside it.
The app image
An image is the app packed up ready to go, everything ContentBox needs bundled into one download. This template pulls ortussolutions/contentbox:latest, which Docker fetches once (about 489 MB) and then starts your own copy from.
Where the image comes from
Docker pulls its images from registries, public libraries of ready-built apps. ContentBox's comes from Docker Hub, published by ortussolutions.
Version tags
The bit after the colon in the image name is the version tag. Here it's latest, which always points at the newest build, so a redeploy can bump you to a newer release without you asking. Newest right now is 5.6.0. Pin a specific tag if you would rather stay on one version.
Which machines it runs on
Every image is built for particular CPU types. This one ships for amd64, arm64, arm/v7, so it runs on both regular x86 servers and ARM boards like a Raspberry Pi.
Ports
A port is the door the app answers on. Here the app exposes a port but leaves the host side blank, so Docker picks a free one for you. It opens:
8080, published on a random host port8443, published on a random host port
Volumes
A volume is where ContentBox keeps its files so they survive an update or a restart. Without one, anything it saves would sit inside the container and vanish the moment it's recreated. This template mounts:
/data/contentbox/dbas a volume Docker manages for you/app/includes/shared/mediaas a volume Docker manages for you
Environment variables
Environment variables are the settings you hand over when you deploy, things like a password or a timezone. ContentBox takes 3 of them, all with defaults you can leave alone or tweak:
express, defaults totrueinstall, defaults totrueCFENGINE, defaults to[email protected]
Networking
Nothing custom is set, so ContentBox sits on Docker's default bridge network: its own private space that reaches the outside world only through the ports it publishes.
Platform
The platform is linux, the kind of system the container is built to run on. Docker and Portainer handle this on a normal Linux server.
Portainer app templates
Zooming out, this whole page comes from a Portainer app template: a short recipe telling Portainer how to set ContentBox up. Add the template list to Portainer once, then deploying ContentBox is a click rather than a wall of config.