déployer Archives - XpresServers

Comment déployer une application Django flexible et sécurisée avec Kubernetes

Introduction

Au cours de ce tutoriel, vous allez déployer une application de sondage Django conteneurisée dans un cluster Kubernetes.

Django est un framework web puissant qui peut vous aider à lancer votre application en Python. Il intègre plusieurs fonctionnalités pratiques comme un object-relational mapper, l’authentification des utilisateurs et une interface d’administration personnalisable pour votre application. Il comprend également un caching framework et encourage la conception de l’application propre grâce à son URL Dispatcher et son système de modèles.

Dans le tutoriel Comment créer une application Django et Gunicorn avec Docker, le tutoriel Django sur l’application de sondages a été modifié en prenant en considération la méthodologie du Twelve-Factor pour créer des applications web natives en nuage. Cette configuration conteneurisée a été cadrée et sécurisée par un certificat TLS Nginx reverse-proxy et Let’s Encrypt-signed dans le tutoriel Comment cadrer et sécuriser une application Django avec Docker, Nginx et Let’s Encrypt. Au cours de ce dernier tutoriel dans les séries Des conteneurs à Kubernetes avec Django, la nouvelle version de l’application de sondage Django sera déployée dans un cluster Kubernetes.

Kubernetes est un orchestrateur de conteneurs libre puissant qui automatise le déploiement, la mise à l’échelle et la gestion des applications conteneurisées. Les objets Kubernetes comme ConfigMaps et Secrets vous permettent de centraliser et de découpler la configuration de vos conteneurs, tandis que les contrôleurs comme les Deployments redémarrent automatiquement les conteneurs défaillants et permettent une mise à l’échelle rapide des répliques de conteneurs. L’activation du chiffrement TLS se fait à l’aide d’un objet Ingress et le contrôleur Ingress open-source ingress-nginx. L’add-on Kubernetes cert-manager renouvelle et publie des certificats à l’aide de l’autorité de certification gratuite Let’s Encrypt.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de :

Un cluster 1.15+ Kubernetes avec role-based access control (RBAC) activé. Cette configuration utilisera un cluster DigitalOcean Kubernetes. Cependant, vous pouvez créer un cluster en utilisant une autre méthode.
L’outil de ligne de commande kubectl installé sur votre machine locale et configuré pour vous connecter à votre cluster. Vous pouvez en savoir plus sur l’installation de kubectl dans la documentation officielle. Si vous utilisez un cluster DigitalOcean Kubernetes, veuillez consulter : Comment se connecter à un cluster DigitalOcean Kubernetes pour apprendre à vous connecter à votre cluster en utilisant kubectl.
Un nom de domaine enregistré. Tout au long de ce tutoriel, nous utiliserons your_domain.com. Vous pouvez en obtenir un gratuitement sur Freenom ou utiliser le registre de domaine de votre choix.
Un contrôleur d’Ingress ingress-nginx et le gestionnaire de certificats TLS cert-manager installés sur votre cluster et configurés pour émettre des certificats TLS. Pour apprendre à installer et configurer un Ingress avec gestionnaire de certificats, veuillez consulter Comment configurer un Ingress Nginx avec Cert-Manager sur DigitalOcean Kubernetes.
Un enregistrement DNS A avec your_domain.com pointant sur l’adresse IP publique du load balancer Ingress. Si vous utilisez DigitalOcean pour gérer les enregistrements DNS de votre domaine, consultez Comment gérer des enregistrements DNS pour apprendre à créer des enregistrements A.
Un object storage bucket S3 comme un espace DigitalOceanpour stocker les fichiers statiques de votre projet Django et un ensemble de clés d’accès pour cet espace. Pour apprendre à créer un espace, consultez la documentation produit Comment créer des espaces. Pour apprendre à créer des clés d’accès pour les espaces, consultez Partager l’accès aux espaces avec les clés d’accès. Avec des modifications mineures, vous pouvez utiliser n’importe quel service de stockage d’objets que le plugin django-storages prend en charge.
Une instance serveur PostgreSQL, une base de données et un utilisateur pour votre application Django. Avec des modifications mineures, vous pouvez utiliser n’importe quelle base de données que Django prend en charge.
Un compte Docker Hub et un référentiel public. Pour plus d’informations sur la création de ces éléments, veuillez consulter le document Référentiels de la documentation fournie par Docker.
Le moteur Docker installé sur votre machine locale. Veuillez-vous reporter Comment installer et utiliser Docker sur Ubuntu 18.04 pour en savoir plus.

Une fois ces composants configurés, vous êtes prêt à suivre ce guide.

Étape 1 — Cloner et configurer l’application

Au cours de cette étape, nous allons cloner le code de l’application de GitHub et configurer des paramètres comme les identifiants de la base de données et les clés de stockage d’objets.

Vous pourrez trouver le code de l’application et le Dockerfile dans la branche polls-docker du GitHub repository de l’application de sondage du tutorial Django. Ce référentiel contient le code pour l’exemple d’application de sondage utilisé dans la documentation de Django, qui vous apprend à développer une application de sondage à partir de zéro.

La branche polls-docker contient une version dockerisée de l’application de sondage. Pour savoir de quelle manière l’application de sondage a été modifiée pour fonctionner efficacement dans un environnement conteneurisé, consultez Comment construire une application Django et Gunicorn avec Docker.

Tout d’abord, utilisez git pour cloner la branche polls-docker du GitHub repository de l’application de sondage Django sur votre machine locale :

git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

Naviguez dans le répertoire django-polls :

Ce répertoire contient le code Python de l'application Django, un Dockerfile que Docker utilisera pour construire l'image du conteneur, ainsi qu'un fichier env qui contient une liste de variables d'environnement à passer dans l'environnement d'exécution du conteneur. Inspectez le Dockerfile :

OutputFROM python:3.7.4-alpine3.10

ADD django-polls/requirements.txt /app/requirements.txt

RUN set -ex 
    && apk add --no-cache --virtual .build-deps postgresql-dev build-base 
    && python -m venv /env 
    && /env/bin/pip install --upgrade pip 
    && /env/bin/pip install --no-cache-dir -r /app/requirements.txt 
    && runDeps="$(scanelf --needed --nobanner --recursive /env 
        | awk '{ gsub(/,/, "nso:", $2); print "so:" $2 }' 
        | sort -u 
        | xargs -r apk info --installed 
        | sort -u)" 
    && apk add --virtual rundeps $runDeps 
    && apk del .build-deps

ADD django-polls /app
WORKDIR /app

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

EXPOSE 8000

CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi"]

Ce Dockerfile utilise la Docker image officielle de Python 3.7.4 comme base et installe les exigences du paquet Python de Django et Gunicorn, telles que définies dans le fichier django-polls/requirements.txt. Il supprime ensuite quelques fichiers de construction inutiles, copie le code de l'application dans l'image, et définit le PATH d'exécution. Enfin, il déclare que le port 8000 sera utilisé pour accepter les connexions de conteneurs entrantes, et exécute gunicorn avec 3 travailleurs, en écoutant sur le port 8000.

Pour en savoir plus sur chacune des étapes de ce Dockerfile, consultez l'Étape 6 de Comment construire une application Django et Gunicorn avec Docker.

Maintenant, construisez l'image à l'aide de docker build :

Nous nommons l'image polls en utilisant le drapeau -t et passons dans le répertoire courant comme contexte de construction, l'ensemble de fichiers à faire référence lors de la construction de l'image.

Après que Docker ait construit et étiqueté l'image, listez les images disponibles à l'aide de docker images :

Vous devriez voir l'image polls listée :

OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
polls               latest              80ec4f33aae1        2 weeks ago         197MB
python              3.7.4-alpine3.10    f309434dea3a        8 months ago        98.7MB

Avant de lancer le conteneur Django, nous devons configurer son environnement d'exécution à l'aide du fichier env présent dans le répertoire actuel. Ce fichier sera transmis dans la commande docker run utilisée pour exécuter le conteneur, et Docker injectera les variables d'environnement configurées dans l'environnement d'exécution du conteneur.

Ouvrez le fichier env avec nano ou votre éditeur préféré :

django-polls/env

DJANGO_SECRET_KEY=
DEBUG=True
DJANGO_ALLOWED_HOSTS=
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=
DATABASE_PASSWORD=
DATABASE_HOST=
DATABASE_PORT=
STATIC_ACCESS_KEY_ID=
STATIC_SECRET_KEY=
STATIC_BUCKET_NAME=
STATIC_ENDPOINT_URL=
DJANGO_LOGLEVEL=info

Remplissez les valeurs manquantes des clés suivantes :

