|
>They are not needed anyway.
turned out to be wrong
I had previously removed definitions for the container's
`container_name` parameters to troubleshoot an issue, but I had
misunderstood the cause of the problem. In fact, even though the use of
the NGINX_PROXY_CONTAINER variable on the acme service didn't appear in
any documentation I read, it _was_ serving a purpose in helping the two
containers communicate.
I still prefer to not use the container_name parameter, so instead,
apply the correct label to the main nginx-proxy container in this
configuration. This actually appears to be the first method used by
acme-companion to locate the container.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Several aspects are touched upon by this commit:
- First, revert the decision to split the acme-companion configuration
into a separate repository. Instead, an alternative docker-compose
file can be used to implement that use case. The alternate file,
defines _both_ services, so a user should only choose one of them.
A big advantage of this is that shared resources between the two
containers will no longer leak outside the docker compose project
namespace, and only a single project will need to be started.
This commit is a git merge purely to preserve the 1 commit that was
unique to the forked repository.
- container_names are no longer defined, as that causes update
conflicts while running cychedelic. They are not needed anyway.
- dhparam volume is dropped, as the upstream documentation does not
require its use.
- The default compose file no longer listens on port 443, and is
generally unaware of the acme-companion service. This makes for a
more concise deployment on systems that will use it.
Signed-off-by: Malfurious <m@lfurio.us>
|
