Γειά σου! Πολλά δροσερά εργαλεία αυτοματισμού έχουν κυκλοφορήσει πρόσφατα τόσο για τη δημιουργία εικόνων Docker όσο και για την ανάπτυξη στο Kubernetes. Από αυτή την άποψη, αποφάσισα να παίξω με το Gitlab, πώς να μελετήσω τις δυνατότητές του και, φυσικά, να δημιουργήσω έναν αγωγό.

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

Προσπάθησα να δημιουργήσω μια παρόμοια διαδικασία από την αρχή, αλλά εξ ολοκλήρου βασισμένη στο Gitlab CI και σε δωρεάν εργαλεία που χρησιμοποιούσα για την ανάπτυξη εφαρμογών στο Kubernetes. Σήμερα θα σας πω επιτέλους περισσότερα για αυτούς.

Το άρθρο θα καλύπτει εργαλεία όπως:
Hugo, qbec, kaniko, git-κρύπτη и GitLab CI με τη δημιουργία δυναμικών περιβαλλόντων.

Περιεχόμενο

1. Γνωριμία με τον Hugo
2. Προετοιμασία του αρχείου Docker
3. Γνωριμία με το kaniko
4. Εισαγωγή στο qbec
5. Δοκιμάζοντας το Gitlab-runner με τον Kubernetes-executor
6. Αναπτύξτε χάρτες Helm με qbec
7. Εισαγωγή στο git-crypt
8. Δημιουργήστε μια εικόνα εργαλειοθήκης
9. Η πρώτη μας διοχέτευση και συναρμολόγηση εικόνων ανά ετικέτες
10. Ανάπτυξη αυτοματισμού
11. Τεχνουργήματα και συναρμολόγηση όταν πιέζετε για να κυριαρχήσετε
12. Δυναμικά περιβάλλοντα
13. Έλεγχος εφαρμογών

1. Γνωριμία με τον Hugo

Ως παράδειγμα του έργου μας, θα προσπαθήσουμε να δημιουργήσουμε έναν ιστότοπο δημοσίευσης τεκμηρίωσης που βασίζεται στο Hugo. Το Hugo είναι μια δημιουργία στατικού περιεχομένου.

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

Δηλαδή, στην έξοδο θα λάβετε μια δομή καταλόγου και ένα σύνολο δημιουργημένων αρχείων html που μπορείτε απλά να ανεβάσετε σε οποιοδήποτε φτηνό hosting και να αποκτήσετε έναν ιστότοπο που λειτουργεί.

Μπορείτε να εγκαταστήσετε το Hugo τοπικά και να το δοκιμάσετε:

Εκκίνηση του νέου ιστότοπου:

hugo new site docs.example.org

Και ταυτόχρονα το αποθετήριο git:

cd docs.example.org
git init

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

Ως θέμα θα χρησιμοποιήσουμε Μάθετε, το οποίο, κατά τη γνώμη μου, είναι το καταλληλότερο για έναν ιστότοπο με τεκμηρίωση.

Θα ήθελα να δώσω ιδιαίτερη προσοχή στο γεγονός ότι δεν χρειάζεται να αποθηκεύσουμε τα αρχεία θεμάτων στο αποθετήριο του έργου μας, αντίθετα μπορούμε απλά να το συνδέσουμε χρησιμοποιώντας υπομονάδα git:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

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

Ας διορθώσουμε τη διαμόρφωση config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

Ήδη σε αυτό το στάδιο, μπορείτε να εκτελέσετε:

hugo server

Και στη διεύθυνση http://localhost:1313/ ελέγξτε τον πρόσφατα δημιουργημένο ιστότοπό μας, όλες οι αλλαγές που έγιναν στον κατάλογο ενημερώνουν αυτόματα την ανοιχτή σελίδα στο πρόγραμμα περιήγησης, πολύ βολικό!

Ας προσπαθήσουμε να δημιουργήσουμε μια σελίδα τίτλου στο περιεχόμενο/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Στιγμιότυπο οθόνης της σελίδας που δημιουργήθηκε πρόσφατα

Για να δημιουργήσετε έναν ιστότοπο, απλώς εκτελέστε:

hugo

Περιεχόμενο καταλόγου δημόσιο/ και θα είναι ο ιστότοπός σας.
Ναι, παρεμπιπτόντως, ας το βάλουμε αμέσως .gitignore:

echo /public > .gitignore

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .
git commit -m "New site created"

2. Προετοιμασία του αρχείου Docker

Ήρθε η ώρα να ορίσουμε τη δομή του αποθετηρίου μας. Συνήθως χρησιμοποιώ κάτι σαν:

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

• dockerfiles/ - περιέχει καταλόγους με Dockerfiles και όλα όσα χρειάζονται για τη δημιουργία των εικόνων docker μας.
• αναπτύσσω/ - περιέχει καταλόγους για την ανάπτυξη των εφαρμογών μας στο Kubernetes

