SUSE has just released the third prototype of ALP, named “Piz Bernina” (the highest mountain in the Swiss Alps).  The new prototype has a strong focus on security and demonstrates an innovative concept with confidential computing and a zero-trust approach. 

ALP stands for SUSE’s Adaptable Linux Platform, providing a new approach to enterprise Linux for evolving use cases in a cloud-native world – from core to cloud to edge. ALP is an application-centric, secure, and flexible platform designed to focus on workloads while abstracting from the hardware and the application runtime layers. Every three months we publish a new prototype with newly implemented features, approaches, and significant changes. 

Credits: Xavier von Erlach on Unsplash

SUSEs newly published ALP “Piz Bernina” consists of two separate prototypes which are momentarily close to each other, but will in the future deviate according to different use-cases and as more services are added: 

• the server-oriented version (codename “Bedrock”) 
• the cloud-native oriented version (codename “Micro”) 

Major changes in Piz Bernina 

The new SUSE ALP Piz Bernina focuses on security and provides many enhancements from our previous December prototype (Punta Baretti):  

• Confidential Computing: provides a Trusted Execution Environment that protects data in use by isolating, encrypting, and executing virtual machines. 
• Hardware and runtime attestation to verify the integrity of workloads and together with FDE (Full Disk Encryption) mark the starting point for end-to-end data security. 

• Foundation for future extended Confidential Virtual Machine support (CVM), covering support for more hardware vendors and making use of the most recent hardware for confidential computing.  
• Integration of NeuVector: to support a secure ecosystem, ALP-users can run NeuVector to identify malicious behaviors and prevent those affecting the underlying host OS or potentially other containerized workloads.  
• Support for s390x architecture: in addition to the already supported x86_64 and aarch64 architectures. 
• FDE (Full Disk Encryption) with TPM can now be selected at installation-time to support data security at rest. 

With NeuVector running on Piz Bernina, SUSE secure software supply chain gets stronger than ever, starting with source code analysis, a certified build system environment producing the distributions and artifacts like packages and containers, and now a runtime scanner for malicious workloads. Once installed and enabled on ALP system, NeuVector will automatically scan all running containers on the system, detect potential vulnerabilities and other threats. It will learn how containers behave and allow users to put some additional restrictions based on this learning. 

Enhanced Full Disk Encryption and Data Security 

The previously introduced FDE (Full Disk Encryption) with TPM (Trusted Platform Module ) is now available to be selected at installation-time to support data security at rest.  

What has changed from the previous December prototype Punta Baretti is that everything works equally with both LVM (Logical Volume Manager) and plain partition. An important change for usability is now there is no need to enter the passphrase on the first boot. As an engineer in you may wonder: “how can you do that?”. The non-interactive first boot is possible because we have the temporary passphrase hardcoded in the Grub2 configuration – which, of course, is fully erased (from both the encryption device and the Grub2 configuration) during the first boot and, soon after that, the TPMv2 is configured and fully utilized for all subsequent boots.  

With new support for FDE with TPM and confidential computing, ALP “Piz Bernina” provides an all-in-one security solution for all types of data, from data-at-rest to data-in-transit to data-in-use. 

Finally, Piz Bernina is adding support for the s390x architecture on top of the already supported x86_64 and aarch64 architectures. 

Useful links: 

• Pre-builds VMs:  

• https://download.opensuse.org/repositories/SUSE:/ALP:/Products:/Bedrock:/0.1/images/ 
• https://download.opensuse.org/repositories/SUSE:/ALP:/Products:/Micro:/0.1/images/

• Installer 

•  https://download.opensuse.org/repositories/SUSE:/ALP:/Products:/Installer:/0.8/images/iso/  

• https://documentation.suse.com/alp/bedrock/ 
• https://documentation.suse.com/alp/micro/ 

• Sam Varghese at iTWire in conversation with Vojtech Pavlik on confidential computing and zero-trust: https://itwire.com/business-it-news/open-source/suse-claims-new-era-of-confidential-computing-through-its-adaptable-linux-platform.html 

