In cadrul scheletului de cod este implementat un API Gateway minimal sub forma de server de NodeJS. Acesta are urmatoarele functionalitati:

• expune rute din aplicatie
• functioneaza ca un punct central de acces in sistem

Cu toate acestea, implementarea programatica a unui API Gateway necesita timp si, de multe ori, munca depusa implica scriere repetitiva de cod.

Kong este unul dintre liderii din domeniul Cloud in materie de solutii de API Gateway declarative. Kong este nativ Docker, este bazat pe NGinx si nu necesita scriere de cod, ci doar furnizarea unei configuratii (sau configurarea on-the-fly prin cereri HTTP).

Kong functioneaza ca un serviciu de Docker si intercepteaza traficul venit, in functie de regulile mentionate, si apoi il redirecteaza catre alte servicii.

In plus, Kong ofera o gama variata de plugins ce aduc functionalitati extra precum rate limiting, compression, logging, etc…

Arhitectura este identica cu cea a exercitiului din laboratorul precedent, insa, in loc de API Gateway programatic, vom folosi Kong. In plus, vom expune si serviciul Adminer tot prin intermediul Kong.

Comportamentul dorit va fi ca, in urma apelului IP_PUBLIC/api/books sa interactionam cu serviciul books (POST/GET) si in urma apelului IP_PUBLIC/adminer sa interactionam cu serviciul adminer.

Kong poate fi rulat atat in modul DB-on cat si in modul DB-less. Noi vom folosi abordarea DB-less, furnizand o configuratie bazata pe un fisier .yml. In modul DB-on, Kong mai foloseste o baza de date si configuratia se face pe baza de cereri POST catre api-ul intern de configurare.

_format_version: "2.1"

services:
  - name: books-service
    url: http://labkong_books-service/api
    routes:
      - name: books-service-route
        paths: 
          - /api/books
          
  - name: db-adminer
    url: http://labkong_adminer:8080
    routes:
      - name: adminer-service
        paths:
          - /adminer

consumers:
  - username: lab-student

plugins:
  - name: key-auth
    service: books-service

keyauth_credentials:
  - consumer: lab-student
    key: mobylab
    hide_credentials: true

• Services - reprezinta ce servicii se vor conecta la Kong pentru interceptare si forwardare de trafic
• Consumers - reprezinta ce optiuni se pot seta fiecarui serviciu, in functie de plugin (este optional, si se foloseste doar in contextul pluginurilor)

• services → name - numele serviciului din punct de vedere al configurarii rezultate. Trebuie sa fie unic.
• services → url - calea de comunicare cu serviciul de docker. In cazul nostru, reprezinta ruta din interioriul serviciilor de docker, unde se vor forwarda cererile HTTP.

• services → routes - rutele pe care se va mapa traficul din exterior
• services → routes → name - numele rutei din punct de vedere al configurarii rezultate. Trebuie sa fie unic.
• services → routes → path - calea de comunicare din exterior, care se va mapa pe ruta furnizata in url

Ca si oricare alt serviciu de Docker, Kong se adauga in fisierul de configuratie al stivei .yml.

services:
  kong:
    image: kong:latest
    volumes:
      - ./kong:/usr/local/kong/declarative #injectarea fisierului de configurare la calea specificata
    environment:
      KONG_DATABASE: 'off' #obligatoriu, daca se vrea modul DB-less
      KONG_DECLARATIVE_CONFIG: /usr/local/kong/declarative/kong.yml #trebuie specificat unde anume se va gasi fisierul de configurare
      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, 0.0.0.0:8444 ssl
    ports:
      - 8000:8000 #expunerea porturilor
      - 8443:8443
    deploy:
      placement:
        constraints: [node.role == manager] #constrangerea de rulare doar pe master, pentru a nu exista conflict la nivel de volume
    networks:
      - internal

Daca totul a decurs bine, apelarea rutei IP_PUBLIC_PLAY_WITH_DOCKER/adminer va trebui sa rezulte in panoul de administrare al bazei de date, iar cererile din Postman pe ruta IP_PUBLIC_PLAY_WITH_DOCKER/api/books vor trebui sa esueze, in cazul in care nu exista apikey in header, sau sa functioneze, daca se pune cheia mobylab in header.

Bineinteles, exemplul aratat in cadrul acestui laborator este unul trivial. Kong se poate folosi pentru mult mai multe lucruri utile in lucrul cu servicii distribuite si microservicii, precum rate limiting, distributed logging, ip restriction, 3rd party authorization, cors, samd…

Esential, Kong se foloseste ca un punct central de acces in sistemul vostru, care se introduce nativ in ecosistemul Docker. In plus, este indicat sa dedicati cat mai multe functionalitati care au legatura cu traficul web catre API Gateway, pentru a nu ingreuna business logic-ul din interiorul serviciilor.

In continuare o sa ilustram aplicarea urmatoarelor pluginuri:

1. Rate Limiting - limitarea numarului de cereri pe anumite rute
2. JWT - autorizarea serviciilor pe baza unui JWT
3. CORS - adaugarea politicilor CORS pe anumite servicii
4. Bot Detection - protectia impotriva botilor web
5. Promtheus Logging - suport pentru extragerea logurilor utilizand Prometheus