DEV Community: Renan

Move Fixtures Out of src/ Folder

Renan — Tue, 06 Oct 2020 16:37:14 +0000

We'll see in this post an alternative place to write fixtures in an Symfony application.

According to the Symfony Framework Best Practices, fixtures should be placed in src/DataFixtures/.

I'll briefly argue against this.

Development, tests, and build stuff is supposed to be discarded once the application is built. Fixtures are precisely this, a set of files for testing and/or development purposes.

I would say we should place fixtures outside of src/ for the same reasons we write tests in the tests/ directory. It's better to not bloat the src/ with code that isn't business logic.

The golden rule is to not pollute src/ directory with non-runtime stuff.

Fixtures Under `fixtures/`

I propose to place fixtures inside the fixtures/ directory in the root of the project instead of src/DataFixtures/.

From:

project/
└─ src/
   └─ DataFixtures/

To:

project/
├─ fixtures/
└─ src/

Implementation

Let's make it real in your Symfony application. It may work with Symfony Demo as well.

Move Files

Move the src/DataFixtures/ directory to the root;
Rename it as fixtures/; and
Change its classes namespaces to App\Fixtures^*.

At this point, the doctrine:fixtures:load command doesn't work because it can't find fixtures anymore. If you try running it you'll get this error message:

[ERROR] Could not find any fixture services to load.

In order to fix it, we must:

Inform Composer there is a new directory that contains classes (dev only); and
Make the classes inside this directory loadable as service (dev only as well).

Fix Classes Autoloading

Add "App\\Fixtures\\": "fixtures/"^* to the autoload-dev section in composer.json.

     "autoload-dev": {
         "psr-4": {
+            "App\\Fixtures\\": "fixtures/",
             "App\\Tests\\": "tests/"
         }
     },

Don't forget to run:

composer dump-autoload

Configure Services Loading

Make the new fixtures/ content^* findable by loading them automaticaly in config/services_dev.yaml.

# config/services_dev.yaml

services:
    _defaults:
        autowire: true
        autoconfigure: true

    App\Fixtures\:
        resource: '../fixtures/*'

If you need fixtures in another mode (e.g. test), create the corresponding file (e.g. config/services_test.yaml) with the same content above.

Fin

The command below should work as before.

bin/console doctrine:fixtures:load

^* I use App\Fixtures instead of App\DataFixtures as namespace. It's up to you to adopt it or not.

Boot Symfony From Scratch With a Single Command

Renan — Mon, 11 May 2020 13:54:31 +0000

As promised:

docker run -it --rm \
    -p 8000:8000 \
    solune/symfony:7.4-cli \
    bash -c "yes n | symfony new --no-git . && yes n | symfony serve"

Application will be available at http://127.0.0.1:8000

You're welcome.

If you want to understand the command above, continue reading.

Behind The Scenes

As you may have noticed, the command is actually a few of well orchestred embedded commands.

The base is docker run. It means we are going to run Symfony inside an isolated container. That's why we don't need enything else as requirement.

The docker run -it options provide us a better bash experience with an interactive shell.

The docker run --rm option automatically removes the container when it exits.

The image selected is solune/symfony, one of my favorites. This image contains almost everything we need to work with Symfony: some PHP extensions, Composer, Git, and Symfony CLI.

Once the container is running, we can install and serve an application. We run actually a script inside the container, thanks to the pair docker run and bash -c option. The script we run inside the container is:

yes n | symfony new --no-git .
yes n | symfony serve

The commands contain yes no. This trick prevents us to be prompted for updating Symfony CLI.

The symfony new command carries yet the --not-git option. This command performs a couple of tasks, which includes the project git set up and an initial commit. It's great, but it doesn't work unless we set up our git identity. Remember we're inside a container. Adding this option we skip these actions.

The symfony serve starts the web server at localhost:8000 that serves our Symfony application. Remember, we are inside the container.

Lastly, the docker run -p 8000:8000 option. This makes the application available for us. This is mandatory because the container's ports aren't reachable from outside unless we ask for it. Note the symfony serve command serves the application under the port 8000, but inside the container. Thanks to the docker port mapping, we can link a port into the container for us. In this case we use the same port number.

Conclusion

