Create the best possible docker-compose.yml for this project

[javiereguiluz]

Calling for help from Docker experts. We need to create the best possible docker-compose.yml file for this project. The application requirements are well defined (we use env vars, Webpack Encore, PHP 7.1, Symfony 4.1, SQLite database, etc.) so it should be possible to create that file.

[javiereguiluz]

An important note mentioned to me by a person on Symfony Slack (I don't remember exactly who, I'm sorry). In the normal Symfony Demo app, we must use SQLite because it's our only option to use a database that requires zero setup.

However, when using Docker, we can use any database with zero setup. So, let's use PostgreSQL in the Docker config file. (I suggest PosgreSQL because to me it looks more popular among Symfony devs than MySQL).

[stof]

the hard part is that our config/packages/doctrine.yml file is currently incompatible with Postgresql as it defines a mysql-only charset (the proper UTF-8 charset is the utf8 on postgresql, as they got it right directly instead of creating a second charset like utf8mb4 for proper UTF-8 support)

[javiereguiluz]

@stof could we run a quick sed command on that config file to replace the wrong value while setting up things in Docker?

[stof]

@javiereguiluz if we copy the file inside the image at build time, we could. If we want to mount the source code instead (to make it a dev-like environment where you can edit things), we cannot modify files in the image (as they are not in the image)

[sebastianblum]

@javiereguiluz we can remove charset: utf8mb4 in this file (https://github.com/symfony/demo/blob/master/config/packages/doctrine.yaml) and add it as a parameter ?charset=utf8mb4 in the env.dist file (https://github.com/symfony/demo/blob/master/.env.dist)

DATABASE_URL=sqlite:///%kernel.project_dir%/var/data/blog.sqlite?charset=utf8mb4

then we can create a new .env file for the docker environment

[syther101]

Hay all, subscribed to this issue when it was being talked about in slack. Was toying around with docker the other day and got reminded of this. Not the most experienced with Docker but can try and help where I can 😄

Do we have any ideas what base image we would want to use. 7.1-jessie maybe?

[OlivierToussaint]

we can take this : https://github.com/dunglas/symfony-docker ?

[frastel]

I would vote for sqlite because you do not have to start an additional container for this database.

About the requirements:

• mailing should also be possible? Or should we ignore this feature as it is disabled by default?
• how about the webserver? Which one should be used or should the build-in webserver be used?
• very often discussed: How about the phpunit and composer runner? Some ppl start the official images ignoring the PHP version used there. Others create own "dev" PHP images with phpunit and composer installed. I prefer the later one because imho it is very important that those runners run within the same PHP environment than your application does.

[frastel]

@OlivierToussaint the aim of your linked docker setup is to start a new Symfony project not to use an existing one.

Btw: The project uses the second approach I mentioned in my prior comment.

[OlivierToussaint]

@frastel yes I know, but the base of dockerfile & docker-compose is here, we can be inspired

[frastel]

@OlivierToussaint Ok, for inspiration it is good enough.

@syther101 The question of the base image is a good one. php:7.1-jessie would be 378MB in size, php:7.2.7-fpm-alpine would be only 81MB.
I would try it with the alpine image. I am aware of the fact that not everything is possible with alpine images. But the Docker workshops I hosted have shown it is very important to use the smallest Docker Images possible.

[ajardin]

There are several possibilities, but to summarize:

• php:7.2-fpm-alpine with everything needed by Symfony 4.1 and Webpack Encore
• nginx:1-alpine VS built-in webserver
• postgres:alpine VS SQLite

I personally prefer the approach where everything is provided by a dedicated container.
Also, I'm using djfarrelly/maildev on my local environment to test emails. Does someone know a better alternative?

[moosti]

I am using this guy

• https://github.com/tulik/symfony-4-docker-runtime-env

It's good (not include yarn support for assets yet)

[thomas-hiron]

How about building each image from alpine with 3 Dockerfile inside project?
I needed such resources a few time ago and I think it could be nice

[j4nr6n]

This one is based on a setup from phpdocker.io, with a couple of modifications. I know it can be improved on. Contents are here

[o-alquimista]

I built this one recently: https://github.com/o-alquimista/symfony-demo-docker

• None of the containers start as root. The user symfonyd was created for this.
• Unix socket used to connect HTTPD with PHP-FPM.
• Uses SQLite.
• Node and Composer containers included. Composer creates the project on startup.
• Commented code.
• SELinux ready.
• Well organized directory structure.

However:

• Before starting it, you must edit the docker-compose.yml file and set your UID where needed. Node and Composer, for example, run as your UID and the GID of the web server.

If anyone knows how to automatically detect the UID for the compose file, then things get a lot more simple.

docker-compose up -d

After the containers node and composer exit, the application is ready at localhost.

I haven't discovered any errors or limitations so far.

[mehdibo]

@javiereguiluz is help still wanted?

Update: #1275

[javiereguiluz]

@mehdibo hi! Sadly, there's a big problem when trying to solve this.

The technical part is not a problem, because many people here know how to dockerize this app.

Problem is that there are many different ways of solving it ... and people using Docker can't agree on "the best way" to solve this for this project. Discussions usually end up being an endless debate about why doing XXX is better than doing YYY, and later someone comes and says that both XXX and YYY are wrong and we should do ZZZ.

It's a shame, but how things are 😐

[mehdibo]

@javiereguiluz Oh, that's a shame, can't someone from the core team just decide "dectatorally"?

I don't think such a debate is important for a demo app.

If you have an example of a debate I'd be happy to take a look at it (I promise I won't jump in xD)