DJANGO_SECRET_KEY : définissez cette valeur à une valeur unique et imprévisible, comme indiqué dans les docs de Django. Une méthode de génération de cette clé est fournie dans Ajustement des paramètres du tutoriel sur les applications Django dimensionnables.
DJANGO_ALLOWED_HOSTS: : cette variable sécurise l'application et prévient les attaques d'en-tête d'hôte HTTP. Pour les besoins de test, définissez cette variable à *, un joker qui correspondra à tous les hôtes. En production, vous devriez la définir sur your_domain.com. Pour en savoir plus sur ce paramètre Django, consultez les paramètres de base dans les docs Django.
DATABASE_USERNAME : définissez ce paramètre sur l'utilisateur de la base de données PostgreSQL créé dans les étapes préalables.
DATABASE_NAME : définissez ce paramètres sur polls ou le nom de la base de données PostgreSQL créée dans les étapes préalables.
DATABASE_PASSWORD : définissez ce paramètre sur le mot de passe de l'utilisateur PostgreSQL créé dans les étapes préalables.
DATABASE_HOST : définissez ce paramètre sur le nom d'hôte de votre base de données.
DATABASE_PORT : définissez ce paramètre sur le port de votre base de données.
STATIC_ACCESS_KEY_ID : définissez ce paramètre sur la clé d'accès de votre espace ou stockage d'objets.
STATIC_SECRET_KEY : définissez ce paramètre sur la clé d'accès de votre espace ou stockage d'objets Secret.
STATIC_BUCKET_NAME : définissez ce paramètre sur votre nom d'espace ou votre object storage bucket.
STATIC_ENDPOINT_URL : définissez ce paramètre sur les URL applicables de vos espaces ou du point final du stockage des abjets, par exemple https://space-name.nyc3.digitaloceanspaces.com si votre espace se trouve dans la région nyc3.

Une fois que vous avez terminé vos modifications, enregistrez et fermez le fichier.

Au cours de la prochaine étape, nous allons exécuter un conteneur configuré localement et créer un schéma de base de données Nous allons également charger des actifs statiques, comme des feuilles de style ou des images, dans le stockage d'objets.

`Étape 2 - Création du schéma de la base de données et chargement d'actifs dans le stockage d'objets`

Une fois le conteneur créé et configuré, utilisez docker run pour remplacer le paramètre CMD dans le Dockerfile et créer le schéma de la base de données à l'aide des commandes manage.py et manage.py migrate :

docker run --env-file env polls sh -c "python manage.py makemigrations && python manage.py migrate"

Nous lançons le container d'images polls:latest, nous passons dans le fichier variable d'environnement que nous venons de modifier, et remplacons la commande Dockerfile par sh -c "python manage.py makemigrations python manage.py image", qui créera le schéma de base de données défini par le code de l'application.

Si vous exécutez cette opération pour la première fois, vous devriez voir apparaître ce qui suit :

OutputNo changes detected
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying polls.0001_initial... OK
  Applying sessions.0001_initial... OK

Cela indique que le schéma de base de données a été créé avec succès.

Si vous exécutez migrate une fois de plus, Django effectuera un no-op à moins que le schéma de base de données ait changé.

Ensuite, nous allons exécuter une autre instance du conteneur de l'application et utiliser un shell interactif à l'intérieur de celui-ci pour créer un utilisateur administratif pour le projet Django.

docker run -i -t --env-file env polls sh

Vous obtiendrez une invite shell à l'intérieur du conteneur en cours d'exécution que vous pouvez utiliser pour créer l'utilisateur Django :

python manage.py createsuperuser

Entrez un nom d'utilisateur, une adresse email et un mot de passe pour votre utilisateur, et après avoir créé l'utilisateur, appuyez sur CTRL+D pour quitter le conteneur et le fermer.

Enfin, nous allons générer les fichiers statiques pour l'application et les télécharger sur l'espace DigitalOcean à l'aide de collectstatic. Notez que cela peut prendre un peu de temps.

docker run --env-file env polls sh -c "python manage.py collectstatic --noinput"

Une fois que ces fichiers sont générés et téléchargés, vous obtiendrez la sortie suivante.

Output121 static files copied.

Nous pouvons maintenant exécuter l'application :

docker run --env-file env -p 80:8000 polls

