Fix address already in use

[vvbogdanov87]

Disables default Nginx site.
The default Nginx site binds to port 80 which can be already in use if the container is started with host network.

[fquirin]

Thanks for the contribution! 🙂
I think this change makes total sense but may I ask how you get the "fix address already in use" error? Are you using a different network interface for your containers? Otherwise the network inside the container should be isolated and there is nothing else running that could cause a conflict 🤔

[vvbogdanov87]

I use host network.

docker run --network host ...

I am actually trying to launch SEPIA server on TrueNAS. It has built-in Kubernetes and uses Helm charts for app distribution.
Here is a deployment definition: https://github.com/vvbogdanov87/truenas-charts/blob/0db3c869ce61cbfc22e142376ea457d12d2bf65c/charts/sepia/0.0.2/templates/deployment.yaml#L17

[vvbogdanov87]

Note this line https://github.com/vvbogdanov87/truenas-charts/blob/0db3c869ce61cbfc22e142376ea457d12d2bf65c/charts/sepia/0.0.2/templates/deployment.yaml#L33
I had to mount nginx logs folder in order to extract nginx error logs. Without this the only output I saw in stdout was

Starting nginx: failed

This is the situation to think about. Not all logs of app subsystems(nginx, elasticsearch) go to stdout or stderr. This makes debuging of the container bit more challenging. Logs probably should be redirected to stdout.

[fquirin]

I see the problem, but is there any specific reason why you use the host network? Network isolation is meant to prevent errors exactly like the one you've encountered. Also I'm not sure if you still need the port configuration if you're using the host network anyway. Besides port 80 there are additional ports used for SEPIA micro services: 20721-20723 and in the future there might be additional ones for STT and TTS so you always have to keep an eye on those too if in 'host network' mode.

[vvbogdanov87]

I use host network on my TrueNAS Kubernetes deployments just to keep things simple. In any case, unused port 80 shouldn't be used.
The best practice for complex deployments like SEPIA is to keep each component in a separate container and allow a user to configure application ports in each container(see Single Concern Principle). There are always environment-specific requirements that the developer of an application doesn't aware of (like in my case for example). In Kubernetes ecosystem(which is de facto a container orchestration standard today) complex apps are "packaged" as Helm charts. And usually, it is up to a user how he/she wants to expose an application.

I could help out with making SEPIA containers more Kubernetes friendly and write a helm chart for it.

TrueNAS is quite popular as a home server OS. The latest version TrueNAS SCALE uses Kubernetes as a container orchestration engine and uses a slightly modified Helm charts repository as an application distribution mechanism. I believe having the ability to run SEPIA on TrueNAS by clicking one button in TrueNAS UI will help with SEPIA adoption among enthusiasts.

[fquirin]

I use host network on my TrueNAS Kubernetes deployments just to keep things simple

I don't really think that will keep things simple tbh. Almost all containers use some ports internally and will only explicitly mention the ones that have to be exposed to the outside world (e.g. define them in a docker compose YAML etc.). Most devs will feel safe inside their containers or simply forget to disable certain defaults (like port 80 in SEPIA ^^). In the worst case you are opening up ports that were meant to be private.

The best practice for complex deployments like SEPIA is to keep each component in a separate container and allow a user to configure application ports in each container(see Single Concern Principle).

In principle I agree the principle ^^ but in reality the distinction between micro- and macro-service is often not very clear. In SEPIA for example there is a hard cut between Assist-Server (your SEPIA Home container) and STT-Server, they both run completely independent of each other. Between the "micro"-services that build the SEPIA-Home stack boarders are not that obvious. Many devs might split up code just to avoid large monolithic structures or to better distribute work.

I could help out with making SEPIA containers more Kubernetes friendly and write a helm chart for it.

I'm not familiar with Helm Charts (yet) but I'd certainly be interested in increased compatibility and adapting to standards 🙂 . Feel free to open a new discussion if you have any ideas or suggestions. Something I was planning to do at some point was good Docker compose files. It looks like Helm Charts could make good use of that as well :-).

I believe having the ability to run SEPIA on TrueNAS by clicking one button in TrueNAS UI will help with SEPIA adoption among enthusiasts.

Sounds good 🙂