I'm working on a setup where several client machines connect over a local network to a web application hosted on a server. The server also runs the database and the web app in a container, with the whole system installed at customer sites.
I've run into two main issues. First, containers launched with a restart policy such as `always` do not reliably come back after updates. I suspect this is because I remove the old container when deploying a new production image, then create another container with the same name, which may not preserve the original configuration.
Second, the client machines need to reflect application updates without someone manually refreshing each browser. They will run in kiosk mode, so when the hosted application changes, the clients should update automatically. The server can be refreshed manually if necessary, but that is not practical for every client.
Is Docker Desktop the right choice for this environment? Should I use a Linux-based server or another deployment approach, and what is the usual way to make kiosk clients detect a new version and reload safely?
2 Answers
Docker itself can work, but Docker Desktop is mainly a development convenience and may not be the best production runtime. A dedicated Linux server running Docker or another container runtime is usually more predictable. If you replace containers during deployment, make sure the new container is created from the intended compose or deployment configuration, including its restart policy. In practice, using a compose file and a repeatable deployment process is safer than manually deleting and recreating containers.
Before choosing the tooling, plan the deployment and recovery process as a whole. At each customer site you need to account for the operating system, hardware capacity, startup behavior, network access, backups, update rollback, and what happens if the server or application fails. Running the database and web app on one machine may be acceptable, but you should still have a tested backup and a way to restore the previous application version. Containerization does not automatically solve deployment or operations; it mainly makes the application environment more consistent.
I’m an employee and this was proposed as a replacement for an older IIS-based setup, but the deployment plan is not well defined yet. I’m going to push for a documented update, rollback, backup, and recovery process before treating Docker as the complete solution.
That makes sense. This currently runs on the same PC as the database at customer sites, so I need to investigate whether a small Linux server or virtual machine would be more appropriate than relying on a desktop installation.