guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <vn...@apache.org>
Subject Re: More containers?
Date Sun, 17 Jun 2018 00:05:55 GMT
On Sat, Jun 16, 2018 at 6:11 PM Mike Jumper <mike.jumper@glyptodon.org>
wrote:

> On Sat, Jun 16, 2018 at 7:22 AM, Joachim Lindenberg <
> joachim@lindenberg.one> 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:
>
>
> https://github.com/apache/guacamole-client/blob/984ab48ce8dbbb5b9949ce1f5e5f774168b4830b/guacamole-docker/bin/start.sh#L340-L352
>
> 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:
>
>
> https://github.com/apache/guacamole-client/blob/984ab48ce8dbbb5b9949ce1f5e5f774168b4830b/guacamole-docker/bin/start.sh#L31-L33
>
> 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

Mime
View raw message