Monday, May 7, 2018

Doing major version upgrades of OTRS docker containers

One missing feature of my OTRS docker containers was automating a major version upgrade without any manual configuration. It should be as easy to do as it is launching it. Minor versions upgrades are easy: just pull the new image and restart your containers. 

For example, if you are running OTRS 6.0.1 and want to upgrade to the latest version (6.0.7 ATM):
sudo docker-compose -f docker-compose-prod.yml pull
sudo docker-compose -f docker-compose-prod.yml stop
sudo docker-compose -f docker-compose-prod.yml rm -f -v
sudo docker-compose -f docker-compose-prod.yml up   
That's it. Minor version upgrades only involve security and bug fixes, so there are no database schema or module upgrades needed, the new image contains the latest OTRS software packages with the latest fixes.

Major version upgrades need much more work done, as mentioned before, additional to updating the software components there are others components that need updating too:
  • Database schema
  • Cronjobs
  • Configuration rebuild
  • Cache delete
So I have added a new major version upgrade feature controlled by the environment variable OTRS_UPGRADE=yes. When this variable is set in the docker-compose file, the major version upgrade process will be started.  Also modify your docker-compose file and make sure that the OTRS docker image has the latest tag (juanluisbaptiste/otrs:latest) on both the otrs and its data container. 

Then like with the minor version upgrade, pull the new OTRS image and restart your containers:
sudo docker-compose -f docker-compose-prod.yml pull
sudo docker-compose -f docker-compose-prod.yml stop
sudo docker-compose -f docker-compose-prod.yml rm -f -v
sudo docker-compose -f docker-compose-prod.yml up   
The upgrade procedure will pause the OTRS container boot process for 10 seconds to give the user the chance to cancel the upgrade. 

The first thing done by the upgrade process is to do a backup of the current version before starting. The backup will be stored on /backups (don't forget to map that directory to one in your host so you can access it).

Then it will follow the official upgrade instructions: 
  • Run database upgrade scripts
  • Upgrade cronjobs
  • Upgrade modules 
  • Fix file permissions 
  • Rebuild OTRS configuration and delete cache.
The software components were updated when pulling the new  mage. Also, there was no need to stop/start services as the upgrade occurs on container bootup, which means no services are started yet. Also remember to remove the OTRS_UPGRADE variable from the docker-compose file afterwards.

You could use this container to upgrade from non docker installations too, btw.

Note:
This feature was added to both OTRS 5 & 6 images, so upgrades from OTRS 4 can be preformed too.


WARNING: this feature is experimental and is still in heavy testing, use at your own risk !!

Wednesday, May 2, 2018

Ansible installation role for BigBlueButton



I was looking for an ansible role to install BigBlueButton with SSL support, but it seems there's not much roles out there for this. Searching I the Internet the most complete one I found was this one, but it was outdated (last commit from two years ago) and broken, and the PR to fix it was from almost a year ago with no answer from the developer, so I figured it was abandoned and forked it.

Additional to fixing the broken stuff, this fork has the following additional features:
  • Installs latest BigBlueButton stable version, currently 1.1, but it will be updated to 2.0 when it comes out of beta.
  • Installation behind a firewall (NAT setup support).
  • Automatic SSL configuration using LetsEncrypt certificates.
  • Optionally installs the bbb-demo and bbb-check packages.

Lets see an example playbook to do a BigBlueButton install with SSL support:
---
- hosts: bbb
  remote_user: ansible
  become: True
  become_user: root
  gather_facts: True
  roles:
    - role: ansible-bigbluebutton
      bbb_server_name: bbb.example.com
      bbb_configure_ssl: True
      bbb_ssl_email: foo@bar.com
Replace bbb_server_name with your server's hostname and bbb_ssl_email with your email address for the LetsEncrypt certificate generation, that's it. 

The role will install BigBlueButton according to the official installation instructions, generate SSL certificates using LetsEncrypt, and configure BigBlueButton to use those certificates. Remember, your hostname has to resolve to a public IP address, if not then LetsEncrypt certificate generation will not work.

If your server is behind a firewall the variable bbb_configure_nat: True needs to be added to the playbook to enable NAT configuration:
---
- hosts: bbb
  remote_user: ansible
  become: True
  become_user: root
  gather_facts: True
  roles:
    - role: ansible-bigbluebutton
      bbb_server_name: bbb.example.com
      bbb_configure_ssl: True
      bbb_ssl_email: foo@bar.com
      bbb_configure_nat: True
This will reconfigure BigBlueButton components to use the local IP address instead of the one the server publicly resolves to. 

If you want to install the demo package or the health check package you can use bbb_install_demo: True and bbb_install_check: True respectevly to install them.

There is still some missing stuff I want to do before I consider this role complete:
  • Push it to Ansible Galaxy.
  • Install the new greenlight interface to create meetings.
  • Install the new HTML5 client for testing.

As an alternative to greenlight there's another project called Mconf-web, which is a web portal from were you can create public and private rooms that have their own videoconference room in the BigBlueButton server. Check my mconf-web docker container for an easy way to use it.