Έτσι, θα δημιουργήσουμε το πρώτο μας Dockerfile στην πορεία dockerfiles/ιστοσελίδα/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

Όπως μπορείτε να δείτε, το Dockerfile περιέχει δύο ΑΠΟ, αυτή η δυνατότητα ονομάζεται πολυβάθμια κατασκευή και σας επιτρέπει να εξαιρέσετε οτιδήποτε περιττό από την τελική εικόνα του docker.
Έτσι, η τελική εικόνα θα περιέχει μόνο σκοτεινόhttpd (ελαφρύς διακομιστής HTTP) και δημόσιο/ - το περιεχόμενο του ιστοτόπου μας που δημιουργείται στατικά.

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. Γνωριμία με το kaniko

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

Για να δημιουργήσετε την εικόνα, απλώς εκτελέστε το κοντέινερ με kaniko εκτελεστής και περάστε το τρέχον περιβάλλον κατασκευής σε αυτό, μπορείτε να το κάνετε τοπικά, μέσω docker:

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

Πού registry.gitlab.com/kvaps/docs.example.org/website - το όνομα της εικόνας του docker σας, μετά τη δημιουργία θα εκκινηθεί αυτόματα στο μητρώο του docker.

Παράμετρος --κρύπτη σας επιτρέπει να αποθηκεύετε επίπεδα κρυφής μνήμης στο μητρώο του docker, για το συγκεκριμένο παράδειγμα που θα αποθηκευτούν registry.gitlab.com/kvaps/docs.example.org/website/cache, αλλά μπορείτε να καθορίσετε μια άλλη διαδρομή με την παράμετρο --cache-repo.

Στιγμιότυπο οθόνης docker-registry

4. Εισαγωγή στο qbec

Qbec είναι ένα εργαλείο ανάπτυξης που σας επιτρέπει να περιγράφετε δηλωτικά τις δηλώσεις της εφαρμογής σας και να τις αναπτύσσετε στο Kubernetes. Η χρήση του Jsonnet ως κύριας σύνταξης καθιστά πολύ εύκολη την περιγραφή των διαφορών για πολλά περιβάλλοντα και επίσης εξαλείφει σχεδόν πλήρως την επανάληψη κώδικα.

Αυτό μπορεί να ισχύει ιδιαίτερα σε περιπτώσεις όπου χρειάζεται να αναπτύξετε μια εφαρμογή σε πολλά συμπλέγματα με διαφορετικές παραμέτρους και θέλετε να τα περιγράψετε με δηλωτικό τρόπο στο Git.

Το Qbec σάς επιτρέπει επίσης να αποδίδετε χάρτες Helm περνώντας τους τις απαραίτητες παραμέτρους και στη συνέχεια να τις χρησιμοποιείτε με τον ίδιο τρόπο όπως τα κανονικά μανιφέστα, συμπεριλαμβανομένης της δυνατότητας εφαρμογής διαφόρων μεταλλάξεων σε αυτά, και αυτό, με τη σειρά του, εξαλείφει την ανάγκη χρήσης του ChartMuseum. Δηλαδή, μπορείτε να αποθηκεύσετε και να αποδώσετε γραφήματα απευθείας από το git, όπου ανήκουν.

Όπως είπα προηγουμένως, θα αποθηκεύσουμε όλες τις αναπτύξεις στον κατάλογο αναπτύσσω/:

mkdir deploy
cd deploy

Ας αρχικοποιήσουμε την πρώτη μας εφαρμογή:

qbec init website
cd website

Τώρα η δομή της εφαρμογής μας μοιάζει με αυτό:

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

κοιτάξτε το αρχείο qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

Εδώ μας ενδιαφέρει πρωτίστως spec.περιβάλλοντα, η qbec έχει ήδη δημιουργήσει το προεπιλεγμένο περιβάλλον για εμάς και πήρε τη διεύθυνση του διακομιστή και τον χώρο ονομάτων από το τρέχον kubeconfig.
Τώρα κατά την ανάπτυξη σε αθέτηση περιβάλλον, το qbec θα αναπτύσσεται πάντα μόνο στο καθορισμένο σύμπλεγμα Kubernetes και στον καθορισμένο χώρο ονομάτων, δηλαδή δεν χρειάζεται πλέον να κάνετε εναλλαγή μεταξύ περιβάλλοντος και χώρων ονομάτων για να το αναπτύξετε.
Εάν είναι απαραίτητο, μπορείτε πάντα να ενημερώσετε τις ρυθμίσεις σε αυτό το αρχείο.

Όλα τα περιβάλλοντά σας περιγράφονται στο qbec.yaml, και στο αρχείο params.libsonnet, που λέει πού πρέπει να πάρετε τις παραμέτρους για αυτές.

Στη συνέχεια βλέπουμε δύο καταλόγους:

• συστατικά/ - όλες οι δηλώσεις για την εφαρμογή μας θα αποθηκευτούν εδώ, μπορούν να περιγραφούν τόσο σε jsonnet όσο και σε κανονικά αρχεία yaml
• περιβάλλοντα/ - εδώ θα περιγράψουμε όλες τις μεταβλητές (παραμέτρους) για τα περιβάλλοντά μας.

Από προεπιλογή έχουμε δύο αρχεία:

• περιβάλλοντα/base.libsonnet - θα περιέχει κοινές παραμέτρους για όλα τα περιβάλλοντα
• περιβάλλοντα/default.libsonnet - περιέχει παραμέτρους που επαναπροσδιορίζονται για το περιβάλλον αθέτηση

ας ανοίξουμε περιβάλλοντα/base.libsonnet και προσθέστε παραμέτρους για το πρώτο μας στοιχείο εκεί:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

Ας δημιουργήσουμε επίσης το πρώτο μας στοιχείο components/website.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Σε αυτό το αρχείο, περιγράψαμε τρεις οντότητες Kubernetes ταυτόχρονα, αυτές είναι: Ανάπτυξη, Υπηρεσία и Είσοδος. Εάν είναι επιθυμητό, ​​θα μπορούσαμε να τα μετακινήσουμε σε διαφορετικά εξαρτήματα, αλλά σε αυτό το στάδιο, ένα είναι αρκετό για εμάς.

σύνταξη jsonnet πολύ παρόμοιο με το κανονικό json, κατ 'αρχήν, το κανονικό json είναι ήδη ένα έγκυρο jsonnet, επομένως στην αρχή μπορεί να είναι πιο εύκολο για εσάς να χρησιμοποιήσετε διαδικτυακές υπηρεσίες όπως yaml2json για να μετατρέψετε το συνηθισμένο σας yaml σε json ή εάν τα στοιχεία σας δεν περιέχουν μεταβλητές, τότε μπορούν να περιγραφούν με τη μορφή κανονικού yaml.

Όταν εργάζεστε με jsonnet Σας συμβουλεύω ανεπιφύλακτα να εγκαταστήσετε ένα πρόσθετο για τον επεξεργαστή σας

Για παράδειγμα, υπάρχει ένα πρόσθετο για το vim vim-jsonnet, το οποίο ενεργοποιεί την επισήμανση σύνταξης και εκτελείται αυτόματα jsonnet fmt σε κάθε αποθήκευση (απαιτείται η εγκατάσταση του jsonnet).

Όλα είναι έτοιμα, τώρα μπορούμε να ξεκινήσουμε την ανάπτυξη:

Για να δούμε τι έχουμε, ας τρέξουμε:

qbec show default

Στην έξοδο, θα δείτε τα αποδοθέντα μανιφέστα yaml που θα εφαρμοστούν στο προεπιλεγμένο σύμπλεγμα.

Τέλεια, εφαρμόστε τώρα:

qbec apply default

Στην έξοδο θα βλέπετε πάντα τι θα γίνει στο σύμπλεγμα σας, το qbec θα σας ζητήσει να αποδεχτείτε τις αλλαγές πληκτρολογώντας y μπορείτε να επιβεβαιώσετε τις προθέσεις σας.

Ολοκληρώθηκε τώρα η εφαρμογή μας έχει αναπτυχθεί!

Εάν γίνουν αλλαγές, μπορείτε πάντα να εκτελέσετε:

qbec diff default

για να δείτε πώς αυτές οι αλλαγές θα επηρεάσουν την τρέχουσα ανάπτυξη

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. Δοκιμάστε το Gitlab-runner με το Kubernetes-executor

Μέχρι πρόσφατα χρησιμοποιούσα μόνο τακτικά gitlab-runner σε προπαρασκευασμένο μηχάνημα (κοντέινερ LXC) με εκτελεστή κελύφους ή docker. Αρχικά, είχαμε ορισμένους από αυτούς τους δρομείς παγκοσμίως στο gitlab μας. Έφτιαξαν εικόνες docker για όλα τα έργα.

Αλλά όπως έδειξε η πρακτική, αυτή η επιλογή δεν είναι η πιο ιδανική, τόσο από άποψη πρακτικότητας όσο και από άποψη ασφάλειας. Είναι πολύ καλύτερο και ιδεολογικά σωστό να υπάρχουν ξεχωριστοί δρομείς για κάθε έργο, ακόμη και για κάθε περιβάλλον.

Ευτυχώς, αυτό δεν είναι καθόλου πρόβλημα, αφού τώρα θα αναπτύξουμε gitlab-runner απευθείας ως μέρος του έργου μας στο Kubernetes.

