Release 0.0.2
: 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 :
Image name | Component of | Notes |
---|---|---|
opensuzie/portus:2.5 |
portus |
OpenSUSE Team publishes that with generic mame opensuse/portus:2.5 |
- This release is therefore tagged
0.0.2-portus-2.5
, additionally to the0.0.2
release tag. For example, If this release was also distributing an image ofclair
, version5.2.7
, then we would add a third tag on this release0.0.2-clair-5.2.7
- Tag marking the exact version of https://github.com/openSUSE/docker-containers , for which this
0.0.2
release ofopensuzie/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 to run 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.2
export [email protected]: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
Container Image portus:2.5
Versions of ruby
, gem
, bundle
, bundler
, and rake
In Official opensuse/portus:2.5
executable | version | path on openSUSE Leap Distrib. |
---|---|---|
ruby |
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-gnu] |
/usr/bin/ruby.ruby2.6 |
gem |
3.0.3 |
/usr/bin/gem.ruby2.6 |
bundle |
1.17.2 |
/usr/bin/bundle.ruby2.6 |
bundler |
1.17.2 |
/usr/bin/bundler.ruby2.6 |
rake |
12.3.2 |
/usr/bin/rake.ruby2.6 |
rails |
5.2.3 |
/srv/Portus/bin/rails |
In Pokus!Portus' opensuzie/portus:2.5
, as of release 0.0.2-portus-2.5
:
executable | version | path on openSUSE Leap Distrib. |
---|---|---|
ruby |
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-gnu] |
/usr/bin/ruby.ruby2.6 |
gem |
3.0.3 |
/usr/bin/gem.ruby2.6 |
bundle |
1.16.4 |
/usr/bin/bundle.ruby2.6 |
bundler |
1.16.4 |
/usr/bin/bundler.ruby2.6 |
rake |
12.3.2 |
/usr/bin/rake.ruby2.6 |
rails |
5.2.3 |
/srv/Portus/bin/rails |
- how to check those values in running containers
jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && /usr/bin/gem.ruby2.6 --version" /srv/Portus 3.0.3 jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && /usr/bin/ruby.ruby2.6 --version" /srv/Portus ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-gnu] jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && /usr/bin/bundle.ruby2.6 --version" /srv/Portus Bundler version 1.17.2 jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && /usr/bin/bundler.ruby2.6 --version" /srv/Portus Bundler version 1.17.2 jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && /usr/bin/rake.ruby2.6 --version" /srv/Portus rake, version 12.3.2 jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && /usr/bin/rails.ruby2.6 --version" /srv/Portus bash: /usr/bin/rails.ruby2.6: No such file or directory jibl@poste-devops-typique:~$ docker exec -it compose_background_1 bash -c "cd /srv/Portus && pwd && rails --version" /srv/Portus bash: rails: command not found jibl@poste-devops-typique:~$
Warning : the fix is not enough
Why this OCI image definition is not suitable for production
- One part of the fix I applied, involves the setup of two symlinks.
- Setting up those symlinks, fixes the
ruby
environment installation and configuration, inside the container. - The
ruby
environment is installed and configured in the container, using anOpenSUSE
/zypper
linux package (like a*.deb
package forDebian
) - Therefore, to distribute an
opensuse/portus:2.5
, and not break or change its distribution policy (installing software in OpenSUSE-based containers, using OpenSUSE package repositories) , Open SUSE must repair theruby2.6
package distributed in theobs://devel:languages:ruby/openSUSE_Leap_15.1 ruby
repository. - Then OpenSUSE Team might be a bit surprised that this package is broken. Nevertheless, the reader and the OpenSUSE team will read and check for themselves, that the production grade fix to apply is the analog of this fix for debian based ruby containers. This fix, transposed from
debian to
OpenSUSE Leap` :- Invovles, I think, proposing a
rubygems-integration
, released by OpenSUSE, and forOpenSUSE Leap
, like there is one, forDebian
, cf. rubygems/rubygems#2180 (comment) and https://bugs.launchpad.net/ubuntu/+source/rubygems-integration/+bug/1749226 - The
OpenSUSE/rubygems-integration
would then support an environment variable named something likeOPENSUSE_LEAP_DISABLE_RUBYGEMS_INTEGRATION
, like they have aDEBIAN_DISABLE_RUBYGEMS_INTEGRATION
, at https://salsa.debian.org/ruby-team/rubygems-integration.git - when that new
OpenSUSE/rubygems-integration
provides the fix for the OpenSUSE Leap repository-based ruby installation, then the new package should be published to theobs://devel:languages:ruby/openSUSE_Leap_15.1 ruby
repository, and declared as aportus
dependency (zypper
error thrown,by portus installation, if dependency not installed)
- Invovles, I think, proposing a
Et voilà.
(Hope this will help the Open SUSE Team)
p.s.: I opened an issue in https://github.com/openSUSE/docker-containers about this new support issue : openSUSE/docker-containers#114
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 standardportus
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.
What's better in this image
- Well for a start, we don't have anymore the error investigated in #1 :
background_1 | /usr/bin/bundle:23:in `load': cannot load such file -- /usr/lib64/r
uby/gems/2.6.0/gems/bundler-1.16.4/exe/bundle (LoadError)
- I created users, teams namespaces, docker push and pull, absolutely no error logged, whether on the
background
service side, or theportus
service. - Best : I have a setup clair scanner and ...Even Clair Works GREAAAAT :D
- confirmed 2.5 version of portus source code, I can even tell the commit ID I believe it is
b87d37e4e692b4fe5616b6f0970cb606688c344a
:
- And look, now Clair scanning
Rocket Chat
official distribution for docker ... full of vulnerabilities, my dear, as I expected ^ ^ :
- Now here for the
volcanosh/spark:v2.4.0
docker hub hosted image, an example of the Vulnerability list, with theirCVE-MITRE
reference :
- So I checked the webui, I am running portus version 2.5, and I can even say the exact commit (on
master
I checked),b87d37e4e692b4fe5616b6f0970cb606688c344a
is the last commit on master (onMarch, 2nd 2020
) :
Clonage dans 'Portus'...
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 38892 (delta 4), reused 0 (delta 0), pack-reused 38883
Réception d'objets: 100% (38892/38892), 36.50 MiB | 16.89 MiB/s, fait.
Résolution des deltas: 100% (18385/18385), fait.
jibl@poste-devops-typique:~$ cd Portus
jibl@poste-devops-typique:~/Portus$ export GIT_COMMIT_ID='b87d37e4e692b4fe5616b6f0970cb606688c344a'
jibl@poste-devops-typique:~/Portus$ git branch --contains $GIT_COMMIT_ID
* master
jibl@poste-devops-typique:~/Portus$
jibl@poste-devops-typique:~/Portus$
- and it is this commit 👍 SUSE/Portus@b87d37e so, as of today, the exact last commit on master . So yeah, they always build from source from last commit on
master
(regardless of whether it is tagged or not). ... Why not switch togit flow AVH Edition
? ...