Ankündigung

Einklappen
Keine Ankündigung bisher.

Installer-Improvement

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Installer-Improvement

    Hoi gaert ,

    auch wenn in der Install-Doku explizit darauf hingewiesen wird: Du könntest im Install-Script ganz am Anfang einfach die folgende Zeile einfügen und es ist egal, von wo aus das Script aufgerufen wird:

    Code:
    cd "$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
    Damit ermittelt das Script selbständig, wo es sich befindet und wechselt dorthin.

    Ich mach' das in meinen Scripts in ähnlicher Form, denn dann kann man bspw. sauber weitere Files includieren und die Entwicklungsumgebung kann damit direkt umgehen:

    Code:
    # - Store path from where script was called
    # - Determine own location
    # - cd to this location
    # - Source further content
    callDir=$(pwd)
    ownLocation="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
    cd ${ownLocation}
    . ./include/helpers_console.sh
    . ./include/helpers_xml.sh
    Kind regards,
    Yves

    #2
    Danke für den Tipp!

    Der "Installer" ist eigentlich ohnehin recht... naja... War eben ursprünglich (wie alles) mehr für mich selbst gedacht, damit ich auch in zehn Jahren EDOMI schnell mal installieren kann (daher sind auch die Pakete und Config-Files gleich dabei).

    Daher bastel' ich gerade ein wenig an einer neuen Fassung und kann Deinen Tipp bestimmt gleich mal verwerten

    EDIT:
    Am liebsten wäre mir ja eine professionelle Lösung, d.h. EDOMI liegt als rpm irgendwo herum (z.B. auf meinem Serverchen). Aber da fehlen mir wohl die Linux-Kentnisse...
    Zuletzt geändert von gaert; 15.02.2019, 17:03.
    EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

    Kommentar


      #3
      Nun, direkt installiert ist es nicht, aber die Docker Lösung kommt dem recht nahe, ist einfach und hat keine Probleme mit Abhängigkeiten (MySQL config, etc...).
      Schau es dir mal an!

      Kommentar


        #4
        Nee - ich (alte Schule) brauch' dat Zeugs nicht Auf meinem EDOMI-Server läuft ohnehin nur EDOMI, da wäre jede Art von VM/Docker-Lösung einfach nur Verschwendung von Ressourcen.

        Am liebsten würde ich ein Mini-Linux (Arch oder so) mit integriertem EDOMI draufpacken - und sämtliche unnützen Dienste gar nicht erst installieren. Aber das kann ich Euch Spielkindern ja nicht antun
        EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

        Kommentar


          #5
          Es gibt Mini docker-host Systeme mit 20MB... ????. Performance ist fast bare-Metal, aber ja, dezidiert ist halt dezitiert....
          ​​​​​​JOE

          Kommentar


            #6
            Ist schon ein paar Tage her, aber ich greife es trotzdem noch mal auf.

            Begründungen wie "alte Schule" sieht man glaube ich generell, und speziell bei Informatikern, ja gar nicht gerne. Bei deinem Hobbyprojekt kannst du natürlich gerne umsetzen, was dir beliebt. Gerade hier im Forum ärgern wir uns aber so häufig über all die Elis mit ihren "veralteten Ansätzen" etc

            Wie givemeone schon sagte, die Laufzeitperformance sollte keinen relevanten Einschränkungen unterliegen (<1%).
            Natürlich hat gaert grundlegend recht mit der impliziten Aussage, dass für den docker daemon Ressourcen verwendet werden.
            Aber auch hier glaube ich, dass das für einen Großteil der Hardware einfach zu vernachlässigen ist.

            Auf der anderen Seite steht (sowohl für gaert als auch alle Benutzer) ein unglaublich einfaches Handling bzgl. Einrichtung, Update, Deinstallation.
            Weiter oben sagt gaert ja explizit, dass der Installer ursprünglich dafür gedacht war, dass er selbst auch in Jahren noch einfach ein lauffähiges System inkl. Abhängigkeiten installieren kann. Gerade hierfür ist docker prädestiniert:
            • Durch einen Container kann gaert ohne Fehlerquellen auf der Benutzerseite sicherstellen, welche Komponenten zur Verfügung stehen.
              • Einheitliches System.
              • Exakt gleicher Stand in Entwicklung, Tests und in "Produktion", ohne weiteren Aufwand.
            • Die Benutzer sind nicht mehr auf das Basis-OS angewiesen, sondern können den Container "irgendwo" ausführen.
            • Installation erfolgt durch einen einzelnen Aufruf. (Zwei, wenn docker noch fehlt?)
            • Parallelinstallation und Betrieb mehrerer Instanzen Problemlos möglich. -> Sorgenfreies Experimentieren
            • Kein direktes Hosting mehr durch gaert notwendig (aber weiter möglich).

            Ein paar Punkte, die mir so spontan in den Kopf kamen. Es gibt sicherlich noch weitere Pro-Argumente.
            Auf der Contra-Seite sehe ich, bis auf leicht geringeren Ressourcenverbrauch durch den daemon, "nur noch" die "Einarbeitung durch gaert".
            Aber hier wurde ja auch schon sehr viel von starwarsfan getan.

            Das soll wirklich nichts heißen. Es ist wie gesagt dein Hobbyprojekt, und du machst, was dir Spaß macht.
            Einarbeitungszeit deinerseits, und deine persönlichen Vorlieben spielen verständlicherweise eine große Rolle.
            Sieh es vielleicht als ganz kleinen Seitenhieb auf die "alte Schule".
            Primär wollte ich das Thema Docker in ein positiveres Licht rücken und die vielen Vorteile mal hervorheben
            "Wir" können dank starwarsfan Edomi ja bereits im Container betreiben.

            Kommentar

            Lädt...
            X