Portus 2.3 released!
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:
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).
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
file, and it can be enabled for containerized deployments by setting the
PORTUS_BACKGROUND environment variable to
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.
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.
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.
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
An official Helm Chart for deploying Portus in a Kubernetes cluster is being developed.
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
PORTUS_PUMA_TLS_CERTenvironment 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_HOSTenvironment variable to tell Puma where to bind itself (in containerized deployments it will bind by default to
- The database environment variables have changed the prefix from
PORTUS_DB_. Moreover, you will be able now to provide values for the following items: adapter (set it to
postgresqlfor 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
- As stated above, set the
PORTUS_BACKGROUNDenvironment variable to
truefor the background process.
- You can set
trueif 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
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
/srv/Portus or simply as part of a
docker exec command):
$ portusctl exec rake db:migrate