Assets

Highlight

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.

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

Background process

One of the main issues for Portus was that sometimes it took too long to complete certain critical tasks. For this release we have moved these 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 when showing the main page for repositories. This was the first task moved into this new process. Commit: e0f7d53cb2b2.

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). This task can be disabled as documented here. Commit: 6a4f7d7dca60.

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). All this has been documented in its documentation page. Commit: ced9b46a9064.

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

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 Connect support

Portus' authentication logic has been extended to allow OAuth & OpenID Connect. 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!

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. Some observations:

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).

Use the new PORTUS_DB_ environment variable prefix instead of the old PORTUS_PRODUCTION_ one for database options. Moreover, in the database you can now specify more options like PORTUS_DB_POOL for stating the DB pool.

Portus will complain if you provide old environment variables like PORTUS_PRODUCTION_DATABASE, or if you forgot to specify some relevant environment variables for production like PORTUS_MACHINE_FQDN_VALUE. Commit: 06a405c4f5fd.

Helm Chart

An official Helm Chart for deploying Portus in a Kubernetes cluster is being developed. It is expected to be released soon after this release.

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 (commit: ea02cab5c822).

Upgrading

In this section we want to detail some things that you might want to take into account when upgrading 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.

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):

Deprecations

Some configuration options that were soft-deprecated in 2.2 will now raise a DeprecationError. These are:

The expiration time of the JWT token can no longer be expressed as a string with a format: x.minutes. You have to provide now an integer representing the minutes for the jwt_expiration_time configurable option. Users that have not touched this option since the 2.1 times will have to change this.

The jwt_expiration_time option was moved to registry.jwt_expiration_time in 2.2. Now, if you continue to provide the former rather than the latter, you'll get a DeprecationError exception.

Besides this, Portus will also raise a DeprecationError during initialization in the case you provided the prefix PORTUS_PRODUCTION_ for database configurable options instead of PORTUS_DB_.

Finally, portusctl as provided by Portus is getting deprecated in favor of openSUSE/portusctl. This new portusctl has been built from scratch for the following reasons:

Since 2.3 our main focus is the support containerized deployments. Therefore, portusctl's main task to setup the installation didn't make sense anymore.

Moreover, from experience we noticed lots of corner cases where the old portusctl was simply not effective.

With the introduction of the API, we wanted to re-purpose the tool to be more similar to tools like kubectl for Kubernetes. That is, a CLI interface to the API that administrators can use with ease.

Packaging

Lots of issues regarding packaging were fixed. We want to highlight the following commits: