How to debug a 502 Bad Gateway

[tiredofit]

How to debug a 502 Bad Gateway

[tiredofit]

Because you are overwriting the default.conf file in /etc/nginx/conf.d likely -
the STAGE command isn't really useful in that image other than to me, but it wont hurt to have it set.

The ./logs/nginx/error.log should also give a clue as to whats happening.

[perarg]

Because you are overwriting the default.conf file in /etc/nginx/conf.d

I wanted to have a control to some kind of modifications in the feature. But I didn't change anything there. I haven't previously created any folder there, so the conf.d/ is a mirror of the container's folder.

The ./logs/nginx/error.log should also give a clue as to whats happening.

That's a weird thing. access.log and error.log are both empty.

I notice that there is no location / { } directive in nginx.conf file. Is it relative to the issue?

[tiredofit]

Strange, I can't seem to recreate it even doing what you are doing with the conf.d folder. I think this is probably a good opportunity to add some custom script functionality into the image. I'm quite busy right now but will put it on the list to support some sort of "snippets" function.

Hows about when you head inside the container and type curl localhost

[perarg]

Hows about when you head inside the container and type curl localhost

Connection refused at port 80

But...
i tried commenting the line # - ./nginx_conf.d:/etc/nginx/conf.d and it worked.

I noticed that when i try to link the folder /etc/nginx/conf.d with a host folder (./nginx_conf.d) these two folders are empty. Why this is happening ??

The two other volumes (html and logs) are created at the container's creation time and they contain the files existed inside the container. But this is not happening with the /etc/nginx/conf.d folder. It is empty only when i try to mount it.

[tiredofit]

I have a couple of files in nginx/conf.d - the biggest one that matters would be the default.conf file - I'm guessing if you are mapping it, and the folder is empty outside the container, it's overwriting the inside of it which is killing the config.

I have to figure out a way to be able to load additional configs for you - I agree this is not the best way forward, but I rarely if ever do something with this image other than serve basic apps, more so using it as a springboard to build other images.

On one of my other images I expanded on this and had a "conf.available" folder that let me use and insert certain templates, although it was very specific for the application. I'll need to think about this on how to implement without mucking too many things up.

At the very least you could in the meantime get a copy of the nginx/conf.d/default.conf from the working image, copy it out, make your changes to it and then mount the folder ./conf.d:/etc/nginx/conf.d:ro for the time being. The image won't fail per say just won't edit any of the files properly, I've done that a few times in a pinch.

[perarg]

At the very least you could in the meantime get a copy of the nginx/conf.d/default.conf from the working image, copy it out, make your changes to it and then mount the folder ./conf.d:/etc/nginx/conf.d:ro for the time being

That's how i did it and it is indeed a working path.