This article is published under a SIGNATURE 4.0 International (CC BY 4.0) license. Signature 4.0 International (CC BY 4.0)

Author: Su Yang

Creation time: on May 20, 2020 statistical word count: 5171 words reading time: 11 minutes to read this article links: soulteary.com/2020/05/20/…

Nginx basic usage pickups

Nginx is a daily familiar with the software, stability and efficiency is the label of this software. Nginx is often used as an address forwarding service or as a file hosting capability. But there’s more to Nginx than that. Native Nginx also has a lot of utility that allows you to do some of the messy little things in your business.

This article covers the three basic uses, and if you are familiar with Nginx and containers, the reading time is about five minutes.

Writing in the front

The sample environment used this time is simulated using containers. If you’re not familiar with containers, welcome to the previous Docker-related articles.

Easy to create health checks with Compose

Some front-end class containers have no service capabilities themselves, but in order to enjoy the basic health check of the container services and provide external services such as load balancing, we may have to start a language runtime such as Node/PHP/Java. However, if you use Nginx as the front-end Web services software, it comes with basic routing capabilities and the power to customize response codes and content, which saves us from introducing a huge language runtime.

All we need to do is add a route named /health to the configuration and then use the default_type and return directive to do the desired “return HTTP CODE 200 and output something when the service is healthy”.

server {
  listen 80;

  location = /health {
    access_log off;
    default_type text/html;
    return 200 'alive'; }}Copy the code

You may say, we can have the health check software check the business routes, but I want to tell you that when we isolate the routes, you will see the health check response time is faster, and we can also discard the logs. If you combine health check routes with service routes, massive health check logs and service logs will make you miserable during debugging.

It’s also easy to do a health check with Compose:

version: "3.6"Services: health.test.soulteary.com: image: nginx: 1.18.0 - alpine volumes: - ./default.conf:/etc/nginx/conf.d/default.conf:ro healthcheck:# Used in older versions
      # test: ["CMD-SHELL", "wget -q --spider --proxy off localhost:80/health || exit 1"]
      test: ["CMD-SHELL"."curl -f localhost/health || exit 1"]
      interval: 3s
      retries: 12
Copy the code

When you use Docker PS to view the container process, you will see that our container will be marked as “HEALTHY”, and then you can carry out basic operations such as container service basic DISASTER recovery with various strategies.

CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS                    PORTS                                                  NAMES
2afd71cd562 e nginx: 1.18.0 - alpine"Nginx - g 'daemon of..."   10 minutes ago      Up 3 seconds (healthy)   80/tcp             health.test.soulteary.com_1
Copy the code

Use Nginx to aggregate content from different sites

In the daily development process, in the “front-end cross-domain”, “fixed link in the SMS template”, “existing program call source restriction” and other scenarios, the need to aggregate site domain name or path will be encountered.

We know that it is possible to achieve remote content retrieval and transliteration using programming languages, but it is actually much easier to achieve content aggregation using Nginx’s reverse proxy capabilities.

Before doing content aggregation, for example, we need to access the content on apple.test.soulteary.com and banana.test.soulteary.com, and we hope that after polymerization content show in test.soulteary.com.

For the sake of emulating the environment, we’ll start by creating a compose configuration file:

version: "3.6"Services: test.soulteary.com: Image: nginx:1.18.0- Alpine Ports: -8080 :8080 Volumes: -. / default. Conf: / etc/nginx/conf. D/default. Conf: ro apple.test.soulteary.com: image: nginx: 1.18.0 - alpine volumes: - ./apple.test.soulteary.com.conf:/etc/nginx/conf.d/default.conf:ro banana.test.soulteary.com: image: Nginx: 1.18.0 - alpine volumes: -)/banana.test.soulteary.com.conf:/etc/nginx/conf.d/default.conf:roCopy the code

The three subitems of Services in the configuration file represent the aggregated site and the two sites to be aggregated, which can be imagined as three servers connected to the network in real life.