December is here and it is time to deliver the next version of the ALP  project, which we call “Punta Baretti”. For those wondering, ALP stands for ‘Adaptable Linux Platform’.

Back in September, we unveiled the ALP. Before jumping into Punta Baretti, let’s recap what ALP is.

What is ALP?

ALP is the next generation of Linux, an application-centric, secure and flexible platform designed to focus on workloads while abstracting from the hardware and the application runtime layers.

Punta Baretti is one of the prototypes based on ALP where we implemented features, approaches and relevant changes. There will be also other deliverables builds all based on ALP to come!

The products and solutions based on ALP use containerized workloads to isolate different processes at the application layer. These are managed using K3s for Kubernetes-based workloads or Podman for non-k8s workloads. This approach adds extra flexibility while keeping the deployment and management of workloads persistent, easy and stable.

ALP’s ‘Zero-Touch’ approach makes systems management, patching, and upgrading more stable, reliable and secure.

Major Changes in Punta Baretti

D-Installer

D-Installer is a new Linux installer that comes from the YaST team. It is designed to offer re-usability, integration with third-party tools, and the possibility of building advanced user interfaces over it.

In a secure environment, D-Installer can deploy ALP on encrypted volumes using FDE (Full Disk Encryption).

A customized LUKS2, compatible with GRUB, opens the door to using TPM (Trusted Platform Module) to decrypt the boot volume, so keys stored on the TPM chip can be used instead of passwords.

This allows us to get closer to highly secure deployments with no-user interaction at boot time.

Containerized YaST

Containerized YaST available in ALP since its inception. This allows users to run package management and other modules as first-class workloads following the ALP model.

• Many YaST clients have already adapted to run in containers: bootloader, iSCSIClient, Kdump, firewall, etc.
• Several modules have been adapted to work in transactional systems although currently some clients work only in the non-transactional variant of ALP.
• Implemented initial support for transactional systems handling when some packages need to be installed.
• Make libyui-rest-api available at the containers for openQA. This allows the containerized version of YaST to be integrated with openQA, leveraging the extensive sets of tests already available to greatly improve the quality of current and future releases.

All YaST containers are currently available through the project on the Open Build Service – https://build.opensuse.org/project/show/SUSE:ALP:Workloads.

Two types of containers are provided:

• Management Containers, to work with YaST on text, GUI and Web modes.
• Testing Containers, designed for automated testing of the YaST containerized workload, not intended for Production.

Those containerized YaST versions can run not only on ALP but also on the latest SLE, openSUSE Leap, or openSUSE Tumbleweed, using Podman, docker or any other container engine.

Cockpit

Cockpit is now containerized and available as an ALP workload. Once deployed, you can use Cockpit to manage your servers using just a web browser.

One of the key highlights in this release is Cockpit becoming the default 1:1 system management for ALP.

If you are interested in what’s new in this release or in testing the deployment and execution of Cockpit as a containerized workload, take a look here.

Full Disk Encryption (FDE)

ALP is designed to run securely on both private and/or public clouds, relying on features like FDE (Full Disk Encryption).

Regarding security, the Zero-Touch approach means volumes can be decrypted at boot time through the usage of encryption keys instead of a password. The use of encrypted volumes adds an additional layer of security to all ALP workloads.

To achieve this, the team decided to move on with the following additions to Punta Baretti:

• GRUB2 will be the new bootloader for ALP.
• FDE (Full Disk Encryption) is now available on bare-metal servers

New ALP workloads

There are new workloads available at online repositories:

• firewalld-container
• warewulf-container

Conclusion

We received a lot of feedback since September 2022 when the first prototype was released. There are now a lot of active discussions, tests, setups, and engineering involved in building the next generation of Linux!

This major release makes ALP more flexible, secure and stable. Punta Baretti has extended the FDE support to bare metal servers. By using the Trusted Platform Module we have allowed for unattended booting while keeping the systems encrypted and secured.

After some compatibility issues, SELinux has been moved to ‘enforced’ and Firewalld defaulted to ‘deny’.

The integration within the D-Installer increases the possibility of different deployment configurations.

The new Punta Baretti prototype is now available, go ahead and test it out!

Next Steps

ALP is driven by the workgroups; if you are interested in joining the discussion, you can find them here.

Documentation for ALP is now updated with Punta Baretti.

Download ALP  images

The following article has been contributed by Tanja Roth, Project Manager Technical Documentation at SUSE.

With the release of the Adaptable Linux Platform (ALP) prototype ‘Les Droites’ in September, the first Alpine summit of more than 4,000 meters has been reached. As the Adaptable Linux Platform is a shift towards a modular operating system, what would be more natural than to accompany it with modular documentation? Since the initial publication of the ‘SUSE Smart Docs’ pilot last year, which is based on this approach, the collection of articles on the ‘Smart Docs’ beta documentation page has grown.

Modular documentation

Now – in parallel with ALP development breaking new ground – for the first time the SUSE documentation team applied modular writing principles to a larger amount of documentation (which we mostly had to create from scratch). The content was broken down into brief self-contained units which fulfilled a specific purpose. Each unit provides either of the following:

• Step-by-step procedure

Current example: Enabling Podman
https://documentation.suse.com/alp/all/html/alp/concept-containers-podman.html#task-enable-podman

• Explanation of a concept

Current example: Concepts of the Adaptable Linux Platform
https://documentation.suse.com/alp/all/html/alp/concept-alp.html

• Reference

Current example: Available workloads for the Adaptable Linux Platform
https://documentation.suse.com/alp/all/html/alp/concept-alp.html#reference-available-alp-workloads

Higher flexibility

At first sight, the recently published ALP documentation does not look much different from our SUSE Linux Enterprise documentation.

This is because for the first ALP prototype, we have bundled those content units into a bigger entity – and published them as ALP Guide. But this is part of the flexibility of this new approach:

From the content building blocks in the back-end, we still have the possibility to publish a consecutive piece of documentation at the front-end. At the same time, the modular writing approach allows us to assemble the building blocks in multiple ways and to reuse them within different contexts – similar to a LEGO building kit.

Reaching the next peaks

So for now, the major changes are mainly ‘under the hood’. They consisted primarily of applying the modular writing principles on a bigger scale. And we have adjusted the documentation infrastructure to provide more flexibility for the future documentation approach. But there is much more to come. Stay tuned for more visible changes with the next ALP prototypes!

The Concept

The Adaptable Linux Platform (ALP) is switching from the UNIX-style centered, influenced structure of previous operating systems to a more workload and application-centric design. A flexible and secure platform with advancing concepts, as seen in both MicroOS and SLE Micro, along with the incorporation of other components, is evolving. This platform is designed to easily build, deploy and manage applications regardless of hardware or environment.

Separating the hardware enablement in a Host OS and a (containerized) Application Layer provides an immutable platform for workloads and workload runtime environments.

While the Adaptable Linux Platform proof of concept is not provided with desktop, the addition of desktop to ALP will be done in following releases:

ALP is Built and tested in public instances of OBS and openQA.

The Components

The prototype consists of an immutable image and an orchestrator providing application-layer features.

OpenSUSE MicroOS will serve as a base operating system for the container orchestrator.

Container orchestrators, so far, k3s. Podman is also available for non-k8s workload.

As a prototype, MicroOS and k3s will be used for each layer; the roadmap shows there will be more container orchestrators with a final version that could include a variation of MicroOS instead of the official one.

The Characteristics

This prototype includes the following characteristics and principles:

Full disk encryption

The encryption on ALP is specifically designed to manage encrypted devices that do not have any human interaction. For instance, patch management, which is ideal for edge architecture, it is done by using Trusted Platform Module (TPM) using cryptographic keys

