Skip to content

Semaphore - Die API

Verschoben Ansible
  • 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

  • Update 1.30.5 released

    Vaultwarden
    1
    0 Stimmen
    1 Beiträge
    103 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    4 Beiträge
    676 Aufrufe
    FrankMF

    Ich parke das mal hier, damit ich das nicht noch mal vergesse. Hat mich eben mal wieder eine Stunde gekostet 😞

    /etc/ansible/ansible.cfg

    [defaults] host_key_checking = False

    Edit -> https://linux-nerds.org/topic/1493/ansible-host_key_checking

  • Flatpak Paket zurückrollen

    Linux
    1
    0 Stimmen
    1 Beiträge
    42 Aufrufe
    Niemand hat geantwortet
  • Debian 11 Bullseye released!

    Linux
    4
    0 Stimmen
    4 Beiträge
    281 Aufrufe
    FrankMF

    Mein Systemadmin auf der Arbeit meinte heute, angesprochen auf das Problem, läuft der Network-Manager? Ok, gute Frage...... Schauen wir mal.

    Ich bin mir leider nicht 100% sicher, ob er vor meinem Eingreifen lief, ich denke aber schon. Warum ich unsicher bin?

    root@debian:~# systemctl enable systemd-networkd.service Created symlink /etc/systemd/system/dbus-org.freedesktop.network1.service → /lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/multi-user.target.wants/systemd-networkd.service → /lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/sockets.target.wants/systemd-networkd.socket → /lib/systemd/system/systemd-networkd.socket. Created symlink /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service → /lib/systemd/system/systemd-networkd-wait-online.service.

    Ok, danach

    root@debian:~# systemctl start systemd-networkd.service root@debian:~# systemctl status systemd-networkd.service ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; ven> Active: active (running) since Tue 2021-08-17 17:36:38 CEST; 6s ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 1288 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 19087) Memory: 3.9M CPU: 39ms CGroup: /system.slice/systemd-networkd.service └─1288 /lib/systemd/systemd-networkd Aug 17 17:36:38 debian systemd[1]: Starting Network Service... Aug 17 17:36:38 debian systemd-networkd[1288]: enp25s0: Gained IPv6LL Aug 17 17:36:38 debian systemd-networkd[1288]: Enumeration completed Aug 17 17:36:38 debian systemd[1]: Started Network Service.

    Danach ging immer noch nix.

    root@debian:/etc/network# ^C root@debian:/etc/network# nmcli device show GENERAL.DEVICE: wlx7cdd907cbec2 GENERAL.TYPE: wifi GENERAL.HWADDR: BA:59:C0:76:C7:F5 GENERAL.MTU: 1500 GENERAL.STATE: 20 (nicht verfügbar) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- GENERAL.DEVICE: enp25s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 30:9C:23:60:C6:8E GENERAL.MTU: 1500 GENERAL.STATE: 10 (nicht verwaltet) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- WIRED-PROPERTIES.CARRIER: an IP4.ADDRESS[1]: 192.168.3.169/24 IP4.GATEWAY: 192.168.3.1 IP4.ROUTE[1]: dst = 192.168.3.0/24, nh = 0.0.0.0, mt = 0 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.3.1, mt = 0 IP6.ADDRESS[1]: 2a02:908:1260:13bc:329c:23ff:xxxx:xxxx/64 IP6.ADDRESS[2]: fd8a:6ff:2880:0:329c:23ff:fe60:c68e/64 IP6.ADDRESS[3]: fe80::329c:23ff:fe60:c68e/64 IP6.GATEWAY: fe80::e4d3:f0ff:fe8f:2354 IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 256 IP6.ROUTE[2]: dst = ::/0, nh = fe80::e4d3:f0ff:fe8f:2354, mt = 1024 IP6.ROUTE[3]: dst = 2a02:908:xxxx:xxxx::/64, nh = ::, mt = 256 IP6.ROUTE[4]: dst = fd8a:6ff:2880::/64, nh = ::, mt = 256

    Jetzt hatte ich das erste Mal einen Ansatz, wonach ich suchen musste.

    GENERAL.STATE: 10 (nicht verwaltet)

    Etwas Suche im Netz und dann das

    nano /etc/NetworkManager/NetworkManager.conf

    Inhalt der Datei

    [main] plugins=ifupdown,keyfile [ifupdown] managed=false

    Das false in true geändert. Danach ein

    systemctl restart NetworkManager

    und ich konnte den Network-Manager auf dem Desktop benutzen!?!?!?

    Bildschirmfoto vom 2021-08-17 18-07-25.png

    Irgendwas ist da durcheinander im Bullseye 😳

  • Images 0.11.x

    Images
    5
    0 Stimmen
    5 Beiträge
    323 Aufrufe
    FrankMF

    0.11.2: gitlab-ci-linux-build-187 released

    0.11.2: Update OMV install (to also be able to run OMV6)
  • NanoPi R4S - Armbian

    NanoPi R4S
    2
    0 Stimmen
    2 Beiträge
    306 Aufrufe
    FrankMF

    Müsste seit gestern so weit sein 🙂

    b20f93d2-1719-40c5-afb8-6b4edafa6793-image.png

  • 0 Stimmen
    3 Beiträge
    320 Aufrufe
    FrankMF

    @thrakath1980 Das kann ich Dir leider nicht beantworten. Denke aber, das es sinnvoll ist neu anzufangen. Welche Settings meinst Du?

    Ich würde mal /etc/config sichern. Da sollte das Meiste ja drin sein.

    Notifications? Hmm, ich hoffe das das funktioniert. Ich schau zur Sicherheit mal nach.

  • Kopia 0.7.0-rc1 Kurztest

    Kopia
    2
    0 Stimmen
    2 Beiträge
    291 Aufrufe
    FrankMF

    Nachdem ich doch ziemlich lange Snapshot Zeiten hatte, habe ich Jarek mal gefragt woran das liegt.

    I guess you could run it in the cloud but latency will be progressively worse
    because it's a chatty protocol sensitive to latency

    Technisch verstehe ich das nicht, aber ich habe dann mal als kurzen Test auf meine lokale SSD einen Snapshot gemacht. Der war nach 2 Minuten (ca. 11GB) fertig. Der zweite Snapshot brauchte ca. 12 Sekunden. Das hört sich schon mal viel besser an, als die Stunden.

    Aktuell ist der Plan den Kopia-Server im Internet zu nutzen damit beerdigt. Das scheint so nicht zu funktionieren. Ich mache da noch einen kurzen Test, diesmal Lokal auf meinem NAS.