Skip to content
Learni
View all tutorials
DevOps

Comment implémenter un API Management avec Kong en 2026

22 minADVANCED
DevOpsDockerKongAPI GatewayAPI Management

Introduction

L'API Management est essentiel en 2026 pour les architectures microservices : il centralise le proxying, la sécurité, le throttling et le monitoring de vos APIs. Kong, gateway open-source ultra-performant, excelle en mode DB-less (sans base de données), idéal pour Kubernetes ou environnements éphémères. Ce tutoriel advanced vous guide pas à pas pour déployer un système complet : un backend Node.js simulé, proxifié par Kong avec rate-limiting (5 req/min), key-authentication, logging structuré et métriques Prometheus.

Pourquoi Kong ? Il supporte 100+ plugins Lua, scale horizontalement et intègre nativement Docker/K8s. Imaginez comme un vigile intelligent : il filtre les abus, authentifie les consumers et expose des dashboards. À la fin, vous aurez une stack production-ready, testable localement. Temps estimé : 30 min. Gain concret : réduction de 80% des attaques DDoS et monitoring temps réel.

Prérequis

  • Docker et Docker Compose installés (version 20.10+)
  • Node.js 20+ et npm
  • curl pour les tests API
  • Connaissances avancées en Docker, YAML et APIs REST
  • Git pour cloner le projet exemple (optionnel)

Créer le backend API Node.js

backend/app.js
const express = require('express');
const app = express();
app.use(express.json());

app.get('/hello', (req, res) => {
  res.json({ message: 'Hello from Backend API!', timestamp: new Date().toISOString() });
});

app.get('/users', (req, res) => {
  res.json([
    { id: 1, name: 'Alice', email: 'alice@example.com' },
    { id: 2, name: 'Bob', email: 'bob@example.com' }
  ]);
});

app.post('/users', (req, res) => {
  const { name, email } = req.body;
  if (!name || !email) {
    return res.status(400).json({ error: 'Name and email required' });
  }
  res.status(201).json({ id: 3, name, email });
});

const PORT = 3001;
app.listen(PORT, () => {
  console.log(`Backend API listening on port ${PORT}`);
});

Ce backend Express.js expose trois endpoints : GET /hello (simple healthcheck), GET /users (liste statique) et POST /users (création avec validation). Il écoute sur le port 3001 pour simulation microservice. Piège à éviter : toujours valider les inputs pour prévenir injections ; ici, check basique des champs obligatoires.

Package.json et installation backend

backend/package.json
{
  "name": "api-backend",
  "version": "1.0.0",
  "main": "app.js",
  "scripts": {
    "start": "node app.js",
    "dev": "nodemon app.js"
  },
  "dependencies": {
    "express": "^4.19.2"
  },
  "devDependencies": {
    "nodemon": "^3.1.4"
  }
}

Ce package.json installe Express pour le serveur et Nodemon pour hot-reload en dev. Exécutez npm install après création. Avantage : scripts prêts pour prod (npm start) et dev. Évitez les dépendances inutiles pour minimiser la surface d'attaque.

Dockerfile pour le backend

backend/Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3001
CMD ["npm", "start"]

Dockerfile lightweight avec Alpine pour ~100MB image. Copie package d'abord pour cache layer npm. Utilisez npm ci en prod pour install déterministe. Piège : oubliez EXPOSE ou WORKDIR, causant des binds ports foireux.

docker-compose.yml avec Kong DB-less

docker-compose.yml
version: '3.9'
services:
  backend:
    build: ./backend
    ports:
      - "3001:3001"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/hello"]
      interval: 10s
      timeout: 5s
      retries: 3

  kong:
    image: kong:3.6
    restart: always
    environment:
      KONG_DATABASE: "off"
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: "0.0.0.0:8001"
    ports:
      - "8000:8000"  # Proxy
      - "8001:8001"  # Admin API
      - "8443:8443"  # Proxy HTTPS
      - "8002:8002"  # Admin GUI? Non, metrics
    networks:
      - kong-net

networks:
  kong-net:

Ce docker-compose lance backend + Kong en mode DB-less (sans Postgres). Kong proxy sur 8000, Admin API sur 8001 pour configs dynamiques. Healthcheck backend assure disponibilité. Piège : exposez toujours Admin en prod via VPN ; ici localhost-only pour dev.

