151–160 of 290 posts
Earlier quoted context omitted.
[deleted]
Can we please stop sounding the trumpet of "progress"? Containers have been around for nearly a couple of decades (possibly more if you extend the definition), since IBM i had LPARs. There's nothing fast-moving or technologically novel about, especially, Linux containers.
I wrote about my experience with deploying Docker & ECS here: https://news.ycombinator.com/item?id=9759639 I'm frustrated though because I keep pinging them about adding branch information to their (dockerhub) webhooks so I can actually deploy environments via branches.. It's crazy vital in my opinion and seems like it should be an easy fix, but 2 months later and still doesn't seem to be scheduled in. Nevertheless,…
That said, what we do is we have our CI system build our docker images, push them to dockerhub (private registry) if the tests all go great, and then we deploy using https://github.com/remind101/deploy. We also tag all our images with the git SHA that they were created from, so we have immutable identifiers for each image, which has been useful.
We just recently put direct github deployment support in Empire, so that's been really nice (before we had to use another service that pulled deployments and put them into Empire).
Anyway, not quite the workflow you're talking about, but it's really worked well for us, so maybe it'd help you as well :)
Earlier quoted context omitted.
I'm not sure how much you know about docker, so to anyone in whom this list scares: > Where to put logs Well, I just throw them aside and use `docker logs [container]` > How to manage state One container should perform one service. I haven't run into a problem here. > How to schedule containers ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running. > How to…
Well I used Docker on top of Mesos so I have quite a bit of experience and the above were all problems I faced. They're not impossible problems obviously but they take time and thought to solve. From your responses, I am not sure you fully appreciate the problem to be honest. You have to remember that you containers and coming and going all the time, which is one of the biggest challenges. It basically means you have…
Earlier quoted context omitted.
Are you suggesting that a person with a total of 3 nodes use a system like Kubernetes which requires at a minimum (correct me if I'm wrong) 5 nodes just to function? If you really, really want to use Docker with a typical Nginx-App-DB setup just whip up the necessary shell commands to start/stop/log containers and throw that in Ansible or the like. edit: I guess you can cram all of the various Kubernetes master/etcd…
It's the future! http://blog.circleci.com/its-the-future/
Earlier quoted context omitted.
Even if you're building brand new infrastructure from scratch right now many issues (discussed elsewhere in these comments and the article) are still unsolved.
Yup. At my last gig we built out a Mesos cluster and were deploying Docker containers, but we couldn't answer "how do we practically secure this to the same level as independent virtual machines?" and, finding no good answer, we went back to auto-scaling groups and baked AMIs.
Earlier quoted context omitted.
There's no need to say that at all. Just address the points and let everyone form their own opinions.
Because opinions are not the same as facts/best practices (nor is everyone's opinion equal). If you want to argue "this is the right way", be prepared to bring data and defend your statements. People here might be making critical decisions based on knowledge shared here, and they deserve the most accurate information possible.
While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…
> is that if it ain't broke, don't fix it. I hate being passive-aggressive so I'll be directly aggresive here: this mentality is a way to say, "I don't want to revisit the operational aspects of my system because I don't like to do that work. Find someone else." Like any aspect of your system, your ops and deploy components can rot. Pretending otherwise is outright ignoring a consistent lesson offered by those who ca…
While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…
Docker solves a problem that most people don't have. It's not a PaaS, rather, it's (some of) the building blocks to create your own PaaS. Most folks don't need that. Most folks want to put files on a server and start a process. For those folks, Docker in the raw ends up being a whole lot of confusing & unnecessary scaffolding.
Earlier quoted context omitted.
> Breaking out of container will always be easier than breaking out of deeper levels of virtualization (Xen/KVM). I agree it's not easy to get right, but it doesn't seem necessary that containers will always be leaky. Solaris/Illumos Zones are an OS-level virtualization approach that's pretty airtight, for example.
I agree. But that's my biggest problem with Docker. Who runs SmartOS and uses Zones? Why? When you have a local server, that supports KVM and Zones, you choose KVM as the cleaner abstraction. While surrounded by neat tech, Zones are actually a bit of a pain and not all that portable between systems IME. OTOH I can `zfs send/recv` over SSH, drop a short bit of JSON in, and have my KVM instance reliably moved to anothe…
I currently use it for MySQL DB restoration and remote bug-checking by having a handful of xtrabackup instances that I can quickly attach a docker to, hand an IP to a developer, and he can then debug the problem with production data _at that exact point in time._
When they're done, I simply throw that docker away.
It's a tool that (in my mind) doesn't solve any existing problems better than a lot of tools out there. It instead should be thought of like a better hammer for the same nail. Think of it like... would you rather have a giant set of wrenches, or a single ratchet with a set of sockets? They both accomplish the same thing, but both are better for certain jobs.
My application compiles to a jar that runs on a server and expects an accompanying config file. I've tried giving Docker a whirl a few times and I never fully understood what need I had that it was solving.
Throw in a database, a cache server, couple of versioned libraries your jar file needs, and more developers, and suddenly a reproducible image with all this packaged will make a lot of sense.