Hacker News Reader

Comment by ljm | Hacker News Reader

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.

View on HN

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.

> - 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?

Not the responsibility of the container. The host deals with those details.

Still, I haven't seen it in quite some time.

*STDERR

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.

The normal output of a service is nothing.

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.

> 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.

Reply on news.ycombinator.com