Nachdem wir im Juni ein eigenes Plugin zur Integration des SUSE Customer Centers entwickelt und die Verbesserung der SUSE Unterstützung von orcharhino massiv verbessert haben, stand nun der Support von Debian basierten Systemen ganz oben auf unserer Agenda.

English Version

Zu Debian basierten Systemen zählen neben Debian selbst auch Linux Distributionen, die das "deb" Paket Format verwenden, sprich Distributionen wie Ubuntu oder Linux Mint (insofern dies jemand auf dem Server einsetzen möchte).

Doch was genau ist das Neue daran? Bisher konnte man mit orcharhino Debian Systeme installieren und diese dann per Puppet, Ansible oder SaltStack konfigurieren. Da das Paket Management für Debian in orcharhino noch nicht existierte, konnte man das Lifecycle Management für Debian Server über orcharhino nicht umsetzen. Jedoch ist dieses Feature der elementare Bestandteil unserer orcharhino Story: Deployment, Patch Management, Configuration Management.

Für einen Administrator ist es essentiell die Kontrolle darüber behalten, welche Pakete in welcher Version für die jeweiligen Server der unterschiedlichen Lifcecycle Environments wie Development, Testing und Production bereitgestellt werden. Nur so ist sichergestellt, dass die richtigen Pakete und Versionen bei einem Server installiert sind und ggf. über das Patch Management aktualisiert werden.

