Add PHP-FPM variant #4
Conversation
fcharlaix-opendsi
force-pushed
the
main
branch
from
b3a612a
to
e61f6e9
Compare
|
Hello there, First of all thanks for your contribution! Getting FPM support would be amazing. I usually handle PHP-FPM and NGINX deployments by building separated containers with the same version number. For instance this is what we have done here at VOLD when we were first building our custom Dolibarr images. (See: https://github.com/vold-lu/docker-dolibarr). We built two containers : dolibarr-php and dolibarr-nginx, one that bundle the source code and NGINX, the other that bundle the source code and PHP-FPM. The two containers then interact together using FastCGI. I am not against your approach either but I don't understand the need to have a dedicated folder Cheers, |
|
Hi, I see, your way solve the need of a volume, but this requires to maintain another image and have the Dolibarr source code twice in image storage. This PR use a separated directory because mounting the folder with a bind mount empty the content in the container : services:
test1:
image: dolibarr/dolibarr:19
container_name: test1
entrypoint: /bin/ls
command:
- -a
- /var/www/html
test2:
image: dolibarr/dolibarr:19
container_name: test2
volumes:
- /tmp/test/vol:/var/www/html
entrypoint: /bin/ls
command:
- -a
- /var/www/html
test3:
image: dolibarr/dolibarr:19
container_name: test3
volumes:
- test3:/var/www/html
entrypoint: /bin/ls
command:
- -a
- /var/www/html
volumes:
test3:Output logsThis could be needed for dev purpose (having access to the source code in an editor), or for people that want to store this in another disk without moving all docker data. (I also think, if someone accidentally modifies the volume content, they're not getting the file updated with future releases) If you have a cleaner way I'm very interested. Thanks, |
|
Hello,
And sadly using a volume mount won't be better... While the first time it will populate the volume with the container data, on upgrade the volume won't be updated and therefore no matter which volume type we are using, we will need a synchronisation mechanism like you suggest here. I have mixed feelings about this implementation. Dolibarr source code by nature should be immutable and therefore does not really fit the volume use-case (persist data across containers restart). (This is only my opinion) In addition to your suggestion I only have two others approach at the moment : Provide another web container Building another (let's call it web) container that duplicate the application source code and provide a web server / reverse proxy. We will end-up having :
And the end user can choose which web flavour he want to deploy and deploy the php backend as well. This approach follow the volume best practices and ensure immutability of the source code. But the cost is a more complex deployment process. Bundle everything into a single container The idea here is to bundle process manager like supervisord that will start both nginx and php-fpm and supervise them. This way we only have one root process inside the container. We will end-up having only :
While this approach clearly shit on (pardon my french) the unix philosophy I know a lot of folks who run similar deployment in production and never had any trouble despite angering some purists online. (And I too am a purist sometime) IMO the main drawback of such approach is that you cannot scale separately the nginx or php-fpm process. By uncoupling the two containers one can easily scale the application by scaling each containers separately but having a single container with the two process mean you scale both nginx and php-fpm at the same time. Would that be a trouble for a Dolibarr deployment? I am personally not sure about this. What do you think about those suggestions? Do you have other ideas? |
|
Hi, The proposed volume and sync mechanism is based on the official Nextcloud Docker image. I don't like my solution, but I don't see any way to improve this. I'm strongly against multiples services in one container, this break the Docker principle of one service one container. For the web container, this need to use a common base to share the source code and not storing the source code multiples time in the Docker image storage. |
| -e 's/^#\(ServerSignature Off\)$/\1/g' \ | ||
| -e 's/^\(ServerTokens\) OS$/\1 Prod/g' \ | ||
| /etc/apache2/conf-available/security.conf | ||
| %EXTRAS% |
There was a problem hiding this comment.
you'll probably have to create a second template for the FPM version of your image instead of editing this one ...
There was a problem hiding this comment.
I want to minimize the number of files to update and avoid any inconsistency between variants
|
Hi there, I think the FPM docker version should be available for those who wants to have plain control on their web server... The dolibarr FPM should only have the source code and the crontab running inside the container (even if it's better to have it separated for concurrency reason), but I endorse the fact to have an image available that just run PHP-FPM with dolibarr app inside to let the people have their own web server dealing with an fpm capable service. Upvoting for a FPM variant along with the full embed apache version... 👍 |
Hello, sorry for the delay, I finally found the time to think more about this.
Can you please explain why are strongly against it? Any production feedback where it was a problem? IMHO I'd rather go with "breaking docker one service principle" (Actually Docker own documentation acknowledge such use-cases https://docs.docker.com/engine/containers/multi-service_container/) rather than using volume to share immutable data between containers. I know the Nextcloud folks have used a similar approach and this had introduce several issues and I think some of them are more harmful than breaking the one service principle : People confused about data being deleted after an upgrade People usually NEVER expect container to remove data especially from a volume. Imagine mounting a volume to persist Dolibarr source code / and or modules. On every upgrade the container will erase people data. Many end users are not aware of the proper way to use Docker, introducing such a change will definitely make some people having a very bad time.
Introducing scalability issues Adding a bottleneck, this change will introduce severe scalability issue when it come to upgrade scaled Dolibarr instances. If we are targeting Kubernetes deployments for example this will definitely be a problem. Many complex tricks will be required in order to make this work. But at what cost?
I hope my answers are not coming rude or anything. I really appreciate what we are doing here and being a NGINX/PHP-FPM guy I really hope we could get this integrated very soon. But I have some strong concerns about the approach. Cheers, |
|
Hi,
Don't worry, In my case this isn't urgent and this shouldn't be rushed.
When restarting a container I want to restart only one service that's misbehaving, and I expect the container healthcheck to report the state of one service, not a stack. As an example, if I tweak the web server or PHP config, I want that docker to crash and don't take the rest of the stack with it (it's especially useful with Kubernetes deployment).
I do not agree with the immutability of the Dolibarr source files, some module adds files outside the custom folder, this is very bad practice but real production behavior. As an example, this is used to bypass Dolibarr limitation, like a module adding his theme folder (example : Oblyon v3) And patching the source code while waiting for a proper release need to stay even if the container is recreated with the same image version.
This is a big problem, but with proper documentation and warnings this can be mitigated.
When you update an app, you expect the code to be replaced, and that's why custom and documents are both in separated volumes. The container will not erase peoples data with proper configuration : Line 163 in ad408d9 (I should add
End user should not use Docker if they don't know how to use it, at least they should stick to premade example with documentation or use other means to host Dolibarr. If we stick to the Nextcloud example, this is why Nextcloud All-In-One image exist.
The main problem reported on those issues is caused by slow storage and readiness probe failing. I like challenging my view of things, it is (for me) the best way to improve outside his comfort zone. Regards, |
This PR add the support of "variants" images in the update process, like FPM.
To allow PHP-FPM to work properly with an external web server, the
htdocsneed to be accessible outside the PHP container.This is done by storing Dolibarr original
htdocsinto/usr/src/dolibarrand on install or update, this folder isrsyncinto the/var/www/htmlvolume.This is not limited to a Nginx container, this could be used by a Kubernetes Nginx Ingress, Caddy or a host Nginx server.