ERROR: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

The easiest (and most brute though) solution to this is to prune all networks, as suggested here on SO.

docker network prune

This will delete all networks that are not connected to currently active containers.
But this also means it will delete all networks of your not runnning dev projects.
(Which might be numerous as in my case.)

2. So next time you spin up another dev project the network will be missing, as it has been pruned and you will see this error:

Could not attach to network 726...: rpc error: code = NotFound desc = network 726... not found

Ok sure, the network is gone, but no problem let’s recreate it.
As described in this blog post.
We can simply add the —force-recreate option to docker-compose up and run it once then remove the option again to continue as usual.

docker-compose up --force-recreate

Also described here on SO.

Then we are back to normal in our dev docker environments.

ERROR: for docker_myproject_phpmyadmin_1 Cannot start service mg_myproject_phpmyadmin: network 15dff95a23808fe9d14b3dae71c0daeaa8b274c90566baa5beff37f3738033b6 not found

For some reason the networks were deleted and docker-compose doesnt automatically recreate networks unless you tell so by forcing docker to recreate containers:

docker-compose up --force-recreate

Solution came from this issue:
https://github.com/docker/compose/issues/5745#issuecomment-370031631

Probably i have to explicitly declare the networks to prevent mixups between projects.
Though i thought this would not be necessary…

Update: Today i would rather use the IntelliJ Database Tool for Sqlite administration.

But since Adminer is a popular hacking target they introduced a feature that does not allow to run adminer without a password, out of the box.
Sqlite database usually runs without password and dang, workaround needed!

So we need to add a plugin to adminer that allows password-less login and extend the official Adminer Docker image to include the plugin.

We add a script that loads the official password-less-login plugin and copy it to the plugins-enabled folder of the Adminer image

login-password-less.php:

<?php
require_once('plugins/login-password-less.php');

/** Set allowed password
 * @param string result of password_hash
 */
return new AdminerLoginPasswordLess(
    $password_hash = password_hash("admin", PASSWORD_DEFAULT)
);

Dockerfile:

FROM adminer
USER root
COPY login-password-less.php /var/www/html/plugins-enabled/login-password-less.php
#USER adminer # we run as root because of permissions problems on db file with the volume

In docker-compose.yml:

version: "3"
services:
  app:
    build: ./php
      - mailcatcher
    volumes:
      - "../:/app:rw"
      - "./php/cli/php.ini:/etc/php/7.3/cli/php.ini:ro"
      - "./php/fpm/php.ini:/etc/php/7.3/fpm/php.ini:ro"

  nginx:
    build: ./nginx
    depends_on:
      - app
    command: /bin/sh -c "nginx -g 'daemon off;'"
    volumes:
      - "..:/app:rw"
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - '8088:80'

  adminer:
    build: ./adminer
    restart: unless-stopped
    volumes:
      - "..:/app:rw"
    ports:
      - 8080:8080

File tree:

• adminer
  – Dockerfile
  – login-password-less.php
• nginx
  …
• php
  …
• docker-compose.yml

Note that since docker-compose.yml version 3 the volumes_from directive was removed in favor of top level volumes to share volumes across images. However this implementation is imho rather weird, so i jut duplicated the volumes declaration in the App container and Adminer container.
Feels rather wrong but thats all i could come up with. Any advice here is welcome.

Now that this is done we can open the Sqlite3 database with the pseudo-password “admin” and manage the database.

After all you could also just copy the one-file Adminer with plugin to the php container and run it from within the php container. Just adjust your Nginx config to allow calling the file directly and take care to not deploy Adminer to live.
There is also a project that bundles the plugin with Adminer to one file: https://github.com/FrancoisCapon/LoginToASqlite3DatabaseWithoutCredentialsWithAdminer/blob/master/build-adminer-4-sqlite3-into-one-file.sh

An exception occured in driver: SQLSTATE[HY000] [1130] Host ‘172.17.0.5’ is
not allowed to connect to this MySQL server

The reason for this is not quite clear yet but i usually resolve it like described here.
Note that all data stored in the project will be lost!
So this error is quite annyoing but luckily i work on fixtures so i can restore data easily.
These steps let me connect to the mysql container again, at least.

