-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data Only Containers/No Run Containers #942
Comments
+1 for this feature |
+1 |
I think this would be valuable, especially for data-only containers. To bikeshed: I don't like |
I find |
@Vrakfall I would say that I +1 |
I was shooting for something to distinguish the concept of running from automatically running. Maybe that's unnecessary. |
I am still really skeptical of any new config setting for this. I think we can solve these issues in a better way. For one, you can already do this by just listing the services you want to operate on. I don't quite understand the problem with having a data volume container run I think #988 is a better way to address the "administrative container that can run, but shouldn't run by default" issue. You can put those services into separate files, and just include the linked services. |
@dnephin that is a fair suggestion, but it will not fit all use cases such as:
Let me know if I'm misunderstanding |
@MrMMorris Regarding the first point: If we remove the need for intermediate containers - either by using renaming (#874) or manually copying volume config (#858) - then the only requirement for the image used is that it can run a command of some kind. I don't think that's a huge issue? Regarding the second: does it matter that the container is started again when Compose is run? |
@aanand just so I understand: does #874 and #858 mean that you won't have to use the same container for the data as you do for the db as pointed out by @cpuguy83? http://www.tech-d.net/2014/11/18/data-only-container-madness/ as for the second point, I actually didn't consider whether or not the container starting again would be an issue or not. More of a note 👍 |
@dnephin I'm surprised that containers with Does it only work with |
Yes, true. It only works with |
@dnephin I don't think your suggestion to use svc1:
image: scratch
volumes:
- /foo
svc2:
image: tianon/true
volumes_from:
- svc1 Then even if I explicitly tell fig only to run |
I'm pretty sure that |
It's possible that there are semantics for dependency that I'm abusing here. Regardless, fig 1.0.1 and docker-compose 1.1.0 (1.1.0-6-g44f5a3e) both definitely try to start the
You can see from the above that the "No command specified" complaint is actually due to |
The I just tried it out with a similar example. I ran I used |
@dnephin so for now, can I have my command for the data only container be something like |
If Compose isn't starting @MrMMorris: if the data-only container has |
@aanand it's not that there is something 'wrong' with it restarting, I would just want to know whether I should be expecting it to or not. I answered my own question anyways, and it doesn't restart if I |
+1 running/start: false |
first of all 👍 for this effort. I am trying to orchestrate a solution that requires to create a d.ata container using docker-compose. I think the naming of the feature within the yml language should be similar to the docker commands to make it as close as a one-to-one mapping. Like the docker team have said in the past, docker in general should be a consistent API, even if you go from the CLI to swarm or in this case to docker-compose. So, perhaps something in the likes of Thanks! |
I would like to mention another use case here that doesn't even need a container to be created:
Maybe we need two options like |
+1 |
+1 |
Yes, I manually create container with same name as compose, and run "docker-compose up --no-recreate" |
+1 |
@ReSearchITEng My workaround is to use Setting something like |
Bump, any movement on this? How about |
This might seem crazy, but what if docker/compose didn't consider it an error if a service doesn't have an entrypoint at all? What if the lack of an entrypoint is just an indication that the container can exist without running? For images that don't have a native entrypoint you shouldn't have to say anything: svc:
image: scratch
volumes:
- /glorp/blatz For images that do, you would need to be able to nullify it. svc:
image: mysql:5.6
entrypoint: null
volumes:
- /flue/barge I recognize this would probably require changes to Docker itself, but thought it was relevant enough to this issue to bounce it here, first. Thoughts? |
What if data containers went away completely at some point now that docker 1.7 supports named volumes and volume drivers? Also no, you can't have a null entrypoint, this will not change in Docker. |
We've talked a bit about making |
See discussion in #741. |
I believe this is fixed by #1754. If you disagree, please feel free to re-open for further discussion. |
I would find a |
Being tracked here: #1896 |
So... how can I create a data-container only using docker-compose.yml? |
Use still need a command, so use something like For now you run up with |
@MrMMorris you totally made my points! |
+1 |
1 similar comment
+1 |
Hi, So, I've gone through this and multiple other linked-to-and-from issues. I'm confused about whether there's a working solution or not... Basically, I want to make Here's my current setup:
elasticsearch:
image: elasticsearch
ports:
- "9200:9200"
kibana:
image: kibana
ports:
- "5601:5601"
links:
- elasticsearch
api:
build: ./api
working_dir: /app
command: forever app.js
environment:
- NODE_ENV=development
volumes:
- "./api:/app"
ports:
- "1337:1337"
links:
- elasticsearch
dashboard:
build: ./dashboard
working_dir: /app
command: forever server.js
environment:
- NODE_ENV=development
volumes:
- "./dashboard:/app"
ports:
- "8080:8080"
links:
- api
Any ideas? |
This issue may not receive much attention because it has been suggested that Data Volume Containers don't provide much advantage over the use of Named Volumes (the use and creation of which can easily be specified in a compose file). |
There is no way to omit the absolute path to the data inside the container if we don't use data-only containers, or is there? Example with data-only container:
The Example with named volume:
Here I explicitly need to create volumes for each directory that is listed as |
I hate to add +1 posts (there should be a voting mechanism on github) but my use case is: I want to build an image with docker-compose but for creating containers I have another process that is based on user interaction. so I would like to see actually,
or perhaps:
though that can lead to choices that could cause errors like failing to specify build but asking to create (which would break if the image has not already been built) |
@ekkis If this doesn't pan out you might be able to use something like shipwright. |
@tn-osimis: thanks for the recommendation. in my case I don't keep my source on github, nor do I publish to the Docker hub |
+1 |
I propose that Compose be able to support a way to create volume containers that never run. Right now, if you want to describe a volume container in your figfile, you must expect it to run. The best you can do is
But it shouldn't be necessary to run a DVC at all. In the commandline Docker client I can do:
It's admittedly a little strange to have to provide an entrypoint to
scratch
, but it doesn't ever run, so it doesn't make a difference. It would be nice to be able to do this in Compose as well.Related:
fig up
(no other arguments) to run a subset of containers #697 asks to be able to run a subset of containers. This is similar in that it asks not to run a container. Perhaps this provides a use case for that, but that issue still implies that the containers can be run. This proposal is to mark containers for creation, but never to run them.The text was updated successfully, but these errors were encountered: