More containers?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

More containers?

Joachim Lindenberg

Hello,

I assume I will have to upgrade guacamole in the near future. Rather than updating all dependencies and recompiling, I´d actually favor to use docker. Now initially I decided against docker because I didn´t like the database…

I am also running mailcow-dockerized (and the database drives up memory utilization L). mailcow-dockerized uses lots of containers plus a central configuration directory (which is filled via git, i.e. my configuration changes are locally merged with central ones). I am wondering whether you can/want to adopt similar separation and offer separate containers for guacd (as already), guacamole, and database (could be a choice of different database including lightweights J). As you already have an extension concept that wires guacamole and the database, I guess it should be possible to expose or copy the relevant directories/configuration from one container to the other and have that picked up. Ideally one can run not just one extension but multiple using distinct containers. Or edit the composition not to load a database.

Does this make sense? The benefit I anticipate is less work during installation and updates.

Best Regards,

Joachim

Reply | Threaded
Open this post in threaded view
|

Re: More containers?

vnick
On Wed, May 9, 2018 at 11:57 AM, Joachim Lindenberg <[hidden email]> wrote:

Hello,

I assume I will have to upgrade guacamole in the near future. Rather than updating all dependencies and recompiling, I´d actually favor to use docker. Now initially I decided against docker because I didn´t like the database…


Well, you don't *have* to, but we're resolving a decent number of issues and adding features along the way, so if you want the bug fixes and features, you'll need to upgrade.  And, yes, Docker is designed to ease this process.
 

I am also running mailcow-dockerized (and the database drives up memory utilization L). mailcow-dockerized uses lots of containers plus a central configuration directory (which is filled via git, i.e. my configuration changes are locally merged with central ones). I am wondering whether you can/want to adopt similar separation and offer separate containers for guacd (as already), guacamole, and database (could be a choice of different database including lightweights J).


Yes, best practices for containers is to run a single workload per container, so you should run your guacd instance, guacamole-client (Tomcat + Guacamole Client + Extensions), and Database in separate instances.
 

As you already have an extension concept that wires guacamole and the database, I guess it should be possible to expose or copy the relevant directories/configuration from one container to the other and have that picked up. Ideally one can run not just one extension but multiple using distinct containers. Or edit the composition not to load a database.


