/var/www/html data volume?

[mautic]

/var/www/html data volume?

[rvalle]

@nilyin that is the point.

IMHO the ideal mautic distribution would be:

• Compose file with each process in its container
• Codebase (including plugins) distributed in the image (versioned matching mautic codebase)
• Configuration via environment variables (including which plugins should be enabled).
• Data in a separate volume (including data only, excluding mautic/plugin code).

benefits:

• update process is simplified, just a docker pull
• it is possible to pin a given version, in case an update breaks something.
• it is always possible to go back to a previous version, even if something goes wrong after pulling an update (provided data volume is backed up).

For this to be possible mautic would need to:

• be able to detect that it is running on previous version's data and migrate it automatically (probably can already).
• have proper separation of code/data
• should be aware of been running inside a docker container and not offer to perform updates but just inform that a new version is available and can be pulled.

[rvalle]

If the container contains all mautic distribution and the version tag matches mautic version then the community can choose when/how to update.

They can use a pinned version number such as "2.15.1" or "latest" version depending on how critical the environment is, and what their update policy is.

Obviously they should backup data volumes to ensure they can go back to previous version if the update process goes wrong, or the new image is buggy.

For this we would also need to tag the images with the mautic version, but that should not be a problem either.

[MikeDaniel18]

Would like to chime in too that the current structure doesn't make a great deal of sense. The application code should be baked into the container, not compiled into a volume on run. As it stands, there's really no benefit to using Docker in this way and it makes for a very messy container - though I appreciate that using Docker more appropriately would likely invalidate the current upgrade script.

[rvalle]

Hello @luizeof

to me, the question is why running mautic under docker at all?
I see one key benefit is to easily maintain updates. Mautic is going to be out there on the internet, with email connectivity, etc.

I think this can be achieved the whole mautic distribution comes in the docker image, and user data is stored in docker volumes.

At startup, mautic should be able to decide if the data volumes belong to an older image or not and trigger update procedures when required.

This would pave the way to unsupervised docker updates.

Do you think this is achievable?

Mautic should be written in a way that:

• User Data / Mautic code are well separated in the file tree.
• Mautic can deduce when an update producedure needs to be launched.

Do you think this is already there or easily achievable?

[luizeof]

Hello @rvalle

the Mautic files reside in the /var/www/html folder, as well as the app/themes and app/media folder that are used to store users' files.

By the way mautic is developed, I do not advise updating it just by recreating the container. Some caching and database operations are usually required.

Mautic also offers a simple script that can be used to upgrade. https://github.com/mautic/mautic/blob/staging/upgrade.php

[luizeof]

@rvalle

I think it's possible to do this with Docker. But I do not know how it would be for the rest of the community to just re-create the container and update the Mautic ... many people wait a while before updating

[aspiers]

@luizeof commented on April 1, 2019 8:52 PM:

Hello @rvalle

the Mautic files reside in the /var/www/html folder, as well as the app/themes and app/media folder that are used to store users' files.

I think @rvalle makes a good point. Is there any reason why docker-compose.yml couldn't be changed to mount user files from separate volumes? Isn't this basically the same as the discussion in #2? Docker images are supposed to be stateless, so if currently Mautic is storing non-disposable state inside the container, it needs to be separated out.

By the way mautic is developed, I do not advise updating it just by recreating the container. Some caching and database operations are usually required.

Mautic also offers a simple script that can be used to upgrade. mautic/mautic:upgrade.php@staging

Is this any different from doing an upgrade from within the web UI?

[nilyin]

I also support the idea to separate app code location from user's data so we could mount these volumes separately. Also web server would be better to separate as well, as docker's idea is a single process containers. So please publish a recommended docker-file for: mautic app + php-fpm, nginx, cron, maridb containers.

Now I don't understand how to use fresh mautic docker images to upgrade my existing setup. Documentation says that image unpacks mautic app into /var/www/html folder, but this volume is already mounted with existing setup and contains my data, as was recommend in you own example of compose file:

mautic:
container_name: mautic
image: mautic/mautic:v3
volumes:
- mautic_data:/var/www/html

so, what will happen if after user's docker-compose up the new mautic container will detect that such "mautic_data" volume already exists? it will mount and use old data and application code instead of new one, right? It means that mautic version update will not happen. If you can suggest a temporary workaround, I'll appreciate that.

[nilyin]

++

another potential benefit is that we can implement Mautic multi-tenancy (multiple own Mautic Landing pages on same host or cluster) by using containers' separation with one dedicated container for database server.

[iBobik]

I am going to work on this. I just does not know Mautic, could you please help me what to not forget about in #184?