I have a requirement to run the services (Zeppelin, grafana etc) using https. I have installed certificates and added below configuration to NGINX.
But still it is not working, please let me know if any other configuration to be added. Thanks!
server {
listen 443 ssl;
ssl on;
ssl_certificate ../crt/*****.crt;
ssl_certificate_key ../crt/*****.key;
.
.
.
location /zeppelin {
proxy_pass http://127.0.0.1:8080/#/;
}
}
Configure the zeppelin IP in upstream and use the upstream name in proxy_pass like below
upstream zeppelin {
server 127.0.0.1:8080;
}
server {
....
location / {
proxy_pass http://zeppelin;
}
....
}
To host zeppelin under 'zeppelin' context you have to change the zeppelin.server.context.path property in conf/zeppelin-site.xml
Configuring zeppelin using nginx needs more configuration like websocket proxying. You can refer the sample nginx configuration in this link
Related
I have a front-end react app, that runs at localhost:3000. And a back-end that runs at localhost:9900.
I can access my back-end with a postman's(or curl) localhost:80/api request.
But I can't access either the site or the server via the web address: my-1stconnection.lan.test.
What's the problem?
NGINX config:
server {
listen 80;
listen [::]:80;
server_name my-1stconnection.lan.test;
location / {
proxy_pass http://localhost:3000/;
}
location /api {
proxy_pass http://localhost:9900/;
}
}
I forgot one important thing in order to activate the local server:
127.0.0.1 my-1stconnection.lan.test into /etc/hosts
After this fix, everything started working.
I have have four web applications running in one ec2-instance with hostname "ip-10-176-225-83.us-west-2.compute.internal" on the ports 8888, 8088, 8042 and 8890. All those web application are on HTTP.
Our security team doesn't allow to open http port from onpremise to AWS. The suggest to setup a reverse proxy in same VPC subent which takes HTTPS requests and forward the same to back end webservers using HTTP.
I have created a new instance in same subnet with hostname "ip-10-176-225-84.us-west-2.compute.internal" and installed Niginx Server.
How can i configure Nginx so that it does as below
https://ip-10-176-225-84.us-west-2.compute.internal:8080 call http://ip-10-176-225-83.us-west-2.compute.internal:8080 and responds back
same for other ports
TL;DR: There are several methods of accomplishing what you're looking for here.
Adhering to the principle of reducing attack surface where possible, it's usually best to not expose ports to the public internet unless absolutely necessary. A reverse proxy is an excellent way to accomplish this. Generally, you'd want all of the backend web apps to be reverse proxied over HTTPS on port 443, and you would access each service either:
with different host names, such as app1.example.com and app2.example.com, or
with different subdirectories, such as example.com/app1 and example.com/app2
Depending on the method you choose, the configuration may vary significantly, either with multiple server blocks for the former scenario, or location blocks for the latter. In either case, we'll be making use of the upstream and proxy_pass directives. I'll give an example of both scenarios.
Multiple Hosts
If you're using multiple hostnames (or multiple ports) for the frontend, you'll need to create multiple server blocks for them:
# Nginx reverse-proxy configuration
upstream app1 {
server 10.176.225.83:8888;
}
upstream app2 {
server 10.176.225.83:8088;
}
upstream app3 {
server 10.176.225.83:8042;
}
upstream app4 {
server 10.176.225.83:8890;
}
server {
listen 443 ssl;
server_name app1.example.com;
ssl_certificate_key /path/to/your/ssl-key.pem;
ssl_certificate /path/to/your/ssl-cert.pem;
location / {
proxy_pass http://app1;
}
}
server {
listen 443 ssl;
server_name app2.example.com;
ssl_certificate_key /path/to/your/ssl-key.pem;
ssl_certificate /path/to/your/ssl-cert.pem;
location / {
proxy_pass http://app2;
}
}
server {
listen 443 ssl;
server_name app3.example.com;
ssl_certificate_key /path/to/your/ssl-key.pem;
ssl_certificate /path/to/your/ssl-cert.pem;
location / {
proxy_pass http://app3;
}
}
server {
listen 443 ssl;
server_name app4.example.com;
ssl_certificate_key /path/to/your/ssl-key.pem;
ssl_certificate /path/to/your/ssl-cert.pem;
location / {
proxy_pass http://app4;
}
}
Several things to note here:
All of the backends have been defined at the top, using the upstream directive, and can now be referenced by name.
If you don't want to do it this way, you can omit the upstream blocks, and the proxy_pass lines would look like this: proxy_pass http://10.176.225.83:8888;
Because each app is being served on a different hostname, each gets its own server block. This would also be the case if they were each being served on different ports.
The ssl_certificate and ssl_certificate_key in each server block can point to different certificates, or even the same certificate, if you defined multiple SANs in the certificate.
Each app will be available from its own hostname, which all point to the frontend server:
App 1: https://app1.example.com
App 2: https://app2.example.com
App 3: https://app3.example.com
App 4: https://app4.example.com
Multiple Directories
For a configuration using a single host and port, serving the backend apps from subdirectories, you'll be using a single server block with multiple location blocks:
# Nginx reverse-proxy configuration
upstream app1 {
server 10.176.225.83:8888;
}
upstream app2 {
server 10.176.225.83:8088;
}
upstream app3 {
server 10.176.225.83:8042;
}
upstream app4 {
server 10.176.225.83:8890;
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate_key /path/to/your/ssl-key.pem;
ssl_certificate /path/to/your/ssl-cert.pem;
location /app1 {
proxy_pass http://app1;
}
location /app2 {
proxy_pass http://app2;
}
location /app3 {
proxy_pass http://app3;
}
location /app4 {
proxy_pass http://app4;
}
}
A few more things to note with this one:
We still define all four upstream services, as before. And you can still omit them if you prefer the direct route. This directive is more useful in complex configurations.
Because all the apps are being served from the same hostname, they share a server block, but have separate location blocks for their respective subdirectories.
Since they all share the same hostname, multiple SANs aren't necessary for the server certificate in this case.
Each backend app will be available from a subdirectory on the frontend server:
App 1: https://example.com/app1
App 2: https://example.com/app2
App 3: https://example.com/app3
App 4: https://example.com/app4
TLS Configuration
In either scenario, you'll need to configure SSL certificates, either signed by a public CA, or your internal PKI, if applicable. If your apps are to be public facing, you will need to use public certificates. Then you'd add their location to the above Nginx config.
Further Reading
For a real world example, you can check out the Nginx configuration I'm using for a Genieacs TR-069 server, which implements SSL and reverse proxies several other services, albeit on their original ports, not to 443. This may be useful if you wanted to keep them on their original ports.
The Nginx site also has a decent primer on reverse proxy basic configuration.
I am working with docker containers with reverse proxy for jenkins container and got into this issue.
My nginx custom config is as follow:
upstream jenkins {
server 172.17.0.2:8080;
}
server {
listen 80;
server_name jenkins;
location /jenkins {
proxy_pass http://172.17.0.2:8080;
}
Also, /etc/nginx/nginx.conf doesn't have any default root directory but still when I tried to access http://localhost/jenkins, it is giving me 404 with Problem accessing /jenkins. Reason:Not Found
I checked nginx error logs and it has "/etc/nginx/html/index.html" is not found
Though I have not set any /etc/nginx/html/ config, why it is giving me 404 error?
Can someone clarify my doubt?
ScreenShot
Something like this seems more approriate for the nginx part. If you declare an upstream, use it :
upstream jenkins {
server 172.17.0.2:8080;
}
server {
listen 80;
server_name jenkins;
location /jenkins {
proxy_pass http://jenkins;
}
}
For the docker part, I recommand using port mapping if you can. Because IP of docker containers change, you will have to edit you config file each time you recreate the jenkins container. With something like docker container run -d -p 127.0.0.1:8080:8080 my-jenkins-container-image you can modify your nginx config to something like :
upstream jenkins {
server 127.0.0.1:8080;
}
server {
listen 80;
server_name jenkins;
location /jenkins {
proxy_pass http://jenkins;
}
}
I tried to follow the instructions here, but I still can't seem to get it to work. As with the question, I don't expect some of the servers to be running at the time of starting nginx. I would actually prefer if instead a local 404 html were returned if the server was not running.
upstream main {
server my_main:8080;
}
server {
listen 80;
server_name www.my_site.com my_site.com;
location / {
resolver 8.8.8.8 valid=30s;
set $upstream_main main;
proxy_pass http://$upstream_main;
}
}
I'm having trouble figuring out load balancing on Nginx. I'm using:
- Ubuntu 16.04 and
- Nginx 1.10.0.
In short, when I pass my ip address directly into "proxy_pass", the proxy works:
server {
location / {
proxy_pass http://01.02.03.04;
}
}
When I visit my proxy computer, I can see the content from the proxy ip...
but when I use an upstream directive, it doesn't:
upstream backend {
server 01.02.03.04;
}
server {
location / {
proxy_pass http://backend;
}
}
When I visit my proxy computer, I am greeted with the default Nginx server page and not the content from the upstream ip address.
Any further assistance would be appreciated. I've done a ton of research but can't figure out why "upstream" is not working. I don't get any errors. It just doesn't proxy.
Okay, looks like I found the answer...
two things about the backend servers, at least for the above scenario when using IP addressses:
a port must be specified
the port cannot be :80 (according to #karliwsn the port can be 80 it's just that the upstream servers cannot listen to the same port as the reverse proxy. I haven't tested it yet but it's good to note).
backend server block(s) should be configured as following:
server {
# for your reverse_proxy, *do not* listen to port 80
listen 8080;
listen [::]:8080;
server_name 01.02.03.04;
# your other statements below
...
}
and your reverse proxy server block should be configured like below:
upstream backend {
server 01.02.03.04:8080;
}
server {
location / {
proxy_pass http://backend;
}
}
It looks as if a backend server is listening to :80, the reverse proxy server doesn't render it's content. I guess that makes sense, since the server is in fact using default port 80 for the general public.
Thanks #karliwson for nudging me to reconsider the port.
The following example works:
Only thing to mention is that, if the server IP is used as the "server_name", then the IP should be used to access the site, means in the browser you need to type the URL as http://yyy.yyy.yyy.yyy or (http://yyy.yyy.yyy.yyy:80), if you use the domain name as the "server_name", then access the proxy server using the domain name (e.g. http://www.yourdomain.com)
upstream backend {
server xxx.xxx.xxx.xxx:8080;
}
server {
listen 80;
server_name yyy.yyy.yyy.yyy;
location / {
proxy_pass http://backend;
}
}