26 ms·

Docker in Production: A retort

133 points by crymer11 10y ago

smegel 10y ago
> So the point is valid, but there are some big names invested in solving it, so I’m optimistic we’ll see some stability in the future And it will still be valid if someone forks Docker. In fact, that would validate the criticism.
rusanu 10y ago
The HN discussion of the article being retorted: https://news.ycombinator.com/item?id=12872304 https://news.ycombinator.com/item?id=12872304
Johnny555 10y ago
This seems less of a "retort" and more of a validation that most of the issues brought up in the original article are valid complaints.
CSDude 10y ago
> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story. Sorry, but this is really a bad advice. We have ran and contine to run various databases inside Docker including MySQL, PostgRedis, Cassandra, Elastic Search, RethinkDB even HDFS with proper user rights and configuration. We can maintain the state just as fine. If your only problem is to move the data, all you have to do is stop, export, tar it, move to another server, just as you would do in a normal server. Docker is not a magic bullet to solve such kind of issues. Yes, Docker might have another problems, but just as you could not run someting with state inside Docker does not mean "thou shalt not run" , there are various ways to manage state. Host, IO can get crash regardless of Docker.
- otterley 10y ago
  What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't fix it." It's there to store data on behalf of the applications you write; it is not a thing to upgrade or migrate for its own sake unless there is a bug to quash or a new feature that your application will depend upon; and even then, migrations must be carefully planned to preserve availability for users. Docker and the like seem like a solution in search of a problem for this particular part of a typical service infrastructure. Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.
  - kstenerud 10y ago
    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.
    - toomuchtodo 10y ago
      Unnecssesary complexity. A VM would've sufficed for what you described.
      - cs02rm0 10y ago
        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.
        ascendantlogic 10y ago
        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 10y ago
        [deleted]
      - distracted_boy 10y ago
        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.
  - 10y ago
carapace 10y ago
I've never used Docker, or containers, but I read about things like "Breaking changes and regressions ... a well documented problem with Docker" and "Can’t clean old images ... a well known issue" and it just seems to me like a crazy thing to try to use and depend on this thing/company. Bluntly put they seem like children. 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.!?
- ben_jones 10y ago
  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 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).
  - chousuke 10y ago
    I'm not sure if I qualify as a docker expert, but I feel like I need to comment on these... 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.
nickthemagicman 10y ago
I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'.... That says all you need to know about the trustworthiness of Docker. EVEN DOCKER PROPONENTS caution against using it in 'important' apps.... What apps are people investing time in that aren't 'important'? Is there a coffee machine that is ok to use for a docker app somewhere?
- sheeshkebab 10y ago
  AWS was also considered not a fit for running "core" apps and databases... look where we are now. Docker is certainly having some teething issues - and things like kubernetes are certainly WIP. But I wouldn't be as skeptical - plenty of companies use it in production already, for "core" apps.
  - nickthemagicman 10y ago
    Interesting, yeah I truly see the potential of the idea. It's definitely the future. Really glad to see Google and others getting on board and giving them the resources they need.
- user5994461 10y ago
  > Is there a coffee machine that is ok to use for a docker app somewhere? Most coffee machines are docker ready. To guarantee you the best experience, you will need to setup a pair of coffee machines, plus an orchestration system that will be responsible for swapping them automatically when one ran out of coffee. Note: There are only prototype of orchestration systems. Nothing for sale in the corner shop yet. --- More seriously... Not important: Most internal, development, and test systems Somewhat important: Web applications, various support micro services. (They all are stateless, with multiple instances, and reactive failover by their respective load balancers). Critical: Most databases (especially the ones without multi-master mode and automatic failover), trading applications, payment systems, accounting systems, databases with money $$$
  - nickthemagicman 10y ago
GirlsCanCode 10y ago
I don't understand the need for Docker at all. For many people, it's a a bad way to try to make a fundamentally flawed environment like Ruby or Node and make it scale sort of.
cuillevel3 10y ago
Good retort. The original article seemed clueless, the part about aufs was just wrong, the complains about the apt repo exaggerated. Running docker on Debian ancient is kind of brave, though. And software is finished after five years, maybe in the financial industry. Currently development has such a pace, I'd say after five years it's abandoned and replaced.
wickedlogic 10y ago
Related question, what happens when a docker images gets pop'd.... how do you keep it around for investigation, does it get imaged for later forensics? Every time I have asked people in IRL doing docker, they seem to focus on updating/patch... on how easy that is and moving on... but that is not always an option for every client. Do you just image all docker images before they get terminated/migrated?
- justincormack 10y ago
  All the containers are available after termination, yes, so you can investigate.
