4 ms·

Nobody calls it '12 factor' anymore but we still adhere to a generic set of principles as a result (since 12-factor predated docker and kubernetes in the mainst

by ljm 3y ago

Nobody calls it '12 factor' anymore but we still adhere to a generic set of principles as a result (since 12-factor predated docker and kubernetes in the mainstream). - Logs as a stream: yep, just write your logs to STDOUT instead of a file. Let the orchestrator deal with reading and storing it. - Configuration in the environment. Apps tend to pull config from different sources depending on the deploy - maybe a .env locally and a secret store in production. - Port binding - your app listens on a port and you put nginx or whatever in front of it and set up a reverse proxy. K8S services and ingress do that. I think the biggest criticism you can lay down on 12 Factor these days is that it's not actually written very well and assumes you know exactly what it is talking about.

talent_deprived 3y ago
> Port binding - your app listens on a port and you put nginx or whatever in front of it Apache for my personal projects, in front of the docker containers.
morelisp 3y ago
It's written very well but the audience is server application programmers in 2011, not someone who has written a dozen services yet never seen a log rotator, "production mode", or an AF_UNIX socket in their whole career.
rbanffy 3y ago
> - Logs as a stream: yep, just write your logs to STDOUT instead of a file. Let the orchestrator deal with reading and storing it. This is one that always feels odd to me: what happened to rsyslogd?
- craigmcnamara 3y ago
  Not the responsibility of the container. The host deals with those details.
  - rbanffy 3y ago
    Still, I haven't seen it in quite some time.
paulddraper 3y ago
*STDERR
- me-vs-cat 3y ago
  The normal output of a service is a log, and should go to STDOUT. The service can separately output errors to STDERR. The normal output of a non-service command (eg. grep) sometimes/often goes to STDOUT, which is why that command will write errors to STDERR -- even "info" messages that look like logging.
  - paulddraper 3y ago
    The normal output of a service is nothing.
    - zemo 3y ago
      dunno if you haven't noticed but people haven't been writing self-daemonizing processes that disappear into the background silently for ::checks watch:: at least a decade now. The practice of writing self-daemonizing processes was always a wart, a reflection of how low our expectations are of the job-control expressivity of cli shells. Grab ten programmers who use bash/zsh every day and say "you have a program that runs in the foreground forever, launch it in the background and close your terminal" and see what they do. You'll find some mixture of nohup, launching it and putting it in the background and disowning it, putting it in a tmux session and then detaching from the session, or deciding they have to put it in a container just to get that behavior, or some other workaround to deal with the fact that launching a process into the background is an ergonomic challenge for a lot of people. The circa-2000 status quo actually had a drawback or two.

by ljm 3y ago

talent_deprived 3y ago

> Port binding - your app listens on a port and you put nginx or whatever in front of it Apache for my personal projects, in front of the docker containers.

morelisp 3y ago

It's written very well but the audience is server application programmers in 2011, not someone who has written a dozen services yet never seen a log rotator, "production mode", or an AF_UNIX socket in their whole career.

rbanffy 3y ago

> - Logs as a stream: yep, just write your logs to STDOUT instead of a file. Let the orchestrator deal with reading and storing it. This is one that always feels odd to me: what happened to rsyslogd?

craigmcnamara 3y ago
Not the responsibility of the container. The host deals with those details.
- rbanffy 3y ago
  Still, I haven't seen it in quite some time.

paulddraper 3y ago

*STDERR

me-vs-cat 3y ago
The normal output of a service is a log, and should go to STDOUT. The service can separately output errors to STDERR. The normal output of a non-service command (eg. grep) sometimes/often goes to STDOUT, which is why that command will write errors to STDERR -- even "info" messages that look like logging.
- paulddraper 3y ago
  The normal output of a service is nothing.
  - zemo 3y ago
    dunno if you haven't noticed but people haven't been writing self-daemonizing processes that disappear into the background silently for ::checks watch:: at least a decade now. The practice of writing self-daemonizing processes was always a wart, a reflection of how low our expectations are of the job-control expressivity of cli shells. Grab ten programmers who use bash/zsh every day and say "you have a program that runs in the foreground forever, launch it in the background and close your terminal" and see what they do. You'll find some mixture of nohup, launching it and putting it in the background and disowning it, putting it in a tmux session and then detaching from the session, or deciding they have to put it in a container just to get that behavior, or some other workaround to deal with the fact that launching a process into the background is an ergonomic challenge for a lot of people. The circa-2000 status quo actually had a drawback or two.