It’s been a year since we released Portus 2.2, but we can finally present to you the latest release of Portus. We wanted to deliver this new release much sooner, but some late-coming features changed the release schedule quite a bit, so we had to spend more time for the final release.

For this release we have improved lots of small UX details and we have fixed as many bugs as we could from the 2.2 release. You can check the changelog for more details, but in this blog post we want to highlight the following features:

Security scanning

Portus is now able to scan security vulnerabilities on your Docker images. This is done with different backends, where the stable one is CoreOS Clair. You have to enable the desired backends and then Portus will use them to fetch known security vulnerabilities for your images. The repository page will now show the vulnerabilities like this:

When you click any of the links, you will get to a page that lists the CVEs:

Note: this version of Portus supports Clair v2 specifically (current master branch is not supported).

You can read the blog post or the documentation for more info.

Background process

One of the main issues for Portus was that sometimes it took too long to complete certain critical tasks. We have moved those tasks into a separate background process. This background process resides in the bin/background.rb file, and it can be enabled for containerized deployments by setting the PORTUS_BACKGROUND environment variable to true.

The following tasks have been moved into this new process:

• Security scanning: after testing security scanning more in depth, we noticed that sometimes it could block Portus completely. This was the first task moved into this new process.
• Registry events: before creating this process, we dealt with incoming registry events in the main Portus process. The problem with this was that after getting a push event, for example, Portus had to fetch manifests, which could take quite some time. This meant that Portus got blocked in some deployments. Now Portus will simply log the event, and then the background process will process it right away (by default this process will check for events every 2 seconds).
• Registry synchronization: we have removed the crono process in favor of this new process. Hence, the code that was executed in previous releases by crono has been merged as another task of this new process. Moreover, since it can be quite dangerous, we have added some configuration options: it can be disabled; and it can be tuned with a strategy (from a riskier approach to a safer one).

Note on deployment: this new background process has to have access to the same database as the main Portus process.

You can read the new documentation page for more info.

Anonymous browsing

Portus will now allow anonymous users to search for public images. This is a configurable option which is enabled by default. You can read more about this in the documentation.

OAuth & OpenID support

Portus’ authentication logic has been extended to allow OAuth & OpenID. For OAuth you are allowed to login through the following adapters: Google, Github, Gitlab and Bitbucket. Check the config/config.yml file for more info on the exact configurable options.

Thanks a lot to Vadim Bauer (@Vad1mo) and Andrei Kislichenko (@andrew2net) for working on this!

API

An effort to design and implement an API for Portus has been started. This is useful for CLI tools like portusctl among other user cases. We do not consider the API to be in a stable state, but it is useful already. We will continue this effort in forthcoming releases.

Thanks a lot to Vadim Bauer (@Vad1mo) and Andrei Kislichenko (@andrew2net) for working on this!

Puma

The deployment of Portus has been simplified as much as possible. For this reason we have removed a lot of clutter on our official Docker image, and we have embraced best practices for deploying Ruby on Rails applications. For this reason we have set Puma as the web server for Portus.

Production deployment examples

We provide in the source code examples that illustrate how Portus is intended to be deployed on production. These examples reside in the examples directory.

Helm Chart

An official Helm Chart for deploying Portus in a Kubernetes cluster is being developed.

PostgreSQL support

Some tools like CoreOS Clair require PostgreSQL as their database. When developing support for security scanning we noticed that it was quite redundant to have two different databases running. For this reason, we have added PostgreSQL support, so you can use PostgreSQL for both Portus and Clair.

Upgrade to Ruby 2.5

Some features required an upgrade of Ruby. Since SLE 15 and Tumbleweed will most likely have Ruby 2.5 as their default version, we have anticipated this move. So, now Portus is supported for Ruby 2.5. If you try to run Portus on previous versions, it will error out during initialization.

Upgrading from 2.2

These are the things that you have to take into account before moving to 2.3:

• As explained above, Puma is now the HTTP server being used. Make sure to use the PORTUS_PUMA_TLS_KEY and the PORTUS_PUMA_TLS_CERT environment variables to point puma to the right paths for the certificates. Moreover, if you are not using the official Docker image, you will have to use the PORTUS_PUMA_HOST environment variable to tell Puma where to bind itself (in containerized deployments it will bind by default to 0.0.0.0:3000).
• The database environment variables have changed the prefix from PORTUS_PRODUCTION_ to PORTUS_DB_. Moreover, you will be able now to provide values for the following items: adapter (set it to postgresql for PostgreSQL support), port, pool and timeout. All these values are prefixed by PORTUS_DB_ as well, so for example, to provide a value for the pool you need to set PORTUS_DB_POOL.
• As stated above, set the PORTUS_BACKGROUND environment variable to true for the background process.
• You can set RAILS_SERVE_STATIC_FILES to true if you want Portus to serve the assets directly (e.g. if you don’t want a load-balancer like NGinx or HAproxy to do this).
• Portus will complain if you forgot to specify some relevant environment variables for production like PORTUS_MACHINE_FQDN_VALUE.

Finally, we are not running migrations automatically anymore as we used to do before. This is now to be done by the administrator by executing (on the Portus context in /srv/Portus or simply as part of a docker exec command):

$ portusctl exec rake db:migrate

What’s next

We have already documented the release process for 2.4. The idea from now on is to release earlier and more often. You can take a look at our planned features for 2.4 here.