Hacker News Reader

Comment by reacharavindh | Hacker News Reader

Serious question: Why do you need Docker for a Go project? Cant you build it, and copy the binaries over to the host you want to run it on?

View on HN

In my use case: container scheduling / orchestration. Tools like mesos/k8s/docker swarm. I don't "copy binaries over to a host" - it's rare that I would even have ssh access to a host.

Those tools aren't optimized for running arbitrary binaries - hence containers.

This is my favorite feature of Go in Lambda. You cross compile a Linux binary, throw it in S3, and Lambda runs it on demand.

It feels so good to skip over all the Docker tools, config and services to build a Go app.

I wrote up more details here:

https://github.com/nzoschke/gofaas/blob/master/docs/dev-pack...

There's definitely use cases for Docker with Go that mostly revolve around running untrusted code or wanting to be able to set tight restrictions on CPU usage, memory etc. Though you could also just do the latter via cgroups. Another use case might be if you have extra files that need to be deployed with the binary as well.

I wrote up some documentation about this for my use case just in case I ever have to go back and change it.

You can see it here: https://fn.lc/post/docker-scratch/

>There's definitely use cases for Docker with Go that mostly revolve around running untrusted code.

Please don't run untrusted code in Docker, it's not designed for security.

https://security.stackexchange.com/questions/107850/docker-a...

Docker containers can run in other places where they are secure, IIRC then Joyent has way to do this in their cloud

You havent refuted my point. People take a stance that docker can run untrusted code without actually looking at what they have to do for that to be true.

I haven't taken the stance that all docker containers can run untrusted code, but I've certainly done my best to harden my docker containers as much as possible. If you took a look at that write up I cover it.

I run with the flags: --net=none --cap-drop=all --cpus=1 --read-only --tmpfs=/tmp:rw,size=1g,mode=1777,noexec

This gives it no way to communicate with the outside world and drops all capabilities so it's not allowed to interact with the kernel at all. Setting CPU limit to be 1 also prevents DOS attacks internally.

I also run the process under the nobody user which entirely avoids the "container root is system root" issue.

I'm also only sort of running "untrusted" code. I'm running tensorflow models which can do arbitrary computation but are more secure than just running raw code.

Unified deployment with your non-go containers.

Also, port and volume mapping, so the container/go binary does not need to know physical/host pathnames to data files.

You could, but the application would not run sandboxed and probably wouldn't play nice with other binaries / applications running on the same server.

Maybe you'd like to run it on kubernetes; as far as I know running in a container is a requirement.

You don't. Perhaps they need to fit a square peg into a rectangular hole.

Reply on news.ycombinator.com