Μέρος 2: Πώς να βελτιώσετε τους αγωγούς CI / CD σας Kubernetes με το GitLab και το Open Source

Εικόνα χαρακτηριστικού μέσω Pixabay.

Στο προηγούμενο άρθρο μου "Μέρος: 1 Πώς οι αγωγοί CI / CD με εμπορευματοκιβώτια λειτουργούν με Kubernetes και GitLab", έγραψα για τη δημοτικότητα και τη σημασία του Kubernetes το 2019. Περιέγραψα επίσης τα πλεονεκτήματα των αγωγών μεταφοράς εμπορευματοκιβωτίων με την προσφορά GitLab CI / CD και Kaniko. Σε αυτήν την ανάρτηση, θα ήθελα να παρουσιάσω περισσότερα έργα ανοικτού κώδικα και λειτουργίες GitLab που θα σας βοηθήσουν να αναπτύξετε και να εκτελέσετε την εφαρμογή σας στο cloud native.

Βελτιώστε τις εφαρμογές ανάπτυξης εφαρμογών

Τώρα ας επανέλθουμε στην ανάπτυξη εφαρμογών και σας παρουσιάσουμε στο έργο open source Kustomize. Το Kustomize, το οποίο είναι μέρος του έργου Kubernetes και χρηματοδοτείται από το sig-cli, σάς επιτρέπει να προσαρμόσετε τα αρχεία YAML χωρίς ωμά και χωρίς πρότυπα για πολλαπλούς σκοπούς, αφήνοντας το αρχικό YAML ανέπαφο και χρησιμοποιήσιμο ως έχει. Το Kustomize είναι ένα εργαλείο CLI που είναι επίσης ενσωματωμένο στο kubectl από προεπιλογή.

Για μένα, το Kustomize είναι το τέλειο εργαλείο για την ανάπτυξη εφαρμογών σε κοντέινερ σε ένα συγκρότημα Kubernetes χρησιμοποιώντας συνεχή παράδοση (CD). Μας επιτρέπει να ορίσουμε τις προσαρμογές με μια δηλωτική προσέγγιση, υποστηρίζοντας μας να αναπτύξουμε τις εφαρμογές μας σε διαφορετικά περιβάλλοντα, μη διπλασιάζοντας τον κώδικα μας. Σε αντίθεση με άλλα εργαλεία ανάπτυξης, το Kustomize έχει τα μικρότερα έξοδα και επικεντρώνεται μόνο στα χαρακτηριστικά που απαιτούνται σε έναν αυτόματο αγωγό CD.

Για να προσαρμόσουμε τα υπάρχοντα δηλωτικά YAML, πρέπει μόνο να ορίσουμε τις προσαρμογές μας σε ένα kustomization.yaml, το οποίο το Kustomize στη συνέχεια χρησιμοποιεί ως σύνολο κανόνων για την κατασκευή των ορισμών YAML αποτελεσμάτων. Επιτρέψτε μου να σας δώσω ένα παράδειγμα (μπορείτε να ανατρέξετε ολόκληρο το παράδειγμα εδώ):

apiVersion: kustomize.config.k8s.io/v1beta1 είδος: Βασικές προσαρμογές: - ../../base commonLabels: env: dev patchesStrategicMerge: - replica.yaml - env.yaml namePrefix: dev-

Αυτό το kustomization.yaml, για παράδειγμα, χρησιμοποιείται για την ανάπτυξη μιας εφαρμογής σε περιβάλλον ανάπτυξης. Επομένως, προσαρμόζει το υπάρχον δηλωτικό μας YAML (συνδέεται μέσω της παραμέτρου βάσεων) και προσθέτει μερικές συγκεκριμένες διαμορφώσεις:

  • προσθέτει μια ετικέτα env = dev σε όλους τους πόρους.
  • επιδιορθώνει το υπάρχον δηλωτικό YAML με βάση τα καθορισμένα αρχεία. σε αυτό το παράδειγμα, ενημερώνει τον αριθμό ρεπλίκα και προσθέτει συγκεκριμένες μεταβλητές περιβάλλοντος κοντέινερ.
  • προσθέτει το όνομα Prefix dev- σε όλους τους πόρους.

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

