Previous article: "This is nowhere near ready for those who just want to get the job done."
This article: "It'll be better in the future, you'll see!"
The former is verifiable, the latter is a hypothesis.
Docker in Production: A retort
41–50 of 132 posts
Re: Docker in Production: A retort
#42Are these breaking changes problems caused by Docker itself? I was contacted by Docker and was considering applying, but it sounds like their engineering management doesn't know what they're doing. Is this depiction accurate or is it overblown?
I would recommend investigating the matter yourself, and making your own opinion. What specifically has been broken in past Docker releases? How have they handled it? How would you have handled it? If you do decide to interview with Docker, make sure to bring up your findings, especially areas where you think they screwed up. This has two advantages: you can see how they react to constructive criticism, and they can observe that you are capable of making your own opinion and providing constructive criticism.
If you really want to impress your interviewers, back up your criticism with a pull requests fixing the issue. That will automatically put you on top of the pile of resumes.
Re: Docker in Production: A retort
#43Earlier quoted context omitted.
As someone considering using Docker for production infrastructure I'd love to hear from a docker expert what their thoughts are on the following observations: * 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 Do…
Author from the original article here. >>> * 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'…
>Having docker without orchestration is like having cars without roads.
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.
Re: Docker in Production: A retort
#44Anyone know why Erlang doesn't run well on containerized Docker?
I have used Erlang and containers, but not in combination.
I know that Erlang (really, beam) has some ideas about what the network should behave like, and highly virtualized/"software defined " networking may confuse it.
Re: Docker in Production: A retort
#45Docker founder here.
I keep reading articles stating that "the Docker API changes with every release", but the assertion is never backed by any specific examples. Has anyone here encountered an actual breaking change? If so, I would appreciate you sharing the specifics so we can fix it.
Docker is by no means perfect:
- I remember that in 1.10 the switch to content-addressed registries meant that older clients could not pull by digest (but all other commands, and even non-pinned pull, still worked). This was not an accidental breaking change: it was the result of a difficult tradeoff. In the end we decided that the benefits of the new content-addressed model outweighed the inconvenience. To guide our decision we used data from Docker Hub to assess how many clients would be affected. I forget the exact number but it was a very small minority.
- And in 1.12 we got bitten by a change in how Go 1.6 processes HTTP headers (it became more strict and thus rejected headers from older clients). That was quite simply a screwup on our part.
So we've had our share of screw-ups, no question. But lately I've been reading the "breaks at every release" meme more and more. Based on the evidence I have, it seems incredibly disconnected from reality.
What am I missing?
Re: Docker in Production: A retort
#46Earlier quoted context omitted.
> Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea. What is your typical server infrastructure? We use bare machines and had kernel panics very rarely (only with experimental MACVLAN). We did not 'get away' with anything. We have been using Docker for over 2 years, and LXC much more and know how to handle mounted directories, it is not a rocket science. We use…
I can't imagine what your use case is that requires running bleeding edge database servers in production and that cannot be managed via native OS packaging. Would you please enlighten us? Otherwise it really sounds like you're using a non-best practice (running a DB in a container) to paper over another non-best practice (treating your DB as a non-sacrosanct piece of infrastructure by introducing intentional instabil…
I really don't understand why you insist. You keep saying "best-practice" like it is a law, but the truth is there is no such thing is best. It fits our cases, worked well, continues to work well. Did I say it cannot be managed with traditional package managers? No. But I do not like upstart nor systemd, and I like the simplicty I get from Docker, and ability to replicate the almost same environment easily. I really don't care a guy on the internet that is upset because I don't follow their "best" practice. I gave you my use cases, said that Its workinng well for almost 2 years and list the advantages, you still focus on your "best" cases. It works just fine as long as you know what you are doing, and I expect to hear more justifiable and technical explanations why this should not be done, rather than your feelings and biased best practices that does not translate into any verifiable points.
Re: Docker in Production: A retort
#47Earlier quoted context omitted.
I'm still not sure I follow. If you're not setting up a DB that will have such heavy usage that it needs bare metal access, what's wrong with setting it up such that it stores data on a NAS, or via mounted volumes? Then when it comes time to upgrade due to a security issue, you can create a new container, spin it up, and if it barfs, relaunch the old one.
Unnecssesary complexity. A VM would've sufficed for what you described.
What is the "Unnecssesary complexity" in this scenario? You literally just run a command and you can spin up a new container with your data.
Re: Docker in Production: A retort
#48Earlier quoted context omitted.
Less downtime and automatic recovery, I'd say. When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would.
> Less downtime and automatic recovery, I'd say. How? By magic dust sprinkled by Docker Inc? > When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would. You seem to forget that a) container's filesystem needs to be downloaded in the first place, and b) that VMs can work in a standby mode, not running the serv…
Its faster virtual machines, which do not have live migration for that specific use case. Just because you are doing it for years does not mean that it cannot be improved or have an alternative with its both downsides and upsides.
Re: Docker in Production: A retort
#49Earlier quoted context omitted.
I find VMs are super slow for development purposes (I mean setup, starting up and shutting down rather than actual processing), where docker's made a massive difference. YMMV especially if you're not spinning up new projects frequently. They might be a better solution in production, but I have a strong preference for production mimicking development.
Precisely the point. It's fine in dev but once you are running in prod and need rock solid stability the generally accepted dogma is that containerizing your DB is playing with fire. As you said, YMMV.
[deleted]
Re: Docker in Production: A retort
#50Earlier quoted context omitted.
> Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea. What is your typical server infrastructure? We use bare machines and had kernel panics very rarely (only with experimental MACVLAN). We did not 'get away' with anything. We have been using Docker for over 2 years, and LXC much more and know how to handle mounted directories, it is not a rocket science. We use…
> They are often outdated, we mostly get one of the latest builts, and in some cases Snapshot builds, That's a very usual thing to say about databases. For critical and commercially supported things such as your relational databases, nobody runs snapshot builds. You run whatever builds your vendor supports, and for all those you mentioned (and most other vendors) that is going to be native packages.
Native packages are nothing more than packaged software with startup and maintaining scripts, (and tested) so as long as you can manage these, I really don't see I have to stick to what my vendor thinks best.