Live data from Hacker News

Some questions about Docker and rkt

jvns.ca

51–60 of 92 posts

Re: Some questions about Docker and rkt

#51
post #29

So 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.

Re: Some questions about Docker and rkt

#52

It seems that isolation is frequently the cause. E.g.: * Better developer environment. Actually, I'm not sure anymore. It totally makes sense for testing (all the CI/CD stuff), and - thanks to the packaging aspect - it's easy to set up external dependencies (like databases), but I just wasn't able to grasp how the actual development is better with Docker. Developers tinker with stuff, containers and images are all ab…

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.

Re: Some questions about Docker and rkt

#53
post #30

"Installing stuff on computers so you can run your program on them really sucks. It's easy to get wrong! It's scary when you make changes! Even if you use Puppet or Chef or something to install the stuff on the computers, it sucks." I think a lot of people feel this way. I think that fear is born of ignorance, and we should fix that. Let's say you are working on an application in NewPopularLanguage 2.3.1, using CoolF…

> But if you really need the new versions, you should use a repeatable build system that generates OS packages exactly the way you want them. You should put them into a local repo so that when you install or upgrade a new machine, you get the version you specify, not whatever has just hit trunk upstream. And you may want your versions to be placed in a non-(system)-standard location, so that your application has to s…

> That's his point.

That's her point. :)

Re: Some questions about Docker and rkt

#54
post #30

"Installing stuff on computers so you can run your program on them really sucks. It's easy to get wrong! It's scary when you make changes! Even if you use Puppet or Chef or something to install the stuff on the computers, it sucks." I think a lot of people feel this way. I think that fear is born of ignorance, and we should fix that. Let's say you are working on an application in NewPopularLanguage 2.3.1, using CoolF…

> It feels like a lot of overhead,

Right, because it IS a lot of overhead.

Re: Some questions about Docker and rkt

#55

While this thread has visibility, I am curious about your typical security model with docker. From my experience, whoever is running docker seems to be able to run root commands on the host [1]. So any best practices for running docker ? [1] http://reventlov.com/advisories/using-the-docker-command-to-...

Take a look at this pdf - https://www.nccgroup.trust/globalassets/our-research/us/whit...

There is also a docker-bench-security tool set worth checking out.

Re: Some questions about Docker and rkt

#56
post #37

I will try and answer networking question. At scale a single host can be running may be 20 containers and port collision becomes a real problem. So imagine if a container opened a port directly on host -we have to be careful that they don't step on each other toes. Even if all containers used some sort of contract about which port they are going to use - there are all sort of corner cases waiting to happen such as ep…

> Using smartstack the applications running inside container can run on any port but the port on which they are externally available is decided by orchestration service

AFAIK this is not the case: with smartstack you configure your application to listen on some port, and you configure nerve to register : under in zk/etcd/whatever. You have to do both of these things; smartstack itself doesn't configure your app for you or make sure that nerve and your app agree on the port.

I'm not aware of any such efforts to make smartstack aware of orchestration yet, but I haven't gone looking recently.

It'd be entirely possible to make the app and nerve aware of network orchestration: have the orchestration layer 1. pick a port, 2. tell the app about it, and 3. configure nerve accordingly. In smartstack, each instance of can have different port numbers, so they could all be arbitrary high-numbered ports.

edit: You could also just have your orchestration layer inform the service discovery layer itself (in the case of smartstack, by writing the app's ip:port to zk/etcd/whatever). nerve contains some local healthchecking (sanity checking that the app is up before registering it) and maybe a few other things, however, so I think if you're already using / considering smartstack it would make sense to keep using nerve instead of having orchestration do it.

Re: Some questions about Docker and rkt

#57

While this thread has visibility, I am curious about your typical security model with docker. From my experience, whoever is running docker seems to be able to run root commands on the host [1]. So any best practices for running docker ? [1] http://reventlov.com/advisories/using-the-docker-command-to-...

You are right that docker currently runs as root. There is some phenomenal work that Aleksa Sarai is doing on getting runc to work as an unprivileged user [1] that Docker should be able to take advantage of at some point. There are still a lot of places which need love without root in the Docker world, but it's a huge step forward.

[1] https://github.com/cyphar/runc/tree/rootless-containers

Re: Some questions about Docker and rkt

#58
Julia writes: "I think "violates a lot of normal Unix assumptions about what normally happens to normal processes" is basically the whole story about containers."

This is a key point. Lots and lots of standard Unix invariants are violated in the name of abstraction and simplification, and the list of those violations is not popularized; and most of the current systems have different lists.

For example, in Kubernetes (my current love affair), the current idea of PetSets (basically, containers that you want to be carefully pampered, like paxos members, database masters, etc. -- stuff that needs care) /still/ has the notion that a netsplit can cause the orchestrator to create (1 .. #-of-nodes) exact doppelgangers of your container, all of which believe they are the one true master. You can imagine what this means for database masters and paxos members, and that is going to be, as the kids say, surprising af to the first enterprise oracle db admin who encounters this situation.

If you believe in containers, then one thing that you really do have to get to, is that most of your existing apps should not be in them yet, and that if your app is not (a) stateless (b) strongly 12-factor (c) designed for your orchestrator and (d) written not to do things like fork() or keep strong references to IP addresses, then you should probably wait 3-4 years and use VMs in the meantime.

Re: Some questions about Docker and rkt

#59
post #47

Kubernetes is the answer to all of your questions. You shouldn't directly use "docker run" in production. At least not yet. Think of the docker binary and daemon as development tools not a production platform. Develop your apps one process per container, microservice style. If you can't do that you should probably use vms. When it comes time to deploy, kubernetes handles scheduling for you automatically across your f…

Kubernetes supports rkt as we speak: http://kubernetes.io/docs/getting-started-guides/rkt/

Re: Some questions about Docker and rkt

#60
post #24

Another issue with Docker: it does not interact well with process supervision (say systemd). The "docker run" process that you run with systemd is only a proxy for the real container process, which is started by the Docker daemon - so in reality, you have two init systems, Docker _and_ systemd. This means that many supervision features won't work (signals, seccomp, cgroups...). rkt fixes this by not having a global d…

cgroups, seccomp etc are set by docker so they do work. I think it is weird to view these as exclusively owned by the init process. Docker works on systems without systemd (indeed, it runs on Windows), so relying on features that systemd has (currently, many are only recent additions) is not really an option.

Give it time. Once systemd runs out of Unix utilities to consume, it will inevitably turn on WinInit.exe and the Service Control Manager.
Post reply on HN