Νέα από τον πλανήτη…planet.ellak.gr Μοντέλα ανάπτυξης και συνεργασίας openSUSE και SLE

Τύποι διανομών Linux

Κάτι που δεν έχω καταπιαστεί σε κάποιο άρθρο είναι οι διαφορετικοί τύποι διανομών Linux που μπορείτε να βρείτε. Θα αναφέρω επιγραμματικά τους διαφορετικούς τύπους διανομών Linux, καθώς γνωρίζετε λίγο περισσότερα σχετικά με το τι είναι μια διανομή Linux και την εξήγηση της τρέχουσας σχέσης μεταξύ του openSUSE και του SLE.

Πρώτα λοιπόν, υπάρχουν τρεις βασικοί τύποι διανομών Linux που καθορίζονται από τους κύκλους κυκλοφορίας τους και, συνεπώς, από το κοινό τους:

Κυλιόμενη Έκδοση:

Τελευταία λέξη της τεχνολογίας
Κυκλοφορία το συντομότερο δυνατό (CI / CD)
Παραδείγματα: openSUSE Tumbleweed, ArchLinux, Manjaro, Gentoo

Τακτική Έκδοση:

Κυκλοφορία από μια έως δύο φορές το χρόνο
Ενημερώνει ολόκληρη τη διανομή σε κάθε κυκλοφορία
Παραδείγματα: Ubuntu, Fedora, Debian

Έκδοση μακροπρόθεσμης υποστήριξης / Εκδόσεις για επιχειρήσεις:

Αργός ρυθμός “ανάπτυξης” (περίπου κυκλοφορεί ετησίως)
Ελάχιστα προγράμματα αναβαθμίζονται μεταξύ των δευτερευουσών κυκλοφοριών. Μόνο η κύρια κυκλοφορία φέρνει μεγάλες αλλαγές
Παραδείγματα: openSUSE Leap, Ubuntu LTS, SUSE Linux Enterprise Server, SUSE Linux Enterprise Desktop, RHEL

Αυτή είναι η βάση για την κατανόηση των σχέσεων μεταξύ SUSE Linux Enterprise και το openSUSE. Όπως θα δούμε στην επόμενη ενότητα, τα openSUSE Tumbleweed, openSUSE Leap και SUSE Linux Enterprise συνδέονται μεταξύ τους.

Κοινή ανάπτυξη openSUSE & SLE

Ακολουθεί μια απλή εικόνα που περιγράφει τη σχέση μεταξύ του openSUSE & SLE από την ημερομηνία κυκλοφορίας του Leap 15.0 (25 Μαΐου 2018):

Το Factory Project είναι το αποθετήριο για ανάπτυξη κώδικα όπου βασίζονται όλες οι διανομές SUSE και openSUSE, ΔΕΝ είναι διανομή Linux! Είναι η άμεση πηγή για το openSUSE Tumbleweed και τελικά καταλήγει στις διανομές openSUSE Leap και SUSE Linux Enterprise. Με απλά λόγια, το Factory είναι το αποθετήριο ανάπτυξης για το openSUSE και το SUSE!

Τώρα ίσως αναρωτιέστε ποια είναι η σχέση Factory and openSUSE Tumbleweed; Είναι πολύ απλό! Το Factory λαμβάνει μια συνεχή ροή κώδικα χωρίς καμία σωστή Διασφάλιση Ποιότητας εκτός από κάποια ανασκόπηση κώδικα (κυρίως από bots), οπότε η κοινότητα του openSUSE δημιουργεί στιγμιότυπα του Factory που έχουν δοκιμαστεί με το openQA. Όταν ένα στιγμιότυπο είναι απαλαγμένο από σφάλματα, αποτελεί ενημέρωση για το openSUSE Tumbleweed, ως εκ τούτου χαρακτηρίζεται ως κυλιόμενη έκδοση.

Στη συνέχεια πιο κάτω στην εικόνα είναι η σχέση μεταξύ openSUSE Tumbleweed, openSUSE Leap και SUSE Linux Enterprise.

Με βάση το κοινό πρόγραμμα, το openSUSE Leap και το SLE έχουν ένα προβλέψιμο χρονικό πλαίσιο κυκλοφορίας: μια κυκλοφορία κάθε 12 μήνες και μια επικάλυψη υποστήριξης 6 μηνών για την προηγούμενη και τη νέα κυκλοφορία. Επομένως έρθει η στιγμή, γίνεται ένα στιγμιότυπο του openSUSE Tumbleweed και οι διανομές openSUSE Leap και SLE θα χρησιμοποιήσουν αυτό το στιγμιότυπο για να δημιουργηθούν οι επόμενες εκδόσεις των διανομών.

