Easy Docker dev environments for PHP with CloudEstuary

Lately I’ve been messing around with Docker, and specifically with containerizing PHP applications to perform quick services, such as static analysis of PHP code, compatibility of existing PHP code to specific versions of PHP, and performing security checks on PHP libraries included in my projects. However, I’ve not created a development environment for my projects using Docker.

Like most professional PHP developers, I’ve been using Vagrant to create virtual environments for most of my development. It works fantastic, but one of the downfalls is that it leads to a large VM file for each virtual machine taking up disk space on my laptop. This is unfortunate for a consultant like myself, who creates a separate VM for each client.

But today I found another way. A way to easily create PHP development environments with Docker. The fine folks at CloudEstuary have created an easy to use web-based tool to create PHP development environments (yml files) for use with Docker-compose.

CloudEstuary

The entire process was super easy, assuming we already have Docker and Docker-Compose installed.

Create a Project

To start I selected the framework, of which I decided to try this with the very popular Zend Framework in an application I’ve been working on, so I clicked the Zend Framework icon. The tool chosen will cause the runtime settings in the next section to be altered to accommodate.

Next I added a custom name for my project and chose PHP 7.1 for the Runtime, but left the rest of the items set as default.

Following that, there is a list of pre-existing Addons to be enabled as desired. It seems Postgres is selected by default, but it is simple enough to Remove it and select another solution if desired.

 Then the final step, as of this writing, was to add any workers if I desired. I’m not sure of the limits of what can be put there, but I’m sure documentation will be forthcoming.

Then, finally, I was able to click the Generate Docker Compose button to receive the docker-compose.yml file. The final result was a brief explanation of what to do next, and of course, the file contents.

The docker-compose file expects to be placed in a directory where the application to be served resides in an ‘html’ directory. Don’t worry, you can change this as needed. In my case I simply change the following portions of the yml file (3’ish places):

To become:

I placed the docker-compose.yml file to the root of my Zend Framework application. (on the same level as the composer.json file)

Additionally, I have a local installation of Apache running on port 80, so the docker-compose file would not work for me out of the box. It sets the Nginx server port forwarding to expect the host port 80 to forward to the Docker container port 80. So I updated the ports from this:

To become this:

Use It

Now I was ready to fire up the Docker container. I did this via CLI by navigating to the root of the application and issuing the docker-compose command.

After a couple minutes of Docker fetching various images, the container was running. Note: the terminal continues showing what it happening inside the container. (Nginx and other apps logs are output to the terminal)

Now I was able to pull up my awesome Zend Framework PHP app in the browser using the address http://localhost:8888

Add Account

One other nice feature of the site is the ability to create an account. I am told there will be more functionality around this later, but for now it allows you to see a list of all projects you’ve created, and enables you to edit the configurations.

Simply click the link to create an account:

Then you can see projects created while you were logged in via the “My Projects” menu item.

Closing

I hope you found this post helpful. Using Docker to create PHP development environments is easy. Enjoy!

Setting up local step debugging with Zend Studio

Setting up debugging in an IDE with a local PHP development environment has gotten so easy it can be done in a couple automated steps. In this post I will demonstrate how to get step debugging functioning with Zend Studio and Zend Debugger when the server is set up on a local environment.

To begin with, I had the following:

  • Local installation of Zend Server 8.5.+ (basic LAMP stack, but with Zend Debugger included in the Zend Server installation). Alternatively I could have had a vanilla LAMP environment with Xdebug.
  • Ensure that Z-Ray is active in the Zend Server settings.
  • A local project set up on Zend Studio, without the server set up in the Zend Studio project configuration. (in this example I have a Zend Expressive Skeleton ready)
  • The local project set up as an Apache virtualhost.

Ensure Zend Studio is running with the project we will debug open.

In a browser with the application rendered I click the debug icon in the Z-Ray toolbar at the foot of the window, and select the desired debugging action.

This will cause Zend Studio to prompt if we desire to use the Debug Perspective after it receives the debug connection from Zend Debugger. In most cases we can simply click Yes and let things happen normally.

That’s about it, we are debugging!

Closing

This was a very simplistic local development environment setup. We didn’t have a firewall to contend with, and the server was set up locally rather than inside a virtual machine. I have other posts, linked below, to help with some of these alternative setups.

Happy Debugging!

Other posts on Debugging you may find helpful:

Setting up local step debugging with PhpStorm

Setting up PHP debugging in an IDE with a local development environment has gotten so easy it can be done in a few automated steps. In this post I will demonstrate how to get step debugging functioning with PhpStorm and Zend Debugger when the server is set up on a local environment.

