Can nginx-ingress return a html content direct？

[xuziheng1002]

If I want to return html content by nginx-ingress, how can I do?

like as:

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

can I set any html content into nginx-ingress (with configmap? or snippets)

[github-actions[bot]]

Hi @xuziheng1002 thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

[vepatel]

Hi @xuziheng1002 , any application (html or otherwise) should be exposed using deployment, service and ingress/virtual-server using a docker image, see:

• https://github.com/nginxinc/kubernetes-ingress/tree/v3.2.1/examples/ingress-resources/complete-example
• https://github.com/nginxinc/kubernetes-ingress/tree/v3.2.1/examples/custom-resources/basic-configuration

snippets allow you to insert raw NGINX config into contexts of the NGINX configurations that the Ingress Controller generates but user must understand NGINX configuration primitives and implementing a correct NGINX configuration.

These can be inserted in configmap and/or Ingress.
May I ask you what use case here is not possible using normal workflow as in above two examples? Ideally snippets are used to provide extra functionality not directly available through Ingress or VirtualServer.

[brianehlert]

Also, consider something like this: https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#actionreturn

the ingress controller is still NGINX. And we allow different ways for you to extend it which supports you customizing in a way that works for you.
To add to what vepatel said. A response page may be an appropriate function. But attempting to use the ingress controller as a web server is not appropriate, you would be better served instrumenting NGINX as a service.

[xuziheng1002]

Hi @xuziheng1002 , any application (html or otherwise) should be exposed using deployment, service and ingress/virtual-server using a docker image, see:

• https://github.com/nginxinc/kubernetes-ingress/tree/v3.2.1/examples/ingress-resources/complete-example
• https://github.com/nginxinc/kubernetes-ingress/tree/v3.2.1/examples/custom-resources/basic-configuration

snippets allow you to insert raw NGINX config into contexts of the NGINX configurations that the Ingress Controller generates but user must understand NGINX configuration primitives and implementing a correct NGINX configuration.

These can be inserted in configmap and/or Ingress. May I ask you what use case here is not possible using normal workflow as in above two examples? Ideally snippets are used to provide extra functionality not directly available through Ingress or VirtualServer.

yes, I agree with your point of view. But I wish to remove unnecessary nodes in the request chain. Because we are deploy our app on OSS(Object Storage Service, a cloud service of storage) so I think the nginx pod is unnecessary if ingress can storage index.html file.

[xuziheng1002]

Also, consider something like this: https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#actionreturn

the ingress controller is still NGINX. And we allow different ways for you to extend it which supports you customizing in a way that works for you. To add to what vepatel said. A response page may be an appropriate function. But attempting to use the ingress controller as a web server is not appropriate, you would be better served instrumenting NGINX as a service.

yes, that is grate solution for me,
"But attempting to use the ingress controller as a web server is not appropriate"
-> why? Is it easy to encounter performance bottlenecks? Or is it difficult to upgrade smoothly? Or is there any other reason?

[brianehlert]

why? Is it easy to encounter performance bottlenecks? Or is it difficult to upgrade smoothly? Or is there any other reason?

I think of it this way. NGINX has personalities. Yes, those include web server, proxy, cache, api gateway, and so forth.
In that, an ingress controller is optimized to be a proxy. We carry that through default settings, optimizations, and design assumptions, and security and hardening related considerations. It is not just a K8s API integration of NGINX, but rather specific to the personalities of proxy, api gateway, some cache use cases.

All that said, we do have customers that use it in all kinds of ways and some that even ignore all the value we bring through YAML objects and other optimizations - because for them the key value is the K8s API integration itself. And you know what, that is okay. I will also say that these are generally advanced NGINX users as well. They are familiar with nginx.conf and very comfortable and tend to use advanced configuration knobs and tuning.
If you fall into this bucket, that is actually great - and I honestly want to understand more about why you want to use the ingress controller in a way that is "not proxy" so that we can figure out how to make your specific use case better - all around.

I noticed a comment about storage. Sure, the ingress controller could take your html and write it locally to disk and serve it. You might be better served all up to present a shared volume to the entire deployment, mounted at a specific path and mapping your configuration path to that. Then, all your artifacts remain unique and most likely managed in a method like you do today. It is kind of better of both worlds. K8s take care of the volume attach, sharing, and all that in this case.