❌

Lese-Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.

Incus: Linux Containers Projekt forkt LXD

✇Linux-Magazin
Von: Ulrich Bantle

Das Linux Containers Projekt hat mit Incus einen Fork von LXD angekündigt, der von Aleksa Sarai entwickelt wurde.

Aleksa Sarai sei bislang vor allem für die Arbeit an runc, umoci und anderen Open-Containers-Projekten sowie für seine Beiträge zum Linux-Kernel bekannt. Daneben sei er aber auch lange Zeit der Packager von LXD in Opensuse gewesen, berichtet das Linux Containers Projekt .

Aleksa Sarai habe den Fork kurz nach der Entscheidung von Canonical, LXD von Linux Containern zu trennen. Der Name Incus sei unmittelbar nach der Veröffentlichung von LXD 5.16 eingeführt. Der Fork sei zunächst als persönliches Projekt gedacht, habe aber inzwischen in der Community und bei ehemaligen LXD-Mitarbeitern Interesse geweckt.

Nach Diskussionen mit Aleksa und Zuspruch aus der Community habe man sich entschlossen, Incus unter das Dach von Linux Containers zu stellen und ihm die Infrastruktur zur Verfügung zu stellen, die zuvor für LXD gestellt wurde.

Ziel von Incus sei es, eine vollständig von der Community geführte Alternative zu Canonicals LXD zu bieten und eine Möglichkeit zu bieten, einige Fehler zu korrigieren, die während der Entwicklung von LXD gemacht wurden und nicht korrigiert werden konnten, ohne die Abwärtskompatibilität zu verletzen.

Bislang gebe es keine klar definierte Roadmap, heißt es weiter. Incus werde die Änderungen in LXD mitverfolgen und wahrscheinlich mit der Zeit davon abweichen. Ein stabiles Release von Incus werde wahrscheinlich noch einige Monate auf sich warten lassen, so dass bestehende LXD-Benutzer sich nicht beeilen sollten, einen Weg zur Migration zu suchen.

Der Beitrag Incus: Linux Containers Projekt forkt LXD erschien zuerst auf Linux-Magazin.

LXD-Entwickler kündigt bei Canonical

✇Linux-Magazin
Von: Ulrich Bantle

Nach der Ankündigung von Canonical, die LXD-Entwicklung ins eigene Haus zu holen, wird nun bekannt, dass der seit 2011 bei Canonical beschäftigte LXD-Entwickler Stéphane Graber das Unternehmen verlassen hat.

Stéphane Graber schreibt in seinem Blog, dass er seinen Kollegen und der Geschäftsleitung gesagt habe, dass Canonical nicht mehr das Unternehmen sei, bei dem er 2011 mit Begeisterung eingestiegen sei, und es sei auch kein Unternehmen, bei dem er heute einsteigen würde, daher sollte er auch nicht weiter für dieses Unternehmen arbeiten.

Nach der Ankündigung seines Rücktritts habe Canonical beschlossen, LXD aus den Linux-Container-Projekten herauszuziehen und es in ein vollständig internes Projekt umzuwandeln, schreibt Graber weiter. Ich wünschte sich, diese Änderung hätte nicht stattgefunden, da er es für sehr wichtig halte, dass ein Projekt wie LXD in einer offeneren Community-Umgebung betrieben werde, in der die Meinung jedes Einzelnen geschätzt und jeder Beitrag willkommen sei. Das “LXD-Community-Experiment” innerhalb von Canonical als Fehlschlag abzustempeln, erscheint ihm und allen, die im Laufe der Jahre dazu beigetragen hätten, als unfair.

Graber will ein aktiver Benutzer von LXD bleiben und wahrscheinlich weiterhin Probleme und gelegentliche Korrekturen einreichen. Allerdings beabsichtige er nicht, jemals Canonical’s CLA zu unterschreiben.

Der Beitrag LXD-Entwickler kündigt bei Canonical erschien zuerst auf Linux-Magazin.

Canonical übernimmt LXD

✇Linux-Magazin
Von: Tim Schürmann

Der Container-Manager LXD hatte bislang seine Heimat im offenen Community-Projekt Linux Containers. Jetzt hat LXD-Erfinder Canonical das Tool komplett unter seine Kontrolle gebracht. Die entsprechenden Anlaufstellen beim Linux-Containers-Projekt werden abgeschaltet.

