Examen de Skaffold pour le développement de Kubernetes

Examen de Skaffold pour le développement de Kubernetes

Il y a un an et demi, le 5 mars 2018, Google publiait la première version alpha de son projet Open Source pour CI/CD appelé Skaffold, dont l'objectif était de créer un « développement Kubernetes simple et reproductible » afin que les développeurs puissent se concentrer sur le développement plutôt que sur l'administration. Qu’est-ce qui pourrait être intéressant chez Skaffold ? Il s’avère qu’il a quelques atouts dans son sac qui peuvent en faire un outil puissant pour le développeur, et peut-être même pour l’ingénieur d’exploitation. Faisons connaissance avec le projet et ses capacités.

NB: D'ailleurs, nous avons déjà parlé brièvement de Skaffold dans notre général revue des outils de développement, dont la vie est liée à Kubernetes.

Théorie. Objectif et capacités

Ainsi, de manière générale, Skaffold résout le problème de l'automatisation du cycle CI/CD (aux étapes de construction, de poussée et de déploiement), en offrant au développeur un retour rapide, c'est-à-dire la possibilité de recevoir rapidement le résultat des modifications ultérieures du code - sous la forme d'une application mise à jour exécutée dans le cluster Kubernetes. Et cela peut fonctionner dans différents circuits (développement, scène, production...), pour lesquels Skaffold aide à décrire les pipelines correspondants pour le déploiement.

Le code source de Skaffold est écrit en Go, distribué par sous la licence gratuite Apache 2.0 (GitHub).

Examinons les principales fonctions et caractéristiques. Les premiers comprennent les éléments suivants :

  • Skaffold propose des outils pour créer des pipelines CI/CD.
  • Vous permet de surveiller les modifications du code source en arrière-plan et d'exécuter un processus automatisé d'assemblage de code dans des images de conteneur, de publier ces images dans le registre Docker et de les déployer sur le cluster Kubernetes.
  • Synchronise les fichiers du référentiel avec le répertoire de travail du conteneur.
  • Teste automatiquement à l’aide de conteneur-structure-test.
  • Transfère les ports.
  • Lit les journaux d'une application exécutée dans un conteneur.
  • Aide au débogage des applications écrites en Java, Node.js, Python, Go.

Parlons maintenant des fonctionnalités :

  • Skaffold lui-même n'a aucun composant côté cluster. Autrement dit, il n'est pas nécessaire de configurer davantage Kubernetes pour utiliser cet utilitaire.
  • Différents pipelines pour votre application. Avez-vous besoin de déployer le code sur le Minikube local pendant que vous développez, puis de le mettre en scène ou en production ? A cet effet il y a Les profils et les configurations utilisateur, les variables d'environnement et les indicateurs, qui vous permettent de décrire différents pipelines pour une application.
  • CLI. Uniquement l'utilitaire de console et les configurations en YAML. Sur Internet, vous pouvez trouver des références à des tentatives de création interface graphique expérimentale, cependant, pour le moment, cela signifie probablement simplement que quelqu'un a besoin de lui, mais pas vraiment.
  • Modularité. Skaffold n'est pas une moissonneuse autonome, mais vise à utiliser des modules individuels ou des solutions existantes pour des tâches spécifiques.

Illustration de ce dernier :

  • Au stade de l'assemblage, vous pouvez utiliser :
    • docker build localement, dans un cluster utilisant kaniko ou dans Google Cloud Build ;
    • Bazel localement ;
    • Jib Maven et Jib Gradle localement ou dans Google Cloud Build ;
    • les scripts de construction personnalisés s'exécutent localement. Si vous devez exécuter une autre solution de build (plus flexible/familière/...), elle est décrite dans le script afin que Skaffold la lance (exemple tiré de la documentation). Cela vous permet d'utiliser n'importe quel collecteur pouvant être appelé à l'aide d'un script ;
  • Au stade des tests, le déjà mentionné test de structure de conteneur;
  • Pour le déploiement, les éléments suivants sont fournis :
    • Kubectl ;
    • Barre;
    • Personnaliser.

Grâce à cela, Skaffold peut être qualifié d'unique cadre pour la création de CI/CD. Voici un exemple de flux de travail lors de son utilisation (tiré de la documentation du projet) :

Examen de Skaffold pour le développement de Kubernetes

À quoi ressemble le travail de Skaffold d’une manière générale ?

  1. L'utilitaire surveille les modifications dans le répertoire du code source. Si des modifications sont apportées aux fichiers, elles sont synchronisées avec le pod d'application dans le cluster Kubernetes. Si possible, sans réassembler l'image. Sinon, une nouvelle image est assemblée.
  2. L'image assemblée est vérifiée à l'aide du test de structure de conteneur, étiquetée et envoyée au registre Docker.
  3. Après cela, l'image est déployée - déployée dans le cluster Kubernetes.
  4. Si le lancement a été initialisé à l'aide de la commande skaffold dev, puis nous commençons à recevoir des journaux de l'application et Skaffold attend les modifications pour répéter à nouveau toutes les actions.

Examen de Skaffold pour le développement de Kubernetes
Illustration des principales étapes du fonctionnement de Skaffold

Pratique. Essayer Skaffold

Pour démontrer l'utilisation de Skaffold, je prendrai un exemple de Dépôt de projet GitHub. Au fait ibid Vous pouvez trouver de nombreux autres exemples qui prennent en compte diverses spécificités. J'effectuerai toutes les actions localement dans Minikube. L'installation est simple et prend quelques minutes, et vous aurez besoin de kubectl pour commencer.

Installez Skaffold :

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
skaffold version
v0.37.1

Clonons le référentiel de Skaffold avec les exemples nécessaires :

git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservices

J'ai choisi un exemple avec deux pods, chacun contenant une petite application Go. Une application est le frontend (leeroy-web), qui redirige la demande vers la deuxième application - le backend (leeroy-app). Voyons à quoi cela ressemble :

~/skaffold/examples/microservices # tree
.
├── leeroy-app
│   ├── app.go
│   ├── Dockerfile
│   └── kubernetes
│       └── deployment.yaml
├── leeroy-web
│   ├── Dockerfile
│   ├── kubernetes
│   │   └── deployment.yaml
│   └── web.go
├── README.adoc
└── skaffold.yaml
 
4 directories, 8 files

leeroy-app et leeroy-web contiennent du code Go et de simples Dockerfiles pour construire ce code localement :

~/skaffold/examples/microservices # cat leeroy-app/Dockerfile
FROM golang:1.12.9-alpine3.10 as builder
COPY app.go .
RUN go build -o /app .
 
FROM alpine:3.10
CMD ["./app"]
COPY --from=builder /app .

Je ne donnerai pas le code de l'application - il suffit de le savoir leeroy-web accepte les demandes et les mandate leeroy-app. Donc dans les fichiers Deployment.yaml il existe un service uniquement pour app (pour le routage interne). Port du module web nous nous le transmettrons pour un accès rapide à l'application.

On dirait skaffold.yaml:

~/skaffold/examples/microservices # cat skaffold.yaml
apiVersion: skaffold/v1beta13
kind: Config
build:
  artifacts:
    - image: leeroy-web
      context: ./leeroy-web/
    - image: leeroy-app
      context: ./leeroy-app/
