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
9c8f78a059 already fixed many of the cert issues.
However, some issues were caught in the CI:
* The TLS addon has to be rebuilt and not just restarted. For this reason, we now
move things to a directory instead of mounting files. This way the container is just restarted.
* Cleanups must be driven by the database and not the filesystem . Deleting files on disk or after a restore,
the certs are left dangling forever in the db.
* Separate the db cert logic and disk cert logic. This way we can sync as many times as we want and whenever we want.
just move bind mounts. the initial idea was to use docker volume backends
but we have no plans for this. in addition, usage of volumes means that
files get copied from the image and into volume on first run which is
not desired. people are putting /app/data stuff into images which ideally
should break.