Rework of Examples Section

[tilosp]

Closes #103 Closes #98 Closes #95 Closes #75 Closes #86 Closes #104

TODO:

• split the examples into subfolders
• docker-compose example:
  • use JrCs proxy companion Docker-compose examples uses outdated docker-letsencrypt-nginx-proxy-companion image #98
  • Use volumes instead of mounted folders
  • add proxy settings for upload size nextcloud:fpm Request Entity Too Large #95
  • don't use an external network as it is not needed when the proxy is defined in the same file. Use multiple networks in the file instead
  • add example for apache version
  • change mounts to only /var/www/html since it's simpler and less error-prone (would prevent that "config directory not writeable"-error Permission denied error for config directory in examples #75 example docker-compose does not work on ubuntu 14.04.5 #86)
  • remove container names (not needed)
  • remove ${DOMAIN}, it isn't explained anywhere
  • Add example with "indiehosters"-style 2nd container running a cron job Example: Add container for cron job #123
  • Don't use volumes_from in the fpm example since it isn't supported in docker-compose file version 3
• derived Dockerfiles:
  • Add examples for both cases apache and fpm
  • Add build tests

[SnowMB]

Hey @tilosp,

thanks for starting to work on the examples section. Here a few thoughts on the folder structure.

current version

examples\apache\dockerfiles\Dockerfile.cron
examples\apache\dockerfiles\supervisord.conf
examples\fpm\dockerfiles\Dockerfile.cron
examples\fpm\dockerfiles\supervisord.conf

This has the disadvantage that additional files would clutter the structure and users might ask themself what are these files for (e.g. when s.o. wants to build an Dockerfile.imap and there is the supervisord.conf file). It could get worse when more examples are added.

I would prefer to differentiate between the base images (fpm/apache) in the last subfolder. That leaves three options:

option 1

examples\dockerfiles\cron\Dockerfile.apache
examples\dockerfiles\cron\Dockerfile.fpm
examples\dockerfiles\cron\supervisord.conf

This has the advantage, that the additional files would not be redundant. As long as the additional files can be used in all base images it would be a very clean folder structure.

option 2

examples\dockerfiles\cron\apache\Dockerfile
examples\dockerfiles\cron\apache\supervisord.conf
examples\dockerfiles\cron\fpm\Dockerfile
examples\dockerfiles\cron\fpm\supervisord.conf

Reintroduces redundency, but in cases where different additional files for the base images are needed, their would be no conflicts. Also it is possible to run the default commands docker build . or docker-compose up -d directly in the folder.

option 3

examples\dockerfiles\cron\apache\Dockerfile
examples\dockerfiles\cron\fpm\Dockerfile
examples\dockerfiles\cron\supervisord.conf

This last option could be used to avoid the redundency issue by moving matching files to the parent folder. But at the same time the Dockerfiles get dependant on these directories.

My opinion:

option 1 is useful, if someone dislikes using to many subfolders 😉
Personally I prefer option 2 because it seems to be the cleanest one.

[tilosp]

@SnowMB i agree with you that option 2 is the cleanest one and i am fine with using many sub-directories.
And by the way supervisord.conf is not redundant because one of them starts fpm and the other one apache.

[SnowMB]

You're right. Missed that. But you unterstood what I tried to explain 😁

[tilosp]

@SnowMB this line is redundant, it is already part of the image apcu.config.php

[SnowMB]

done

[SnowMB]

Hey @tilosp,

I got a quick question:

You have an app folder for each example creating a derived image copying the *.php files. Wouldn't it be easier mounting them in the docker-compose.yml file and using the default image?

Are there any advantages / disadvantages that I miss?

[tilosp]

@SnowMB
There is one advantage.
Mounting them is just fine when the docker engine is on the same machine as the docker client.
But if you use a docker engine on a remote machine mounting will fail because the files are only on the client side so that the remote docker engine can't mount them. This problem came up in #104.
When building an image the client transfers the build context (all file which are not excluded by a .dockerignore file) to the docker engine to build it there.

I forgot to do the same for the nginx.conf which I will do later.

[SnowMB]

Ah, I see. Great solution for that case! 👍

[SnowMB]

@tilosp I reworked the proxy examples to fit your style and added a readme file. Please review and maybe add a few words to the readme.

[tilosp]

@SnowMB please take a look.

I removed the example with collabora for now because it does not work. The problem is that the nginx proxy is not setup to handle WebSocket connection and collabora requires WebSocket connection. I would like to merge this PR without a collabora example, we can add one in a later PR.

But we should add a link to the main readme which links to the example readme. Maybe you have an idea where exactly this link should go.

I would also suggest a rework of README.md#running-this-image-with-docker-compose. Maybe by just replacing it with a link to the docker-compose examples

[tilosp]

ping @SnowMB

[SnowMB]

The link in the main readme is easier to add once it is merged, because it should to point to the master branch. I think we can finish this pr now and do some fine tuning in additional pr/issues.

LGTM so far 👍

[SnowMB]

add a sentence why this setup is insecure and that it should not be used in production.

[tilosp]

done

[SnowMB]

lgtm