Would it be better to use FreeBSD and their Jails mechanism for all of this?
Getting Started with Docker
11–20 of 78 posts
Re: Getting Started with Docker
#12This 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...
Re: Getting Started with Docker
#13This 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…
> 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. It might be a stupid question but I wonder what's considered a leaky abstraction in this case. By the way, I'm not sure I fully understand your concerns over reverse proxy routing, but I recall that Ambassador pattern linking[0] is a suggested way of tying Docker conta…
>It might be a stupid question but I wonder what's considered a leaky abstraction in this case.
I consider poking a hole a leaky abstraction because you are exposing the internals of your stack. The consumer should not know or care that you are using docker containers to serve the application. From a security perspective directly exposing a container may lead to potential exploits of docker itself.
Re: Getting Started with Docker
#14For 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…
I've had the same issue with MySQL. It's an issue of timing - You install MySQL, and the MySQL data directory has its data/default databases. Then you share the directory with Docker, and the data lib directory is wiped out (the files don't exist on the host machine, after all). Getting it right in an automated way is a Hard Problem™. As of now, I'm keeping data persisted within the Container, which I don't necessari…
Since I already use schroot and I'm happy with it since it is a mature project I'll continue to use it, keeping a look to next Docker developments.
Re: Getting Started with Docker
#15Would it be better to use FreeBSD and their Jails mechanism for all of this?
Or schroot on Linux, as I wrote in another comment
Re: Getting Started with Docker
#16For 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…
I've had the same issue with MySQL. It's an issue of timing - You install MySQL, and the MySQL data directory has its data/default databases. Then you share the directory with Docker, and the data lib directory is wiped out (the files don't exist on the host machine, after all). Getting it right in an automated way is a Hard Problem™. As of now, I'm keeping data persisted within the Container, which I don't necessari…
As a note, for Debian/Ubuntu, you can recreate the default DBs on a shell with mysql_install_db followed by mysql_secure_installation .
Re: Getting Started with Docker
#17For 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…
I've had the same issue with MySQL. It's an issue of timing - You install MySQL, and the MySQL data directory has its data/default databases. Then you share the directory with Docker, and the data lib directory is wiped out (the files don't exist on the host machine, after all). Getting it right in an automated way is a Hard Problem™. As of now, I'm keeping data persisted within the Container, which I don't necessari…
Here's a dockerfile setup I wrote for Postgres which uses a 'data container' for the entire Postgres database: https://github.com/codelittinc/dockerfiles/tree/master/postg...
The gist of it is that you explicitly tell your DB container that there will be a shared directory on the container at runtime. This allows you to chown the directory before the data container is added.
Then, when you're running, use --volumes-from `$data-container-name` and it'll work. Want an article on it?
Re: Getting Started with Docker
#18Earlier quoted context omitted.
I've had the same issue with MySQL. It's an issue of timing - You install MySQL, and the MySQL data directory has its data/default databases. Then you share the directory with Docker, and the data lib directory is wiped out (the files don't exist on the host machine, after all). Getting it right in an automated way is a Hard Problem™. As of now, I'm keeping data persisted within the Container, which I don't necessari…
Here's a dockerfile setup I wrote for Postgres which uses a 'data container' for the entire Postgres database: https://github.com/codelittinc/dockerfiles/tree/master/postg... The gist of it is that you explicitly tell your DB container that there will be a shared directory on the container at runtime. This allows you to chown the directory before the data container is added. Then, when you're running, use --volumes-f…
Awesome, thanks. I can figure it out from that example most likely, but an article would never hurt :D
Re: Getting Started with Docker
#19This 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…
Update etcd with connection details on container start/stop. Then use a script to watch the appropriate directory in etcd for changes and regenerate the config.
Look at "fleet" from CoreOS, and especially their "sidekick" example that uses systemd dependencies to trigger etcd updates: https://coreos.com/docs/launching-containers/launching/launc... though you can certainly do this without fleet too.
Then on the haproxy/varnish box (or put them in a container), put something that does "etcdctl exec-watch /services/website -- updateconfig.sh", where updateconfig.sh would be a script to watch for changes and regenerate the config / reload.
I don't see how your config will get "bloated" any more than it would otherwise - presumably your number of domains won't increase.
Re: Getting Started with Docker
#20This 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 think you can define the IP address assigned to a container via something like `-p 127.18.0.10:80:80`, if that helps with your HAProxy config (but that assumes your host machine isn't changing as well). Definitely an interesting issue. Have you seen etcd from CoreOS? Useful for service discovery.
That doesn't assign an ip address to the container, it just determines which of the hosts addresses are forwarded to the container. But you can certainly use that to keep a fixed IP, if you use a suitable script to update iptables. You can use that if the host machine is changing as well, as long as an IP address is only ever used by containers that will be on the same server. Just add the IP on the new host, remove it from the old, and use arpsend -U -i [ip] [interface] to speed up the ip takeover. I use it fairly regularly to live-migrate services.