deploy:
  kubectl:
    manifests:
      - ./leeroy-web/kubernetes/*
      - ./leeroy-app/kubernetes/*
portForward:
  - resourceType: deployment
    resourceName: leeroy-web
    port: 8080
    localPort: 9000

Toutes les étapes mentionnées ci-dessus sont décrites ici. En plus de cette configuration, il existe également un fichier avec les paramètres globaux - ~/.skaffold/config. Il peut être modifié manuellement ou via la CLI - par exemple, comme ceci :

skaffold config set --global local-cluster true

Cette commande définira la variable globale local-cluster dans le sens true, après quoi Skaffold n'essaiera pas de transférer les images vers le registre distant. Si vous développez localement, vous pouvez utiliser cette commande pour créer des images localement.

Retour à skaffold.yaml:

  • Sur la scène build nous précisons que vous devez collecter et sauvegarder l'image localement. Après la première exécution de la build, nous verrons ce qui suit :
    // т.к. Minikube создает кластер в отдельной виртуальной машине,
    // придется проникнуть внутрь, чтобы найти образы
    # minikube ssh
    $ docker images
    REPOSITORY                                TAG                                                                IMAGE ID            CREATED             SIZE 
    leeroy-app                                7d55a50803590b2ff62e47e6f240723451f3ef6f8c89aeb83b34e661aa287d2e   7d55a5080359        4 hours ago         13MB 
    leeroy-app                                v0.37.1-171-g0270a0c-dirty                                         7d55a5080359        4 hours ago         13MB
    leeroy-web                                5063bfb29d984db1ff70661f17d6efcc5537f2bbe6aa6907004ad1ab38879681   5063bfb29d98        5 hours ago         13.1MB
    leeroy-web                                v0.37.1-171-g0270a0c-dirty                                         5063bfb29d98        5 hours ago         13.1MB

    Comme vous pouvez le voir, Skaffold a lui-même étiqueté les images. À propos, plusieurs politiques de balisage sont prises en charge.

  • Plus loin dans la config c'est indiqué context: ./leeroy-app/, c'est à dire. le contexte dans lequel l'image est collectée est précisé.
  • Au stade du déploiement, il est déterminé que nous utiliserons kubectl et un masque pour les manifestes nécessaires.
  • PortForward: similaire à la façon dont nous transférons habituellement les ports en utilisant kubectl port-forward, nous donnons des instructions à Skaffold pour appeler cette commande. Dans ce cas, le port local 9000 est transféré vers 8080 dans le déploiement avec le nom leeroy-web.

Il est temps de se lancer skaffold dev: L’équipe créera une « boucle de rétroaction » continue, c’est-à-dire non seulement il collectera tout et le déploiera sur le cluster, mais il vous informera également de l'état actuel des pods, surveillera les changements et mettra à jour l'état des pods.

Voici le résultat du lancement skaffold dev --port-forward au remontage :

Examen de Skaffold pour le développement de Kubernetes

Tout d’abord, vous pouvez voir que le cache est utilisé. Ensuite, l'application est assemblée, déployée et les ports sont transférés. Depuis spécifié --port-forward, Skaffold a transmis le port à web, comme on lui a demandé, mais ici app il a lancé à sa discrétion (a choisi le gratuit le plus proche). Après cela, nous recevons les premiers logs des applications.

Vérifions si ça marche ?

~/skaffold/examples/microservices # kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
leeroy-app-6998dfcc95-2nxvf   1/1     Running   0          103s
leeroy-web-69f7d47c9d-5ff77   1/1     Running   0          103s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy app!!!

Modification du fichier leeroy-app/app.go - quelques secondes passent... et :

~/skaffold/examples/microservices # kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
leeroy-app-ffd79d986-l6nwp    1/1     Running   0          11s
leeroy-web-69f7d47c9d-5ff77   1/1     Running   0          4m59s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy Habr!!!

Dans le même temps, Skaffold lui-même affichait la même chose dans la console qu'avant, à l'exception d'un point : il n'a déployé que leeroy-app, et pas tout à la fois.

Plus d'entraînement

Il convient également de mentionner que lors de la création d'un nouveau projet, les configurations pour Skaffold peuvent être démarrées à l'aide de la commande init, ce qui est très pratique. De plus, vous pouvez écrire plusieurs configs : effectuer le développement sur la config par défaut, puis déployer en stage avec la commande run (même processus que dev, ne surveille tout simplement pas les changements), en utilisant une configuration différente.

Sur Katacoda, il y a руководство C'est encore plus simple avec un exemple. Mais il propose un bac à sable prêt à l'emploi avec Kubernetes, une application et Skaffold. Une excellente option si vous souhaitez essayer vous-même les bases.

Un cas d'utilisation possible de Skaffold consiste à effectuer du développement sur un cluster distant. Tout le monde n'est pas à l'aise pour exécuter Minikube sur son propre matériel, puis déployer l'application et s'attendre à ce qu'elle fonctionne correctement... Dans ce cas, Skaffold résout parfaitement le problème, ce qui peut être confirmé, par exemple, par les ingénieurs de Reddit, comme nous l'avons fait. déjà discuté écrit dans notre blog.

Et dans cette publication sur Weaveworks, vous pouvez trouver un exemple de création d'un pipeline pour la production.

Conclusion

Skaffold est un outil pratique pour créer des pipelines impliquant le déploiement d'applications sur Kubernetes et principalement axés sur les besoins de développement. Cela permet de créer assez facilement un pipeline « court » qui prend en compte les besoins fondamentaux du développeur, mais si vous le souhaitez, vous pouvez organiser des processus plus vastes. Comme l'un des exemples clairs d'utilisation de Skaffold dans les processus CI/CD donné tel projet de test de 10 microservices utilisant les capacités de Kubernetes, gRPC, Istio et OpenCensus Tracing.

Skaffold compte déjà près de 8000 XNUMX+ étoiles sur GitHub, est développé par Google et fait partie de GoogleContainerTools — en général, à l'heure actuelle, il y a toutes les raisons de croire que le projet se développera heureusement pour toujours.

PS

A lire aussi sur notre blog :

Source: habr.com

Ajouter un commentaire