It's all about saving time. It's not about a smart shortcut. It's neither about a long script that performs boring tasks.

By simply using Docker we can dive immediately into a more pleasant context. The trick is to know and pick the best-fit start point. In this case I've choose solune/symfony.

Controlling Service Readiness in Docker Compose

Renan — Tue, 24 Mar 2020 22:43:56 +0000

TL;DR Add dokku/wait as a service, then run wait -c service:port

If you use Docker Compose, you probably have already tried to request a service that isn't ready, despite the container is running.

Actually "running" and "ready" are two different concepts from Docker's point of view. "Running" refers to the container state. "Ready" refers to the service running inside it.

You can control the order of service startup and shutdown with the depends_on option. (...) However, for startup Compose does not wait until a container is "ready" only until it’s running.

https://docs.docker.com/compose/startup-order/

Reproducing The Problem

To illustrate the problem, let's run some SQL command against a PostgreSQL instance just after starting it as a Docker Compose.

# docker-compose.yaml

version: '3'

services:

    postgres:
        image: postgres:12
        environment:
            POSTGRES_PASSWORD: s3cr3t

Using the docker-compose.yaml file above, if we run these commands sequentially:

docker-compose up -d
docker-compose exec postgres psql -U postgres -c "SELECT NOW()"

We'll probably get this output error:

psql: error: could not connect to server: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

This error is due to the fact we try to run a SQL before the PostgreSQL is ready.

We therefore need to find a way to be sure the service is ready before making requests to it. That's make sense, but how to fix it?

Note that this problem may also happen to other services, because they follow the same pattern: container is running but the service isn't ready. Here a list of outputs for some popular services:

Elasticsearch
- Failed connect to elasticsearch:9200; Connection refused
MySQL
- ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
RabbitMQ
- Error: unable to perform an operation on node 'rabbit@a1b2c3d4e5f6'
Redis
- Could not connect to Redis at redis:6379: Connection refused

The Solution

We can solve this by (1) adding dokku/wait as a service in the docker-compose.yaml, then (2) asking it to watch the service we want.

dokku/wait is a (...) Docker utility that blocks until another container is accepting TCP connections, and errors-out if it cannot connect within a given timeout.

https://github.com/dokku/docker-wait

Step 1: Add dokku/wait as a service

Let's change the docker-compose.yaml file by adding a new wait service.

# docker-compose.yaml

version: '3'

services:

    postgres:
        image: postgres:12
        environment:
            POSTGRES_PASSWORD: s3cr3t

    wait:
        image: dokku/wait

Step 2: Ask dokku/wait to watch the target service

The new wait service we added to the docker-compose.yaml file is able to reach any service in the stack by giving its name and its exposed port (e.g. postgres:5432) thanks to the network set up by Docker Composer.

We can then ask it to block until the database get ready.

docker-compose up -d
docker-compose run wait -c postgres:5432
docker-compose exec postgres psql -U postgres -c "SELECT NOW()"

Result: SQL commands will work as expected

The wait -c postgres:5432 command will block for some seconds the psql -U postgres -c "SELECT NOW()" execution. That's why the SQL will work as expected.

Furthermore, we can wait for multiples services at once:

docker-compose run wait -c mysql:3306,redis:6379,rabbitmq:5672,elasticsearch:9200

Conclusion

There are other approaches¹ to solve this problem, but they assume we have to install some script into the host machine or into each dependent service.

Adopting dokku/wait as suggested here is less intrusive because it's not needed to install a script on our machine neither on docker services stack.

Tip: We can even apply this to an existing project via docker-compose.override.yaml without changing anything in the project itself.

¹ wait-for-it, dockerize, wait-for

DEV Community: Renan

Move Fixtures Out of src/ Folder

Fixtures Under fixtures/

Implementation

Move Files

Fix Classes Autoloading

Configure Services Loading

Fin

Boot Symfony From Scratch With a Single Command

Behind The Scenes

Conclusion

Controlling Service Readiness in Docker Compose

Reproducing The Problem

The Solution

Step 1: Add dokku/wait as a service

Step 2: Ask dokku/wait to watch the target service

Result: SQL commands will work as expected

Conclusion

Fixtures Under `fixtures/`