Lorawan-stack: Stellen Sie Standard-Systempakete als Alternative zu Docker bereit
Zusammenfassung:
Alle großen Linux-Distributionen verlassen sich auf Paketmanager, um Software kontrolliert und sicher zu installieren.
Dieser Vorschlag sieht vor, dass Pakete als Ausgangspunkt in den Formaten RPM , deb und opkg erstellt werden, wobei zu einem späteren Zeitpunkt weitere Paketformate hinzugefügt werden.
Warum brauchen wir das?
Viele Unternehmensorganisationen hindern git daran, sich mit anderen Servern als ihren eigenen zu verbinden, und erlauben möglicherweise auch keine wget -Befehle.
Docker ist in diesen Organisationen häufig auch nicht verfügbar, der Zugriff auf Paket-Repositories ist jedoch eine „bekannte Größe“ und daher leichter an die Sicherheitsteams zu verkaufen, zumal Pakete im Rahmen des Erstellungsprozesses in der Regel vollständig signiert werden.
Es gibt auch Situationen, für die Docker einfach nicht geeignet ist. Dies könnte beinhalten, wenn Systemintegratoren/Managed Service Provider mithilfe von AWS Auto Scaling Groups skalieren möchten, die auf Instances statt auf Containern basieren, oder für Bare-Metal-Installationen in sicheren Umgebungen.
Die Installation über Konfigurationsmanagement-Tools wie Ansible, Chef oder Puppet ist auch unglaublich schwierig, wenn Sie keine Pakete zur Verfügung haben.
Schließlich ist die Installation aus einem Git-Repository im Gegensatz zu einem Paket ohne Compiler schwierig, was ein Sicherheitsrisiko darstellt, wenn Compiler auf Produktionssystemen installiert werden.
Was ist schon da?
Derzeit haben wir die Wahl zwischen zwei Docker-Containern ( ttn-lw-stack und ttn-lw-cli ) oder dem Erstellen von gleichnamigen Binaries aus Git.
Die Bereitstellung erfolgt entweder über docker pull oder git clone , die beide möglicherweise nicht hinter Unternehmens-/Bildungs-Firewalls funktionieren.
Was fehlt?
Die Möglichkeit zur Installation über yum , apt oder opkg
Wie schlagen Sie vor, dies umzusetzen?
Dies sollte mit GO Releaser relativ einfach zu implementieren sein, aber GO ist keine Sprache, mit der ich (noch!)
Umfeld:
Linux – CentOS/RHEL-basiert, Debian/Ubuntu-basiert, OpenWRT-basiert
Was können Sie selbst tun und wo brauchen Sie Hilfe?
Ich brauche eine Bestätigung, dass dies der geeignete Weg ist, eine Go-Anwendung für die Bereitstellung zu packen, und dann etwas Hilfe bei der Implementierung von jemandem, der GO versteht!
proffalken
Alle 10 Kommentare
Ich werde mit dem Hinzufügen von Paketen zu APT, AUR und https://github.com/nixos/nixpkgs beginnen, da ich bereits mit dem Format dieser Pakete vertraut bin. Andere werden später hinzugefügt.
Beiträge sind natürlich immer willkommen!
rvolosatovs
am 2. Feb. 2019
@rvolosatovs werden Sie go-releaser oder eine andere Möglichkeit zum Erstellen der Pakete verwenden?
Ich würde mich freuen, an der RPM-Seite der Dinge zu arbeiten, solange ich weiß, was Sie verwenden, um sie zu erstellen! :)
proffalken
am 3. Feb. 2019
Wir werden diesen Teil der CD auch machen.
Fügen Sie auch brew zur Wunschliste hinzu.
johanstokking
am 3. Feb. 2019
Ich füge nur meine Unterstützung hinzu. Ich habe Docker noch nie zuvor verwendet, und obwohl ich zu schätzen weiß, dass es viele Programmiersprachen gibt, war dies ein großer Sprung für jemanden, der dies noch nie zuvor getan hat. Während die Installation aus einem Repo die Art und Weise ist, wie Entwickler Dinge tun, ist es für Endbenutzer nicht sehr freundlich.
mrpackethead
am 11. Feb. 2019
Vielen Dank für all Ihre Arbeit an diesem Thema. Ich hoffe, dass ich in den nächsten Tagen Zeit finde, RPM-Unterstützung hinzuzufügen und zu testen.
proffalken
am 13. Feb. 2019
@proffalken Wir werden das RPM-Paket als Teil von CI bauen – Sie werden es auf unserer Veröffentlichungsseite finden, sobald wir eine Veröffentlichung machen. (FYI, github unterstützt auch Atom-Feeds für Releases: https://github.com/thethingsnetwork/lorawan-stack/releases.atom)
Ich bin deinem Vorschlag gefolgt, goreleaser zu verwenden.
In Bezug auf das RPM-Paket selbst - es ist (vorerst) nur https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L79 -L92
Ich vermute zum Beispiel, dass der Speicherort des Frontends für RPM-Pakete nicht standardmäßig ist und tatsächlich auch nicht standardmäßig für den Stack (wir erwarten, dass er bei /srv/ttn-lorawan/public liegt).
Daher wäre Ihr Beitrag dazu, wie dies geschehen sollte, sehr hilfreich.
Beachten Sie, dass wir beispielsweise für brew die Stack-Binärdatei umschließen, um die zugehörige Umgebungsvariable so einzustellen, dass sie auf das Frontend zeigt:
https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L116 -L119
Ich bin mir sicher, dass die erwartete Position im RPM-Paket anders ist, aber wir können dort hoffentlich denselben Ansatz verwenden.
rvolosatovs
am 14. Feb. 2019
@rvolosatovs macht für mich absolut Sinn.
Die Einstellung der env-Variablen erfolgt wahrscheinlich am besten in einem systemd-Dienstskript, ich werde versuchen, eines zusammenzustellen, sobald ich kann.
Dinge in /srv/ttn-lorawan/public zu stecken ist auch vollkommen akzeptabel :)
proffalken
am 15. Feb. 2019
@rvolosatovs können Sie die Labels und/oder den ursprünglichen Kommentar aktualisieren, um anzugeben, dass wir keine Hilfe mehr benötigen, oder Hilfe bei einer bestimmten Verteilung? Bevor die Community-Mitglieder eifrig damit beginnen, dies zu implementieren, während das meiste davon noch in Arbeit ist.
johanstokking
am 18. Feb. 2019
Blockiert durch fehlende Freigabe von v3.0.0 .
Es ist nicht sinnvoll, Vorabversionen in Repositories zu veröffentlichen.
rvolosatovs
am 18. März 2019
Wegen Freigabe geschlossen. Wir haben Snappy- und Brew-Unterstützung sowie Deb- und RPM-Dateien
johanstokking
am 9. Apr. 2019
Verwandte Themen
johanstokking
·
5Kommentare
johanstokking
·
6Kommentare
kschiffer
·
7Kommentare
kschiffer
·
4Kommentare
MatteMoveSRL
·
7Kommentare
Hilfreichster Kommentar
Wir werden diesen Teil der CD auch machen.
Fügen Sie auch
brewzur Wunschliste hinzu.