So ist der Quellcode sofort unter https://github.com/canonical/lxd zu finden, die LXD-Website lässt sich unter https://ubuntu.com/lxd erreichen. Canonical übernimmt auch die entsprechenden YouTube-Kanäle. Diskussionen rund um das Tool erfolgen im entsprechenden Discourse-Forum.

Als eine Folge aus der Übernahme lassen sich Images nur noch für die Architekturen x86_64 und aarch64 erstellen. Der bisherige Image-Server bleibt weiterhin in Betrieb, bietet aber nur die erwähnten Architekturen an.

Das Linux-Container-Team bedauert in einer Stellungnahme die Entscheidung von Canonical, respektiert sie aber und unterstützt Canonical beim Umzug. Der wiederum soll recht schnell vollzogen werden, LXD-Anwender und Entwickler sollten daher bereits die entsprechenden Anlaufstellen bei Canonical verwenden.

LXD war acht Jahre lang Teil des Linux-Containers-Projekt. Canonical hatte das Tool ursprünglich ins Leben gerufen und trieb die Entwicklung während der letzten Jahre maßgeblich voran.

Der Beitrag Canonical übernimmt LXD erschien zuerst auf Linux-Magazin.

Wekan – eine Open Source Trello Alternative

✇Zefanjas
Von: zefanja

In den letzten Wochen habe ich eine Software ausprobiert, die schon lange auf meiner Liste stand: Wekan. Wekan ist eine Open Source Alternative für Trello, einer Kanban-Software. Mit ihr lassen sich mit der Kanban-Methode Projekte oder Abläufe managen. Manche verwenden es auch als Aufgabenmanagementsystem. Es gibt verschiedene Open Source Alternativen zu Trello – Wekan ist eine, die dem Original am nächsten kommt. Ich möchte heute zeigen, wie man Wekan installiert und einrichtet.

Installation

Wekan kann man auf verschiedene Art und Weise installieren (manuell, Docker, snap, …). Wir werden es heute in einem LXD Container (Ubuntu 18.04) einrichten (LXD Container waren hier schon mehrmals Thema im Blog). Als erstes erstellen wir einen Container für Wekan:

$ lxc launch ubuntu:b wekan

Nachdem der Container erstellt und gestartet ist, loggen wir uns im Container ein:

$ lxc exec wekan bash

Wir werden Wekan als Snap installieren. In den Ubuntu LXD Container ist snapd schon installiert. Wir können also direkt Wekan installieren mit

$ snap install wekan

Nun legen wir die Haupt-URL und den Port für Wekan fest:

$ snap set wekan root-url="http://wekan.example.com"
$ snap set wekan port="80"

Optional kann man noch einstellen, das Updates automatisch installiert werden:

$ snap set core refresh.schedule=02:00-04:00

Fertig 🙂

Einrichtung

Nun können wir unter der IP unseres LXD Containers Wekan aufrufen. Wenn man LXD nicht lokal, sondern auf einem Server betreibt, kann es unter Umständen hilfreich sein eine Netzwerkbrücke für den Container einzurichten. Alternativ kann man auch Nginx als Reverse Proxy verwenden. Hinweise zur Einrichtung findet man im Wiki von Wekan.

Wekan Login

Hinweis: Der erste Benutzer, den wir einrichten, ist Administrator für Wekan.

Wir klicken als auf Registrieren und legen einen neuen Benutzer an.

Wekan Registrieren

Wenn wir nun auf Registrieren klicken, erscheint eine Fehlermeldung („Internal Server Error“). Das liegt daran, weil wir noch keinen EMail-Server eingerichtet haben.

Wekan Error

Wekan funktioniert aber auch ohne einen EMail-Server, deswegen öffnen wir einfach wieder unsere Hauptseite (wekan.example.com bzw. die IP des Containers) und können uns mit den eben angelegten Benutzer anmelden.

wekan open source

Nun können wir neue Boards in diesen neue Listen und Karten erstellen. Die Funktionsweise ist dem von Trello sehr ähnlich.

Fazit

Wer nach einer Open Source Alternative für Trello sucht, die man selber hosten kann, findet in Wekan einen guten Ersatz. Ich habe bisher oft Trello verwendet. Mit Wekan habe ich endlich einen Ersatz gefunden, der so ziemlich ein 1:1 Ersatz für Trello ist.

Der Beitrag Wekan – eine Open Source Trello Alternative erschien zuerst auf zefanjas.

Netzwerkbrücke für LXD Container einrichten

