Production Replication

“Production Replication” is a process that allows the Production stack’s database and media (on the Production cluster) to be replicated to another stack. The target stack can be on the Production or Development cluster.

This process is used to instantiate the Staging Stack (which runs in the Production Cluster) using a copy of the the current Production Database and Media directory. The use fo this process allows the Staging stack to be used for pre-production testing of features on a near-identical stack prior to tagging the stack’s repository for automatic deployment to Production.

As well as being used for the Staging Stack you can production data to prime a developer stack (on the Developer Cluster). This provides a developer to test their code on stack that’s nearly identical to the Production stack.

Replicating to the Staging stack

The staging stack can be instantiated from the current [1] Production data using a Workflow Template on the production AWX server.

  • Staging Fragalysis Stack (Production Replica) [FULL]

This workflow executes a number of underlying Job Templates that run in the staging-stack namespace to: -

  1. Shuts down the Staging Stack Pods and can remove the media volume (if the Ansible stack_shutdown_remove_media_volume is yes)

  2. Recover the production database content to the database server (from an NFS backup)

  3. Instantiate a new stack

  4. Recover the stack Media content (from an NFS backup)

The user is expected to provide the stack image tag in the workflow’s EXTRA VARIABLES parameter section. The most important variable is stack_image_tag, which sets the image tag for the deployed stack.

Warning

You MUST set the stack_image_tag to the same value used in the production stack prior to replicating the production data as the staging stack’s database model must be the same as that used in production. After recovery you can deploy a new stack but during replication it must be the same.

Note

The time it take for the stack to become usable will depend on the database and media content. For a new stack the media directory is the most time-consuming element and (at the time of writing) takes more than 1 hour 15 minutes to complete. Subsequent start times are significantly reduced (typically around 8 to 10 minutes) as the media directory is preserved between stack instances.

For database replications only there is a shorter Workflow Template that does not Recover the stack’s media directory: -

  • Staging Fragalysis Stack (Production Replica) [JUST DB]

A Job Template also exists to shutdown and wipe the Staging stack. The wipe template removes the stack, database and the database volume: -

  1. Shuts down the Staging Stack Pods and can remove the media volume (if the Ansible stack_shutdown_remove_media_volume is yes)

  2. Remove the Database Pod and database volume (if the Ansible stack_shutdown_remove_database_volume is yes)

  • Staging Fragalysis Stack [WIPE]

Replication to a Developer stack

Developers are able to start their stacks (on the Development cluster) using the same process described above but this requires them to manage their own Workflow Template.

An example pair of Templates can be found on the AWX developer server: -

  • Production Replica (Alan) [START]

Footnotes