[stof]

The decision taken by the core team for the Symfony way of running a dev environment is to run PHP on the host and not in Docker (see the book for an example using that setup).
So if we go for "the core team way" to fix this issue, it would get closed as "won't do".

[wouterj]

Yes, I would either implement the "core way"/"Symfony CLI way" or don't implement anything at all.

[mehdibo]

I see, well as Javier said that's a shame, from 2018 and we still don't have a Dockerized demo 😅
I hope we all reach a conclusion after all these years, thanks for the information!

[maxbeckers]

Hi,

just saw this old issue. I think the main problem besides the many possibilities to dockerize it are the somewhat unclear requirements or the unclear context.

Is it about creating a local symfony dev environment? To give an example what one way is how to develop symfony in a docker environment? This is possible, i did such a setup already, but has some problems like performance when you have to mount too much files you mount into the container. As @stof and @wouterj already said there is the better way to have a local setup.

Or is it about creating a docker image that starts up locally to show the demo, but does not mount files from the local computer. So a docker image that could also run anywhere else in the cloud. More a blueprint for a dockerfile to use it in an environment. Just to show a basefile that can be copied and modified (install other php extensions or whatever needed) when you plan to have a containerized running envrionment for your application. Then you could use this blueprint, modify it, create the image during the build process e.g. in the build pipeline and then deploy it to dev or whatever.

@javiereguiluz what do you think?

[Wirone]

I think the main problem besides the many possibilities to dockerize it are the somewhat unclear requirements or the unclear context. Is it about creating a local symfony dev environment? (...) Or is it about creating a docker image that starts up locally to show the demo, but does not mount files from the local computer.

Personally I think it should run the demo, but allow development of the demo (not the Symfony itself), however requirements are really outdated and should be reviewed. Anyway, I'm interested too, maybe I could help with it if there are clear requirements.

This is possible, i did such a setup already, but has some problems like performance when you have to mount too much files you mount into the container

I don't get the problem, we work on Docker locally with the app that mounts >430k files and it's totally usable, why Symfony Demo would be problematic here 🤔?

[stof]

I don't get the problem, we work on Docker locally with the app that mounts >430k files and it's totally usable, why Symfony Demo would be problematic here 🤔?

@Wirone on which OS are you working ? Based on past feedback (maybe things have changed since them), such volume mounts are very good on Linux but suffer from abysmal performance in Docker for Windows or Docker for Mac because of the additional VM layer being used to run a Linux kernel (the mounts are fast between the container and the Linux VM but slow between the Linux VM and the host).

[Wirone]

@stof I'm on MacOS (M1) with OrbStack, but previously also on Docker Desktop. Yes, the performance is not as good as on Linux, but I'm pretty sure it's totally doable to run Symfony Demo with volume mounts, that would work on any OS. I believe really often these performance problems are caused by wrong Docker setup, not Docker per se.

[stof]

@Wirone the performance we talk about here would also be the performance of editing the demo (if we only care about running it, we don't need a volume).
And the symfony demo should not showcase a config that works only thanks to having only a small number of files in the Symfony Demo. Once we add it, it will be the inspiration for others and they might have projects with a lot more files.

Anyway, my local stack runs PHP on the host (with the symfony-cli project) and relies on Docker only for the services. So I don't have the answers for which Docker config will have the right performance.

[Wirone]

@stof I know it's about being able to edit the demo 🙂. I work with Docker stacks for years now, and many times it wasn't even required to have anything installed locally more than Docker itself, everything happened inside containers - both when it comes to serving backend and rebuilding frontend in real-time. I now have PHP installed locally for convenience only and because of PHPStan which is significantly slower on our main project when run in Docker (but it's 30k+ PHP project-only files). I am pretty sure Symfony Demo can be run through Docker with full development support 🙂.

[stof]

@Wirone I totally agree that the symfony/demo project can probably be run with good performance on almost any configuration due to being very small. But the whole point of the symfony/demo is to demonstrate how to do things. It is a learning tool. So we cannot select a solution that is acceptable only thanks to the small size of the project as it would defeat its goal.

[Wirone]

@stof but the same solutions work for really large projects I worked or still work with, so... 🤷. IMHO this Demo should lead the path and show how things can (should?) be done, but it just can't cover all real-world scenarios, because each project is different. It can certainly show how to utilise Docker, and if anyone picks this to any real-world project and encounters any problems, then these must be solved in the context of that project. In fact, I believe any other concept picked from this demo can turn out to be problematic just like Docker, so it's only about familiarity - developers most probably won't have problems with PHP or Symfony, while not everyone knows Docker enough. But it should not be a blocker in my opinion 😉.