4 ms·

> This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. You

by twic 3y ago

> This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. You're misinterpreting that guideline. The text says (my emphasis): > Most programming languages offer a packaging system for distributing support libraries, such as CPAN for Perl or Rubygems for Ruby. Libraries installed through a packaging system can be installed system-wide (known as “site packages”) It's not saying not to depend on the operating system (of which glibc is part), it's saying not to require particular language package manager packages to be installed on the machine. Agreed that the other ones you mention are silly, though. Especially the one about environment variables - that isn't actually reasoned advice, it was just the authors writing down what was most common in Ruby development at the time, on the assumption that that must be the best thing to do.

vilunov 3y ago
Well, glibc could be considered part of the operating system, although this too is arguably not correct, because some technologies go out of the way to not depend on anything present in the system and be completely self-contained, e.g. fully statically linked Go binary with no Cgo usage. Nevertheless, glibc is not the only system dependency which is often used by apps, another such example is JVM of a specific version, which is not tracked by any of the popular JVM build tools and package managers; and OpenSSL, which is too installed by the system package manager. Dockerfiles exists to fix this by defining all the necessary installation steps as a sequence of instructions, but this is far from a proper package manager.
- twic 3y ago
  The libc is absolutely part of the operating system. Some people and tools go out of their way to avoid using it, but they are completely mistaken to do so. Go in particular has wasted a huge amount of effort on this absolutely pointless exercise. And not just libc - on a typical unix, there are a small number of other libraries which constitute part of the operating system, like libm, libdl, and libpthread. They are part of the means by which the operating system delivers the POSIX environment. You're right that the JVM is a dependency, and that there is very poor versioning support for it in production. Everywhere i've worked, we've come up with ad-hoc solutions for it, and none of them have been very good.
aniforprez 3y ago
In my experience, sourcing config from env variables seems like the best thing to do because you can completely ignore where the app is running in favor of injecting whatever you want in any environment of your choosing and your app no longer needs to care about that. The implication is that business logic must not include the content of your config or where it is sourced from. It must simply use the values in the config. This way my apps could give less of a fart if I run it as a container in kube, in nomad, in local on localhost, in a devcontainer, in a directory with vars loaded using direnv, in vercel/netlify and so on. This also allows incredible flexibility in how that config is sourced as long as you simply dump them into the env vars. Want to load secrets from a .env file on local? Sure. Want to load secrets from Vault on production? Run a simple script to load vault secrets onto the env and run your app.
- dalyons 3y ago
  yeah this is the actual point - it makes the code/app totally portable & decoupled from config. I find it significantly better than having to have the app code choose different config based on interrogating facts about its runtime (eg am i in prod? use this value. am i in test? use this)
  - twic 3y ago
    Everything you both wrote is spot on - but there's nothing about it which means you have to use environment variables! All of those mechanisms could be used with any other means of delivering the config at the point of process invocation - a config file, command line arguments, YAML to standard input, whatever. Personally, i would pick a config file over environment variables any day: easier to manually inspect and tweak, easier to give structure to, doesn't get implicitly passed down to subprocesses, can be secured with familiar file permissions, etc.
    - stackskipton 3y ago
      Problem with config files is you are forced to process it properly in pipeline so it can be delivered during deploy AND depending on your runtime environment, you might have to redeploy to change things. Environment variables exist on just about EVERY runtime, changed without requiring a pipeline run. However, subprocess is interesting but I've never run into subprocess that is not sharing a config. Where I worked, if you have subprocess that can't see those configs, you create a new service.
jjice 3y ago
I heavily agree. I used to work on a LAMP stack where the deployment was just dumping the code into an EC2 instance. All is fine until there's a weird system dependency error that isn't documented because the AMI being used has just been hand built over the last three years. Have fun tracking down that specific PHP system dependency when AL2 goes EOL. I don't want to write code that doesn't have _documented_ dependencies on system packages. Even just a Dockerfile serves as solid documentation on what we're using.

by twic 3y ago

vilunov 3y ago

Well, glibc could be considered part of the operating system, although this too is arguably not correct, because some technologies go out of the way to not depend on anything present in the system and be completely self-contained, e.g. fully statically linked Go binary with no Cgo usage. Nevertheless, glibc is not the only system dependency which is often used by apps, another such example is JVM of a specific version, which is not tracked by any of the popular JVM build tools and package managers; and OpenSSL, which is too installed by the system package manager. Dockerfiles exists to fix this by defining all the necessary installation steps as a sequence of instructions, but this is far from a proper package manager.

twic 3y ago
The libc is absolutely part of the operating system. Some people and tools go out of their way to avoid using it, but they are completely mistaken to do so. Go in particular has wasted a huge amount of effort on this absolutely pointless exercise. And not just libc - on a typical unix, there are a small number of other libraries which constitute part of the operating system, like libm, libdl, and libpthread. They are part of the means by which the operating system delivers the POSIX environment. You're right that the JVM is a dependency, and that there is very poor versioning support for it in production. Everywhere i've worked, we've come up with ad-hoc solutions for it, and none of them have been very good.

aniforprez 3y ago

In my experience, sourcing config from env variables seems like the best thing to do because you can completely ignore where the app is running in favor of injecting whatever you want in any environment of your choosing and your app no longer needs to care about that. The implication is that business logic must not include the content of your config or where it is sourced from. It must simply use the values in the config. This way my apps could give less of a fart if I run it as a container in kube, in nomad, in local on localhost, in a devcontainer, in a directory with vars loaded using direnv, in vercel/netlify and so on. This also allows incredible flexibility in how that config is sourced as long as you simply dump them into the env vars. Want to load secrets from a .env file on local? Sure. Want to load secrets from Vault on production? Run a simple script to load vault secrets onto the env and run your app.

dalyons 3y ago
yeah this is the actual point - it makes the code/app totally portable & decoupled from config. I find it significantly better than having to have the app code choose different config based on interrogating facts about its runtime (eg am i in prod? use this value. am i in test? use this)
- twic 3y ago
  Everything you both wrote is spot on - but there's nothing about it which means you have to use environment variables! All of those mechanisms could be used with any other means of delivering the config at the point of process invocation - a config file, command line arguments, YAML to standard input, whatever. Personally, i would pick a config file over environment variables any day: easier to manually inspect and tweak, easier to give structure to, doesn't get implicitly passed down to subprocesses, can be secured with familiar file permissions, etc.
  - stackskipton 3y ago
    Problem with config files is you are forced to process it properly in pipeline so it can be delivered during deploy AND depending on your runtime environment, you might have to redeploy to change things. Environment variables exist on just about EVERY runtime, changed without requiring a pipeline run. However, subprocess is interesting but I've never run into subprocess that is not sharing a config. Where I worked, if you have subprocess that can't see those configs, you create a new service.

jjice 3y ago

I heavily agree. I used to work on a LAMP stack where the deployment was just dumping the code into an EC2 instance. All is fine until there's a weird system dependency error that isn't documented because the AMI being used has just been hand built over the last three years. Have fun tracking down that specific PHP system dependency when AL2 goes EOL. I don't want to write code that doesn't have _documented_ dependencies on system packages. Even just a Dockerfile serves as solid documentation on what we're using.