{"id":8773,"date":"2016-07-23T08:08:36","date_gmt":"2016-07-22T23:08:36","guid":{"rendered":"https:\/\/jirak.net\/wp\/3-ways-to-automate-with-nginx-and-nginx-plus\/"},"modified":"2016-07-23T08:34:41","modified_gmt":"2016-07-22T23:34:41","slug":"3-ways-to-automate-with-nginx-and-nginx-plus","status":"publish","type":"post","link":"https:\/\/jirak.net\/wp\/3-ways-to-automate-with-nginx-and-nginx-plus\/","title":{"rendered":"3 Ways to Automate with NGINX and NGINX\u00a0Plus"},"content":{"rendered":"

3 Ways to Automate with NGINX and NGINX\u00a0Plus<\/p>\n

\n
“<\/span>How long would it take your organization to deploy a change that involves just one single line of code?”<\/span><\/div>\n
– Lean software development guru Mary Poppendieck<\/a><\/div>\n<\/div>\n

In many organizations today, manual processes are slowing down the process of deploying and managing applications. Manual processes create extra work for developers and operations teams, cause unnecessary delays, and increase the time it takes to get new features and critical bug and security fixes into the hands of customers. Automating common tasks – using tools, scripts, and other techniques – is a great way to improve operational efficiency and accelerate the rollout of new features and apps.<\/p>\n

The potential improvements to productivity with automation are impressive. With the proper components in place, some companies have been able to deploy new code to production more than 50 times per day, creating a more stable application and increasing customer satisfaction.<\/p>\n

High‑performing DevOps teams turn to the open source NGINX<\/a> software and to NGINX Plus<\/a> to build fully automated, self‑service pipelines that developers use to effortlessly push out new features, security patches, bug fixes, and whole new applications to production with almost no manual intervention. <\/p>\n

This blog covers three methods for automating common workflows using NGINX and NGINX Plus.<\/p>\n

For more, register for our live webinar, 3 Ways to Automate App Deployments with NGINX<\/a>, to be held on Wednesday, July 27, 2016 at 10:00 AM PDT.<\/p>\n

Method 1 – Pushing New App Versions to Production<\/h2>\n

Releasing a new version is one of the most common occurrences in the lifecycle of any software application. Common reasons for an update are introducing a new feature or fixing bugs in existing functionality. Updating becomes much simpler and less time‑consuming when it\u2019s automated, as you can ensure that the same process is happening on all your servers simultaneously, and you can define rollback procedures or fallback code.<\/p>\n

To facilitate automation, NGINX Plus has an easy‑to‑use HTTP‑based API<\/a> that allows on‑the‑fly reconfiguration of upstream server groups. With the API, you can modify an upstream group of servers by adding or removing instances as part of your deployment script. The changes are reflected in NGINX Plus immediately, which means you can simply add a line that makes a curl<\/code> request to your NGINX load balancer as a final step in your deployment script, and the servers are updated automatically. <\/p>\n

To use the HTTP interface, create a separate location<\/code><\/a> block in the configuration block for a virtual server and include the upstream_conf<\/code><\/a> directive. We\u2019re using the conventional name for this location, \/upstream_conf<\/strong>. We want to restrict use of the interface to administrators on the local LAN, so we also include allow<\/code> and deny<\/code><\/a> directives:<\/p>\n

server {
\n    listen 8080;          # Listen on a local port<\/p>\n
    location \/upstream_conf {
\n        allow 10.0.0.0\/8; # Allow access only from LAN
\n        deny all;         # Deny everyone else<\/p>\n
        upstream_conf<\/strong>;
\n    }
\n}<\/pre>\n
<\/code><\/p>\n
The API requires a shared memory zone to store information about an upstream group of servers, so we include the zone<\/code><\/a> directive in the configuration, as in this example for an upstream group called backend<\/strong>:<\/p>\n
upstream backend {
\n    zone backend 64k;
\n    server 10.2.2.90:8000;
\n    server 10.2.2.91:8000;
\n    server 10.2.2.92:8000;
\n}<\/pre>\n
<\/code><\/p>\n
Using the HTTP‑Based API<\/h3>\n
Let\u2019s say we’ve created a new server with IP address 10.2.2.93 to host the updated version of our application and want to add it to the backend<\/strong> upstream group. We can do this by running curl<\/code> with the upstream<\/code> and server<\/code> arguments in the URI.<\/p>\n
# curl 'http:\/\/localhost:8080\/upstream_conf?add=&upstream=backend&server=10.2.2.93:8000'<\/strong>
\nserver 10.2.2.93:8000; # id=3<\/pre>\n
<\/code><\/p>\n
Then we want to remove from service the server that’s running the previous application version. Abruptly ending all the connections to that server would result in a bad user experience, so instead we first drain sessions<\/a> on the server. To identify which server to drain, we need to display the IDs assigned to the servers in the group:<\/p>\n
# curl 'http:\/\/localhost:8080\/upstream_conf?upstream=backend'<\/strong>
\nserver 10.2.2.90:8000; # id=0
\nserver 10.2.2.91:8000; # id=1
\nserver 10.2.2.92:8000; # id=2
\nserver 10.2.2.93:8000; # id=3<\/pre>\n
<\/code><\/p>\n
We know that the server with the old application version has IP address 10.2.2.92, and the output shows us its ID is 2. We identify the server by that ID in the command that puts it in draining state:<\/p>\n
# curl 'http:\/\/localhost:8080\/upstream_conf?upstream=backend&id=2&drain=1'<\/strong>
\nserver 10.2.2.92:8000; # id=2 draining<\/pre>\n
<\/code><\/p>\n
Active connections to a server can be tracked using the upstreams.peers.id<\/em>.active<\/code> JSON object from the NGINX Plus extended Status module<\/a>, where id<\/em><\/code> is the same ID number for the server that we retrieved in the previous step. When there are no more connections to the server, we can remove it completely from the upstream group:<\/p>\n
# curl 'http:\/\/localhost:8080\/upstream_conf?upstream=backend&id=2&remove=1'<\/strong>
\nserver 10.2.2.90:8000; # id=0
\nserver 10.2.2.91:8000; # id=1
\nserver 10.2.2.93:8000; # id=3<\/pre>\n
<\/code><\/p>\n
This is just a sample of what you can do with the API, and you can script workflows that use the API to fully automate the release process. For more details, see our three‑part blog series, Using NGINX Plus for Backend Upgrades with Zero Downtime<\/a>.<\/p>\n
Method 2 – Automated Service Discovery<\/h2>\n
A modern microservices‑based application can have tens or even hundreds of services, each with multiple instances that are updated and deployed multiple times per day. With large numbers of services in deployment, it quickly becomes impossible to manually configure and reconfigure each service every time you deploy a new version or scale up and down to handle fluctuating traffic load. <\/p>\n
With service discovery<\/a>, you shift the burden of configuration to your application infrastructure, making the entire process a lot easier. NGINX and NGINX Plus support several service discovery methods for automatically updating a set of service instances.<\/p>\n
NGINX Plus can automatically discover new service instances and help cycle out old ones using a familiar DNS interface. In this scenario, NGINX Plus pulls the definitive list of available services from your service registry by requesting DNS SRV<\/code> records. DNS SRV<\/code> records contain the port number of the service, which is typically dynamically assigned in microservice architectures. The service registry can be one of many service registration tools such as Consul<\/a>, SkyDNS\/etcd <\/a>, or ZooKeeper<\/a>. <\/p>\n
In the following example, the service=http<\/code> parameter to the server<\/code><\/a> directive configures NGINX Plus to request DNS SRV<\/code> records for the servers in the my_service<\/strong> upstream group. As a result, the application instances backing my_service<\/strong> are discovered automatically.<\/p>\n
http {
\n    resolver dns-server-ip;<\/p>\n
    upstream my_service {
\n        zone backend 64k;
\n        server hostname-for-my_service service=http<\/strong> resolve;
\n    }
\n   server {
\n       ...
\n       location \/my_service {
\n            ...
\n            proxy_pass http:\/\/my_service;
\n        }
\n    }
\n}<\/pre>\n
<\/code><\/p>\n
With open source NGINX, a generic configuration template tool like consul‑template<\/a> can be used. When new service instances are detected, a new NGINX configuration is generated with the new service instances and NGINX is gracefully reloaded. For a detailed example of this solution, see this blog<\/a> by Shane Sveller at Belly.<\/p>\n
For more details on DNS‑based service discovery with NGINX Plus, see Using DNS for Service Discovery with NGINX and NGINX Plus<\/a> on our blog.<\/p>\n
Method 3 – Orchestration and Management<\/h2>\n
Large enterprises might deploy many instances of NGINX or NGINX Plus in production to load balance application traffic. It quickly becomes difficult to manage the configuration of each one individually, and this is where DevOps tools for configuration and management – such as Ansible, Chef, and Puppet – come into play. These tools allow you to manage and update configuration at a central location, from which changes are pushed out automatically to all managed nodes.<\/p>\n
NGINX Plus has several points of integration to help automate your processes and facilitate infrastructure and application management:<\/p>\n