1. 16
  1.  

  2. 14

    The irony of using Docker, which runs only on Linux (and requires Docker), to distribute a daemon written in Go, which could be compiled statically and run anywhere without dependencies.

    1. 4

      What if this is going to be built upon, and the next stage is to add something further that requires Docker? There is no claim that this is intended to be optimal for a Go project and the author even hints at how it can be used with multiple platforms at the beginning. There is a related post from today at https://lobste.rs/s/v5rrhi/your_statement_is_100_correct_misses which is worth reading.

      1. 0

        Then show it being somehow useful.

        Using Go as your ‘introduction’ to how Docker might help things, is like telling someone to spend an hour preparing a charcoal BBQ, then saying “ok great now get out your hot dog and put it on the grill. It’ll be done in about 30 seconds”.

        You’re right that someone missed the point, but I guess we’ll just have to agree to disagree about who it was.

        1. 3

          It only has to be useful to illustrate how Docker works. If Go provides the simplest examples, then it might be best to use that to keep the samples easy for the audience. It might be more infinitely more useful to dockerize other projects when it comes to real world use, but I don’t think that’s the point. The author is writing for their audience, and this might not include you.

          1. 2

            Personally find these “How to do the barebones thing” very useful. It’s the equivalent of a reprex. Because it doesn’t have anything sophisticated going on it’s a useful point to compare against when you have something weird going on.

      2. 4

        Very nice! Here is something more that I do when I sometimes teach people docker multistage builds. I use this example of an HTTP server from go by example. And I use busybox instead of alpine for the base image.

        1. 2

          Interesting. Any reason for preferring busybox over Alpine Linux as the base image?

          1. 3

            Even smaller :) In the end, if we’re talking about Go executables in the container, you do not even need busybox and you can FROM scratch

            1. 3

              But you might want to copy something over from your (alpine, or debian) build stage, like ca-certificates or timezone files.

              1. 3

                One size does not fit all :) Of course you may want to do what you say.

        2. 4

          Nice writeup! Some small comments:

          • The examples contain HTML entities (&, >) rather than the actual characters & and >.

          • In this example

          docker rm my_hello_world_server; docker run --name my_hello_world_server -p 127.0.0.1:8080:8080 -it my_hello_world_server
          

          You could also use docker run with the --rm flag to do the cleanup for you. I.e.:

          docker run --rm --name my_hello_world_server -p 127.0.0.1:8080:8080 -it my_hello_world_server
          
          • Nitpicking:

          Oops, we forgot to install Go runtime for building this.

          Not only the runtime, also the compiler ;).

          1. 2

            Not only the runtime, also the compiler ;).

            Good catch. This should have been build toolchain. Fixed.

            1. 2

              The examples contain HTML entities (&, >) rather than the actual characters & and >.

              The Wordpress editors show me & and > while they render as & and > :/ Fixed by editing the source.

              Also, added –rm as an option. Thanks, TIL.

            2. 4

              It would be nice to show a modified version of that server serving files, to illustrate how you deal with accessing resources external to the Docker image.

              1. 2

                Thanks. I will include that in a follow-on writeup I am planning to write on deployment.

              2. 0

                Interesting, I didn’t know about BuildKit!