-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Define services which are not started by default #1896
Comments
+1 for option 1 I think adding services that aren't actually part of a composition, but just happen to need to link/attach to it, is a bad design choice. There are a few other use cases that would be solved by allowing some form of includes syntax. Solving multiple problems with a single feature is always nice. Some of these issues (the ones that deal with data-only containers, #942, the last comment from @cpuguy83) are actually already fixed by #1754, I don't think we need to consider them a problem any more (after 1.5). |
We develop Magento extensions. To do that, we need a simple way to run a webstore on a LAMP stack. Compose makes that easy. But we also want to run phpunit, various static analysis tools, documentation builders, etc. In fact, the vast majority of our "services" are just commands, like
would only start long-running service (actual services as it were), and would not trigger other effects like phpunit, unnecessarily. (It's also important that it not trigger things out-of-order, like running Selenium tests before the web service is up.) All we are really trying to do is take the pain of environment management away from developers, not run production services. I don't know if @dnephin 's comment is representative of the direction Compose is headed or not, but it seems ambiguous to me whether Compose is still planning to serve the niche Fig started out in. (Because, to be clear, I think option 1 does not support the ease-of-use that developers need to use this as Fig apparently intended.) I totally understand if Compose doesn't want to have multiple responsibilities, but I hope that someone can let us know, clearly, if those of us using this product for fast, isolated development environments should head in another direction. |
@kojiromike, what is it about (1) that is unsuitable for your use case? Is it just about the command semantics ( |
Its that |
👍 I routinely find myself wanting to create a (btw, nice work all around, folks) cc @jameydeorio |
@ryneeverett The semantics are one part of it. It's a problem of self-documenting and findability. Currently, we tell developers The other thing is just maintaining relationships between services becomes more onerous. Just because we want something not to run by default doesn't mean it doesn't use a |
@kojiromike That's what I suspected. I wonder if you would be satisfied with improved |
I vote for Option 2. e.g. something like a |
I think our proposed solution for #1987 (comment) will handle this. "admin" services can be defined into a separate config, and added with |
@dnephin The solution in #1987(comment) does handle "admin services", but it doesn't handle "data only containers", right? You would still have to use the |
You shouldn't need data-only containers with compose as compose will handle swapping the volumes to re-created containers for you. |
@cpuguy83 In the following example the data container is not really necessary, but if I want to change the volume, I only need to look at one designated place.
However, I agree that this is a corner case and adding additional syntax is probably not worth it. I'm just saying that the proposed solution doesn't handle this case. |
True, some command is still required for data volumes, so you would have to use a minimal image to support that command. I'm not completely up-to-date with the new volumes API that's coming out, but my hope is that we will be able to add a |
This doesn't necessarily make it the right choice, but I think learning curve/ease of understanding should be considered. I feel like (2) is the easiest to comprehend. I don't really have a way to confirm this, but my gut says most people who aren't intimately familiar with all of They don't say, "If only there was a way I could create a 2nd file with an awkward linking story to solve this..." (tho I realize that #1987 (comment) helps with the "awkward linking story," ya?). (4) was kind of vague, but a dedicated avenue for the way for scripts and one-offs like this fits this "makes sense" bill. |
Today I was looking for exactly I have couple of container and all of them link to the same Works well but |
Just had to make a compose file where some services should not be executed with the |
I've run across this as well. Not sure which I think is the best solution, but it what it comes down to for me is that I need the ability to build images that are utilized as part of a composition. They're for ephemeral containers, but I need the image to be ready for use so I can run the container on demand. |
Hi! same issue here, glad there is a nice grouping issue, great work! In my case I have a python stack working with a couple of containers with services. Everything is working fine, but I've just found a case out of the stack. I'm managing static dependencies with bower, and want to run the bower command inside a container, it's just a script that we run once a while. Would be great to run this script within the compose structure we have. I imagen something like: So I like the 2th of 4th option. Just need the service not to start, it's not needed :P If there is some consensus I could try to send a pull-req for something like "restart" |
Another vote for option 2. |
I would prefer option 2 as well. The new Docker Data Containers can be specified in a docker-compose file but they don't need to be running to be used. |
@tberne I agree with that. docker-compose is simple and simple is a good thing. we should vote to keep it |
Heh, what an extensive discussion! Don't pay much attention to this comment, just my two cents. At first I agreed with the majority to just add a sort of My current solution is to create some docker-compose yamls and write some bash wrapping scripts to not run docker-compose by hand. E.g. this is how I run containers which run a website ( #!/usr/bin/env bash
def_opts="-d"
cd "$(dirname "$0")"/../
# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh
docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \
# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail |
Big +1 to either Option 2 or 3. |
+1 for Option 2 or 3. Also the proposed "group" concept sounds interesting! |
+1 for option 2 |
There are so many To add a new idea: Can't we just set a default scale to web:
image: busybox:latest
command: echo 'scaled'
scale: 0 |
You should just do option 2 (but maybe nostart instead or something) because people have been waiting years now, then wrapping docker-compose with their own configuration managers because the tool is too limited, which defeats the point as it's doing what docker compose should be doing. In two years someone could create their own more powerful docker-compose as well. That's a lot of time this issue has been open for. In the long run there should be some consideration of true options grouping. Some are relevant only to build, some only to run and some are mutual (you really want a layer of nesting at least for run or just separate out and have a build section, problem solved). Currently though a lot of things are problematic in the configuration, I'm all for just remake it all in version 5 but getting it right that time (primarily by representing the real on a technical level domain rather than trying to make it map a usage based domain or overly simple, instead create a config layer for those goals on top of the right one, you can't do it in reverse). I think because of that state of affairs the quick fix is justified. |
+1 for option 2 or 4 If there aren't any plans to add this feature currently, I want the way to run such services (or tasks) in a composition is written in docker-compose's docs. |
This is an old thread, and I agree that But I also commonly add a
|
@paulodiovani That looks more like a hack than a solution. |
+1 for a feature request. |
I solved this in my project by providing a simple bash script that calls the appropriate Now if I do Therefore, my This somewhat solves @acran's problem of the user not knowing which files to include (and in which order) to the |
No need for envsubst, docker-compose config does the environment variables and then docker stack takes it from stdin:
Let's you use the docker-compose .env substitutions as well. |
@kogli I think the problem here is to pick an option. All have Pros and Cons. As I said before: Every solution will be better for some use cases, and worse (Or even useless) for others. If the something is implemented, the mantainers it forever, so I believe they're wise in taking their time with it. @shin- I guess you're the one to ask: Does it even make sense to consider this? Considering the current position of the team, how hard it is to design it, and the many tools out there, wouldn't it be easier to simply tell people this won't happen? Most people if not everyone who commented here found a way to deal with it. Closing this seems pretty good, plus you can focus on the stuff that matters, and no one wonders if they should make a pull request and how to meet all those needs at the same time. They can just go build something else, and maybe even publish it to help others. Just for the record: My solution was not perfect, but way better than the 2 days it took me to install the dependencies and fix a shitload of stuff and make the project run (and it already used Docker). Just 3 commands, with Docker and Docker Compose as the only dependencies. Yes there was more code than I wanted. Yes there's a shitty order to run commands. And yes there's a tiny bit more to keep in mind. A Wiki page covered those. Preety good, if I do say so myself, which means Docker Compose did it's job, I just also needed somethig else. Point is: If it's out of the scope, it's a waste of time to keep discussing it. Many people just stop here to ask about this and give their opinion, before trying to decide what to do. They will still find or build something else if this is closed, just faster. And you get one less thread to babysit. Edit: Just thought of a good way to put it: If there's no clear criteria to accept PR and there is no one in the core team either involved with it or planning to take a look at it in the foreseeable future, it's not an "issue", just an idea. I see no reason to clutter the issue list, I believe many ideas here are good, but I think they belong somewhere else, for good or for worse. It's almost 3 years, and on the off chance that one day the situation changes, you can always reopen this, or open a new issue about it. |
This feature takes like one day to implement because it's really simple. However, after 2 years of discussions, still nothing. Sad. |
@rubycut Yeah, that's what happens when so called "higher principles" take over from usability and user-friendliness. I completely understand the devs don't want to clog the product with illogical features. However, this particular highly requested feature actually seem to make sense. It's sad when the developers think they know better than their users. (Again, they usually do. But not always. Not this time.) |
@rubycut Talk is cheap, show me the code. If you can,send your PR, if you can't, just report it and wait . |
@wangwenpei Are you kidding me? First of all, you are not maintainer of this project. If maintainers would accept this idea, and put "help wanted" tag, I am sure somebody could contribute pull request. But they said that they are not interested. So, why bother will pull request if it will not be accepted. |
Just FYI, "the code" is already there: #3047 |
@wangwenpei well, #3047, there's the pull request...
which quite angers me to be honest because the arguments given in #1896 (comment) do not relate in any way with the pull request:
I don't see the assertion And that's also exactly what the change in the pull request does: add the ability to mark a service to be started by default or not. Just for completeness:
Yes, there were examples of one-off tasks, but there also were examples for real services according to your definition, i.e. legitimate use cases for this feature. In fact this is also one of the suggested workarounds! Just split the tasks into a separate The only real argument brought up against the most basic implementation of option 2 - i.e. having some way to tell
On the one hand highlighting that there is only one active maintainer while on the other hand just ignoring pull requests and therefore wasting any opportunity to maybe get other developers involed in the project isn't something I could comprehend. All the additional requirements - having to introduce completely new concepts, new dependency management, up to a |
I came upon this issue just a couple days ago because I was looking for a feature like this. Since it's unfortunately not implemented, and from what I could gather, the officially supported alternative is to use multiple yaml files. Well, I find the idea of using multiple yaml files for services not run by default a poor alternative in comparison to using one yaml file for all services containing one additional setting for each service not run by default. So, here's my +1. |
Implement profiles as introduced in compose-spec/compose-spec#110 fixes docker#7919 closes docker#1896 closes docker#6742 closes docker#7539
Implement profiles as introduced in compose-spec/compose-spec#110 fixes docker#7919 closes docker#1896 closes docker#6742 closes docker#7539 Signed-off-by: Roman Anasal <roman.anasal@bdsu.de>
Implement profiles as introduced in compose-spec/compose-spec#110 fixes docker#7919 closes docker#1896 closes docker#6742 closes docker#7539 Signed-off-by: Roman Anasal <roman.anasal@bdsu.de>
Implement profiles as introduced in compose-spec/compose-spec#110 fixes docker#7919 closes docker#1896 closes docker#6742 closes docker#7539 Signed-off-by: Roman Anasal <roman.anasal@bdsu.de>
Implement profiles as introduced in compose-spec/compose-spec#110 fixes docker#7919 closes docker#1896 closes docker#6742 closes docker#7539 Signed-off-by: Roman Anasal <roman.anasal@bdsu.de>
Implement profiles as introduced in compose-spec/compose-spec#110 fixes docker#7919 closes docker#1896 closes docker#6742 closes docker#7539 Signed-off-by: Roman Anasal <roman.anasal@bdsu.de>
Users quite often define maintenance scripts, test suites, debugging systems in their Compose files which they don't want to run when they do
docker-compose up
.There should be some way of defining what services are started by default, but can be still be run manually by doing
docker-compose up servicename
ordocker-compose run servicename ...
.Possible solutions
(Please suggest others if you have ideas.)
Data points:
fig up
(no other arguments) to run a subset of containers #697@cpuguy83: "I've got a little helper service in my compose yaml that injects a bunch of stuff into redis for hipache, which of course exits when it is done. Can't usethis is fixed now that we don't exit fromcompose up
w/o the-d
"compose up
until all services have exited.The text was updated successfully, but these errors were encountered: