4 ms·

Bare metal doesn't mean what it used to.

gaius 12y ago
You know, Unix has a pretty good abstraction already for managing resources: a process. Nowadays it is fashionable to deploy applications consisting of hundreds of files in a complex structure, but this is fashion and not technology and that's easy to demonstrate: in the old days, a C application consisted of hundreds of files in a complex structure, that would compile into one self-contained executable. There's no technical reason you couldn't take a RoR app (for example) and "compile" it and manage it just like any other process. Start it, stop it, move it around, one binary executable and one plain text file for configuration, that's really all you need for any application. Really. I look at things like Docker and think, you are solving a completely artificial problem, and as soon as fashion swings the other way (10 years at most) people will wonder why people ever did this.
- vidarh 12y ago
  > You know, Unix has a pretty good abstraction already for managing resources: a process. And that's what Docker is built on: processes + namespaces to restrict what each process group can access. > I look at things like Docker and think, you are solving a completely artificial problem, and as soon as fashion swings the other way (10 years at most) people will wonder why people ever did this. Things like Docker will still have value with single-executable containers. Problems that people have had for years. Even with single-executables. You still need to manage privileges. You still need service discovery. You still need to manage the network. You still need to manage data volumes. You still need to manage the environment. Docker provides mechanisms that either solves all of that, or provides information for tools to hook into (e.g. ability to query what ports the currently running containers expose). I agree with you that there is distinct benefit in self-contained executables, and I think you'll find a lot of people working with Docker thinks the same. Partly this is part of what Docker gives us: We get to treat a bigger hairball of an environment pretty much like a single entity, even if we're not able to slim it down. But partly, note that a lot of the adoption of Go within devops tools appears to at least partially be motivated by the simplicity of distribution and installation from getting static binaries (without having to use C). I prefer Ruby, and find Go to be a ugly, too low level, language, but I definitively understand the appeal Go has when it comes to simplicity. Yet despite having those devops tools as single executables, people want to put them in containers to manage them properly. If anything, I hope and think that things will move even further down this route. For my part, I'm containerising my desktop environment part by part. There's no reason we should not move to far more locked down process environments.
  - custardcream 12y ago
    Couple of points/questions, at least from my perspective as a man of many hats to anyone passing by the above comment: 1. Docker appears to only allow a single entry point per container. What do I do if I want to run a container consisting of say postfix and dovecot together? If this is possible can someone please point me at it. 2. Go doesn't allow you to bundle resources with the executables (as say Java/C#) so you have to rely on 3rd party libraries to do this that aren't very good. I can't easily ship my templates with my web server for example as part of the "go build" process. Again if I'm wrong, please point me at a solution.
    - vidarh 12y ago
      Personally I wouldn't run Postfix and Dovecot together under Docker. Instead, I'd export a volume for the mail store, and share that volume between a Postfix and Dovecot container. But if you absolutely want to put them in the same container, the solution is to run a process manager as the entrypoint. E.g. base it on something like baseimage-docker [1] Re: 2. I don't use Go, so I can't answer that part. [1] http://phusion.github.io/baseimage-docker/ http://phusion.github.io/baseimage-docker/
      - custardcream 12y ago
        Thanks for the info. I'd have a couple of problems with exporting the volume because I need postfix to talk to a Unix domain socket that dovecot listens on for SASL auth. I'll go with the process manager solution - thanks for your suggestion! Been trying to build a canned mail server for a few years so this is probably a nice solution if I can get my head around it.
        myhf 12y ago
        Unix domain sockets work in docker shared volumes. A common use-case is to mount /dev/log into a container so that it doesn't have to run its own syslogd.
        vidarh 12y ago
- amirmc 12y ago
  Sounds a lot like you're describing Mirage OS (and its ilk). I see that you've written OCaml before, so I assume you've come across it already -- if not, I think you'd find it really interesting. http://openmirage.org http://openmirage.org
- pjc50 12y ago
  I very much see your point, but containerisation deals with the limitations of the UNIX permissions system. Not everything is a file, or at least controllable through the file permissions system. The requirement to run as root to open sockets below 1024 has been a security disaster, for example, because you can't just say "webserver user is allowed to open port 80". Docker configuration files are standardised. Application configuration files generally aren't.
  - mappu 12y ago
    I realise you're trying to make a more serious point, but to address the symptom, have you seen `authbind` ?
