161–170 of 290 posts
Every service I deploy gets it's own VM (which is automatically provisioned/locked-down by a bash script), and they automatically update when a new revision is pushed to our production git branch.
It seems that docker is more useful when you have physical hardware? and/or lots of under-utilized infrastructure?
Earlier quoted context omitted.
There was also a time when most people thought they didn't need version control. Back in the 80s and 90s it was a justifiable viewpoint because existing version control systems sucked . The problem with Docker is not that it doesn't solve (or attempt to solve) widespread problems. At its best, Docker gives you dev/production parity, and dependency isolation which is useful even for solo developers working part-time.…
> At its best, Docker gives you dev/production parity I get that when I use the same OS and built-in package manager? I would virtualize the environment using something like VirtualBox for my dev and EC2/DigitalOcean/etc on prod. > and dependency isolation If you're going to scale something, you're going to split everything out on different virtualized servers anyway, so you'll get your isolation that way. Basically,…
I don't use Docker, but those are problems I can think of off the top of my head.
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.
> At its best, Docker gives you dev/production parity I get that when I use the same OS and built-in package manager? I would virtualize the environment using something like VirtualBox for my dev and EC2/DigitalOcean/etc on prod. > and dependency isolation If you're going to scale something, you're going to split everything out on different virtualized servers anyway, so you'll get your isolation that way. Basically,…
Yeah, but then there's still the issue of secrets, you need to have testing PayPal credentials, testing mailing service credentials, etc. There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? I don't use Docker, but those are problems I can think of off the top of my head.
(And, later, if you want to play with Docker, Packer lets you do that too. But you should use the Racker DSL in any case, because life is too short to deal with Packer's weird JSON by hand.)
Earlier quoted context omitted.
Yes, doing the same thing here as well. Still using docker to streamline deployments though, but one docker container/role per instance, no "orchestration" for containers (baked AMIs, ASGs).
I did that at one place, but I wasn't super satisfied with the process--having to download container images on spin-up was annoyingly slow and I didn't feel like we were getting better dev/prod consistency versus Vagrant and Packer.
Packer is used to build the AMIs with the containers built-in, and Docker is used both in Prod (single container to each AMI) and Dev (Docker Compose to bring up entire dev env locally). Both used a shared docker registry.
The security question (it's possible to break out of containers) isn't solved, and the workaround (use VMs) eliminates many of the advantages of containers and adds a massive burden.
For multitenant situations, sure. Still more isolation than running a bunch of services on the same box.
see : bocker
Earlier quoted context omitted.
> At its best, Docker gives you dev/production parity I get that when I use the same OS and built-in package manager? I would virtualize the environment using something like VirtualBox for my dev and EC2/DigitalOcean/etc on prod. > and dependency isolation If you're going to scale something, you're going to split everything out on different virtualized servers anyway, so you'll get your isolation that way. Basically,…
Yeah, but then there's still the issue of secrets, you need to have testing PayPal credentials, testing mailing service credentials, etc. There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? I don't use Docker, but those are problems I can think of off the top of my head.
How would Docker help with this? Genuinely curious.
I store them in bash scripts outside the repo that populate the relevant data into environment variables and execute the code. The code then references the environment variables.
> How about installing the required dependencies?
There are two kinds. On the OS level and on the platform level.
On the OS level, you can have a simple bash script. If you need something more complex, there are things like Chef/Puppet/etc.
On the platform level, you have NPM/Composer/PIP/etc which you can trigger with a simple cron script or with a git hook.
> There's the issue of deploying changes fast without leaving files in an inconsistent state
So the argument here is that you're replacing one file in one go vs possibly thousands? That in the latter scenario the user might hit code while it's in the process of being updated?
Ok. With docker, you would shut it down to update. You would have to.
Same goes for the traditional deployment? Shut it down, update, start it back up?
You can, of course, automate all of this with web hooks on Github/Bitbucket, for both docker and the traditional deployment.
The traditional deployment should also be faster, since it's an incremental compressed update being done through git.
Earlier quoted context omitted.
> At its best, Docker gives you dev/production parity I get that when I use the same OS and built-in package manager? I would virtualize the environment using something like VirtualBox for my dev and EC2/DigitalOcean/etc on prod. > and dependency isolation If you're going to scale something, you're going to split everything out on different virtualized servers anyway, so you'll get your isolation that way. Basically,…
Yeah, but then there's still the issue of secrets, you need to have testing PayPal credentials, testing mailing service credentials, etc. There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? I don't use Docker, but those are problems I can think of off the top of my head.
> There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies?
rpm / dpkg also install dependencies, are quite fast and well tested. They have the advantage of working in a standard environment which most sysadmins know but the disadvantage that you need to configure your apps to follow something like LSB (e.g. install to standard extension locations rather than overwriting system files, etc.).
The one issue everything has is handling replacement of a running service and that's not something which Docker itself solves – either way you need some higher level orchestration system, request routers, etc. Some of those systems assume Docker but that's not really the value for this issue.
Earlier quoted context omitted.
It's the future! http://blog.circleci.com/its-the-future/
Crap like that actually happens. I have a mathematician friend who does a bit of programming ask me about Docker, as someone had told her to use it. She works as a researcher in academia, so probably only needs to run her script a few times to get results. Why the hell would you recommend Docker?
Docker is really good for dev environments. I've had a relatively painless time dockerizing snapshots of old internal web apps so I can hack on them without installing things into my main desktop environment. It lets me have lots of server things side by side.
Earlier quoted context omitted.
I did that at one place, but I wasn't super satisfied with the process--having to download container images on spin-up was annoyingly slow and I didn't feel like we were getting better dev/prod consistency versus Vagrant and Packer.
We bake the container into the AMI, so no fetch is necessary at spin up (there is no cost to generate AMIs, only storage fees, so cost is not an issue). Packer is used to build the AMIs with the containers built-in, and Docker is used both in Prod (single container to each AMI) and Dev (Docker Compose to bring up entire dev env locally). Both used a shared docker registry.