Level 2

crx2oak for Blue–Green deployment

Forum|Forum|8 years ago
August 4, 2017
3 replies
4676 views

I've seen some threads discussing the use of crx2oak for Blue–Green deployment, which sounds quite interesting, as one of the challenges of applying this deployment pattern with AEM is the question of how to handle syncing repositories easily.
That said, other people recommend only running the repo migration offline (slide 9).
The official documentation (Using the CRX2Oak Migration Tool) isn't conclusive either way — not even mentioning offline or online migrations, let alone that one way or the other is recommended (or prohibited).

So, is the use of crx2oak for a migration against a running instance of AEM a supported use-case? If so,

are there any limitations against running it in this way (e.g. speed)?
If there are limiting factors, does it have an impact if both instances are offline (versus one online and one offline).

Any info would be appreciated, and links to canonical documentation would be great if they exist.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

smacdonald2008

Level 10

The Eng teams talks about the crx2oak tool in this GEMS session -- Deep dive into AEM upgrade process

another-daveAuthor

Level 2

Thanks, though from the slides & description (haven't had a chance to check video yet), it seems to be related to upgrades, rather than deployments, is that right? — Is deployment a supported use-case for crx2oak, or is it only for upgrades?

joerghoh

Adobe Employee

Hi,

The blue-green deployment pattern post by Martin Fowler simply forgot a single item: What happens when blue is under constant change by its users while you prepare green?

This is the problem with AEM, as your blue publishs are under constant change by authoring users. Oh, and don't forget that you have your single point of truth as well, the authoring instance. There you cannot apply this pattern at all, if you don't want to have a planned downtime for the time of the deployment.

My conclusion: You cannot apply the classical blue-green approach.

I normally do deployments in a way, that I use planned service downtimes on authoring, but none on publish.

initiate service downtime on author
deploy author
remove 1st half of the publishing instances from loadbalancer, so that the 2nd half is serving all the requests.
deploy 1st half of the publish instances
switch loadbalancer, so the 1st half now servces all the requests
deploy 2nd half
bring all back online

This is a modified version of the blue-green approach: I don't have a standby instance which just changes roles with the production instance. But I have enough redundancy in the frontend that I am able to perform the deployment without downtime.

Jörg

another-daveAuthor

Level 2

Thanks Jörg,

what I meant by Blue-Green in this case was to have a 'Blue' and a 'Green' author instance, one which is the live Production instance, and one acting as Pre-Prod. For example:

Deploy new release to non-live servers (green), both author and publish.
Enforce a content freeze on live author (blue).
Run a synchronisation of content between live & non-live servers.
Put green servers live, and set blue to non-live
Lift the content freeze for authors.

In theory, this set-up is quite feasible, even with a changing author, if we can quickly sync the latest changes from Blue back to Green — a minimal content freeze can be tolerable, especially if outside of normal business hours.

I'm still not clear as to whether this is a supported use-case of the tooling though?

joerghoh

Adobe Employee

Hi,

the approach sounds good, but the problem is indeed step 3. And unless you know a method, which can achieve this really quickly (that means 2 min at max) in 99% of all cases, I would doubt that this is doable.

Fast synchronization between AEM instances (especially if 1 instance is weeks behind) is hard; especially problematic is the versioning stuff, because the API prevents it to create the versioning nodes directly via JCR APi (you have to use the versioning API for it).

So yes, in theory it's possible. But I haven't seen it implemented yet :-)

Jörg