3 ms·

It's a good question, especially in the age of small static binaries with no external depdencies anyway. Even if the isolation isn't of much value, Docker is s

It's a good question, especially in the age of small static binaries with no external depdencies anyway. Even if the isolation isn't of much value, Docker is still useful as transport and storage. Getting back to the shipping container metaphor, it's easier to move things around if they are all the same. And Docker containers are a pretty good way to do that with code.

sz4kerto 11y ago
I don't know if this is the age of small binaries. Maybe in some industries. The artifacts we're deploying are -- partly because of various constraint, partly because of the weight of legacy - are between 25-50 MB. Oh, and they are run inside of a Java app server, that's also 100-200 MB. Ah, and that runs on a Java VM. The integration tests require a running Firefox, Chrome, V8, JVM, databases, whatever. (No, I can't replace these with a couple of command-line Unix tools just yet.)
- lobster_johnson 11y ago
  I suspect the parent is mostly referring to Go.
  - auvrw 11y ago
    i do wonder what aspects of Go make it good for the container use-case. both Docker and the other container system mentioned at the top of the article are written in Go.
    - jacques_chester 11y ago
      > i do wonder what aspects of Go make it good for the container use-case. Same as JARs or C/C++ binaries. You can ship the compiled product to the target runtime and expect it to launch and run as-is. Languages with an interpreted nature require containers to also ship an additional runtime, plus a dependencies mechanism.
      - techdragon 11y ago
        Go is a step further than these though since it enables "static binaries" you can run go programs in docker with nothing else in their containers. Just one file, the Go binary. Which is amazing and frustrating since it exposes the inability of other languages to operate in such a simple environment. Even languages like Rust, C and C++ aren't able to do this reliably all the time, with the results being highly dependent on libraries and platforms of choice.
        auvrw 11y ago
        thanks for the &replies ;-) ... tbh, Go vs. Rust for the, "i wanna write a Docker-thing!" use case was pretty much the question i had in mind. the Rust ppl are looking toward static linking [links]... https://internals.rust-lang.org/t/static-binary-support-in-rust/2011/48 https://internals.rust-lang.org/t/static-binary-support-in-r... https://github.com/rust-lang/rust-buildbot/issues/24 https://github.com/rust-lang/rust-buildbot/issues/24
nzoschke 11y ago
Yeah the registry is a great example. I too am building everything into nice little Go binaries, and wonder why I'm using Docker to run these in production. It's really nice to have the common interface and tools both on dev and prod. If I didn't wrap these binaries in Docker I'd be wrapping them in upstart scripts, systemd config, chef scripts or .deb packages. All of these layers are a burden. Docker is simply more modern, easier, and has a great API, and tools for packaging, running and monitoring a program. Why not Docker for everything?

sz4kerto 11y ago

I don't know if this is the age of small binaries. Maybe in some industries. The artifacts we're deploying are -- partly because of various constraint, partly because of the weight of legacy - are between 25-50 MB. Oh, and they are run inside of a Java app server, that's also 100-200 MB. Ah, and that runs on a Java VM. The integration tests require a running Firefox, Chrome, V8, JVM, databases, whatever. (No, I can't replace these with a couple of command-line Unix tools just yet.)

lobster_johnson 11y ago
I suspect the parent is mostly referring to Go.
- auvrw 11y ago
  i do wonder what aspects of Go make it good for the container use-case. both Docker and the other container system mentioned at the top of the article are written in Go.
  - jacques_chester 11y ago
    > i do wonder what aspects of Go make it good for the container use-case. Same as JARs or C/C++ binaries. You can ship the compiled product to the target runtime and expect it to launch and run as-is. Languages with an interpreted nature require containers to also ship an additional runtime, plus a dependencies mechanism.
    - techdragon 11y ago
      Go is a step further than these though since it enables "static binaries" you can run go programs in docker with nothing else in their containers. Just one file, the Go binary. Which is amazing and frustrating since it exposes the inability of other languages to operate in such a simple environment. Even languages like Rust, C and C++ aren't able to do this reliably all the time, with the results being highly dependent on libraries and platforms of choice.
      - auvrw 11y ago
        thanks for the &replies ;-) ... tbh, Go vs. Rust for the, "i wanna write a Docker-thing!" use case was pretty much the question i had in mind. the Rust ppl are looking toward static linking [links]... https://internals.rust-lang.org/t/static-binary-support-in-rust/2011/48 https://internals.rust-lang.org/t/static-binary-support-in-r... https://github.com/rust-lang/rust-buildbot/issues/24 https://github.com/rust-lang/rust-buildbot/issues/24

nzoschke 11y ago

Yeah the registry is a great example. I too am building everything into nice little Go binaries, and wonder why I'm using Docker to run these in production. It's really nice to have the common interface and tools both on dev and prod. If I didn't wrap these binaries in Docker I'd be wrapping them in upstart scripts, systemd config, chef scripts or .deb packages. All of these layers are a burden. Docker is simply more modern, easier, and has a great API, and tools for packaging, running and monitoring a program. Why not Docker for everything?