The vendor stylizes it as NGINX.
Previously docs capitalized it as either NGINX, Nginx or nginx. nginx
was the preferred capitalization before commercialization of the
software.
Signed-off-by: Ville Ojamo <git2233+ceph@ojamo.eu>
======================
In Ceph releases beginning with Tentacle, the ``mgmt-gateway`` service introduces a new design for Ceph applications
-based on a modular, service-based architecture. This service, managed by cephadm and built on top of nginx
+based on a modular, service-based architecture. This service, managed by cephadm and built on top of NGINX
(an open-source, high-performance web server), acts as the new front-end and single entry point to the
Ceph cluster. The ``mgmt-gateway`` provides unified access to all Ceph applications, including the Ceph dashboard
-and monitoring stack. Employing nginx enhances security and simplifies access management due to its robust
+and monitoring stack. Employing NGINX enhances security and simplifies access management due to its robust
community support and high-security standards. The ``mgmt-gateway`` service acts as a reverse proxy that routes
requests to the appropriate Ceph application instances.
Benefits of the mgmt-gateway service
====================================
-* ``Unified Access``: Consolidated access through nginx improves security and provides a single entry point to services.
+* ``Unified Access``: Consolidated access through NGINX improves security and provides a single entry point to services.
* ``Improved user experience``: Users no longer need to know where each application is running (IP/host).
-* ``High Availability for dashboard``: nginx HA mechanisms are used to provide high availability for the Ceph dashboard.
-* ``High Availability for monitoring``: nginx HA mechanisms are used to provide high availability for monitoring.
+* ``High Availability for dashboard``: NGINX HA mechanisms are used to provide high availability for the Ceph dashboard.
+* ``High Availability for monitoring``: NGINX HA mechanisms are used to provide high availability for monitoring.
Security enhancements
=====================
High availability enhancements
==============================
-nginx HA mechanisms are used to provide high availability for all the Ceph management applications including the Ceph dashboard
+NGINX HA mechanisms are used to provide high availability for all the Ceph management applications including the Ceph dashboard
and monitoring stack. In case of the Ceph dashboard, users no longer need to know where the active manager is running.
``mgmt-gateway`` handles manager failover transparently and redirects the user to the active manager. In case of the
monitoring ``mgmt-gateway`` takes care of handling HA when several instances of Prometheus, Alertmanager or Grafana are
Multiple ``mgmt-gateway`` instances can be deployed in an active/standby configuration using keepalived
for seamless failover. The ``oauth2-proxy`` service can be deployed as multiple stateless instances,
-with nginx acting as a load balancer across them using a round-robin strategy. This setup removes
+with NGINX acting as a load balancer across them using a round-robin strategy. This setup removes
single points of failure and enhances the resilience of the entire system.
In this setup, the underlying internal services follow the same high availability mechanism. Instead of
Default images
~~~~~~~~~~~~~~
-The ``mgmt-gateway`` service internally makes use of nginx reverse proxy. The following container image is used by default:
+The ``mgmt-gateway`` service internally makes use of NGINX reverse proxy. The following container image is used by default:
::
High availability
=================
In general, `oauth2-proxy` is used in conjunction with the `mgmt-gateway`. The `oauth2-proxy` service can be deployed as multiple
-stateless instances, with the `mgmt-gateway` (nginx reverse-proxy) handling load balancing across these instances using a round-robin strategy.
+stateless instances, with the `mgmt-gateway` (NGINX reverse-proxy) handling load balancing across these instances using a round-robin strategy.
Since oauth2-proxy integrates with an external identity provider (IDP), ensuring high availability for login is managed externally
and not the responsibility of this service.
.. contents::
-This feature adds to RGW the ability to securely cache objects and offload the workload from the cluster, using Nginx.
-After an object is accessed the first time it will be stored in the Nginx cache directory.
+This feature adds to RGW the ability to securely cache objects and offload the workload from the cluster, using NGINX.
+After an object is accessed the first time it will be stored in the NGINX cache directory.
When data is already cached, it need not be fetched from RGW. A permission check will be made against RGW to ensure the requesting user has access.
-This feature is based on the Nginx modules ``ngx_http_auth_request_module`` and `nginx-aws-auth-module <https://github.com/kaltura/nginx-aws-auth-module>`_, and OpenResty for Lua capabilities.
+This feature is based on the NGINX modules ``ngx_http_auth_request_module`` and `nginx-aws-auth-module <https://github.com/kaltura/nginx-aws-auth-module>`_, and OpenResty for Lua capabilities.
Currently this feature will cache only AWSv4 requests (only S3 requests), caching-in the output of the first GET request
and caching-out on subsequent GET requests, passing through transparently PUT, POST, HEAD, DELETE and COPY requests.
There are 2 new APIs for this feature:
- **Auth API:** The cache uses this to validate that a user can access the cached data.
-- **Cache API:** Adds the ability to override the ``Range`` header securely so that Nginx can use its own `smart cache <https://www.nginx.com/blog/smart-efficient-byte-range-caching-nginx/>`_ on top of S3.
+- **Cache API:** Adds the ability to override the ``Range`` header securely so that NGINX can use its own `smart cache <https://www.nginx.com/blog/smart-efficient-byte-range-caching-nginx/>`_ on top of S3.
Using this API gives the ability to read ahead objects when client is asking a specific range from the object.
- On subsequent accesses to the cached object, Nginx will satisfy requests for already-cached ranges from the cache. Uncached ranges will be read from RGW (and cached).
+ On subsequent accesses to the cached object, NGINX will satisfy requests for already-cached ranges from the cache. Uncached ranges will be read from RGW (and cached).
Auth API
~~~~~~~~
During this flow the RGW will override the ``Range`` header.
-Using Nginx with RGW
+Using NGINX with RGW
--------------------
Download the source of OpenResty:
wget https://openresty.org/download/openresty-1.15.8.3.tar.gz
-Use git to clone the Nginx AWS authentication module:
+Use git to clone the NGINX AWS authentication module:
.. prompt:: bash $
sudo gmake install
sudo ln -sf /usr/local/openresty/bin/openresty /usr/bin/nginx
-Put in-place your Nginx configuration files and edit them according to your environment:
+Put in-place your NGINX configuration files and edit them according to your environment:
-Example Nginx configuration files are available at
+Example NGINX configuration files are available at
https://github.com/ceph/ceph/tree/main/examples/rgw/rgw-cache
- ``nginx.conf`` should go to ``/etc/nginx/nginx.conf``.
radosgw-admin user create --uid=cacheuser --display-name="cache user" --caps="amz-cache=read" --access-key <access> --secret <secret>
-It is possible to use `Nginx slicing <https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/#byte-range-caching>`_ which is suitable for streaming purposes.
+It is possible to use `NGINX slicing <https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/#byte-range-caching>`_ which is suitable for streaming purposes.
To enable slicing you should use ``nginx-slicing.conf`` instead of ``nginx-default.conf``.
If you do not want to use prefetch caching, it is possible to replace ``nginx-default.conf`` with ``nginx-noprefetch.conf``.
-If prefetch caching is disabled Nginx will cache each range request separately and possible overlap in the range requests will be fetched more than once. For example, if a client is sending a range request of 0-4095 and then 0-4096 both requests are fetched completely from RGW.
+If prefetch caching is disabled NGINX will cache each range request separately and possible overlap in the range requests will be fetched more than once. For example, if a client is sending a range request of 0-4095 and then 0-4096 both requests are fetched completely from RGW.
-Run Nginx (OpenResty):
+Run NGINX (OpenResty):
.. prompt:: bash #
===========================
If the ``radosgw`` process dies, you will normally see a 500 error
-from the web server (apache, nginx, etc.). In that situation, simply
+from the web server (Apache, NGINX, etc.). In that situation, simply
restarting radosgw will restore service.
To diagnose the cause of the crash, check the log in ``/var/log/ceph``
* A new cephadm-managed ``mgmt-gateway`` service provides a single, TLS-terminated
entry point for Ceph management endpoints such as the Dashboard and the monitoring
- stack. The gateway is implemented as an nginx-based reverse proxy that fronts Prometheus,
+ stack. The gateway is implemented as an NGINX-based reverse proxy that fronts Prometheus,
Grafana, and Alertmanager, so users no longer need to connect to those daemons directly or
know which hosts they run on. When combined with the new ``oauth2-proxy`` service, which
integrates with external identity providers using the OpenID Connect (OIDC) / OAuth 2.0
protocols, the gateway can enforce centralized authentication and single sign-on (SSO) for
both the Ceph Dashboard and the rest of the monitoring stack.
* High availability for the Ceph Dashboard and the Prometheus-based monitoring stack is now
- provided via the cephadm-managed ``mgmt-gateway``. nginx high-availability mechanisms allow
+ provided via the cephadm-managed ``mgmt-gateway``. NGINX high-availability mechanisms allow
the mgmt-gateway to detect healthy instances of the Dashboard, Prometheus, Grafana, and Alertmanager,
route traffic accordingly, and handle manager failover transparently. When deployed with a virtual
IP and multiple ``mgmt-gateway`` instances, this architecture keeps management access available
projects / ceph.git / commitdiff