Evan

@dorongutman Otherwise, I've not had a chance to use multi-stage builds yet. But the idea is more to have `alpine-fat` derive from the `alpine` image. Being able to copy-out OpenResty...

I'm very supportive of this. Thanks for pointing out K8S aspects of it. We've talked about some aspects of this in #24. Things have evolved since then and Nginx now...

The logs would get written to `/var/run/openresty/{access,error}.log` but those are symlinked to `/dev/std{out,err}` in the build. Users can replace that if they want, but it gets Docker logging to work...

I have released the new temporary paths in `1.15.8.2-2`. The log destinations and default user have not changed.

The [Usage section of the README](https://github.com/openresty/docker-openresty#usage) says: > docker-openresty symlinks /usr/local/openresty/nginx/logs/access.log and error.log to /dev/stdout > and /dev/stderr respectively, so that Docker logging works correctly. If you change the log...

What happens if you do `docker logs` on the raw container... meaning outside of your `docker-compose` run . Edit: I mean, start with `docker-compose` and witness the buffering... then look...

I was Googling a bit and it seems there's some nuance or issues with `docker-compose` and buffering. If you think there's something with the image, I can try to help...

It looks like that person's tooling uses this library: https://github.com/knyar/nginx-lua-prometheus Beyond the build scaffolding in that repo, there are no extra modules or compile-time changes needed. There is an OPM...

I'm sorry I haven't been responsive on this. I think it does make sense to make all these images as slim as possible. And think that can happen across all...

My plan is to rework the Dockerfiles using Docker multi-stage builds and provide thin/fat versions of all the packages.