Na tym etapie wszystko już działało (miejscami z małą wydajnością, ale jednak). Problemem były jednak stare wersje Jenkinsa i SonarQube.

Jenkins w używanej przez nas wersji (2.176.1) miał lukę bezpieczeństwa i alarmował o wymaganej aktualizacji do wersji 2.176.2.

SonarQube był zainstalowany w starej wersji LTS (6.7.7), a nie najnowszej (7.9.1 LTS). Należało to zmienić.

1. Aktualizacja Jenkinsa przez podmienienie archiwum jenkins.war na nowsze,

2. Instalacja nowszej wersji SonarQube (sekcje: Install and Configure SonarQube oraz Create Systemd Service file for SonarQube),

3. Naprawa błędów: ERROR: bootstrap checks failed [1]max file descriptors [4096] for elastizcsearch process is too low, increase to at least [65536] oraz [2]max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144],

4. Uruchomienie zaktualizowanych Jenkinsa i SonarQube,

5. Usunięcie JDK 11.0.3 z dystrybycji Oracle i instalacja OpenJDK 11.0.4,

6. Naprawa konfiguracji w pliku locale.

W przypadku aktualizacji Jenkinsa obyło się bez komplikacji. Wymagane było tylko podążenie za instrukcją dla instalacji z archiwum war (przy oczywistej zmianie wersji na wymaganą przez nas w komendzie wget (wget http://updates.jenkins-ci.org/download/war/2.176.2/jenkins.war)).

Pomiędzy kolejnymi wersjami SonarQube wzrosły minimalne wymagania . Przy próbie uruchomienia SonarQube w logach (sonar.log) pojawiły się następujące wpis: ERROR: bootstrap checks failed [1]max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536] [2]max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144], a sam serwis był w stanie ciągłego restartu.

Drugi z wymienionych błędów udało się wyeliminować poprzez zastosowaną radę ze StackOverflow. Niestety pierwszy występował nadal mimo użycia rady z tej samej strony. Z pomocą przyszła oficjalna dokumentacja (sekcja Platform notes#Linux - dodanie wpisów w /etc/systemd/system/sonar.service w postaci: LimitNOFILE=65536 oraz LimitNPROC=4096).

Dlaczego Jenkins został zainstalowany w ten sposób, a nie jako snap? ArubaCloud domyślnie przychodzi z zainstalowanym JDK w wersji 11.0.3 od Oracle. Nie jest to najnowsza wersja i przy próbie sudo apt-get update && sudo apt-get upgrade oraz sudo install jenkins proces był blokowany z powodu braku plików instalacyjnych JDK 11.0.4 w odpowiedniej lokalizacji. Odpowiedzią na to była instalacja Open JDK w wersji najnowszej, ustawienie go jako domyślnego oraz ręczne usunięcie każdego pliku i lokalizacji związanej z JDK od Oracle za pomocą sudo rm -r (metody automatyczne były blokowane tak samo, jak wcześniej wspomniane sudo install jenkins).

Drugim problemem była również błędna konfiguracja pliku locale serwera. Rozwiązane to zostało z pomocą instrukcji oraz ręczną edycją pliku wraz z dodaniem wpisu LC_ALL=en_US.UTF-8 (bez tego przy każdym restarcie serwera locale znowu wracało do błędnej konfiguracji).