Ας δούμε πώς μπορούμε να ενσωματώσουμε το Kustomize σε αγωγό μεταφοράς εμπορευματοκιβωτίων (μπορείτε να ανατρέξετε ολόκληρο το παράδειγμα εδώ):

Επεξεργασία μεταβλητών: εμφάνιση μεταβλητών: εμφάνιση μεταβλητών: IMAGE: "registry.gitlab.com/nmeisenzahl/dockerfiles/kubectl:latest" ENV: "dev" app-deploy: στάδιο: ανάπτυξη ετικετών: - kubernetes image: name: $ IMAGE entrypoint: ] script: - kubectl ισχύσει -k ανάπτυξη / επικάλυψη / $ ENV μόνο: - master

Για άλλη μια φορά, έχουμε ορισμό αγωγού μόνο με μία δουλειά. Το τμήμα δέσμης ενεργειών θα εκτελεστεί σε ένα δοχείο που παρέχει kubectl με βάση το Alpine. Η εργασία εκτελεί το CLI kubectl με την παράμετρο εφαρμογής. -k λέει στο kubectl να χρησιμοποιήσει την προσθήκη Kustomize. Και οι δύο παράμετροι ακολουθούνται από τη διαδρομή στην οποία βρίσκονται τα αρχεία ανάπτυξης. Σε αυτό το παράδειγμα, χρησιμοποιούμε μια μεταβλητή αγωγού για να καθορίσουμε τις προσαρμογές που θέλουμε να αναπτύξουμε.

Ασφαλίστε την εφαρμογή σας

Τώρα μπορούμε να κατασκευάσουμε και να αναπτύξουμε την εφαρμογή μας χρησιμοποιώντας αγωγούς μεταφοράς εμπορευματοκιβωτίων. Τώρα δείχνουμε πώς μπορούμε να εξασφαλίσουμε το φορτίο εργασίας των εφαρμογών που εκτελείται στο σύμπλεγμα Kubernetes μας.

Όταν ενσωματώνουμε το υπάρχον σύμπλεγμα Kubernetes με ένα έργο ή μια ομάδα GitLab, μπορούμε να επιλέξουμε την εγκατάσταση ενός ελεγκτή Ingress. Ο έτοιμος ελεγκτής Ingress ονομάζεται GitLab Web Application Firewall. Το GitLab WAF σας παρέχει παρακολούθηση ασφαλείας σε πραγματικό χρόνο βασισμένη σε ένα Nginx Proxy με ενεργοποιημένη την ModSecurity μονάδα. Το βασικό σύνολο κανόνων βασικού κανόνα OWASP προσαρμόζεται με βάση τις βέλτιστες πρακτικές του GitLab και έχει διαμορφωθεί σε λειτουργία μόνο ανίχνευσης. Φυσικά, είναι δυνατή η ενεργοποίηση περαιτέρω ρυθμίσεων ασφαλείας, αν χρειαστεί. Το Τείχος προστασίας εφαρμογών Web σας βοηθάει να ανιχνεύετε και να αποτρέπετε τη δημιουργία σεναρίων μεταξύ ιστοτόπων καθώς και επιθέσεις ένεσης SQL.

Όπως αναφέρθηκε παραπάνω, το GitLab WAF είναι ρυθμισμένο να εντοπίζει μόνο από προεπιλογή. Το Τείχος προστασίας εφαρμογών Web καταγράφει όλα τα θέματα που σχετίζονται με την ασφάλεια σε ένα αρχείο καταγραφής ελέγχου (/var/log/modsec/audit.log) στο pod kontroller του Ingress, το οποίο μπορεί να προωθηθεί σε οποιαδήποτε διαχείριση αρχείου για περαιτέρω ανάλυση ή ενέργεια. Παράδειγμα εξόδου ενός ζητήματος ασφαλείας:

Γιατί πρέπει να φροντίζετε μόνο για την επιχειρηματική σας λογική

