Have a question about this project. Sign up for a free GitHub account to open an issue and contact its maintainers and the community. I'm trying to share some containers between microservices. So I have multiple docker-compose. I would love for them to use existing containers that matched up name, image but they don't. There's a failure if I try to do that. Unless something has changed very recently and I missed it. I suppose could solve the problem, but it requires a shared config file to live somewhere that all the projects know about. Allowing for existing containers and erroring if anything is different or conflicting would actually be more straightforward for my use case. That would also solve my use case in a readable way. However, I think it would be a mistake to have compose attempt to start any containers that are marked external. A service should be one or the other. If it's external it must be started externally, if it's internal compose will start or recreate it. I have to say that I agree withand with the current knowledge that I have, I would be in favour of this feature. We have multiple projects at our company, and one of those projects is shared between all other projects. It only has to run once to work for all projects, but ideally it would be included in the docker-compose. This way, each project is self-contained, but can use an already running instance of the shared project. I don't understand why you'd want to share a single instance of a project with all other projects. Why wouldn't you want to start a new instance of it for each like. A service is either externally managed, or it's locally managed, it can't be both. I really think the missing feature here is what's described in. A way to include projects from the local one. So you are sharing configuration, but not running containers. I want to add its dependency to all our projects docker-compose files, and only start the service if one isn't already running with the given configuration. So we can do things like company. For that to work only one has to be running, and it has to be cross-service. That's one of the use-case that would be nice to solve if Docker Compose had the option to start a service, unless docker compose link containers already started some other way, as described above. I have the same use case - the shared service is a load balancer. This works great and the only sticking point is that there isn't a good, semantic way to do it within Compose. Activity on this issue seems to have stalled out, but as the issue is still listed as open I thought it appropriate to continue the discussion here. I, too, would very much like this feature. My use case, similar toinvolves docker compose link containers. This host runs multiple websites which themselves are powered by docker-compose or just docker. My current workflow is to start the single ngnix container and then docker-compose up all of the relevant services that all use the ngnix service. Most of the benefit of docker-compose is that everything can be spun up all at once with clear inter-service relationships defined. Needing to start a required service separately seems to very much contrast this advantageous design pattern. It is not possible for each service to have its own instance of the external service because only one can be bound to port 80. Is there an existing pattern to accomplish this using only docker-compose and no external scripting. If not, does this feature have a possibility of being added to the roadmap. Thanks As we start to move to a more distributed pattern ie. Then you could use said flag to create the container if it is not running and if it is just use said container. This would also allow you to build or pull if you would like. Another thing to consider would be that any down, stop, or rm commands should leave these services, which could result in dangling services. Does this go against any predefined standards or processes. A possible use-case for this, is to ensure any shared docker networks are created. Ideally, compose up of A or B would ensure that mynet1 was running and bring it up if not, etc. Echoing what others are saying. As is saying, very useful for cache and database containers where you normally just want to have one running. At this point, we have to put all the containers settings under one file, but docker-compose will destroy and spin new containers when rerunning it, which is not what you want to do with cache and database. Ideally, compose up of A or B would ensure that mynet1 was running and bring it up if not, etc. This is what I'm envisioning for networks shared by things like jwilder's proxy too. I opted to create the network manually so docker-compose treats it as external and won't down the network. I feel it is cleaner than having any sort of strange dependencies between unrelated stacks. So the intention docker compose link containers external is obviously to not manage them. Lead here by I need something like this to use mailcatcher with all of my docker project. I don't want to boot it manually, I want my docker compose create or use it directly if the service is already running cause it's part of the project as developer. Or maybe my approach is bad and you have some better practices for this case. You need one master project that defines the network as non external and thus creates itand the all your other projects can use it that network as external. Keeping the network fully external from all docker-compose projects also prevent docker-compose from trying to destroy that in use network every time you docker-compose down too, so there won't be an error. We had this problem with the nginx-proxy. To avoid the container name conflict error this would normally give you, I created a folder structure in every project where the docker-compose. I think I read somewhere that the folder name is used as a prefix for the container name in some way. Anyhow, it results in docker recreating the nginx-proxy container, which is fine for our purposes. I would like each compose file to fully specify all dependencies of each app. The shared services must be single instance because my testers need to be able to complete a work flow between 4 to 5 apps while maintaining the state from the previous steps. In agreement with and re: the need for this with a similar use case as described above. My company has many microservices. We want developers to be able to stand up sets of microservices separately without spinning up the entire cluster on their development machine. Furthermore, we'd prefer not to spin up a separate database container for each microservice. With that said, our current solution is less than ideal when it comes to user experience. We essentially write a wrapper script around docker-compose and duplicate it across all of our repositories. And sadly, this is just one of many minor issues with docker-compose that are all adding up to make it very frustrating docker compose link containers work with. It feels as if we're fighting docker-compose every step of the way. Maybe that means we're using it improperly and it's not meant for our use case or maybe it means there's room for improvement. I feel it's the latter. If any core devs are willing to merge this, then please let me know what needs to be taken into consideration.
