We had some issues with docker-compose for our use-cases, such as persistent database even when recreating every container from scratch, so I hacked on some stuff that become "dup" [0] (nee. docker-up)
Ps. it's written in Nim, which was a lot of fun!
So, some dodgy code and a JSON file later, and our team uses the `dup` CLI to run everything with exactly zero hitches thus-far, and we've been using (across it's two incarnations) for... 18 months now?
Docker is a slow, blunt tool for just containerizing dependencies IMO.
No it does not change processor architectures for you.
Macs don't appear to have support for containers which is what Docker is. Well that is probably bollocks because they are *BSD based and I know that FreeBSD at least has a form of containerization and I seem to recall that the whole container thing was invented on a BSD - "jails".
So Docker can't run native on iStuff. You have to run it within a Linux VM. I gave up on Googling for "apple mac jail" 8)
The reason why Docker runs slowly on Macs is because it is running under emulation within a VM.
Unfortunately, Macs are not cool enough to run Docker, so there 8)
Cheers Jon
Always beware of perception bias or whatever the right term is for this. When docker was new it got tons of hype and people were talking about how great it was. Now it's no longer the hot new thing so it's just another tool many people are using quietly and successfully. It no longer warrants much positive discussion. The people using docker in production successfully don't feel compelled to write articles about it working for them.
I'd say the pros/cons of docker (or containers in general) are similar to the pros/cons of buying hand made vs. mass produced goods. The hand made goods will probably be higher quality but they take more time and skill to produce so they're more expensive. The mass produced goods will probably be lower quality but will work fine and at least offer consistent/reliable level of quality. They take less time and skill to produce so they'll also be less expensive. In the context of using Docker in production this translates to it being very good for solving 'off the shelf' types of problems quickly and reliably. It's essentially the software/systems version of an assembly line. If you don't need an assembly line then docker may be worthless or even a total waste of time. If you do need an assembly line it's the best option currently.
There aren't articles about docker in production because barely anyone adopted it for major production environments [yet]. And for the few who are early adopters, there wasn't enough time to write articles.
* Docker encourages fully disposable infrastructure
* Docker containers can be more secure then traditional environments
* Docker provides for indempotent environments agnostic of hardware concerns etc
* Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better
Specifically, I'm curious if my observations are correct, and if they are why they are correct and why are they SO much better (vs current docker alternatives including non-container based approaches).
>>> * Docker encourages fully disposable infrastructure => I'd consider that incorrect and/or misleading
Docker is meant to manage disposable (i.e. stateless) applications. They are expected to be killed/stopped/restarted at any time, no persistent state, no data.
An application is either disposable OR not disposable by its design, docker doesn't change that. (For instance, don't try to dockerize databases).
Docker gives you a quick, nice and easy way to package your applications with dependencies (as Docker image) AND deploy them. [This is valuable]
It's especially great for development and test environments because you can run many containers (i.e. applications) on a dev/test machine, without dependency/deployment hell. [This is very valuable]
>>> * Docker containers can be more secure then traditional environments => No. Just No.
Docker has nothing to do with security.
>>> * Docker provides for idempotent environments agnostic of hardware concerns etc
Docker gets to ignore the hardware. You do not.
You get to buy, setup and manage servers. Maintain a full environment that can run docker.
It can be an undertaking full of dangers, as told by this article and mine :D
>>> * Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better
Docker allows to package and deploy an application. It doesn't do anything about infrastructure at all (i.e. machines, load balancers, DNS, discovery), which you still have to manage and it's a HARD problem.
The orchestration systems is supposed to help you manage all of that. As a result, it will be able to automatically kill/restart/move/add containers across a cluster and make the necessary [physical or virtual] infrastructure changes.
Container + Orchestration will be a [r]evolution to manage entire giant fleets of hosts and applications. [This will be infinitely valuable (allowing me to automate the work of 10 people, all freeing all my time to enjoy unlimited free drinks and foods)]
IMO: In the current state of affairs. Having docker without orchestration is like having cars without roads.
Host volume mappings. Problem solved.
I've been using them for over a year, with all kinds of different databases, postgres, mysql, mongodb, in dev, ci, and production, never had a problem. It gives you a nice separation of what is and what isn't part of the application state, and makes backups a breeze.
Docker's stated purpose is to be the "shipping container" abstraction for server-side code.
Shipping containers are not much more exciting than any other kind of box (VM, jail, whatever) in isolation. Things get more interesting when every port has container-optimized cranes and there are thousands of container ships competing for your business.
But then a while later all the buzz was containerization, with Docker as the poster boy. This, i suspect, in that rather than have the overhead of a VM and such, you could spin up a container instance over there, take it down over here, and achieve much the same result. This in particular if the content of your VM or container was talking to a storage backend anyways.
That said, I've found myself swinging back towards preferring VMs - with docker-like infrastructure made available. The runv project (https://github.com/hyperhq/runv/) is an interesting and functional take on Docker-with-VMs since I spend way too much time wanting to do privileged things in containers.
Why ever not? There no less reason to do so in a container - and all the usual benefits still apply.
I just want to tack on the upgrade rollback situation. A container looks a lot like a process from the host os point of view. You can bring up the new release and leave the old release running on the same machine without much difference in load. The load just shifts to the new container. With a VM approach, you kind of need both vm's for the whole upgrade window.
Depending on your orchestration, blue/green deployment is pretty straightforward.
I may suppose that you talk about [CPU] load, because you are running computations/processing applications and not webservices.
FWIW, Kubernetes solves this out of the box.
Docker can totally reduce the risk of in-container services being exploited. It has sane defaults, and makes it easy to distribute other restrictions with the application (seccomp profile, apparmor settings, etc).
Firstly, I think it is correct that docker encourages disposable infrastructure, because your docker setup basically must be able to recover from the loss of a container. I think it would not be sane to expect your containers to "just keep working".
Regarding security, I don't think Docker provides much other than the illusion of better security at the moment. At least on Linux containers don't add security that you can't get with traditional services.
I suppose if you use authenticated images you can at least be sure that you're running the code you think you are, but then again package managers have had signing for ages.
You're always going to have to test your software in the environment you will be deploying it in, because driver bugs and weird interactions still exist. Docker doesn't really let you ignore the hardware
I have no opinion of kubernetes and such at the moment.
What docker does grant is an easy method of "packaging" software... Pretty much anyone can just throw everything together in a big bundle and distribute that. For certain use-cases, this can give a development team much more speed, since setting up a workable environment is much faster. There is also a nontrivial amount of software that simply does not bother with OS packaging where containers can help you deploy it in a more controlled fashion.
Why?
For sure for developer it's a big thing, for SysAdmin and people thinking about the datas it's more a pain in the ass.
Anyway, no way to go back. This is the future Jack.
On the last DockerConf you could ear ADP talking about their success with Docker, but obviously their there to promote Docker. ;)
Absolutely. You will get the most out of it like this. You can run pets, and treat containers VMs but I don't think you will get all the advantages.
* Docker containers can be more secure then traditional environments
Out of the box you get isolation from namespaces (not being able to see the host filesystem or network), resource limits via cgroups, a default seccomp profile that restricts some system calls that could be used in exploits, and more. You can set all these defaults yourself but the majorty of people do not. So there are definit benefits.
* Docker provides for indempotent environments agnostic of hardware concerns etc
Most applications do not talk directly to hardware, the default container does not directly present hardware interfaces, yes.
* Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better
It does help to have software to manage programs across multiple computers, for scaling and redundancy, yes.
* Use modern tools to spin up a dev env * Determine how to monitor and maintain dev and deploy * Test dev env * Determine, based on dev and a deep risk assessment how prod will look * Create prod env * Determine how to monitor and maintain prod env and deploy (based on your test) * Test new prod env * Open up prod env to end users
It's not bloody rocket science - it's Engineering and the steps above hide loads of steps and feedback loops such as a safe upgrade method eg snapshot/clone VM, test, release.
If your product is important to you then you take it seriously and treat it right!
Cheers Jon
PS Did I mention documentation?
So nevermind a retort, what I would like to see is a sane, sensible "business value" cost/benefit, pros v. cons breakdown of just what the heck you're actually gaining (and losing) using Docker vs. some other architecture/methodology. Because absent that it's all just hype and kool-aid drinking in my opinion.
What would help with the above is if people would document what they are doing with Docker that works, because either they are hurting but not realizing it, or the author of the article is just "doing it worng" and whining about it in public. What is really going on with Docker, et. al.!?