中文
Every month, we receive fascinating questions from both our customers and open source users about how to use our products for a wide range of use cases, and how to properly integrate other platforms and tools with NGINX.
We want to share this expertise as widely as possible across the NGINX community, so we decided to launch a new series: Ask NGINX. Every month, we’ll share a selection of questions that we’ve received during the month. These have been answered by our experts including technical architects, systems engineers, and our award‑winning customer support specialists.
When migrating from F5 to NGINX Plus, how do I convert an iRule for content‑based routing?
We hear this question often, as our customers modernize their application delivery infrastructure with the adoption of DevOps practices, replacing their F5 application delivery controllers with NGINX Plus to improve agility. NGINX Plus implements request routing with the location directive, using either a URI prefix or regular expressions to match against requests. For examples of how to implement either option, see Migrating F5 iRules and Citrix Policies to NGINX Plus on our blog. For complete instructions on all aspects of a migration, download our free ebook, F5 BIG-IP to NGINX Plus: Migration Guide.
How do I convert Apache rewrite rules to NGINX syntax?
See Converting Apache Rewrite Rules to NGINX Rewrite Rules on our blog. You need to convert rewrite rules from Apache to NGINX syntax when you place NGINX Open Source or NGINX Plus in front of your Apache servers to take over as either the reverse proxy or load balancer, or when you replace Apache web servers with NGINX web servers. Keep in mind that NGINX and NGINX Plus do not support per‑directory configuration files (Apache’s .htaccess files), so you need to convert them in particular.
Can I use NGINX to protect our services without exposing them directly to the Internet?
Yes. You can use NGINX Open Source and NGINX Plus as a reverse proxy to distribute client requests across all your backend servers. You then publish the reverse proxy’s address as the access point for your site, instead of the address where your services are hosted. By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. NGINX Plus offers a variety of enterprise‑grade enhancements that simplify load balancing and improve reliability, including active health checks, dynamic reconfiguration of upstream groups, and state sharing across multiple NGINX Plus instances in a cluster.
Can NGINX Plus function as an API gateway? How can I manage all my APIs?
Yes, NGINX Plus can be deployed as an API gateway. For full API lifecycle management, we have just launched the API Management Module for NGINX Controller. This module enables Infrastructure & Operations and DevOps teams to define, publish, secure, monitor, and analyze APIs, all without compromising performance.
Can I use NGINX Plus to implement blue‑green deployment, where incoming traffic is easily switched between two servers or containers, using either a script or a call to the NGINX Plus API?
Yes, you can! It can be done with the NGINX Plus key‑value store. Define two upstream groups named blue and green, then use the NGINX Plus API to set a value that indicates which upstream group to use. Here’s a sample configuration.
keyval_zone zone=blue-green:64k;
keyval $environment $keyval_upstream zone=blue-green;
map $keyval_upstream $upstream {
~.+ $keyval_upstream;
default blue;
}
upstream blue {
# ...
}
upstream green {
# ...
}
server {
set $environment environment;
location / {
proxy_pass http://$upstream;
}
# Enable the NGINX Plus API. For production, add directives to restrict
# access to the API.
location /api {
api write=on;
# in production, directives restricting access
}
}The map block sets the default environment to blue, so you don’t have to initialize the key‑value store. To change to the green environment, run this command:
# curl -iX PATCH -d '{"environment":"green"}' http://localhost/api/3/http/keyvals/blue-greenThis is one of the simplest possible use cases for the key‑value store, as there is only one key in the store (namely environment, defined with the set directive). For more complex use cases – including A/B testing, bandwidth limiting, and IP address denylisting – see our blog.
Ask Us!
Got a question for our Ask NGINX series? Leave a comment below or get in touch with our team, and we’ll be happy to help!