Με αυτήν την εικόνα, βλέπουμε ότι είναι μόνο μια ομάδα πηγών πακέτων που θα χρησιμοποιήθούν για την κατασκευή της αντίστοιχης διανομής. Αλλά προτού δούμε πως χτίζεται, σημειώστε ότι είναι μια απλοποιημένη προβολή επειδή υπάρχει πάντα εναλλαγή μεταξύ openSUSE Leap / SLE και openSUSE Tumbleweed. Δεν είναι συγχρονισμός πακέτων προς μια κατεύθυνση, επειδή κατά τη φάση ανάπτυξης των διανομών, εντοπίζονται σφάλματα και φυσικά οι διορθώσεις υποβάλλονται πίσω στο Factory, έτσι ώστε το openSUSE Tumbleweed να λαμβάνει επίσης διορθώσεις από τη διαδικασία.

Στην εταιρία SUSE, ο ανοικτός κώδικας είναι στα γονίδια των υπαλλήλων, οπότε πάντα συνεισφέρουν στο openSUSE, αλλά από το 2017, η υπεύθυνη ομάδα για την κυκλοφορία της SUSE είχε επιβάλει έναν κανόνα που ονομάζεται «Factory First Policy», ο οποίος αναγκάζει τις υποβολές κώδικα για το SLE να προωθηθούν πρώτα στο Factory πριν εισαχθούν στην διανομή SLE. Αυτή είναι η συνέχεια της αρχής «Upstream First» στο επίπεδο διανομής. Με αυτό τον τρόπο, μειώνεται η προσπάθεια συντήρησης και αξιοποιείται η κοινότητα.

Όταν γίνεται μια υποβολή κώδικα από υπάλληλο της SUSE για την ενσωμάτωση στην SLE15, ένας αυτοματοποιημένος έλεγχος θα διασφαλίσει ότι έγινε παρόμοια υποβολή στο αποθετήριο Factory. Εάν δεν έγινε, η υποβολή θα απορριφθεί αυτόματα και θα απαιτήσει από την υπεύθυνη ομάδα για την κυκλοφορία της SUSE να ρίξει μια πιο προσεκτική ματιά και να ζητήσει την υποβολή κώδικα στο αποθετήριο Factory. Με αυτήν την πολιτική «Factory First Policy», διασφαλίζεται ότι οποιαδήποτε ανάπτυξη της SLE ωθείται και στο openSUSE ακόμη και πριν γίνει δεκτή στην SLE!

Πώς «χτιζόταν» οι openSUSE & SLE μέχρι τώρα

Ας δούμε λίγο τεχνικά πώς δημιουργήθηκαν οι διανομές openSUSE & SLE μέχρι την έκδοση openSUSE Leap 15.2 και την SUSE Linux Enterprise 15 Service Pack 2.

Πώς «χτίζονται» οι openSUSE & SLE μέχρι τώρα

Η κορυφή της εικόνας αναφέρθηκε στο προηγούμενο τμήμα του άρθρου. Γίνεται χρήση της ίδιας ομάδας πηγών πακέτων για τη δημιουργία της openSUSE Leap και της SUSE Linux Enterprise Server.

Αυτό συμβαίνει επειδή το openSUSE Leap και το SLE ήθελαν

να μοιράζονται άμεσα μια βασική σειρά πακέτων (πράσινο σκούρο διαμάντι στην κορυφή)
να έχουν «επιπλέον» πακέτα (πράσινα ανοικτό σχήμα «V») που μπορούν να ενημερώνονται πιο συχνά ή να έχουν διαφορετικό επίπεδο υποστήριξης

Για την openSUSE είναι πολύ απλό, το μεγαλύτερο διαμάντι (πράσινο σκούρο + πράσινο ανοικτό) αντιπροσωπεύει ολόκληρη τη διανομή του openSUSE Leap με όλα τα επίσημα πακέτα.

Για την SUSE Linux Enterprise, οι επίσημες διανομές και πακέτα είναι μόνο το πράσινο σκούρο διαμάντι στην κορυφή! Αλλά το υπόλοιπο πράσινο ανοικτό “V” θα είναι διαθέσιμο στο Package Hub. Το Package Hub είναι το αποθετήριο κοινότητας που δημιουργήθηκε από την κοινότητά για τις SUSE Linux Enterprise Server και Desktop, αλλά φυσικά το SUSE δεν υποστηρίζει άμεσα αυτά τα πακέτα, αλλά υποστηρίζονται από την κοινότητα.

