This is an old revision of the document!
In cadrul scheletului de cod este implementat un API Gateway minimal sub forma de server de NodeJS. Acesta are urmatoarele functionalitati:
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.2" services: - name: books-service url: http://lab4_books-service/api routes: - name: books-service-route paths: - /api/books - name: db-adminer url: http://lab4_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
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: - 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
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: