Using this for production apps?

[sclorg]

Using this for production apps?

[omron93]

do you guys see any issues with this template being used for production apps?

@alikhajeh1 Please, what template are you referring?

So my concern isn't high-availability, but a pod restart or an unclean shutdown causing data corruption/loss. However, I tested this and the default behaviour is for MongoDB to start in recovery mode when it detects this.

Journal is enabled by default for this image. So there should be no problem.

As a good practice, we would obviously also be having a backup strategy that we could use to recover following issues.

@bparees How to do backups in OpenShift please?

Upgrades: It seems currently, users could update the image referenced in the deploymentconfig and click on deploy... e.g. when you add support for 3.4, would that be all we'd need to do to upgrade?

For MongoDB upgrades upstream releases document with things to check and fix before upgrade. This applies to images too. (for example https://docs.mongodb.com/manual/release-notes/3.2-compatibility/, https://docs.mongodb.com/manual/release-notes/3.4-compatibility/)

Also testing upgrade in staging environment or data backup is suggested.

[bparees]

@bparees How to do backups in OpenShift please?

oc rsh into the mongo container, use the mongo tools to create the backup and then oc rsync to pull the backup archive off the pod to your backup location.

[alikhajeh1]

@alikhajeh1 Please, what template are you referring?

Thanks for the detailed answer guys, I was referring to this template, which links to this repo...

Re backups, yep, that's exactly what we planned to do.

[BorntraegerMarc]

If I understood this comment right then MongoDB support has been removed from Fedora. So these images shouldn't be used in production, to my understanding