✇Zefanjas
Von: zefanja

Die meisten unserer Webanwendungen laufen in LXD Containern. Nicht ohne Grund ist LXD für mich eines der wichtigsten Features von Ubuntu Server. Es gibt viele Wege um von außen auf eine Webanwendung in einem LXD Container zuzugreifen. So kann man z.B. einen Reverse Proxy nehmen und darüber die Zugriff auf die Container regeln (hier hatte ich schon mal davon berichtet). Eine andere Möglichkeit ist die Einrichtung einer Netzwerkbrücke, sodass sich die Container im gleichen Netz wie der Containerhost (Ubuntu Server) befinden. In diesem Artikel möchte ich kurz beschreiben, wie man eine Netzwerkbrücke für LXD Container einrichtet.

Netzwerkbrücke für LXD Container

Um eine Netzwerkbrücke unter Ubuntu einzurichten, muss man die bridge-utils installieren:

$ apt install bridge-utils

Danach kann man die Netzwerkbrücke einrichten.

bis Ubuntu 16.04

Bis Ubuntu 16.04 nutzt Ubuntu ifupdown um Einstellungen für die Netzwerkverbindungen festzulegen. Die Konfiguration nimmt man in den Dateien unter /etc/network/ vor. Eine einfache Netzwerkbrücke, um die Container in das Host-Netzwerk zu bekommen, könnte so aussehen:

$ cat /etc/network/interfaces
# 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 main Bridge
auto br0
iface br0 inet dhcp
    bridge-ifaces enp4s0
    bridge-ports enp4s0
    up ip link set enp4s0 up

# The primary network interface
iface enp4s0 inet manual

Hier bekommt die Brücke ihre Adresse vom DHCP-Server mitgeteilt. Die reale Netzwerkkarte enp4s0 wird in den manuellen Modus gesetzt und der Brücke zugewiesen.

ab Ubuntu 18.04

Ab Ubuntu 18.04 wird Netplan für die Konfiguration der Netzwerkverbindungen verwendet. Die Konfigurationsdateien befinden sich unter /etc/netplan/. Eine Definition für die Brücke könnte folgendermaßen aussehen:

$ cat /etc/netplan/50-cloud-init.yaml 
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp3s0:
            dhcp4: no
    version: 2
    bridges:
        br0:
            dhcp4: no
            addresses:
            - 10.10.10.5/24
            gateway4: 10.10.10.254
            nameservers:
                addresses:
                - 10.10.10.254
            interfaces:
            - enp3s0

Im oberen Teil konfiguriert man die reale Netzwerkkarte (enp3s0) und weißt ihr keine Adresse zu. Danach folgt die Definition der Netzwerkbrücke. Sie wird wie eine statische Netzwerkverbindung eingerichtet und enthält zusätzlich den Punkt interfaces. Dort legt man fest, welche reale Netzwerkkarte „überbrückt“ werden soll. Weitere (komplexere) Beispiele zu Netzwerkbrücken gibt es auf der offiziellen Website.

Nun werden mit dem folgenden Befehl die Änderungen an den Netzwerkeinstellungen angewendet:

$ netplan apply  --debug

Netzwerkbrücke zuweisen

Hat man die Netzwerkbrücke fertig eingerichtet und bekommt sie auch die richtige IP-Adresse, muss man dem LXD Container noch mitteilen, dass er seine IP-Adresse über die Netzwerkbrücke beziehen soll. Das erledigt man mit folgendem Befehl:

$ lxc config device add containername eth0 nic nictype=bridged parent=br0 name=eth0

Mit name=eth0 legt man fest, unter welchen Namen man die Netzwerkkarte im Container findet. Nun kann man im Container eth0 nach Belieben konfigurieren. Ab sofort sollte der Container eine IP-Adresse aus dem Host-Netzwerk bekommen.

Fazit

Eine einfache Netzwerkbrücke lässt sich schnell einrichten und man kann sie ohne Probleme einem Container zuweisen. Andere Benutzer im Netzwerk können so ohne die Einrichtungen eines Reverse-Proxys auf eine Webanwendung zugreifen. Auch komplexere Szenarien sind denkbar (VLANs, mehrere Brücken, um die Container in verschiedene Netz zu bekommen etc.), doch das würde den Rahmen dieses kurzen Artikels sprengen.

3 Kommentare

Der Beitrag Netzwerkbrücke für LXD Container einrichten erschien zuerst auf .:zefanjas:..

❌