Output[2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0
[2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync
[2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7
[2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8
[2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

Ici, nous exécutons la commande par défaut définie dans le Dockerfile gunicorn --bind :8000 --workers 3 mysite.wsgi:application et exposons le port de conteneur 8000 afin que le port 80 de votre machine locale soit mappé sur le port 8000 du conteneur polls.

Vous devriez maintenant pouvoir naviguez jusqu'à l'application polls à l'aide de votre navigateur web en tapant : http://localhost. Comme il n'y a pas de route définie pour le chemin d'accès / , vous obtiendrez probablement une erreur de recherche 404 Page Not Found, qui est prévisible.

Naviguez sur http://localhost/polls pour voir l'interface de l'application de sondage :

Pour voir l'interface administrative, allez à http://localhost/admin. Vous devriez voir la fenêtre d'authentification de l'application de sondage :

Entrez le nom d'utilisateur administratif et le mot de passe que vous avez créé avec la commande createsuperuser.

Après avoir été authentifié, vous pouvez accéder à l'interface administrative de l'application de sondage :

Notez que les actifs statiques pour les applications d’administration et de sondage sont livrées directement depuis le stockage d'objets. Pour confirmer ceci, consultez Testing Spaces Static File Delivery.

Lorsque vous avez terminé d'explorer, appuyez sur CTRL+C dans la fenêtre de terminal en exécutant le conteneur de Docker pour terminer le conteneur.

Une fois que l'image Docker de l'application Django est testée, les actifs statiques chargés sur le stockage d'objets et le schéma de base de données configuré et fonctionnel avec votre application, vous êtes prêt à charger votre image de l'application Django sur un registre d'images comme Docker Hub.

`Étape 3 - Pousser l'image de l'application Django sur Docker Hub`

Pour lancer votre application sur Kubernetes, votre image d'application doit être chargée sur un registre comme Docker Hub. Kubernetes ira extraire l'image de l'application de son référentiel, puis la déploiera sur votre cluster.

Vous pouvez utiliser un registre Docker privé, comme DigitalOcean Container Registry, actuellement gratuit en Early Access ou un registre Docker public comme Docker Hub. Docker Hub vous permet également de créer des référentiels Docker privés. Un référentiel public permet à quiconque de voir et d'extraire les images du conteneur, tandis qu'un référentiel privé vous permet de restreindre l'accès à vous et aux membres de votre équipe.

Au cours de ce tutoriel, nous allons pousser l'image Django sur le référentiel public Docker Hub créé dans les conditions préalablement citées. Vous pouvez également pousser votre image sur un référentiel privé, mais l'extraction d'images à partir d'un référentiel privé n'est pas traité dans le cadre de cet article. Pour en savoir plus sur l'authentification de Kubernetes avec Docker Hub et l'extraction d'images privées, veuillez consulter la section Extraire une image d'un référentiel privé dans les documents de Kubernetes.

Commencez par vous connecter à Docker Hub à partir de votre machine locale :

OutputLogin with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username:

Pour vous connecter, utilisez votre nom d'utilisateur et votre mot de passe Docker Hub.

L'image Django a actuellement la balise polls:latest. Pour la pousser sur votre référentiel Docker Hub, balisez à nouveau l'image en utilisant votre nom d'utilisateur Docker Hub et votre nom de référentiel :

docker tag polls:latest your_dockerhub_username/your_dockerhub_repo_name:latest

Poussez l'image sur le référentiel :

docker push sammy/sammy-django:latest

Pour ce tutoriel, nous utilisons le nom d'utilisateur Docker Hub sammy et le nom de référentiel sammy-django. Vous devez remplacer ces valeurs par votre propre nom d'utilisateur Docker Hub et votre nom de référentiel.

Vous verrez quelques résultats se mettre à jour alors que les couches des images sont poussées sur Docker Hub.

Maintenant que Kubernetes peut accéder à votre image sur Docker Hub, vous pouvez commencer à la déployer dans votre cluster.

`Étape 4 - Configuration de ConfigMap`

Lorsque nous avons exécuté le conteneur Django localement, nous avons passé le fichier env dans docker run pour injecter des variables de configuration dans l'environnement d'exécution. Sur Kubernetes, les variables de configuration peuvent être injectées à l'aide de ConfigMaps et Secrets.

ConfigMaps permet de stocker des informations de configuration non confidentielles comme les paramètres de l'application. Secrets permet de stocker des informations sensibles comme les clés API et les identifiants de la base de données. Ils sont tous les deux injectés dans des conteneurs de manière similaire, mais Secrets dispose d'un contrôle d'accès et de fonctionnalités de sécurité supplémentaires comme encryption at rest. Secrets stocke également les données dans base64, tandis que ConfigMaps stocke les données en texte clair.

Pour commencer, créez un répertoire que vous nommerez yaml dans lequel nous allons stocker nos manifestes Kubernetes. Naviguez dans le répertoire.

Ouvrez un fichier appelé polls-configmap.yaml dans nano ou votre éditeur de texte préféré :

nano polls-configmap.yaml

Collez–y le manifeste ConfigMap suivant :

polls-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: polls-config
data:
  DJANGO_ALLOWED_HOSTS: "*"
  STATIC_ENDPOINT_URL: "https://your_space_name.space_region.digitaloceanspaces.com"
  STATIC_BUCKET_NAME: "your_space_name"
  DJANGO_LOGLEVEL: "info"
  DEBUG: "True"
  DATABASE_ENGINE: "postgresql_psycopg2"

Nous avons extrait la configuration non sensible du fichier env modifié à l'étape 1 et l'avons collée dans un manifeste ConfigMap. L'objet ConfigMap se nomme polls-config. Copiez-y les mêmes valeurs que celles que vous avez saisies dans le fichier env à l'étape précédente.

Pour les besoins de test, laissez DJANGO_ALLOWED_HOSTS avec * pour désactiver le filtre configuré sur les en-têtes Host. Dans un environnement de production, vous devriez procéder à la même configuration sur le domaine de votre application.

Une fois que vous avez terminé de le modifier, enregistrez et fermez votre fichier.

Créez la ConfigMap dans votre cluster en utilisant kubectl apply :

kubectl apply -f polls-configmap.yaml

Outputconfigmap/polls-config created

Une fois la ConfigMap créée, nous allons créer le Secret que notre application utilisera à l'étape suivante.

`Étape 5 - Configuration du secret`

Les valeurs de Secret doivent être base64-encoded, ce qui signifie que la création d'objets Secret dans votre cluster exige un peu plus d'implication que la création de ConfigMaps. Vous pouvez répéter le processus décrit à l'étape précédente, en codant manuellement les valeurs Secret en baseb64 et en les collant dans un fichier de manifeste. Vous pouvez également les créer à l'aide d'un fichier variable d'environnement, kubectl create, et la balise --from-env-file, ce que nous ferons au cours de cette étape.

Nous utiliserons à nouveau le fichier env de l'étape 1, en supprimant les variables insérées dans la ConfigMap. Copiez le fichier env appelé polls-secrets dans le répertoire yaml :

cp ../env ./polls-secrets

Modifiez le fichier dans votre éditeur de texte préféré :

polls-secrets

DJANGO_SECRET_KEY=
DEBUG=True
DJANGO_ALLOWED_HOSTS=
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=
DATABASE_PASSWORD=
DATABASE_HOST=
DATABASE_PORT=
STATIC_ACCESS_KEY_ID=
STATIC_SECRET_KEY=
STATIC_BUCKET_NAME=
STATIC_ENDPOINT_URL=
DJANGO_LOGLEVEL=info

Supprimez toutes les variables insérées dans le manifeste ConfigMap. Une fois que vous aurez terminé, vous devriez obtenir un résultat similaire à ce qui suit :

polls-secrets

DJANGO_SECRET_KEY=your_secret_key
DATABASE_NAME=polls
DATABASE_USERNAME=your_django_db_user
DATABASE_PASSWORD=your_django_db_user_password
DATABASE_HOST=your_db_host
DATABASE_PORT=your_db_port
STATIC_ACCESS_KEY_ID=your_space_access_key
STATIC_SECRET_KEY=your_space_access_key_secret

Veillez à utiliser les mêmes valeurs que celles utilisées à l'étape 1. Une fois que vous avez terminé, enregistrez et fermez le fichier.

Créez le Secret dans votre cluster en utilisant kubectl create secret :

kubectl create secret generic polls-secret --from-env-file=poll-secrets

Outputsecret/polls-secret created

Ici, nous créons un objet Secret appelé polls-secret dans lequel vous intégrerez le fichier secrets que nous venons de créer.

Vous pouvez inspecter le Secret en utilisant kubectl describe:

kubectl describe secret polls-secret

OutputName:         polls-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
DATABASE_PASSWORD:     8 bytes
DATABASE_PORT:         5 bytes
DATABASE_USERNAME:     5 bytes
DJANGO_SECRET_KEY:     14 bytes
STATIC_ACCESS_KEY_ID:  20 bytes
STATIC_SECRET_KEY:     43 bytes
DATABASE_HOST:         47 bytes
DATABASE_NAME:         5 bytes

À ce stade, vous avez stocké la configuration de votre application dans votre cluster Kebernetes en utilisant des types d'objets Secret et ConfigMap. Nous sommes maintenant prêts à déployer l'application dans le cluster.

`Étape 6 - Déploiement de l'application Django avec un Déployment`

Au cours de cette étape, vous allez créer un Deployment pour votre application Django. Un Deployment est un contrôleur que vous pouvez utiliser pour gérer des applications apatrides dans votre cluster. Un contrôleur est une boucle de contrôle qui régule les charges de travail en les augmentant ou en les réduisant. Les contrôleurs redémarrent et suppriment les conteneurs défaillants.

Les Deployments contrôlent un ou plusieurs Pods, la plus petite unité déployable dans un cluster Kubernetes. Les Pods intègrent un ou plusieurs conteneurs. Pour en savoir plus sur les différents types de charges de travail que vous pouvez lancer, veuillez consulter Une introduction à Kubernetes.

Commencez par ouvrir le fichier appelé polls-deployment.yaml dans votre éditeur de texte préféré :

nano polls-deployment.yaml

Collez-y le manifeste de Deployment suivant :

polls-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: polls-app
  labels:
    app: polls
spec:
    replicas: 2
  selector:
    matchLabels:
      app: polls
  template:
    metadata:
      labels:
        app: polls
    spec:
      containers:
        - image: your_dockerhub_username/app_repo_name:latest
          name: polls
          envFrom:
          - secretRef:
              name: polls-secret
          - configMapRef:
              name: polls-config
          ports:
            - containerPort: 8000
              name: gunicorn

Renseignez le nom de l'image du conteneur applicable, qui doit faire référence à l'image Django Polls que vous avez poussée sur Docker Hub à l’étape 2.

Ici, nous allons définir un Deployment Kubernetes appelé polls-app et l'étiqueter avec la paire de valeur app: pools. Nous spécifions que nous souhaitons exécuter deux répliques du Pod défini sous le champ template.

En utilisant envFrom avec secretRef et configMapRef, nous spécifions que toutes les données du Secret polls-secret et de la ConfigMap polls-config doivent être injectées dans les conteneurs sous forme de variables d'environnement. Les clés ConfigMap et Secret deviennent les noms des variables d'environnement.

Enfin, nous allons exposer containerPort 8000 et le nommer gunicorn.

Pour en savoir plus sur la configuration des Deployments de Kubernetes, veuillez consulter le document Deployments dans la documentation de Kubernetes.

Une fois que vous avez terminé de le modifier, enregistrez et fermez votre fichier.

Créez le Deployment dans votre cluster en utilisant kubectl apply -f :

kubectl apply -f polls-deployment.yaml

deployment.apps/polls-app created

Vérifiez que le Deployment s'est correctement déployé en utilisant kubectl get :

kubectl get deploy polls-app

OutputNAME        READY   UP-TO-DATE   AVAILABLE   AGE
polls-app   2/2     2            2           6m38s

Si vous rencontrez une erreur ou que quelque chose qui ne fonctionne pas correctement, vous pouvez utiliser kubectl describe pour inspecter le Deployment défaillant :

Vous pouvez inspecter les deux Pods en utilisant kubectl get pod :

OutputNAME                         READY   STATUS    RESTARTS   AGE
polls-app-847f8ccbf4-2stf7   1/1     Running   0          6m42s
polls-app-847f8ccbf4-tqpwm   1/1     Running   0          6m57s

Deux répliques de votre application Django sont maintenant opérationnelles dans le cluster. Pour accéder à l'application, vous devez créer un service Kubernetes, ce que nous ferons ensuite.

`Étape 7 - Autoriser un accès externe à l'aide d'un Service`

Au cours de cette étape, vous allez créer un Service pour votre application Django. Un Service Kubernetes est une abstraction qui vous permet d'exposer un ensemble de Pods en cours d'exécution en tant que service réseau. En utilisant un Service, vous pouvez créer un point final stable pour votre application qui ne change pas à mesure que les Pods périssent et sont recréés.

Il existe plusieurs types de Services, dont : les Services ClusterIP qui exposent le Service sur un IP interne de cluster, les NodePort Services qui exposent le Service sur chaque nœud au niveau d'un port statique appelé NodePort et les LoadBalancer Services qui intègrent un équilibreur de charge du trafic externe vers les Pods dans votre cluster (via NodePorts, ce qu'il crée automatiquement). Pour en savoir plus sur ces éléments, consultez le document Service dans la documentation de Kubernetes.

Pour notre configuration finale, nous allons utiliser un Service ClusterIP qui est exposé à l'aide d'un Ingress et du Controller Ingress configurés dans les conditions préalablement requises pour ce guide. Pour l'instant, pour vérifier que tout fonctionne correctement, nous allons créer un Service NodePort temporaire pour accéder à l'application Django.

Commencez par créer un fichier appelé polls-svc.yaml en utilisant votre éditeur de texte préféré :

Collez-y le manifeste de Service suivant :

polls-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: polls
  labels:
    app: polls
spec:
  type: NodePort
  selector:
    app: polls
  ports:
    - port: 8000
      targetPort: 8000

Ici, nous créons un NodePort Service appelé polls et lui donnons l'étiquette app: polls. Nous sélectionnons ensuite les Pods de backend portant l'étiquette app: polls et ciblons leurs ports 8000.

Une fois que vous avez terminé de le modifier, enregistrez et fermez votre fichier.

Déploiement du Service avec kubectl apply :

kubectl apply -f polls-svc.yaml

Outputservice/polls created

Confirmez que votre Service a été créé en utilisant kubectl get svc :

OutputNAME    TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
polls   NodePort   10.245.197.189   <none>        8000:32654/TCP   59s

Ce résultat affiche l'adresse IP interne du cluster de Service et NodePort (32654). Pour nous connecter au service, nous avons besoin de l'adresse IP externe de nos nœuds de cluster :

OutputNAME                   STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP      OS-IMAGE                       KERNEL-VERSION          CONTAINER-RUNTIME
pool-7no0qd9e0-364fd   Ready    <none>   27h   v1.18.8   10.118.0.5    203.0.113.1   Debian GNU/Linux 10 (buster)   4.19.0-10-cloud-amd64   docker://18.9.9
pool-7no0qd9e0-364fi   Ready    <none>   27h   v1.18.8   10.118.0.4    203.0.113.2    Debian GNU/Linux 10 (buster)   4.19.0-10-cloud-amd64   docker://18.9.9
pool-7no0qd9e0-364fv   Ready    <none>   27h   v1.18.8   10.118.0.3    203.0.113.3   Debian GNU/Linux 10 (buster)   4.19.0-10-cloud-amd64   docker://18.9.9

Dans votre navigateur Web, consultez votre application de sondage en utilisant l'adresse IP externe de n'importe quel nœud et le NodePort. Compte tenu du résultat ci-dessus, l'URL de l'application devrait être : http://203.0.113.1:32654/polls.

Vous devriez voir apparaître la même interface d'application de sondage que celle à laquelle vous avez accédé localement à l'étape 1 :

Vous pouvez répéter le même test en utilisant le chemin /admin : http://203.0.113.1:32654/admin. Vous devriez voir apparaître la même interface d'administration qu'auparavant :

À ce stade, vous avez déployé deux répliques du conteneur de l'application Django Polls en utilisant un Deployment. Vous avez également créé un terminal de réseau stable pour ces deux répliques et l'avez rendu accessible à l'extérieur à l'aide d'un Service NodePort.

La dernière étape de ce tutoriel consiste à sécuriser le trafic externe de votre application en utilisant HTTPS. Pour ce faire, nous allons utiliser le contrôleur Ingress ingress-nginx installé dans les conditions préalables requises et créer un objet Ingress pour acheminer le trafic externe vers le Service Kubernetes polls.

`Étape 8 - Configuration du HTTPS en utilisant Nginx Ingress et cert-manager`

Les Ingresses de Kubernetes vous permettent d'acheminer le trafic de manière flexible depuis votre cluster Kubernetes vers Services à l'intérieur de votre cluster. Ceci se fait en utilisant des objets Ingress qui définissent des règles pour acheminer le trafic HTTP et HTTPS aux Services Kubernetes et les Ingress Controllers, qui implémentent les règles en équilibrant le trafic de charge et en l'acheminant vers les Services du terminal applicables.

Dans les conditions préalablement requises, vous avez installé le contrôleur Ingress ingress-nginx et l'add-on d'automatisation des certificats TLS cert-manager. Vous avez également défini des ClusterIssuers de simulation et de production pour votre domaine en utilisant l'autorité de certification Let’s Encrypt, et créé un Ingress pour tester l'émission de certificats et le cryptage TLS sur deux Services de backend factices. Avant de poursuivre avec cette étape, vous devez supprimer Ingress echo-ingress créée dans le tutoriel préalable :

kubectl delete ingress echo-ingress

Si vous le voulez, vous pouvez également supprimer les Services et Deployments factices en utilisant kubectl delete svc et kubectl delete deploy, mais cela n'est pas essentiel pour terminer ce tutoriel.

Vous devriez également avoir créé un dossier A DNS avec your_domain.com pointant sur l'adresse IP publique de l'équilibreur de charge Ingress. Si vous utilisez un équilibreur de charge DigitalOcean, vous pouvez trouver cette adresse IP dans la section Load Balancer du panneau de configuration. Si vous utilisez également DigitalOcean pour gérer les enregistrements DNS de votre domaine, consultez Comment gérer des enregistrements DNS pour apprendre à créer des enregistrements A

Si vous utilisez DigitalOcean Kubernetes, assurez-vous également de bien avoir implémenté le détour décrit à l’étape 5 de Comment configurer un Ingress Nginx avec Cert-Manager sur DigitalOcean Kubernetes.

Une fois que vous disposez d'un enregistrement A pointant sur l'équilibreur de charge du contrôleur Ingress vous pouvez créer un Ingress pour your_domain.com et le Service polls.

Ouvrez un fichier appelé polls-ingress.yaml en utilisant votre éditeur de texte préféré :

Collez-y le manifeste Ingress suivant :

[polls-ingress.yaml]
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: polls-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - your_domain.com
    secretName: polls-tls
  rules:
  - host: your_domain.com
    http:
      paths:
      - backend:
          serviceName: polls
          servicePort: 8000

Nous créons un objet Ingress appelé polls-ingress et nous l'annotons pour instruire le plan de contrôle d'utiliser le contrôleur Ingress ingress-nginx et le ClusterIssuer de simulation. Nous activons également TLS pour your_domain.com et stockons le certificat et la clé privée dans un secret appelé polls-tls. Enfin, nous définissons une règle pour acheminer le trafic de l'hôte your_domain.com vers le Service polls sur le port 8000.

Une fois que vous avez terminé de le modifier, enregistrez et fermez votre fichier.

Créez l'Ingress dans votre cluster en utilisant kubectl apply :

kubectl apply -f polls-ingress.yaml

Outputingress.networking.k8s.io/polls-ingress created

Vous pouvez utiliser kubectl describe pour suivre l'état de l'Ingress que vous venez de créer :

kubectl describe ingress polls-ingress

OutputName:             polls-ingress
Namespace:        default
Address:          workaround.your_domain.com
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  polls-tls terminates your_domain.com
Rules:
  Host        Path  Backends
  ----        ----  --------
  your_domain.com
                 polls:8000 (10.244.0.207:8000,10.244.0.53:8000)
Annotations:  cert-manager.io/cluster-issuer: letsencrypt-staging
              kubernetes.io/ingress.class: nginx
Events:
  Type    Reason             Age   From                      Message
  ----    ------             ----  ----                      -------
  Normal  CREATE             51s   nginx-ingress-controller  Ingress default/polls-ingress
  Normal  CreateCertificate  51s   cert-manager              Successfully created Certificate "polls-tls"
  Normal  UPDATE             25s   nginx-ingress-controller  Ingress default/polls-ingress

Vous pouvez également exécuter un describe sur le certificat polls-tls afin de confirmer à nouveau que sa création est probante :

kubectl describe certificate polls-tls

Output. . .
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Issuing    3m33s  cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  3m32s  cert-manager  Stored new private key in temporary Secret resource "polls-tls-v9lv9"
  Normal  Requested  3m32s  cert-manager  Created new CertificateRequest resource "polls-tls-drx9c"
  Normal  Issuing    2m58s  cert-manager  The certificate has been successfully issued

Cela confirme que le certificat TLS a bien été émis et que le chiffrement HTTPS est maintenant actif pour your_domain.com.

Étant donné que nous avons utilisé le ClusterIssuer de simulation, la plupart des navigateurs web ne feront pas confiance au faux certificat Let’s Encrypt qu'il a émis, de sorte que la navigation sur your_domain.com vous renverra vers une page d'erreur.

Pour envoyer une requête de test, nous utiliserons wget à partir de la ligne de commande :

wget -O - http://your_domain.com/polls

Output. . .
ERROR: cannot verify your_domain.com's certificate, issued by ‘CN=Fake LE Intermediate X1’:
  Unable to locally verify the issuer's authority.
To connect to your_domain.com insecurely, use `--no-check-certificate'.

Nous allons utiliser la balise --no-check-certificate suggérée pour contourner la validation du certificat :

wget --no-check-certificate -q -O - http://your_domain.com/polls

Output

<link rel="stylesheet" type="text/css" href="https://your_space.nyc3.digitaloceanspaces.com/django-polls/static/polls/style.css">


    <p>No polls are available.</p>

Le résultat ainsi obtenu affiche le HTML de la page d'interface /polls, confirmant également que la feuille de style est servie à partir du stockage d'objets.

Maintenant que vous avez réussi à tester la délivrance de certificats en utilisant le ClusterIssuer de simulation, vous pouvez modifier l'Ingress pour utiliser le ClusterIssuer de production.

Ouvrez polls-ingress.yaml pour l'éditer à nouveau :

Modifiez l'annotation cluster-issuer

[polls-ingress.yaml]
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: polls-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - your_domain.com
    secretName: polls-tls
  rules:
  - host: your_domain.com
    http:
      paths:
      - backend:
          serviceName: polls
          servicePort: 8000

Lorsque vous avez terminé, enregistrez et fermez le fichier. Mettez à jour l'Ingress en utilisant kubectl apply :

kubectl apply -f polls-ingress.yaml

Outputingress.networking.k8s.io/polls-ingress configured

Vous pouvez utiliser kubectl describe certificate polls-tls et kubectl describe ingress polls-ingress pour suivre l'état de délivrance du certificat :

kubectl describe ingress polls-ingress

Output. . .
Events:
  Type    Reason             Age                From                      Message
  ----    ------             ----               ----                      -------
  Normal  CREATE             23m                nginx-ingress-controller  Ingress default/polls-ingress
  Normal  CreateCertificate  23m                cert-manager              Successfully created Certificate "polls-tls"
  Normal  UPDATE             76s (x2 over 22m)  nginx-ingress-controller  Ingress default/polls-ingress
  Normal  UpdateCertificate  76s                cert-manager              Successfully updated Certificate "polls-tls"

Le résultat ci-dessus confirme que le nouveau certificat de production a bien été émis et stocké avec succès dans le Secret polls-tls.

Naviguez vers your_domain.com/polls dans votre navigateur web pour confirmer que le cryptage HTTPS est activé et que tout fonctionne comme prévu. Vous devriez voir l'interface de l'application de sondage :

Vérifiez que le cryptage HTTPS est actif dans votre navigateur web. Si vous utilisez Google Chrome, tout fonctionne correctement si vous atteignez la page ci-dessus sans aucune erreur. En outre, vous devriez voir un cadenas dans la barre d'URL. Cliquez sur le cadenas pour inspecter les détails du certificat Let’s Encrypt.

Pour procéder à la tâche finale de nettoyage, vous pouvez facultativement commuter le type de Service polls de NodePort à Type ClusterIP interne uniquement.

Modifiez polls-svc.yaml en utilisant votre éditeur de texte :

Changez le type de NodePort à ClusterIP:

polls-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: polls
  labels:
    app: polls
spec:
  type: ClusterIP
  selector:
    app: polls
  ports:
    - port: 8000
      targetPort: 8000

Une fois que vous avez terminé de le modifier, enregistrez et fermez votre fichier.

Déployez les changements en utilisant kubectl apply :

kubectl apply -f polls-svc.yaml --force

Outputservice/polls configured

Confirmez que votre Service a bien été modifié en utilisant kubectl get svc :

OutputNAME    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
polls   ClusterIP   10.245.203.186   <none>        8000/TCP   22s

Ce résultat montre que le type de Service est désormais configuré sur ClusterIP. La seule façon d'y accéder consiste à le faire via votre domaine et l'Ingress créé à cette étape.

`Conclusion`

Au cours de ce tutoriel, vous avez déployé une application Django évolutive et sécurisée HTTPS dans un cluster Kubernetes. Le contenu statique est directement extrait du stockage d'objets. Le nombre de Pods en cours d'exécution peut rapidement être augmenté ou diminué en utilisant le champ replicas dans le manifeste de Deployment polls-app.

Si vous utilisez un espace DigitalOcean, vous pouvez également activer la livraison d'actifs statiques via un réseau de distribution de contenu et créer un sous-domaine personnalisé pour votre espace. Veuillez consulter la section Activer CDN du document Comment configurer une application Django évolutive avec des bases de données et des espaces gérés par DigitalOcean pour en savoir plus.

Pour découvrir le reste de la série, veuillez consulter notre page sur la série Du conteneur aux Kubernetes avec Django.

Source link

`Comment déployer Laravel 7 et MySQL sur Kubernetes en utilisant Helm`

hassan latif
blog

L’auteur a choisi le Diversity in Tech Fund pour recevoir un don dans le cadre du programme Write for DOnations.

`Introduction`

Laravel est l’une des infrastructures d’application PHP les plus populaires aujourd’hui. Son déploiement se fait généralement avec une base de données MySQL, mais il peut être configuré pour utiliser une variété d’options de stockage de données de backend. Laravel est fier de profiter des nombreuses fonctionnalités modernes de PHP et de son vaste écosystème complet de package.

Kubernetes est une plate-forme d’orchestration de conteneurs qui peut être hébergée sur des DigitalOcean Kubernetes clusters afin de simplifier la gestion et la configuration de conteneurs en production. Helm est un gestionnaire de packages Kubernetes qui facilite la configuration et l’installation des services et des pods sur Kubernetes.

Dans ce guide, vous allez créer une application Laravel PHP, développer votre application dans une image Docker et déployer cette image dans un cluster DigitalOcean Kubernetes en utilisant le LAMP Helm chart. Ensuite, vous configurerez un contrôleur d’entrée pour ajouter SSL et un nom de domaine personnalisé à votre application. Une fois terminé, vous disposerez d’une application Laravel fonctionnelle connectée à une base de données MySQL qui s’exécute sur un cluster Kubernetes.

`Conditions préalables`

Docker installé sur la machine à partir de laquelle vous accédez à votre cluster. Vous pouvez trouver des instructions détaillées sur l’installation de Docker pour la plupart des distributions Linux ici ou sur le site web de Docker pour d’autres systèmes d’exploitation.
Un compte sur Docker Hub pour stocker les images Docker que vous allez créer pendant ce tutoriel.
Un cluster DigitalOcean Kubernetes 1.17+ avec votre connexion configurée sur kubectl par défaut. Pour apprendre à créer un cluster Kubernetes sur DigitalOcean, voir notre Kubernetes Quickstart. Pour apprendre à se connecter au cluster, consultez Comment se connecter à un cluster DigitalOcean Kubernetes.
Le gestionnaire de paquets Helm 3 installé sur votre machine locale. Exécutez la première étape et ajoutez le référentiel stable à partir de la deuxième étape du tutoriel Comment installer un logiciel sur des clusters Kubernetes avec le Helm 3 Package Manager.
Un nom de domaine entièrement enregistré avec un enregistrement A disponible. Ce tutoriel utilisera your_domain. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom, ou utiliser le bureau d’enregistrement de domaine de votre choix. Pour le moment, ne vous souciez pas d’associer l’enregistrement A de votre domaine à un IP. Une fois que vous serez à l’étape 5 et que votre contrôleur Ingress est opérationnel, vous connecterez alors your_domain à l’IP qui convient.

`Étape 1 — Création d’une nouvelle application Laravel`

Au cours de cette étape, vous utiliserez Docker pour créer une nouvelle application Laravel 7. Cependant, vous devriez pouvoir suivre le même processus avec une application Laravel existante qui utilise MySQL comme base de données de sauvegarde. La nouvelle application que vous créez vérifiera que Laravel est bien connecté à la base de données et affichera le nom de la base de données.

Tout d’abord, allez dans votre répertoire principal. Ensuite, créez une nouvelle application Laravel à l’aide d’un conteneur Docker composer :

cd ~
docker run --rm -v $(pwd):/app composer create-project --prefer-dist laravel/laravel laravel-kubernetes

Une fois le conteneur créé et tous les paquets Composer installés, vous devriez voir une nouvelle installation de Laravel dans votre répertoire actuel sous le nom de laravel-kubernetes/. Allez dans ce dossier :

Vous exécuterez le reste des commandes de ce tutoriel à partir de là.

Cette application a pour rôle de tester votre connexion à la base de données et d’afficher son nom dans votre navigateur. Pour tester la connexion à la base de données, ouvrez le fichier ./resources/views/welcome.blade.php dans un éditeur de texte :

nano ./resources/views/welcome.blade.php

Trouvez la section <div class="links">...</div> et remplacez son contenu par ce qui suit :

./resources/views/welcome.blade.php

...
<div class="links">
   <strong>Database Connected: </strong>
    @php
        try {
            DB::connection()->getPDO();
            echo DB::connection()->getDatabaseName();
            } catch (Exception $e) {
            echo 'None';
        }
    @endphp
</div>
...

Enregistrez et fermez le fichier.

Voilà l’intégralité de la personnalisation que vous devez apporter à l’application Laravel par défaut dans le cadre de ce tutoriel. Une fois terminé, ce bref extrait de PHP testera votre connexion à la base de données et affichera le nom de la base de données sur l’écran de démarrage de Laravel dans votre navigateur web.

À l’étape suivante, vous utiliserez Docker pour créer une image contenant cette application Laravel et Docker Compose afin de tester son exécution locale et sa connexion à une base de données MySQL.

`Étape 2 — Conteneurisation de votre application Laravel`

Maintenant que vous avez créé une nouvelle application Laravel, vous devez créer votre code sur une image Docker, puis tester l’image avec Docker Compose. Bien que ce tutoriel ait pour objectif de vous apprendre à déployer votre application sur un cluster Kubernetes, Docker Compose est un moyen pratique de tester votre image et votre configuration Docker localement avant de l’exécuter dans le cloud. Cette boucle de rétroaction rapide peut s’avérer très utile pour effectuer et tester de petits changements.

Tout d’abord, en utilisant nano ou votre éditeur de texte préféré, créez un fichier à la racine de votre application Laravel que vous appelerez Dockerfile :

Ajoutez le contenu suivant. Docker utilisera ce fichier pour créer votre code dans une image :

./Dockerfile

FROM php:7.4-apache

# Install packages
RUN apt-get update && apt-get install -y 
    git 
    zip 
    curl 
    sudo 
    unzip 
    libicu-dev 
    libbz2-dev 
    libpng-dev 
    libjpeg-dev 
    libmcrypt-dev 
    libreadline-dev 
    libfreetype6-dev 
    g++

# Apache configuration
ENV APACHE_DOCUMENT_ROOT=/var/www/html/public
RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf
RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf
RUN a2enmod rewrite headers

# Common PHP Extensions
RUN docker-php-ext-install 
    bz2 
    intl 
    iconv 
    bcmath 
    opcache 
    calendar 
    pdo_mysql

# Ensure PHP logs are captured by the container
ENV LOG_CHANNEL=stderr

# Set a volume mount point for your code
VOLUME /var/www/html

# Copy code and run composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
COPY . /var/www/tmp
RUN cd /var/www/tmp && composer install --no-dev

# Ensure the entrypoint file can be run
RUN chmod +x /var/www/tmp/docker-entrypoint.sh
ENTRYPOINT ["/var/www/tmp/docker-entrypoint.sh"]

# The default apache run command
CMD ["apache2-foreground"]

Enregistrez et fermez le fichier.

Ce Dockerfile commence avec le PHP 7.4 Apache Docker Image que se trouve sur Docker Hub, puis installe plusieurs des paquets Linux qui sont généralement nécessaires aux applications Laravel. Ensuite, il crée des fichiers de configuration Apache et active les réécritures d’en-tête. Le Dockerfile installe plusieurs extensions PHP communes et ajoute une variable d’environnement afin que les journaux de Laravel soient bien acheminés vers le conteneur via stderr. Cela vous permettra de consulter les journaux Laravel en personnalisant vos journaux Docker Compose ou Kubernetes.

Enfin, le Dockerfile copie tous les codes de votre application Laravel sur /var/www/tmp et installe les dépendances Composer. Il définit ensuite un ENTRYPOINT, mais vous aurez besoin de créer ce fichier, ce que nous allons faire ensuite.

Dans le répertoire racine de votre projet, créez un nouveau fichier que vous appellerez docker-entrypoint.sh. Ce fichier s’exécutera lorsque votre conteneur sera exécuté localement ou dans le cluster Kubernetes. Il copiera ensuite votre code d’application Laravel du répertoire /var/www/tmp dans /var/www/html où Apache sera capable de le servir.

nano ./docker-entrypoint.sh

Maintenant, ajoutez le script suivant :

./docker-entrypoint.sh

#!/bin/bash

cp -R /var/www/tmp/. /var/www/html/
chown -R www-data:www-data /var/www/html

exec "$@"

La ligne finale, exec "$@" indique au shell d’exécuter toute commande ensuite passée à titre d’argument de l’entrée. Ceci est important car Docker doit continuer à exécuter la commande d’exécution d’Apache (apache2-foreground) une fois ce script exécuté. Enregistrez et fermez le fichier.

Ensuite, créez un fichier .dockerignore dans le répertoire racine de votre application. Lors de la création de votre image Docker, ce fichier veillera à ce qu’elle ne soit pas polluée par des paquets ou des fichiers d’environnement qui ne devraient pas y être copiés :

./.dockerignore

.env
/vendor

Enregistrez et fermez le fichier.

Avant de pouvoir exécuter votre application localement avec Docker Compose, vous devez créer un dernier fichier nommé docker-compose.yml. Mais, lors de la configuration de ce fichier YAML, vous devez saisir la APP_KEY générée par Laravel lors de l’installation. Trouvez-la en ouvrant et en faisant une recherche dans le fichier . /.env ou en exécutant les commandes chat et grep suivantes :

Vous verrez un résultat similaire à ce qui suit :

Output
APP_KEY=base64:0EHhVpgg ... UjGE=

Copiez votre clé dans votre presse-papiers. Veillez à bien inclure le préfixe base64: Maintenant, créez le fichier docker-compose.yml dans le répertoire racine de votre application :

nano ./docker-compose.yml

Ici, nous allons inclure l’image PHP de votre application Laravel ainsi qu’un conteneur MySQL pour exécuter votre base de données. Ajoutez le contenu suivant :

./docker-compose.yml

version: '3.5'
services:
  php:
    image: your_docker_hub_username/laravel-kubernetes:latest
    restart: always
    ports:
      - 8000:80
    environment:
      - APP_KEY="your_laravel_app_key"
      - APP_ENV=local
      - APP_DEBUG=true
      - DB_PORT=3306
      - DB_HOST=mysql
      - DB_DATABASE
      - DB_USERNAME
      - DB_PASSWORD
  mysql:
    image: mysql:5.7
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
      - MYSQL_DATABASE=${DB_DATABASE}
      - MYSQL_USER=${DB_USERNAME}
      - MYSQL_PASSWORD=${DB_PASSWORD}

Utilisez la variable APP_KEY que vous avez copiée dans votre presse-papiers pour la variable your_laravel_app_key et utilisez votre nom d’utilisateur Docker Hub pour la variable your_docker_hub_username. Enregistrez et fermez le fichier.

Vous allez créer la première image localement en utilisant docker build. La deuxième image est l’image officielle de MySQL Docker, disponible sur Docker Hub. Toutes deux nécessitent plusieurs variables d’environnement que vous allez inclure lors de l’exécution des conteneurs.

Pour créer l’image Docker qui contient votre application Laravel, exécutez la commande suivante. Veillez à bien remplacer your_docker_hub_username par votre nom d’utilisateur ou le nom d’utilisateur de votre équipe dans Docker Hub où cette image sera sauvegardée :

docker build -t your_docker_hub_username/laravel-kubernetes:latest .

Ensuite, vous pouvez exécuter les deux conteneurs avec Docker Compose et les identifiants de base de données nécessaires :

DB_ROOT_PASSWORD=rootpassword DB_DATABASE=local_db DB_USERNAME=admin DB_PASSWORD=password docker-compose up -d

Au besoin, vous pouvez modifier les quatre variables d’environnement utilisées ici (DB_ROOT_PASSWORD, DB_DATABASE, DB_USERNAME, DB_PASSWORD). Cependant, étant donné vous testez votre application que localement, inutile de les sécuriser pour le moment.

Il vous faudra près de 30 secondes pour que votre base de données MySQL soit initialisée et que vos conteneurs soient prêts. Une fois que cela est fait, vous pouvez consulter votre application Laravel sur votre machine sur localhost:8000.

Votre application PHP se connectera à votre base de données MySQL. Une fois connecté, vous verrez apparaître le texte « Database Connected: local_db » apparaître sous le logo Laravel.

Maintenant que vous avez testé votre image Docker localement avec Docker Compose, vous pouvez arrêter les conteneurs en exécutant docker-compose down :

Dans la section suivante, vous allez pousser votre image Docker sur Docker Hub afin que votre chart Helm puisse l’utiliser et déployer votre application dans votre cluster Kubernetes.

`Étape 3 — Poussez votre image Docker dans Docker Hub`

Votre code doit être disponible dans un registre de conteneurs pour que le chart Helm LAMP que vous utiliserez puisse le déployer sur Kubernetes. Bien que vous puissiez pousser votre image dans un registre privé ou autohébergé, aux fins de ce tutoriel, vous utiliserez un registre Docker public et gratuit sur Docker Hub.

Accédez à votre compte dans Docker Hub en utilisant votre navigateur web. Créez ensuite un nouveau référentiel nommé laravel-kubernetes.

Si vous n’êtes pas connecté à Docker Hub depuis votre machine locale, vous devez ensuite vous y connecter. Vous pouvez le faire grâce à la ligne de commande suivante :

docker login -u your_docker_hub_username

Saisissez vos identifiants de connexion lorsque vous serez invité à le faire. Il est généralement nécessaire de le faire qu’une seule fois par machine. En effet, Docker enregistrera vos identifiants dans ~/.docker/config.json dans votre répertoire personnel.

Enfin, poussez votre image dans Docker Hub :

docker push your_docker_hub_username/laravel-kubernetes:latest

En fonction de la vitesse de votre connexion, le téléchargement de votre application peut prendre quelques minutes. Cependant, une fois Docker terminé, vous verrez un hachage cryptographique et la taille de votre image dans le terminal. Elle ressemblera à cela :

Outputlatest: digest: sha256:df4bdeda91484c8c26a989b13b8f27ab14d93ab2e676e3c396714cb3811c4086 size: 4918

Maintenant que votre application Laravel est conteneurisée et que vous avez poussé une image dans Docker Hub, vous pouvez utiliser l’image dans un déploiement de chart Helm ou Kubernetes. Au cours de la prochaine étape, vous allez configurer des valeurs personnalisées en fonction du chart LAMP Helm et le déployer dans votre cluster DigitalOcean Kubernetes.

`Étape 4 — Configuration et déploiement de l’application avec chart LAMP Helm`

Helm propose un certain nombre de Charts pour vous aider à configurer des applications Kubernetes en utilisant des combinaisons d’outils prédéfinies. Même si vous pouvez écrire vos propres fichiers de service Kubernetes pour effectuer un déploiement similaire, dans cette section vous verrez que l’utilisation d’un chart Helm nécessite beaucoup moins de configuration.

Tout d’abord, vous aurez besoin d’un répertoire pour y stocker tous vos fichiers de configuration Helm. Créez un nouveau répertoire dans la racine de votre projet Laravel que vous nommerez helm/ :

Dans le répertoire helm/, vous allez créer deux nouveaux fichiers : values.yml et secrets.yml. Commencez par créer et ouvrir values.yml :

Le fichier values.yml comprendra des options de configuration non secrètes qui remplaceront les valeurs par défaut dans le chart LAMP Helm. Ajoutez les configurations suivantes, tout en veillant bien à remplacer your_docker_hub_username par votre nom d’utilisateur :

./helm/values.yml

php:
  repository: "your_docker_hub_username/laravel-kubernetes"
  tag: "latest"
  fpmEnabled: false
  envVars:
    - name: APP_ENV
      value: production
    - name: APP_DEBUG
      value: false
    - name: DB_PORT
      value: 3306
    - name: DB_HOST
      value: localhost

Enregistrez et fermez le fichier.

Maintenant, créez un fichier secrets.yml :

secrets.yml ne sera pas archivé dans le contrôle de version. Il contiendra des informations de configuration sensibles comme votre mot de passe et votre clé d’app Laravel. Ajoutez les configurations suivantes, en les ajustant au besoin pour qu’elles soient adaptées à vos identifiants :

./helm/secrets.yml

mysql:
  rootPassword: "your_database_root_password"
  user: your_database_user
  password: "your_database_password"
  database: your_database_name

php:
  envVars:
    - name: APP_KEY
      value: "your_laravel_app_key"
    - name: DB_DATABASE
      value: your_database_name
    - name: DB_USERNAME
      value: your_database_user
    - name: DB_PASSWORD
      value: "your_database_password"

Veillez à utiliser des combinaisons de noms d’utilisateur et de mot de passe difficiles à trouver pour votre base de données de production. Utilisez la même your_laravel_app_key que celle indiquée ci-dessus. Sinon, ouvrez une nouvelle fenêtre et générez un nouveau fichier en exécutant la commande suivante. Vous pouvez ensuite copier la nouvelle valeur configurée par Laravel dans votre fichier .env :

docker run --rm -v $(pwd):/app php:cli php /app/artisan key:generate

Sauvegardez et fermez secrets.yml.

Ensuite, afin d’empêcher votre fichier secrets.yml d’être intégré à l’image Docker ou d’être sauvegardé dans le contrôle de version, veillez à bien ajouter la ligne suivante à la fois dans vos fichiers .dockerignore et .gitignore. Ouvrez et ajoutez /helm/secrets.yml dans chaque fichier, ou exécutez la commande suivante pour ajouter les deux :

echo '/helm/secrets.yml' >> ./.dockerignore && echo '/helm/secrets.yml' >> ./.gitignore

Maintenant que vous avez créé les fichiers de configuration Helm pour votre application et l’image Docker, vous pouvez installer ce chart Helm comme une nouvelle version dans votre cluster Kubernetes. Installez votre chart dans le répertoire racine de votre application :

helm install laravel-kubernetes -f helm/values.yml -f helm/secrets.yml stable/lamp

Vous verrez un résultat similaire à ce qui suit :

OutputNAME: laravel-kubernetes
LAST DEPLOYED: Mon May 18 13:21:20 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1

Il faudra une à deux minutes pour que votre application soit disponible. Cependant, vous pouvez exécuter cette commande pour surveiller les services Kubernetes dans votre cluster :

Recherchez le nom de votre application :

OutputNAME                        TYPE            CLUSTER-IP          EXTERNAL-IP     PORT(S)
laravel-kubernetes-lamp     LoadBalancer    your_cluster_ip      your_external_ip   80:32175/TCP,3306:32243/TCP

Lorsque votre nouveau service laravel-kubernetes-lamp affiche une adresse IP sous EXTERNAL-IP, vous pouvez consulter your_external_ip pour voir l’application qui est exécutée dans votre cluster Kubernetes. Votre application se connectera à votre base de données. Vous verrez alors le nom de la base de données apparaître sous le logo Laravel, comme ce fut le cas lors de l’exécution locale de votre application dans Docker Compose.

L’exécution d’une application web sur une adresse IP non sécurisée est adaptée pour une démonstration de faisabilité. Cependant, votre site web n’est pas prêt à être publié sans certificat SSL et un nom de domaine personnalisé. Avant que vous configuriez cela à l’étape suivante, désinstallez votre version via la ligne de commande suivante :

helm delete laravel-kubernetes

Au cours de la prochaine étape, vous allez étendre cette première configuration Helm pour ajouter un contrôleur Ingress, un certificat SSL et un domaine personnalisé à votre application Laravel.

`Étape 5 — Ajout d’un contrôleur Ingress et SSL à votre cluster Kubernetes`

Dans Kubernetes, un contrôleur Ingress est chargé d’exposer les services de votre application sur Internet. À l’étape précédente, le chart LAMP Helm a créé un équilibreur de charge DigitalOcean et a exposé votre application directement via l’adresse IP de l’équilibreur de charge.

Vous pourriez résilier SSL et votre nom de domaine directement sur l’équilibreur de charge. Cependant, étant donné que vous travaillez dans Kubernetes, il serait plus pratique de gérer celà au même endroit. Pour plus d’informations sur les contrôleurs Ingress et des détails sur les étapes suivantes, consultez Comment configurer un Ingress Nginx sur DigitalOcean Kubernetes en utilisant Helm.

Le chart LAMP Helm intègre une option de configuration pour prendre en charge Ingress. Ouvrez votre fichier helm/values.yml :

Maintenant, ajoutez les lignes suivantes :

./helm/values.yml

...
# Use Ingress Controller
service:
  type: ClusterIP
  HTTPPort: 80
ingress:
  enabled: true
  domain: your_domain

Cela indique à votre déploiement de ne pas installer d’équilibreur de charge et d’exposer l’application dans le port 80 du cluster Kubernetes où le contrôleur Ingress l’exposera sur Internet. Sauvegardez et fermez values.yml.

Maintenant, exécutez la commande helm install que vous avez exécutée précédemment pour que votre application Laravel s’exécute à nouveau. Veillez à exécuter la commande à partir du répertoire racine de votre application :

helm install laravel-kubernetes -f helm/values.yml -f helm/secrets.yml stable/lamp

Ensuite, installez le contrôleur nginx-ingress sur votre cluster Kubernetes en utilisant le contrôleur Nginx Ingress maintenu sous Kubernetes :

helm install nginx-ingress stable/nginx-ingress --set controller.publishService.enabled=true

Après l’installation, vous aurez un résultat similaire à ce qui suit :

OutputNAME: nginx-ingress
LAST DEPLOYED: Mon May 18 13:28:34 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1

Vous avez également besoin d’une Ressource Ingress pour exposer le déploiement de votre application Laravel. Créez un nouveau fichier dans le répertoire racine de votre application que vous nommerez ingress.yml :

Ce fichier définit l’hôte de votre application, le gestionnaire de certificat SSL, le service de backend et le nom de port de votre application. Ajoutez les configurations suivantes en remplacant your_domain avec le domaine de votre choix :

./ingress.yml

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: laravel-kubernetes-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - your_domain
      secretName: laravel-kubernetes-tls
  rules:
    - host: your_domain
      http:
        paths:
          - backend:
              serviceName: laravel-kubernetes-lamp
              servicePort: 80

Enregistrez et fermez le fichier.

Ensuite, vous deviez installer Cert-Manager et créer un émetteur qui vous permettra de créer des certificats SSL de production en utilisant Let’s Encrypt. Cert-Manager nécessite des Custom Resource Definitions que vous pouvez appliquer à partir du Cert-Manager repository en utilisant la ligne de commande suivante :

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.crds.yaml

Cela créera un certain nombre de ressources Kubernetes qui s’afficheront dans la ligne de commande :

Outputcustomresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io create

Cert-Manager a également besoin d’un namespace pour l’isoler dans votre cluster Kubernetes :

kubectl create namespace cert-manager

Vous verrez ce résultat :

Outputnamespace/cert-manager created

Étant donné que le Cert-Manager de Jetstack ne fait pas partie des charts maintenus par Kubernetes, vous aurez également besoin d’ajouter le référentiel Helm Jetstack. Exécutez la commande suivante pour le rendre disponible dans Helm :

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

Si l’ajout est correctement effectué, vous obtiendrez le résultat suivant :

Output"jetstack" has been added to your repositories

Maintenant, vous êtes prêt à installer Cert-Manager dans l’espace de nommage cert-manager de votre cluster Kubernetes :

helm install cert-manager --version v0.15.0 --namespace cert-manager jetstack/cert-manager

Une fois terminé, vous verrez apparaître un résumé du déploiement similaire à ce qui suit :

OutputNAME: cert-manager
LAST DEPLOYED: Mon May 18 13:32:08 2020
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1

Le dernier fichier que vous devez ajouter dans le répertoire racine de votre application Laravel est un fichier de configuration de Kubernetes production_issuer.yml. Créez le fichier :

nano ./production_issuer.yml

Maintenant, ajoutez ce qui suit :

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # Email address used for ACME registration
    email: your_email_address
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Name of a secret used to store the ACME account private key
      name: letsencrypt-prod-private-key
    # Add a single challenge solver, HTTP01 using nginx
    solvers:
      - http01:
          ingress:
            class: nginx

Enregistrez et fermez le fichier.

Let’s Encrypt enverra toutes les notifications importantes et tous les avertissements d’expiration à your_email_address. Veillez donc à bien ajouter une adresse que vous consultez régulièrement. Sauvegardez ce fichier et créez une nouvelle ressource à la fois pour votre ressource Ingress et votre émetteur de production dans votre cluster Kubernetes :

kubectl create -f ingress.yml
kubectl create -f production_issuer.yml

Enfin, mettez à jour les enregistrements DNS de votre nom de domaine pour qu’un enregistrement A pointe vers l’adresse IP de votre équilibreur de charge. Pour trouver l’adresse IP de votre contrôleur Ingress, saisissez ce qui suit :

kubectl get service nginx-ingress-controller

OutputNAME                       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
nginx-ingress-controller   LoadBalancer   your_cluster_ip      your_external_ip   80:30187/TCP,443:31468/TCP   6m10s

Utilisez l’adresse your_external_ip comme adresse IP de votre Enregistrement A de DNS. Le processus de mise à jour de vos enregistrements DNS varie en fonction de l’endroit où vous gérez vos noms de domaine et l’hébergement DNS. Cependant, si vous utilisez DigitalOcean, vous pouvez consulter notre guide Comment gérer vos enregistrements DNS.

Une fois que vos enregistrements DNS sont mis à jour et votre certificat SSL est configuré, votre application sera disponible sur your_domain et SSL sera activée.

Même si votre application et votre base de données PHP sont déjà connectées, vous aurez encore besoin de migrer la base de données. Au cours de la dernière étape, vous verrez comment exécuter des Artisan commands sur votre pod Kubernetes pour migrer la base de données et effectuer d’autres tâches de maintenance communes.

`Étape 6 — Exécution de commandes à distance`

Même si votre application Laravel fonctionne et est connectée à la base de données MySQL dans Kubernetes, vous aurez besoin d’effectuer plusieurs opérations communes sur une nouvelle installation Laravel. Une de ces tâches communes est la migration de base de données.

Avant que vous puissiez exécuter une commande Artisan sur votre application Laravel, vous devez connaître le nom du pod qui exécute votre conteneur d’application Laravel. En utilisant la ligne de commande suivante, vous pouvez consulter tous les pods de votre cluster Kubernetes :

Vous verrez un résultat similaire à ce qui suit :

OutputNAME                                             READY   STATUS    RESTARTS   AGE
laravel-kubernetes-lamp-77fb989b46-wczgb         2/2     Running   0          16m

Sélectionnez le pod pour votre déploiement laravel-kubernetes-lamp-... Veillez à bien utiliser le nom dans votre résultat et non celui mentionné ci-dessus. Maintenant, vous pouvez y exécuter kubectl exec. Par exemple, exécutez une migration de base de données en utilisant la commande artisan migrate. Vous allez ajouter la balise --force car vous exécutez le pod en production :

kubectl exec laravel-kubernetes-lamp-77fb989b46-wczgb -- php artisan migrate --force

Cette commande générera un résultat :

OutputMigration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.16 seconds)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (0.05 seconds)

Vous avez maintenant déployé correctement Laravel 7 et MySQL dans Kubernetes et exécuté une tâche essentielle de maintenance de la base de données.

`Conclusion`

Dans ce tutoriel, vous avez appris à conteneuriser une application PHP Laravel, à la connecter à une base de données MySQL, à pousser une image Docker contenant votre code sur Docker Hub, puis à utiliser un chart Helm pour la déployer sur un cluster DigitalOcean Kubernetes. Enfin, vous avez ajouté un SSL et un nom de domaine personnalisé et appris à exécuter des outils de ligne de commande sur vos pods en cours d’exécution.

Par rapport à l’hébergement traditionnel de pile LAMP, Kubernetes et Helm vous offrent un certain nombre d’avantages : extensibilité, échange de services sans connexion directe à votre serveur, outils de mises à jour en roulement et contrôle de votre environnement d’hébergement. Cela dit, la complexité initiale de la conteneurisation et de la configuration rendent le démarrage de votre application assez difficile. En utilisant ce guide comme point de départ, il est plus facile de déployer Laravel sur Kubernetes. À partir de là, vous pourriez envisager d’en apprendre plus sur la puissance de Laravel ou sur l’ajout d’outils de surveillance à Kubernetes (Linkerd, par exemple), que vous pouvez installer manuellement avec notre guide ou avec un DigitalOcean 1-Click.

Source link

Shared

Cloud VPS

Dedicated

déployer

Comment déployer une application Django flexible et sécurisée avec Kubernetes

Introduction

Conditions préalables

Étape 1 — Cloner et configurer l’application

Étape 2 - Création du schéma de la base de données et chargement d'actifs dans le stockage d'objets

Étape 3 - Pousser l'image de l'application Django sur Docker Hub

Étape 4 - Configuration de ConfigMap

Étape 5 - Configuration du secret

Étape 6 - Déploiement de l'application Django avec un Déployment

Étape 7 - Autoriser un accès externe à l'aide d'un Service

Étape 8 - Configuration du HTTPS en utilisant Nginx Ingress et cert-manager

Conclusion

Comment déployer Laravel 7 et MySQL sur Kubernetes en utilisant Helm

Introduction

Conditions préalables

Étape 1 — Création d’une nouvelle application Laravel

Étape 2 — Conteneurisation de votre application Laravel

Étape 3 — Poussez votre image Docker dans Docker Hub

Étape 4 — Configuration et déploiement de l’application avec chart LAMP Helm

Étape 5 — Ajout d’un contrôleur Ingress et SSL à votre cluster Kubernetes

Étape 6 — Exécution de commandes à distance

Conclusion

`Étape 2 - Création du schéma de la base de données et chargement d'actifs dans le stockage d'objets`

`Étape 3 - Pousser l'image de l'application Django sur Docker Hub`

`Étape 4 - Configuration de ConfigMap`

`Étape 5 - Configuration du secret`

`Étape 6 - Déploiement de l'application Django avec un Déployment`

`Étape 7 - Autoriser un accès externe à l'aide d'un Service`

`Étape 8 - Configuration du HTTPS en utilisant Nginx Ingress et cert-manager`

`Conclusion`

`Comment déployer Laravel 7 et MySQL sur Kubernetes en utilisant Helm`

`Introduction`

`Conditions préalables`

`Étape 1 — Création d’une nouvelle application Laravel`

`Étape 2 — Conteneurisation de votre application Laravel`

`Étape 3 — Poussez votre image Docker dans Docker Hub`

`Étape 4 — Configuration et déploiement de l’application avec chart LAMP Helm`

`Étape 5 — Ajout d’un contrôleur Ingress et SSL à votre cluster Kubernetes`

`Étape 6 — Exécution de commandes à distance`

`Conclusion`