Live data from Hacker News

Some questions about Docker and rkt

jvns.ca

21–30 of 92 posts

Re: Some questions about Docker and rkt

#21
post #8
post #2

While the info is kinda useful, the writing style reminds me of Stan, the salesman of Monkey Island.

Personally, I really like her writing style. She's very honest about the things she doesn't know, which I find a lot easier to relate to than blogposts by some random internet gurus. Behind the self-deprecation she has a lot of really interesting things to say and is really enthusiastic about learning new technologies. Her full archive is well worth reading.

Me too. Her writing is superb. I find her presenting a little more rambling and less informative/entertaining.

It's ballsy to write a blog asking questions about docker.

Re: Some questions about Docker and rkt

#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 daemon.

The linked article puts it well:

https://medium.com/@adriaandejonge/moving-from-docker-to-rkt...

Re: Some questions about Docker and rkt

#25

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

Best practice? Docker daemon access to equivalent to root access, so only allow it for root.

Re: Some questions about Docker and rkt

#26

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

In production, you usually don't want to have users running around and spawning containers anyway. You will likely have an orchestrator like Kubernetes or Mesos or Swarm, who will be running as root and spawning containers for you. Of course, that just replaces the question of "how is access to the docker daemon secured?" with "how is access to the orchestrator API secured?".

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`

Re: Some questions about Docker and rkt

#27
post #2

While the info is kinda useful, the writing style reminds me of Stan, the salesman of Monkey Island.

I agree. The content is most definitely there and I learned a few things, but the signal-to-noise ratio is a bit high for my tastes. The "like"s and whatnot are distracting, I find. I would humbly suggest that Julia work on her writing style. She's in a good position to do so: there's stuff to be said and now it's just a question of tweaking the manner in which it's said. Edit: why the hate? I didn't think I was bein…

She wrote a blog post, put it online for ... who knows? It could be literally any reason. For her own later reference, to help crystallize her thoughts, or just for fun. Somebody else posts it to Hacker News. Dudes (always dudes!) tell her to change her writing style. Why? Why should she? Why do they care?

Re: Some questions about Docker and rkt

#28

Earlier quoted context omitted.

I agree. The content is most definitely there and I learned a few things, but the signal-to-noise ratio is a bit high for my tastes. The "like"s and whatnot are distracting, I find. I would humbly suggest that Julia work on her writing style. She's in a good position to do so: there's stuff to be said and now it's just a question of tweaking the manner in which it's said. Edit: why the hate? I didn't think I was bein…

She wrote a blog post, put it online for ... who knows? It could be literally any reason. For her own later reference, to help crystallize her thoughts, or just for fun. Somebody else posts it to Hacker News. Dudes (always dudes!) tell her to change her writing style. Why? Why should she? Why do they care?

>Why? Why should she? Why do they care?

In a word: constructive criticism

Again, I thought the piece was informative. I figured I'd voice my opinion in the form of suggestions, since this is a forum for such things.

Lesson learned. The only feedback one can give is positive.

>dudes, always dudes

What does sex/gender have to do with this? From your comment, it follows that you'd be less upset if women had commented. That feels wrong and regressive.

Re: Some questions about Docker and rkt

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

Re: Some questions about Docker and rkt

#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 CoolFramework version 3.3. Your Linux distro ships NPL 2.1.7 and CF2.8, which don't support a really nifty feature that you would like to have.

Important questions to ask: what is the distro's support record? Do they have a dedicated security team? Is there significant support for NPL and CF in the distro, or just a single package maintainer?

If the distro's security and NPL packaging team are good, you might want to use their versions even if it means giving up use of the really nifty feature until sometime in the unknowable future. Making an explicit, considered decision is worthwhile.

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 specify the path -- but be guaranteed that you can install several versions in parallel, and use the right one.

It feels like a lot of overhead, but it can save you lots of debugging and deployment time. Once you have the infrastructure tools in place, using them is not much of a burden, and pays for itself many times over.

Post reply on HN