We have a J2EE application (Wildfly) running behind an Apache web server currently running on Amazon EC2 instances. We are planning on migrating this to a Kubernetes (EKS) platform using Docker images. However, we were curious about best practices. Should we create a Docker container with both the web and app server running within it, as seems common, or are there advantages of creating separate images to house both the web server and another housing the app server?
Create a container per main process. One for the web server, one for the app server.
If the containers will always have a one to one relationship and need to run together, the containers can be scheduled in the same Pod (or as @sfgroups mentioned, an ingress controller may take care of your web server needs).
Kubernetes is a work load scheduler and benefits from knowing the state of the processes it runs. To run multiple processes in a container you need to add a layer of process management, usually starting with backgrounding in a script using ./app &, running into issues, then some type of init system like s6
container-runtime c-r c-r
| | |
init VS web app
/ \
web appIf you start adding layers of process management in between Kubernetes and the processes being managed, the state Kubernetes can detect starts to become fuzzy.
What happens when the web is down but the app is up? How do you manage logs from two processes? How do you debug a failing process when the init stays up and Kubernetes thinks all is good. There are a number of things that start becoming custom solutions rather than making use of the functionality Kubernetes already supplies.