Improve the docker build to use the release configuration and allow splitting off the database/web front end to allow scaling

[SeanFarrow]

Having just looked at the dockerfile, I wondered whether there was a reason why it built BaGet using the debug configuration.

Also, is there a reason tests aren't run during build?

Finally, it would be nice to split the web frontend and database in to separate containers using docker compose for scalability.
Happy to submit pr's to do this.

[loic-sharma]

Hey there! BaGet's Docker integration could definitely use some love. BaGet's Docker image is pretty much unusable for production environments.

... it would be nice to split the web frontend and database in to separate containers using docker compose for scalability.

This would be awesome.

... why it built BaGet using the debug configuration.

BaGet creates its database at startup if it is run debug mode (see this). Today, the Docker image uses this feature to create its database. This is an ugly hack that should be removed. Instead, the database should be created when the container is created.

Also, is there a reason tests aren't run during build?

The tests are run on each commit by the Travis CI configuration. Is the idea to run the tests while creating the docker image? If so, what are the added benefits to doing this?

Happy to submit pr's to do this.

That'd be great! I'm no Docker expert and I'd appreciate any help 😄

[SeanFarrow]

@loic-sharma,

Ok, what database do we want to use in development, I'm assuming people will be running on .net core, therefore I'd suggest either PostGres or sql server on Linux, with a preference to the former!
We should probably disable database creation and have an SQL script created during build using the .net cli.

The idea is definitely to run tests during Docke image creation, it means hat local and CI ae in step with each other--currently you are assuming the tests have been run locally, which in my view is a bad idea!

Once we've decided on a database, I'll start creating docker files. We will have 3 containers locally, one for the database, one for the API and one for the frontend.

[loic-sharma]

Ok, what database do we want to use in development

I'd suggest either PostGres or sql server on Linux, with a preference to the former!

BaGet has been ported to SQL Server and SQLite, so we should stick to those. For now, I recommend using SQLite for development and SQL Server for production. I'm definitely open to porting BaGet to more database engines though! 😄

We should probably disable database creation and have an SQL script created during build using the .net cli.

You can create the database manually by following these steps:

1. Install .NET Core
2. Navigate to src\BaGet
3. Update appsettings.json with your desired database configuration
4. Run dotnet ef database update

[tomzo]

I will soon create a docker image which uses published release configuration. The backend database type will be indicated by environment variable. By default it will be sqlite.
If database does not exist in expected location then it will be created on container start.
Then I will setup e2e tests with such image.
Later we can extend those to include other databases, as long as they can run in docker.