Skip to content

Semaphore - Die API

Verschoben Ansible
2 1 352
  • Nehmen wir mal an, wir haben bei Gitlab oder auch Github, oder was auch immer, ein Repo das wir gelegentlich bearbeiten und das danach automatisch auf einen Server soll. So was ist ja in der Entwicklung von Software normal. Dafür gibt es ganz viele Möglichkeiten, ich habe mir gedacht das kann man sicherlich auch mit einem Playbook realisieren. Mittlerweile, nach vielen Kopfschmerzen, funktioniert es.

    PyCharm (commit & push) -> Gitlab -> Semaphore (Playbook) -> Server mit Applikation

    Wir müssen also mit Gitlab das Playbook auf dem Semaphore Server triggern. Meine ersten Versuche zielten darauf ab, meinen lokalen Semaphore Server zu triggern. Dazu wollte ich die IPv6 Adresse benutzen. Dies scheiterte aber die ganze Zeit.

    Die Docker Container, die Gitlab startet, scheinen keine IPv6 Funktionalität zu besitzen!?? Da ich aber schauen wollte, ob das so klappt wie ich mir das vorstellte, habe ich einen Semaphore Server im Netz aufgesetzt. Und da funktionierte es (IPv4 & IPv6) einwandfrei.

    Ok, die Doku zur API (Application Programming Interface) findet man -> https://docs.ansible-semaphore.com/administration-guide/api

    Ganz wichtig ist das Thema Authentifizierung. Damit ein User auf die API zugreifen kann, benötigt dieser meistens einen s.g. Token. Den kann man mit der API auch erzeugen, aber zuerst muss man sich mal anmelden, an der API.

    LOGIN

    curl -v -c /tmp/semaphore-cookie -XPOST \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -d '{"auth": "YOUR_LOGIN", "password": "YOUR_PASSWORD"}' \
    http://localhost:3000/api/auth/login
    

    Login & Passowort sind die Login Daten Eures Semaphores Users. Danach ist man angemeldet und kann weiter arbeiten.

    TOKEN erzeugen

    curl -v -b /tmp/semaphore-cookie -XPOST \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    http://localhost:3000/api/user/tokens
    
    
    curl -v -b /tmp/semaphore-cookie \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    http://localhost:3000/api/user/tokens
    

    Danach erscheint in der Konsole die Ausgabe und man kann sich den Token kopieren. Damit kann man dann weiter arbeiten. Beispiel aus der Doku.

    [{"id":"YOUR_ACCESS_TOKEN","created":"2017-03-11T13:13:13Z","expired":false,"user_id":1}]
    

    Um jetzt mit Gitlab einen Task anzustoßen, braucht man diesen curl-String.

    curl -v -XPOST \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
    -d '{"template_id": 1}' \
    http://localhost:3000/api/project/1/tasks
    

    Ok, das bekommt man hin, oder? War für mich leider doch ein sehr lange Sessions des Ausprobierens usw. Das Problem war die Formatierung des curl-Strings bei gitlab. Ok, weiter geht es.

    Gitlab

    Wir legen im Gitlab Projekt eine Datei mit dem Namen

    gitlab-ci.yml
    

    an. Die Testdatei hat folgenden Inhalt.

    # Here we test to trigger a semaphore task from gitlab runner.
    stages:
      - deploy
    
    deploy:
      stage: deploy
    
      script:
        # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables
        >
        curl -v -XPOST -H 'Content-Type: application/json' -H 'Accept: application/json' -H "Authorization: Bearer $SEMAPHORE_API_TOKEN " -d '{"template_id": 2}' https://<DOMAIN>/api/project/2/tasks
      only:
        - master  # Specify the branch to trigger the pipeline (adjust as needed)
    

    Ich wollte den Code eigentlich lesbar reinschreiben, also mit \ mehrere Zeilen. Aber alle meine Versuche sind gescheitert, egal was ich im Internet gefunden habe oder auch bei ChatGPT, es ging erst als ich alles in eine Zeile geklatscht habe. Naja, dann halt nicht.

    Wie ihr seht, habe ich zu dem Token was kommentiert.

    # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables
    

    Unter dem Pfad kann man Token usw. ablegen und ihnen einen Namen geben. Damit kann man die sensiblen Informationen aus dem Code raushalten. Wenn man dann noch in den Einstellungen, den Token auf masked setzt, wird er auch in den Logs usw. nicht angezeigt, sondern maskiert.

    > authorization: Bearer [MASKED]
    

    Das sieht ja schon gut aus 🙂 Wenn man nun was in Pycharm editiert und das per commit & push nach gitlab befördert, führt gitlab nach der Ausführung der Befehle das File gitlab-ci.yml aus.
    Und das sorgt dafür, das der entsprechende Task auf dem Semaphore Server ausgeführt wird.

    Ein wunderbares Spielzeug 🙂 Viel Spaß beim Spielen!

    Wer Fehler findet, bitte kommentieren. Ich mag es nicht, wenn unnützes Zeug im Internet steht.

  • Ich hasse schlecht lesbaren Code, scheint man sich bei Python so anzugewöhnen. Habe da nochmal was mit der langen Zeile getestet.

    stages:
      - deploy
    
    deploy:
      stage: deploy
    
      script:
        # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables
        - >-
         curl -v XPOST
         -H 'Content-Type: application/json'
         -H 'Accept: application/json'
         -H "Authorization: Bearer $SEMAPHORE_API_TOKEN "
         -d '{"template_id": 2}'
         https://<DOMAIN>/api/project/2/tasks
      only:
        - master  # Specify the branch to trigger the pipeline (adjust as needed)
    

    Hier noch was Dr. ChatGPT dazu schreibt

    631de9d4-b04d-4043-bfff-c5f2d1b6eea7-grafik.png

    Erledigt - läuft 🙂 Und verstanden habe ich es auch.

  • FrankMF FrankM verschob dieses Thema von Linux am
  • NodeBB - 4.2.2

    NodeBB nodebb linux
    1
    0 Stimmen
    1 Beiträge
    150 Aufrufe
    Niemand hat geantwortet
  • Forgejo-Runner

    Verschoben Forgejo forgejo linux podman
    2
    4
    0 Stimmen
    2 Beiträge
    279 Aufrufe
    FrankMF
    Was macht man, wenn man den forgejo-runner aktualisieren will? Das bei der Einrichtung erhaltene Binary liegt unter /usr/local/bin Ok, man kann von der forgejo Webseite, direkt die Binarys herunterladen. https://code.forgejo.org/forgejo/runner/releases Das Binay kopiert man dann nach /usr/local/bin - Fertig! Aktuell bin ich jetzt auf v8.8.8 root@trixie:~# forgejo-runner -v forgejo-runner version v8.0.0
  • RockPro64 - Mainline Kernel 6.13.0-1197-ayufan

    ROCKPro64 rockpro64 linux
    1
    0 Stimmen
    1 Beiträge
    93 Aufrufe
    Niemand hat geantwortet
  • Nextcloud - Update auf 31.0.0

    Nextcloud nextcloud linux
    2
    1
    0 Stimmen
    2 Beiträge
    663 Aufrufe
    FrankMF
    Und nicht vergessen service php8.2-fpm restart Damit sieht man dann auch alle Files und Kalendereinträge LOL
  • Restic v0.16.5 released

    Restic restic linux
    1
    0 Stimmen
    1 Beiträge
    178 Aufrufe
    Niemand hat geantwortet
  • Star64 - Warnung

    Angeheftet Star64 star64 risc-v linux
    1
    0 Stimmen
    1 Beiträge
    137 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Debian Bullseye Teil 1

    ROCKPro64 debian linux rockpro64
    17
    4
    0 Stimmen
    17 Beiträge
    2k Aufrufe
    FrankMF
    Durch diesen Beitrag ist mir mal wieder eingefallen, das wir das erneut testen könnten Also die aktuellen Daten von Debian gezogen. Das Image gebaut, könnt ihr alles hier im ersten Beitrag nachlesen. Da die eingebaute Netzwerkschnittstelle nicht erkannt wurde, habe ich mal wieder den USB-to-LAN Adapter eingesetzt. Bus 005 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Die Installation wollte ich auf einem NVMe Riegel installieren. Die Debian Installation durchgezogen und nach erfolgreicher Installation neugestartet. Und siehe da, ohne das man alles möglich ändern musste, bootete die NVMe SSD Eingesetzter uboot -> 2020.01-ayufan-2013...... Die nicht erkannte LAN-Schnittstelle müsste an nicht freien Treibern liegen, hatte ich da irgendwo kurz gelesen. Beim Schreiben dieses Satzes kam die Nacht und ich konnte noch mal drüber schlafen. Heute Morgen, beim ersten Kaffee, dann noch mal logischer an die Sache ran gegangen. Wir schauen uns mal die wichtigsten Dinge an. root@debian:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: enx000acd26e2c8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff inet 192.168.3.208/24 brd 192.168.3.255 scope global dynamic enx000acd26e2c8 valid_lft 42567sec preferred_lft 42567sec inet6 fd8a:6ff:2880:0:20a:cdff:fe26:e2c8/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:20a:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5426sec preferred_lft 1826sec inet6 fe80::20a:cdff:fe26:e2c8/64 scope link valid_lft forever preferred_lft forever Ok, er zeigt mir die Schnittstelle eth0 ja an, dann kann es an fehlenden Treibern ja nicht liegen. Lässt dann auf eine fehlerhafte Konfiguration schließen. Nächster Halt wäre dann /etc/network/interfaces Das trägt Debian ein # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug enx000acd26e2c8 iface enx000acd26e2c8 inet dhcp # This is an autoconfigured IPv6 interface iface enx000acd26e2c8 inet6 auto Gut, bei der Installation hat Debian ja nur die zusätzliche Netzwerkschnittstelle erkannt, folgerichtig ist die auch als primäre Schnittstelle eingetragen. Dann ändern wir das mal... # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug enx000acd26e2c8 allow-hotplug eth0 #iface enx000acd26e2c8 inet dhcp iface eth0 inet dhcp # This is an autoconfigured IPv6 interface #iface enx000acd26e2c8 inet6 auto iface eth0 inet6 auto Danach einmal alles neu starten bitte systemctl status networking Da fehlte mir aber jetzt die IPv4 Adresse, so das ich einmal komplett neugestartet habe. Der Ordnung halber, so hätte man die IPv4 Adresse bekommen. dhclient eth0 Nachdem Neustart kam dann das root@debian:/etc/network# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff inet 192.168.3.172/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 42452sec preferred_lft 42452sec inet6 fd8a:6ff:2880:0:6003:b0ff:fed6:dcb3/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:6003:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5667sec preferred_lft 2067sec inet6 fe80::6003:b0ff:fed6:dcb3/64 scope link valid_lft forever preferred_lft forever 3: enx000acd26e2c8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff Fertig, eth0 läuft. Nun kann man den zusätzlichen Adapter entfernen oder halt konfigurieren, wenn man ihn braucht. Warum der Debian Installer die eth0 nicht erkennt verstehe ich nicht, aber vielleicht wird das irgendwann auch noch gefixt. Jetzt habe ich erst mal einen Workaround um eine Installation auf den ROCKPro64 zu bekommen.
  • Debian 10 - Terminal wechseln

    Linux linux
    2
    0 Stimmen
    2 Beiträge
    727 Aufrufe
    FrankMF
    Das eigentliche Problem scheint zu sein, das bei der Installation folgendes fehlte. root@debian:~# apt install gnome-terminal Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Die folgenden zusätzlichen Pakete werden installiert: gnome-terminal-data nautilus-extension-gnome-terminal Die folgenden NEUEN Pakete werden installiert: gnome-terminal gnome-terminal-data nautilus-extension-gnome-terminal 0 aktualisiert, 3 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen 2.867 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 9.971 kB Plattenplatz zusätzlich benutzt. Möchten Sie fortfahren? [J/n] Nach der Deinstallation von tilix ist jetzt alles wieder so, wie ich es gewohnt bin