21–30 of 78 posts
This is a copy and improvement of the article I wrote last month, even down to the breakdown of "What's that command doing?" with `docker run -t -i ubuntu /bin/bash`. Glad it was useful enough to spur an improved article, at least. http://tonyhb.com/unsuck-your-vagrant-developing-in-one-vm-w...
This is a copy and improvement of the article I wrote last month, even down to the breakdown of "What's that command doing?" with `docker run -t -i ubuntu /bin/bash`. Glad it was useful enough to spur an improved article, at least. http://tonyhb.com/unsuck-your-vagrant-developing-in-one-vm-w...
This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container th…
I just came here to basically say the same; which I guess is the question shared by 80% of Docker's target market. I have a box sitting somewhere which, like virtually any dedicated machine, is wildly overprovisioned for it's current usage patterns. I would like to virtualize my services so that I can one day, when my needs outgrow my box, scale out without having to rewrite any code. My box has limited IPs available…
Could you not run multiple docker containers/services behind a single nginx or apache container on a production server? Then the nginx container basically gets one of your public IP addresses, and you use linking to that container to provide it with knowledge of the other running processes' IP addresses (each within their own container, of course). In that way, you have one public facing container which has knowledge of the other containers and can use the information provided through -link to configure the nginx server to route requests appropriately. This requires a bit of bash script / sed command line hackery to update your nginx configuration to accommodate the changing IP addresses of the other containers on restart (unless you can set them by hand now using Docker, we still don't), but once you get it setup you never have to think about it again.
Like I said, maybe I'm just showing my ignorance, but something like the above scenario is how we get around hosting multiple services with limited public IP addresses available.
Earlier quoted context omitted.
I just came here to basically say the same; which I guess is the question shared by 80% of Docker's target market. I have a box sitting somewhere which, like virtually any dedicated machine, is wildly overprovisioned for it's current usage patterns. I would like to virtualize my services so that I can one day, when my needs outgrow my box, scale out without having to rewrite any code. My box has limited IPs available…
I'm probably just going to show my ignorance, here...but why doesn't container linking solve this problem? Could you not run multiple docker containers/services behind a single nginx or apache container on a production server? Then the nginx container basically gets one of your public IP addresses, and you use linking to that container to provide it with knowledge of the other running processes' IP addresses (each wi…
CoreOS' "fleet" ( https://coreos.com/docs/launching-containers/launching/launc... ) gives a cluster-wide solution.
But even without using fleet, the overall mechanism is fairly easy to adapt: Either use systemd dependencies like in their example, or have a script that queries docker on each host to spot changes in running containers, and update an etcd instance (or whichever your preferred config server is).
This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container th…
I just came here to basically say the same; which I guess is the question shared by 80% of Docker's target market. I have a box sitting somewhere which, like virtually any dedicated machine, is wildly overprovisioned for it's current usage patterns. I would like to virtualize my services so that I can one day, when my needs outgrow my box, scale out without having to rewrite any code. My box has limited IPs available…
For non-Paas use cases (for example, a development server with a bunch of projects) I find schroot (1) simpler and more productive. For example, you can use the normal `service stop / service start` instead of writing manually init scripts, and you don't get stuck with sharing directories, which I found extremely tricky with Docker (for example, I couldn't start correctly mysql with supervisor sharing the mysql db di…
Building a fresh container then takes a couple of seconds. And the projects run within those containers only. Ever time I restart the apps in my development environment, I rebuild the container, because it is so cheap. Which means I know at any time that the container can be rebuilt to a state the app will run in. I know when I want to deploy that the Dockerfile accurately reflects the dependencies, because otherwise my app wouldn't be running in the dev environment, as any and all changes to anything outside of the application repository are only applied through changes to the Dockerfile.
Earlier quoted context omitted.
I just came here to basically say the same; which I guess is the question shared by 80% of Docker's target market. I have a box sitting somewhere which, like virtually any dedicated machine, is wildly overprovisioned for it's current usage patterns. I would like to virtualize my services so that I can one day, when my needs outgrow my box, scale out without having to rewrite any code. My box has limited IPs available…
Why not use ipv6 for the network between services?
This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container. Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container th…
Varnish at least can route using DNS [0] - You do need a nameserver or two to handle the internal domain of course, but they're reasonably easy to set up using powerdns for example.
[0] https://www.varnish-cache.org/docs/3.0/reference/vcl.html#th...
Would it be better to use FreeBSD and their Jails mechanism for all of this?
I misread that as "Microsoft's..." and got excited since I run a build farm that's 70% windows and wish I could use docker but it's not worth having two systems (Container and VMs).
Also isn't that complete wrong? Macintosh is not an OS or company. It was one of Apple's product lines, long ago.
