Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

correct method to clone the AEM environment

Avatar

Level 1

if i am cloning my env which is whole stack(author,publishers and dispatchers)

what are thing i need to consider after cloning to make it work. 

What are the changes needed in the new one ,

like if config which and what

if uri which one?

1 Accepted Solution

Avatar

Correct answer by
Level 10

@rohan07,

Disclaimer: my credentials are as a developer and not so much on the infrastructure/networking side of AEM but perhaps my input will still be useful  I'm assuming that you have something like 3 virtual machines:

  • dev.aem.author
  • dev.aem.publisher
  • dev.aem.dispatcher

And you want to replicate this for another environment (eg. UAT). If however you only have 1 machine with all 3 instances installed on it, it doesn't make a big difference.

The first thing is to decide how to get the new servers and instances. The first question is then: can you virtualise it? At my job we unfortunately have AEM instances installed directly on our VMs, rather than using containers which would make the creation of new environments easier (its a political thing). If you are in the same boat as me, then you have 3 options:

  1. If you want to keep all the OS config (ie: java config, httpd/apache2 config, ssl libraries, etc), you can simply clone the VMs (save an image and spin it up under a different hostname)
  2. If you can't do that, then create a new VM and clone the AEM instance by simply copy-pasting the install folder from one machine to the other.
  3. If you can't do that either, then you'll need to create a new VM and do a new installation of the 2 AEM instances and the Dispatcher from scratch which is a pain in the... 

Once you have your new machine(s), there is some critical config to change (this is just what comes to my mind, but there might be more):

  1. Assuming you want to use mutual SSL between instances and HTTPS to access the UI from your development and author machines, you will need to either implement (if you haven't already) or adapt the configuration. This will involve the creation of a new private key and certificate for each VM. See this article for SSL on AEM and this article for SSL on Dispatcher
  2. If you are using the ACS site-map generator, you will need to change the config to fir your new VM's DNS hostname.
  3. You'll have to update the Apache .conf and Dispatcher .any files to reflect the change in the DNS hostname too.
  4. This is more specific to your work environment, but when I created a new environnement I had to ask for a bunch of URLs and IPs to be whitelisted because our network also includes firewalls, proxies, etc.
  5. If you are creating a non-development environment, there are also some AEM and project-specific things that may need to change.
    1. For example, you may want to activate the code minifaction feature using the Adobe Granite HTML Library Manager (com.adobe.granite.ui.clientlibs.impl.HtmlLibraryManagerImpl) config. See documentation on changing your minification engine here.
    2. If you are using webpack with source-mapping to hello you debug your front-end code during development, you'll want to avoid that in higher environments. This will require you to change your project build config.
  6. I don't know if you already have a build pipeline with automatic deployments but if so, you'll have to configure that to point to your new environment too
  7. It's always a good idea to have a quick look at the official AEM security checklists whenever you set up an instance, just to make sure you haven't missed something. You can find the AEM one here and Dipatcher one here.

That's all that's popping to my mind on this Sunday morning but if I have any Eureka moments later I'll add more Perhaps someone with more infrastructure/networking/installation experience can add to the list too 

View solution in original post

3 Replies

Avatar

Correct answer by
Level 10

@rohan07,

Disclaimer: my credentials are as a developer and not so much on the infrastructure/networking side of AEM but perhaps my input will still be useful  I'm assuming that you have something like 3 virtual machines:

  • dev.aem.author
  • dev.aem.publisher
  • dev.aem.dispatcher

And you want to replicate this for another environment (eg. UAT). If however you only have 1 machine with all 3 instances installed on it, it doesn't make a big difference.

The first thing is to decide how to get the new servers and instances. The first question is then: can you virtualise it? At my job we unfortunately have AEM instances installed directly on our VMs, rather than using containers which would make the creation of new environments easier (its a political thing). If you are in the same boat as me, then you have 3 options:

  1. If you want to keep all the OS config (ie: java config, httpd/apache2 config, ssl libraries, etc), you can simply clone the VMs (save an image and spin it up under a different hostname)
  2. If you can't do that, then create a new VM and clone the AEM instance by simply copy-pasting the install folder from one machine to the other.
  3. If you can't do that either, then you'll need to create a new VM and do a new installation of the 2 AEM instances and the Dispatcher from scratch which is a pain in the... 

Once you have your new machine(s), there is some critical config to change (this is just what comes to my mind, but there might be more):

  1. Assuming you want to use mutual SSL between instances and HTTPS to access the UI from your development and author machines, you will need to either implement (if you haven't already) or adapt the configuration. This will involve the creation of a new private key and certificate for each VM. See this article for SSL on AEM and this article for SSL on Dispatcher
  2. If you are using the ACS site-map generator, you will need to change the config to fir your new VM's DNS hostname.
  3. You'll have to update the Apache .conf and Dispatcher .any files to reflect the change in the DNS hostname too.
  4. This is more specific to your work environment, but when I created a new environnement I had to ask for a bunch of URLs and IPs to be whitelisted because our network also includes firewalls, proxies, etc.
  5. If you are creating a non-development environment, there are also some AEM and project-specific things that may need to change.
    1. For example, you may want to activate the code minifaction feature using the Adobe Granite HTML Library Manager (com.adobe.granite.ui.clientlibs.impl.HtmlLibraryManagerImpl) config. See documentation on changing your minification engine here.
    2. If you are using webpack with source-mapping to hello you debug your front-end code during development, you'll want to avoid that in higher environments. This will require you to change your project build config.
  6. I don't know if you already have a build pipeline with automatic deployments but if so, you'll have to configure that to point to your new environment too
  7. It's always a good idea to have a quick look at the official AEM security checklists whenever you set up an instance, just to make sure you haven't missed something. You can find the AEM one here and Dipatcher one here.

That's all that's popping to my mind on this Sunday morning but if I have any Eureka moments later I'll add more Perhaps someone with more infrastructure/networking/installation experience can add to the list too 

Avatar

Employee Advisor

The other 2 posts are already very valuable regarding the doing, but I want to raise some other points as well.

When cloning instances to a different environment, you have to care of the environment specific settings, which have to be different from environment to environment.

For example configured hostnames (for whatever reason) are likely to be different from environment to environment. Then there's the question if you can clone user information as well (assuming that on lower environments more persons need to have access to the "admin" user, and having this will allow these users to get access of the password hash of the cloned users as well, and that hash is identical to the password hash in production!). Sometimes you have pay special attention to content as well (if you have embargoed content which is produced on PROD and which cannot be moved to STAGE yet).

 

If you have figured out the proper technical processes to clone such an environment, you have to implement all the business and security restrictions on top. And from my experience these are harder to identify, to build and to execute than a simple technical cloning