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!

  • Enrico Simonetti

    I am using the sugar subdirectory as the root for my clients. I have been switching the directory names to "sugar" and I am switching too many times. 

    For example "cp sugar clientBfolder" and then "cp clientAfolder sugar".

    I now have it like this :

    sugar/clientAfolder
    sugar/clientBfolder

    and of course, access like this "http://docker.local/sugar/clientAfolder/index.php", etc., etc.

    Can you please help me engineer cron containers for the ones I want to run cron? In other words, not sure how to proceed with copying your builtin container.

    :-)

  • in reply to Kenneth Brill

    Makes sense to me Ken. I think you would of had a better experience if you didn't need the virtualbox.

    Hope to see you at SugarCon if you go this year.

  • in reply to Enrico Simonetti

    I completely understand what you are saying here, I just wanted to make sure I wasn't missing out on something.  My mailbox is full of docker-this and docker-that to the point I though maybe I needed it.  But I think I fall into the category where its just a tool that I don't need.  In the end, I think I am going to dump virtualbox too and go back to having a actual development box over in a corner of my office and free up some resources on my Macbook.  I thought when I got the terabyte SSD drive I would never need anything else, but alias I have fond a way to accumulate 800G of clutter that I cant seem to let go of.

  • in reply to Kenneth Brill

    Kenneth Brill,

    For me the reasoning is exactly what Michael Joyner mentioned.

    It boils down to two essential factors for me:

    • repeatability
    • flexibility

    If you need to test an upgrade, you can swap infrastructure components in and out to test the system. If you need to narrow down an issue, you can do so easily without having to rebuild a full stack.

    Plus components are isolated pretty much as any production environment, even when in early development mode, and everything works without the need of doing anything special.

    Additionally all infrastructure components and the installed application are not affected by your desktop/laptop upgrades either.

    I hear your point about performance on Mac, I use OSX too. And not much can be done there unfortunately. It got a little better over time, but never near the performance of native linux.

    The extra hoop does not bother me too much tough. Not as much as it would bother me to setup a new infrastructure every time I need to do something slightly different.

    As an alternative you could have a linux box with your SugarDockerized stack inside. A spare oldish linux CLI box (or even an old laptop) with few GB of RAM might do. It does not have to be a VM on your local environment, using your resources.

    Finally, the docker stack does not HAVE to work for everyone. From my point of view it is just another tool you have available at your disposal if you want to take advantage of it. If you find yourself more comfortable developing on your own stack, or using Vagrant, or even installing LAMP locally, feel free to stick with it.

    Hope it clarifies your doubts and thanks Michael Joyner for chiming in with your experience!

  • in reply to Michael Joyner

    While all of that is perfectly valid, many of us develop for a single platform, our production server.  I occasionally take outside work when its interesting but most of my work is for one customer.  Production is always php 7.1 and MySQL 5.7 and when that changes we update the development instances to match it exactly.

    With that said, for my use case, I don't see any benefit to it other than if it worked well in MacOS it would be faster to spin up and might have less of a load on my memory and CPU.  It looked like that was true but it would take more testing to make sure.

    But if I have to run VirtualBox anyway I can see any benefit from using docker.  However I am glad I played with it and because fairly comfortable with it as you never know what the future holds.