Docker does allow you to make directories available from your host to the containers, which also means you could share the configuration amongst the various containers.  If you look at the very last section of the Guacamole Manual on Docker (http://guacamole.apache.org/doc/gug/guacamole-docker.html) you'll see an example of using the "-v" flag to forward a directory through to a container.

However, I'm not sure what you mean by running "multiple extensions using distinct containers" - this doesn't make sense to me.  All of your extensions need to be present in the container where Tomcat is running the Guacamole Client.  You could run a separate instance of the Tomcat client for each extension, but these will not be magically linked together - you'll have one container with one extension (JDBC, for example) running, another container with another one, etc., and different clients that behave differently.  If you want to use multiple extensions with the Guacamole Client, you should run all of these extensions in a single container with the Guacamole Client.

-Nick

Reply | Threaded
Open this post in threaded view
|

AW: More containers?

Joachim Lindenberg

Hell Nick, all,

I finally found some time to invest into experimenting with docker, docker-compose, and guacamole. Good news is, I can run guacamole dockerized now, even with docker-compose.

Now the challenges:

·       as I am running an extension I wanted to make this available in a separate (data) container in order not to change your existing ones but expose a data volume with the extensions directory. This appears to be difficult and also depending on the version of compose (and file). Actually I gave up on that one for now, but any suggestions or examples welcome.

·       instead I am now building my own guacamole container deriving from guacamole/guacamole and just adding my extension and – see below – configuration file. The docker file looks like the following:

FROM guacamole/guacamole

ADD https://software.lindenberg.one/backup/downloads/guacamole-lindenberg-backup-0.9.14.jar /ext/guacamole/extensions/

COPY guacamole.properties /ext/guacamole/

(I am aware of that ADD is kind of deprecated). What I don´t understand is why I use /ext/ and in fact the files end up in /root/.guacamole/.

To some extent this also clarifies how to include multiple extensions: just add all of them. However it is not really a modular approach then.

·       what I dislike about the docker file above is, that I have to include the configuration with the code and force a rebuild on every configuration change. Imho being able to separate code and data is one of the key aspects in using containers. Maybe I am just unaware of a better approach, but what comes to my mind is that it would be great to have distinct environment variables pointing to extensions directory vs guacamole configuration. For compatibility reasons the extensions directory variable can still default to the existing definition.

·       Last but not least, it would be great to have some more documentation on how to use guacamole extensions and docker-compose. And of course I´d also love to see docker-compose in the official documentation though I noticed there are plenty of examples on github. Most of them however are not using environment variables for credentials as suggested in https://stackoverflow.com/questions/22651647/docker-and-securing-passwords.

Thanks & Best Regards,

Joachim

 

 

Von: Nick Couchman [mailto:[hidden email]]
Gesendet: Mittwoch, 9. Mai 2018 19:44
An: [hidden email]
Betreff: Re: More containers?

 

On Wed, May 9, 2018 at 11:57 AM, Joachim Lindenberg <[hidden email]> wrote:

Hello,

I assume I will have to upgrade guacamole in the near future. Rather than updating all dependencies and recompiling, I´d actually favor to use docker. Now initially I decided against docker because I didn´t like the database…

 

Well, you don't *have* to, but we're resolving a decent number of issues and adding features along the way, so if you want the bug fixes and features, you'll need to upgrade.  And, yes, Docker is designed to ease this process.

 

I am also running mailcow-dockerized (and the database drives up memory utilization L). mailcow-dockerized uses lots of containers plus a central configuration directory (which is filled via git, i.e. my configuration changes are locally merged with central ones). I am wondering whether you can/want to adopt similar separation and offer separate containers for guacd (as already), guacamole, and database (could be a choice of different database including lightweights J).

 

Yes, best practices for containers is to run a single workload per container, so you should run your guacd instance, guacamole-client (Tomcat + Guacamole Client + Extensions), and Database in separate instances.

 

As you already have an extension concept that wires guacamole and the database, I guess it should be possible to expose or copy the relevant directories/configuration from one container to the other and have that picked up. Ideally one can run not just one extension but multiple using distinct containers. Or edit the composition not to load a database.

 

Docker does allow you to make directories available from your host to the containers, which also means you could share the configuration amongst the various containers.  If you look at the very last section of the Guacamole Manual on Docker (http://guacamole.apache.org/doc/gug/guacamole-docker.html) you'll see an example of using the "-v" flag to forward a directory through to a container.

 

However, I'm not sure what you mean by running "multiple extensions using distinct containers" - this doesn't make sense to me.  All of your extensions need to be present in the container where Tomcat is running the Guacamole Client.  You could run a separate instance of the Tomcat client for each extension, but these will not be magically linked together - you'll have one container with one extension (JDBC, for example) running, another container with another one, etc., and different clients that behave differently.  If you want to use multiple extensions with the Guacamole Client, you should run all of these extensions in a single container with the Guacamole Client.

 

-Nick

 

Reply | Threaded
Open this post in threaded view
|

Re: More containers?

Mike Jumper-2
On Sat, Jun 16, 2018 at 7:22 AM, Joachim Lindenberg <[hidden email]> wrote:

...

(I am aware of that ADD is kind of deprecated). What I don´t understand is why I use /ext/ and in fact the files end up in /root/.guacamole/.


Copying the provided template GUACAMOLE_HOME into place is part of the Docker image's startup process:


The Docker image (somewhat confusingly) uses its own GUACAMOLE_HOME variable to define the location that should serve as the basis for the webapp's GUACAMOLE_HOME. As the GUACAMOLE_HOME environment variable has special meaning to the web application, it is explicitly forced back to ~/.guacamole/ with your custom value stored in GUACAMOLE_HOME_TEMPLATE:


To some extent this also clarifies how to include multiple extensions: just add all of them. However it is not really a modular approach then.


How is separating things into distinct extensions not modular?

·       what I dislike about the docker file above is, that I have to include the configuration with the code and force a rebuild on every configuration change. Imho being able to separate code and data is one of the key aspects in using containers.


I believe this is as aspect of the approach the unmodified Docker image already takes. With the exception of third-party customizations (which naturally can't be part of the mainline Docker image), the container is self-contained and driven by configuration provided through environment variables.

You will need to dynamically generate your guacamole.properties during container startup (like the existing start.sh does) if you wish to avoid rebuilding the image.

Maybe I am just unaware of a better approach, but what comes to my mind is that it would be great to have distinct environment variables pointing to extensions directory vs guacamole configuration. For compatibility reasons the extensions directory variable can still default to the existing definition.


I disagree here.

Though the Docker image layers its own semantics on top of GUACAMOLE_HOME (let's set those aside for the moment as they are not a part of the webapp), the point of the main GUACAMOLE_HOME directory with respect to Guacamole configuration is to be able to rely upon convention. Once the location of GUACAMOLE_HOME is defined, the locations of all Guacamole-specific configuration files, all extensions, etc. are known and rigorous.

- Mike

Reply | Threaded
Open this post in threaded view
|

Re: More containers?

vnick
On Sat, Jun 16, 2018 at 6:11 PM Mike Jumper <[hidden email]> wrote:
On Sat, Jun 16, 2018 at 7:22 AM, Joachim Lindenberg <[hidden email]> wrote:

...

(I am aware of that ADD is kind of deprecated). What I don´t understand is why I use /ext/ and in fact the files end up in /root/.guacamole/.


Copying the provided template GUACAMOLE_HOME into place is part of the Docker image's startup process:


The Docker image (somewhat confusingly) uses its own GUACAMOLE_HOME variable to define the location that should serve as the basis for the webapp's GUACAMOLE_HOME. As the GUACAMOLE_HOME environment variable has special meaning to the web application, it is explicitly forced back to ~/.guacamole/ with your custom value stored in GUACAMOLE_HOME_TEMPLATE:


To some extent this also clarifies how to include multiple extensions: just add all of them. However it is not really a modular approach then.


How is separating things into distinct extensions not modular?

I don't think the point was that extensions are not modular, I believe it was that adding all possible extensions to the container defeats the modular nature of extensions, and I agree.  The solution to trying to figure out how to get multiple extensions into the Docker image should not be to just dump them all in.
 

·       what I dislike about the docker file above is, that I have to include the configuration with the code and force a rebuild on every configuration change. Imho being able to separate code and data is one of the key aspects in using containers.


I believe this is as aspect of the approach the unmodified Docker image already takes. With the exception of third-party customizations (which naturally can't be part of the mainline Docker image), the container is self-contained and driven by configuration provided through environment variables.

You will need to dynamically generate your guacamole.properties during container startup (like the existing start.sh does) if you wish to avoid rebuilding the image.

Maybe I am just unaware of a better approach, but what comes to my mind is that it would be great to have distinct environment variables pointing to extensions directory vs guacamole configuration. For compatibility reasons the extensions directory variable can still default to the existing definition.


I disagree here.

Though the Docker image layers its own semantics on top of GUACAMOLE_HOME (let's set those aside for the moment as they are not a part of the webapp), the point of the main GUACAMOLE_HOME directory with respect to Guacamole configuration is to be able to rely upon convention. Once the location of GUACAMOLE_HOME is defined, the locations of all Guacamole-specific configuration files, all extensions, etc. are known and rigorous.


It's also worth noting that one of the changes to the current code that will be released in version 1.0.0 is the ability to define any of the guacamole.properties options using environment variables.  This was introduced in GUACAMOLE-464, and should add some flexibility to the process of configuring Guacamole in a container environment by allowing those options to be configured entirely in the environment without writing the guacamole.properties file, if you choose to do it that way.

-Nick
Reply | Threaded
Open this post in threaded view
|

Re: More containers?

vnick
In reply to this post by Joachim Lindenberg
On Sat, Jun 16, 2018 at 10:23 AM Joachim Lindenberg <[hidden email]> wrote:

Hell Nick, all,

I finally found some time to invest into experimenting with docker, docker-compose, and guacamole. Good news is, I can run guacamole dockerized now, even with docker-compose.

Now the challenges:

·       as I am running an extension I wanted to make this available in a separate (data) container in order not to change your existing ones but expose a data volume with the extensions directory. This appears to be difficult and also depending on the version of compose (and file). Actually I gave up on that one for now, but any suggestions or examples welcome.

This is not difficult, this is impossible.  The extensions *must* be in the same container as the main Tomcat instance that runs Guacamole.  These extensions are loaded by the Guacamole Client as it is deployed by Tomcat, so it is really not possible to run extensions in separate containers.  It doesn't matter if you're sharing the GUACAMOLE_HOME directory or the Tomcat WebApps directory or the entire filesystem between two containers, you cannot run an extension in a separate container from the main Guacamole Client (guacamole.war file).

- Nick
Reply | Threaded
Open this post in threaded view
|

AW: More containers?

Joachim Lindenberg

Hi Nick,

I am aware that extensions need to execute in the same container, but I wanted to provide them from a different data container. I know this is possible with plain docker, but failed with docker-compose.

This would address the need to build a container on-the-fly without providing guacamole on my own – which imho is both overhead and less transparent for the user.

Best Regards, Joachim

 

Von: Nick Couchman [mailto:[hidden email]]
Gesendet: Sonntag, 17. Juni 2018 02:10
An: [hidden email]
Betreff: Re: More containers?

 

On Sat, Jun 16, 2018 at 10:23 AM Joachim Lindenberg <[hidden email]> wrote:

Hell Nick, all,

I finally found some time to invest into experimenting with docker, docker-compose, and guacamole. Good news is, I can run guacamole dockerized now, even with docker-compose.

Now the challenges:

·       as I am running an extension I wanted to make this available in a separate (data) container in order not to change your existing ones but expose a data volume with the extensions directory. This appears to be difficult and also depending on the version of compose (and file). Actually I gave up on that one for now, but any suggestions or examples welcome.

This is not difficult, this is impossible.  The extensions *must* be in the same container as the main Tomcat instance that runs Guacamole.  These extensions are loaded by the Guacamole Client as it is deployed by Tomcat, so it is really not possible to run extensions in separate containers.  It doesn't matter if you're sharing the GUACAMOLE_HOME directory or the Tomcat WebApps directory or the entire filesystem between two containers, you cannot run an extension in a separate container from the main Guacamole Client (guacamole.war file).

 

- Nick