Simplify the usage of certs, certbot and nginx


#1

See also the issue in the lab.

It would be convenient to have a single role (instead of the three below) providing the following feature: using letsencrypt certificates in production and for testing, in an nginx server.

User stories:

  • As a developer I want to install the letsencrypt staging certs only, in a host that is a client of a letsencrypt enabled service in a staging environment:
    role: nginx-letsencrypt
    vars:
          client: true
          staging: true or false
  • As a sysadmin I want to install a letsencrypt enabled nginx server for mydomain.com
    role: nginx-letsencrypt
    vars:
          mail: mymail@foo.com
          domain: mydomain.com
          staging: true or false
  • As a sysadmin I want to install a letsencrypt enabled nginx reverse proxy, configured to handle websockets:
    role: nginx-letsencrypt
    vars:
          email: mymail@foo.com
          reverse_proxy: mydomain.net => backend:8000
          staging: true or false

    role: nginx-letsencrypt
    vars:
          email: mymail@foo.com
          reverse_proxy: otherdomain.net => backend:8000
          staging: true or false

The three roles that currently exist are are:

  • certs role which installs the fake letsencrypt certificates when using the staging environment, convenient for testing so we don’t run into the throttling limits of production certificates
  • certbot role which obtains letsencrypt certificates and installs them in a previously installed nginx server
  • jdauphant.nginx used to install a web server or a reverse proxy to a service so it can be used by certbot to install a letsencrypt certificate

These three roles are used together, as can be seen at:

In all cases the certs role is used in the molecule playbook (see the weblate molecule playbook for instance) and not in the production playbook. The tests rely on the letsencrypt staging environment certificates to run otherwise curl/requests fail because the certificate is unknown (see the chat tests for instance).


#2

Examples of import_role usage, courtesy @pilou


#3

There also is a need to add content to the nginx server definition like the one for icinga2

  location ~ ^/icingaweb2/index\.php(.*)$ {
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /usr/share/icingaweb2/public/index.php;
    fastcgi_param ICINGAWEB_CONFIGDIR /etc/icingaweb2;
    fastcgi_param REMOTE_USER $remote_user;
  }
  
  location ~ ^/icingaweb2(.+)? {
  	alias /usr/share/icingaweb2/public;
  	index index.php;
  	try_files $1 $uri $uri/ /icingaweb2/index.php$is_args$args;
  }
  location / {
    return 302 /icingaweb2;
  }

#4

For the record the implementation led to the letsencrypt-nginx role which is now used by all services.