Docker-compose database

[Plomging]

How do I use docker-compose with sail ?
If I have a PHP project with a PostgreSQL database, must I install the PostgreSQL database in the sail container who contains PHP ?

[linux-china]

Same question. How to access docker compose services from sail container? for example MySQL, Redis and PostgreSQL etc. If you want to run some unit tests in sail container, and this problem is very important. Any good suggestion?

[nathanpotter]

You should be able to mount in the docker socket to give your sail container access to the docker daemon running on the host to create additional docker containers or startup docker compose services.

See: https://sail.dev/docs/guides/docker-in-docker/ for more details

[teddy-codes]

Doesn't sail by default use the host network? If you spun up a Docker container that contains the Postgres instance (within the host terminal), you should be able to connect to it via localhost: 5432 from within the sail instance.

An idea for sail would be to include a docker-compose like file within the .sail directory which will allow Sail to not bind to the host's ports and spin up all the required containers upon bootup of the image.
Note: this would all be within a sail defined network.

I am not a fan of having a docker-within-docker setup since it exposes the docker daemon from the host. This allows for mounting "/" into the container and having the ability to remove it. People at the moment should definitely be checking to see what is happening within the .sail/Dockerfile, but this should really not be a concern for the users.

TL;DR
We should implement a docker-compose like file for Sail that would isolate both the docker daemon and ports from the host.

@nathanpotter @ammario @deansheather what are your guy's thoughts on this?

[linux-china]

@roberthmiller great idea. Now sail is great to setup dev environment, but for development we need some services, such as mysql, redis or mongo etc. Could wee add egress reverse proxy in Sail container, and you can access any outside services from sail by localhost only.

LABEL share.egress="host.docker.internal: 6379: 6379,host.docker.internal:3306:3306,192.168.1.33: 11211: 11211"

[teddy-codes]

Currently, I am leaning towards all of the containers being required to use the same network as Sail. Do you have a use case that would make this a non-starter?

Edit:
As a note, this would also allow for fully isolating development environments by not sharing services as well (which is a problem I have come across in the past).

[deansheather]

I think the main reason we use host network instead of regular network is so you don't need to bind ports ahead of time. If I span up a web server in my container and didn't have the port binded to the host, I wouldn't be able to access it. You can't add ports to created containers, so I would need to recreate the container entirely to access my webserver.

I'm a fan of a docker-compose extension for Sail. docker-compose v3 apparently won't read any keys that start with x-, so users could add a fake service for Sail and docker-compose won't touch it.

[teddy-codes]

Instead of it accessing the host network, we might be able to create a bridge network with some ports being published. This could potentially be a label: share.ingress (#229). I think that having a docker-compose file created within a defined network would be a great idea, but not sure how the implementation would work.

Edit:
Referenced issue

[deansheather]

Running the sail containers with host network definitely hurts reproducabililty, so if we can switch to docker networking it would be great. Apparently there was an issue that was encountered when sail was being developed that lead to host networking being used instead of docker networking.

[ammario]

host network is used for best interop with current developer workflow. E.g devs can still access their webapp on localhost, and don't have to finagle with port mappings.

[teddy-codes]

Ah, I think that if we went ahead created an ingress proxy for all of the containers running within sail, etc.. that it would not be too bad of a situation since this would allow for use like normal when developing an API or web app.