Download The Code

So, you have two ways to install Magento 2 - the first is if you’re a core contributor whereby you clone the GitHub repo, the second is if you’re a systems integrator (SI) and are making a site for a client, in which case you want to install via composer. Essentially, everyone except core contributors should install via composer. I mistakenly went down the contributor route initially and cloned the repo, a small note there - the repo is huge! It took 522MB on disk, most of that being the .git directory, so I ditched that attempt and downloaded via composer instead using the following:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition magento2

Along this plodded until this happened:

Your requirements could not be resolved to an installable set of packages.

Problem 1 - Installation request for magento/product-community-edition 2.1.0 -> satisfiable by magento/product-community-edition[2.1.0]. - magento/product-community-edition 2.1.0 requires ext-mcrypt * -> the requested PHP extension mcrypt is missing from your system.

To enable extensions, verify that they are enabled in those .ini files: - /usr/local/etc/php/5.6/php.ini You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.

Well that’s annoying - I’m going to use docker or a VM, so it doesn’t matter what my host has. I could alter php.ini but I don’t see why I should have to, upon looking I can avoid it though with --ignore-platform-reqs, making the command I needed as follows:

composer create-project --ignore-platform-reqs --repository-url=https://repo.magento.com/ magento/project-community-edition magento2-composer

That took a fair while, but much better - I now have Magento as well as all its requirements with only 353MB disk space used.

Set Up The Environment

So, at this point I started looking in to getting docker running - I made my own image for phpfpm with all the requirements, and httpd, and got it all running and started setup. I won’t go in to how I did this as, suffice to say, it was very, very slow to run - setup actually aborted at Weee, and running the environment was not nice (very, very slow). After trying other methods I discovered the issue was due to me having mounted the root of Magento 2 to my docker container - the problem with this is that Magento 2 does a lot of file generation (for DI and so forth) which all goes in var/generation, and because this file resided on my host system (which was OS X), and because I was running through the new Docker beta (which uses an xhyve VM, and presumably some form of NFS or filesystem like vboxsf) the write performance (and actually, the read performance when reading all the files from the modules) was very slow, so things took ages.

The solution? I opted for using Mageinferno’s docker compose instead, initially I didn’t like the look of it because it was geared toward downloading via composer (and running commands) from within the container, and I’m just not used to that - I like to do everything from my host, but as it turns out that created the very slowness I describe above.

So, using this compose and Mageinfernos great set of images, the process went like this:

  1. Edit ~/.composer/auth.json to add my repo.magento.com keys
  2. Use wget to fetch the docker-compose.yml
  3. Alter the docker-compose.yml in the following ways (both documented by the way):
    • Set M2SETUP_USE_ARCHIVE to false
    • Uncomment - ~/.composer:/var/www/.composer
  4. Run docker-compose run --rm setup

At this point, Magento 2 has been downloaded and set up, but only the DB container remains running - the setup container has been removed (because we supplied --rm to docker-compose run) and the app container hasn’t even been created yet (because only the containers needed by the setup container were created and started), the next step is fairly cool I find - we’re going to copy the downloaded Magento 2 code (vendor and all) to our host machine, and then share only the app/code directory, this way the places that get written to (var/generation, var/cache etc) most, and also the vast majority of the places read (vendor) will reside within docker only, so the speed will be very quick, yet we can still add our own modules to the system - very nice! To do so, we do the following:

  1. Copy the downloaded code to our host OS - docker cp CONTAINERID:/srv/www ./
  2. Uncomment - ./www/app/code:/srv/www/app/code in docker-compose.yml

Now we’re ready to run! Just run docker-compose up app and browse to http://localhost:8000 (note - you should make a host file entry so that cookies function correctly).

I have to say, the speed of this solution vs having the entire codebase shared is like night and day - previously admin pages would take 10’s of seconds to load, and my MacBooks fan would spin up constantly, with this solution pages in the admin load in under a second with no fan activity, so that’s a good result!

Also, something I noticed along the way - I’d just run the setup (which downloaded all the packages via composer) and I then had to rm the container, “Damn” I thoguht to myself, I’m going to have to download all those packages again, but ahh no! I forgot - the docker compose file shared my ~/.composer directory, which contains the cache, so all items were loaded from the cache - great!

Thanks very much to Mageinferno for their fantastic docker images. They have posted an interesting and related post about docker speed, go give it a read if you’re interested.