To begin with, I had the following:

  • Local installation of Zend Server 8.5.+ (basic LAMP stack, but with Zend Debugger included in the Zend Server installation). Alternatively I could have had a vanilla LAMP environment with Xdebug.
  • Ensure that Z-Ray is active in the Zend Server settings.
  • A local project set up on PhpStorm, without the server set up in the PhpStorm project configuration. (in this example I have a Zend Expressive Skeleton ready)
  • The local project set up as an Apache virtualhost.

With the project open in PhpStorm I click the icon to inform the IDE to start listening for debugging sessions. (Usually in the upper right corner, looks like a telephone receiver with a red indicator that it is not listening, and turns green when you click it)

Then a browser with the application rendered I click the debug icon in the Z-Ray toolbar at the foot of the window, and select the desired debugging action.

This will cause PhpStorm to prompt after it receives the debug connection from Zend Debugger. In most cases we can simply click Accept and let things happen normally.

That’s about it, we are debugging!

Behind the scenes, PhpStorm created a site and associated it with the project.

Of course we could have created the server ahead of time and not be prompted to Accept the incoming connection, but what is the fun in that?

Closing

This was a very simplistic local development environment setup. We didn’t have a firewall to contend with, and the server was set up locally rather than inside a virtual machine. I have other posts, linked below, to help with some of these alternative setups.

Happy Debugging!

Other posts on Debugging you may find helpful:

PHPMyAdmin blank whitescreen (414 Request-URI Too Long)

Ran across an interesting issue where PhpMyAdmin on a newly installed CentOS server was not rendering in a browser. Or more accurately, it was rendering but the CSS kicked in and caused the browser to display a blank page rather than the desired login screen. (Doing a View Source on the page showed that the login form was in fact there, but hidden by CSS.)

After checking the obvious things: PHP running (with error reporting on), file permissions, Apache working, VirtualHost definition correct, I was stuck. There were no indications of a problem, and PHP reported nothing. (Because, as we will see, there were no errors to be displayed…or was there?)

Finally, I turned on Firebug and refreshed the page. Voilà! There were actually two issues, but they were hidden within additional calls in the backend:

Screenshot from 2016-05-05 17-29-03

Wow, those two long URL strings! One URL was:

https://{domain-withheld}/phpmyadmin/js/get_scripts.js.php?scripts%5B%5D=jquery/jquery-2.1.4.min.js&scripts%5B%5D=sprintf.js&scripts%5B%5D=ajax.js&scripts%5B%5D=keyhandler.js&scripts%5B%5D=jquery/jquery-ui-1.11.4.min.js&scripts%5B%5D=jquery/jquery.cookie.js&scripts%5B%5D=jquery/jquery.mousewheel.js&scripts%5B%5D=jquery/jquery.event.drag-2.2.js&scripts%5B%5D=jquery/jquery-ui-timepicker-addon.js&scripts%5B%5D=jquery/jquery.ba-hashchange-1.3.js&scripts%5B%5D=jquery/jquery.debounce-1.0.5.js&scripts%5B%5D=menu-resizer.js&scripts%5B%5D=cross_framing_protection.js&scripts%5B%5D=rte.js&scripts%5B%5D=tracekit/tracekit.js&scripts%5B%5D=error_report.js&scripts%5B%5D=config.js&scripts%5B%5D=doclinks.js&scripts%5B%5D=functions.js&scripts%5B%5D=navigation.js&v=4.6.1

A quick search uncovered a possible fix. The default Apache limit of the request line needed to be made longer to accomodate PhpMyAdmin. Doing this was simple. I added the directive to ‘/etc/httpd/conf/httpd.conf’ like so:

LimitRequestLine 800

I tried a few different lengths and found that 700 was too short, but 800 worked fine. Also, though I simply added this to the conf file, according to the docs you can add this within the VirtualHost rather than making it blanket covering the entire server.

Hope this helps others.

Ubuntu 16.04 and PHP 7 not rendering

After reloading my work laptop with Ubuntu 16.04 LTS (I prefer to do a reload versus an upgrade, for each LTS version) I was very excited to install PHP 7, and installed using the standard Ubuntu repositories using typical commands:

$ sudo apt-get install apache2
$ sudo apt-get install php7.0

However, after doing the installs I discovered PHP scripts would not render in a browser. After a small amount of digging I realized that doing the base installs did not include one important piece. The package ‘libapache2-mod-php7.0’ was not automatically installed as expected, as it did in the past. (I don’t remember needing to install it separately in the past.) Hopefully the package maintainers fix this at some point. Your mileage may vary.

$ sudo apt-get install libapache2-mod-php7.0

So one quick install like shown previous and all is working fine.

Happy PHP’ing.