31–40 of 296 posts
Author doesn't know about https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' environment (or rather, doesn't know about separation of such environments in the first place).
I don't know about https://12factor.net either. But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.
> For comparison using JSON configuration files this entire class os problems would not exist.
This is the trade-of between structure and embedding. Writing '{"ARG": "-Dfoo=\"bar bar\" -Dbaz"}' would satisfy the authors need for JSON but not really do any difference.
The initial example is also wrong. There certainly are example where one would use variables defined in out scope.
f v = f' 0
where
f' n = v nMaybe I live under a rock, but I feel like command line utilities taking environment variable arguments just isn’t that common of a practice? The only examples I can think of are when an argument is more of a “global variable” that many different commands may find useful such as JAVA_HOME, GITHUB_TOKEN, etc. For web applications and docker containers, environment variables fit easily into the deployment process and f…
Earlier quoted context omitted.
Changing a variable of an existing container without recreating or re-running the docker run command is tricky, though. With a configuration file mapped to an external folder it's "just" modifying the file and docker restart, with environment variables it's somewhat more convoluted. I don't think it is as clear-cut as the title suggest, each kind of configuration has its place.
You don't need to modify the Dockerfile to change environment variables at runtime. Also if you specifically want to modify a file and re-run the container look at --env-file arg to docker run.
What I say is that if you are in a machine with an already running docker container, one you don't have the corresponding `run` command of (i.e. you _can't docker run_ for whatever reason), changing the environment variables of that container is tricky.
I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…
One of the projects I currently work on, the configuration system/model/table is a monster.. I wish it was just strings. It basically contains boolean flags, strings, numbers etc but the most insidious one is, it can contain groups of related configs - meaning people started dumping stuff into that should be a normal table (ex, ShippingType:, Road, Rail, Air), so we get no foreign key constraints for reference data. This caused them to implement soft-deletes for it, so now you have some config values that float around forever because they were referenced somewhere (aka pseudo-foreignkey). It's so utterly dumb I want delete the whole thing but everyone thinks it works great (non-tech people). I'm a developer, not a system-admin, but this is too much. Doesn't help that 5 different people has added 'features' to it over the years. The same can be accomplished with something waaaay simpler/cleaner. We also keep having config-related issues where people blame the system/servers/devops etc... every single time it is due to misconfig the project, so the system admins cannot do anything about it anyways (meaning we keep wasting their time, thinking the problem was with the servers). Let me pause here, need to take a blood pressure pill.
Earlier quoted context omitted.
I don't know about https://12factor.net either. But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.
What security concerns did that alleviate?
I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…
The article's point stands if we're being lame and treating internal code details as external.