Navigation

Blog Bg

Phalcon, Docker and Mongo

Friday 26 May 2017

As part of my recent experiments and research, I have been looking certain technologies that have caught my eye over the last year. Always keen to find a “More Betterer” ™ arrow to add to my bow, or a better bow, or even a better concentric target rings… I thought I would checkout two key pieces of technology together. Phalcon and Docker.

Phalconan open source, full stack framework for PHP written as a C-extension — and Docker — a Whale playing Tetris, (or as they prefer to put it: an open platform for developers and sysadmins to build, ship, and run distributed applications) — have been on my radar for a while, but I’ve not had a chance to test them out.

VirtualBox vs Docker

I’ve been using Vagrant and VirtualBox on and off for years, for different parts of projects. For instance, we used them at Tate to build the Python/Django replacement for the Art & Artist section. For that project, and many others, the system has worked well… however, there have always been issues to overcome.

  1. If you need to create systems that interconnect, that perhaps would live on separate servers, the provisioning and inter-communication configuration becomes a lot trickier.
  2. This may have been resolved by the community now (I’ve haven’t had the need to check recently) but in the past I’ve had a number of issues with the speed of the Shared folders for Virtual box.
  3. The drain on the host system once you start running multiple VMs can be prohibitive, so much so, that you start making your choices in terms of architecture linked to what you can run locally.

This is where Docker comes in. I always read a lot tech articles, and had obviously come across the fact that Docker has been specifically designed to avoid specifically point 1 and 3. So a definitely good reason to check it out.

Phalcon

In development, speed means you can do more. In business, it tends to mean you can sell more. In HR, it probably means there’s a problem somewhere.

Whatever you build these days, (excluding putting together your project’s team), it had better be fast.

Node took off because it was unique, and well thought-out, but also because for certain tasks, it was faster than anything else available.

This was probably a call to arms for those who code in slightly lower-level/secretive languages than front-end scripters ;) because now it seems every technology ecosystem (new and old alike) are broadcasting how fast their <INSERT YOUR LANGUAGE, FRAMEWORK HERE> operates.

Phalcon is no exception, but then something deserves to call itself “fast” if it is compiled in C. Which was exactly how it was sold to me by a fellow developer. Being someone who has dabbled with Assemble, C++, and then C# — I was keen to find out what would be possible using a web framework that might allow you to mix high-level with low-level.

Getting started

As is so often the case these days, whatever you search for, you can generally find a project that someone has put together… usually on GitHub. Which is a godsend for those with diminishing hours of daylight. So after trying a few repos I had found, to no avail, I came across the following:

https://github.com/phalcon/phalcon-compose

Which after a little bit of finagling the configurations, I managed to get up and running pretty quickly. After doing this, I set about the task of actually understanding what had been done by trying to recreate parts from scratch. There is no substitute for learning by taking to the time to bumble around, mess things up, and then debug.

My only complaint for the above repo, is that its documentation is a bit thin on the ground. Basically I think it assumes you already know quite a bit about Docker and, more specifically, docker-compose.

For those who, like me, where just getting up to speed, here are a few commands that may be useful.

Controlling your app

Once you have the root directory created, it should look something like this:

First up, you need to make sure you edit the variables.env file, and make environment changes that align to your specific configuration.

I also found that when running the full suite of included services, performance was atrocious (loading a simple phpinfo() page took 20s+) on my MacBook Pro (Retina, 15-inch, Late 2013). This may be because I’m still running Yosemite, and perhaps a particular dependency didn’t like it, or it could be something completely different. I have yet to investigate properly. Whatever it was, it was attempting to convince my laptop that it could fly, using only the power of its internal fans — which is never a good idea.

I didn’t need the full suite however, I was only really interested in getting a basic stack up, so I commented out everything save for mysql and mongo in the services and volumes definitions found inside docker-compose.yml (not forgetting to also comment out the removed services from the depends_on key inside the app service.

The default configuration for the app ports, found in docker-compose.yml also had to be changed — because I already had port 80 in use, so I switched it to 8009

app:
  build: docker/app
  restart: always
  working_dir: /project
  ports:
    - "8009:80"
    - "443:443"
  ...

Once that had be done I could rerun the containers using:

docker-compose up -d

Now on visiting http://0.0.0.0:8009 I could view the evaluated index.php file found in ./application/public which meant I was able to actually start coding with Phalcon — without needing to install anything directly on my host machine. Nice.

Interacting with Mongo

For my next step, I did something foolish. I didn’t read Phalcon’s documentation correctly, and made an assumption. If I had taken the time to read correctly, I would have noticed that Falcon comes with its own Database ORM that can interrogate MongoDB instances. Instead I only read briefly and learned that Phalcon’s ORM was designed to work with MySQL… Which wasn’t Mongo, like I wanted. So, I went ahead and started to pull in and configure doctrine/mongodb-odm, along with alcaeus/mongo-php-adapter for PHP7 support.

It took a bit of time, which I’ll never be getting back. However, I did get it working, I created my own collections and got them to persist successfully. I also learned a lot about the construction of the containers, and how to configure Doctrine’s Mongo DocumentManager, which is all useful stuff. But I think next time I’ll be a bit more thorough in my pre-configuration reading.