Why docker does not help you with AEM

[#1]

In my blog post I explain why docker rarely brings benefit in AEM environments. The single usecase I see as of today is for running short-lived test instances, where you validate feature-branches. But anything beyond DEV environment it does not bring any value.

AEM and docker – a question of state | Things on a content management system

[#2]

Thanks for sharing this with the community but it is a hard pill to swallow for team working on testing side of AEM.

~kautuk

[#3]

Totally agree, it is a conceptual issue here.

[#4]

Thanks for sharing mate. I can show you how to do AEM in Docker properly so that it work as it meant to, in all scenarios especially Prod. From your experience point of view I would have to say that Volumes should be the least of your concerns, if a concern at all.

[#5]

I would not worry about it mate, its just a discussion.

[#6]

Hi,

ok, challenge accepted. Imagine this case:

* You golive with AEM on docker and your application version 1.

* Your editors start to add and modify content

* After some weeks you want to deploy application version 1.1

How do you implement this 3rd step of the deployment of application version 1.1? How can docker help you there?

[#7]

The actual challange if any that I propose to you is to understand this notion:

"What is good enough in Prod good Enough in Dev"

And its fundemental impact though practices on efficiency and how DevOps space closing the loops on all the old ways of solving problems that do not need to be solved. After all its 2017 not 1999 oldshcool thinking don't cut it anymore. This would be worthwhile endevour to explore. This does go to the core of developer mindset, whereby a developer thinks "hey I can do X in dev and its cool, but they do Y in prod", usualy Prod is not their problem so anything goes on Dev side. And if you accepts this challange though the journey you will be able to counter argue your own ideas you pose now.

Back to your questions

How do you implement this 3rd step of the deployment of application version 1.1?

- You just deploy the new package to running container using Package Manager, package are not part of your Docker Image so nothing to worry about here.

How can docker help you there?

- its hosts your running AEM instance, you can replicate exact (not same, actually exact) instance in another environment and test installation of your new App Package and see if it works.

I think these questions come from place of understanding of how Docker should be used and how you are using Docker and practices that should be used with it. I think you might be thinking about baking you Application Package into Docker image... is this what you mean?

As far as Docker concerned I would need to point out that Docker on its own does not do anything, but provide an opportunity to change the way things are done. Typically Docker would be part of a suite of tools that will bring an unparallel benefit to all practices for managing Prod and other envrionments. The list of benefits would by far out weigh any percived gaps.

Saying all this here is a very very high level DevOps practice around managing an application in Prod.

1. So you should be writing Docker images specific for particular version of AEM, chain a couple of images with diffrent concerns.

2. Then once you have started the container and tested everything is good, your provision Packages you belive you need as a Provision step.

3. Then once you have tested that package you installed are good, you install your Application Verison, and do a test again.

4. Then using best DevOps practice (not manual hacks) you deploy specific tested version of your Applciation to that Container using package manager.

5. Then you open floodgates of users at it.

All of this is not posible with Docker alone but there is no point saying Docker without meaning DevOps these days, as its basically means that lots of stuff is still manual and that probably cause to work on.

Let me know what you think.

[#8]

The problem I have is the location of the repository itself. Where do you actually host the repository? When it lives totally inside the container, all changes to it are lost as soon as I stop the container. This is not what I want. In PROD and also some lower environments the changes must be persisted over restarts and application deployments.

And if I place the repository outside of the container, I still need to deploy/install new application versions into the repository. So there is still a deployment (and subsequent validation phase) in production.

When you work with docker, you test your docker images in lower environments and when done, you promote them into production. You just start the images. That's at least how I understood the docker philosophy.

At the moment I don't care about development or testing processes or how it can improve my processes. I can already imagine how I could make use of it if I solve the above mentioned problem.

[#9]

AEM instance content should be on a volume or in S3 Bucket. This will allow you what you wanted to do.

[#10]

Hi,

Ok, so it looks to me, that you don't have an idea how Docker can help me. Putting the repository onto an host volumen or into S3 (which is btw technically not possible, and just putting the DS into S3 doesn't change anything regarding this problem) will not solve the problem.

Because the problem is: Content and application are a single entity, which cannot be split; at least with the current AEM versions. And Docker cannot overcome this limitation.

Jörg

[#11]

Works as advertised for me...

[#12]

My requirements are:

1) I have a repository with an application and content.

2) The content inside this repository changes without me having any chance to influence it.

3) I must never loose any of this content.

4) At a point I need to deploy a new application version to this repository.

Please describe how you would get a new application version to this repository without

a) deploying the application to this instance

b) any subsequent validation of the deployment.

These limitations a) and b) are the ones which cause downtimes in production; people claim that they can overcome these limitations by using docker, but I haven't seen any approach which works with the constraints 1) to 4).

[#13]

To meet A and B which protects Prod Instance from Un-Tested Changed. You would need to clone your Docker Container, I would recommend having File Store be located on Volume so that you can mount it in Readonly to new Container.

To do this:

1. Create a Docker image

2. Run is a container and map repository to a volume

3. While running the container do a Commit of the container to new Image

4. Run your new image with a maped volume with readonly

5. Test you install etc .

[#14]

1) You cannot mount the repo from a read-only volume; the application always need write-access to all TarMK files.

2) You still need to deploy your application into the repository using packagemanager and test it.

To come back to the original post: I don't see the benefit of using docker with AEM.

[#15]

Ok then you clone your volume as well.

This would be same or even more complicated issue doing it Manually.

At least if you run Docker image without Volume you can Just commit it and spin it up and test it, then do same to Original running image. If you are doing HA and HR you would have Tiplicate of everything so having a another full copy as Shadow for Updates Testing is not going to break the bank.

You original point was about "Why docker does not help you with AEM" which it does, but not is a particular closed logic case (Chicken and egg)... I get where you are going with this but no real show stopper uncovered thus far... still beats rolling VM's or Manaully hacking with Boxes...

[#16]

.

[#17]

Well, there is a little exception there (OSGi bundle can be split/replaced from existing content and nothing bad is happening - assuming it is a valid and working replacement), apart from that I agree with that statement.

However, how are you handling existing deployment anyway? I think it is installing a new package to the existing repository. How its different from using Docker to run instance (without wiping data out of course) and installing new application package on prod as usual)? There also might be a content export made if needed (although I presume its not). I don't know if Docker is useful or not in context of using AEM, just curious about that part

[#18]

Hi,

Thanks for this article and also for all the useful comments. What do you all think about the new feature of oak, composite node store? Can this new feature make AEM prod deployments more "Docker friendly"?

[#19]

The composite node store will definitly be a game changer regarding the use of AEM in containers.

Jörg

[#20]

What issues do you currently experience with AEM in Docker?

[#21]

I believe Docker will shine in AEM if we were able to host /apps, /libs and /content externally and plug them in to AEM. Currently, if you work with a TarMK and want to have another docker container with a newer version of AEM installed, you'd have to run a new instance of your dockerized AEM and install content packages on it to make sure that you're not losing your content every time you perform an upgrade.