Self-healing and self-management

ALP leverages self-healing and self-management features from a containerized perspective. Both these features can identify and perform tasks considering not only the OS but the containerized layer; no OS tasks will be disruptive to the workload.

Multi-versions stack

Environments must be flexible and agile states, which sometimes causes multiple dependencies if you are working with Python, Java, Node, or any other programming language. This could result in a messy environment – dealing with incompatibilities between these dependencies, packages, libraries or tools.

ALP addressed that with Base Container Images (BCI) to create independent stacks that make the developer’s life easier.

To manage multi-stack environments coexistence, ALP is developed by these principles:

• Ease of installation: Users can create, manage, update and delete stacks independently without affecting other developing environments.
• Security checks via k8s webhook/plugin: Using the capabilities provided by the orchestrator, the code can be followed to prevent any potential attacker interfering through the usage of sigstore/cosign.

ALP is designed to be flexible and agile to provide users the stack they need to develop and manage their platforms and workloads.

The Proof of Concept

Proof of concepts should have the following considerations:

• Time frame: As per current development, Proof of Concept (PoC) should be considered for a short-time frame (3 months).
• Adding value: The content must include the specific value added by ALP with a clear differentiation between ALP and SLE.
• Coherent fashion: Delivering the PoC in a way that can be shared with partners and some other relevant actors, it should also include market research people.
• Baseline: ALP should be considered the baseline for the PoC, avoiding disaggregation between the layers inside. To be clear, there is no SLE + k3s, but ALP as a base concept and can be built on top of ALP.
• Qualifying out scenarios: ALP is a prototype of a concept that is not for all scenarios; the PoC does not need to work for all scenarios or platforms.

Available References

OpenSUSE ALP Community update https://news.opensuse.org/tag/adaptable-linux-platform

We do publish weekly updates on Community Work Group: https://en.opensuse.org/openSUSE:ALP/Workgroups/Community

On Day two, June 3,  of the openSUSE Conf 2022 the main event was the discussion of the ALP Steering Committee with the openSUSE community. ALP, the Adaptable Linux Platform, stands for the next generation of the SUSE Linux family. As intro to the event Michal Svec, SUSE Product Manager for SLES, explained what it is all about. ALP stands for a new approach, for a new thinking out of the Box when it comes to Linux, especially to the openSUSE/SUSE Linux distro.

Michal is member of the Steering Committee together with Anja Stock, Director Program Management Linux Systems, and her team: Jiri Srain, Alex Herzig, Lubos Kocman, Pavel Niahodkin, Stefan Weiberg, all SLE Release and Project Managers. They all were available on Stage to answer the community questions.

ALP is mainly split into two parts: the workload part with the possibility to apply different life cycles for specific workloads and exchange components over the life time. And the host part that is minimale and more stable. The idea is that the host part will be stripped down to its core functionality, even more down as the current SUSE Product SLE Micro. Features like ignition or combustion should be included, everything else as minimal as possible. “We do not need Python in the base OS” said Thorsten Kukuk, SUSE Architect for SLE Micro. But “options are wide open” so far, nothing is decided yet as the Steering Committee emphasised.

A longer discussion evolved around the topic of older versus newer Python or Ruby versions. One solution could be to provide multiple versions of the scripting language in the product. Especially when they are packed in Containers a lot of more flexibility is possible then with the current Leap 15.4 or SLE 15 SP4. Agreement was also that a python version in a distro is both “too old” and “too new”, depending on which user you ask.

Another question was that it is a lot of work to move existing applications into Containers and what tools are around for that. Michal Svec explained that there are some tools around but not many yet. On the other hand there are already a lot of Docker container available, so the work is “done” already to some extend. What is also needed are tutorials and trainings for developers to help them move missing applications to containers if needed.

Last but not least Lubos Kocman encouraged the community to get engaged, to get your hands on the already existing project in the Open Build Server and to get loud in the openSUSE mailing lists.

