New “netplan status –diff” subcommand, finding differences between configuration and system state
As the maintainer and lead developer for Netplan, I’m proud to announce the general availability of Netplan v1.0 after more than 7 years of development efforts. Over the years, we’ve so far had about 80 individual contributors from around the globe. This includes many contributions from our Netplan core-team at Canonical, but also from other big corporations such as Microsoft or Deutsche Telekom. Those contributions, along with the many we receive from our community of individual contributors, solidify Netplan as a healthy and trusted open source project. In an effort to make Netplan even more dependable, we started shipping upstream patch releases, such as 0.106.1 and 0.107.1, which make it easier to integrate fixes into our users’ custom workflows.
With the release of version 1.0 we primarily focused on stability. However, being a major version upgrade, it allowed us to drop some long-standing legacy code from the libnetplan1 library. Removing this technical debt increases the maintainability of Netplan’s codebase going forward. The upcoming Ubuntu 24.04 LTS and Debian 13 releases will ship Netplan v1.0 to millions of users worldwide.
Highlights of version 1.0
In addition to stability and maintainability improvements, it’s worth looking at some of the new features that were included in the latest release:
Simultaneous WPA2 & WPA3 support.
Introduction of a stable libnetplan1 API.
Mellanox VF-LAG support for high performance SR-IOV networking.
New hairpin and port-mac-learning settings, useful for VXLAN tunnels with FRRouting.
New netplan status –diff subcommand, finding differences between configuration and system state.
Besides those highlights of the v1.0 release, I’d also like to shed some light on new functionality that was integrated within the past two years for those upgrading from the previous Ubuntu 22.04 LTS which used Netplan v0.104:
We added support for the management of new network interface types, such as veth, dummy, VXLAN, VRF or InfiniBand (IPoIB).
Wireless functionality was improved by integrating Netplan with NetworkManager on desktop systems, adding support for WPA3 and adding the notion of a regulatory-domain, to choose proper frequencies for specific regions.
To improve maintainability, we moved to Meson as Netplan’s buildsystem, added upstream CI coverage for multiple Linux distributions and integrations (such as Debian testing, NetworkManager, snapd or cloud-init), checks for ABI compatibility, and automatic memory leak detection.
We increased consistency between the supported backend renderers (systemd-networkd and NetworkManager), by matching physical network interfaces on permanent MAC address, when the match.macaddress setting is being used, and added new hardware offloading functionality for high performance networking, such as Single-Root IO Virtualisation virtual function link-aggregation (SR-IOV VF-LAG).
The much improved Netplan documentation, that is now hosted on “Read the Docs”, and new command line subcommands, such as netplan status, make Netplan a well vested tool for declarative network management and troubleshooting.
Integrations
Those changes pave the way to integrate Netplan in 3rd party projects, such as system installers or cloud deployment methods. By shipping the new python3-netplan Python bindings to libnetplan, it is now easier than ever to access Netplan functionality and network validation from other projects. We are proud that the Debian Cloud Team chose Netplan to be the default network management tool in their official cloud-images for Debian Bookworm and beyond. Ubuntu’s NetworkManager package now uses Netplan as it’s default backend on Ubuntu 23.10 Desktop systems and beyond. Further integrations happened with cloud-init and the Calamares installer.
In der heutigen schnelllebigen digitalen Landschaft ist Multi-Cloud-Hosting nicht nur ein Buzzword, sondern eine wesentliche Komponente für Unternehmen, die nach Robustheit, Flexibilität und Skalierbarkeit in ihrer Online-Präsenz streben. Während traditionelles Webhosting auf einem einzelnen Server oder innerhalb eines einzigen Cloud-Anbieters beruht, ermöglicht Multi-Cloud-Hosting die Verteilung von Ressourcen über mehrere Cloud-Plattformen hinweg. Diese innovative Hosting-Lösung bietet eine einzigartige Kombination aus Vorteilen, darunter verbesserte Ausfallsicherheit, optimierte Leistung und erhöhte Flexibilität, die sie besonders attraktiv für Webhosting-Experten und technikaffine Unternehmen macht. Die Implementierung einer Multi-Cloud-Strategie kann jedoch komplexe Herausforderungen mit sich bringen, von der Datenmigration bis hin zur Sicherheit und Kostenkontrolle. Daher ist ein tiefgreifendes Verständnis sowohl der Vorteile als auch der Implementierungsstrategien von entscheidender Bedeutung, um die Potenziale von Multi-Cloud-Hosting vollständig ausschöpfen zu können.
1. Verständnis der Multi-Cloud-Umgebung: Grundlagen und Key-Player
Multi-Cloud-Hosting umfasst die Nutzung von Cloud-Diensten verschiedener Anbieter, um eine diversifizierte Hosting-Umgebung zu schaffen. Diese Strategie ermöglicht es Unternehmen, die Stärken einzelner Cloud-Provider zu nutzen, während sie gleichzeitig Abhängigkeiten reduzieren und die Ausfallsicherheit verbessern. Zu den Key-Playern in der Multi-Cloud-Umgebung gehören große Cloud-Plattformen wie Amazon Web Services, Microsoft Azure, Google Cloud Platform und IBM Cloud, die jeweils einzigartige Dienste und Preismodelle bieten. Durch das Verständnis der spezifischen Funktionen und Angebote jedes Anbieters können Unternehmen eine Multi-Cloud-Strategie entwickeln, die ihre spezifischen Bedürfnisse erfüllt. Wesentlich ist dabei die Bewertung von Faktoren wie Performance, Sicherheit, Compliance und Kosten, um eine ausgewogene und effektive Cloud-Lösung zu konzipieren.
2. Die Vorteile von Multi-Cloud-Hosting: Flexibilität, Skalierbarkeit und Risikominimierung
Der entscheidende Vorteil des Multi-Cloud-Hostings liegt in seiner unübertroffenen Flexibilität und Skalierbarkeit. Unternehmen können Ressourcen dynamisch zuweisen oder entziehen, um auf Nachfrageschwankungen zu reagieren, ohne an die Grenzen eines einzigen Anbieters gebunden zu sein. Diese Flexibilität ermöglicht eine optimale Performance und Effizienz, insbesondere bei der Handhabung von Spitzenlasten oder global verteilten Nutzern. Darüber hinaus trägt die Diversifizierung der Cloud-Dienste zur Risikominimierung bei, da die Abhängigkeit von einem einzigen Anbieter verringert wird, was die Resilienz gegenüber Ausfällen und anderen Störungen verbessert.
3. Strategien zur Implementierung von Multi-Cloud-Hosting: Best Practices für Experten
Die Implementierung von Multi-Cloud-Hosting erfordert sorgfältige Planung und Strategie. Zu den Best Practices gehören die Bewertung der eigenen Bedürfnisse und Ziele, die Auswahl kompatibler Cloud-Dienste und die Entwicklung eines kohärenten Datenmanagements und einer Governance-Struktur. Wichtig ist auch die Berücksichtigung von Aspekten wie Netzwerkdesign, Sicherheitsrichtlinien und Kostenmanagement. Durch die Entwicklung eines umfassenden Implementierungsplans, der Schulung von Personal und der Einrichtung effektiver Überwachungs- und Managementtools können Unternehmen die Vorteile des Multi-Cloud-Hostings maximieren und gleichzeitig potenzielle Fallstricke minimieren.
4. Herausforderungen und Lösungen im Multi-Cloud-Hosting: Sicherheit, Datenmanagement und Kostenkontrolle
Trotz seiner vielen Vorteile bringt Multi-Cloud-Hosting auch spezifische Herausforderungen mit sich, insbesondere in den Bereichen Sicherheit, Datenmanagement und Kostenkontrolle. Die Sicherheit in einer Multi-Cloud-Umgebung erfordert eine konsistente Anwendung von Sicherheitsrichtlinien und -verfahren über alle Cloud-Dienste hinweg. Datenmanagement in einer Multi-Cloud-Umgebung erfordert effektive Lösungen für Datenintegration, -qualität und -lebenszyklusmanagement, um Silos zu vermeiden und die Datenintegrität zu gewährleisten. Die Kostenkontrolle in Multi-Cloud-Umgebungen erfordert transparente Abrechnungsmodelle und kontinuierliches Monitoring, um unerwartete Kosten zu vermeiden. Durch die Adressierung dieser Herausforderungen mit strategischen Lösungen können Unternehmen die Effizienz und Sicherheit ihrer Multi-Cloud-Plattformen maximieren.
I’m happy to announce that Netplan version 0.107 is now available on GitHub and is soon to be deployed into a Linux installation near you! Six months and more than 200 commits after the previous version (including a .1 stable release), this release is brought to you by 8 free software contributors from around the globe.
Highlights
Highlights of this release include the new configuration types for veth and dummy interfaces:
Furthermore, we implemented CFFI based Python bindings on top of libnetplan’s API, that can easily be consumed by 3rd party applications (see full cffi-bindings.py example):
from netplan import Parser, State, NetDefinition
from netplan import NetplanException, NetplanParserException
parser = Parser()
# Parse the full, existing YAML config hierarchy
parser.load_yaml_hierarchy(rootdir='/')
# Validate the final parser state
state = State()
try:
# validation of current state + new settings
state.import_parser_results(parser)
except NetplanParserException as e:
print('Error in', e.filename, 'Row/Col', e.line, e.column, '->', e.message)
except NetplanException as e:
print('Error:', e.message)
# Walk through ethernet NetdefIDs in the state and print their backend
# renderer, to demonstrate working with NetDefinitionIterator &
# NetDefinition
for netdef in state.ethernets.values():
print('Netdef', netdef.id, 'is managed by:', netdef.backend)
print('Is it configured to use DHCP?', netdef.dhcp4 or netdef.dhcp6)
Linux networking can be confusing due to the wide range of technology stacks and tools in use, in addition to the complexity of the surrounding network environment. The configuration of bridges, bonds, VRFs or routes can be done programmatically, declaratively, manually or with automated with tools like ifupdown, ifupdown2, ifupdown-ng, iproute2, NetworkManager, systemd-networkd and others. Each of these tools use different formats and locations to store their configuration files. Netplan, a utility for easily configuring networking on a Linux system, is designed to unify and standardise how administrators interact with these underlying technologies. Starting from a YAML description of the required network interfaces and what each should be configured to do, Netplan will generate all the necessary configuration for your chosen tool.
In this article, we will provide an overview of how Ubuntu uses Netplan to manage Linux networking in a unified way. By creating a common interface across two disparate technology stacks, IT administrators benefit from a unified experience across both desktops and servers whilst retaining the unique advantages of the underlying tech.
But first, let’s start with a bit of history and show where we are today.
The history of Netplan in Ubuntu
Starting with Ubuntu 16.10 and driven by the need to express network configuration in a common way across cloud metadata and other installer systems, we had the opportunity to switch to a network stack that integrates better with our dependency-based boot model. We chose systemd-networkd on server installations for its active upstream community and because it was already part of Systemd and therefore included in any Ubuntu base installation. It has a much better outlook for the future, using modern development techniques, good test coverage and CI integration, compared to the ifupdown tool we used previously. On desktop installations, we kept using NetworkManager due to its very good integration with the user interface.
Having to manage and configure two separate network stacks, depending on the Ubuntu variant in use, can be confusing, and we wanted to provide a streamlined user experience across any flavour of Ubuntu. Therefore, we introduced Netplan.io as a control layer above systemd-networkd and NetworkManager. Netplan takes declarative YAML files from /etc/netplan/ as an input and generates corresponding network configuration for the relevant network stack backend in /run/systemd/network/ or /run/NetworkManager/ depending on the system configuration. All while keeping full flexibility to control the underlying network stack in its native way if need be.
Recent versions of Netplan are available and ready to be installed on many distributions, such as Ubuntu, Fedora, RedHat Enterprise Linux, Debian and Arch Linux.
Ubuntu
As stated above, Netplan has been installed by default on Ubuntu systems since 2016 and is therefore being used by millions of users across multiple long-term support versions of Ubuntu (18.04, 20.04, 22.04) on a day-to-day basis. This covers Ubuntu server scenarios primarily, such as bridges, bonding, VLANs, VXLANs, VRFs, IP tunnels or WireGuard tunnels, using systemd-networkd as the backend renderer.
On Ubuntu desktop systems, Netplan can be used manually through its declarative YAML configuration files, and it will handle those to configure the NetworkManager stack. Keep reading to get a glimpse of how this will be improved through automation and integration with the desktop stack in the future.
Cloud
It might not be as obvious, but many people have been using Netplan without knowing about it when configuring a public cloud instance on AWS, Google Cloud or elsewhere through cloud-init. This is because cloud-init’s “Networking Config Version 2” is a passthrough configuration to Netplan, which will then set up the underlying network stack on the given cloud instance. This is why Netplan is also a key package on the Debian distribution, for example, as it’s being used by default on Debian cloud images, too.
Our vision for Linux networking
We know that Linux networking can be a beast, and we want to keep simple things simple. But also allow for custom setups of any complexity. With Netplan, the day-to-day networking needs are covered through easily comprehensible and nicely documented YAML files, that describe the desired state of the local network interfaces, which will be rendered into corresponding configuration files for the relevant network stack and applied at (re-)boot or at runtime, using the “netplan apply” CLI. For example /etc/netplan/lan.yaml:
Having a single source of truth for network configuration is also important for administrators, so they do not need to understand multiple network stacks, but can rely on the declarative data given in /etc/netplan/ to configure a system, independent of the underlying network configuration backend. This is also very helpful to seed the initial network configuration for new Linux installations, for example through installation systems such as Subiquity, Ubuntu’s desktop installer or cloud-init across the public and private clouds.
In addition to describing and applying network configuration, the “netplan status” CLI can be used to query relevant data from the underlying network stack(s), such as systemd-networkd, NetworkManager or iproute2, and present them in a unified way.
At the Netplan project we strive for very high test automation and coverage with plenty of unit tests, integration tests and linting steps, across multiple Linux distros, which gives high confidence in also supporting more advanced networking use cases, such as Open vSwitch or SR-IOV network virtualization, in addition to normal wired (static IP, DHCP, routing), wireless (e.g. wwan modems, WPA2/3 connections, WiFi hotspot, controlling the regulatory domain, …) and common server scenarios.
Should there ever be a scenario that is not covered by Netplan natively, it allows for full flexibility to control the underlying network stack directly through systemd override configurations or NetworkManager passthrough settings in addition to having manual configuration side-by-side with interfaces controlled through Netplan.
The future of Netplan desktop integration
On workstations, the most common scenario is for end users to configure NetworkManager through its user interface tools, instead of driving it through Netplan’s declarative YAML files, which makes use of NetworkManager’s native configuration files. To avoid Netplan just handing over control to NetworkManager on such systems, we’re working on a bidirectional integration between NetworkManager and Netplan to further improve the “single source of truth” use case on Ubuntu desktop installations.
Netplan is shipping a “libnetplan” library that provides an API to access Netplan’s parser and validation internals, that can be used by NetworkManager to write back a network interface configuration. For instance, configuration given through NetworkManager’s UI tools or D-Bus API can be exported to Netplan’s native YAML format in the common location at /etc/netplan/. This way, administrators just need to care about Netplan when managing a fleet of Desktop installations. This solution is currently being used in more confined environments, like Ubuntu Core, when using the NetworkManager snap, and we will deliver it to generic Ubuntu desktop systems in 24.04 LTS.
In addition to NetworkManager, libnetplan can also be used to integrate with other tools in the networking space, such as cloud-init for improved validation of user data or installation systems when seeding new Linux images.
Conclusion
Overall, Netplan can be considered to be a good citizen within a network environment that plays hand-in-hand with other networking tools and makes it easy to control modern network stacks, such as systemd-networkd or NetworkManager in a common, streamlined and declarative way. It provides a “single source of truth” to network administrators about the network state, while keeping simple things simple, but allowing for arbitrarily complex custom setups. If you want to learn more, feel free to follow our activities on Netplan.io, GitHub, Launchpad, IRC or our Netplan Developer Diaries blog on discourse.
