Magnolia cockpit concepts
This pages explains how the different elements you see in the cockpit fit together:
Cockpit
The cockpit is the user interface to view and manage Magnolia cloud-based packages and provide actions to update the environments in them.
Cloud content
By content, we refer to both:
-
Editor-created content such as web pages, images, documents, which are stored in the Magnolia JCR repository workspaces such as
website,dam,contacts, and so on. -
Administrator-created configuration content such as module and server configuration data, users, groups and roles, which are stored in the
config,users,usergroupsanduserrolesworkspaces.
Cloud package
A package is a group of cloud-based environments which belong together.
An example of this is a group of environments and their spaces used to build, test and deliver a corporate website.
Cloud snapshot
A snapshot is created based on development changes pushed to the cloud-based Magnolia Git repository. You create a snapshot to transfer and apply these changes to the Integration environment. You can then wrap one or more snapshots into a release.
Cloud release
A release is created based on the latest snapshot. When you Creating a release, you give the release a name and a description. You Promoting a release to UAT in the Integration environment and then in the UAT and Live environments.
Cloud release version
The Magnolia cockpit system automatically assigns a version to every
release created. The version has the pattern v<index>, where the index
is a number starting with 1. The index is incremented with every new
version resulting in v1, v2, v3, and so on.
Cloud environment
A cloud-based package is made up of three default environments. An environment consists of one or several spaces.
The default Magnolia environments in the cloud are:
-
Live environment: delivers an approved version of the site to customers.
-
UAT (User Acceptance Testing) environment: allows developers to make the next version of the site available to editors and managers for testing and review.
-
Integration environment: helps developers to try out ideas and solutions with Magnolia.
Cloud environments vary
Depending on your subscription package, the environments available to you may differ.
For example:
You may have only a single Live environment available, or only a UAT and a Live environment. In these cases, you can deploy a development snapshot directly in the Live or in the UAT environment respectively.
Cloud space
A space exists in an environment and groups together related functionality needed to build or deliver a site. Which systems a space actually contains and how they are connected is defined by the space’s setup. A space is a container for one or more instances of Magnolia.
Examples of spaces are:
-
The Live environment is typically split into two spaces:
-
Author space: The authoring space is where editors work on content. It contains mainly the cloud-based Magnolia back-end.
-
Public space: The live space is where content is being delivered. It contains a larger set of cloud-based Magnolia instances, load balancers, caches, etc.
-
-
The UAT environment often contains two spaces (one public, one author, with one instance each) where new developments are tested and reviewed by managers and editors.
-
The Integration environment consists of a single space. In this environment the separation between delivery and authoring is not important so a single space suffices.
Cloud space setup
A space setup defines how a space is technically set up with Magnolia.
It contains one or several Magnolia instances of the same or different type, in addition to other systems required to fulfil the purpose of the space.
Examples of space setups are:
-
Since delivery is separated from authoring in a production environment and they are in different networks requiring different attention, they are defined as one space each.
-
The live space setup of a high-traffic content product contains many public instances plus a load-balancer, and possibly advanced caches.
-
The authoring space setup of a typical website product consists only of a single instance.
-
-
The setup of a review and testing space may initially only consist of a single author instance, as this is sufficient to test all aspects of a new release. It may eventually contain one or two public instances eventually to test some specifics such as a new version of Public User Registration.
-
The space dedicated to development and POCs is probably the least defined, since its setup depends largely on the requirements of the development work done.
Cloud instance
Instances exist in a space. An instance is a Java webapp running in a servlet container.
There are two kinds of instance:
-
Author instance - Author instances are where editors work. This instance typically resides in a secure location behind a corporate firewall, inaccessible from the Internet. The author instance publishes content to one or more public instances.
-
Public instance - Public instances receive content from an author instance and serves it to visitors on the Web. No authoring occurs here. This instance resides in a publicly reachable location. You can have more than one public instance serving the same or different content. In a typical deployment you have at least two public instances.
Read more about instances.