pmarreck 10y ago
Anyone know why Erlang doesn't run well on containerized Docker?
- justincormack 10y ago
  What issues are you having? Containers are not really different from non containerised environments. Have you filed an issue?
  - pmarreck 10y ago
    It's something I read in another HN thread
- jwatte 10y ago
  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.
- empath75 10y ago
  Why not use an erlang unikernal instead?
- lobster_johnson 10y ago
  It runs fine. However, the challenges are the same as any other environment (e.g. AWS): Remember to set a Erlang cookie, and make sure the host name is sane/set and resolvable, otherwise you will run into issues with the portmapper (epmd).
- bitwalker 10y ago
  I run several erlang/elixir applications in containers, it works just fine. I'm not sure why someone claimed it doesn't, but I suspect they didn't try very hard if they did have trouble.
  - pmarreck 10y ago
    Chokes under significant load, perhaps? Do your erl/iex apps receive much traffic?
pfarnsworth 10y ago
Are 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?
- shykes 10y ago
  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.
conradk 10y ago
Can anyone comment on how rkt compares to Docker regarding the issues from this article ? And how does rkt compare to Docker in production in your experience ? I've been using Docker in production for a single server website and have had very few issues. I do like how easy it is to reproduce a working environnement with a "docker build" though. That being said, I think that just using Ansible on a server is probably an easier and more reliable solution. Ansible is battle tested and allows to have reproducible environments too.
- DigitalJack 10y ago
  Is ansible still python 2.7 only?
  - okket 10y ago
    Yes, and it will still stay so until RHEL 5 is EOL (next year I think), so the Python 2.4 support requirement can be dropped. This is the main showstopper. There is also work in progress: https://docs.ansible.com/ansible/python_3_support.html https://docs.ansible.com/ansible/python_3_support.html
  - krakensden 10y ago
    They've been working on it, but it might just be the control machine that's 2/3 ready.
jwatte 10y ago
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.
- DrNemski 10y ago
  No what I was saying was its ready for today in certain use cases. But only if you look at it as a long term transition and not a short term project
shykes 10y ago
Docker 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?
- OhSoHumble 10y ago
  Oh, hai there. I haven't gone 'whole hog' on Docker yet and subsequently tried to push for rolling it out in production for my team. I don't know how incorrect I am, but it seems like the Docker project is more interested in features rather than stability. Except, like you said, I don't have any specific examples to back that up. Maybe it's just community hive mind thought bleeding onto my decision making abilities? The most concrete failing I've experienced was the deprecation of the boot2docker project in favor of docker machine. When I started using docker machine, stuff just... broke... and it left a bad taste in my mouth. In fact, using docker on either a mac or windows is just awful for me. My anecdotal experience is that it breaks in small ways that then that can really disrupt my productivity. I'm in the process of picking up docker again and it led me to install Arch on my work laptop just so I can have native containers. Right now my use case is using containers to test Chef cookbooks and it works... alright. Not as well as virtual machines, but alright. How docker handles init bothers me a little bit but it's nothing the maintainers of the testing suites for Chef couldn't handle through yaml configuration options. Oh, I guess while you're here... one thing I've been wrestling over is the usage of dockerfiles. I have no problem with containers but to me, it looks like using a configuration management system to bake container images seems to grant so much more flexibility and testing capabilities that I can't really see dockerfiles as anything other than an intermediate step. Is this a valid viewpoint?
lobster_johnson 10y ago
Re ECR (the EC2 Container Registry), it has one downside that the author doesn't mention, which also applies to Google's own registry. A Docker registry has own authentication system. So does AWS (and GCloud). So what you end up is one wrapping the other: To access the ECR, you have to run an AWS command to get a token to put into "docker login". Google has "gcloud docker login" for the same purposes. Both produce temporary credentials that time out, so can't be used for long-running things. This means that any tool designed to work with a Docker registry needs to support this particular workflow. For example, this affects Drone [1]. It also adds complexity. GCloud is particularly heavy on the authentication complexity side already (compared to AWS's comparatively simple keypair approach), and with SSH, GCR and Kubernetes on top it starts to stack up in ways which can make users' head spin. Straight Docker Hub is refreshingly straightforward by comparison. [1] http://readme.drone.io http://readme.drone.io (not to be confused with drone.io)
- erikgrinaker 10y ago
  At least with Google's GCR, this is no longer the case. They have a Docker credentials helper [1] which transparently handles authentication for regular interactive use, and service accounts with permanent keys [2] for use with CI servers etc. I find both of these to be fairly straightforward to use. [1] https://github.com/GoogleCloudPlatform/docker-credential-gcr https://github.com/GoogleCloudPlatform/docker-credential-gcr [2] https://cloud.google.com/container-registry/docs/advanced-authentication#using_a_json_key_file https://cloud.google.com/container-registry/docs/advanced-au...
girvo 10y ago
As an example of Docker in production: Expedia are moving lots of their legacy infrastructure into Docker containers. My third-party contracting team that works on projects for Expedia (we're brought in so the rules and bureaucracy don't apply to use, allowing us to rapidly iterate and experiment in ways the core teams can't) have been using Docker end-to-end (local development through to autoscaled production deploys) While there were teething issues, this article does a good job of pointing out the flaws in the original article, I think. It's been easier to get our team up to speed on Docker and it's gotchas than nearly any other configuration management, server management, et al. systems that we tried!
- user5994461 10y ago
  Short version: Nope :p Long version: I met the DevOps guy who [I believe] is responsible for pushing Docker at Expedia and we've had long conversations about it. They were lucky to have had a particular environment and a specific version that worked, and got it pinned down and frozen very early. I suppose you are on the dev side and not aware of all that. (Hell, maybe, you're not even in the same subsidiary of Expedia). I'm glad it all worked out for you as a dev, my devs are also happy with Docker. (We're probably used as an example of Docker success story at times). In the end, there is no free lunch. There is dirty work done and more to be done. Some of which is invisible.
  - girvo 10y ago
    Sorry if I didn't explain it correctly! We're an external team (completely seperate to Expedia) that is brought in to build certain products :) And yeah, definitely. I spent a couple weeks debugging the ECS issues we had with the Wotif guys, which was fun, but none of the issues were insurmountable! We were one of the first adopters for the new ECS deployment, and while some parts of it weren't fun (Splunk still drives me mental) for the most part it went smoothly: that's down to how good the ops team is, I think. Our specific case was somewhat special, in that because we're outside of the rest of the infrastructure, and had extensive experience with Docker in production for other clients, our apps were basically ready to rock from the get-go. I think we were the first PHP deployment within the new ECS deployments! Should send me an email, it's in my profile, would love to chat sometime!
yawz 10y ago
"The internet has been a wash with a well written article about ..." Typo: a wash => awash I know! The content is more important than the quality of the writing, but it's a little surprising to see such a mistake jumping at the reader at the start of an article. We should go back to the first days of the Internet where "updates" were possible. :) I would have loved to suggest an update quickly.
- DrNemski 10y ago
  My googling failed on this account on the correct grammatical term.
corv 10y ago
Docker seems very limited when it's unsuitable to run databases. I've never seen this limitation with other container solutions. What is it about Docker that makes it problematic?
- lobster_johnson 10y ago
  Nothing. It's bad advice. Lots of companies run databases in containers.
- SoreGums 10y ago
  Most likely lack of planning and applying a it should "just work" process to the scenario at hand... The thing I've learnt with Docker is that all the other Prod issues still exist. Docker at its core only solves the executable part or distribution of the process to run. Still need to figure out, network, storage, monitoring, backups, discovery, etc... What starts out as a single host can quickly quadruple once all the other considerations are taken into account and wanting a scalable, reliable and available system.
ledil 10y ago
if I am using mount Volumens to export my data, can I bypass the aufs/overlay implementation/logic ? do I need to pay attention only if I don't mount the volumes? thx
- justincormack 10y ago
  Volume mounts do not use the aufs/pverlay drivers, no. These are used for build, and for constructing the rott filesystem for running containers so files are shared.

133 points by crymer11 10y ago

> So the point is valid, but there are some big names invested in solving it, so I’m optimistic we’ll see some stability in the future And it will still be valid if someone forks Docker. In fact, that would validate the criticism.

rusanu 10y ago

The HN discussion of the article being retorted: https://news.ycombinator.com/item?id=12872304 https://news.ycombinator.com/item?id=12872304

Johnny555 10y ago

This seems less of a "retort" and more of a validation that most of the issues brought up in the original article are valid complaints.

CSDude 10y ago

> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story. Sorry, but this is really a bad advice. We have ran and contine to run various databases inside Docker including MySQL, PostgRedis, Cassandra, Elastic Search, RethinkDB even HDFS with proper user rights and configuration. We can maintain the state just as fine. If your only problem is to move the data, all you have to do is stop, export, tar it, move to another server, just as you would do in a normal server. Docker is not a magic bullet to solve such kind of issues. Yes, Docker might have another problems, but just as you could not run someting with state inside Docker does not mean "thou shalt not run" , there are various ways to manage state. Host, IO can get crash regardless of Docker.

otterley 10y ago
What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't fix it." It's there to store data on behalf of the applications you write; it is not a thing to upgrade or migrate for its own sake unless there is a bug to quash or a new feature that your application will depend upon; and even then, migrations must be carefully planned to preserve availability for users. Docker and the like seem like a solution in search of a problem for this particular part of a typical service infrastructure. Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.
- kstenerud 10y ago
  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.
  - toomuchtodo 10y ago
    Unnecssesary complexity. A VM would've sufficed for what you described.
    - cs02rm0 10y ago
      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.
      - ascendantlogic 10y ago
        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 10y ago
        [deleted]
    - distracted_boy 10y ago
      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.
- 10y ago

carapace 10y ago

I've never used Docker, or containers, but I read about things like "Breaking changes and regressions ... a well documented problem with Docker" and "Can’t clean old images ... a well known issue" and it just seems to me like a crazy thing to try to use and depend on this thing/company. Bluntly put they seem like children. 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.!?

ben_jones 10y ago
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 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).
- chousuke 10y ago
  I'm not sure if I qualify as a docker expert, but I feel like I need to comment on these... 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.

nickthemagicman 10y ago

I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'.... That says all you need to know about the trustworthiness of Docker. EVEN DOCKER PROPONENTS caution against using it in 'important' apps.... What apps are people investing time in that aren't 'important'? Is there a coffee machine that is ok to use for a docker app somewhere?

sheeshkebab 10y ago
AWS was also considered not a fit for running "core" apps and databases... look where we are now. Docker is certainly having some teething issues - and things like kubernetes are certainly WIP. But I wouldn't be as skeptical - plenty of companies use it in production already, for "core" apps.
- nickthemagicman 10y ago
  Interesting, yeah I truly see the potential of the idea. It's definitely the future. Really glad to see Google and others getting on board and giving them the resources they need.
user5994461 10y ago
> Is there a coffee machine that is ok to use for a docker app somewhere? Most coffee machines are docker ready. To guarantee you the best experience, you will need to setup a pair of coffee machines, plus an orchestration system that will be responsible for swapping them automatically when one ran out of coffee. Note: There are only prototype of orchestration systems. Nothing for sale in the corner shop yet. --- More seriously... Not important: Most internal, development, and test systems Somewhat important: Web applications, various support micro services. (They all are stateless, with multiple instances, and reactive failover by their respective load balancers). Critical: Most databases (especially the ones without multi-master mode and automatic failover), trading applications, payment systems, accounting systems, databases with money $$$
- nickthemagicman 10y ago

GirlsCanCode 10y ago

I don't understand the need for Docker at all. For many people, it's a a bad way to try to make a fundamentally flawed environment like Ruby or Node and make it scale sort of.

cuillevel3 10y ago

Good retort. The original article seemed clueless, the part about aufs was just wrong, the complains about the apt repo exaggerated. Running docker on Debian ancient is kind of brave, though. And software is finished after five years, maybe in the financial industry. Currently development has such a pace, I'd say after five years it's abandoned and replaced.