Continue to create apple.test.soulteary.com.conf this Nginx configuration file.

server {
    listen 80;
    server_name apple.test.soulteary.com;
    default_type text/html;

    location / {
        return 200 'apple.test.soulteary.com'; }}Copy the code

As you can see, the site functions very simply. When you visit /, it returns HTTP CODE 200 and outputs text apple.test.soulteary.com, In the same way we create another site banana.test.soulteary.com Nginx configuration file.

Finally, create an Nginx configuration to aggregate profiles.

server {
    listen 8080;
    server_name test.soulteary.com;

    location = / {
        return 302 /apple;
    }

    location /apple {
        proxy_pass http://apple.test.soulteary.com/;
        proxy_set_header Host "apple.test.soulteary.com";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /banana {
        proxy_pass http://banana.test.soulteary.com/;
        proxy_set_header Host "banana.test.soulteary.com";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }}Copy the code

As you can see, the configuration is very simple, with proxy_pass and proxy_set_header directives, we have aggregated the different sites together.

Bind test.soulteary.com locally, then start the service, use the command line to access the site, and you can see that the configuration is as expected.

# curl http://test.soulteary.com:8080/apple  
apple.test.soulteary.com

# curl http://test.soulteary.com:8080/banana
banana.test.soulteary.com
Copy the code

Forward Git SSH TCP requests

In addition to handling HTTP requests, Nginx can also aggregate/forward TCP type data. For example, if we want to restrict access to a GitLab in a production environment to a specific IP address, we can do this using Nginx in addition to cloud platform firewall rules.

The ngx_STREAM_proxy_module of Nginx is used here.

The default configuration of the Nginx container contains only the HTTP service mode, so this change cannot be the same as above. We need to change the main configuration of the nginx.conf.

Docker run --rm it nginx:1.18.0-alpine cat /etc/nginx/nginx.confCopy the code

By executing the above command, you can see that the default configuration is simple:

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush on;

    keepalive_timeout  65;

    #gzip on;

    include /etc/nginx/conf.d/*.conf;
}
Copy the code

To make it easy for the reader to verify, let’s assume that the target repository is GitHub and after a simple modification to the configuration file:

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } stream{ server{ listen 2223; proxy_pass github.com:22; proxy_connect_timeout 10s; proxy_timeout 20s; proxy_buffer_size 512k; }}Copy the code

We continue to create a compose configuration file:

version: "3.6"Services: proxy-git.test.soulteary.com: image: nginx:1.18.0- Alpine Ports: -2223:2223 Volumes: - ./nginx.conf:/etc/nginx/nginx.conf:roCopy the code

After starting the docker-compose up service, we use the classic Git test command line to verify the service:

# ssh -T [email protected] -p 2223
The authenticity of host '[127.0.0.1] : 2223 (2223) (127.0.0.1) :' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '(127.0.0.1) : 2223' (RSA) to the list of known hosts. Hi soulteary! You've successfully authenticated, but GitHub does not provide shell access.
Copy the code

You will find that we have achieved the desired target at this point. If you do not believe me, you can use the same command to test the original Git server address.

# ssh -T [email protected]    

Hi soulteary! You've successfully authenticated, but GitHub does not provide shell access.
Copy the code

As mentioned at the beginning of this section, we can use Nginx’s native Allow/deny directives to do this:

Location / {deny 192.168.1.1; Allow 192.168.1.0/24; Allow 10.1.1.0/16; allow 2001:0db8::/32; deny all; }Copy the code

The last

There are many more interesting and useful uses of Nginx, but for time’s sake, I won’t go into them here.

–EOF

I now have a small toss group, which gathered some like to toss small partners.

In the case of no advertisement, we will talk about software, HomeLab and some programming problems together, and also share some technical salon information in the group from time to time.

Like to toss small partners welcome to scan code to add friends. (Please specify source and purpose, otherwise it will not be approved)

All this stuff about getting into groups