Blog Details
Blog Post Actions
Related
Recommended

Developing Sugar on Docker

Enrico Simonetti
8 minute read time

TLDR 

Developing Sugar on Docker, get up to speed now!

The long version

What are Docker containers?

If containers for you are more than the two pictures below… then you are in the right place!

As you might be aware, there has been and there continues to be a lot of hype around containers. The hype really started with Docker, but containers have been around for a while (more or less), in a different shape or form. If you are not yet familiar with containers or are confused about the difference between a virtual machine and a container, this blog post from Docker might be useful to you.

Personally, I was deploying container-based virtualised single purpose hosting environments (now labelled micro-services?) for my customers, back when it was not so trendy. It was about 10 years ago when I was leveraging OpenVZ. OpenVZ is slightly different (eg: it has state/persistent storage for every container), but in the end you can run multiple lightweight containers that share the custom linux kernel of their host.

What Docker has managed to do differently is make infrastructure deployments repeatable and portable. An application can be shipped together with its Docker container directives, providing the same exact configuration across different host environments. The infrastructure looks more like code, which simplifies the process of automating and delivering software deployments. Teams using Docker found that the lines between development and operations blurred even further, and guess what? DevOps was born!

Docker has made it easy to get up and running with a technology for development purposes. A developer just needs Docker installed on his or her local machine (or on a linux VM) and a “Dockerfile”, to get an application up and running. If he or she needs to replace a single component of the infrastructure for testing purposes, they simply swap a few directives and re-build. The same application is executing on top of a slightly different platform. How awesome and easy is that?

With the always increasing pace of software development innovation required today, and with applications becoming more and more decoupled from each other (and at the same time integrated), development teams need to keep their deployment velocities up as well quickly deliver innovation across the board on a multitude of heterogeneous backends.

This need for a fast deployment velocity can be fulfilled with the aid of flexible containers and orchestration technologies when their delivery is seamlessly baked into the traditional software development pipeline. Obviously containers are not the silver bullet or the answer to every known question, but they are currently applicable to a vast set of different workloads and use cases.

Docker in production

At this stage, I do not have direct experience with Docker in production environments, but, as with any technology, there is always someone willing to share their horror stories…

Jokes aside; with the increase in popularity of orchestration, the extensive backing and support from various cloud providers and how lightweight it is, I am convinced Docker is the way to go for micro-services deployment and orchestration in production environments as well. As a matter of fact, container-technology adoption is constantly growing across the board and not just for micro-services.

Sugar on Docker

Enough said about the containers topic. Here it is, my attempt at creating a set of development stacks for Sugar with Docker.

I have to thank one of our long-standing partners Cédric Mourizard from Synolia for the initial work (read more in his previous blog post). The Sugar Docker setup has been polished here and there over the past 6 months, and it is now to a point where I only run Sugar locally with this solution.

I highly encourage you to give it a try. Have a look at how Docker can fit in your development process, and, if it does not yet fit into it, think about how it could help you streamline your overall software delivery pace and capabilities.

Flavours used

Let’s give a quick overview of the various components used. When using *nix, I’m a Debian kind of guy. So that’s that.

LAMP stack, Elasticsearch and Redis on top of Debian.

Stack components

It might evolve over time, but for now the main containers are:

  • Apache load balancer - Load balances requests between the cluster of Apache PHP web servers, round robin
  • Apache PHP web server - Web server(s)
  • MySQL database - Database
  • Elasticsearch - Sugar search engine
  • Redis - Two purposes: Sugar object caching service and PHP Session storage/sharing service
  • Cron - Sugar background scheduler processing. Note that this is enabled immediately and it will run cron.php as soon as the file is available, and it will attempt to do so every 60 seconds since its last run
  • Permission - Sets Sugar instance permissions correctly and then terminates

The application files are shared on the “cluster” (if you can call it that) through a directory based mounted volume to offer persistent storage. We also have various persistent storage directories within ./data/ for all the other software components that need them.

Based on the selected stack (within the ./stack/ directory) you will be able to pick and choose the various versions of the stack components available, and to decide if you want a load balancer and multiple web servers or just a single web server during initial development phases. Because the Docker containers are stateless, it is possible to run the same Sugar installation (stored on the persistent volume) either with PHP 7.1 or PHP 5.6 and swap between versions within seconds.

Current software versions

Currently, there are a few stack combinations available that run the supported platform for Sugar 7.9.

Containers are available with PHP 7.1/5.6, MySQL 5.7, Elasticsearch 1.7.5 and the latest Redis. When selecting a stack, it is possible to run it as a single web server or as two web servers behind a load balancer.

Sugar 7.10 is not available for on-site hosting but it can be downloaded for local development, so, I have prepared a single stack leveraging PHP 7.1, compatible with the required matching platform. The main difference in stack requirements between Sugar 7.10 and earlier versions is the Elasticsearch version 5.4 requirement. Elasticsearch 5.4 seems to be more memory hungry, so be prepared for that.