Το Gitlab παρέχει ένα έτοιμο διάγραμμα τιμονιού για την ανάπτυξη του gitlab-runner στο Kubernetes. Το μόνο που χρειάζεται να ξέρετε λοιπόν είναι διακριτικό εγγραφής για το έργο μας σε Ρυθμίσεις -> CI / CD -> Runners και περάστε το στο τιμόνι:

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

Πού:

• https://gitlab.com είναι η διεύθυνση του διακομιστή σας Gitlab.
• yga8y-jdCusVDn_t4Wxc - διακριτικό εγγραφής για το έργο σας.
• rbac.δημιουργώ=αλήθεια - δίνει στον δρομέα τον απαραίτητο αριθμό προνομίων για να μπορεί να δημιουργήσει pods για να εκτελέσει τις εργασίες μας χρησιμοποιώντας το kubernetes-executor.

Εάν όλα γίνονται σωστά, θα πρέπει να δείτε τον εγγεγραμμένο δρομέα στην ενότητα Δρομείς, στις ρυθμίσεις του έργου σας.

Στιγμιότυπο οθόνης του προστιθέμενου δρομέα

Είναι τόσο απλό; - Ναι, είναι τόσο απλό! Δεν υπάρχει άλλη ταλαιπωρία με τη μη αυτόματη εγγραφή δρομέων, στο εξής οι δρομείς θα δημιουργούνται και θα καταστρέφονται αυτόματα.

6. Αναπτύξτε χάρτες Helm με QBEC

Αφού αποφασίσαμε να εξετάσουμε gitlab-runner μέρος του έργου μας, ήρθε η ώρα να το περιγράψουμε στο αποθετήριο του Git.

Θα μπορούσαμε να το περιγράψουμε ως ξεχωριστό στοιχείο , αλλά στο μέλλον σκοπεύουμε να αναπτύξουμε διαφορετικά αντίγραφα πολύ συχνά, σε αντίθεση gitlab-runner, το οποίο θα αναπτυχθεί μόνο μία φορά ανά σύμπλεγμα Kubernetes. Ας αρχικοποιήσουμε λοιπόν μια ξεχωριστή εφαρμογή για αυτό:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Αυτή τη φορά δεν θα περιγράψουμε χειροκίνητα τις οντότητες του Kubernetes, αλλά θα πάρουμε ένα έτοιμο διάγραμμα Helm. Ένα από τα πλεονεκτήματα του qbec είναι η δυνατότητα απόδοσης γραφημάτων Helm απευθείας από ένα αποθετήριο Git.

Ας το ενεργοποιήσουμε χρησιμοποιώντας την υπομονάδα git:

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

Τώρα ο κατάλογος πωλητής/gitlab-runner περιέχει το αποθετήριο μας με ένα γράφημα για το gitlab-runner.

Άλλα αποθετήρια μπορούν να συνδεθούν με παρόμοιο τρόπο, για παράδειγμα, ολόκληρο το αποθετήριο με επίσημα γραφήματα https://github.com/helm/charts

Ας περιγράψουμε το συστατικό components/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

Το πρώτο επιχείρημα για expandHelmTemplate περνάμε το μονοπάτι προς το γράφημα, λοιπόν παραμ.αξίες, το οποίο παίρνουμε από τις παραμέτρους περιβάλλοντος, μετά έρχεται το αντικείμενο με

• nameTemplate - όνομα έκδοσης
• χώρο ονομάτων - Ο χώρος ονομάτων πέρασε στο τιμόνι
• αυτό το αρχείο - μια απαιτούμενη παράμετρος που περνά τη διαδρομή προς το τρέχον αρχείο
• πολύλογος - δείχνει εντολή πρότυπο πηδαλίου με όλα τα ορίσματα κατά την απόδοση ενός γραφήματος

Τώρα ας περιγράψουμε τις παραμέτρους για το στοιχείο μας περιβάλλοντα/base.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

Обратите внимание runnerRegistrationToken λαμβάνουμε από εξωτερικό αρχείο μυστικά/βάση.libsonnet, ας το δημιουργήσουμε:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Ας ελέγξουμε αν όλα λειτουργούν:

qbec show default

εάν όλα είναι εντάξει, τότε μπορούμε να αφαιρέσουμε την προηγούμενη εφαρμογή μας μέσω της απελευθέρωσης Helm:

helm uninstall gitlab-runner

και αναπτύξτε το, αλλά μέσω του qbec:

qbec apply default

7. Εισαγωγή στο git-crypt

git-crypt είναι ένα εργαλείο που σας επιτρέπει να ρυθμίσετε διαφανή κρυπτογράφηση για το αποθετήριο σας.

Προς το παρόν, η δομή του καταλόγου μας για το gitlab-runner μοιάζει με αυτό:

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

