Skip to content

Fixed broken Ruby stack in OpenSUSE Leap's repos

Latest
Compare
Choose a tag to compare
@Jean-Baptiste-Lasselle Jean-Baptiste-Lasselle released this 02 Mar 12:00

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

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 an OpenSUSE / zypper linux package (like a *.deb package for Debian)
  • 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 the ruby2.6 package distributed in the obs://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` :

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

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 the portus service.
  • Best : I have a setup clair scanner and ...Even Clair Works GREAAAAT :D

Even Clair Works GREAAAAT

  • confirmed 2.5 version of portus source code, I can even tell the commit ID I believe it is b87d37e4e692b4fe5616b6f0970cb606688c344a :

any body find meeeeeee sme-body - to love

  • And look, now Clair scanning Rocket Chat official distribution for docker ... full of vulnerabilities, my dear, as I expected ^ ^ :

My beloved rocket.chat

rookiedookie image

  • Now here for the volcanosh/spark:v2.4.0 docker hub hosted image, an example of the Vulnerability list, with their CVE-MITRE reference :

volcanosh vulnerable

volcanosh CVE-MITRE kil list

  • 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 (on March, 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 to git flow AVH Edition ? ...