Compose File Discussion

[clairmont32]

Originally raised by takov751: #25 (comment)

I thought a bit more today about what may make automating the server installs through a docker-compose file like Takov had brought up. The docker-compose file does have the ability to taken an env_file so having a user fill in a couple of fields in a pre-canned .env file may be enough to stage the environment for the entire process.

I think the script that starts the server selection may need a bit of adjustments to read the envs to make this happen since the .env would be replacing the user's input through the terminal. I may have a bit of explorative time tonight to confirm my theory.

[takov751]

That would be great. A lot could be passed on with .env even some of the static settings, like domain, public ip etc.
As an example I would mention linuxserver.io they make a tons of container and all of their work available. I think we wouldn't be able to get to that capability as of yet. Please correct me ,but I think some adjustment needed for the original project to get similar capability. On the other hand i was thinking we don't even need that as we already have that with mounted directory.

[clairmont32]

I haven't done anything with LGSM in a cloud environment with a server tied to a domain yet. I'm sure just the direct IP connection to the server would be all thats required though since it shouldnt be any different than connecting to a friend's IP.

[takov751]

True . What I referred to back there how to optimise the container and how much we could automate with for example with a env file

[BBBosp]

Hi, I'm no expert by any means, but have been running more and more services in containers, and also liked the idea of a compose file here.
I need to look at whether the User/Group numbers are important or the name, but assuming the name in the container is the important part, what do you think about taking a number out of Linuxserver.io's playbook and adding a environmental variable to set PUID and PGID. This way you can run the container under a specific user that would presumably also have access to the lgsm directory. I would require a slight rework of the dockerfile, but nothing extensive.

in the same vein, would it be a better to pass the values you consider through a .env as environmental variables for docker?

Linuxserver.io example :
https://github.com/linuxserver/docker-baseimage-ubuntu/blob/master/root/etc/cont-init.d/10-adduser

[BBBosp]

As it stands (correct me if I'm misreading), the dockerfile creates a user of linuxgsm with a uid and gid of 750. This is presumably why you need to perform the initial step of making the lgsm directory and giving ownership to 750 on your host. If instead you make an environmental variable PUID and PGID, have the docker file make linuxgsm user based on these values as opposed to a static 750.

As I know it this should offer 2 things. a) if the user sets the PUID and PGID to the user on the host they want to manage, the chown in the initial step is unnecessary. b) The user will have access to any config files inside of lgsm directory without any extra shenanigans on the host.

There is also maybe a longer term benefit, which is setting up defined practices for using environmental variables. This can be used in the future if you want to do things like have an automated system to install a specific server. And speaking of clear docs you could have a page that says if using this option, map these ports by default. That's optimistic thinking for the future though, and a bit much for a first step of implementation.

[clairmont32]

With bind mounted files/directories we're able to everything in the volume without having to create a local user on the host.

I got most of the way through a rough draft of everything up to the server install success user input before having to do some things around the house.

It seems like removing the verification check is the easiest way to handle it since this workflow is meant to be more automated.

[BBBosp]

I may not have communicated it well, the point isn't adding a user to the host, it's mapping the user inside the container (linuxgsm) to the same ID's as the existing user on the host so the user has access to files without being root or having to docker exec -it lgsm-docker /bin/bash

[clairmont32]

I think you're still describing what a volume is meant for. Maybe we can hop on Discord sometime? Here's the links to docker volumes for managing persistent storage within the container. TLDR: there are 3 forms and one allows you to see and edit directories or files within the container without needing additional perms outside of the container itself.

https://docs.docker.com/storage/
https://docs.docker.com/storage/bind-mounts/

Edit: I think I understand what you were trying to stay now. Since the configs are generated within the container first you'll need a user with the same IDs to fake out the container's permissioning to appear that it's the same user. It would allow the execution of the shell scripts and editing the files after they've been generated.

[BBBosp]

Yes, that's what I mean. Also, I'm on the community discord now, so feel free to reach me there.

[dgibbs64]

Brilliant there is a discussion on this. Sadly my docker knowledge is still basic so I am heavily guided by others on how to improve the docker image

[clairmont32]

Initial draft for what I've got working thus far has a PR on the develop branch. I only had single commit for today so it's catching up the branch as well.

#29

I tossed around the idea of using Docker's resource limiting but that would be better suited after the entire workflow gets finished. The installserver.sh script could initiate the needed docker swarm and call the docker stack deploy for starting up the container itself but that might be on the level of over designing

[takov751]

True. Docker Swarm would only be needed rarely for LGSM . It would more confusing for general users and would need extra steps at the install process.