5 ms·

That's the thing I like about self-contained binaries (Of Go or any other sort). Just FROM scratch COPY this-or-that LABEL prometheus.port=9100

by ilyt 3y ago

That's the thing I like about self-contained binaries (Of Go or any other sort). Just FROM scratch COPY this-or-that LABEL prometheus.port=9100 LABEL prometheus.path=/metrics EXPOSE 3001 EXPOSE 9100 and nothing breaks. Only feeble component is CA bundle for SSL-related stuff as that by nature is changeable.

lmm 3y ago
Why bother with a container at that point? Doesn't it introduce as many problems as it solves?
- deleted 3y ago
  [deleted]
- femiagbabiaka 3y ago
  The same reason you'd use one to begin with, primarily isolation of processes. That doesn't go away just because the binary is statically compiled. But you don't have to, of course, plenty of people don't.
- xyst 3y ago
  Now you are back to the “it works on my machine” issues. Seen a couple of times where a precompiled binary works okay on one OS but the behavior changes when ran on another OS. In my case, the bottom bid contracting firm that delivered the code had special logic for windows but otherwise wouldn’t happen on unix based machines.
  - lmm 3y ago
    > Now you are back to the “it works on my machine” issues. Seen a couple of times where a precompiled binary works okay on one OS but the behavior changes when ran on another OS. Sure, but containers don't protect you from that - you're still exposed to differences in the host kernel. For that kind of issue you'd want a full VM rather than a container.
    - maxbond 3y ago
      By that logic, we'll need to ship bare metal, to avoid differences in processors. You've gone from being exposed to OS and kernel differences to being exposed only to kernel differences. For most apps, that's acceptable. Others will need to ship VMs. Some will even need to ship bare metal. It's a tool, not a dogma.
      - lmm 3y ago
        What "OS differences" are you exposed to if you're shipping a static binary? > It's a tool, not a dogma. The idea that containers are the only or right way to do service orchestration is absolutely dogma, enforced by kubernetes and friends.
        maxbond 3y ago
        > What "OS differences" are you exposed to if you're shipping a static binary? I dunno, probably stuff like ulimits and selinux rules that you don't think about until it burns you. Not to mention whatever idiosyncratic configuration your customer might perform. > [It's] absolutely dogma, enforced by kubernetes and friends. The dogmatic people are wrong to be dogmatic, but in the context of this particular conversation, I would like to point out - meaning no disrespect - that it is you who is advocating the more maximalist and less pragmatic view.
        lmm 3y ago
        > The dogmatic people are wrong to be dogmatic, but in the context of this particular conversation, I would like to point out - meaning no disrespect - that it is you who is advocating the more maximalist and less pragmatic view. How so? The thread started with talking about having a statically linked binary (not a specific one with special requirements, but a generic one), and described putting it in a container with a config to expose some ports from it. That seems very much like a dogmatic everything-must-be-a-container position. I'm not arguing for never using containers, I'm arguing for using them where they make sense and not using them where they don't.
- stavros 3y ago
  Does it solve any problems? How is a statically-linked executable liable to break from changes in an OS it doesn't even use?
  - theamk 3y ago
    Badly designed apps can break in all sorts of fun ways without docker - Check for processes called "sleep", exit if such process exist (or try to kill it). - Reset $PATH to default value then expect to find a _very_ specific ancient version of system utilities there. - Create files in /tmp with fixed names. Fail if they already exist. Forget to delete them on failure. - Walk entire filesystem searching for something. Crash on broken symlinks. - Enumerate network interfaces. Crash if more than 7 are present. - Hardcode _both_ specific user name and associated UID. - Put temp files all over place, including into application directory - Ignore $HOME and use homedir from /etc/passwd, then create lock/config file under homedir. And you want to run two instance of this app in parallel.
- ilyt 3y ago
  Sometimes customer wants containers; most of our (ops/orchestration) runs outside of container but containerising it (for same reason, one static blob) is easy But the code I nicked the example from was actually our internal k8s/docker deployment testing/debug app, so, well, it's in containers by design.
- quickthrower2 3y ago
  Maybe you are using kubernetes or there are multiple things running on the box you want to keep isolated.
- pravus 3y ago
  Because I get other levels of isolation such as at the network, filesystem, and syscalls and I can run many instances of the same binary on a host much like a VM, but vastly lighter-weight. No, containers are not a problem and they don't add any additional problems.
chomp5977 3y ago
This is just moving the complexity to your build process.
- ilyt 3y ago
  That's the beauty! The build process is exactly the same for in and out of container stuff. In both cases result is either binary or binary + static files (nowadays, as it is mostly ops stuff, binary gets embedded static files). It's not more complex by any stretch
zX41ZdbW 3y ago
A nice writeup: https://notes.volution.ro/v1/2022/01/notes/fbf3f06c/ https://notes.volution.ro/v1/2022/01/notes/fbf3f06c/

by ilyt 3y ago

lmm 3y ago

Why bother with a container at that point? Doesn't it introduce as many problems as it solves?

deleted 3y ago
[deleted]
femiagbabiaka 3y ago
The same reason you'd use one to begin with, primarily isolation of processes. That doesn't go away just because the binary is statically compiled. But you don't have to, of course, plenty of people don't.
xyst 3y ago
Now you are back to the “it works on my machine” issues. Seen a couple of times where a precompiled binary works okay on one OS but the behavior changes when ran on another OS. In my case, the bottom bid contracting firm that delivered the code had special logic for windows but otherwise wouldn’t happen on unix based machines.
- lmm 3y ago
  > Now you are back to the “it works on my machine” issues. Seen a couple of times where a precompiled binary works okay on one OS but the behavior changes when ran on another OS. Sure, but containers don't protect you from that - you're still exposed to differences in the host kernel. For that kind of issue you'd want a full VM rather than a container.
  - maxbond 3y ago
    By that logic, we'll need to ship bare metal, to avoid differences in processors. You've gone from being exposed to OS and kernel differences to being exposed only to kernel differences. For most apps, that's acceptable. Others will need to ship VMs. Some will even need to ship bare metal. It's a tool, not a dogma.
    - lmm 3y ago
      What "OS differences" are you exposed to if you're shipping a static binary? > It's a tool, not a dogma. The idea that containers are the only or right way to do service orchestration is absolutely dogma, enforced by kubernetes and friends.
      - maxbond 3y ago
        > What "OS differences" are you exposed to if you're shipping a static binary? I dunno, probably stuff like ulimits and selinux rules that you don't think about until it burns you. Not to mention whatever idiosyncratic configuration your customer might perform. > [It's] absolutely dogma, enforced by kubernetes and friends. The dogmatic people are wrong to be dogmatic, but in the context of this particular conversation, I would like to point out - meaning no disrespect - that it is you who is advocating the more maximalist and less pragmatic view.
        lmm 3y ago
        > The dogmatic people are wrong to be dogmatic, but in the context of this particular conversation, I would like to point out - meaning no disrespect - that it is you who is advocating the more maximalist and less pragmatic view. How so? The thread started with talking about having a statically linked binary (not a specific one with special requirements, but a generic one), and described putting it in a container with a config to expose some ports from it. That seems very much like a dogmatic everything-must-be-a-container position. I'm not arguing for never using containers, I'm arguing for using them where they make sense and not using them where they don't.
stavros 3y ago
Does it solve any problems? How is a statically-linked executable liable to break from changes in an OS it doesn't even use?
- theamk 3y ago
  Badly designed apps can break in all sorts of fun ways without docker - Check for processes called "sleep", exit if such process exist (or try to kill it). - Reset $PATH to default value then expect to find a _very_ specific ancient version of system utilities there. - Create files in /tmp with fixed names. Fail if they already exist. Forget to delete them on failure. - Walk entire filesystem searching for something. Crash on broken symlinks. - Enumerate network interfaces. Crash if more than 7 are present. - Hardcode _both_ specific user name and associated UID. - Put temp files all over place, including into application directory - Ignore $HOME and use homedir from /etc/passwd, then create lock/config file under homedir. And you want to run two instance of this app in parallel.
ilyt 3y ago
Sometimes customer wants containers; most of our (ops/orchestration) runs outside of container but containerising it (for same reason, one static blob) is easy But the code I nicked the example from was actually our internal k8s/docker deployment testing/debug app, so, well, it's in containers by design.
quickthrower2 3y ago
Maybe you are using kubernetes or there are multiple things running on the box you want to keep isolated.
pravus 3y ago
Because I get other levels of isolation such as at the network, filesystem, and syscalls and I can run many instances of the same binary on a host much like a VM, but vastly lighter-weight. No, containers are not a problem and they don't add any additional problems.

chomp5977 3y ago

This is just moving the complexity to your build process.

ilyt 3y ago
That's the beauty! The build process is exactly the same for in and out of container stuff. In both cases result is either binary or binary + static files (nowadays, as it is mostly ops stuff, binary gets embedded static files). It's not more complex by any stretch

zX41ZdbW 3y ago

A nice writeup: https://notes.volution.ro/v1/2022/01/notes/fbf3f06c/ https://notes.volution.ro/v1/2022/01/notes/fbf3f06c/