Rework nginx.conf to be inline with alpine upstream and relocate line… #115
Conversation
…s from other files
|
I am a bot, here are the test results for this PR: |
1 similar comment
|
I am a bot, here are the test results for this PR: |
|
Also, food for thought. . . Currently we just set the resolver to 127.0.0.11, which is docker's dns service and works great with docker networking. However, k3s/k8s use a different resolver for their networks, requiring modification of all the nginx and proxy confs. Perhaps it would be more prudent to rely on what's listed in Here's a potential implementation: https://serverfault.com/a/638855 |
Addressed in d77a64a |
|
I am a bot, here are the test results for this PR: |
|
I have read mixed things about setting NGINX worker processes from inside a Docker container with some claiming the 'auto' settings cannot pick up the number of cores, but in my tests setting the worker_processes to auto has worked well. May be worth considering as an alternative to this: Pulling the latest Alpine container in docker, and installing NGINX with apk add suggests it is also using the auto setting: For reference: https://nginx.org/en/docs/ngx_core_module.html#worker_processes "worker_processes – The number of NGINX worker processes (the default is 1). In most cases, running one worker process per CPU core works well, and we recommend setting this directive to auto to achieve that. There are times when you may want to increase this number, such as when the worker processes have to do a lot of disk I/O." - https://www.nginx.com/blog/tuning-nginx/ |
|
I am a bot, here are the test results for this PR: |
|
@Maggie0002 it is only auto-generated if it doesn't already exist. Then it's up to the user to set it to whatever number they prefer, or |
I mean the default generated by the script would like be better as 'auto' rather than detecting the number of cores itself and echoing the number to a file. Using 'auto' passes off the detection process to NGINX to do, reducing the need for the container scripts to handle the logic. It aligns it with the Alpine container NGINX defaults and recommended settings from NGINX page noted above. It also provides a default setup that is responsive to the changes going on at the hardware level, for example it I were to scale up or down a VPS from 2 cores to 4 cores, after a restart the 'auto' setting would adjust accordingly, whereas the script here would have left me at 2 cores. The auto-generated file makes sense, but having the new file generated with the default setting of 'auto' would likely be more effective. |
Based on all information we're able to find on this topic, After some more extensive testing I have found that the original proposed solution You are correct that our init script would for example set you up with a value of Our container has shipped with the default hard coded to Anyway we do appreciate you chiming in (got me to take a second look at the original implementation). If you have any additional info I'm happy to read it. |
|
I am a bot, here are the test results for this PR: |
|
I am a bot, here are the test results for this PR: |
|
I am a bot, here are the test results for this PR: |
Of course no problem at all, appreciate the consideration of the change. I had seen the posts like the one you cited but hadn’t found anything more recent that echos the issue still remains (the cited one is 6 years old). So I did a test a while back myself. As the number set for worker processes starts a process for each, you can see the workers when you look in HTOP on Linux. Worker processes 4 and will be 4 lines for NGINX process, worker processes set to 1 and there will be 1 line for NGINX etc etc. When set to auto in a container it launched the correct number of worker processes based on the number of CPUs, and changed after restart if I scaled the number of cpus on the server. Interesting though that the previous solution you had there didn’t pick up resource limiting to the container. That’s one thing I didn’t check on the ‘auto’ mode in the container test I mentioned above. Also interesting that the default Alpine NGINX repo uses the auto mode (the file you referenced in your original post) considering they are primarily used as containers and there doesn’t seem to be any concrete guidance from NGINX on it. That’s my two cents on it. Everything you mentioned above makes sense, setting a worker process on launch is already a step up from having it default to 4. And despite NGINX’s recommendation to use the auto mode, if I recall correctly they still default to a fixed number on their own docker images. Of course a circumstance where someone would really need to care about how many worker processes they have, is a high demand service and really should be checking this and a lot more manually anyway. Maybe all this info so far will prove useful to someone else experimenting with it in the future. |
|
I am a bot, here are the test results for this PR: |
…s from other files
Supersedes #104
Ref: https://git.alpinelinux.org/aports/tree/main/nginx/nginx.conf
Other additions:
resolver.conf(only if it doesn't exist) with values from the container's/etc/resolv.conf(helps with k3s/k8s internal dns resolution)worker_processes.conf(only if it doesn't exist) with detected cpu coresffdhe4096for dhparams.pem per RFC7919closes #119