Possible issue with latest docker compose 2.24

[pyr0hu]

Sail Version

1.27.0

Laravel Version

10.40.0

PHP Version

8.2

Operating System

Linux

OS Version

Description

Using the latest docker compose plugin v2.24, using a dot in the service name will break the sail up -d command.

Related issue: docker/compose#11336

The output shows when someone tries to sail up -d:

5 error(s) decoding:

* 'services[laravel.test].depends_on' expected a map, got 'slice'
* 'services[laravel.test].networks' expected a map, got 'slice'
* 'services[laravel.test].ports[0]' expected a map, got 'string'
* 'services[laravel.test].ports[1]' expected a map, got 'string'
* 'services[laravel.test].volumes[0]' expected a map, got 'string'

Possible solutions could be using a default app name which does not contain a dot, or wait for a hotfix, but I think the former solution would be better.

Steps To Reproduce

Update to latest docker compose (2.24)

Call curl -s https://laravel.build/example-app | bash to create a new Sail app

[driesvints]

Thanks. Gonna await what the feedback of docker is.

[erayaydin]

Also got same problem with new docker compose version.

Workaround is using long syntax [1] on compose file (you can still use . in service name).

        ...
        ports:
            - target: 80
              published: "${APP_PORT:-80}"
              protocol: tcp
        ...
        volumes:
            - source: ./
              target: /var/www/html
              type: bind
        ...
        depends_on:
            pgsql:
                condition: service_healthy

[1] https://docs.docker.com/compose/compose-file/compose-file-v3/

[remarkusable]

is there a reason to name the service laravel.test instead of just laravel ?

[erayaydin]

is there a reason to name the service laravel.test instead of just laravel ?

Probably use as domain when reaching; http://laravel.test. Personally, I use project.localhost

[remarkusable]

Probably use as domain when reaching; http://laravel.test. Personally, I use project.localhost

access of http://laravel.test will only work within the Docker Compose services as Docker will resolve the DNS within the services. but for the host machine to resolve http://laravel.test we still need to map it in the /etc/hosts.

i skimmed the Laravel Sail documentation, and the guide is to access it via http://localhost. so i don't believe it's being used as a domain to reach the container from the host machine. hence my initial question whether there is a reason to choose this name laravel.test instead of just laravel.

i did a quick search and see that the service name laravel.test is used as default here https://github.com/laravel/sail/blob/9dc648978e4276f2bfd37a076a52e3bd9394777f/bin/sail#L139C16-L139C16 which also provide another solution to rename the service our self by setting the APP_SERVICE .env variable and changing the service name in docker-compose.yml

so another solution to fix this issue is by:

1. renaming laravel.test service to laravel in docker-compose.yml
2. set APP_SERVICE=laravel in your .env file

[pyr0hu]

@remarkusable it might break some stuff if you use APP_SERVICE, see this pr: #650 but this was closed

[remarkusable]

@remarkusable it might break some stuff if you use APP_SERVICE, see this pr: #650 but this was closed

yes, i see that we have to manually add the newly added service to the laravel service's depends_on but in my projects, i'm rarely adding new services. from the code here

sail/src/Console/Concerns/InteractsWithDockerComposeServices.php

Line 68 in 9dc6489

if (! array_key_exists('laravel.test', $compose['services'])) {

we should get a warning to do the addition manually, which i'm fine with since this should be a one off change.

[driesvints]

It seems Docker merged the fix so I suspect they'll be releasing the fix soon. Thanks for your help all.

[nikoplusx]

There are cases where the long syntax workaround cannot be applied. In case a directory does not exist in the host system, by using the short syntax

volumes:
   - "./local/directory: /remote/directory"

the docker engine was creating the directory and mounting it to the container.

Now if you're using docker-compose syntax version 3.9. and docker-compose binary 2.24 one must use the long syntax and by using the long syntax one must create a bunch of empty directories on the host system

[fithurriague]

Hi! Any updates on this?

[remarkusable]

Hi! Any updates on this?

Docker Compose version 2.24.1 was released which fixed this issue