Previously Compose did not have a specification, only the implementation, and it was tied to Docker's products. The aim here is to open it up, and let the specification evolve in new directions, such as better supporting deployment on Kubernetes, as an example. It is supported with some other implementations but we want to bring these closer together.
Compose has a lot of users, and hundreds of thousands of Compose files on GitHub, so we wanted to open up development as much as possible.
Is there any "supported deployment" for docker? I had the impression that swarm has been sidelined, and docker-compose was discouraged. Is there a path to deployment on kubernetes that uses only compose? (I have a hard time seeing how that'll work with ingress, and "compose" well with other kubernetes deployments?)
We have some on-prem stuff that would work on single-node swarm - but I've felt that compose has been in a bit of limbo this past year or so... Is some kind of production style deployment comming back?
Docker is not in the "supported deployment" business any more. We sold Docker Enterprise to Mirantis, to focus on developer tooling. The aim of open sourcing Compose spec is to help make it easier for people to make better deployment tooling, and to clean up the parts of the spec that were specific to the methods we had before to make it more general.
There are quite a few ways now, and we will be helping make them better. These include Kompose (the maintainer, Hang Yan, is involved with Compose spec now) which converts to Kube Yaml, some work on Compose-Helm integrations that is ongoing, Amazon ECS has Compose support, compose-on-kubernetes (we think this needs rewriting to use a CRD again, after having changed it to use API extensions), and some other projects which are being worked on that I have heard about.
That sounds promising. With the only choice for a while seemingly being "single container" or "k8s" for deployment - docker-compose for development seemed a bit of a dead end (ie - might as well go back to vagrant, and at least get proper heterogeneous host support as everyone would be running VMS, with no need for a Linux kernel on host).
With an option like swarm, that fits a certain on-prem type scenario (eg: what gitlab now does with its horrible (working, but still horrible) omnibus installer would be a good fit for swarm).
I never did understand why docker-compose wasn't treated "better" by docker - I guess they focus on non-linux devs? Docker without an orchestrator is a bit like a daemon without a supervisor - if everything fits in a single container - why not just run it as a Linux process?
And compose was a perfectly OK orchestrator - it did some minimal, sensible things that you need, to compose a couple of containers. But it felt scary that you never knew what upstream intentions were.
> docker-compose for development seemed a bit of a dead end (ie - might as well go back to vagrant
It might be a VM either way for Mac and Windows, but Windows developers are likely to always be running a VM with Docker integration soon due to WSL 2, and on Linux it's still an incredible productivity multiplier that beats the pants off everything else when you have dependency issues. Only MacOS is left behind with the worst developer experience out of the three.
I actually meant that with vagrant, even us on Linux would run VMs, so if I set up a dev env, I can be pretty confident a colleague will run the same thing, with similar characteristics, on windows or Mac. With Docker, I feel it's still a bit kinda-sorta. Especially if you need to run multiple stacks for switching between projects.
> With Docker, I feel it's still a bit kinda-sorta.
What makes you think that? Only difference I can think of is use of hemorrhaging edge kernel primitives in your application. Even networking is handled by docker-compose and you don't have to worry about port collision.
> With Docker, I feel it's still a bit kinda-sorta.
This was the first time I ever heard anything of the sort. Docker has been not only solid but by far the most performant system available, and running stuff on VMs always felt a half-baked solution in comparison.
Can you shed some light on what led you to form your opinion?
A former colleague of mine used to rail on Docker for MacOS a few years ago. He always complained about it being super slow to sync with the local file system. I never had any issues but was running everything on Linux. Since then I've moved companies and now I'm running docker on a Mac. Haven't noticed any eggregious performance issues, but as I understand under the hood it's still basically running in a VM.
I certainly hope so - Swarm is a wonderful orchestration system for small deployments (at least, I haven't tried to use it for large ones), and is really easy to use. It's also vastly simpler to comprehend and operate that Kubernetes, and doesn't eat CPU & memory for breakfast. I'd wager that Swarm would be a better fit than Kubernetes for most systems.
Totally agree. I tested out both Kubernetes and Swarm for a recent project. Swarm was so vastly easier to not only understand at an architectural level, but to actually use, that I was delighted by using it. Kubernetes, on the other hand, was a real pain, and overly-complicated for 90% of projects I would say.
It was even very difficult to setup a test cluster on my MacBook Pro to try out multi-node support (you have to find a good distribution, something that supports Mac for multi-node, etc.). Whereas for Swarm, it was super easy.
> I certainly hope so - Swarm is a wonderful orchestration system for small deployments (at least, I haven't tried to use it for large ones), and is really easy to use.
I would argue that Docker Swarm is a wonderful orchestration system for all practical real-world applications, with the notable exception of really global and gigantic multi-region deployments.
Docker Swarm works superbly out of the box and it's trivial to setup a multi-node heterogeneous cluster of COTS hardware and/or VM instances.
I think there's a more specific statement about k8s vs swam. Swam is much better at running other people's applications that you're treating largely as a black box -- k8s excels at running your in-house app. The simpler deployment model means there's far less environment specific weirdness you need to contend to to make an arbitrary app run.
The systems I've deployed with Swarm have generally been a mix of both - not sure why it would make a difference if you were running in-house or off-the-shelf images?
"Compose on Kubernetes"[1] seems to be what they're advocating at the moment, and it's included in Docker Desktop. It's probably an OK first step for simpler deployments, though I suspect in order to do any troubleshooting, one would have to learn k8s anyway.
Have you tried moving from on-premise docker-compose to managed kubernetes in the cloud?
If you've been diligent in striving for stateless containers that will help you - but pretty much everything thing else in your compose file is useless.
Docker-compose gets you the "pod"-level in k8s, but doesn't really help with ingress/services etc. So no one can reach your app, certainly not via a load balancer that terminate ssl for you.
This is no longer a game of "beating the nginx container until it gives up and does what you need it to".
That's assuming the existing tools (implementation). Having a spec means you can build more and new tools that do different things. I would expect docker-compose to improve or something else that implements the spec can come along and do what people need. Or, more than one thing can come along.
Oh, I didn't read your comment with a view to the future - I certainly hope a spec and further development of the ecosystem can help improve the deployment story - which would help keep the development story relevant.
Hi Justin, I work at Heroku for Salesforce. I'm unsure if you've worked with anyone here in the past (like on our older app.yml, heroku.yml and constellations, etc stuff). But I just wanted to say thanks for establishing a standard for this and helping the rest of us in this space continue to evolve.
I'm super excited for this. Back when Docker Compose was still called Fig, I got annoyed at how it handled volume-only containers for databases, and wrote Dup [1]. Nowadays Compose is way WAY more useful, but there's a number of projects that still rely on it -- the spec means I can write a converter for the config files (from Dup to Compose) and be sure that it will work :)
So far we have not made changes to the spec, just carried it forward but we definitely want to start cleaning up the v2 v3 mess, and make a single spec work for all platforms.
Docker (Inc) has new priorities and different influences. I'm inclined to feel some optimism that this shifting focus will have beneficial repercussions in places like this.
Hi, I would like to use docker-compose without using docker. Specifically, I’d like to run devil box (php development environment) on fedora using pod man and docker-compose. Is that possible now?
I've been mostly avoiding Docker, Docker-compose etc. (We got stuck at the "Ansible > Digital Ocean works fine for us" stage. Docker was too new at the time and never really had a reason to re-examine things)
But just this past week after a ton of pain previously trying to get a working Geodjango stack running on my Mac locally for experimentation I discovered a docker-compose script that gave me everything I wanted in about 5 minutes. A sample app. Django, nginx, redis, PostGIS and all the complex dependencies - all working together. I literally typed "docker-compose up" and I had a working web GIS-enabled web app running on localhost. And the fact that the deployment to staging is hopefully just as simple makes me smile.
Of course - production is a different story as I then have to worry that all the magic pieces aren't full of backdoors and security holes but I guess that's a job that needs doing anyway.
There are some things that have to be made clear to the team when moving to containers (don't use joerandom/alpine as a baseimage, build via digest instead of tag etc) but the speed at which you can onboard people is amazing.
I couldn't imagine deploying a Python application without Docker nowadays.
i've been doing python for 15+ years now and docker is one of the best things to happen to it, possibly it's saving grace in server side software. deployment and dev env setup used to be brutal.
But couldn't you get the same thing using the virtual environment provided by python? Unless you're using a lot of modules with C extensions, you wouldn't need to install anything outside the virtual environment.
> Unless you're using a lot of modules with C extensions
in my experience only the simplemost applications actually don't need anything outside of vanilla python pip. suddenly the client wants PDF reports and you're setting up e.g. some tex-based printing system with a bunch of host packages needed. only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase.
> only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase.
Couldn't the same thing be done via the package manager and a RPM spec or deb file where all the necessary dependencies are listed and installed as part of the package? It could be done on a VM or could be done on a machine by keeping track of what dependencies are installed when installing the application and handling uninstallation by removing all newly installed dependencies along with the application.
but why polute host or go back to VM overhead per application if we have already a solution that is easier to handle? even just in terms of build & launch time it's quite a bit more performant to use containers vs. VMs.
The package manager can handle removing pretty much any file it installs when uninstalling, so the host really doesn't get "polluted".
> or go back to VM overhead per application
In a development environment hosted on a VM, several applications can be installed on the VM (rather than having one per VM) to reduce overhead. Then testing and making code changes could be done by running a pip -e (editable) install and modifying code in the working directory, or making the change, repackaging and re-installing, and restarting the daemon.
With a container, at least in my experience, you need to re-build it each time you make a change to the code, which actually takes longer than modifying an editable install or re-building the wheel/RPM and reinstalling it.
typically on a dev PC you'll have multiple apps roled out for development / maybe feature testing. if this is done directly on the host it's always possible for these environments to influence each other. very common is to forget to script a dependency, which only may get recognized once someone wants to deploy on a fresh installation.
Yes, but dependencies are handled by the package manager. So if one is missing, it's a simple matter of adding it to the list of dependencies.
In any case, the point I was trying to make is that the development cycle with containers, in my experience, is slower because you have to go through the build step every time you make a change. For an intpreted language like python, that shouldn't be necessary until close to the end where you test a fresh build before submitting the changes for review.
The setup is a bit more involved, but this can be mitigated in several ways. One is docker or SSH plug-ins in editors like VS code coupled with an SSH server included in the develop build phase, like you would use to develop on a remote server. The other approach is adding the source tree as a volume. You can also do a mixed approach where development is done on host, but testing and deployment is done in docker.
Started playing with Docker because it was the cool new thing, but professionally I get more use out of Ansible > Digital Ocean. Seems like your Geodjango experience had more to do with the sharing of the script than the underlying tool.
I guess but Ansible > Digital Ocean wouldn't have helped me get a local dev environment. For that I needed containers or a VM - and containers are a much lighter solution.
I literally wasted nearly a day and filled up my drive with compilation artifacts last time I tried getting GeoDjango working. All those binary dependencies, subtle OS config changes and custom Postgres extensions can be a pain.
So given my need for local deploy and remote deploy it's hard to think of a better solution.
I haven't yet figured out a comfortable local and remote docker solution yet, but I regularly use ansible for this.
I usually spin up a local lxc container and point the ansible scripts at it using a dev inventory file. Mount the source code from the host filesystem onto the the container and I'm ready to go.
Tangentially, it is a little irksome how the docker-compose tool is released completely independently from Docker itself. There are binaries published on GitHub for amd64, but if you want it on an ARM platform, you need to install with pip. But pip can't install system packages, so you also need to know the incantation to install those (python3 python3-pip libffi-dev libssl-dev).
I'm sure there's a historical reason for it not being `docker compose ...`, but it sounds like it's a good time to promote it.
Remember the outcry when Swarm was shipped as part of the core Docker binary? I wouldn't be surprised if this caused some kind of cooldown with respect to the binary assimilating features.
Not sure what you're saying, I can run ARM and regular AMD platform containers via docker compose without problems (other than I have to build ARM using buildx).
Sweet, looks good. I reckon docker and docker-compose have been probably some of the greatest enablers for my development process, and how I think about desiging software systems.
But on that note, the fact that there isn't a single cross-platform filesystem that works on Windows, MacOS, and Linux has been one of the greatest detractors for a docker-based development environment. The performance of Docker for Mac is often a showstopper for running a big app in docker for development, especially in combination with other slow and i/o heavy tools like webpack.
Apparently Apple came very close to using ZFS too, instead of building APFS. Oh what could have been.
The performance of the fs is not really related to the container fs (apfs seems like it could be great for a container fs, in theory), but rather the fs being shared across the VM barrier which enables sharing developer-local files with the container.
Since you were able to describe the problem of fs-sharing-for-containers so well, I was wondering if you have any recommendations for a usable cross-platform dev workflow?
We're currently using a mix of docker-compose for the service and native development for the main application (requiring separate instructions for win, mac, and linux). I'd love to be able to transition this to a simpler all-docker-compose setup.
I fought with this regularly for about a year - on Windows - and recently settled on duplicating almost everything inside the VM and outside it, except the bare shared code I'm working on.
Okay, that sounds confusing, I know. We use Vagrant, because you can put every kind of ancient incantations into the Vagrantfile to check for whatever misconfiguration on the host, and so on. Plus you don't have to wrap your app in Docker this way, so debugging becomes a bit easier.
Basically we have a fair bit of Ruby in the Vagrantfile setting up a dev env on the host (scoop + pip + poetry) and provision files setting up the env inside the VM. (Let's say a DB + pip + poetry + uWSGI.) This is necessary, because for code completion you want the dependencies accessible for your IDE. (Yes, PyCharm Ultimate Pro Gold Edition has a way to use remote interpreters, but then you need to guarantee that for every dev too, and it's still not as fast as just having the files on the host in a venv.)
The VBoxSF shared filesystem has a lot of quirks, so we minimize the shared stuff. (We tried NFS and CIFS/SMB too. Both were amazing disasters.)
For NodeJS stuff we only have the runtime dependencies in the VM (database, other backed services), but you have to be careful to script everything in a cross-platform way in package.json (so basically don't script anything there start the NodeJS process as soon as you can, and work inside that).
And the provision scripts are simple, because they just setup docker containers. Usually without compose, because meh, it's easier to just type a few lines of Bash to rm -f the container and run a new one, and maintaining a useful compose file is unnecessary at that point.
Agreed. I was worried docker-compose might be abandoned for swarm-only at the kubernetes level. Compose is a much easier level to develop and work with. Doesn't do all the balancing and HA, but for most projects you don't need that, just good organization of the pieces.
This is exactly why we still use compose as well. Everybody is talking about kubernetes, but I honestly don’t see the point in adding a huge dependency only for balancing and restarting failed containers..
I just wish there was some SaaS platform which allows you to upload a docker-compose file and run the containers for you. That way, you don’t have to touch the underlying OS.
Good news! Everybody wants to just write a docker compose file and use that in production. Deploy on ECS or k8s or heroku, it would be awesome. That's the simplicity most people want for small projects.
I'm not a devops person at all, but this pile of abstractions seems like it's going the wrong way. Like, this seems almost like a parody?
You have this problem where you want to set up infrastructure in an abstract way, so you come up with a way to write some infrastructure requirements and now you have a program that does all the actions necessary to take your setup from wherever it is, to what you specified.
Then you have multiple of those systems, and it gets confusing. So you come up with a generic way to specify the abstractions that can be sort of compiled into any of the flavors, so that you can set up infrastructure using any of the sub-abstractions available, instead of only a specific one.
This has the smell of a FactoryFactoryFactory sort of thing. Like, if this whole cottage industry were my architecture project I would be saying to myself "This is too much, a rickety, foot-gun-laden tower, destined to crumble. I've obviously chosen a poor abstraction, lemme back way the hell up."
Am I just totally wrong here? I feel like I'm taking crazy pills.
I’ve had similarly adverse reactions to the seemingly “unnecessary” complexity of many things: docker, webpack, autotools, react, AWS, just to name a few.
But I’ve found that, upon closer inspection, the software is usually complicated because the problem domain is complicated. Further, as an inviolable rule, the most popular tools for any problem are the ones that don’t make you rewrite all your code; popular tools build on top of the mess we already have. This can give the illusion that the tool is somehow responsible for all the preexisting complexity. Tools which attempt a “clean slate” approach are mostly doomed for obscurity.
In the case of docker-compose, I can say after years of resistance, I tried docker compose and was an immediate convert. Setting up, documenting, and sharing development environments has never been simpler.
I would add a caveat: Docker compose is nice for setting up development environments as long as everyone's developing on the same platform.
I work in a shop where various developers work on Linux, OS X and Windows (useful for dogfooding - we support deploying to multiple platforms), and, there, Docker Compose has ironically turned out to be our chief source of cross-platform headaches, due to annoying differences in how it works on each host platform. Particularly with the networking subsystem.
Everywhere I've ever worked that had docker/vagrant, the devops guy has promised me easy, one command environments, and not once has it worked.
I've seen the product they are selling, I've watched a docker command build me a multi-part infrastructure, automatically source databases and assets from afar, and do it all quickly. But then it failed the second time I tried it. I've not found it to be a reliable tool at all.
Even in a shop with just Linux and mac, I think docker (especially deployed via fargate) causes way more problems than it solve. We have a single instance of a single app that used to run just fine in a Ubuntu vm. Now it runs in fargate. We waste huge time futzing with the image size due to fargate insane 8gb limit. We wast huge time working around not being able to get a shell when something goes wrong.
Local development also sucks. The docker engine is essentially unusable on my colleagues Mac, consuming 100%+ of all available cpu while sitting idle. On my Linux box, either docker breaks my networking, or IT firewall rules break dockers networking. It’s even worse with wfh, because our vpn is incomparable with docker. Local dev just happens in an anaconda env instead. So what’s the point?
VMs have none of these problems.
Docker is the leakiest abstraction I’ve yet to come across.
I'm not incredibly knowledgeable about AWS and Docker, but I have a couple questions for you:
- How would EC2s compare to Fargate ? I encountered situations where, running the numbers, I much preferred having my own set-up with images ready to deploy + adapting my EC2 instances to the task, instead of dealing with Fargate's convoluted restrictions and definitions
- Has your colleague tried to increase the disk size given to Docker? I have seen on a few macbooks that this made a world of difference for CPU usage, and I thought I'd pass on the information if it hasn't already be tried yet
Everyone is so obsessed with never repeating themselves that they've forgotten to ask whether they are still removing duplicated effort instead of just duplicated text. Every tech cycle we get people trying to compress the text long after the power of the system has already been maximized.
Particularly, as a species, we discount the future heavily, so as developers we do not accurately estimate the variance introduced by something that works by magic until it doesn't. So on some unnamed day in the future when you had other plans, you will be completely blocked while having to learn a bunch of things we were avoiding learning in the first place.
docker-compose is just a tool to run multiple containers together. It is extremely simple, readable and straightforward (if you're familiar with docker). It is not an inf. abstraction at all.
Looking into it for a minute I don't see any particular gotcha. v3 is a breaking change compatible with Docker Swarm, so it's just like any versionned tool: if you're already on v2 and don't care about the new feature stay there, if you're on a greenfield project or do care about new feature use v3. Am I missing something?
Nope, entirely wrong! v3 isn't an upgrade, it has features specific to orchestration. v3 is a fork, not an upgrade. v2 is better for local development, it has things like depends_on which v3 doesn't have.
Docker is how you put your widgets into a container, docker-compose is how you put a few containers on a ship. How is separating those responsibilities overengineering?
I think you generally have the right sentiment, but some of these solutions are born out of necessity. Using containers at scale is really hard when you're trying to solve for optimal resource usage and resilience. These abstractions may seem crazy but other solutions are probably much crazier.
The other part of this problem that isn't applicable generally to other things, is this is a fairly unique problem to cgroups. By design cgroups don't have a singular implementation or solution, so there are a lot of "competing" solutions. I think some amount of unix philosphy is at play here, to do one thing (or really, fewer) and that's why it seems insane how many systems you have to hook up together to make the thing work the way it should.
I'm fairly devops centric, but I'd still take this with a grain of salt b/c containers aren't my area of expertise.
Maybe you have a point but from my perspective you're overthinking it. Lots of developers use Docker Compose and will continue to do so because it's a great product. The news here is that there is now an open specification that others can contribute to.
You're not wrong. What you are missing is how much complicated web development (and software development in general has become). Even if you are doing a simple Static website it's more complicated than yesterday. If you are using Git to push your changes, you already need to push to Github and then SSH into your machine, make a pull request.
Oups. Now Nginx is still serving the old version through cache. So need to clear cache, restart, shut this, reconfigure this, etc... After a while this gets tiring.
Docker is not the perfect solution (one can wonder if it's actually a solution) but it's a symptom of the real issue rather than the issue itself.
It is just a matter of time. Right now, we’re in the thick of things and as pointed out by others, the problem domain is very complex. As we move forward, though, our solutions will become simpler and our container tools will work more elegantly.
it is but it solves the distribution problem. golang aimed to solve the same problem by compiling to a single statically linked binary and it was one of its biggest selling points. i feel docker blunted this part considerably, but it also benefited it nevertheless: development environments, shipping runable packages with assets, etc. is easier when you literally have to only do docker run whatever.
1. Writing all the YAML to deploy an application into Kubernetes is a lot of work. If one does everything fully filled out it's pretty normal to have over a thousand lines of YAML... or much more. With lots of repeat yourself. Tools built from a simpler spec that can "compile" to that would be so great. Like writing in a higher level language instead of machine code or assembly.
2. There are a variety of platforms now. I first thought of Kubernetes vs Nomad. But, Kubernetes using Istio is a different platform from Kubernetes where applications use Ingress. There is more diversity showing up. Being able to define an application in one spec and "compile" for different situations would be useful.
Just my 2 cents. As a Kubernetes user I'm happy to see the higher level tool bar moving. It's desperately needed.
> But, Kubernetes using Istio is a different platform from Kubernetes where applications use Ingress
This. After almost a year working with kubernetes I came to the same conclusion. I am/was studying for the kubernetes certification (cka) but in some way it's useless.
I mean, it would prove basic proficiency, but the whole ecosystem is so varied that wouldn't necessarily mean actual and practical proficiency.
It would probably help passing through vogon recruiters but a technical interviewer that knows his way around kubernetes wouldn't necessarily buy that.
> Tools built from a simpler spec that can "compile" to that would be so great.
Getting into Kubernetes, having Kompose (https://kompose.io/) generate Kubernetes specifications (and Helm charts) from Docker Compose files was a godsend.
2. Specify services that are only intended to be run
Maybe #2 is possible now and I just don't know it?
I wrote a wrapper at previous job around docker-compose that made it easy to define aliases within the compose file for complete run commands... Eg to run migrate in your rails container.
This is great news. Docker really screwed up v2->v3 and have continually suppressed Compose’s potential because it wasn’t inline with swarm. Looking forward to Compose getting some new life put into it.
Suppressed is not quite the right word.
Too many inputs (from the community) and not enough help managing and maintaining, and curating these inputs is really what this is.
That said, I don't personally believe there exists a single specification that can work (optimally) for both local-dev and production deployments.
Disclaimer: ex-Docker engineer, still an active maintainer on the main docker project.
You may recall that compose used to be called fig, and they merged into Docker. I wouldn't be surprised if there was some Us vs Them politics going on there.
This is good. My main annoyance with Docker in the past was that I would make a decent Compose file for local dev but then have to rewrite everything in a proprietary YAML format for use in CI and prod.
You'll still be doing that with this new spec. It's still just a "how would you like me to run multiple containers" spec, it's not defining the relationships of arbitrary infrastructure and services on arbitrary networks/providers.
What's going to happen is, you (or the dev) will fill this thing out to the best of your ability. Then someone's going to run it in one env; it won't work, but Ops will modify it to make it work. So then you'll commit that as your one Compose file. Then someone will try to run it in a different env, and it won't work; they'll fix it to make it run. Now you have two Compose files to maintain, with 3 different use cases. So to make it easier to manage, you go back to one for dev, and one for each env. All this because the different components could not be defined independently and loosely coupled, because the spec (and tools) don't support that.
I like Compose for what it's designed for: let a dev mock something up locally. But it's going to become a pain in any environment that scales and will need a different solution.
Docker Compose has always been an awesome file format, built on top of an idiosyncratic orchestration engine that doesn't interoperate well with anything else.
Writing a spec is a good first step! If work is underway to make this a shared multi-service dev environment that works across Kubernetes, ECS, etc, that would be even better.
When I read the spec, there are ominous words about partial implementations. That makes me nervous. But I'm cautiously optimistic.
There are partial implementations because some of the things in the existing spec are just not a good match for ECS or Kubernetes, for example. The aim is to fix those things in the spec. There are conformance tests so we can hopefully start checking implementations soon.
Yay for conformance tests! What's the strategy for handling things that don't make sense for other platforms? Do you expect that they'll be removed from the spec eventually, or fit in as some kind of platform-specific extension mechanism?
We are expecting to have to have some platform specific extension mechanism for some things eventually, but yes I think some things can be removed too.
Just diving into Docker, and I'm already a bit confused... There's a docker stack (or swarm) that allows me to define containers (services?) and their networking... but then there's also docker compose, which does the same thing? Even the yaml config specs are similar.
Docker is a tool that includes a daemon that runs in the background and a client app that communicates with the daemon. The daemon runs a packaged-up program and its dependencies ("image") as basically a chroot environment using an overlay filesystem and isolated network, in a custom cgroup and namespace (basically, process space/virtual filesystem paths different from your normal user process space/filesystem).
Swarm is a (sadly) soon-to-be-abandoned way to spin up a cluster of multiple hosts with Docker daemons; don't waste your time on it. The comparable solutions are AWS ECS or [to a lesser extent] HashiCorp Nomad.
Docker Compose is a console app that takes a config file and starts multiple Docker containers, creates volumes, and configures Docker networks - on a single Docker instance, so it's only really useful for testing stuff locally that requires multiple containers running at once.
Swarm is an orchestrator while compose is designed to describe services to be run on a single machine.
Basically, you may want to use swarm (or k8s or anything else) in order to orchestrate your containers across a multi-machine cluster and compose when defining a set of services running on a single host.
Yes, it focuses a lot on shared resources, but the negative space defined by where resources are not shared certainly informs any human-defined networking topology. I'm not so sure a tool couldn't make a pretty good stab at doing the same thing.
it essentially the whole thing evolved as follows:
- docker - it is just a packaging mechanism for your app and a deployment unit if you use Kubernetes, ECS or similar
- docker-compose - if you have an app that spreads over multiple docker containers (i.e. you're doing micro services) it allows you to spin all of them with a single command allowing these components to be interconnected. It is essentially your local testing environment.
- swarm - as far as I know it is a dead project, it supposed to compete with Kubernetes and similar, but it failed
This is great. Docker sometimes feels like a tangle of hacks, for example docker-compose build and docker build diverge and don't use the same layers. More standardization is better
ok, so... what? The notion here is to take the compose file, which is basically saying "this is what I want the state of docker to look like", and turn it into a generic application specification that multiple orchestration engines can contribute to and use... And... How would this work? Are we gonna have this smorgasbord of definitions in compose now with a subset of each working on specific orchestration systems, or something? Because that would be completely useless.
So unless there genuinely is a commitment to being able to have each orchestration engine just unreservedly guaranteed take any definition possible in docker-compose and deploy it, then there is no value to be gained here. None. Without that guarantee, then for every system you attempt to deploy a compose file to, you must DEEP DIVE into its internals to understand its limitations and costs and tradeoffs.
This gigantic massive timesink of a process is something I have always had to do. And I always discover all kinds of things that would have absolutely blocked practical deployments. This is the real thing that's bothering me, not that k8s and azure and docker all can sorta read some subset of a configuration. I don't care at all about that. It's not useful.
I'm not saying this will happen, but one way I might like to see this play out is a bit like the following.
I have a bunch of apps. Some of them talk to each other, some do not. In general, if I deploy 5 copies of something, you should assume I mean "never on the same box" by default. (I'm looking at you, Kubernetes. WITAF.)
You could, as a vendor, do a lot of sophisticated work on the spanning tree to reduce the amount of network traffic versus loopback traffic. You might try to spread out unshared volumes across as many motherboards as possible. You could differentiate on how to most efficiently and/or stably migrate from previous config to new config, or vice versa. You could do a bunch of knapsack work, including (and this is a pet peeve of mine) pre-scaling for cyclical traffic patterns.
If you've ever looked at the Nest thermostat, one of several defining features was that it figures out the thermal lag in your heating and cooling system and it can make the house be the correct temperature at a particular time, rather than waiting until the appointed time to do anything. If a hockey puck on my wall can do shit like this then why doesn't every cloud provider do this day 1?
Tack onto this some capacity planning infographics, and a system to schedule bulk, low priority operations around resource contention, and I could probably help get you a meeting with my last boss, my current boss, and probably at least the one after that.
Compose has a lot of users, and hundreds of thousands of Compose files on GitHub, so we wanted to open up development as much as possible.
(I work at Docker)