In diesem Post möchte ich nur kurz auflisten, wie man Storage Accounts in Azure mit Azure CLI und Azure PowerShell auflisten kann. Dies soll mehr für mich als Erinnerung dienen.
az login az storage account list
Import-Module AzureRM Login-AzureRmAccount Get-AzureRmStorageAccount
Vor kurzem wollte ich in PowerShell den Befehl Connect-AzureRmAccount aufrufen, da bekam ich plötzlich diese Fehlermeldung:
Connect-AzureRmAccount : Die Benennung "Connect-AzureRmAccount" wurde
nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines
ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des
Namens, oder ob der Pfad korrekt ist (sofern enthalten),
und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ Connect-AzureRmAccount
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Connect-AzureRmAccount:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Offensichtlich ist Connect-AzureRmAccount ein neuerer Name für das alte Login-AzureRmAccount. Nun gibt es zwei Möglichkeiten:
Zweiteres erreicht man durch den PowerShell-Befehl
Install-Module -Force AzureRM
Dabei sollte PowerShell als Administrator gestartet sein.
Kürzlich wollte ich einen RedHat-Server einrichten und habe dafür docker auf dem Server installieren wollen. Beim Versuch, docker zu installieren bekam ich folgende Fehlermeldung:
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package docker-ce.x86_64 0:18.06.1.ce-3.el7 will be installed
--> Processing Dependency: container-selinux >= 2.9 for package: docker-ce-18.06.1.ce-3.el7.x86_64
--> Finished Dependency Resolution
Error: Package: docker-ce-18.06.1.ce-3.el7.x86_64 (docker-ce-stable)
Requires: container-selinux >= 2.9
**********************************************************************
yum can be configured to try to resolve such errors by temporarily enabling
disabled repos and searching for missing dependencies.
To enable this functionality please set 'notify_only=0' in /etc/yum/pluginconf.d/search-disabled-repos.conf
**********************************************************************
Error: Package: docker-ce-18.06.1.ce-3.el7.x86_64 (docker-ce-stable)
Requires: container-selinux >= 2.9
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Die Lösung hierbei war, dass ich mit Hilfe des Subscription-Managers das Repository rhel-7-server-extras-rpms aktivieren musste:
sudo subscription-manager repos --enable=rhel-7-server-extras-rpms
Danach hat die Installation von docker wunderbar funktioniert.
Ich habe heute etwas mit Fossology gespielt. Genauer gesagt, wollte ich Fossology in Docker Containern starten und zwar mit Hilfe der Dateien, die von dem Projekt Fossology bereit gestellt werden.
Also fing ich an die entsprechenden Befehle in die Kommandozeile zu tippen:
$ git clone https://github.com/fossology/fossology.git $ cd fossology $ sudo docker-compose up
Beim letzten Befehl kam plötzlich eine Fehlermeldung:
ERROR: Version in "./docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a version of "2" (or "2.0") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1. For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file
Mit Hilfe von
$ sudo docker-compose -v docker-compose version 1.8.0, build unknown
fand ich heraus, dass die installierte docker-compose Version zu alt für die docker-compose.yml war, die in dem Fossology-Projekt lag. Also musste ich erstmal docker-compose updaten:
$ sudo curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose $ sudo chmod +x /usr/local/bin/docker-compose
Danach konnte ich Fossology ohne Probleme in Docker Containern starten.
Neulich bekam ich beim Versuch, unter Ubuntu ein Makefile mit Hilfe von CMake zu erstellen, diese Fehlermeldung:
— The ASM_NASM compiler identification is unknown
— Didn’t find assembler
CMake Error at simd/CMakeLists.txt:41 (enable_language):
No CMAKE_ASM_NASM_COMPILER could be found.Tell CMake where to find the compiler by setting either the environment
variable “ASM_NASM” or the CMake cache entry CMAKE_ASM_NASM_COMPILER to the
full path to the compiler, or to the compiler name if it is in the PATH.— Configuring incomplete, errors occurred!
Die Lösung hier war, das Paket nasm zu installieren:
sudo apt install nasm
Vor kurzem bekam ich beim Versuch, ein Visual Studio 2017-Projekt mit CMake zu generieren, diese Fehlermeldung:
CMake Error at CMakeLists.txt:3 (project):
GeneratorVisual Studio 15 2017 Win64
could not find any instance of Visual Studio.
— Configuring incomplete, errors occurred!
Die Fehlermeldung hat mich gewundert, da Visual Studio 2017 doch installiert war. Die Lösung bei mir war, dass ich noch die Komponente Visual C++ tools for CMake and Linux habe installieren müssen:
Mit der Zeit kann es vorkommen, dass der frei verfügbare Speicherplatz auf dem Server auf dem Jenkins läuft, immer kleiner wird. Das kann unter Anderem auch an Jenkins selbst liegen.
In diesem Post möchte ich ein paar Hilfestellungen geben, wie man dieses Problem lösen und auch vorbeugen kann. Ich werde in diesem Post von meiner Jenkins Installation ausgehen, die auf einem Ubuntu-Server installiert ist. Auf anderen Linux- oder Windows-Servern muss man die vorgestellten Strategien jedoch anpassen.
Auf meinem Ubuntu-Server ist Jenkins unter dem Pfad /var/lib/jenkins installiert. Unter diesem Ordner gibt es einen Ordner namens jobs, in dem es wiederum weitere Ordner gibt. Jeder dieser Ordner ist nach dem jeweiligen Job in Jenkins benannt. Wenn man also einen Job namens First Job hat, dann findet man unter jobs einen Ordner, der auch First Job heißt.
Mit dem Kommandos
cd /var/lib/jenkins/jobs
du -h –max-depth=1 | sort -hr
bekommt man nun eine Auflistung aller Ordner in jobs und die Größe aller Dateien zusammen vom jeweiligen Ordner.
Auf diese Weise kann man erkennen, welche Jobs den meisten Speicherplatz belegen. In meinem Fall ist das jedoch noch kein Problem. Will man jedoch für mehr Speicherplatz sorgen gib, kann es helfen, die Anzahl der Builds zu limitieren.
Standardmäßig speichert Jenkins jeden Build ab, den ein Job je ausgeführt hat. Insbesondere auch dann, wenn man anfängt, Artefakte zu archivieren (eine Post-build Aktion), kann der verfügbare Speicherplatz je nach Projekt sehr schnell klein werden. Wenn man aber die Anzahl der Builds limitiert, werden alte Builds von Jenkins automatisch gelöscht und es wird regelmäßig Speicherplatz wieder frei gelegt.
Um die Anzahl der Builds zu limitieren, muss man in einer Job-Konfiguration unter General einen Haken vor Discard old builds setzen und je nach belieben Werte einsetzen:
Anschließend das Speichern nicht vergessen 😉
Erst durch die vielen Plugins wird Jenkins zu dem was es ist: Ein sehr mächtiges Werkzeug. Doch wie installiert man ein Plugin in Jenkins? In diesem Post will ich aufzeigen, wie man in Jenkins Plugins installieren kann.
Der übliche Weg geht über den Link Manage Jenkins.
Wenn man auf den Link Manage Jenkins klickt, taucht eine neue Seite mit einer Reihe von Buttons. Einer davon hat den Titel Manage Plugins.
Wenn man auf diesen Knopf drückt, kommt man auf die Seite, auf der man Plugin installieren kann.
Auf dieser Seite muss man in den Reiter Available wechseln. Dort wird eine Reihe von installierbaren Plugins aufgelistet. Jetzt muss man dort nach dem gewünschten Plugin suchen. Dabei kann man das Suchfeld rechts oben zur Hilfe nehmen.
Hat man das gewünschte Plugin gefunden, setzt man einen Haken links neben dem Namen des Plugins. In meinem Beispiel will ich jetzt das Plugin Pipeline installieren.
Im Browser unten müsste sich jetzt ein Knopf namens Download now and install after restart befinden. Diesen muss man drücken. Anschließend startet man Jenkins neu.
Neben den Boardmitteln von Jenkins, weitere Jobs zu triggern, gibt es einige Plugins, die dasselbe erledigen und dabei mehr Einstellungen anbieten können. In diesem Post geht es um das Plugin namens Parameterized Plugin. Dieses Plugin erlaubt es, in einem Job oder am Ende eines Jobs weitere Jobs zu starten und dazu noch Parameter zu übergeben. Ich nehme jetzt an, dass der Leser/die Leserin das Plugin Parameterized Plugin schon installiert hat.
Es gibt Fälle, da möchte man einen Job laufen lassen, bevor der eigentliche Job gestartet wird. Mit dem Parameterized Plugin geht das folgendermaßen: In der Konfiguration des eigentlichen Jobs geht man in die Build-Sektion und fügt dort einen neuen Build-Schritt hinzu: Trigger/call builds on other projects.
Nun müsste ein neuer Build-Schritt erscheinen. Diesen muss man eventuell nach oben schieben, je nachdem, wie man es haben möchte und entsprechend konfigurieren (siehe nächstes Bild). Second Job ist in dem Fall ein zweiter Job, den ich in diesem Beispiel starten möchte, bevor der eigentliche Build-Prozess von dem aktuellen Job gestartet wird.
Nun kann man weiter unten auf Save drücken und es einfach mal ausprobieren. Dabei muss man darauf achten, dass die entsprechenden Knoten (master / slaves) genügend Slots haben. Ansonsten könnte es passieren, dass ein Job einen anderen blockiert.
Genauso wie man einen Job vor einem Job starten kann (siehe das Unterkapitel weiter oben), kann man auch einen Job nach einem anderen Job starten. In diesem Fall fügt man in der Liste der Post-build-Aktionen eine weitere Aktion hinzu: Trigger parameterized build on other projects.
Nun müsste ein neuer Bereich in den Post-build-Aktionen aufgetaucht sein. Diesen gilt es nun anzupassen und dann mit einem Klick auf Save zu speichern.
In diesem Post möchte ich euch zeigen, wie man einen zweiten Job startet, wenn der erste fertig ist. Das lässt sich mit den Boardmitteln von Jenkins recht einfach realisieren. Dazu muss man in den Post-build actions den Punkt Build other projects auswählen und dann den Namen des anderen Jobs eintragen.
In diesem Fall habe ich zu Testzwecken einen zweiten Job namens Second Job erstellt, der gestartet wird, wenn der erste erfolgreich fertig geworden ist.
Wie man in dem obigen Bild sieht, kann man einstellen, wann der zweite Job Second Job gestartet werden soll. Dies kann geschehen, wenn der erste Job erfolgreich war (Trigger only if build is stable), oder wenn das Ergebnis vom ersten Job instabil ist (Trigger even if the build is unstable) oder auch dann, wenn der erste Job fehlgeschlagen ist (Trigger even if the build fails). Ich habe das jetzt einfach mal auf Trigger only if build is stable eingestellt.
Ist alles eingerichtet, sieht man das auch später in der Liste der Downstream Projects:
Nun kann man einen Testlauf durchführen und den ersten Job starten. Nach dem Ende des ersten Jobs sollte automatisch der zweite gestartet werden (je nachdem, wie das Ergebnis des ersten Jobs ist und welche Einstellung man gewählt hat).