|
|
|
|
|
by e1g
3519 days ago
|
|
Container folks currently advise to not put the database into a container unless you really really really know the internals of both. Even Kelsey Hightower stressed this in a talk - "if you want to keep your job, keep databases out of containers". ReadMe had no prior Docker experience, and they started by putting Mongo (which is complex to manage as is) into a container. This would make me uneasy. Does Replicated assist with this database/persistence layer? Perhaps by helping you to spin up the DB as a separate VM on the clients' side? |
|
Replicated allows for the end customer to choose if they want to run the containerized version of the database, or provide their own instance of it (not in a container) and simply provide a connection string so the application can use that instance. Generally this is exposed as a checkbox on the settings page, and doesn't require a lot of configuration.
If the end customer decides to install with the containerized version of the database, they can choose to run the database container on a specific instance (or instances) and control the host path of the volume mount(s). The idea here is that they will store the data on an EBS volume, network attached storage etc.
We also have a feature that allows for snapshots and restores to help in the scenario where the database was store on the local instance and there was a hardware failure or corruption.
These features work out of the box, without a lot of effort from the software vendor to configure.