Mount volume(s) for config, userfiles, log

[tet3]

Suggest closing Leantime/docker-leantime#8, where the original issue seems to be fixed.

But you do need README and docker-compose.yml to reflect setting up volume(s) for files that need to be accessed outside the container or will change but should survive an image rebuild. Putting the whole of \var\www\html per @marcelfolaron 's last comment on 8 isn't right, because that's got src, vendor and other stuff that should definitely be fully inside the container fs. But volumes for config, userfiles (why are there both /var/www/html/userfiles and /var/www/html/public/userfiles?) and /resources/logs are needed. Is there anything else that changes during normal running, that couldn't be deleted and recreated on a version upgrade?

[marcelfolaron]

Thanks, you're right. We should only consider the userfiles and logs. The two userfiles folders are an unfortunate side effect of an architectural decision. Company logos are stored public/userfiles, they need to be available when users aren't logged in. There is a chance that we'll use this folder in the future for other publicly available files. Everything else /userfiles is protected by the login class.

So we'd have userfiles/ public/userfiles resources/logs config/

There is nothing else that changes during normal operation.

[cesalo]

Just to clarify this .. the recommended docker command should be then something like:

docker run -d -p 80:80 --network leantime-net \
-e LEAN_DB_HOST=mysql_leantime \
-e LEAN_DB_USER=admin \
-e LEAN_DB_PASSWORD=321.qwerty \
-e LEAN_DB_DATABASE=leantime \
-v /local_dir/userfiles:/userfiles
-v /local_dir/public/userfiles:/public/userfiles
-v /local_dir/logs:/resources/logs
-v /local_dir/config:/config
--name leantime leantime/leantime:latest

@marcelfolaron ^

[tet3]

I'd go with docker-managed volumes rather than bind mounts:

-v lt_userfiles:/userfiles
-v lt_pub_userfiles:/public/userfiles
-v lt_logs:/resources/logs
-v lt_config:/config

Could also use what the docker docs call "the more explicit and verbose" --mount instead:

--mount source=lt_userfiles,target=/userfiles
--mount source=lt_pub_userfiles,target=/public/userfiles
--mount source=lt_logs,target=/resources/logs
--mount source=lt_config,target=/config

I'd also recommend moving to a .env file for the environment variables, and adding SMTP config to the default set, at least in the file but maybe commented out. Ain't no way php mail() is gonna work from a docker container without config beyond the scope of what you probably want to provide.

[cesalo]

@tet3 what exactly are the benefits over a bind mount? I've researched a little bit and it seems you can't choose the location of the volumes. In my case all my bind mount points are located in NFS mount points in my main NAS so they not depend on the host and backups are very easy to perform.

[tet3]

For your specific situation, bind mounts may be preferable. But I think for a general recommendation, volumes are the way to start. Doesn't require any editing of the command - if you have Docker installed and running, you have the ability to create Docker volumes. So a docker-compose and a sample command line that use docker volumes can be run as-is, and if someone wants to alter it for their needs, they of course can.

But since config through environment variables is now available, there's no need for easy access to the directories. You just want to get them out of the container so that it doesn't bloat, and so that it can be taken down, upgraded, replaced, or whatever, and still have the site be intact when you bring it back up.

[gotjoshua]

For your specific situation, bind mounts may be preferable. But I think for a general recommendation, volumes are the way to start. Doesn't require any editing of the command - if you have Docker installed and running, you have the ability to create Docker volumes. So a docker-compose and a sample command line that use docker volumes can be run as-is, and if someone wants to alter it for their needs, they of course can.

But since config through environment variables is now available, there's no need for easy access to the directories. You just want to get them out of the container so that it doesn't bloat, and so that it can be taken down, upgraded, replaced, or whatever, and still have the site be intact when you bring it back up.

I have some experience with this decision between bind mount (which i prefer whenever possible) and named volumed ("docker managed")... The only time i use named mounts, is when i need the folder to be pre-populated with the contents of the docker image, and then be persistent thereafter. Is this the case for the folders that are mentioned above? or can they easily start out empty and then be populated "from scratch" once the system is running?

[marcelfolaron]

Thanks for the input. The config folder and settings folder needs to be prepopulated when Leantime is set up. (config and settings file. The config file is created as part of the startup script while the settings file exists when downloading the tar.

On Sun, Jul 12, 2020 at 5:22 AM gotjoshua [email protected] wrote:

For your specific situation, bind mounts may be preferable. But I think for a general recommendation, volumes are the way to start. Doesn't require any editing of the command - if you have Docker installed and running, you have the ability to create Docker volumes. So a docker-compose and a sample command line that use docker volumes can be run as-is, and if someone wants to alter it for their needs, they of course can.

But since config through environment variables is now available, there's no need for easy access to the directories. You just want to get them out of the container so that it doesn't bloat, and so that it can be taken down, upgraded, replaced, or whatever, and still have the site be intact when you bring it back up.

I have some experience with this decision between bind mount (which i prefer whenever possible) and named volumed ("docker managed")... The only time i use named mounts, is when i need the folder to be pre-populated with the contents of the docker image, and then be persistent thereafter. Is this the case for the folders that are mentioned above? or can they easily start out empty and then be populated "from scratch" once the system is running?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Leantime/leantime/issues/779, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALG4EFTTL756JENMI2BUG4TR3GTJPANCNFSM4MVC2HHA .

[DHS1001]

Tried the below setup in synology docker on 2.1.8.

-v /local_dir/userfiles:/userfiles
-v /local_dir/public/userfiles:/public/userfiles
-v /local_dir/logs:/resources/logs
-v /local_dir/config:/config

I have add Everyone to allow read and write to the nas folders.

But the userfiles and the rest are not showed in the nas folder...

Is there other setting need to be done to make this work? Thanks

[gotjoshua]

is there other setting

this is not really a setting, but rather a docker convention (what i call a limitation): named volumes are pre populated from the docker image folders on the first container up. mounted /local_dir/s are not. You can monkey patch this by mounting elsewhere and manually copying the contents of the container folders into your folders. OR you can use https://github.com/MatchbookLab/local-persist

good luck