Instructions for running container

[atz]

I'm not sure I follow the Docker container composition in use. Certainly there is something additional expected of the operator to configure for their environment.

docker pull trellisldp/trellis-ext-db
docker run -p8080:8080 -p8081:8081 trellisldp/trellis-ext-db 
ERROR [2018-11-07 01:36:30,609] org.apache.tomcat.jdbc.pool.ConnectionPool: Unable to create initial connections of pool.
! java.net.UnknownHostException: db
...
org.postgresql.util.PSQLException: The connection attempt failed.

Can you clarify what expectations around usability of the container are reasonable? Should consumers derive their own containers and override /opt/trellis/etc/config.yml? Is that sufficient?

[atz]

Is there a configuration strategy whereby config.yml values are overridable from ENV vars?

[acoburn]

Hi @atz, the Docker setup is still pretty new, so we're still trying to get the setup and documentation right. One important point is that the trellis-ext-db container does not contain a postgres database: the expectation is that the database would be in an external container.

@gregjan is using this container in Docker Swarm mode, and there is some documentation available here: https://github.com/trellis-ldp/trellis/wiki/Dockerized-Trellis. In a word, there is an external postgres container (with a hostname defined as db).

The Trellis application itself is entirely configured by the /opt/trellis/etc/config.yml file. I'll do some testing, but basically, the docker compose file from the link above should be changed to include some configs sections.

[acoburn]

And something to add here -- I'm really not an expert on Docker configuration, and so @atz, if you have suggestions for improving the Docker setup or the documentation, please let us know. If you'd like to explore the code that is used for generating the Docker image, it is defined here and the deployment-related files are located here. Or if there is a standard feature that we are missing, please let us know.

[ajs6f]

@atz As far as goes config from ENV, the short answer is yes, and you should be able to do that now. Trellis (in all its forms) relies on Apache Tamaya to manage configuration, and out-of-the-box, Tamaya has a simple pattern of loading that starts with some special files (to which we can add those that Trellis specifies, as @acoburn described above) and goes through sources like JNDI entries, ENV vars, and Java system properties.

Experimentally, we can confirm that you can override config setting from ENV vars (again, @gregjan is doing that now) but it may take a bit of fiddling to get the names right. Please do try and let us know if you run into any trouble!

[acoburn]

I would qualify the degree to which ENV values can influence the Docker-based application. That system uses Dropwizard as a packaging/wiring system, and Dropwizard has its own way to configure things. That said, I just opened a PR to make it possible for a dropwizard-based configuration file to accept environment variables. Once that is merged, I can update the associated configuration file in this repo with hooks for ENV-based configuration.

[ajs6f]

Good point, @acoburn. As we go forward, I'm sure we'll continue to refine the relationship between wiring and configuration (with Docker deployment a high priority use case).

[atz]

Cool, thanks for the replies. Without ENV overrides (or even with them), the product is more a of a proto-container than a container, since it would require another layer or some internal manipulation to become functional.

Another strategy would be to allow a single ENV to point to an off-box source of configuration file (URL, S3 bucket/key, document store, etc.).

To confirm, I see the tension between the 3 major modes of install: OS package, container and from source.

I'll read up on Tamaya and experiment.

[gregjan]

The docker-compose file is currently minimal config, basically for those trying out the software more than for those hosting in production.. I think a more full compose recipe would include all of these new environment variable settings with some defaults.

In any case the front-end needs to wait for PostgreSQL to become fully available, which is not guaranteed by the compose dependency. So it will log some errors until it connects. We've also debated simply using a restart policy or Swarm equivalent to fail fast until the DB is online. In my experience the service re-instantiating itself like that confuses folks and makes it harder to grasp the underlying situation. What do you think?

What else would you do to containerize? We are building container images for the other Trellis implementations as well.

[gregjan]

^^ btw, that "minimal config" tells the postgres container to create a DB and user/pw that matches the Trellis defaults. It is also pulling the trellis-ext-db form of Trellis, if that's not clear.

[atz]

For our context, I'm not as concerned about the initial DB construction, since we are deploying in AWS, so the DB is RDS (and will have to be already built anyway). What I want is to be able to provide the DB configuration variables via ENV so that I don't have to build a wrapper container.

[acoburn]

I updated the docker config example the other day with some sample ENV values for the database connection https://github.com/trellis-ldp/trellis/wiki/Dockerized-Trellis

Does that address your use case?

[atz]

Yes, if the trellis-ext-db container responds to those ENV vars, that would do it.

[acoburn]

@atz has the discussion here resolved this issue for you?