Αλλά η αποθήκευση μυστικών στο Git δεν είναι ασφαλής, έτσι δεν είναι; Πρέπει λοιπόν να τα κρυπτογραφήσουμε σωστά.

Συνήθως για χάρη μιας μεταβλητής δεν έχει πάντα νόημα. Μπορείτε να μεταφέρετε μυστικά σε qbec και μέσω των μεταβλητών περιβάλλοντος του συστήματος CI σας.
Αξίζει όμως να σημειωθεί ότι υπάρχουν και πιο σύνθετα έργα που μπορεί να περιέχουν πολύ περισσότερα μυστικά, θα είναι εξαιρετικά δύσκολο να τα περάσεις όλα μέσα από μεταβλητές περιβάλλοντος.

Επιπλέον, σε αυτή την περίπτωση, δεν θα μπορούσα να σας πω για ένα τόσο υπέροχο εργαλείο όπως git-κρύπτη.

git-κρύπτη Είναι επίσης βολικό καθώς σας επιτρέπει να αποθηκεύετε ολόκληρο το ιστορικό των μυστικών, καθώς και να συγκρίνετε, να συγχωνεύετε και να επιλύετε διενέξεις με τον ίδιο τρόπο που το κάναμε στην περίπτωση του Git.

Το πρώτο πράγμα μετά την εγκατάσταση git-κρύπτη πρέπει να δημιουργήσουμε κλειδιά για το αποθετήριο μας:

git crypt init

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

git-crypt add-gpg-user [email protected]

Με αυτόν τον τρόπο μπορείτε πάντα να αποκρυπτογραφήσετε αυτό το αποθετήριο χρησιμοποιώντας το ιδιωτικό σας κλειδί.

Εάν δεν διαθέτετε κλειδί PGP και δεν αναμένεται να το έχετε, τότε μπορείτε να πάτε από την άλλη πλευρά και να εξαγάγετε το κλειδί έργου:

git crypt export-key /path/to/keyfile

Έτσι, όποιος κατέχει εξάγει αρχείο κλειδιού θα είναι σε θέση να αποκρυπτογραφήσει το αποθετήριο σας.

Ήρθε η ώρα να στήσουμε το πρώτο μας μυστικό.
Να σας υπενθυμίσω ότι είμαστε ακόμα στον κατάλογο deploy/gitlab-runner/όπου έχουμε έναν κατάλογο μυστικά/, ας κρυπτογραφήσουμε όλα τα αρχεία σε αυτό, για αυτό θα δημιουργήσουμε ένα αρχείο μυστικά/.gitattributes με περιεχόμενο σαν αυτό:

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

Όπως φαίνεται από το περιεχόμενο, όλα τα αρχεία με μάσκα * θα τρέξει git-κρύπτη, με εξαίρεση το .gitattributes

Μπορούμε να το ελέγξουμε εκτελώντας:

git crypt status -e

Στην έξοδο, λαμβάνουμε μια λίστα με όλα τα αρχεία στο αποθετήριο για τα οποία είναι ενεργοποιημένη η κρυπτογράφηση

Αυτό είναι όλο, τώρα μπορούμε με ασφάλεια να πραγματοποιήσουμε τις αλλαγές μας:

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

Για να αποκλείσετε το αποθετήριο, αρκεί να εκτελέσετε:

git crypt lock

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

git crypt unlock

8. Δημιουργήστε μια εικόνα εργαλειοθήκης

Μια εικόνα εργαλειοθήκης είναι μια εικόνα με όλα τα εργαλεία που θα χρησιμοποιήσουμε για να αναπτύξουμε το έργο μας. Θα χρησιμοποιηθεί από τον δρομέα gitlab για την εκτέλεση τυπικών εργασιών ανάπτυξης.

Όλα είναι απλά εδώ, δημιουργούμε ένα νέο dockerfiles/εργαλειοθήκη/Dockerfile με περιεχόμενο σαν αυτό:

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

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

Επίσης, για να μπορέσουμε να επικοινωνήσουμε με το Kubernetes και να αναπτύξουμε σε αυτό, πρέπει να ρυθμίσουμε έναν ρόλο για τα pods που δημιουργούνται από το gitlab-runner.

Για να το κάνετε αυτό, μεταβείτε στον κατάλογο με το gitlab-runner'om:

cd deploy/gitlab-runner

και προσθέστε ένα νέο στοιχείο components/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

Περιγράφουμε επίσης τις νέες παραμέτρους στο περιβάλλοντα/base.libsonnet, που τώρα μοιάζει με αυτό:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

Обратите внимание $.components.rbac.name αναφέρεται σε όνομα για συστατικό rbac

Ας δούμε τι έχει αλλάξει:

qbec diff default

και εφαρμόστε τις αλλαγές μας στο Kubernetes:

qbec apply default

Επίσης, μην ξεχάσετε να δεσμεύσετε τις αλλαγές μας στο git:

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. Η πρώτη μας διοχέτευση και συναρμολόγηση εικόνων ανά ετικέτες

Στη ρίζα του έργου θα δημιουργήσουμε .gitlab-ci.yml με περιεχόμενο σαν αυτό:

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

Σημειώστε ότι χρησιμοποιούμε GIT_SUBMODULE_STRATEGY: κανονικό για εκείνες τις εργασίες όπου πρέπει να αρχικοποιήσετε ρητά υπομονάδες πριν από την εκτέλεση.

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .gitlab-ci.yml
git commit -m "Automate docker build"

Νομίζω ότι μπορείτε να το ονομάσετε με ασφάλεια έκδοση v0.0.1 και προσθέστε μια ετικέτα:

git tag v0.0.1

Θα κολλάμε ετικέτες όποτε χρειαστεί να κυκλοφορήσουμε μια νέα έκδοση. Οι ετικέτες στις εικόνες του Docker θα αντιστοιχιστούν σε ετικέτες Git. Κάθε πάτημα με μια νέα ετικέτα θα αρχικοποιεί μια δημιουργία εικόνας με αυτήν την ετικέτα.

Ας το κάνουμε git push -- ετικέτεςκαι δείτε τον πρώτο μας αγωγό:

Στιγμιότυπο οθόνης του πρώτου αγωγού

Αξίζει να σημειωθεί ότι οι εκδόσεις που βασίζονται σε ετικέτες είναι καλές για τη δημιουργία εικόνων docker, αλλά όχι για την ανάπτυξη μιας εφαρμογής στο Kubernetes. Δεδομένου ότι νέες ετικέτες μπορούν επίσης να αντιστοιχιστούν σε παλιές δεσμεύσεις, σε αυτήν την περίπτωση, η προετοιμασία της διοχέτευσης για αυτές θα οδηγήσει στην ανάπτυξη της παλιάς έκδοσης.

Για να λυθεί αυτό το πρόβλημα, η δημιουργία εικόνων docker συνήθως συνδέεται με ετικέτες και η ανάπτυξη της εφαρμογής στον κλάδο κύριος, στο οποίο οι εκδόσεις των συλλεγόμενων εικόνων είναι κωδικοποιημένες. Σε αυτή την περίπτωση μπορείτε να αρχικοποιήσετε την επαναφορά με μια απλή επαναφορά κύριος-κλαδια δεντρου.

10. Ανάπτυξη αυτοματισμού

Προκειμένου το Gitlab-runner να αποκρυπτογραφήσει τα μυστικά μας, πρέπει να εξάγουμε το κλειδί αποθήκης και να το προσθέσουμε στις μεταβλητές περιβάλλοντος CI:

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

θα αποθηκεύσουμε τη συμβολοσειρά που προκύπτει στο Gitlab, για αυτό θα πάμε στις ρυθμίσεις του έργου μας:
Ρυθμίσεις —> CI / CD —> Μεταβλητές

Και δημιουργήστε μια νέα μεταβλητή:

Χαρακτηριστικά
Κλειδί
αξία
Προστατευόμενη
Μεταμφιεσμένος
Έκταση

File
GITCRYPT_KEY
<your string>
true (την ώρα της προπόνησης, μπορείτε false)
true
All environments

Στιγμιότυπο οθόνης της μεταβλητής που προστέθηκε

Τώρα ας ενημερώσουμε το δικό μας .gitlab-ci.yml προσθέτοντας σε αυτό:

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

Εδώ έχουμε ενεργοποιήσει μερικές νέες επιλογές για το qbec:

• --root some/app - σας επιτρέπει να ορίσετε τον κατάλογο μιας συγκεκριμένης εφαρμογής
• --force:k8s-context __incluster__ - αυτή είναι μια μαγική μεταβλητή που λέει ότι η ανάπτυξη θα γίνει στο ίδιο σύμπλεγμα στο οποίο εκτελείται το gtilab-runner. Αυτό είναι απαραίτητο, διαφορετικά η qbec θα προσπαθήσει να βρει έναν κατάλληλο διακομιστή Kubernetes στο kubeconfig σας
• -Περίμενε - αναγκάζει την qbec να περιμένει έως ότου οι πόροι που δημιουργεί μεταβούν σε κατάσταση ετοιμότητας και μόνο τότε να ολοκληρώσει με έναν επιτυχημένο κωδικό εξόδου.
• -Ναί - απλώς απενεργοποιεί το διαδραστικό κέλυφος Είσαι σίγουρος? κατά την ανάπτυξη.

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .gitlab-ci.yml
git commit -m "Automate deploy"

Και μετά git push θα δούμε πώς αναπτύχθηκαν οι εφαρμογές μας:

Στιγμιότυπο οθόνης του δεύτερου αγωγού

11. Τεχνουργήματα και συναρμολόγηση κατά την ώθηση για master

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

Η ιδέα είναι απλή: τώρα η εικόνα μας θα ξαναχτίζεται κάθε φορά που πιέζετε να κύριος, και στη συνέχεια να αναπτυχθεί αυτόματα στο Kubernetes.

Ας ενημερώσουμε αυτές τις δύο θέσεις εργασίας στο δικό μας .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

Λάβετε υπόψη ότι έχουμε προσθέσει ένα υποκατάστημα κύριος к refs για δουλειά build_website και χρησιμοποιούμε τώρα $CI_COMMIT_REF_NAME αντί για $CI_COMMIT_TAG, δηλαδή, απαλλαγούμε από τις ετικέτες στο Git και τώρα θα σπρώξουμε την εικόνα με το όνομα του κλάδου commit που αρχικοποίησε τη διοχέτευση σας. Αξίζει να σημειωθεί ότι αυτό θα λειτουργήσει και με ετικέτες, που θα μας επιτρέψουν να αποθηκεύσουμε στιγμιότυπα του ιστότοπου με μια συγκεκριμένη έκδοση στο docker-registry.

Όταν το όνομα της ετικέτας docker για τη νέα έκδοση του ιστότοπου μπορεί να παραμείνει αμετάβλητο, πρέπει ακόμα να περιγράψουμε τις αλλαγές για το Kubernetes, διαφορετικά απλά δεν θα ανανεώσει την εφαρμογή από τη νέα εικόνα, καθώς δεν θα παρατηρήσει αλλαγές στο δηλωτικό ανάπτυξης.

Επιλογή --vm:ext-str digest="$DIGEST" για qbec - σας επιτρέπει να περάσετε μια εξωτερική μεταβλητή στο jsonnet. Θέλουμε η εφαρμογή μας να αναδιατάσσεται στο σύμπλεγμα με κάθε κυκλοφορία. Δεν μπορούμε πλέον να χρησιμοποιούμε το όνομα της ετικέτας, το οποίο μπορεί πλέον να είναι αμετάβλητο, καθώς πρέπει να συνδεθούμε σε μια συγκεκριμένη έκδοση της εικόνας και να ενεργοποιήσουμε την ανάπτυξη όταν αλλάξει.

Εδώ, θα μας βοηθήσει η ικανότητα του Kaniko να αποθηκεύει τη σύνοψη της εικόνας σε ένα αρχείο (επιλογή --digest-αρχείο)
Στη συνέχεια, θα μεταφέρουμε αυτό το αρχείο και θα το διαβάσουμε κατά τη στιγμή της ανάπτυξης.

Ας ενημερώσουμε τις παραμέτρους για το δικό μας deploy/website/environments/base.libsonnet που τώρα θα μοιάζει με αυτό:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

Έγινε, τώρα οποιαδήποτε δέσμευση κύριος αρχικοποιεί τη δημιουργία της εικόνας docker για , και στη συνέχεια αναπτύξτε το στο Kubernetes.

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .
git commit -m "Configure dynamic build"

Ελέγξτε το μετά git push θα πρέπει να δούμε κάτι σαν αυτό:

Στιγμιότυπο οθόνης Pipeline για master

Κατ 'αρχήν, δεν χρειάζεται να αναδιατάσσουμε το gitlab-runner με κάθε ώθηση, εκτός αν, φυσικά, δεν έχει αλλάξει τίποτα στη διαμόρφωσή του, ας το διορθώσουμε στο .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

αλλαγές θα παρακολουθεί τις αλλαγές σε deploy/gitlab-runner/ και θα ενεργοποιήσει τη δουλειά μας μόνο αν υπάρχουν

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

git push, αυτό είναι καλύτερο:

Στιγμιότυπο οθόνης του ενημερωμένου αγωγού

12. Δυναμικά περιβάλλοντα

Είναι καιρός να διαφοροποιήσουμε τη γραμμή μας με δυναμικά περιβάλλοντα.

Αρχικά, ας ενημερώσουμε την εργασία build_website σε μας .gitlab-ci.yml, αφαιρώντας το μπλοκ από αυτό αποκλειστικά , που θα αναγκάσει το Gitlab να το ενεργοποιήσει σε οποιαδήποτε δέσμευση σε οποιοδήποτε κλάδο:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

Στη συνέχεια, ενημερώστε την εργασία deploy_website, προσθέστε ένα μπλοκ εκεί θετική ατμόσφαιρα:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

Αυτό θα επιτρέψει στο Gitlab να συσχετίσει την εργασία με κέντρο περιβάλλον και εμφανίστε τον σωστό σύνδεσμο προς αυτό.

