Frontend system using Caddy, based on apache-frontend software release, allowing to rewrite and proxy URLs like myinstance.myfrontenddomainname.com to real IP/URL of myinstance.
Caddy Frontend works using the master instance / slave instance design. It means that a single main instance of Caddy will be used to act as frontend for many slaves.
Software type
=============
Caddy frontend is available in 4 software types:
* ``default`` : The standard way to use the Caddy frontend configuring everything with a few given parameters
* ``custom-personal`` : This software type allow each slave to edit its Caddy configuration file
* ``default-slave`` : XXX
* ``custom-personal-slave`` : XXX
About frontend replication
==========================
Slaves of the root instance are sent as a parameter to requested frontends which will process them. The only difference is that they will then return the would-be published information to the root instance instead of publishing it. The root instance will then do a synthesis and publish the information to its slaves. The replicate instance only use 5 type of parameters for itself and will transmit the rest to requested frontends.
These parameters are :
* ``-frontend-type`` : the type to deploy frontends with. (default to 2)
* ``-frontend-quantity`` : The quantity of frontends to request (default to "default")
* ``-frontend-i-state``: The state of frontend i
* ``-frontend-config-i-foo``: Frontend i will be requested with parameter foo
* ``-frontend-software-release-url``: Software release to be used for frontends, default to the current software release
* ``-sla-i-foo`` : where "i" is the number of the concerned frontend (between 1 and "-frontend-quantity") and "foo" a sla parameter.
will request the third frontend on COMP-1234. All frontends will be of software type ``custom-personal``. The second frontend will be requested with the state stopped
*Note*: the way slaves are transformed to a parameter avoid modifying more than 3 lines in the frontend logic.
**Important NOTE**: The way you ask for slave to a replicate frontend is the same as the one you would use for the software given in "-frontend-quantity". Do not forget to use "replicate" for software type. XXXXX So far it is not possible to do a simple request on a replicate frontend if you do not know the software_guid or other sla-parameter of the master instance. In fact we do not know yet the software type of the "requested" frontends. TO BE IMPLEMENTED
XXX Should be moved to specific JSON File
Extra-parameter per frontend with default::
ram-cache-size = 1G
disk-cache-size = 8G
How to deploy a frontend server
===============================
This is to deploy an entire frontend server with a public IPv4. If you want to use an already deployed frontend to make your service available via ipv4, switch to the "Example" parts.
First, you will need to request a "master" instance of Caddy Frontend with:
* A ``domain`` parameter where the frontend will be available
* A ``public-ipv4`` parameter to state which public IPv4 will be used
Those slave instances will be redirected to the "master" instance, and you will see on the "master" instance the associated proper directives of all slave instances.
Finally, the slave instance will be accessible from: https://someidentifier.moulefrite.org.
About SSL
=========
``default`` and ``custom-personl`` software type can handle specific ssl for one slave instance.
**IMPORTANT**: One Caddy can not serve more than one specific SSL site and be compatible with obsolete browser (i.e.: IE8). See http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
How to have custom configuration in frontend server - XXX - to be written
The first one is included in the end of the main apache configuration file.
The second one is included in the virtualhost of the main apache configuration file.
SlapOS will just create those two files for you, then completely forget them.
*Note*: make sure that the UNIX user of the instance has read access to those
files if you edit them.
Instance Parameters
===================
Master Instance Parameters
--------------------------
The parameters for instances are described at `instance-caddy-input-schema.json <instance-caddy-input-schema.json>`_.
Here some additional informations about the parameters listed, below:
domain
~~~~~~
Name of the domain to be used (example: mydomain.com). Sub domains of this domain will be used for the slave instances (example: instance12345.mydomain.com). It is then recommended to add a wild card in DNS for the sub domains of the chosen domain like::
*.mydomain.com. IN A 123.123.123.123
Using the IP given by the Master Instance. "domain" is a mandatory Parameter.
public-ipv4
~~~~~~~~~~~
Public ipv4 of the frontend (the one Caddy will be indirectly listening to)
port
~~~~
Port used by Caddy. Optional parameter, defaults to 4443.
plain_http_port
~~~~~~~~~~~~~~~
Port used by Caddy to serve plain http (only used to redirect to https).
Optional parameter, defaults to 8080.
Slave Instance Parameters
-------------------------
The parameters for instances are described at `instance-slave-caddy-input-schema.json <instance-slave-caddy-input-schema.json>`_.
Here some additional informations about the parameters listed, below:
path
~~~~
Only used if type is "zope".
Will append the specified path to the "VirtualHostRoot" of the zope's VirtualHostMonster.
"path" is an optional parameter, ignored if not specified.
Example of value: "/erp5/web_site_module/hosting/"
apache_custom_https
~~~~~~~~~~~~~~~~~~~
Raw Caddy configuration in python template format (i.e. write "%%" for one "%") for the slave listening to the https port. Its content will be templatified in order to access functionalities such as cache access, ssl certificates... The list is available above.
apache_custom_http
~~~~~~~~~~~~~~~~~~
Raw Caddy configuration in python template format (i.e. write "%%" for one "%") for the slave listening to the http port. Its content will be templatified in order to access functionalities such as cache access, ssl certificates... The list is available above
url
~~~
Necessary to activate cache. ``url`` of backend to use.
``url`` is an optional parameter.
Example: http://mybackend.com/myresource
domain
~~~~~~
Necessary to activate cache.
The frontend will be accessible from this domain.
``domain`` is an optional parameter.
Example: www.mycustomdomain.com
enable_cache
~~~~~~~~~~~~
Necessary to activate cache.
``enable_cache`` is an optional parameter.
ssl_key, ssl_crt, ssl_ca_crt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SSL certificates of the slave.
They are optional.
Functionalities for Caddy configuration
---------------------------------------
In the slave Caddy configuration you can use parameters that will be replaced during instantiation. They should be entered as python templates parameters ex: ``%(parameter)s``:
* ``cache_access`` : url of the cache. Should replace backend url in configuration to use the cache
* ``access_log`` : path of the slave error log in order to log in a file.
* ``error_log`` : path of the slave access log in order to log in a file.
* ``ssl_key``, ``ssl_crt``, ``ssl_ca_crt``, ``ssl_crs`` : paths of the certificates given in slave instance parameters
Examples
========
Here are some example of how to make your SlapOS service available through an already deployed frontend.
Simple Example (default)
------------------------
Request slave frontend instance so that https://[1:2:3:4:5:6:7:8]:1234 will be
redirected and accessible from the proxy::
instance = request(
software_release=caddy_frontend,
software_type="RootSoftwareInstance",
partition_reference='my frontend',
shared=True,
partition_parameter_kw={
"url":"https://[1:2:3:4:5:6:7:8]:1234",
}
)
Zope Example (default)
----------------------
Request slave frontend instance using a Zope backend so that
https://[1:2:3:4:5:6:7:8]:1234 will be redirected and accessible from the
proxy::
instance = request(
software_release=caddy_frontend,
software_type="RootSoftwareInstance",
partition_reference='my frontend',
shared=True,
partition_parameter_kw={
"url":"https://[1:2:3:4:5:6:7:8]:1234",
"type":"zope",
}
)
Advanced example
-----------------
Request slave frontend instance using a Zope backend, with Varnish activated,
listening to a custom domain and redirecting to /erp5/ so that
https://[1:2:3:4:5:6:7:8]:1234/erp5/ will be redirected and accessible from
the proxy::
instance = request(
software_release=caddy_frontend,
software_type="RootSoftwareInstance",
partition_reference='my frontend',
shared=True,
partition_parameter_kw={
"url":"https://[1:2:3:4:5:6:7:8]:1234",
"enable_cache":"true",
"type":"zope",
"path":"/erp5",
"domain":"mycustomdomain.com",
}
)
Simple Example
---------------
Request slave frontend instance so that https://[1:2:3:4:5:6:7:8]:1234 will be::
Where ``{public ip}`` is the public IP of your server, or at least the LAN IP to where your NAT will forward to, and ``{listening ip}`` is the private ipv4 (like 10.0.34.123) that the instance is using and sending as connection parameter.
Solution 2 (IPv6 only)
----------------------
It is also possible to directly allow the service to listen on 80 and 443 ports using the following command::
Generally things to be done with ``caddy-frontend``:
* ``apache-ca-certificate`` shall be merged with ``apache-certificate``
* (new) ``type:websocket`` slave
* ``type:eventsource``:
* **Jérome Perrin**: *For event source, if I understand https://github.com/mholt/caddy/issues/1355 correctly, we could use caddy as a proxy in front of nginx-push-stream . If we have a "central shared" caddy instance, can it handle keeping connections opens for many clients ?*
* ``ssl_ca_crt``
* ``prefer-gzip-encoding-to-backend`` (requires writing middleware plugin for Caddy)::
* ``ssl_proxy_ca_crt`` for ``ssl_proxy_verify``, this is related to bug https://github.com/mholt/caddy/issues/1550, proposed solution `just adding your CA to the system's trust store`
* ``check-error-on-caddy-log`` like ``check-error-on-apache-log``
* cover test suite like resilient tests for KVM and prove it works the same way as Caddy
* have ``caddy-frontend`` specific parameters, with backward compatibility to ``apache-frontend`` ones (like ``apache_custom_http`` --> ``caddy_custom_http``)
* change ``switch-softwaretype`` to way how ``software/erp5`` does, which will help with dropping jinja2 template for ``caddy-wrapper``, which is workaround for current situation https://lab.nexedi.com/nexedi/slapos/merge_requests/312#note_62678
* use `slapos!326 <https://lab.nexedi.com/nexedi/slapos/merge_requests/326>`_, and especially `note about complex restart scenarios <https://lab.nexedi.com/nexedi/slapos/merge_requests/326#note_60198>`_, instead of self-developed graceful restart scripts
* move out `test/utils.py` and use it from shared python distribution
* provide various tricks for older browsers::
# The following directives modify normal HTTP response behavior to
# handle known problems with browser implementations.
* reduce the time of configuration validation (in ``instance-apache-frontend.cfg`` sections ``[configtest]``, ``[caddy-configuration]``, ``[nginx-configuration]``), as it is not scalable on frontend with 2000+ slaves (takes few minutes instead of few, < 5, seconds), issue posted `upstream <https://github.com/mholt/caddy/issues/2220>`_
* drop ``6tunnel`` and use ``bind`` in Caddy configuration, as soon as multiple binds will be possible, tracked in upstream `bind: support multiple values <https://github.com/mholt/caddy/pull/2128>`_ and `ipv6: does not bind on ipv4 and ipv6 for sites that resolve to both <https://github.com/mholt/caddy/issues/864>`_
Things which can't be implemented:
* use certificates valid forever in tests using `cryptography <https://pypi.org/project/cryptography/>`_, with `available example <https://lab.nexedi.com/nexedi/caucase/blob/1c9b9b6dfb062551549566d9792a1608f5e0c2d9/caucase/ca.py#L460-552>`_
* **REASON**: it is impossible to generate certificate without `Not Valid After`, even with `cryptography <https://pypi.org/project/cryptography/>`_
"description":"Raw http configuration in python template format. Your site will be rejected if you use it without notification and approval of frontend administrators",
"textarea":true,
"title":"HTTP configuration",
"type":"string"
},
"apache_custom_https":{
"default":"",
"description":"Raw https configuration in python template format. Your site will be rejected if you use it without notification and approval of frontend administrators",
"textarea":true,
"title":"HTTPS configuration",
"type":"string"
},
"custom_domain":{
"description":"Custom Domain to use for the website",
"description":"Provide default path to redirect user to when user access / (the site root)",
"title":"type:zope Default Path",
"type":"string"
},
"disable-no-cache-request":{
"default":"false",
"description":"If set to true, Cache-Control and Pragma requests headers will not be sent to cache and backend servers. This prevents clients from bypassing cache when enable_cache is true",
"description":"If set to true, Via response headers will not be sent to client",
"enum":[
"false",
"true"
],
"title":"enable_cache: Disable 'Via' headers from cache",
"type":"string"
},
"disabled-cookie-list":{
"default":"",
"description":"[NOT Implemented] List of Cookies separated by space that will not be sent to cache and backend servers. This is especially useful to discard analytics tracking cookies when using Vary: Cookie cache headers",
"title":"[NOT Implemented] Disabled Cookies",
"type":"string"
},
"enable-http2":{
"default":"true",
"description":"Use HTTP2 Protocol for the site",
"enum":[
"true",
"false"
],
"title":"Enable HTTP2 Protocol",
"type":"string"
},
"enable_cache":{
"default":"false",
"description":"If set to true, http caching server (Apache Traffic Server) will be used between frontend Caddy and backend",
"enum":[
"false",
"true"
],
"title":"Enable Cache",
"type":"string"
},
"https-only":{
"default":"false",
"description":"If set to true, http requests will be redirected to https",
"enum":[
"false",
"true"
],
"title":"HTTPS Only",
"type":"string"
},
"https-url":{
"description":"HTTPS Url of the backend if it is diferent from url parameter",
"pattern":"^(http|https|ftp)://",
"title":"HTTPS Backend URL",
"type":"string"
},
"monitor-ipv4-test":{
"default":"",
"description":"IPv4 Address for the frontend keep monitoring with ping",
"title":"IPv4 Address to Monitor Packet Lost",
"type":"string"
},
"monitor-ipv6-test":{
"default":"",
"description":"IPv6 Address for the frontend keep monitoring with ping6 (without brackets)",
"title":"IPv6 Address to Monitor Packet Lost",
"type":"string"
},
"path":{
"default":"",
"description":"Path to proxy to in the backend",
"title":"type:zope Backend Path",
"type":"string"
},
"prefer-gzip-encoding-to-backend":{
"default":"false",
"description":"[NOT Implemented] If set to true, frontend will rewrite Accept-Encoding request header to simply 'gzip' for all variants of Accept-Encoding containing 'gzip', in order to maximize cache hits for resources cached with Vary: Accept-Encoding when enable_cache is used",
"enum":[
"false",
"true"
],
"title":"[NOT Implemented] Prefer gzip Encoding for Backend",
"type":"string"
},
"re6st-optimal-test":{
"default":"",
"description":"IPv6 and IPv6 Address for the frontend test if re6st is on the optimal status (use ipv6,ipv4)",
"title":"IPv6 and IPv4 Address to test Re6st",
"type":"string"
},
"server-alias":{
"default":"",
"description":"Server Alias List separated by space",
"title":"Server Alias",
"type":"string"
},
"ssl-proxy-verify":{
"default":"false",
"description":"[NOT Implemented] If set to true, Backend SSL Certificates will be checked and frontend will refuse to proxy if certificate is invalid",
"description":"Type of slave. If redirect, the slave will redirect to the given url. If zope, the rewrite rules will be compatible with Virtual Host Monster. Implemented are default, zope and redirect, not implemneted are notebook and eventsource.",
"enum":[
"",
"zope",
"redirect",
"notebook",
"eventsource"
],
"title":"Backend Type",
"type":"string"
},
"url":{
"description":"Url of the backend",
"pattern":"^(http|https|ftp)://",
"title":"Backend URL",
"type":"string"
},
"virtualhostroot-http-port":{
"default":80,
"description":"Port where http requests to frontend will be redirected.",
"title":"type:zope virtualhostroot-http-port",
"type":"integer"
},
"virtualhostroot-https-port":{
"default":443,
"description":"Port where https requests to frontend will be redirected.",
