Compose: Only start dependencies

[unalterable]

Can i ask why there's no option to run only the dependencies of an application.

The best advice i can find is https://loomchild.net/2016/01/22/start-only-dependencies-via-docker-compose/ which creates an issue:
If i have a massive docker-compose.yml and i have a ticket that requires a new dependency, if i add it to my development config - and not my actual config, then my app is going to break on deployment. Which is the type of problem that containers are specifically meant to solve.

Is there perhaps a better dev workflow i should be following? Or am i missing something? Like:

docker-compose up --deps-only

[shin-]

Sorry, I'm not sure I understand what you're asking. What do you mean by "dependencies of an application"? And what are you adding to your dev config that's breaking your deploys?

[unalterable]

By dependency i mean a docker container on which myApp depends - such as DBs, messaging servers, other services etc. In the docker-compose.yml such "dependencies" would be listed under depends_on or links.

Lets say i need mysql running for myApp. I want to develop myApp. In order to make alterations, test them, and commit them to a VCS, I would need to be running myApp non-containerised, no? Unless there's an easy way to dev on an application inside a container that I don't know about?
However, in order to test myApp in that state i would need all my other containers to be running. This would seem like a pretty standard thing to need for any developer.

Is there not a command that simply orchestrates all the containers listed under "depends_on" or "links"? In other words a simple way to enter such a development state as i have described above (all containers running EXCEPT myApp)?

Otherwise my only option is to define a "deps" service, as has been done here: "https://github.com/puffinrocks/puffin/blob/06be1e113bb4fa4e8df7b4f9ca79db7aba6e07c7/docker-compose.yml" (an example from the blog i originally linked to). This seems like a pretty silly workaround for such a standard requirement, no? It requires that i duplicate code to define all my "depends_on" and "links". If i forget to match the duplication exactly then my application now has different dependencies defined in dev and in live. It works locally and breaks on deployment.

It would seem like a pretty simple (and much needed) feature. I cannot understand why more people don't request it. A flag that orchestrates all the "dependencies" but not the application itself.

Am i approaching my dev workflow incorrectly? Is there a reason this feature doesn't exist? Am i using this tool incorrectly? Or for the wrong use case? Is there something else i should be using?

[shin-]

Oh, I see.

First off, we definitely recommend that all your services be containerized, even in development. There's several reasons why this is worth doing, but the main one are that it helps guarantee that your development environment works similarly to what you'll deploy in production, as well as improve onboarding for other developers working on the project by ensuring all the dependencies they need are already built into the app's images. As for how to do so, a lot will depend on your general architecture and the language / libraries you're using, but many blogposts have been written on the subject. Here's an example with Django from our docs.

That said, if you're not comfortable with that way of doing things, docker-compose up -d && docker-compose stop myApp should do what you want.

EDIT: grammar

[unalterable]

Thank you for your helpful and graceful answer. I will read that blogpost.

The command docker-compose up -d && docker-compose stop myApp does take 10 extra seconds to allow for a graceful exit, and involves unnecessarily containerizing myApp.

Would it be possible to suggest a feature: docker-compose up --deps-only. I still believe it has merit, and is available in competing orchestration tools (e.g. https://github.com/tes/bosco bosco run -d).

[shin-]

Thank you for your thoughts!

Compose is an opinionated tool that is designed to support use cases where the whole stack is containerized. As a result, implementing features that would encourage users to do the opposite would be difficult to justify. Hope that makes sense!