Release 0.0.1 : Bill Of Material

Purpose of this Release : Sharing a finally successfully built portus:2.5 container, working on SUSE/Portus#2241

Here are the released (fixed) openSUSE Portus OCI container images :

• This release is therefore tagged 0.0.1-portus-2.5, additionally to the 0.0.1 release tag. For example, If this release was also distributing an image of clair, version 5.2.7, then we would add a third tag on this release 0.0.1-clair-5.2.7
• Tag marking the exact version of https://github.com/openSUSE/docker-containers , for which this 0.0.1 release of opensuzie/portus:2.5 is a fix : https://gitlab.com/pokus-io/opensuse/docker-containers/-/tags/DEVOPS_PORTUS_2.5_REPAIRMAN

How to use

Building a portus image

This image is used torun both the main portus server, and its background companion.

To build a release of that container, execute the following :

export SUZIE_OCI_LIBRARY_RELEASE=0.0.1
export SUZIE_OCI_LIBRARY_GIT_URI=git@github.com:pokusio/opensuzie-oci-library.git
export SUZIE_OCI_LIBRARY_GIT_URI="https://github.com/pokusio/opensuzie-oci-library.git"
export WORK_FOLDER=$(mktemp -d /tmp/suzie.oci.library.XXXXXXXX)
# define image tag
export PORTUS_RELEASE_TAG=${PORTUS_RELEASE_TAG:-'opensuzie/portus:2.5'}

git clone $SUZIE_OCI_LIBRARY_GIT_URI $WORK_FOLDER
cd $WORK_FOLDER
git checkout $SUZIE_OCI_LIBRARY_RELEASE

docker build library/portus -t $PORTUS_RELEASE_TAG

Warning : OpenSUSE repository network availability

Why this OCI image definition is not suitable for production (except for OpenSUSE internal use)

The library/portus/Dockerfile uses OpenSUSE zypper package manager, to install packages into the portus OCI container image.

I have experienced across my tests, that OpenSUSE package repositories are often unreachable across the network. I believe the OpenSUSE Team is aware of that too, internally (cf. --retries 3 in library/portus/init, https://github.com/pokusio/opensuzie-oci-library/blob/8fe1d9fb87fda6060627342f1b46959a68c85a2e/library/portus/init#L20 )

So your docker build may often fail because of that network unavailability. Don't be shy about relaunching the docker build, usually I didn't have to run it more than twice in a row, to get a success.

That being said, we there have a good improvement axis for the global devops factory for portus, and a good lesson learned :

• it is a very bad idea, to make an OCI container image build, dependent on network availabitity.
• never resolve an OCI container image build's dependencies, over a not internally managed network
• Either I setup on-premises OpenSUSE linux package repositories, inside the portus devops factory,
• or I build, package portus, and immediately install it inside its OCI image (and later use the exact same package to build a zypper package for openSUSE to distribute a standard portus package across appliances.)

Last but not least, I need a protus devops factory as fast as can be, more exactly, I need it to be always at least 10 times faster than openSUSE's, to be able to analyze, test, and fix, faster than Open SUSE team in each work cycle. That way, I can be useful to OpenSUSE 's Team, and portus users community.