Nopcommerce: Store datasettings parameters as environment variables

[RomanovM]

nopCommerce version: 4.20

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.

Perhaps, store in the appsettings.json file. Add some new setting

Source: https://www.nopcommerce.com/boards/t/72758/making-nopcommerce-more-docker-friendly.aspx

See also: https://github.com/nopSolutions/nopCommerce/issues/4164, https://github.com/nopSolutions/nopCommerce/issues/2494

[dpoetzsch]

The possibility to set basic settings such as database connection string via docker environment variables would be very interesting to us as well.

[Meowzz95]

This is definitely an issue for docker deployment.

[Shane32]

This is an important feature to me, and I made a patch - see #4583 .

This is useful for IIS, Azure, docker, and continuous deployment testing scenarios. It really helps to (1) ensure that data settings for testing do not get pushed to production (2) production sites always use data settings for production (3) production passwords are not accidentally pushed into a repository.

[Shane32]

I also changed a some code to pull the installedplugins.json from the configured database (and save to there). Since the nop database depends on the plugins being loaded, I wrote some ADO.Net code to pull and save the plugins list to the Settings table of the database, bypassing Entity Framework (skipping this of course if the database has not been configured). This is the other missing piece of the puzzle to allow you to publish without preserving the app_data folder. If anyone wants it, I'd be happy to share this code or issue a pull request for it.

[AndreiMaz]

also see https://github.com/nopSolutions/nopCommerce/issues/4164

[justinjstark]

To add to this, here are some common deployment strategies and how we would want to configure the connection string:

Docker: Environment variables
Running locally: appsettings.json (I don't want my developers to have to configure env variables)
Octopus deploy: appsettings.json (Octopus has built-in support for doing appsettings value replacements during deploy)
Azure App Service: Environment-level connection strings can be set in the app service environment configuration. These are read from the application as if they were stored inside the appsettings.json ConnectionStrings section.

IMO if we take the strategy of putting the connection string in appsettings.json under the ConnectionStrings section and also allowed for overwriting the connection string via environment variable, it would follow the .NET Core appsettings connection string standard and also handle 99% of deployment scenarios. If we use appsettings this way, incorporating environment variables is as simple as

c# ConfigurationBuilder() .AddJsonFile("appsettings.json") .AddEnvironmentVariables();

[ryanbarlow1]

The plugins.json file will have a similar issue as dataSettings.json for docker images. Would the solution be the same approach for both?

[nicklundin08]

The plugins.json file will have a similar issue as dataSettings.json for docker images. Would the solution be the same approach for both?

Is there a reason that the data in plugin.json cant come from the db?

[Shane32]

Is there a reason that the data in plugin.json cant come from the db?

No; that’s how I configured my installation. It’s ridiculously easy with linq2db as the database provider. Besides, as the database structure is based on the installed plugins, it only makes sense.