NGINX Unit 未来三个月的进展与计划

Three months ago, we released the first beta version of NGINX Unit, a new dynamic web and application server. See our initial description of NGINX Unit, the announcement blog post, the in‑depth demo, and our webinar.

The announcement of NGINX Unit became the top story on Hacker News. The code continues to receive attention on GitHub, and NGINX Unit’s features and architecture spawned numerous discussion threads on Facebook, Twitter, and other networks. We invite you to download NGINX Unit packages or compile it yourself, to try it, and to join the discussion.

To share our progress since the initial beta release, in this blog post, I’ll summarize the last three months of engineering work, then describe our plans for future features and for production readiness.

Vision

We at NGINX have known for many years how to connect to applications. Now, with NGINX Unit, we help you run them. Modern applications change frequently, and they consist of multiple parts. Various services that comprise a distributed application are written in different languages by separate teams. All parts of this mess have to work together for the benefit of end users.

NGINX Unit is designed with some key points about modern applications in mind:

• Instances of web and app server – In most environments, we see NGINX used as a web server and reverse proxy in front of every application instance. Operations teams choose to implement a web server as an additional layer for consistency, security, and ease of configuration. Now, with NGINX Unit, the web‑server features are tightly coupled with the application execution runtime. In addition to consistent operation, you see improved performance of the application, with fewer moving parts.
• Frequent changes – Today’s infrastructure gives you the ability to make changes easily. You can run cloud virtual machines, containers, and lightweight server workloads, and scale them independently and frequently. NGINX Unit has a fresh architecture, doesn’t reload on changes, and gives you an easy, dynamic operation model for the application infrastructure. You can make changes in architecture and in running code as frequently as you need to. All changes are performed without loss of connection or interruption in service.
• Multiple stacks – Using multiple application languages and infrastructure stacks creates complexity and inconsistency in the operation of a large application. Because NGINX Unit can run many application stacks and application versions at the same time, you get operational consistency, stability, and performance across the range of supported languages and language versions. In addition, NGINX Unit isolates applications from one another, providing an aspect of security that every production deployment needs.
• Service‑to‑service connectivity – Distributed applications, including microservices applications, inevitably require reliable connectivity across their infrastructure. NGINX has a lot of experience in connecting users to applications, and services to services, within large, distributed environments. One of our goals for future releases is to build service‑to‑service proxy features into NGINX Unit in order to simplify the operation of your service mesh.

Architectural Approach

NGINX Unit is new software, built from scratch. We didn’t reuse any major part of the existing architecture of NGINX while designing and developing NGINX Unit.

In NGINX Unit, we decided not to have configuration code compatibility with NGINX for the following reasons:

• When NGINX was originally designed, 15 years ago, many features of today’s systems were not available, or were not stable enough for widespread deployment. Examples include threads and cgroups. We can utilize them now in the core of NGINX Unit.
• Placing NGINX Unit as the server for backend operation in distributed applications focuses on features that are different from a frontend web server and reverse proxy, such as NGINX.
• Creating a new code base allows us to focus more strongly on the performance and security of your application. Now we treat application code as an essential part of the web operation, and not as a black box behind a reverse proxy.
• With this fresh start, we were able to design NGINX Unit so it can be configured and reconfigured “live,” during runtime, with no separate configuration file. To achieve configuration code compatibility with NGINX, we would have had to add an otherwise unneeded configuration file, and much other scaffolding, to NGINX Unit, complicating the software.

However, although they’re distinct, NGINX Unit and NGINX are parts of the NGINX Application Platform, and you can use them together, playing different roles within your application environment.

NGINX Unit Source Code

NGINX Unit is free. The source code is available at http://hg.nginx.org/unit and https://github.com/nginx/unit. It’s available under the Apache 2.0 license. You can compile NGINX Unit yourself on most popular Linux and Unix systems.

The code repository gives you the most recent view on the progress of the software and provides you with the latest features and updates. However, expect frequent changes if you choose to use the latest source for your project. In addition to the raw code, we regularly make versioned packages for most popular operating systems.

Here’s a quick overview of the last three months of development.

Three-Month Development Recap

NGINX Unit 0.1

The initial beta version of NGINX Unit was released on September 7, 2017, at our annual event, nginx.conf 2017. With version 0.1, you can:

• Dynamically configure any of the listener and application parameters with the RESTful API.
• Launch apps in Python and PHP without modifying the code.
• Build and run Go apps using the NGINX Unit package.
• Securely isolate the apps with Unix users and groups.
• Save and restore configuration.

NGINX Unit 0.1 was intended for initial experimentation, and the most active members of our community took advantage of that. We send thanks to everyone who tried NGINX Unit early on and posted questions, bug reports, feature requests, and code modifications in the GitHub repository.

Our initial users tried running NGINX Unit with various applications and frameworks, including WordPress, Django, and Grafana, and using PHP 5 and PHP 7, Python 2 and Python 3, and Go. NGINX Unit enabled them to take existing legacy apps, start them, and configure them in real time.

Watch the in‑depth demo of NGINX Unit 0.1, featuring system configuration, startup, application loading, and real‑time reconfiguration.

NGINX Unit 0.2

NGINX Unit 0.2 was released on October 20, 2017. This second beta version added a number of new features and bug fixes:

• Configuration persistence – Starting with version 0.2, NGINX Unit can save configuration state and restore it in case of a service restart or a server reboot. (Note that you do not make changes directly in the configuration state file. Instead, use the NGINX Unit API to make changes, and they are saved as part of the current system state in the state file.)
• Improved error messages – NGINX Unit can now display the full text details of an error in case of a misconfiguration via API. In addition to the text, NGINX Unit now can display the location of the error in the original request.
• Application timeouts – Every application can now be configured with a specific timeout setting, which ensures that application workers are restarted in case of an unexpected delay in application execution.
• New repository for documentation – The new repository is available at https://hg.nginx.org/unit-docs/ and https://github.com/nginx/unit-docs.
• New scripts – There’s a new set of packaging scripts for package maintainers.
• Bug fixes – Various bug fixes to address application crashes, a memory leak, router crashes, and abnormal request handling.

Watch the on‑demand webinar about NGINX Unit 0.2.

NGINX Unit 0.3

The NGINX Unit 0.3 beta is scheduled for release in the middle of December. The major changes and new features will include:

• Improvements in HTTP handling
• Improvements in the Go package
• The addition of Python Virtual Environments
• Code refactoring and bug fixes

Roadmap

We want you to know our plans. It’s an open project, and we share our roadmaps early. Here’s what’s coming in the upcoming release, scheduled to appear in the beginning of 2018:

• Full HTTP/1.1 support
• SSL/TLS support (update as of June 7, 2018: delayed, please stay tuned. Ed.)
• First stage of application process management features: prefork model, memory management, CPU management, timeouts, etc.
• Improvements in error reporting and logging

In the second quarter of 2018 we will fork the NGINX Unit code into two branches:

• Still branch will be recommended for production use. The still branch will have infrequent feature updates, while maintaining security fixes and bug fixes for extended periods of time. We’ll ensure consistent API operation within versions of the still branch.
• Fresh branch will contain actively developed code. New features will be implemented first in the fresh branch. We’ll encourage the use of fresh branch for projects that require new functionality on a frequent basis.

We’ll release new packages from the fresh branch every few weeks. These packages will be available for the most popular operating systems, and all installation instructions will be posted at unit.nginx.org.

This versioning system will allow us to focus on the development of new functionality while maintaining high‑quality code in both branches. This is similar to the versioning used for NGINX Open Source.

Later in 2018, we will continue development in the following areas:

• New languages – Potentially including JavaScript/Node.js, Java, .NET Core, and Ruby
• Service‑to‑service communication – Proxying HTTP traffic, load balancing, and service discovery
• Support for additional protocols – HTTP/2 and proxy of TCP traffic

Join the development effort on GitHub, contribute to the documentation, and send us feedback about your experiences.

If you wish to make NGINX Unit a part of your career and your full‑time job, join our team: NGINX is hiring C/Unix developers. Check out this page for details: https://www.nginx.com/jobs/