Hello all,
As I've been working on upgrading to a Docker-containerized instance of nopCommerce 4.2, I've seen a few pain points that I was wanting to bring up. It seems there are a few components in nopCommerce 4.2 that were built to run on IIS rather than a container:
1. dataSettings.json
2. plugins.json
3. The product images upload folder
The dataSettings.json file is hard coded in the App_Data folder. If a Docker image is created from this, then any implementation of that Docker image will run against that hard-coded database. Is there a way to parameterize this, to reference an environment variable instead? Then the same Docker container can be used against many different nopCommerce store instances.
The reason why there's a plugins.json is confusing to me since it's just a list of active plugins and lists of plugins that should be installed or uninstalled. Couldn't this be replaced as an entity in the database?
Product images can be uploaded anytime, not initially before the website is brought live. If the site is being run in a Docker container, the image will only be uploaded to the container, and it will not persist after the container is terminated. Additionally, if the site is being run in Docker Swarm, the image won't be available to other nodes in the Swarm. Instead, should product images be uploaded into a file table in the database, or is there another way that this should be handled?
What's the best way to deal with these issues? Should parts of the site be rearchitected? If the solution is run as a Docker container, should nopCommerce require persistent data volumes as a part of the Dockerfile? I look forward to hearing your thoughts about this!
Making nopCommerce more Docker-friendly
Team Member
- 879
- 9286
- 1/11/2016
Hi.
ryanbarlow wrote:
The dataSettings.json file is hard coded in the App_Data folder. If a Docker image is created from this, then any implementation of that Docker image will run against that hard-coded database. Is there a way to parameterize this, to reference an environment variable instead? Then the same Docker container can be used against many different nopCommerce store instances.
I just created a work item for this.
ryanbarlow wrote:
The reason why there's a plugins.json is confusing to me since it's just a list of active plugins and lists of plugins that should be installed or uninstalled. Couldn't this be replaced as an entity in the database?
The reason for this approach is that plugins are loaded (and accordingly you need to know the list of installed plugins) before the database is initialized.
ryanbarlow wrote:
Product images can be uploaded anytime, not initially before the website is brought live. If the site is being run in a Docker container, the image will only be uploaded to the container, and it will not persist after the container is terminated. Additionally, if the site is being run in Docker Swarm, the image won't be available to other nodes in the Swarm. Instead, should product images be uploaded into a file table in the database, or is there another way that this should be handled?
Please see here.
ryanbarlow wrote:
The dataSettings.json file is hard coded in the App_Data folder. If a Docker image is created from this, then any implementation of that Docker image will run against that hard-coded database. Is there a way to parameterize this, to reference an environment variable instead? Then the same Docker container can be used against many different nopCommerce store instances.
I just created a work item for this.
ryanbarlow wrote:
The reason why there's a plugins.json is confusing to me since it's just a list of active plugins and lists of plugins that should be installed or uninstalled. Couldn't this be replaced as an entity in the database?
The reason for this approach is that plugins are loaded (and accordingly you need to know the list of installed plugins) before the database is initialized.
ryanbarlow wrote:
Product images can be uploaded anytime, not initially before the website is brought live. If the site is being run in a Docker container, the image will only be uploaded to the container, and it will not persist after the container is terminated. Additionally, if the site is being run in Docker Swarm, the image won't be available to other nodes in the Swarm. Instead, should product images be uploaded into a file table in the database, or is there another way that this should be handled?
Please see here.