Dockerizing simple webbapp: how to pick what goes in which container?
I have a very simple webapp. You can think that it’s a webpage with an input box which sends the user input to the backend, the backend returns a json and then the front end plugs that json into a jinja2 template and serves some html. That’s it. (Also there’s a MySQL db on the backend)
I want to dockerize this. The reason for that is that this webapp happens to have gotten some traction and I’ve had before scares where I push something, the website breaks, I try and roll it back and it’s still broken and I end up spending a couple of hours sweating to fix it as fast as possible. I’m hoping that Docker solves this.
Question: how should I split the whole thing into different containers? Given what I have planned for the future, the backend will have to be turned into an API to which the frontend connects to. So they will be two independent containers. My question is really how to connect them. Should the API container expose a http:80 endpoint, to which the frontend container GETs from? I guess my confusion comes from the fact that I will then have to have TWO python processes running: one for the API obviously, and then another one which does nothing but sending an input to the API and rendering the returned json into a jinja2 template. (and then one container for the MySQL db).
OR should I keep both the renderer and the API in the same container, but have two pages, for example /search.html which the user knows about and the api /api.html which is “secret” but which I will need in the future?
Does this picture make sense, or am I over complicating it?
One Solution collect form web for “Dockerizing simple webbapp: how to pick what goes in which container?”
There are no hard and fast rules for this, but a good rule of thumb is one process per container. This will allow you to reuse these containers across different applications. Conversely, some people are finding it useful to create “fat containers” where they have a single image for their whole app that runs in one container.
You have to also think about things like, “how will this affect my deploy process?” and “do I have a sufficient test feedback loop that allows me to make these changes easily?”. This link seems useful: https://valdhaus.co/writings/docker-misconceptions/
If this really is a small application, and you’re not operating in a SOA environment, one container will probably get you what you want.