See also my blog about Day One of the conf: Impressions from the openSUSE Conf 2022 – Day One: openQA and BCI

SUSE Linux, the international technology leader and solutions provider in Open Source operating system software,announced the shipping of SUSE Linux 7.1 for Compaq’s Alpha Server. By porting the latest SUSE distribution to Compaq’s 64-bit technology, SUSE proves itself again as a leading provider of Linux server solutions.SUSE Linux for AlphaServers is available directly from SUSE as well as from bookstores and software retailers at a recommended retail price of $ 49.95.

SUSE Linux for AlphaServers comes with the proven Linux Kernel 2.2.19 as well as the latest Kernel 2.4.4 as a special bonus for technophile users. With more than 1,200 programs included, SUSE Linux for AlphaServers provides a comprehensive array of applications. The system offers professional Linux solutions for virtually any utilization area. Apart from Internet and network tools, SUSE Linux 7.1 for AlphaServers comes with a wide range of database applications, development tools, office and image processing software, and window managers. A user may select among two graphical user interfaces, KDE 2.1 or GNOME 1.2.

SUSE Linux 7.1 for AlphaServers will be delivered on 6 CDs with a 500-page manual.The 60-day installation support, which is included in the purchase price, provides assistance for the installation.

Due to the timing of the recent release of the SUSE Linux 7.2 version, we will not be releasing a version of 7.2 for Alpha as well as for the PowerPC, but focusing the development of these products for the subsequent release of SUSE Linux beyond 7.2

To learn more about the SUSE Products, visit suse.com/shop/

About Novell
Novell, Inc. is a leading provider of information solutions that deliver secure identity management (Novell® Nsure™), Web application development (Novell exteNd™) and cross-platform networking services (Novell Nterprise™), all supported by strategic consulting and professional services (Novell NgageSM). Active in the open source community with its Ximian and SUSE Linux brands, Novell is firmly committed to open source and offers comprehensive Linux products and services for the enterprise, from the desktop to the server. Novell’s vision of one Net – a world without information boundaries – helps customers realize the value of their information securely and economically. For more information, call Novell’s Customer Response Center at (888) 321-4CRC (4272) or visit http://www.novell.com. Press should visit http://www.novell.com/pressroom.

Novell is a registered trademarks; Nsure, exteNd and Nteprise are trademarks; and Ngage is a service mark of Novell, Inc. in the United States and other countries. SUSE is a registered trademark of SUSE Linux AG. * All third-party trademarks are the property of their respective owners.

Today, SUSE Linux, the international technology leader and solutions provider in Open Source operating system software, announced the release of SUSE Linux 7.0 for Alpha systems. The port of the current SUSE distribution to Compaq 64-Bit-technology, underlines SUSE technical competence as the leading provider of server solutions. In addition to the Alpha platform, SUSE Linux also supports Intel and PowerPC as well as the SPARC and S/390 architectures.

“SUSE Linux with multi-platform support is an ideal uniform server platform for a professional environment,” explained Dirk Hohndel, CTO SUSE Linux AG. “The advantages of SUSE Linux are not limited to comprehensive network capabilities, stability, and flexibility. The possibility of a uniform and rational administration of heterogeneous networks helps minimize the expenditures for development or acquisition of strategic software products. Due to low acquisition costs and reduced long-term administration costs, SUSE Linux operating system contributes considerably to economical operation of large server farms.”

SUSE Linux for Alpha processors, which includes more than 1200 applications on 6 CDs, offers professional Linux solutions for virtually any purpose. In addition to Internet and network tools, SUSE Linux 7.0 for Alpha provides a wide range of database applications, developer tools, office and image processing software, and window managers. The package includes the graphical user interfaces KDE and the current GNOME desktop version.

