One place for hosting & domains

      Kubernetes

      How To Use Telepresence on Kubernetes for Rapid Development on MacOS


      The author selected the Tech Education Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Application developers building microservices on Kubernetes often encounter two major problems that slow them down:

      • Slow feedback loops. Once a code change is made, it must be deployed to Kubernetes to be tested. This requires a container build, push to a container registry, and deployment to Kubernetes. This adds minutes to every code iteration.
      • Insufficient memory and CPU locally. Developers attempt to speed up the feedback loop by running Kubernetes locally with minikube or the equivalent. However, resource-hungry applications quickly exceed the compute and memory available locally.

      Telepresence is a Cloud-Native Computing Foundation project for fast, efficient development on Kubernetes. With Telepresence, you run your service locally, while you run the rest of your application in the cloud. Telepresence creates a bi-directional network connection between your Kubernetes cluster and your local workstation. This way, the service you’re running locally can communicate with services in the cluster, and vice versa. That allows you to use the compute and memory resources of the cluster, but without having to go through a complete deployment cycle for each change.

      In this tutorial, you’ll configure Telepresence on your local machine running MacOS to work with a Kubernetes cluster. You’ll intercept traffic to your cluster and redirect it to your local environment.

      To complete this tutorial, you will need:

      Step 1 — Installing Telepresence

      In this step, you’ll install Telepresence and connect it to your Kubernetes cluster. First, make sure that you have kubectl configured and that you can connect to your Kubernetes cluster from your local workstation. Use the get services command to check your cluster’s status:

      The output will look like this, with your own cluster’s IP address listed:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 116m

      Next you’ll install Telepresence locally. Telepresence comes as a single binary.

      Use curl to download the latest binary for MacOS (around 60 MB):

      • sudo curl -fL https://app.getambassador.io/download/tel2/darwin/amd64/latest/telepresence -o /usr/local/bin/telepresence

      Then use chmod to make the binary executable:

      • sudo chmod a+x /usr/local/bin/telepresence

      Now that you have Telepresence installed locally, you can verify that it worked by connecting to your Kubernetes cluster:

      You’ll see the following output:

      Output

      Launching Telepresence Daemon v2.2.0 (api v3) Connecting to traffic manager... Connected to context default (https://<cluster public URL)

      If Telepresence doesn’t connect, check your kubectl configuration.

      Verify that Telepresence is working properly by connecting to the Kubernetes API server with the status command:

      You will see the following output. Telepresence Proxy: ON indicates that Telepresence has configured a proxy to access services on the cluster.

      Output

      Root Daemon: Running Version : v2.2.0 (api 3) Primary DNS : "" Fallback DNS: "" User Daemon: Running Version : v2.2.0 (api 3) Ambassador Cloud : Logged out Status : Connected Kubernetes server : https://e5488ea3-6455-4fc7-be25-09d1d90bde82.k8s.ondigitalocean.com Kubernetes context: your_kubernetes_context Telepresence proxy: ON (networking to the cluster is enabled) Intercepts : 0 total

      When you use telepresence connect, on the server side, Telepresence creates a namespace called ambassador and runs a traffic manager. On the client side, Telepresence sets up DNS to enable local access to remote servers. That means you do not have to use kubectl port-forward to manually configure access to local services. When you access a remote service the DNS resolves to a specific IP address. For more details, see the Telepresence architecture documentation.

      You can now connect to the remote Kubernetes cluster from your local workstation, as if the Kubernetes cluster were running on your laptop. Next you’ll try out a sample application.

      Step 2 — Adding a Sample Node.js Application

      In this step, you’ll use a simple Node.js application to simulate a complex service running on your Kubernetes cluster. Instead of creating the file locally, you’ll access it from DockerHub and deploy it to your cluster from there. The file is called hello-node, and returns a text string:

      var http = require('http');
      
      var handleRequest = function(request, response) {
        console.log('Received request for URL: ' + request.url);
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello, Node!');
        response.end();
      };
      
      http.createServer(handleRequest).listen(9001);
      console.log('Use curl <hostname>:9001 to access this server...');
      

      Use the kubectl create deployment command to create a deployment called hello node:

      • kubectl create deployment hello-node --image=docommunity/hello-node:1.0

      You will see the following output:

      Output

      deployment.apps/hello-node created

      Use the get pod command to confirm that the deployment has occurred and the app is now running on the cluster:

      The output will show a READY status of 1/1.

      Output

      NAME READY STATUS RESTARTS AGE hello-node-86b49779bf-9zqvn 1/1 Running 0 11s

      Use the expose deployment command to make the application available on port 9001:

      • kubectl expose deployment hello-node --type=LoadBalancer --port=9001

      The output will look like this:

      Output

      service/hello-node exposed

      Use the kubectl get svc command to check that the load balancer is running:

      The output will look like this, with your own IP addresses:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.245.75.48 <pending> 9001:30682/TCP 4s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 6d

      If you are using local Kubernetes without load balancer support, then the external IP value for LoadBalancer will show as <pending> permanently. That is fine for the purposes of this tutorial. If you are using DigitalOcean Kubernetes, you should see the external IP value will display the IP address after a delay.

      Next, verify that the application is running by using curl to access the load balancer:

      If you’re not running a load balancer, you can use curl to access the service directly:

      • curl <servicename>.<namespace>:9001

      The output will look like this:

      Output

      Hello, Node!

      Next, use the telepresence connect command to connect Telepresence to the cluster:

      This allows you to access all remote services as if they were local, so you can access the service by name:

      • curl hello-node.default:9001

      You’ll receive the same response as you did when you accessed the service via its IP:

      Output

      Hello, Node!

      The service is up and running on the cluster, and you can access it remotely. If you make any changes to the hello-node.js app, you’d need to take the following steps:

      • Modify the app.
      • Rebuild the container image.
      • Push it to a container registry.
      • Deploy to Kubernetes.

      That is a lot of steps. You could use tooling (automated pipelines, such as Skaffold) to reduce the manual work. But the steps themselves cannot be bypassed.

      Now you’ll build another version of our hello-node app, and use Telepresence to test it without having to build the container image or push it to registry or even deploy to Kubernetes.

      Step 3 — Running a New Version of the Service Locally

      In this step, you’ll modify the existing hello-node application on your local machine. You’ll then use Telepresence to route traffic to the local version with a Telepresence intercept. The intercept takes traffic intended for your cluster and reroutes it to your local version of the service, so you can continue working in your development environment.

      Create a new file containing a modified version of the sample application:

      Add the following code to the new file:

      hello-node-v2.js

      var http = require('http');
      
      var handleRequest = function(request, response) {
        console.log('Received request for URL: ' + request.url);
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello, Node V2!');
        response.end();
      };
      
      http.createServer(handleRequest).listen(9001);
      

      Save and exit the file.

      Start the service with Node:

      Leave the service running, then open a new terminal window and access the service:

      The output will look like this:

      Output

      Hello, Node V2!

      This service is only running locally, however. If you try to access the remote server, it is currently running version 1 of hello-node. To fix that, you’ll enable an intercept to route all traffic going to the hello-node service in the cluster to the local version of the service.

      Use the intercept command to set up the intercept:

      • telepresence intercept hello-node --port 9001

      The output will look like this:

      Output

      Using deployment hello-node intercepted Intercept name : hello-node State : ACTIVE Destination : 127.0.0.1:9001 Volume Mount Error: sshfs is not installed on your local machine Intercepting : all TCP connections

      Check that the intercept has been set up correctly with the status command:

      The output will look like this:

      Output

      Root Daemon: Running Version : v2.2.0 (api 3) Primary DNS : "" Fallback DNS: "" User Daemon: Running Version : v2.2.0 (api 3) Ambassador Cloud : Logged out Status : Connected Kubernetes server : https://e5488ea3-6455-4fc7-be25-09d1d90bde82.k8s.ondigitalocean.com Kubernetes context: <your_kubernetes_context> Telepresence proxy: ON (networking to the cluster is enabled) Intercepts : 1 total hello-node: user@context

      Now access the remote service with curl as you did previously:

      The output will look like this:

      Output

      Hello, Node V2!

      Now, any messages sent to the service on the cluster are redirected to the local service. This is useful in the development stage, because you can avoid the deployment loop (build, push, deploy) for every individual change to your code.

      Conclusion

      In this tutorial, you’ve installed Telepresence on your local machine, and demonstrated how to make code changes in your local environment without having to deploy to Kubernetes every time you make a change. For more tutorials and information about Telepresence, see the Telepresence documentation.



      Source link

      How To Use Telepresence on Kubernetes for Rapid Development on Ubuntu 20.04


      The author selected the Tech Education Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Application developers building microservices on Kubernetes often encounter two major problems that slow them down:

      • Slow feedback loops. Once a code change is made, it must be deployed to Kubernetes to be tested. This requires a container build, push to a container registry, and deployment to Kubernetes. This adds minutes to every code iteration.
      • Insufficient memory and CPU locally. Developers attempt to speed up the feedback loop by running Kubernetes locally with minikube or the equivalent. However, resource-hungry applications quickly exceed the compute and memory available locally.

      Telepresence is a Cloud-Native Computing Foundation project for fast, efficient development on Kubernetes. With Telepresence, you run your service locally, while you run the rest of your application in the cloud. Telepresence creates a bi-directional network connection between your Kubernetes cluster and your local workstation. This way, the service you’re running locally can communicate with services in the cluster, and vice versa. That allows you to use the compute and memory resources of the cluster, but without having to go through a complete deployment cycle for each change.

      In this tutorial, you’ll configure Telepresence on your local machine running Ubuntu 20.04 to work with a Kubernetes cluster. You’ll intercept traffic to your cluster and redirect it to your local environment.

      To complete this tutorial, you will need:

      Step 1 — Installing Telepresence

      In this step, you’ll install Telepresence and connect it to your Kubernetes cluster. First, make sure that you have kubectl configured and that you can connect to your Kubernetes cluster from your local workstation. Use the get services command to check your cluster’s status:

      The output will look like this, with your own cluster’s IP address listed:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 116m

      Next you’ll install Telepresence locally. Telepresence comes as a single binary.

      Use curl to download the latest binary for Linux (around 50 MB):

      • sudo curl -fL https://app.getambassador.io/download/tel2/linux/amd64/latest/telepresence -o /usr/local/bin/telepresence

      Then use chmod to make the binary executable:

      • sudo chmod a+x /usr/local/bin/telepresence

      Now that you have Telepresence installed locally, you can verify that it worked by connecting to your Kubernetes cluster:

      You’ll see the following output:

      Output

      Launching Telepresence Daemon ... Connected to context default (https://<cluster public IP>)

      If Telepresence doesn’t connect, check your kubectl configuration.

      Verify that Telepresence is working properly by connecting to the Kubernetes API server with the status command:

      You will see the following output. Telepresence Proxy: ON indicates that Telepresence has configured a proxy to access services on the cluster.

      Output

      Root Daemon: Running Version : v2.1.4 (api 3) Primary DNS : "" Fallback DNS: "" User Daemon: Running Version : v2.1.4 (api 3) Ambassador Cloud : Logged out Status : Connected Kubernetes server : https://7c10e553-10d1-4fee-9b7d-1ccbce4cdd34.k8s.ondigitalocean.com Kubernetes context: <your_kubernetes_context> Telepresence proxy: ON (networking to the cluster is enabled) Intercepts : 0 total Connected Context: do-tor1-k8s-bg-telepresence (https://bee66877-1b07-4bb1-8c8f-4fd62e416865.k8s.ondigitalocean.com) Proxy: ON (networking to the cluster is enabled) Intercepts: 0 total

      When you use telepresence connect, on the server side, Telepresence creates a namespace called ambassador and runs a traffic manager. On the client side, Telepresence sets up DNS to enable local access to remote servers. That means you do not have to use kubectl port-forward to manually configure access to local services. When you access a remote service the DNS resolves to a specific IP address. For more details, see the Telepresence architecture documentation.

      You can now connect to the remote Kubernetes cluster from your local workstation, as if the Kubernetes cluster were running on your laptop. Next you’ll try out a sample application.

      Step 2 — Adding a Sample Node.js Application

      In this step, you’ll use a simple Node.js application to simulate a complex service running on your Kubernetes cluster. Instead of creating the file locally, you’ll access it from DockerHub and deploy it to your cluster from there. The file is called hello-node, and returns a text string:

      var http = require('http');
      
      var handleRequest = function(request, response) {
        console.log('Received request for URL: ' + request.url);
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello, Node!');
        response.end();
      };
      
      http.createServer(handleRequest).listen(9001);
      console.log('Use curl <hostname>:9001 to access this server...');
      

      Use the kubectl create deployment command to create a deployment called hello node:

      • kubectl create deployment hello-node --image=docommunity/hello-node:1.0

      You will see the following output:

      Output

      deployment.apps/hello-node created

      Use the get pod command to confirm that the deployment has occurred and the app is now running on the cluster:

      The output will show a READY status of 1/1.

      Output

      NAME READY STATUS RESTARTS AGE hello-node-86b49779bf-9zqvn 1/1 Running 0 11s

      Use the expose deployment command to make the application available on port 9001:

      • kubectl expose deployment hello-node --type=LoadBalancer --port=9001

      The output will look like this:

      Output

      service/hello-node exposed

      Use the kubectl get svc command to check that the load balancer is running:

      The output will look like this, with your own IP addresses:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.245.75.48 <pending> 9001:30682/TCP 4s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 6d

      If you are using local Kubernetes without load balancer support, then the external IP value for LoadBalancer will show as <pending> permanently. That is fine for the purposes of this tutorial. If you are using DigitalOcean Kubernetes, you should see the external IP value will display the IP address after a delay.

      Next, verify that the application is running by using curl to access the load balancer:

      If you’re not running a load balancer, you can use curl to access the service directly:

      • curl <servicename>.<namespace>:9001

      The output will look like this:

      Output

      Hello, Node!

      Next, use the telepresence connect command to connect Telepresence to the cluster:

      This allows you to access all remote services as if they were local, so you can access the service by name:

      • curl hello-node.default:9001

      You’ll receive the same response as you did when you accessed the service via its IP:

      Output

      Hello, Node!

      The service is up and running on the cluster, and you can access it remotely. If you make any changes to the hello-node.js app, you’d need to take the following steps:

      • Modify the app.
      • Rebuild the container image.
      • Push it to a container registry.
      • Deploy to Kubernetes.

      That is a lot of steps. You could use tooling (automated pipelines, such as Skaffold) to reduce the manual work. But the steps themselves cannot be bypassed.

      Now you’ll build another version of our hello-node app, and use Telepresence to test it without having to build the container image or push it to registry or even deploy to Kubernetes.

      Step 3 — Running a New Version of the Service Locally

      In this step, you’ll modify the existing hello-node application on your local machine. You’ll then use Telepresence to route traffic to the local version with a Telepresence intercept. The intercept takes traffic intended for your cluster and reroutes it to your local version of the service, so you can continue working in your development environment.

      Create a new file containing a modified version of the sample application:

      Add the following code to the new file:

      hello-node-v2.js

      var http = require('http');
      
      var handleRequest = function(request, response) {
        console.log('Received request for URL: ' + request.url);
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello, Node V2!');
        response.end();
      };
      
      http.createServer(handleRequest).listen(9001);
      

      Save and exit the file.

      Start the service with Node:

      Leave the service running, then open a new terminal window and access the service:

      The output will look like this:

      Output

      Hello, Node V2!

      This service is only running locally, however. If you try to access the remote server, it is currently running version 1 of hello-node. To fix that, you’ll enable an intercept to route all traffic going to the hello-node service in the cluster to the local version of the service.

      Use the intercept command to set up the intercept:

      • telepresence intercept hello-node --port 9001

      The output will look like this:

      Output

      Using deployment hello-node intercepted Intercept name : hello-node State : ACTIVE Destination : 127.0.0.1:9001 Volume Mount Error: sshfs is not installed on your local machine Intercepting : all TCP connections

      Check that the intercept has been set up correctly with the status command:

      The output will look like this:

      Output

      Root Daemon: Running Version : v2.1.4 (api 3) Primary DNS : "" Fallback DNS: "" User Daemon: Running Version : v2.1.4 (api 3) Ambassador Cloud : Logged out Status : Connected Kubernetes server : https://7c10e553-10d1-4fee-9b7d-1ccbce4cdd34.k8s.ondigitalocean.com Kubernetes context: <your_kubernetes_context> Telepresence proxy: ON (networking to the cluster is enabled) Intercepts : 1 total hello-node: brian@telepresence-tutorial

      Now access the remote service with curl as you did previously:

      The output will look like this:

      Output

      Hello, Node V2!

      Now, any messages sent to the service on the cluster are redirected to the local service. This is useful in the development stage, because you can avoid the deployment loop (build, push, deploy) for every individual change to your code.

      Conclusion

      In this tutorial, you’ve installed Telepresence on your local machine, and demonstrated how to make code changes in your local environment without having to deploy to Kubernetes every time you make a change. For more tutorials and information about Telepresence, see the Telepresence documentation.



      Source link

      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 :

      Output

      FROM 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 :

      Output

      No 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.

      Output

      121 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 :

      Interface des applications de sondage

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

      Page Auth admin des sondages

      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 :

      Interface principale de l'administration de sondages

      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 :

      Output

      Login 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

      Output

      configmap/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

      Output

      secret/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

      Output

      Name: 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

      Output

      NAME 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 :

      Output

      NAME 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

      Output

      service/polls created

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

      Output

      NAME 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 :

      Output

      NAME 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 :

      Interface des applications de sondage

      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 :

      Page Auth admin des sondages

      À 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

      Output

      ingress.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

      Output

      Name: 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

      Output

      ingress.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 :

      Interface des applications 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

      Output

      service/polls configured

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

      Output

      NAME 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