Home > Net >  Trying to understand how docker works in production for a scalable symfony application
Trying to understand how docker works in production for a scalable symfony application

Time:10-17

I'm trying to understand how docker works in production for a scalable symfony application. Let's say we start with a basic LAMP stack:

  • Apache container
  • php container
  • mysql container

According to my research once our containers are created, we push them to the registry (docker registry). For production, the orchestrator will take care of creating the PODS (in the case of kubernetes) and will call the images that we have uploaded to the registry.

Did I understand right ? Do we push 3 separate images on the registry?

CodePudding user response:

Let me clarify a couple of things:

push them to the registry (docker registry)

You can push them to the docker registry, however, depending on your company policy this may not be allowed since dockerhub (docker's registry) is hosted somewhere in the internet and not at your company. For that reason many enterprises deploy their own registry, something like JFrog's artifactory for example.

For production, the orchestrator will take care of creating the PODS (in the case of kubernetes)

Well, you will have to tell the orchestrator what he needs to create, in case of Kubernetes you will need to write a YAML file that describes what you want, then it will take care of the creation.

And having an orchestrator is not only suitable for production. Ideally you would want to have a staging environment as similar to your production environment as possible.

will call the images that we have uploaded to the registry

That may need to be configured. As mentioned above, dockerhub is not the only registry out there but in the end you need to make sure that it is somehow possible to connect to the registry in order to pull the images you pushed.

Do we push 3 separate images on the registry?

You could do that, however, I would not advice you to do so. As good as containers may have become, they also have downsides. One of their biggest downsides still are stateful applications (read up on this article to understand the difference between stateful vs stateless). Although it is possible to have stateful applications (such as MySQL) inside a container and orchestrate it by using something like Kubernetes, it is not advised to do so. Containers should be ephemeral, something that does not work well with databases for example. For that reason I would not recommend having your database within a container but instead use a virtual or even a physical machine for it.

Regarding PHP and Apache: You may have 2 separate images for these two but it honestly is not worth the effort since there are images that already have both of them combined. The official PHP image has versions that include Apache, better use that and save yourself some maintenance effort.

Lastly I want to say that you cannot simply take everything from a virtual/physical server, put it into a container and expect it to work just as it used to.

  • Related