1. Run an inspection on the mysql container:

docker inspect my-project-with-mysql

And search for the data mounts of the mysql container to know where the data is stored on my machine because i need to delete them, aargh:

{
   "Mounts":[
      {
         "Type":"volume",
         "Name":"db9aa2f8a43c08",
         "Source":"/var/lib/docker/volumes/db9aa2f8a43c08/_data",
         "Destination":"/var/lib/mysql",
         "Driver":"local",
         "Mode":"",
         "RW":true,
         "Propagation":""
      }
   ]
}

The path can be found in the “Source” property.

2. Now i remove all containers to start anew:

docker-compose rm my-project-with-mysql

3. Then i remove all data in the mysql container. My assumption is that somehow the data in the system tables got corrupted.
So delete all contents and restore the directory:

sudo rm -rf /var/lib/docker/volumes/db9aa2f8a43c08/_data
sudo mkdir /var/lib/docker/volumes/db9aa2f8a43c08/_data

4. Finally rebuild the containers

docker-compose build
docker-compose up

5. Now i run the scripts that will populate the database from the fixtures again and the problem is fixed.

If you know the reason for this error please let me know.

When I first tried docker (docker-toolbox for mac) I was really disappointed how slow symfony apps ran inside the container.

I did a bit of research (didn’t completely get it though) – but most of the speed issues that people experience seem to be related to the rather slow file system access in mounted folders.

That’s where dlite really shines.
It’s an app that uses some sort of alternative to virtualbox etc. which has significant speed advantages.

I highly recommend you give it a try if you’re developing with docker in OSX.
Installation with homebrew is quite simple:

brew install dlite
dlite stop && dlite update -v 2.3.0 && dlite start
brew install docker
brew install docker-compose

Another thing I found quite challenging was setting up permissions when running symfony inside docker.
I found a couple of tutorials on that but none of those seemed to really work with my setup.

You could use data containers for the cache and log folders and don’t have any permission problems.
Or just use some internal folder `/tmp/myapp/cache` or `/dev/shm/myapp` (the latter really is fast…).

But any of those approaches will make it difficult to access the cache files from the host.
(I use PHPStorm with the symfony plugin, which relies on parsing some cache files)
It also doesn’t solve the problem of persmissions for the `/web` folders, when installing assets or write to any data folders you also wan’t to mount from the host filesystem.

I have not found a really elegant solution for that, but there’s a workaround which does work magic:

You can set uid of the www-data inside the container your host users’ uid.
Something like `RUN usermod -u 501 www-data` inside your webserver Dockerfile should do the trick for your default user on mac. You can then log into the container and run symfony commands as www-data and have no problems with accessing files from host filesystem, command-line or the webserver.

We put together a docker setup for symfony development, which should work across different operating systems.

https://github.com/nerdpress-org/docker-sf3/

So as a quickstart, after installing docker & dlite just run:

git clone https://github.com/nerdpress-org/docker-sf3.git docker-sf3
cp -r docker-sf3/docker /path/to/your/symfony-project/
cd /path/to/your/symfony-project/docker
sh ./docker.sh -l

• v3 now uses symfony3 components
  Silex 1.3 supports symfony3 so lets use it :)
  Note: as symfony3 doesnt support php5.4 anymore, we dont either!
• new ConsoleServiceProvider
  the one from knplabs that was used before seems to be unmaintained and wasnt matching the dependencies anymore.
  So i decided to take it over and renew it a bit. Check it out!
• Docker support
  I started to use Docker as dev enviroment for my projects, so i added dev & prod Docker support.
  For the sake of simplicity it uses a single container with Apache and PHP7.
  If you have Docker and docker-compose on your machine just spin it up with docker-compose up and check on localhost:8088.

As a quick outview:
we are all waiting for Silex2, but development seems to stagnate there.
Hopefully it will pace up again.
But with the rise of other MicroFrameworks like Lumen or the symfony MicroKernel, things went all a bit quiet around Silex.
As i use symfony quite a lot i personally tend to symfony MicroKernel these days.
Check out this blogpost for a benchmark of the microframeworks.