Finally, there is an additional stack for 7.9 upgrades, running both Elasticsearch 1.7.5 and 5.4, to allow future testing of upgrades to the Sugar Spring '18 release.

Getting up and running

Most of the details you need to get up and running are within the README.md of the git repository. In terms of where to run this setup, you have the option of leveraging docker-machine or to run your own VM, as currently the native Docker for Mac does not perform well with the mounted volumes for persistent storage.

I personally use a Debian VirtualBox VM on a Macbook. If you want to run the same VM as I do, I have prepared a VirtualBox appliance export. You can find the appliance on this repository, as well as more details on how to deploy it on your Mac. It runs a NFS share as well, so that you can mount the directory locally and code with your preferred editor.

During my process, I’ve also tried Vagrant to help with automatic deployment of the VM instead of building an appliance, but I did not obtain the same performance footprint (not even close). So I abandoned that route long ago.

Now you are up to speed with Sugar on Docker, and you might have realised how containers can help your business gain velocity.

Feel free to let us know your thoughts, by leaving some comments below!

  • in reply to Hector Rios

    Hi Hector Rios,

    Thanks for the answer. The problem i have is i don't have a Mac, i have a Windows and in Docker for Windows, docker enables hyper-v and if hyper-v is enabled, virtualbox just stop working. So i have to try creating the debian machine with hyper-v.

    But the docker-sync tool i mentioned into my last message uses unison to sync files. But i'll try to install unison in my windows host and into one docker container and i'll try the performance.

    I hope that docker into the future will find a way to not lost performance into windows and mac hosts and we can develope with docker without tricks.

    Thanks!

  • in reply to Diego Celdrán

    Hi Diego Celdrán

    I make use of a setup close to what you have and regarding the question...

    So, what do you do is have one virtual machine with Debian and NFS Server, mount that nfs server to your Mac host files and into the Debian machine you have docker installed and you use docker into the debian machine right? 

    And the performance is fine? at the end you are virtualizing inside virtual machine (if I understood it well)

    Yup the performance is actually very fast! QuickRepair and Rebuilds take roughly 3 to 4 seconds as opposed to the 15 to 30 seconds if I leverage Docker-for-Mac. As Enrico mentioned previously there is no perfect setup when you want to use PHPStorm as your IDE. One setup that could help with the PhpStorm indexing issue is to use a FileSynchronizer like Unison. You could have the Sugar installation files on your Mac for ease of use with Unsion synchronizing any changes back to the Linux VM. Working with Unison to synchronize files between two machines is a bit tricky because you have to install Unison on each machine and the versions have to be same on both machines.

    Therefore, a cool work around proposed by Enrico Simonetti himself is to synchronize the files between two locations on the same machine (in this case your host Mac). You could synchronize the files from the sugar install directory to the NFS mount and thus get the best-of-both-worlds. I tried it initially and it worked quite Ok. I don't use it anymore though because I learned to live with PhpStorm indexing limitation but more importantly I always seemed to forget to connect to the NFS Server  

    Hope it helps

    -Hector

  • in reply to Enrico Simonetti

    Hi Enrico Simonetti,

    First of all, thanks for the answer. 

    So, what do you do is have one virtual machine with Debian and NFS Server, mount that nfs server to your Mac host files and into the Debian machine you have docker installed and you use docker into the debian machine right? 

    And the performance is fine? at the end you are virtualizing inside virtual machine (if I understood it well)

    Doing a research of this problem i found this: 

    Home · EugenMayer/docker-sync Wiki · GitHub 

    I'll try to use both solutions and i'll post if i could fix the problem.

  • in reply to Diego Celdrán

    Hey Diego Celdrán,

    I had a quick look at threads about Windows 10 and native docker performance issues and I suppose there is not much you can do about that.

    What you could do (similarly to your current Vagrant solution) is try to adapt to your configuration the virtual machine appliance provided with the SuagrDockerized repository, for OSX (see bottom of the repository's readme).

    I experienced similar disk related performance problems with my OSX setup, and that's the setup I use to mitigate them.

    The provided appliance includes a NFS share server, that should give you better performance from your Windows client.

    Give it a try and see if that works out for you as well, but you might have to tweak the setup process along the way, as not all the instructions will match perfectly

  • Hi,

    Actually i'm using vagrant to do local development with SugarCRM. The problem i actually have is the shared folder system to connect vagrant and host system (i have Windows 10) so the "solution" i use is do a "reverse" shared folder, all the items are in the vagrant machine and i connect to them with windows 10 network drive through samba service.

    With this way, my SugarCRM instance is fast and i can develope with phpstorm connecting to the shared folder (slow performance indexing files).

    Now i am trying docker, i think docker is more powerfull than vagrant but in the end i have the same problem that i have in vagrant, the slow shared folder system.

    I know in linux systems the shared folder are faster than in windows or mac, but for some reasons y need to have a Windows 10 host.

    If i use your docker stacks, i need to share the mysql database folder, app folder... so, how do you do to develope with slow shared folder performance?

    thanks!!