Docker
Cloud CMS offers the option to run development and production installations of its software on-premise or within a
virtual private cloud. This option is available to subscription customers and can be utilized in both a development
and production capacity.
The actual installation and management of the various services involved in a full-scale production-ready Cloud CMS
deployment is facilitated greatly through the use of Docker. Docker provides a way for all of the various tiers
to be encapsulated into appropriate microservices. These microservices run within Docker containers that can be
orchestrated together to deliver the full platform.
Cloud CMS delivers its platform for use on-premise and in virtual private clouds via Docker. Docker is an capable
technology with which we've had a lot of success in terms of managing our own software as a service offering.
In addition, Docker has seen fantastic adoption by major cloud providers including Amazon, Rackspace and others.
The Cloud CMS Docker images contain everything needed to run. Unlike traditional software, there is no need
to download and then proceed through installation steps. Rather, Cloud CMS provides runtime configurations via
Docker Compose that allow you to run a single command and go. Docker will download the Cloud CMS images for you,
launch the containers and wire the containers together for you using Docker Compose.
We recommend the use of Docker Machine, Docker Swarm and the Docker AWS EC2 Engine for provisioning and running
production hosted environments. These tools allow you to take advantage of Auto Scaling groups for production
scale out. AWS has excellent Docker support that is improving every day.
Environments
Cloud CMS produces several Docker images that you may launch to construct the architecture for your own Cloud CMS
environments.
The design of a given environment will vary depending on the needs. Production environments, for example, should
be clustered to provide some assurance of fault tolerance and failover where as non-production
environments may be smaller and more volatile in nature.
The same images can be used across all environments but may be configured differently upon being instantiated into
containers. You can think of containers are "instantiated images" (with a configuration) where an image is
essentially a template that can be stamped out using Docker to construct the container and bring it online.
Images
The following images are shipped as part of a Cloud CMS release:
- API Server (
cloudcms/api-server
) - UI Server (
cloudcms/ui-server
) - Virtual Server (
cloudcms/virtual-server
) - Web Server (
cloudcms/webshot-server
)
Kits
Cloud CMS also provides developer kits that we recommend you look to for examples of typical environments. The
kits use Docker Compose to describe the environments and provide sample files to get you started.
Many of the kits make use of third-party Docker images that Cloud CMS does not produce or ship. These include
the official images for MongoDB and Elastic Search but also include HA Proxy, ZooKeeper and Redis.
- HA Proxy is used as a load balancer
- ZooKeeper is used to demonstrate automatic cluster configuration on non-AWS environments
(such as Digital Ocean, Rackspace or purely on-premise) - Redis is used as a backend provider for the Node cluster's distributed cache
Typical Environments and Architectures
Simple
This is a non-production environment that you can launch on a laptop or a small server for development,
staging, QA or other test purposes.
In addition, you may choose to launch Mongo DB and Elastic Seach as containers or you may have those servers
hosted externally.
This environment allows developers to use the API and also log into the user interface to work with content and
schemas within the graphical front-end.
Simple (API Only)
This non-production environment is similar to the previous one but leaves off the user interface. This is common
for scenarios where you solely wish to run operations against the Cloud CMS API (such as in an embedded case or
perhaps as part of an application test runner).
In addition, you may choose to launch Mongo DB and Elastic Seach as containers or you may have those servers
hosted externally.
Simply (All Images)
This is also a non-production environment but demonstrates how additional Cloud CMS produced images hook into the
architecture.
In addition, you may choose to launch Mongo DB and Elastic Seach as containers or you may have those servers
hosted externally.
The cloudcms-appserver
image provides a runtime with Node.js and other OS dependencies pre-installed so that your
custom Node applications can be launched straight away. These custom Node applications can utilize the functionality
of the cloudcms-server
node module to produce web sites with static caching, CDN compatibility, web content management
page generation and more.
Clustered
This is a production environment where the API servers are clustered. This means that there are multiple API servers
running and they're aware of one another. A distributed cache, lock and messaging system operates across the cluster
allowing any of the API cluster members to serve requests equally. A load balancer runs ahead of the API servers
and distributes requests across them.
In an AWS environment, this is typically an AWS Elastic Load Balancer but in many of the kits, you will see
HA Proxy being used.
In addition, the UI tier and Web Shot tier are clustered. In the former case, the underlying cloudcms-server
Node module provides Redis support to enable the cluster-wide distributed cache. In all cases, a load balancer
runs ahead of the cluster.
The API server is architected to be stateless and fast. API servers are designed to fail fast - they can be spun up
or spun down and the cluster automatically detects the new or departing members and redistributes state accordingly.
Clustered (with Mongo DB and Elastic Search scale out)
This is a production environment where the Cloud CMS database layers are scaled out for redundancy and throughput.
The MongoDB tier is configured to use replica sets and/or sharding. If sharding, separate mongos
process andmongoc
processes exist to coordinate connectivity to the correct shard and/or replica.
The Elastic Search tier is also configured for clustering. The clustering mechanics for Elastic Search are very
similar to those of Cloud CMS itself. Elastic Search servers provide nodes that may join or leave an Elastic Search
cluster at any time. Elastic Search cluster state is automatically redistributed on the fly.
Clustered (with dedicated API workers)
Another common production environment is one the total set of API workers is partitioned into the following groups:
- Workers
- Web Request Handlers
In this configuration, the load balancer distributes live requests to the Web Request Handlers. The Web Request
Handlers may put asynchronous jobs onto the distributed work queue as part of what they do to handle the incoming
web request. Workers consist of API servers that are not connected to the load balancer. Instead, they wait for
jobs to become available and then work on them.
The distinction between Workers and Web Request Handlers allows you to fine tune your production environment to more
finally match Web Request Handler capacity to API traffic demand. These instance types or boxes serving these
live web requests will generally require more CPU where as the Workers will generally favor more memory intensive boxes.