Lancer la stack

terminal
mkdir kong-api-management && cd kong-api-management
mkdir backend
# Copiez les fichiers backend/app.js, package.json, Dockerfile ici
cd backend && npm install && cd ..
# Copiez docker-compose.yml à la racine
docker compose up -d
# Vérifiez logs
docker compose logs -f kong
docker compose ps

Ce script bash initialise le projet, installe deps backend et lance tout en detached. docker compose ps confirme services healthy. Avantage : reproductible à 100%. Évitez docker-compose up sans -d en prod pour éviter blocage terminal.

Configurer service et rate-limiting via Admin API

setup-kong.sh
#!/bin/bash

# Créer le service backend
curl -i -X POST http://localhost:8001/services/ \
  --data "name=backend-service" \
  --data "url=http://backend:3001"

# Créer la route /
 curl -i -X POST http://localhost:8001/services/backend-service/routes \
  --data "paths[]=/" \
  --data "methods[]=GET" \
  --data "methods[]=POST"

# Ajouter plugin rate-limiting (5 req/min)
curl -i -X POST http://localhost:8001/services/backend-service/plugins \
  --data "name=rate-limiting" \
  --data "config.minute=5" \
  --data "config.policy=local"

# Vérifier
echo "Services:"
curl -X GET http://localhost:8001/services

echo "Plugins:"
curl -X GET http://localhost:8001/services/backend-service/plugins

Ce script shell configure dynamiquement le service, route et plugin rate-limiting via Kong Admin API (curl POST). Policy 'local' pour mémoire in-process, scalable horizontalement. Testez avec 6+ req /hello pour voir 429. Piège : quotes escaped en bash ; utilisez --data pour simplicité.

Ajouter key-auth et consumer

add-auth.sh
#!/bin/bash

# Créer consumer
CONSUMER_ID=$(curl -s -i -X POST http://localhost:8001/consumers/ \
  --data "username=api-client" | grep -o '"id":"[^"]*' | cut -d'"' -f4)

echo "Consumer ID: $CONSUMER_ID"

# Créer credential key-auth pour ce consumer
curl -i -X POST http://localhost:8001/consumers/api-client/key-auth \
  --data "key=my-secret-api-key-123"

# Attacher plugin key-auth au service
curl -i -X POST http://localhost:8001/services/backend-service/plugins \
  --data "name=key-auth" \
  --data "config.key_names[]=apikey" \
  --data "config.hide_credentials=false"

# Vérifier credential
echo "Key:"
curl -s http://localhost:8001/consumers/api-client/key-auth | jq .

Script avancé extrayant ID consumer dynamiquement (grep/cut), génère clé API statique et attache plugin key-auth (header 'apikey'). hide_credentials=true masque en logs prod. Piège : sans jq pour JSON pretty, mais fonctionnel sans ; ajoutez apt install jq si besoin.

Bonnes pratiques

  • Mode DB-less prioritaire : Pas de DB overhead, config YAML gitops-ready pour CI/CD.
  • Sécurisez Admin API : En prod, KONG_ADMIN_LISTEN=127.0.0.1:8001 + NGINX reverse proxy avec mTLS.
  • Plugins en cascade : Rate-limit avant auth pour économies CPU ; utilisez run_on=first pour perf.
  • Monitoring Prometheus : Ajoutez plugin prometheus avec curl POST /plugins --data name=prometheus.
  • Healthchecks avancés : Activez KONG_PROXY_LISTEN=0.0.0.0:8000 reuseport pour scale.
  • Secrets management : Stockez clés en Vault ou env vars, pas hardcoded.

Erreurs courantes à éviter

  • Oubli réseau Docker : Services isolés sans kong-net causent 'host unreachable' ; toujours network commun.
  • Rate-limit non persistant : Policy 'cluster' sans Redis/DB perd état au restart ; 'local' OK pour dev.
  • Admin API exposée publiquement : Risque takeover ; firewall + auth basique (admin_gui_auth).
  • Images non optimisées : Backend sans multi-stage Dockerfile gonfle à 1GB ; utilisez Alpine + prod deps.

Pour aller plus loin