4 ms·

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?

d4l3k 8y ago
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/ https://fn.lc/post/docker-scratch/
- dijit 8y ago
  >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-as-a-sandbox-for-untrusted-code/108013 https://security.stackexchange.com/questions/107850/docker-a...
  - Zekio 8y ago
    Docker containers can run in other places where they are secure, IIRC then Joyent has way to do this in their cloud
    - dijit 8y ago
      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.
      - d4l3k 8y ago
        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.
Cthulhu_ 8y ago
You could, but the application would not run sandboxed and probably wouldn't play nice with other binaries / applications running on the same server.
nemothekid 8y ago
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.
dijit 8y ago
Maybe you'd like to run it on kubernetes; as far as I know running in a container is a requirement.
apk17 8y ago
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.
nzoschke 8y ago
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-package-deploy.md https://github.com/nzoschke/gofaas/blob/master/docs/dev-pack...
mixmastamyk 8y ago
You don't. Perhaps they need to fit a square peg into a rectangular hole.

d4l3k 8y ago

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/ https://fn.lc/post/docker-scratch/

dijit 8y ago
>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-as-a-sandbox-for-untrusted-code/108013 https://security.stackexchange.com/questions/107850/docker-a...
- Zekio 8y ago
  Docker containers can run in other places where they are secure, IIRC then Joyent has way to do this in their cloud
  - dijit 8y ago
    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.
    - d4l3k 8y ago
      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.

Cthulhu_ 8y ago

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

nemothekid 8y ago

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.

dijit 8y ago

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

apk17 8y ago

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.

nzoschke 8y ago

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-package-deploy.md https://github.com/nzoschke/gofaas/blob/master/docs/dev-pack...

mixmastamyk 8y ago

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