There are three primary project sources in the AEM implementation:
Ansible Deploy Project - used to contain all of the ansible playbooks for managing AEM docker services
Virtual Machine Project - used to create VM hosts using packer.io.
docker-aem - docker container used to run local AEM instances.
The following sections will highlight their key design decisions and their implementation details.
Ansible Deploy Project
The aemdesign-deploy project is a server automation project using Ansible to deploy and configure services. The project also contains scripted operational tasks for maintaining the operating system and services..
Before proceeding, this section contains content with assumed Ansible knowledge. Recommended starting points are ‘Intro to Playbook*s’ (NOTE: http://docs.ansible.com/ansible/latest/playbooks_intro.html) and *‘**Intro to Inventorie*s’* (NOTE: http://docs.ansible.com/ansible/latest/intro_inventory.html) in the Ansible online documentation.
This project is implemented with the following features and their concepts are required to maintain the project:
Additional topics on Ansible, can be found in the online documentation.
The aemdesign-deploy project is implemented using the standard Ansible layout. Anyone familiar with Ansible should also be familiar with this implementation layout.
An implementation specific overview is provided in the following section.
Ansible Project Overview
The recommended operating system for the aemdesign-deploy project is either MacOS or a distribution of Linux such as Red Hat and Ubuntu.
|/||Playbooks for site, group and operations are located at the root of the project. This is discussed in detail in the Playbooks section.|
|/inventory||The inventory defines servers (defined as a SSH host). The servers provide the automation scripts with machine targets to deploy and configure services. In the aemdesign-deploy project, servers are typically Red Hat Enterprise Linux servers with a Docker service and Docker containers are specified in a group using an alias for the target machine. The inventories are organised into environments in a group var (group_vars/[environment_name]/vars.yml) which specifies environment specific configurations. See for Testing Environments for inventory details.|
|/roles||A role is a reusable unit of work that is composed of serial tasks. For example, a role can create a logical volume or start a web server in a Docker host.|
|/group_vars||There are two categories of group vars; application and environment. Typically, application group vars are used to override the default variables defined within roles. The environment group vars are used to define environment specific variables by overriding the group variables. This is represented as a hierarchy within the inventories as groups with the ‘:children’ suffix.|
|/host_vars||These are variables for servers that form the site and they are shared across all environments. This means that automation scripts apply the same host vars in each environment which ensures all environments are similar to each other.|
|/library||Custom modules developed for the project. Modules have been developed to orchestrate AEM and Docker.|
Table of variable descriptions.
|docker_image_tag||Common variable name used in roles for specifying which Docker image version to run.|
For each role, there is group variable that overrides the default variable defined in the role. Within each file, there is the variable *docker_image_tag *that can be updated to change the version of the Docker image to run.
|Role||Group Variable||Role / Files / Dockerfile|
Source Code Repositories
|aemdesign-parent/||root repo for devops script and automation|
|aemdesign-aem-author/||changes to authoring experience|
|aemdesign-aem-config/||configuration for author and publishers|
|aemdesign-aem-services/||services for author and publisher|
|aemdesign-aem-training/||training site content|
|aemdesign-deploy/||deploy project, contains all docker files|
|aemdesign-devbot/||used to control devops script remotely|
|aemdesign-docker/||parent docker project, outdated|
|aemdesign-prototype/||font-end prototype project|
|aemdesign-security/||security for hardening not Atomic hosts|
Adobe Experience Manager Project
Adobe Experience Manager (AEM) Project Source Code and Content Packages
AEM Project Sources
AEM Service Bundle
AEM Initial Content
AEM Project Sources
AEM Service Bundle
The AEM Service Bundle contains Java sources for OSGi services and components that extend or add functionality to AEM.
The AEM Configuration project contains configurations (NOTE: OSGi configuration https://docs.adobe.com/docs/en/aem/6-3/deploy/configuring/configuring-osgi.html) for AEM OSGi services as well as the OSGi services developed in the
For environment specific configurations, apply them with run modes to activate configurations. These environment run modes are configured:
These server run modes are configured:
OSGi Run modes
The path to the run mode configurations is located at:
These run modes are configured for the AEM servers and environments:
By default it will use the AEM server run mode, the OSGi service definition XMLs in config.author, **config.publisher and **config.author.processing. Each environment can override them by specifying a OSGi service definition XML in the corresponding environment run mode.
More information can be found in the online documentation Deploying and Maintaining, Configuring, Run Modes (NOTE: https://docs.adobe.com/docs/en/aem/6-3/deploy/configuring/configure-runmodes.html).
Environment Config Content
The AEM Configuration project produces one configuration file per environment. This is to configure AEM components that are not OSGi based. For example, the following AEM configurations:
These configuration packages are created:
AEM Initial Content
The AEM Initial Content project contains content that is required for a functioning site. It also enables transportable content between testing environments.
Virtual Machine Project
The aemdesign-vm project uses Packer by HashiCorp to automate machine image creation.
To learn more about Packer, refer to the online documentation (NOTE: https://www.packer.io/docs/index.html).
The project was built using VirtualBox Version 5.1.10. The binaries are available for download at: https://www.virtualbox.org/wiki/Downloads
Packer Project Overview
The project is designed to build on Centos and has built and provisioned Centos versions 7+ for deployment on private datacenter infrastructure.
While the datacenter servers are running on VMWare virtualisation, the local development image is built for VirtualBox.
Packer Project Structure
|/||Templates with build configuration for the machine image automation|
|http/||Path to the configuration files for the HTTP server during Machine Image creation. The Anaconda Kickstart scripts configures RHEL7 in an non-interactive environment (the template file’s builder variable boot_command is used to execute the script). Kickstart Syntax Reference|
|http/iso||Path to Red Hat Enterprise Linux 7 Full ISO for building the machine image|
|scripts/||Shell scripts executed as provisioners during the build|
|scripts/common||Scripts common to all machine image builds|
|scripts/devops||Scripts to install and configure devops services such as Docker|
|scripts/rhel||Scripts to configure Red Hat Enterprise Linux|
|settings/||Setting variable files to customise machine images. Overrides variables defined in the build templates|
In the aemdesign-vm project,
npm install && ./packer.io/install
The Packer command requires two json configuration files to build a machine image,
./bin/packer build -var-file=./settings/[variables].json [template_file].json
template_file* *is the configuration for the build
variables overrides the “variables” section in the template_file
The template_file* *build configuration files can be found in the project’s root path. The variables file overrides values defined in the template_file. This enables the customisation of images.
|centos-vbox.json||Builds a VM Machine Image, configures a NAT network interface and installs VM tools|
Machine Image Builds
Note: For best results please pass params to packer instead of using settings files, this will keep repo clean
Local Image Build
./bin/packer build -var-file=./settings/variables-online.json template-rhel-build-virtualbox-localdev.json
SIT Image Build
./bin/packer build -var-file=./settings/variables-online-sit.json template-rhel-build-virtualbox-server.json
Staging Image Build
./bin/packer build -var-file=./settings/variables-online-stage.json ./templates/centos-vbox.json
Production Image Build
./bin/packer build -var-file=./settings/variables-online-prod.json ./templates/centos-vbox.json
Updating a Machine Image
Note: Packer will download and cache ISO file first time, follow this if you want manual control over this process
Download a Centos ISO
Copy it to ./*http/iso/ *in the aemdesign-vm project.
Update the iso_url* variable *to path of the ISO:
3.1 from “iso_url”: “http://ftp.swin.edu.au/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1708.iso”,
3.2. to “iso_url”: “http/iso/your-iso-name.iso”
Update the iso_checksum* *variables to match the ISO:
4.1. from “iso_checksum”: “ec7500d4b006702af6af023b1f8f1b890b6c7ee54400bb98cef968b883cd6546”
4.2. to “iso_checksum”: “your-iso-sha256-checksum”