Spec to improve containerized Apache WSGI footprint
Change-Id: I96621a7f8234dc126eff0b9ae5a3a109a566459f Signed-off-by: Bogdan Dobrelya <bogdando@mail.ru>
This commit is contained in:
Bogdan Dobrelya
parent
50365e46dc
commit
54b133197c
|
|
@ -0,0 +1,156 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=========================================
|
||||
Improve WSGI Apps Footrpint in Containers
|
||||
=========================================
|
||||
|
||||
https://blueprints.launchpad.net/tripleo/+spec/compact-wsgi-footprint
|
||||
|
||||
OpenStack API service workers in TripleO are isolated in Python interpreters
|
||||
instantiated by mod WSGI of their own Apache servers, which is a share nothing
|
||||
execution model.
|
||||
|
||||
This specification proposes an alternative deployment and configuration method
|
||||
for such WSGI applications. That method improves memory footrpint of those, by
|
||||
the price of the failure domain increased to the Apache server(s) that controll
|
||||
it. That layout may become a default one, eventually, and can be applied on a
|
||||
service-by-service case.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
Isolated Apache servers in containers make their WSGI applications consuming
|
||||
an extended memory footprint. Containers not cooperate but compete for more and
|
||||
more RAM for its individual cache among all python interpreter processes there.
|
||||
More details can be found in `[0]`_.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Provide alternative deployment methods for Apache in containers. Wrap its WSGI
|
||||
applications with podman-py `[1]`_ to run those in containers, but share cache
|
||||
and its Python interpreters.
|
||||
|
||||
Depending on a use case, WSGI applications can be segregated by its main
|
||||
service, like Nova, or Neutron, within an Apache container dedicated for its
|
||||
service-group. Or share a global context within a single web-server.
|
||||
|
||||
Open question: shall we share a python interpreter of the application group in
|
||||
order to have its process groups sharing memory/cache? If we start process
|
||||
groups in distinct containers, would they still share nothing? See `[2]`_.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
According to `[2]`_, WSGI applications within the same application group will
|
||||
execute within the context of the same Python sub interpreter. In each distinct
|
||||
process of a named group of processes, there will be a separate sub interpreter
|
||||
instance of same name.
|
||||
|
||||
For example, `Nova`, `Cinder` etc., can become either `WSGIProcessGroup`, or
|
||||
`WSGIApplicationGroup` groups of its service-scoped, or global Python context.
|
||||
|
||||
TripleO could support both proposed Apache deployment layouts. Wthereis the
|
||||
global context aims compact undercloud/standalone/low-memory footprints with
|
||||
APIs failure domain as large as its common web-server is. And those with a
|
||||
per-service apache server aiming HA envs with failure domains reduced to a
|
||||
service.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
* Change nothing.
|
||||
* Switch to NGINX and/or uWSGI.
|
||||
* Use a single Apache container for each controller, or decontainerize Apache.
|
||||
But keep its WSGI apps for API workers wrapped in containers with podman-py
|
||||
as this spec suggests. Then VirtHost configs may use these for segregation:
|
||||
``WSGIApplicationGroup %{ENV:SVC}``, ``SetEnv SVC Nova``. Or use a ``GLOBAL``
|
||||
app group and ``WSGIProcessGroup %{ENV:SVC}`` for a single-node envs.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
A compromised Apache web-server would also compromise its WSGI applications.
|
||||
|
||||
Upgrade Impact
|
||||
--------------
|
||||
|
||||
No special upgrade procedures required. Apache and API containers would
|
||||
catch up deployment method changes by the standard for framework meanings.
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
No deployer impact (the new deployment method of Apache is not users-faced).
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Depending on the global (per a host) or a service-based scoping
|
||||
of deployed Apache server(s), memory footprint would become drastically
|
||||
decreased, while improved caching among Python WSGI processes would
|
||||
benefit undercloud, standalone and multi-node overcloud setups.
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
|
||||
No deployer impact (the new deployment method of Apache provides no new
|
||||
configurable switches).
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
No developer impact aside of maintaining podman-py wrappers of WSGI scripts.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
* Bogdando - Bogdan Dobrelya
|
||||
|
||||
Other contributors:
|
||||
* ???
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Implement podman-py wrapper what starts WSGI applications in containers.
|
||||
* Provide switch to control the deployment mode for Apache in containers.
|
||||
* Default OpenStack APIs to the service-scoped containerized Apache servers.
|
||||
* Switch Undercloud and Standalone deployments to the global Apache container.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
External dependencies include ``podman-remote`` and ``python-podman-api``
|
||||
that provide Python Podman API (podman-py `[1]`_) via Unix Sockets. The latter
|
||||
relies on Systemd socket activation feature. These packages are already
|
||||
available via Centos 8 AppStream and container-tools modules.
|
||||
|
||||
Unfortunately, podman-py won't be available downstream until RHEL 8.5, which
|
||||
means that this feature cannot be backported.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
No special test coverage is required.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
No documentation impact, since the alternative deployment method is internal to
|
||||
TripleO framework.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. _[0]: -- https://etherpad.opendev.org/p/containerized-memory-sharing
|
||||
.. _[1]: -- https://github.com/containers/podman-py
|
||||
.. _[2]: -- https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIApplicationGroup.html
|
||||
Loading…
Reference in New Issue