wickedlogic 10y ago

Related question, what happens when a docker images gets pop'd.... how do you keep it around for investigation, does it get imaged for later forensics? Every time I have asked people in IRL doing docker, they seem to focus on updating/patch... on how easy that is and moving on... but that is not always an option for every client. Do you just image all docker images before they get terminated/migrated?

justincormack 10y ago
All the containers are available after termination, yes, so you can investigate.

pmarreck 10y ago

Anyone know why Erlang doesn't run well on containerized Docker?

justincormack 10y ago
What issues are you having? Containers are not really different from non containerised environments. Have you filed an issue?
- pmarreck 10y ago
  It's something I read in another HN thread
jwatte 10y ago
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.
empath75 10y ago
Why not use an erlang unikernal instead?
lobster_johnson 10y ago
It runs fine. However, the challenges are the same as any other environment (e.g. AWS): Remember to set a Erlang cookie, and make sure the host name is sane/set and resolvable, otherwise you will run into issues with the portmapper (epmd).
bitwalker 10y ago
I run several erlang/elixir applications in containers, it works just fine. I'm not sure why someone claimed it doesn't, but I suspect they didn't try very hard if they did have trouble.
- pmarreck 10y ago
  Chokes under significant load, perhaps? Do your erl/iex apps receive much traffic?

pfarnsworth 10y ago

Are 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?

shykes 10y ago
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.

conradk 10y ago

Can anyone comment on how rkt compares to Docker regarding the issues from this article ? And how does rkt compare to Docker in production in your experience ? I've been using Docker in production for a single server website and have had very few issues. I do like how easy it is to reproduce a working environnement with a "docker build" though. That being said, I think that just using Ansible on a server is probably an easier and more reliable solution. Ansible is battle tested and allows to have reproducible environments too.

DigitalJack 10y ago
Is ansible still python 2.7 only?
- okket 10y ago
  Yes, and it will still stay so until RHEL 5 is EOL (next year I think), so the Python 2.4 support requirement can be dropped. This is the main showstopper. There is also work in progress: https://docs.ansible.com/ansible/python_3_support.html https://docs.ansible.com/ansible/python_3_support.html
- krakensden 10y ago
  They've been working on it, but it might just be the control machine that's 2/3 ready.

jwatte 10y ago

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.

DrNemski 10y ago
No what I was saying was its ready for today in certain use cases. But only if you look at it as a long term transition and not a short term project

shykes 10y ago

Docker 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?

OhSoHumble 10y ago
Oh, hai there. I haven't gone 'whole hog' on Docker yet and subsequently tried to push for rolling it out in production for my team. I don't know how incorrect I am, but it seems like the Docker project is more interested in features rather than stability. Except, like you said, I don't have any specific examples to back that up. Maybe it's just community hive mind thought bleeding onto my decision making abilities? The most concrete failing I've experienced was the deprecation of the boot2docker project in favor of docker machine. When I started using docker machine, stuff just... broke... and it left a bad taste in my mouth. In fact, using docker on either a mac or windows is just awful for me. My anecdotal experience is that it breaks in small ways that then that can really disrupt my productivity. I'm in the process of picking up docker again and it led me to install Arch on my work laptop just so I can have native containers. Right now my use case is using containers to test Chef cookbooks and it works... alright. Not as well as virtual machines, but alright. How docker handles init bothers me a little bit but it's nothing the maintainers of the testing suites for Chef couldn't handle through yaml configuration options. Oh, I guess while you're here... one thing I've been wrestling over is the usage of dockerfiles. I have no problem with containers but to me, it looks like using a configuration management system to bake container images seems to grant so much more flexibility and testing capabilities that I can't really see dockerfiles as anything other than an intermediate step. Is this a valid viewpoint?

lobster_johnson 10y ago

Re ECR (the EC2 Container Registry), it has one downside that the author doesn't mention, which also applies to Google's own registry. A Docker registry has own authentication system. So does AWS (and GCloud). So what you end up is one wrapping the other: To access the ECR, you have to run an AWS command to get a token to put into "docker login". Google has "gcloud docker login" for the same purposes. Both produce temporary credentials that time out, so can't be used for long-running things. This means that any tool designed to work with a Docker registry needs to support this particular workflow. For example, this affects Drone [1]. It also adds complexity. GCloud is particularly heavy on the authentication complexity side already (compared to AWS's comparatively simple keypair approach), and with SSH, GCR and Kubernetes on top it starts to stack up in ways which can make users' head spin. Straight Docker Hub is refreshingly straightforward by comparison. [1] http://readme.drone.io http://readme.drone.io (not to be confused with drone.io)

erikgrinaker 10y ago
At least with Google's GCR, this is no longer the case. They have a Docker credentials helper [1] which transparently handles authentication for regular interactive use, and service accounts with permanent keys [2] for use with CI servers etc. I find both of these to be fairly straightforward to use. [1] https://github.com/GoogleCloudPlatform/docker-credential-gcr https://github.com/GoogleCloudPlatform/docker-credential-gcr [2] https://cloud.google.com/container-registry/docs/advanced-authentication#using_a_json_key_file https://cloud.google.com/container-registry/docs/advanced-au...

girvo 10y ago

As an example of Docker in production: Expedia are moving lots of their legacy infrastructure into Docker containers. My third-party contracting team that works on projects for Expedia (we're brought in so the rules and bureaucracy don't apply to use, allowing us to rapidly iterate and experiment in ways the core teams can't) have been using Docker end-to-end (local development through to autoscaled production deploys) While there were teething issues, this article does a good job of pointing out the flaws in the original article, I think. It's been easier to get our team up to speed on Docker and it's gotchas than nearly any other configuration management, server management, et al. systems that we tried!

user5994461 10y ago
Short version: Nope :p Long version: I met the DevOps guy who [I believe] is responsible for pushing Docker at Expedia and we've had long conversations about it. They were lucky to have had a particular environment and a specific version that worked, and got it pinned down and frozen very early. I suppose you are on the dev side and not aware of all that. (Hell, maybe, you're not even in the same subsidiary of Expedia). I'm glad it all worked out for you as a dev, my devs are also happy with Docker. (We're probably used as an example of Docker success story at times). In the end, there is no free lunch. There is dirty work done and more to be done. Some of which is invisible.
- girvo 10y ago
  Sorry if I didn't explain it correctly! We're an external team (completely seperate to Expedia) that is brought in to build certain products :) And yeah, definitely. I spent a couple weeks debugging the ECS issues we had with the Wotif guys, which was fun, but none of the issues were insurmountable! We were one of the first adopters for the new ECS deployment, and while some parts of it weren't fun (Splunk still drives me mental) for the most part it went smoothly: that's down to how good the ops team is, I think. Our specific case was somewhat special, in that because we're outside of the rest of the infrastructure, and had extensive experience with Docker in production for other clients, our apps were basically ready to rock from the get-go. I think we were the first PHP deployment within the new ECS deployments! Should send me an email, it's in my profile, would love to chat sometime!

yawz 10y ago

"The internet has been a wash with a well written article about ..." Typo: a wash => awash I know! The content is more important than the quality of the writing, but it's a little surprising to see such a mistake jumping at the reader at the start of an article. We should go back to the first days of the Internet where "updates" were possible. :) I would have loved to suggest an update quickly.

DrNemski 10y ago
My googling failed on this account on the correct grammatical term.

corv 10y ago

Docker seems very limited when it's unsuitable to run databases. I've never seen this limitation with other container solutions. What is it about Docker that makes it problematic?

lobster_johnson 10y ago
Nothing. It's bad advice. Lots of companies run databases in containers.
SoreGums 10y ago
Most likely lack of planning and applying a it should "just work" process to the scenario at hand... The thing I've learnt with Docker is that all the other Prod issues still exist. Docker at its core only solves the executable part or distribution of the process to run. Still need to figure out, network, storage, monitoring, backups, discovery, etc... What starts out as a single host can quickly quadruple once all the other considerations are taken into account and wanting a scalable, reliable and available system.

ledil 10y ago

if I am using mount Volumens to export my data, can I bypass the aufs/overlay implementation/logic ? do I need to pay attention only if I don't mount the volumes? thx

justincormack 10y ago
Volume mounts do not use the aufs/pverlay drivers, no. These are used for build, and for constructing the rott filesystem for running containers so files are shared.