some apps really want a valid certificate to send mail and upstream
authors won't add support to skip self-signed certs or skip host name
check in cert. In our case, the issue is that we use 'mail' as the
server name despite having valid certs.
this flag will set the server name to the full mail server fqdn and
also reconfigure the app as needed when the mail server name changes.
we also set up the mail server name to resolve to internal IP because
no mail port is exposed when we are not receiving emails!
with our new retagging approach, the Digest ID remains <null> because
this is only set by docker if truly fetched from the registry.
this means that redis container always gets removed...
Issue 1: DO droplet when given the name my.blah.com , will put an entry
in /etc/hosts with `127.0.1.1 my.blah.com` . When app containers use
system DNS, they get this IP address which does not work inside a container.
An idea is to remove this entry when running cloudron-setup, but maybe this
causes trouble later.
Issue 2: Some networks seem to lack loopback networking. With OIDC changes,
we want the apps to access my.blah.com even if hairpin nat is not working.
Solution: make my.blah.com to resolve to the docker bridge IP (172.18.0.1)
where nginx also listens to. This means that such requests never go outside the server
Caveats:
* This breaks AdGuard which now starts resolving it to 172.18.0.1 for
the entire network! So, we skip ExtraHosts configuration for adguard
* Maybe ExtraHosts should be scoped to OIDC apps only. But the thought here is
that it will help apps like say n8n which are querying dasahboard.
take 2 after failed attempt with 92bce26e22
this makes the dashboard domain resolve internally to nginx
can test with `getent ahosts my.domain.com` inside the container.
ports is REST API input . Map of env var to the host port
portBinding is the database structure. Map of env var to host port, count, type etc
also, rename portCount -> count in various places to keep things consistent
cpuShares is the relative weight wrt other apps. This is used when
there is contention for CPU. If we want this, maybe we implement
a UI where we show all the apps and let the user re-order them.
As it stands, it is confusing.
cpuQuota is a more straightforward "hard limit" of the CPU% that you
want the app to consume.
Can be tested with : stress -c 8 -t 20s
Currently, we allocate 50% as RAM and 50% as swap. The manifest is
usually quite conservative on memory values. This means that we set
up a system where the app is applying memory pressure almost immediately.
This then swaps things randomly and increases cpu usage (kswapd shows
up in the profile).
To rethink the whole situation: we should not cap apps with a swap limit at all.
The memory hard limit is what is important. By redefining memoryLimit , we are
doubling every container's memory and it's good that we over allocate this.
docker is using a extra udp port for every container. when there is
a lot of containers, a lot of random udp ports get used up. this causes
problems when installing apps that require contiguous port ranges
