IMO, in the long term the most sane approach for production is kubernetes with rkt, especially given things happening in docker 1.12.
You even can use docker locally and rkt in prod, as rkt can run docker images.
Some questions about Docker and rkt
81–90 of 92 posts
Re: Some questions about Docker and rkt
#82Earlier quoted context omitted.
How about something that isn't spawned by an orchestrator - for instance the marathon load-balancer - they provide only a docker image which clearly is meant to be run using `docker run`
I would still run it using an orchestrator, if only to have it restart the container automatically on failure or after your node reboots.
I mentioned this in a sibling comment - I'm currently running the container using systemd which gives me restart ability and all that.
Do you think this is insufficient?
Re: Some questions about Docker and rkt
#83So how do you handle what she addressed under secrets? How do you share passwords between containers? For quick and dirty stuff, I use environment variables that are set in my docker-compose file, but I have no experience running docker in production.
Best solution is a dedicated secret management tool. K8S has secret capabilities built in, or something like Hashicorp Vault. Alternatively, I've used something as simple as DynamoDB to distribute config information and secrets to services.
How do you securely consume those secrets though - from everything I have seen with vault or consul you end up with the secret as a environmental variable that is then visible in ps listing.
Re: Some questions about Docker and rkt
#84So how do you handle what she addressed under secrets? How do you share passwords between containers? For quick and dirty stuff, I use environment variables that are set in my docker-compose file, but I have no experience running docker in production.
environment variables are problematic, as they can be read by other processes potentially. Vault or another secrets management tool is a better option. A secrets management solution integrated into Docker is planned, as it is difficult to get right without tooling support.
Does Vault actually address the problem of credentials being visible in the process list? I thought vault only solved the secure distribution part.
Re: Some questions about Docker and rkt
#85Earlier quoted context omitted.
Oracle has had multi-homed master-master RDBMS setups for > 10 years. I'm pretty sure a half-competent Oracle administrator wouldn't be really 'surprised af' at functionality that's been in Oracle for at least a decade. For things that need 'care', this has been a solved problem for decades. Banks[0] homed in the WTC on Sept 11 kept on running because OpenVMS has had NUMA clusters and multi-node replication since the…
I'm saying that an arbitrary number of exact replicas of a master can magically appear on the network believing they are the one true master, identifying themselves as such, and expecting to act that way. Additionally, an arbitrary number of database masters expecting to participate in the cluster may show up or leave at any time. That is somewhat nontrivial for even modern databases to deal with.
If you're running multiple copies of anything that cares about the concept of a master it better have its own consensus algorithm. Luckily such things exist and are open source.
Re: Some questions about Docker and rkt
#86Earlier quoted context omitted.
Best solution is a dedicated secret management tool. K8S has secret capabilities built in, or something like Hashicorp Vault. Alternatively, I've used something as simple as DynamoDB to distribute config information and secrets to services.
How do you securely consume those secrets though - from everything I have seen with vault or consul you end up with the secret as a environmental variable that is then visible in ps listing.
Kubernetes for instance bind mounts secrets by default on read only in memory filesystems (and on Red Hat systems, with unique SELInux labels) that disappear on reboot. You can of course use secrets in env vars if you want, since sometimes it is easier. The hard part is a lot of handy public docker images use env by default, so you end up being tempted into env for convenience.
Re: Some questions about Docker and rkt
#87"rkt" is such a strange name. In my head I don't pronounce it as "rocket" but as "rekt", with all the connotations that has.
It used to be rocket very early on but was changed to rkt for legal reasons fairly early as well.
Re: Some questions about Docker and rkt
#88Earlier quoted context omitted.
environment variables are problematic, as they can be read by other processes potentially. Vault or another secrets management tool is a better option. A secrets management solution integrated into Docker is planned, as it is difficult to get right without tooling support.
Is there a way to prevent other processes from reading environment variables?
on linux kernel >= 3.2 you can mount /proc with the option hidepid=2. However this isn't a very elegant solution in my opinion.
Re: Some questions about Docker and rkt
#89Earlier quoted context omitted.
How do you securely consume those secrets though - from everything I have seen with vault or consul you end up with the secret as a environmental variable that is then visible in ps listing.
Kubernetes for instance bind mounts secrets by default on read only in memory filesystems (and on Red Hat systems, with unique SELInux labels) that disappear on reboot. You can of course use secrets in env vars if you want, since sometimes it is easier. The hard part is a lot of handy public docker images use env by default, so you end up being tempted into env for convenience.
And does that Docker instance need a token to read the password out of key/value store somewhere? How then do you securely distribute the token? It seems like that would just be pushing the problem elsewhere.
Also I am assuming that something is preventing that tmpfs filesystem from swapping to disk?
Re: Some questions about Docker and rkt
#90Earlier quoted context omitted.
Developers tinker with code, but most of the time you don't tinker with the output of that code, like hot patch your binaries or whatever. Same with systems, you build a container from a Dockerfile and maybe Makefile, you don't then go and change a few things you change the source code. We are just pushing the immutability boundaries further and getting more reproducible environments as we do it.
It depends on the project, I guess. Sometimes, it's not that easy. For scripting languages that don't have a compile-time the code is what gets executed. So with Docker there's either necessity to rebuild the container (extra delays, and quite noticeable ones) or necessity to maintain a separate Dockerfile.dev and mount-binding the code into the container a-la Vagrant. Even for compiled stuff, it can be a nuisance wi…
You can debug from the host or from another container using `--pid=container:id` which puts you in the process namespace of a running container.
Build time is important, if you can use build layer cacheing it helps a lot, but how to structure it depends on your project. I don't myself use Dockerfile.dev, but I do sometimes mount the code into the container to build and run it directly. I think it would definitely help for more blogs and examples of how to do these things, as there is a lot of room for improvement.