Στο τελευταίο μέρος αυτής της θέσης, καλύπτω το serverless, μια άλλη προσέγγιση που έχει προσελκύσει πολλή ενέργεια κατά το παρελθόν έτος. Ένας τρόπος για να περιγράψετε τον serverless είναι ότι σημαίνει ότι σταματάτε να νοιάζεστε για τους διακομιστές και την υποδομή σας και απλά εστιάζετε στην επιχειρησιακή λογική σας ή στο ζήτημα που θέλετε να λύσετε. Με το GitLab Serverless μπορείτε να κάνετε ακριβώς αυτό. Το GitLab Serverless είναι γεμάτο με τα Knative, Kaniko και Istio, τα οποία είναι όλα τα έργα ανοιχτού κώδικα που χτίστηκαν πάνω από τα Kubernetes και τα οποία αφηρημένα μακριά τις περίπλοκες λεπτομέρειες που επιτρέπουν στους προγραμματιστές να επικεντρωθούν σε αυτό που έχει σημασία.

Το GitLab Serverless δημιουργεί αυτόματα μια εικόνα κοντέινερ χωρίς να μας παρέχει ένα αρχείο Dockerfile, το μετατρέπει σε Kubernetes και το κλιμακώνει αυτόματα με βάση τις ανάγκες των χρηστών. Αυτό γίνεται με τρόπο παρόμοιο με τη λειτουργία ως υπηρεσία (FaaS), η οποία μας επιτρέπει επίσης να περιορίσουμε την εφαρμογή μας στο μηδέν για να εξοικονομήσουμε πόρους και χρήματα με βάση τις ανάγκες.

Μόλις διαμορφώσουμε το GitLab Serverless στο σύμπλεγμα Kubernetes, θα πρέπει να το ρυθμίσουμε μόνο με δύο αρχεία στο έργο μας: Ένας ορισμός GitLab CI, καθώς και serverless.yaml που περιγράφει τη λειτουργία σας ή ένα Dockerfile που περιγράφει την εφαρμογή σας σε κοντέινερ. Στο παρακάτω παράδειγμα αναπτύσσουμε μια λειτουργία με βάση το NodeJS (μπορείτε να ανατρέξετε ολόκληρο το παράδειγμα εδώ).

Το .gitlab-ci.yml που ορίζει τον αγωγό για την κατασκευή και την ανάπτυξη της λειτουργίας μας:

περιλαμβάνουν: πρότυπο: Serverless.gitlab-ci.yml λειτουργίες: build: επεκτείνει: .serverless: build: λειτουργίες περιβάλλοντος: λειτουργίες παραγωγής: αναπτύξει: επεκτείνει: .serverless: αναπτύξει: λειτουργίες περιβάλλον: παραγωγή

Ένα serverless.yaml που περιγράφει τις λειτουργίες και τον απαιτούμενο χρόνο εκτέλεσης:

υπηρεσία: παροχέας λειτουργιών: όνομα: λειτουργίες triggermesh: echo-js: χειριστής: echo-js πηγή: ./echo-js runtime: gitlab / runtimes / nodejs

Το GitLab Serverless θα μας παρέχει επίσης λεπτομερείς μετρήσεις για την κλιμάκωση της λειτουργίας σας:

Όλα τα παραδείγματα και τα αποσπάσματα κώδικα είναι διαθέσιμα εδώ. Το προηγούμενο άρθρο μου "Πώς οι περιέκτες CI / CD λειτουργούν με Kubernetes και GitLab" περιγράφουν πώς να δημιουργήσετε αγωγούς μεταφοράς εμπορευματοκιβωτίων με GitLab CI / CD και Kaniko. Μπορείτε επίσης να δείτε μια ζωντανή ηχογράφηση της ομιλίας μου στο GitLab Commit 2020 στο Σαν Φρανσίσκο για αγωγούς μεταφοράς εμπορευματοκιβωτίων, Kubernetes και open source γενικά:

Ευτυχισμένη ανάπτυξη!

Αυτό το άρθρο δημοσιεύτηκε για πρώτη φορά στο The New Stack.