4 replies to this topic

[joeldeteves]

We created a public Docker image for X2CRM v6.9, running php7-fpm, NGINX and the superbly lightweight Alpine!

 

Get it here 

https://hub.docker.c...p/docker-x2crm/

 

Feel free to inspect and / or fork the code on GitHub:

https://github.com/p...ap/docker-x2crm

 

Feedback welcome!

[that0n3guy]

Its good to see others using docker.  We've been running x2 on docker for about 3 years now.   Updates can be interesting, but otherwise works great.

[joeldeteves]

@that0n3guy, super happy to hear that we're not the only ones using Docker also! I'm curious as to how you handle updates? Right now, we're just mounting the whole thing as a volume and downloading from master since the version tags on github are asking for a license key. Do you mount specific folders? And for version tracking, do you just make sure you never delete the old images on Docker?

[that0n3guy]

We don't use volumes.   If we used x2's media entity (used to store files), we probably would have a volume just to store the media.  We just store our media elsewhere and don't upload to x2.

 

The entire x2 codebase is in the container.  Everytime we deploy code, our container is rebuilt and deployed.   We can delete the container and recreate it and it works just fine.

 

We are on 6.5.2 at the moment (we like to lag behind because x2 does funky things sometime, like removing process flows in 6.9).   Our update process is still our old way of doing it before x2 had a git repo on github.   We keep our own git repo.   Someday we will have it so that the latest merges into ours.... but now yet. 

 

Here is what we do:

 

on local:

• Update within x2's web interface on the local (this will update local db and local code)
• Add x2's updated code to git: `git add .` and `git commit -am 'updated to vX.x.x'`
• Push git repo to a non-master branch, lets call this 69updateBranch

On staging

• use the old master repo (non-updated code base) container
• Update within x2 within the web interface
  •  This will update the staging db and the code inside the staging container.   If the container is recreated, the old code will come back, soo....
• we deploy the v69updateBranch to staging.   Now db and code base will always match even if 

On production

• do what we did on staging .
• the only difference is that at the end, we merge in v69updateBranch into master so its deployed to production.

 

This sounds complicated, but its not really.  Update via web, make sure container code has updated code to match the db.   The reason we update via the web is because x2 used to be very poor at updating their code base.   We found that updating by using the code base and migrator commands and not with the web would end up with missing files.   It was like their code was made for new installs, but not for updates (very weird I know, but that's how it was).

[joeldeteves]

This is awesome info - thanks a lot for sharing! Definitely useful!