Wir haben in den letzten Monaten viel Zeit und Energie investiert, um dieses fehlende Puzzleteil unseren Kunden bereitzustellen. Mit dem Tech Preview Release anlässlich unseres Open Source Automation Days (http://www.osad-munich.de) haben wir diese Lücke geschlossen. Mit diesem Feature erweitern wir nicht nur unser Build-System maßgeblich, sondern haben wir auch viele Lines of Code bei einigen Open Source Projekten wie Pulp, Katello und Runcible geschrieben sowie unsere Debian Erweiterungen integriert.

Genug der Worte. Nun wollen Sie sicherlich sehen, wie das Paket Management für Debian umgesetzt ist.

Wie bei RPM basierten Systemen, benötigt man zuerst ein Produkt. In das Produkt können dann verschiedene Repositories hinzugefügt werden - wie z.B. "yum", "Puppet" oder eben auch "deb" für Debian basierte Systeme. Was bei "deb" zu beachten ist, ist dass die URLs der Repositories immer gleich sind und eine Unterscheidung von "Component", "Release", "Architecture" über einen Filter angegeben werden.

Nachdem man das Repository hinzugefügt hat, muss man es synchronisieren. Dabei werden alle Debian Pakete vom upstream Repository heruntergeladen, die auch dem Filter nach "Component", "Release" und "Architecture" entsprechen.

Über Content View wird das Lifecycle Management nun umgesetzt. Nach dem Anlegen einer neuen Content View, wählt man verschiedene Repositories aus, die innerhalb dieses Content Views verwaltet werden. Es können verschiedene Typen von Repositories zu einem Content View zusammengefasst werden. Wir haben den Typen "deb Repositories" hier hinzugefügt. In diesem Tab sieht man zum einen eine Liste von bereits dem Content View zugeordneten Repositories. Zum anderen, kann man weitere Repositories zuweisen.

Wie gewohnt muss man diesen Content View über "Publish" veröffentlichen und später über "Promote" der jeweiligen Lifecycle Environment zuweisen. Für unsere erste Veröffentlichung des Debian Supports war es das - fast. Kurz noch zur Verwendung des Content Views: Für RPM-basierte Systeme ist man gewöhnt, dass man über einen Activation Key Zugriff auf die bereitgestellten Content Views erhält. Hierhin wollen wir auch bei Debian kommen. Leider funktioniert das noch nicht so elegant, aber wir arbeiten mit Hochdruck daran.
Jedoch haben wir eine Möglichkeit geschaffen, mit der man den Content View trotzdem verwenden kann: Über ein von uns bereitgestelltes Provisioning Template wird beim Installieren des Debian Hosts die /etc/apt/sources.list manipuliert und dadurch die Repositories des Content Views automatisch eingetragen.
Dieses Provisioning Template wird über unseren orcharhino web installer automatisch installiert. Zudem wird sichergestellt, dass der Debian Host nur die Pakete in den Versionen bekommt, die über den Content View des jeweiligen Lifecycle Environmets konfiguriert sind.
Legt man einen neuen Debian Host an, werden die Pakete direkt über orcharhino bereitgestellt. Natürlich können die Konfigurationsdateien für die Debian, Ubuntu und andere Debian-basierte Systeme auch über Ansible, puppet oder SaltStack verwaltet werden.
In Zukunft wollen wir die Debian Systeme analog zu CentOS, Redhat oder SuSE verwalten. Bei uns im Entwickler-Team der ATIX AG steht der Debian Support nach wie vor ganz oben auf unserer Roadmap. Wir werden auch weiterhin mit der Foreman / Katello Community zusammenarbeiten, um die bestmögliche Debian Unterstützung für unsere Kunden in orcharhino zu leisten.

 

English Version

orcharhino goes the deb-way

After we developed our own plugin for the integration of the SUSE Customer Center in June and massively improved the SUSE support of orcharhino, support for Debian-based systems was at the top of our agenda.

In addition to Debian itself, we also count Linux distributions using the "deb" package format, i. e. distributions like Ubuntu or Linux Mint, as Debian-based systems.

But what exactly are the news here? Up to now you could install Debian systems with orcharhino and configure them using Puppet, Ansible or SaltStack. Because the Debian package management for Debian did not yet exist in orcharhino, it was not possible to implement the lifecycle management for Debian servers via orcharhino. However, this feature is the elementary part of our orcharhino story: Deployment, Patch Management, Configuration Management.

It is essential for an administrator to retain control over which packages are made available in which version for the respective servers of the different lifecycle environments such as development, testing and production. This is the only way to ensure that the correct packages and versions are installed on a server and, if necessary, updated via Patch Management.

We have invested a lot of time and energy in the last few months to make this missing piece of the puzzle available to our customers. With the Tech Preview Release on the occasion of our Open Source Automation Day (http://www.osad-munich.de) we have closed this gap. With this feature we not only extend our build system significantly, but we have also written many lines of code for open source projects such as Pulp, Katello and Runcible to integrate our Debian extensions.

But enough of words. Surely now you want to see how the package management for Debian is implemented.

Similar to RPM-based systems, you first need a product. Different repositories can then be added to the product - such as "yum","puppet" or "deb" for Debian based systems. What needs to be considered with "deb" is that the URLs of the repositories are always the same and a distinction is made between "Component","Release","Architecture" via a filter.

After adding the repository, you have to synchronize it. All Debian packages will be downloaded from the upstream repository, which are also in accordance with the filters for "Component", "Release" and "Architecture".

Content View now implements lifecycle management. After creating a new content view, you select different repositories that are managed within this content view. You can combine different types of repositories into one content view. We have added the type "deb repositories" here. In this tab you can see a list of repositories already assigned to the content view. On the other hand, you can assign further repositories.

As usual, you have to publish this content view via "Publish" and later assign it to the respective lifecycle environment via "Promote". And thats it for our first release of Debian support - almost. A brief comment on the use of the content view: For RPM-based systems, you are used to having an activation key to access the provided content views. This is also the point we want to reach with Debian. Unfortunately, it doesn't yet work as elegantly as we would like, however we are working hard to get it done as quickly as possible.
We have created a way to use the content view anyway: A provisioning template, provided by us, manipulates the /etc/apt/sources. list of the Debian host during the installation and automatically enters the repositories of the content view. With our orcharhino web installer this Provisioning Template is automatically installed. It also ensures that the Debian host gets only the packages in the versions provided by the content view of its lifecycle environment.
If you provision a new Debian host, the packages will be provided directly via orcharhino. Of course, the configuration files for Debian, Ubuntu and other Debian-based systems can also be managed via Ansible, puppet or SaltStack.
In the future we want to manage the Debian systems analogous to CentOS, Redhat or SuSE. Debian support is still at the top of our roadmap in the ATIX AG development team. We will continue to work with the Foreman / Katello community to provide the best possible Debian support for our customers in orcharhino.

Kommentieren

Sie können einen Kommentar abgeben, indem Sie das untenstehende Formular ausfüllen. Nur Text. Kommentare werden moderiert.