The installation/configuration tool YaST provides the user with the whole range of configuration and administration functions. ATI and Matrox chipsets now benefit from the improved performance of XFree86 4.01. The configuration tool SaX2 ensures the easy installation and setup of graphics cards. Users now have all boot loaders for Alpha-Linux at their disposal – Milo 2.2, APB and Aboot 0.7a. The compilers for Compaq C, C++, Fortran and the respective math libraries are also new in this package.

The 490-page English manual is a valuable source for comprehensive information on SUSE Linux 7.0 for Alpha. Additionally, 60 days installation support is available. SUSE Linux 7.0 for Alpha can be obtained from SUSE or from software retailers from the beginning of December onwards. The suggested retail price is $49.95.

About Novell
Novell, Inc. is a leading provider of information solutions that deliver secure identity management (Novell® Nsure™), Web application development (Novell exteNd™) and cross-platform networking services (Novell Nterprise™), all supported by strategic consulting and professional services (Novell NgageSM). Active in the open source community with its Ximian and SUSE Linux brands, Novell is firmly committed to open source and offers comprehensive Linux products and services for the enterprise, from the desktop to the server. Novell’s vision of one Net – a world without information boundaries – helps customers realize the value of their information securely and economically. For more information, call Novell’s Customer Response Center at (888) 321-4CRC (4272) or visit http://www.novell.com. Press should visit http://www.novell.com/pressroom.

Novell is a registered trademarks; Nsure, exteNd and Nteprise are trademarks; and Ngage is a service mark of Novell, Inc. in the United States and other countries. SUSE is a registered trademark of SUSE Linux AG. * All third-party trademarks are the property of their respective owners.

Introduction

In this blogpost we will show how to use one of the new and interesting features Rancher 2.8 brings, Rancher Turtles, it will help you deploy clusters using Cluster API (CAPI).

It is an addition to the existing methods for deploying Kubernetes clusters using Rancher and it’s currently in early access technology state but expected to become fully supported in future versions.

Now with Rancher Turtles and the help of Fleet, Rancher’s GitOps tool, we can automate your clusters lifecycle on platforms that support CAPI in an easy manner.

When a provider supports CAPI, it means we can instruct them, using a common API, to provision and manage the resources we need for our cluster, without having to resort to use their platform-specific APIs. CAPI makes our job easier since we can have our Kubernetes clusters in a hybrid environment without too much customization and this allows us to easily switch providers if there is a need to do so.

What is CAPI?