Το σημαντικό εδώ είναι ότι η openSUSE Leap 15.2 και η SLE 15 SP2 χρησιμοποιούν τις ίδιες πηγές πακέτων και μοιράζονται τις ίδιες λίστες πακέτων, αλλά δεν χρησιμοποιούν τα ίδια εκτελέσιμα (binaries) rpm!

openSUSE & SLE στο μέλλον

Μόλις είδαμε τη «περίεργη συμβίωση», αλλά πώς μπορεί να γίνει καλύτερη; Είναι εύκολη, απλοποιώντας τη μεγάλη εικόνα:

Στην προηγούμενη ενότητα (Πώς «χτιζόταν» οι openSUSE & SLE μέχρι τώρα) η διαδικασία χρησιμοποιήθηκε από τουλάχιστον τις 3 τελευταίες κυκλοφορίες, αλλά η SUSE πίστεψε ότι θα μπορούσε να κάνει περισσότερα, οπότε έκανε την πρόταση Closing the Leap Gap (Κλείσιμο του χάσματος με την Leap) στην κοιντότητα openSUSE, κατά τη φάση ανάπτυξης της SLE 15 SP2. Για να συντομεύσουμε την ιστορία, η πρόταση ήταν να συμπεριληφθούν τα προκατασκευασμένα αρχεία binaries από το SLE, εκτός από τα πηγαία binaries που ήδη παρέχονται, για να αυξηθεί η συμβατότητα. Για περισσότερες λεπτομέρειες σχετικά με όλες τις πτυχές αυτής της πρότασης, δείτε την σελίδα openSUSE FAQ.

Οι αλλαγές έγιναν επειδή για ομαλότερη μετανάστευσης μεταξύ των SLE και openSUSE Leap αλλά και για μια πιο άμεση συνεργασία με την κοινότητα openSUSE. Επομένως, η SUSE διευκολύνει την κοινότητα να συνεισφέρει απευθείας στο openSUSE και το SLE μέσω νέων αποκλειστικών καναλιών. Έτσι, η κοινότητα εξακολουθεί να είναι σε θέση να διαμορφώσει και να υποβάλει αλλαγές στην επόμενη έκδοση διανομής με αυτήν το νέο τρόπο.

Ελέγξτε τους παρακάτω συνδέσμους για περισσότερες πληροφορίες:

Ο απώτερος στόχος είναι να δημιουργηθεί ένα υγιές και αυτόνομο οικοσύστημα, σε επίπεδο διανομής να υπάρχει μια καλή ισορροπία ανάμεσα σε ένα περιβάλλον κατάλληλο για έρευνα και καινοτομία.

Όπως μπορείτε να δείτε, η σχέση μεταξύ του openSUSE και του SLE δεν είναι από μόνη της περίπλοκη, αλλά είναι αλήθεια ότι επιλέχθηκε η συμβίωση που επιτρέπει τη δημιουργία ορίων μεταξύ μιας κοινοτικής διανομής κυλιόμενης κυκλοφορίας (openSUSE Tumbleweed), μιας κοινοτικής διανομής LTS (openSUSE Leap) και μιας εταιρική διανομή (SLE). Με την πρόταση Closing the Leap Gap, αυτό που θέλει η SUSE να επιτύχει είναι να συνεχίσει να βελτιώνει την αποτελεσματικότητα της συνεισφοράς από και προς την κοινότητα και την εταιρική πλευρά.

Μοιραζόμαστε περισσότερα από τον κώδικα

Τέλος, η κοινότητα openSUSE και το SUSE μοιράζονται κάτι περισσότερο από απλώς κώδικα! Αλλά αν σταθούμε καθαρά στην ανάπτυξης λογισμικού, πρέπει να μιλήσουμε για το πώς τα openSUSE και SLE δημιουργούνται και δοκιμάζονται κατά τη φάση της συνδεδεμένης ανάπτυξής τους.

Στη συνέχεια, θα μιλήσουμε για μερικές από τις υποκείμενες διαδικασίες που συνδέουν τα πάντα μαζί, αλλά και για τα εξαιρετικά εργαλείο που χρησιμοποιούμε: Open Build Service (build) και openQA (test).

Περαιτέρω αναγνώσεις / βίντεο:

Πηγή άρθρου: https://planet.ellak.gr/ , https://eiosifidis.blogspot.com