Rewrite with docker compose

[ctorgalson]

Major rewrite. Tests well, ready for beta.

[oolongbrothers]

Hello @ctorgalson!

I have been testing around with your docker compose branch and have been running into some minor problems.

First off, I had problems with the names of the docker containers created by docker-compose not being as expected on version 1.23. Apparently they changed the behaviour between the 1.23 version I had lying around and (currently latest stable) version 1.25. When you rewrite the README file for the release of this PR, you might want to mention that docker-compose version 1.25 is a prerequisite.

Furthermore, I have experienced what seems like a race condition on Nextcloud installation: On first run, the "Check status of Nextcloud installation." task gives me the following error:

Fatal error: require_once(): Failed opening required '/var/www/html/lib/versioncheck.php' (include_path='.:/usr/local/lib/php') in /var/www/html/console.php on line 34

After adding another pause task of 60 seconds before the "Check status of Nextcloud installation." task, the problem disappears. I'm sure there is a smarter way to do this.

Keep up the good work!

Regards, //oolongbrothers

[ctorgalson]

Hi @oolongbrothers!

Thanks for testing! I'll take note of the docker-compose issue.

With respect to the error you're experiencing, there may be something I can do with Ansible's wait_for module (it might also be smart for me to use that for the existing pause task as well).

While we're at it, is there anything you thought was an important/significant omission in the role?

[oolongbrothers]

I have some points. Let me give you some background about my use case first:

My use case is that I want to run my Nextcloud app and data stores in an LXD container, while mounting in shared encrypted storage from the host system. All my HTTP proxy and TLS needs are take care of externally by a reverse proxy LXD-container.

I was looking for an alternative to the Nextcloud snap, which is really well done but it's also very opinionated and it didn't fit my use case. Running a dockerized setup that integrates well into my Ansible automation feels like a good middle ground, where I have more control while still relying on a nicely packaged official distribution of Nextcloud.

For your role to fit my use case, I would need it be more customizable:

• Option to disable the proxy layer and expose the Nexcloud container's HTTP port directly
• Option to not enable encryption
• Ability to apply arbitrary configuration/app parameters and apply them via the occ cli

That said, because of my shared storage permissions rely on groups, I think I will also need to do a more unusual tweak: Setting the umask of the apache running in the Nextcloud container to give the group write access.

In the end it depends on your intention with the role, do you want it to be opinionated and do one use case really well or do you want it to be generalist. Since obviously, the role would get more convoluted the more generic it gets.

I created a branch in my fork (https://github.com/oolongbrothers/ansible-role-nextcloud-docker/tree/rewrite-with-docker-compose-oolongbrothers), with a possible implementation of most of the stuff above. I felt compelled to create a nextcloud_occ_config Ansible module to achieve generic configuration handling while keeping the Ansible code sane. I also added a few one-time DB tasks to the installation, since Nextcloud was complaining without them.

Apps management is not yet implemented, I think I would want to create a companion module called nextcloud_occ_app for that.

The umask thing I don't yet know how to handle. Would be nice not having to rely on a custom Dockerfile for the nextcloud image, but maybe that will be needed anyway when adding more advanced stuff like video call and office document editing support.

My role instantiation with the branch looks something like this:

- role: ansible-role-nextcloud-docker
  nd_docker_compose_remove_project: false
  nd_use_proxy: false
  nd_use_redis: true
  nd_use_cron: true
  nd_domain_name: "nextcloud.my.domain"
  nd_nextcloud_encryption_enabled: false
  nd_nexcloud_additional_configuration:
    - key: trusted_proxies
      array_value: ['10.0.0.8']
    - key: overwriteprotocol
      string_value: "https"
    - key: overwritehost
      string_value: "{{ nd_domain_name }}"

It would be totally ok if you feel this is too much.

[ctorgalson]

@oolongbrothers Hi there. I've only just been able to return to this, and realized I never thanked you for your input (also, given the goings-on in the world, I hope you're getting by ok).

Some of your suggestions do match up with my needs, though I implemented them a bit differently--essentially for occ command management, I've added a tasks file containing one task that accepts a list of literal occ commands (minus the docker exec --user www-data php occ part). This means the role is now pretty un-opinionated about e.g. enabling encryption and whatnot. It should also make it possible to use Nextcloud's import command to grab an existing config file.

I've also made both the install and post-install steps' include files configurable so that it'd be possible to handle a completely different pipeline. I haven't done anything with the proxy for the moment. Revisiting the code for the first time in months, I can hardly read the dockerfile template. What I may do is a) make the default template more opinionated (and so less logic-y) while making the file path configurable, and providing a default variable with a basic structure like:

nd_docker_compose_variables:
  cron: []
  db: []
  letsencrypt: []
  nginx: []
  redis: []
  volumes: []

That would make it possible for users to swap in their own j2 file with absolutely any variables they want under the nd_docker_compose_variables (and that way, they'd always be available to the role, thereby avoiding some of Ansible's weird variable inheritance).

Anyhow, all that's yet to come. This PR passes its tests, so I'm going to merge it and give it a good test on some actual hardware to see if I can start using it before my current server OS goes EOL :)