I this post I want to describe how one can easily setup a development setup incl. various development versions and with a copy of the production backup.
Prerequisite
- container environment on desktop (or on servers or in the cloud)
I use podman desktop on my mac, but you can probably use some docker version as well - git
- a copy of the backup file from Dolibarr, you can get it from this page from your production Dolibarr
/admin/tools/dolibarr_export.php?mainmenu=home&leftmenu=admintools
Container setup
I run 3 containers pr. version of dolibarr I want a dev setup for. These 3 containers are:
- Dolibarr container in the version(s) I want. develop, 21, 20 + perhaps 19 and 18
- mariadb in the latest version
- phpmyadmin in the latest version
In all cases I configure the mariadb container to use the dolibarr backup file as to init the database. I have downloaded such a backup to my ~/Dolibarr_backups folder. In podman I do it like this:
RESTORE_FROM_FILE="mysqldump_dolidb_20.0.4_2503282048.sql.gz"
RESTORE_FROM_PATH="~/Dolibarr_backups"
--volume "/Users/jonbendtsen/${RESTORE_FROM_PATH}/${RESTORE_FROM_FILE}:/docker-entrypoint-initdb.d/${RESTORE_FROM_FILE}:rw" \
The advantage of this is that all my mariadb containers used by different versions of dolibarr will start with the same data. It might be that these data in the database are being reset on every start of the mariadb container, but it could also be that I have to remove the mariadb container and create it again.
Password security
The easiest setup is to just use the same password across all versions you want to run in parallel. It is even super easy and convenient to fall into the trap of using the same password as in your production dolibarr. DO NOT DO THIS.
You should create scripts and/or container setup that ensures that each dolibarr version you run in parallel has different passwords, and preferably these should be randomly generated for the development versions.
Use a password manager service for when you copy this setup to run for multiple customers or even just one setup for a single company where you have different milieus like:
- development
- testing
- staging
- pre-prod
- production
Podman pod
I use podman pods because it creates a unit for containers where network connections can freely flow between each container inside the pod, and all containers just connect to all the other containers using the local host connection.
I then on the pod create 2 and only these 2 ports:
- one port for dolibarr
- another port for phpmyadmin
- no public port for the database
Podman secrets
You could use podman secrets for sharing passwords between the different containers inside the pods. Podman secrets can be used as environment variables inside containers - or as files. Files could be used for certificates.
I am sure docker (or kubernetes) has something similar.
dolidb
This database is used by dolibarr in the DOLI_DB_NAME environment variable and it must be identical to this environment variable in the mariadb container MARIADB_DATABASE.
You can all it any valid database name and it can even be the same across all the different dolibarr version you run because for each dolibarr container there is one and just one mariadb container.
doliuser
Just like for dolidb the same setup applies.
dolipass
haha, no my password is not dolipass, but I hope you get the understanding. This password is also shared between 2 containers, dolibarr and mariadb, they call it DOLI_DB_PASSWORD and MARIADB_PASSWORD respectively.
database root password
This password should be randomly generated and for any production environment you should store it safely in a password manager.
Dolibarr does not need to know this password!
Mariadb of course needs a root password and has some environment variables to generate one randomly, but if you do that, then phpmyadmin has a hard time to connect to your database.
phpmyadmin uses this environment variable MYSQL_ROOT_PASSWORDand it must be identical to this mariadb environment variable MARIADB_ROOT_PASSWORD.
Port numbers
For development I like to use port numbers that correlates to the dolibarr version, here are some examples:
- 21080 for dolibarr + 21036 for phpmyadmin
- 20080 and 20036 respectively
- subversions? No problem
- 20 4 80 + 20 4 36 for dolibarr 20.0.4
git worktree
I start on github where I fork the dolibarr repository, then I clone that to my desktop. This clone I leave in the development branch. For the other versions of dolibarr that I want to run in parallel I use the git worktree command to create a new folder for a different version of dolibarr.
example commands for my git setup
- mkdir ~/doli_dev_setup
- cd ~/doli_dev_setup
- git clone $url develop
- cd develop
- git worktree add …/20.0/
- cd …/20.0
- git switch 20.0
- cd …
repeat steps 4 to 8 for each of the different dolibarr versions you want to run, 21, 20 + possibly 19 and 18.
dolibarr container setup
for each dolibarr version you want to run, I would pull the corresponding image version, develop, 21, 20, possible 19 and 18 as well. This image is used as a base for the dolibarr container, but I will also mount the corresponding folder from git worktree in each container on this path:
--volume ${HOME}/doli_dev_setup/${VERSION}/htdocs:/var/www/html:rw \
create the containers
From this I simply just create all the needed containers and pods, you can even script the git worktree commands such that you are sure that you
- have a folder with dolibarr
- that it is a git repository
- and that it has the corresponding dolibarr version
Start mariadb and dolibarr containers
You may not need to start the phpmyadmin containers until you actually need them, so don’t start it, or perhaps don’t even create it until you need it. For production setup I would leave a port defined in the pod for phpmyadmin, but I would not actually even create the container before I would actually need it.
Congratulations
You should now have different versions of dolibarr running in parallel all using the same database contents from the backup of your production dolibarr, and you can use this for your development purposes while still having real data.
Because of git worktree you easily have a setup from where you can branch out your branches and make changes to dolibarr that will immediately be shown inside the corresponding dolibarr container. No need to do anything other than reload in your browser and then the changes will be shown - or you look in either the dolibarr.log file inside the container or you look at the container log.
Upgrading your production dolibarr
This method can also be used to do a test upgrade of your production dolibarr with real data before you do the real switch.
Rollback option
You can create a rollback option by stopping the current production dolibarr container, but not the production mariadb container. Then you create a backup of your production mariadb, and use that file to init a new mariadb container, which you start, and then you create a start the new production dolibarr.
If everything goes well switch production to the new mariadb and dolibarr container, stopping the old containers, but not removing them just yet.
After some time prune the stopped mariadb and dolibarr containers. Maybe a week, maybe a month.
