Differences
This shows you the differences between two versions of the page.
|
idp:laboratoare:05 [2021/04/04 19:34] alexandru.hogea [Kong Api Gateway] |
idp:laboratoare:05 [2023/02/22 11:11] (current) radu.ciobanu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Laboratorul 05 - Kong ===== | ===== Laboratorul 05 - Kong ===== | ||
| - | ==== Kong Api Gateway ==== | ||
| - | |||
| - | 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. | ||
| - | |||
| - | [[https://konghq.com/|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 Implementata === | ||
| - | |||
| - | 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. | ||
| - | |||
| - | {{:cc:laboratoare:schema_lab.png?600|}} | ||
| - | |||
| - | 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. | ||
| - | |||
| - | === Implementare Kong === | ||
| - | |||
| - | 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. | ||
| - | |||
| - | == Fisierul de Configuratie == | ||
| - | |||
| - | <code yaml> | ||
| - | _format_version: "2.1" | ||
| - | |||
| - | services: | ||
| - | - name: books-service | ||
| - | url: http://lab4-cluster_books-service/api | ||
| - | plugins: | ||
| - | - name: key-auth | ||
| - | routes: | ||
| - | - name: books-service-route | ||
| - | paths: | ||
| - | - /api/books | ||
| - | | ||
| - | - name: db-adminer | ||
| - | url: http://lab4-cluster_adminer:8080 | ||
| - | routes: | ||
| - | - name: adminer-service | ||
| - | paths: | ||
| - | - /adminer | ||
| - | |||
| - | consumers: | ||
| - | - username: lab-student | ||
| - | keyauth_credentials: | ||
| - | - key: mobylab | ||
| - | </code> | ||
| - | |||
| - | * **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) | ||
| - | |||
| - | <note tip>Fiecare serviciu trebuie sa aiba obligatoriu definite urmatoarele: name, url, routes</note> | ||
| - | |||
| - | * **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. | ||
| - | |||
| - | <note tip>Observati ca in URL se precizeaza NUME-STIVA_NUME_SERVICIU_DOCKER, in loc de ip.</note> | ||
| - | |||
| - | * **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 | ||
| - | |||
| - | <note tip>Plugins sunt optionale, insa am vrut sa va demonstram utilizarea unui plugin de autorizare pe baza de apikey trimis in header. Deoarece pluginul este activat doar pe serviciul books-service, numai calea **/api/books** este securizata</note> | ||
| - | |||
| - | == Includerea in Stiva de Servicii Docker == | ||
| - | |||
| - | Ca si oricare alt serviciu de Docker, Kong se adauga in fisierul de configuratie al stivei .yml. | ||
| - | |||
| - | <code yaml> | ||
| - | 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: | ||
| - | - 80:8000 #expunerea porturilor | ||
| - | - 443:8443 | ||
| - | deploy: | ||
| - | placement: | ||
| - | constraints: [node.role == manager] #constrangerea de rulare doar pe master, pentru a nu exista conflict la nivel de volume | ||
| - | networks: | ||
| - | - internal | ||
| - | </code> | ||
| - | |||
| - | <note tip>Aveti grija sa conectati toate serviciile pe care le vreti expuse in Kong, in aceeasi retea cu el. Observati ca, in cadrul configuratiei de mai sus, am folosit reteaua //internal//. Atat serviciul Books cat si Adminer vor trebui, si ele, sa fie in reteaua //internal//</note> | ||
| - | <note tip>Kong asculta pe porturile 8000 si 8443. Pentru a expune, in public, 80 si 443, este nevoie sa faceti mapare explicita</note> | ||
| - | |||
| - | === Comportament Asteptat === | ||
| - | |||
| - | 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. | ||
| - | |||
| - | {{:cc:laboratoare:apikey_lab6.png?600|}} | ||
| - | |||
| - | === Extindere Kong === | ||
| - | |||
| - | 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 continuare o sa ilustram aplicarea mai multor pluginuri care usureaza mult dezvoltarea: | ||
| - | |||
| - | - [[https://docs.konghq.com/hub/kong-inc/rate-limiting/|Rate Limiting]] - limitarea numarului de cereri pe anumite rute | ||
| - | - [[https://docs.konghq.com/hub/kong-inc/jwt/|JWT]] - autorizarea serviciilor pe baza unui JWT | ||
| - | - [[https://docs.konghq.com/hub/kong-inc/cors/|CORS]] - adaugarea politicilor CORS pe anumite servicii | ||
| - | - [[https://docs.konghq.com/hub/kong-inc/bot-detection/|Bot Detection]] - protectia impotriva botilor web | ||
| - | - [[https://docs.konghq.com/hub/kong-inc/prometheus/|Promtheus Logging]] - suport pentru extragerea logurilor utilizand Prometheus | ||