michaelchisari 12y ago
I thought he was going to make an argument for hand-coded assembly language.
- smcl 12y ago
  To me the phrase "bare metal" would mean writing software (in C, Asm or whatever) that does not use any sort of Operating System or VM.
  - rdc12 12y ago
    I was expecting something along those lines, the sort of post that makes my mind hurt in a good way
  - gaius 12y ago
    In the future, "bare metal" will mean writing Javascript without a framework.
    - moron4hire 12y ago
      Well then, according to the reaction I've had to my projects at various startup meetups, the future is now!
    - jacquesm 12y ago
      That's microcode.
  - masklinn 12y ago
    "bare metal" is often used to mean "OS-less", running a binary or language VM directly (or on Xen to get very-basic HAL (e.g. http://erlangonxen.org) http://erlangonxen.org)) I still have no idea how TFA is using it.

gaius 12y ago

You know, Unix has a pretty good abstraction already for managing resources: a process. Nowadays it is fashionable to deploy applications consisting of hundreds of files in a complex structure, but this is fashion and not technology and that's easy to demonstrate: in the old days, a C application consisted of hundreds of files in a complex structure, that would compile into one self-contained executable. There's no technical reason you couldn't take a RoR app (for example) and "compile" it and manage it just like any other process. Start it, stop it, move it around, one binary executable and one plain text file for configuration, that's really all you need for any application. Really. I look at things like Docker and think, you are solving a completely artificial problem, and as soon as fashion swings the other way (10 years at most) people will wonder why people ever did this.

vidarh 12y ago
> You know, Unix has a pretty good abstraction already for managing resources: a process. And that's what Docker is built on: processes + namespaces to restrict what each process group can access. > I look at things like Docker and think, you are solving a completely artificial problem, and as soon as fashion swings the other way (10 years at most) people will wonder why people ever did this. Things like Docker will still have value with single-executable containers. Problems that people have had for years. Even with single-executables. You still need to manage privileges. You still need service discovery. You still need to manage the network. You still need to manage data volumes. You still need to manage the environment. Docker provides mechanisms that either solves all of that, or provides information for tools to hook into (e.g. ability to query what ports the currently running containers expose). I agree with you that there is distinct benefit in self-contained executables, and I think you'll find a lot of people working with Docker thinks the same. Partly this is part of what Docker gives us: We get to treat a bigger hairball of an environment pretty much like a single entity, even if we're not able to slim it down. But partly, note that a lot of the adoption of Go within devops tools appears to at least partially be motivated by the simplicity of distribution and installation from getting static binaries (without having to use C). I prefer Ruby, and find Go to be a ugly, too low level, language, but I definitively understand the appeal Go has when it comes to simplicity. Yet despite having those devops tools as single executables, people want to put them in containers to manage them properly. If anything, I hope and think that things will move even further down this route. For my part, I'm containerising my desktop environment part by part. There's no reason we should not move to far more locked down process environments.
- custardcream 12y ago
  Couple of points/questions, at least from my perspective as a man of many hats to anyone passing by the above comment: 1. Docker appears to only allow a single entry point per container. What do I do if I want to run a container consisting of say postfix and dovecot together? If this is possible can someone please point me at it. 2. Go doesn't allow you to bundle resources with the executables (as say Java/C#) so you have to rely on 3rd party libraries to do this that aren't very good. I can't easily ship my templates with my web server for example as part of the "go build" process. Again if I'm wrong, please point me at a solution.
  - vidarh 12y ago
    Personally I wouldn't run Postfix and Dovecot together under Docker. Instead, I'd export a volume for the mail store, and share that volume between a Postfix and Dovecot container. But if you absolutely want to put them in the same container, the solution is to run a process manager as the entrypoint. E.g. base it on something like baseimage-docker [1] Re: 2. I don't use Go, so I can't answer that part. [1] http://phusion.github.io/baseimage-docker/ http://phusion.github.io/baseimage-docker/
    - custardcream 12y ago
      Thanks for the info. I'd have a couple of problems with exporting the volume because I need postfix to talk to a Unix domain socket that dovecot listens on for SASL auth. I'll go with the process manager solution - thanks for your suggestion! Been trying to build a canned mail server for a few years so this is probably a nice solution if I can get my head around it.
      - myhf 12y ago
        Unix domain sockets work in docker shared volumes. A common use-case is to mount /dev/log into a container so that it doesn't have to run its own syslogd.
      - vidarh 12y ago
amirmc 12y ago
Sounds a lot like you're describing Mirage OS (and its ilk). I see that you've written OCaml before, so I assume you've come across it already -- if not, I think you'd find it really interesting. http://openmirage.org http://openmirage.org
pjc50 12y ago
I very much see your point, but containerisation deals with the limitations of the UNIX permissions system. Not everything is a file, or at least controllable through the file permissions system. The requirement to run as root to open sockets below 1024 has been a security disaster, for example, because you can't just say "webserver user is allowed to open port 80". Docker configuration files are standardised. Application configuration files generally aren't.
- mappu 12y ago
  I realise you're trying to make a more serious point, but to address the symptom, have you seen `authbind` ?

michaelchisari 12y ago

I thought he was going to make an argument for hand-coded assembly language.

smcl 12y ago
To me the phrase "bare metal" would mean writing software (in C, Asm or whatever) that does not use any sort of Operating System or VM.
- rdc12 12y ago
  I was expecting something along those lines, the sort of post that makes my mind hurt in a good way
- gaius 12y ago
  In the future, "bare metal" will mean writing Javascript without a framework.
  - moron4hire 12y ago
    Well then, according to the reaction I've had to my projects at various startup meetups, the future is now!
  - jacquesm 12y ago
    That's microcode.
- masklinn 12y ago
  "bare metal" is often used to mean "OS-less", running a binary or language VM directly (or on Xen to get very-basic HAL (e.g. http://erlangonxen.org) http://erlangonxen.org)) I still have no idea how TFA is using it.