production-level Docker installation

[kdarras]

We need to make it possible to use a practical and secure Docker installation for production purposes on VMs.

@LiuDilongNJ wrote on the subject:

The project we have on GitHub is designed and configured specifically for testing purposes. As such, it is not production-ready for several reasons:

Security Concerns
The current setup is not secured for Docker deployment in production environments. Additional measures would be needed to harden the container, including non-root user configurations, network security, and runtime restrictions.

Performance Optimization
The configuration is not tuned for container performance. On a production server with multiple projects running, Docker containers may compete for shared resources, potentially impacting the performance of other applications.

Persistence and Recovery
In a virtual machine (VM), data is self-contained within the VM, making it easier to back up and restore as a single entity. If the VM is damaged, restoring it from a snapshot is straightforward.
In contrast, Docker requires external storage for data persistence, and improper configurations could risk data loss or affect other server functions.

Complexity in Configuration
While Docker can be used in production, it demands careful planning and configuration. This includes managing volumes for persistence, securing containers, and monitoring resource usage.
In comparison, virtual machines are often simpler and quicker to configure for production scenarios, offering strong isolation and pre-established tools for backup and recovery.

In summary, while Docker is a viable option for production with the right expertise and adjustments, the GitHub project in its current state is not suitable for direct production use. Virtual machines provide a more straightforward and robust alternative for deploying our project in production environments.

[kdarras]

Sébastien Boutelier also noted:

• anonymous volumes are used for the mySQL database at the moment - this should be a quick fix to rename them

ecosound@docker-user:~/ecoSound-web$ docker volume ls
DRIVER VOLUME NAME
local 2b8c056cf2b901097e731c843c8c0719dc03a0d9fcee9cf091eb642bab857327
local 3c2c7f9ac523d3db97d275b92824c3fa00ce72dac52fc191bbab3d558f8f56f6
local 5df50e63fb28e364420d91c397c7e1de143440992a38c14657e1e05eee5612a1
local 6eb49684461b1852f134e1b6ba1f23f939d19b2fe25c97664da26df9d3d0f0d5
local 7bdc0635ddd2a1377e71694c76f3641b1b4662e375644711cbf0ef4bde097766
local 7e6dfcaafa3682a0ecfaf6c024f85484c630b2795a9aedffa027c3317edc8da1
local 47575a0a4a3b867e3aab05db1d578a72761b914fb6285c81e28c98e1e56514b7
local ac0b4698a1a5a9f6e9ad59ed4d46107a0a8c00f6c5e982e1936fb1da66fbf1a4
local ecosound-web_biosounds-vendor
local ef746f5191a7ed43fa628ef2bd36c7085bc8b6258efc3444164ae524fe44fdb8
local f39072e78637a09def5bdd5ec28f114e922b8f4762891b85d9d91459a9c713ce

• containers do not restart after a server reboot. Probably a "restart: always" is missing in the service (not tested)

[kdarras]

Mario Fischer noted (translated):

The ecoSound-web data (sound files and database) have to be stored outside of the containers, and a connection is established from the container to the database. Files can be mapped in the container to find them inside the file hierarchy inside the container although they are stored on the host. The containers would in that sense be totally independent as they would only "do the computation". Data inside are not persistent because they are deleted when the containers are killed.