Τώρα ας προσθέσουμε δύο ακόμη θέσεις εργασίας:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

Θα ενεργοποιηθούν με ώθηση σε οποιοδήποτε κλάδο εκτός από τον κύριο και θα αναπτύξουν μια έκδοση προεπισκόπησης του ιστότοπου.

Βλέπουμε μια νέα επιλογή για το qbec: --εφαρμογή-ετικέτα - Σας επιτρέπει να προσθέτετε ετικέτες σε αναπτυγμένες εκδόσεις της εφαρμογής και να εργάζεστε μόνο εντός αυτής της ετικέτας· όταν δημιουργείτε και καταστρέφετε πόρους στο Kubernetes, το qbec θα λειτουργεί μόνο σε αυτούς.
Έτσι, δεν μπορούμε να δημιουργήσουμε ξεχωριστό περιβάλλον για κάθε κριτική, αλλά απλώς να επαναχρησιμοποιήσουμε το ίδιο.

Εδώ χρησιμοποιούμε επίσης Qbec εφαρμόστε την αναθεώρηση, αντί qbec εφαρμόστε την προεπιλογή - αυτή είναι ακριβώς η στιγμή που θα προσπαθήσουμε να περιγράψουμε τις διαφορές για τα περιβάλλοντά μας (αναθεώρηση και προεπιλογή):

Ας προσθέσουμε ανασκόπηση περιβάλλον σε deploy/website/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

Μετά το δηλώνουμε deploy/website/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

Και γράψτε προσαρμοσμένες παραμέτρους για αυτό μέσα deploy/website/environments/review.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

Ας ρίξουμε επίσης μια πιο προσεκτική ματιά στη δουλειά stop_review, θα ενεργοποιηθεί όταν αφαιρεθεί το υποκατάστημα και έτσι ώστε το gitlab να μην προσπαθήσει να κάνει ταμείο σε αυτό χρησιμοποιείται GIT_STRATEGY: καμία, αργότερα κλωνοποιούμε κύριος-υποκατάστημα και διαγραφή κριτικής μέσω αυτού.
Λίγο μπερδεμένο, αλλά δεν έχω βρει ακόμα πιο όμορφο τρόπο.
Μια εναλλακτική επιλογή θα ήταν η ανάπτυξη κάθε κριτικής σε έναν χώρο ονομάτων ξενοδοχείου, ο οποίος μπορεί πάντα να καταργηθεί στο σύνολό του.

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .
git commit -m "Enable automatic review"

git push, git checkout -b τεστ, git push origin test, ελέγξτε:

Στιγμιότυπο οθόνης δημιουργημένων περιβαλλόντων στο Gitlab

Όλα λειτουργούν; - υπέροχο, διαγράψτε το δοκιμαστικό μας κλάδο: git master checkout, git push origin :test, ελέγχουμε ότι οι εργασίες για τη διαγραφή του περιβάλλοντος λειτούργησαν χωρίς σφάλματα.

Εδώ θέλω αμέσως να διευκρινίσω ότι οποιοσδήποτε προγραμματιστής στο έργο μπορεί να δημιουργήσει υποκαταστήματα, μπορεί επίσης να αλλάξει .gitlab-ci.yml αρχείο και πρόσβαση σε μυστικές μεταβλητές.
Επομένως, συνιστάται ανεπιφύλακτα να επιτρέπεται η χρήση τους μόνο για προστατευμένα κλαδιά, για παράδειγμα σε κύριος, ή δημιουργήστε ένα ξεχωριστό σύνολο μεταβλητών για κάθε περιβάλλον.

13 Αξιολόγηση εφαρμογών

Έλεγχος εφαρμογών Αυτή είναι μια δυνατότητα gitlab που σας επιτρέπει να προσθέσετε ένα κουμπί για κάθε αρχείο στο αποθετήριο για να το προβάλετε γρήγορα στο αναπτυγμένο περιβάλλον.

Για να εμφανιστούν αυτά τα κουμπιά, πρέπει να δημιουργήσετε ένα αρχείο .gitlab/route-map.yml και περιγράψτε σε αυτό όλους τους μετασχηματισμούς των μονοπατιών, στην περίπτωσή μας θα είναι πολύ απλό:

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

Μην ξεχάσετε να πραγματοποιήσετε τις αλλαγές μας:

git add .gitlab/
git commit -m "Enable review apps"

git pushκαι ελέγξτε:

Στιγμιότυπο οθόνης του κουμπιού εφαρμογής κριτικής

Η δουλειά έγινε!

Πηγές έργου:

• στο gitlab: https://gitlab.com/kvaps/docs.example.org
• στο GitHub: https://github.com/kvaps/docs.example.org

Σας ευχαριστώ για την προσοχή σας, ελπίζω να σας άρεσε

Πηγή: www.habr.com