CAPI stands for Cluster API and it is a “Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.” ( source: https://cluster-api.sigs.k8s.io/ ).

It is meant to help manage the lifecycle of Kubernetes clusters, independently if they are deployed on premises or in the cloud, making it platform agnostic, allowing you to define common cluster operations.

It is not meant to manage the lifecycle of the infrastructure underneath the clusters that is not required for Kubernetes to run, manage clusters spanning across different infrastructure providers or to configure cluster nodes other than at the creation or upgrade times.

For more information we recommend you to check The Cluster API Book ( specially the introduction and concepts part )

Setup Rancher Turtles (optional)

As mentioned in the introduction, Rancher Turtles is the technology that allows us to integrate with different CAPI providers, it doesn’t come by default with older versions of rancher but if you want to try it on an older cluster, this is how it can be done.

Requirements: Rancher 2.7 or higher

From the console, disable the embedded CAPI feature:

kubectl apply -f feature.yaml

---
apiVersion: management.cattle.io/v3
kind: Feature
metadata:
name: embedded-cluster-api
spec:
value: false
...

kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration

kubectl delete validatingwebjookconfigurations.admissionregistration.k8s.io validating-webhook-configuration

Add the Rancher Turtles repository

Now we switch to the management cluster, and add the Rancher Turtles application repository:

helm repo add turtles https://rancher-sandbox.github.io/rancher-turtles

Install Rancher Turtles

helm -n rancher-turtles-system install rancher-turtles --create-namespace --set cluster-api-operator.cert-manager.enabled=false

Please note that Cert Manager is currently a requirement for Rancher Turtles. In this example we assume it’s installed, but, if you wish for the operator to install it automatically, please set cluster-api-operator.cert-manager.enabled=true (default option).

Install additional CAPI provider

kubectl apply -f capd-provider.yml

---
apiVersion: v1
kind: Namespace
metadata:
name: capd-system
...
---
apiVersion: operator.cluster.x-k8s.io/v1alpha1
kind: InfrastructureProvider
metadata:
name: docker
namespace: capd-system
spec:
secretName: capi-env-variables
secretNamespace: capi-system
...

After this we are ready to provision a new cluster following GitOps principles.

Provisioning a new cluster following GitOps with Fleet!

We have talked about how CAPI makes it easy for you to deploy clusters in different platforms without having to learn new APIs and apply a lot of customization for each of them, now we are going to show you how we can use this CAPI definitions with Fleet to manage Kubernetes clusters following GitOps principles.

This will be the process:

After the repository is configured in Fleet or, later on, when somebody makes a change to it.

Fleet will check those changes and when a CAPI cluster definition is found, Fleet will pass it on to Rancher Turtles.

Afterwards Turtles will process the file and contact the CAPI provider/s specified which will proceed to create the Cluster/s:

Since we are talking about new features and Fleet, it is worth mentioning the new coming version of Fleet incorporates a particularly exciting feature:

Drift reconciliation

With this we can now tell fleet that if a resource doesn’t match what has been defined in our GIT repository, it should overwrite it to leave it in the same state, we will create a new blog post about it with more details.

Configure Fleet

First, we will add our git repository to fleet, where we have the instructions.

Remember fleet by itself doesn’t deploy any cluster, it just triggers the process; the actual deployment is executed by the infrastructure provider.

kubectl apply -f myclusters-repo.yaml

---
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: clusters
namespace: fleet-local
spec:
repo:
https://github.com/rancher-sandbox/rancher-turtles-fleet-example.git
branch: main
paths:
- clusters
...

With this, when fleet detects a change in the repository “main” branch, on the path “/clusters”, it will apply the changes we have defined automatically.

Please note this is just an example, we can customize this repository definition to incorporate more complex conditions but the same concept remains.

So the process of adding clusters is streamlined; creating the cluster definition and approving the pull request should be the only steps required to have a new cluster ready.

Extra: Did you notice we are deploying on fleet-local namespace? If you are curious and want to know more please follow this link.

Configure rancher

Now we can go to rancher and indicate that we want to auto import all the clusters in the namespace where we load the CRDs.

To do so we will simply run the following command to enable rancher-auto-import feature

kubectl label namespace <mynamespace> cluster-api.cattle.io/rancher-auto-import=true

Notice in this example, the cluster definitions are introduced in the namespace “default”.

After a while we can see in Rancher “Cluster Management” section the new cluster has been imported and appears like any other cluster we are managing.

Explore the newly deployed cluster using CAPI

By clicking on the “Explore” button on the right side of the cluster we can manage it like with any other cluster in rancher.

If we copy the kubeconfig into our system and, for concenience, we run the following command to set it as the default to be used by kubectl and other tools:

export KUBECONFIG=<my-new-cluster-kubeconfig-file>

Or specify it on the command line of our tool of choice.

We can start running commands to verify it works, for example:

kubectl get pods -A -w --insecure-skip-tls-verify

Which should show us the pods running on the new cluster.

Conclusion

We have seen how easy it is to do GitOps with Rancher and Fleet by using CAPI and how this new feature opens new possibilities for automation and easy management of Kubernetes clusters.

We have seen how we can do this from the command line, but in the future Rancher will incorporate an UI extension to manage Turtles directly from the web UI, stay tuned!

For more information about Rancher Prime and how we can help your business to grow further and be more secure and agile with containers technology please visit our website.

If you want to learn more about Rancher, please feel free to download our free “Why rancher?” whitepaper, join one of our Rancher Rodeos or join Rancher Academy.

👉 For more information about SUSE products and services, please don’t hesitate to contact us.