You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that the author has previously expressed multiple times that Docker deployment will not be supported (because the current deployment method is already simple enough).
However, I still want to explain from a user's perspective why we hope to have Docker support: One GoatCounter is indeed very simple, but when you have 10-20 GoatCounters with different installation methods, data storage, update methods, and backup methods, it’s not so simple anymore.
At this point, the benefits of using Docker Compose become apparent: consistency in data storage and program management. Let me share my example:
1、All my projects are deployed using Docker and are placed in one directory:
Therefore, all data files are mapped to container-data.
The update process is unified; I just need to run docker compose pull.
It is convenient for backups; I automatically back up the project directory daily. In case of an anomaly or failure, I can restore the production environment on any machine within 5 minutes using docker compose up.
2、Purity: This approach leads to a "clean" file and data environment. Whether it’s installation or uninstallation, it can be done "gracefully."
3、Security habits: Sometimes, applications or installation scripts from unknown sources can pose security risks. The Docker environment is secure in terms of both network usage and the file system.
I’m writing this mainly to explain the reasoning behind this request, nothing more.
The text was updated successfully, but these errors were encountered:
Have you looked at using override in systemd? See https://askubuntu.com/a/659268/1657026.
systemd supports both cgroups and namespace v2 to lock down the process' access.
I understand that the author has previously expressed multiple times that Docker deployment will not be supported (because the current deployment method is already simple enough).
However, I still want to explain from a user's perspective why we hope to have Docker support: One GoatCounter is indeed very simple, but when you have 10-20 GoatCounters with different installation methods, data storage, update methods, and backup methods, it’s not so simple anymore.
At this point, the benefits of using Docker Compose become apparent: consistency in data storage and program management. Let me share my example:
1、All my projects are deployed using Docker and are placed in one directory:
2、Purity: This approach leads to a "clean" file and data environment. Whether it’s installation or uninstallation, it can be done "gracefully."
3、Security habits: Sometimes, applications or installation scripts from unknown sources can pose security risks. The Docker environment is secure in terms of both network usage and the file system.
I’m writing this mainly to explain the reasoning behind this request, nothing more.
The text was updated successfully, but these errors were encountered: