101–110 of 131 posts
Earlier quoted context omitted.
Docker already runs fine on 32 bit systems if you compile it yourself and remove the check for 64-bit-ness.
Didn't know that - I'll try it! What happens if you put a 64bit executable in a container they try to run the container on a 32bit machine? Or a Rasberry/Arm device?
This is crazy talk of course, but I wonder if there'd be some way to use rsync or git to support distributed development of images the way git does with code? I mean, it'd be neat to be able to do a "pull" of diffs from one image into another related image. Merge branches and so on. I don't know, possibly this would be just too unreliable, but I would have previously thought that what docker is doing right now would…
http://blog.bittorrent.com/2013/10/22/sync-hacks-deploy-bitt...
http://blog.docker.io/2013/07/docker-desktop-your-desktop-ov...
There has been discussion of taking the git analogy further. We actually experimented with a lot of that early on (https://github.com/dotcloud/cloudlets) and I can tell you it's definitely possible to take the scm analogy too far :)
I do think we can still borrow a few interesting things from git. Including, potentially, their packfile format and cryptographic signatures of each diff. We'll see!
Here's a relevant discussion thread: https://groups.google.com/forum/#!msg/docker-user/CWc5HB6kAN...
Could someone explain the logistics of Docker in a distributed app development scenario? I feel like I am on the outskirts of understanding. My goal is having a team of developers use Docker to have their local development environments match the production environment. The production environment should use the same Docker magic to define its environment. Is the idea that developers define their Docker environment in…
Docker lets you build an environment (read: put together a bunch of files) for you to run an app in. It also has other features, like reducing space if lots of your apps [on the same host] use the same docker images, and networking stuff.
> My goal is having a team of developers use Docker to have their local development environments match the production environment
You run a container. You use images to distribute files. A Dockerfile is a loose set of instructions to build the images.
The basic idea is that, any single program that you want to be able to run anywhere, you make into a container. You can run it here, you can run it there, you can run it anywhere. The whole "running it anywhere" concept comes from the idea that all of your containers are created based on the same images, so no matter what kind of crazy mix of machines you have, your containers will just work - because you're literally shipping them a micro linux distribution in which to run your application. And since all the applications are running in isolated little identical containers, you can run as many of them as you want, independent of each other, in whatever configuration you want.
You'll have a PSQL container and an App container, and you'll manage them separately, even if they share images - the changes they make get saved off to a temp folder so they don't impact each other. Your environment stays the same only as long as the containers and images you're using are the same.
There will always be differences between development and production. You have to focus on managing those differences so you have confidence that what you're shipping to production actually works. The only thing Docker really does there is make sure the files are basically the same.
Earlier quoted context omitted.
Didn't know that - I'll try it! What happens if you put a 64bit executable in a container they try to run the container on a 32bit machine? Or a Rasberry/Arm device?
When you try to run an executable on an architecture it wasn't designed for, it does not run. But this has nothing to do with docker or Linux.
It's not clear to me how I can benefit from Docker given my setup above. Any comments?
For local development, I use Vagrant + Chef cookbooks to setup my environment. The same Chef cookbooks are used to provision the production servers. It's not clear to me how I can benefit from Docker given my setup above. Any comments?
Chef is based on re-running the same commands with various different options depending on the environment, and even without any thing in the cookbooks/attributes/environments changing, Chef still cannot guarantee that this run will produce the same results as a run that happened yesterday, simply because it isn't like an image.
It doesn't run on a typical OpenVZ VPS. Is there any alternative for separating apps on a single VPS?
For local development, I use Vagrant + Chef cookbooks to setup my environment. The same Chef cookbooks are used to provision the production servers. It's not clear to me how I can benefit from Docker given my setup above. Any comments?
Docker really replaces the need for Chef in a sense. You don't need Chef for configuration of your container, because ideally your container should be saved in an image which you use to deploy. This keeps things consistent between your dev environment, staging and production. Chef is based on re-running the same commands with various different options depending on the environment, and even without any thing in the co…
Earlier quoted context omitted.
Docker really replaces the need for Chef in a sense. You don't need Chef for configuration of your container, because ideally your container should be saved in an image which you use to deploy. This keeps things consistent between your dev environment, staging and production. Chef is based on re-running the same commands with various different options depending on the environment, and even without any thing in the co…
I'm new to these tools. Given your explanation, how does Docker replace a packaged Vagrant machine[0] with all the software already pre-installed (without using Chef)? [0] http://docs.vagrantup.com/v2/cli/package.html
Imagine spinning up your db instance vm, your web tier vm, your load balancer vm... etc.
Unless you have a ton of ram it isn't going to happen. With docker you can run containers that mimick a very very large infrastructure on your laptop.