<p>I'm running around 30 different sites on the same host, each managed using docker-compose. Some of them use Nginx, some use Apache. Then there's a reverse proxy container exposed to the internet which runs Nginx, has a bunch of vhosts and will redirect traffic to the right container. Those 30 different sites are just me trying out various ideas, and they don't have a lot of customers.</p>

<p>I know that using docker-compose is unwise for production use, because turning off and turning the container back on using the new version still takes time (&lt;3 seconds). I know about docker swarm and K8S too, which I will use if any of those 30 different sites becomes big enough. By that point I'll probably restructure everything to achieve zero downtime deployment. But what I'm asking is different.</p>

<p>I want to still manage normal containers using docker compose, because it's just so convenient and because I only have 1 node, so running K8S would be overkill and wouldn't really have zero downtime deployment. However, I want to replace the reverse proxy container every now and then (may be 1-3 times a week) and I don't want to have any downtime with that single container because all those 30 sites will be affected. I can accept &lt;3 seconds downtime for single sites, because most sites don't change at all, and the ones that do are experimental, but I'm starting to feel uncomfortable having &lt;3 seconds downtime for the reverse proxy.</p>

<p>So is there a way for me to replace the reverse proxy container with no downtime? Something really simple and lightweight? Doesn't have to use docker compose, but should still use containers overall. I'm considering these:</p>

<ul>
<li>Use KIND (Kubernetes IN Docker), which runs on a single host and creates containers so that they appear as nodes. This takes 800MB-1GB RAM, so it's undesirable</li>
<li>Keep the reverse proxy container up indefinitely, change the configs inside of it, restart Nginx (&lt;1 seconds downtime), but this seriously defeats the purpose of containers and I can't just don't care about containers anymore, which is the initial reason I want to containerize the applications.</li>
</ul>

<p>Are there any other options?</p>

<p>Use Kubernetes.  Even on a single node, it's designed to manage most of these problems for you and when you do want to move to multiple hosts 99% of it will be ready. There will be a learning curve but it's worth it.</p>

<p>I'd recommend using a managed service (<a href="https://www.digitalocean.com/products/kubernetes/" rel="nofollow noreferrer">DigitalOcean</a>, <a href="https://aws.amazon.com/eks/" rel="nofollow noreferrer">EKS</a>, <a href="https://cloud.google.com/kubernetes-engine/" rel="nofollow noreferrer">GKE</a>, <a href="https://learn.microsoft.com/en-us/azure/aks/" rel="nofollow noreferrer">AKS</a>) but a single node cluster that includes the management can be quickly setup with <a href="https://microk8s.io/" rel="nofollow noreferrer">microk8s</a>. </p>

<p>The docker compose configs can easily be brought across with <a href="https://kompose.io/" rel="nofollow noreferrer">kompose</a>.</p>

<p>A <a href="https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/" rel="nofollow noreferrer">Kubernetes ingress controller</a>, usually <a href="https://github.com/kubernetes/ingress-nginx" rel="nofollow noreferrer">nginx</a> would replace the reverse proxy functionality and rarely needs to be replaced except for upgrades. Ingress configuration is automatic from <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource" rel="nofollow noreferrer">ingress definitions</a>. In the rare case of an upgrade, Kubernetes is capable of managing it in a no downtime manner if setup to. The ingress controller is just another deployment. </p>
