Laboratorul 03 - Persistență în Docker Swarm și Kong

Exemplele din acest laborator se găsesc pe repository-ul materiei.

Persistență în Docker Swarm

În contextul Docker Swarm, nu mai există o singură gazdă, ci multiple noduri conectate în rețea. Acest lucru face ca folosirea volumelor locale să nu fie recomandată, deoarce orchestrarea unui task pe un nod care nu are volumul cerut de container va rezulta în respingerea acelui task.

Există două posibilități principale de rezolvare a acestei probleme. Prima variantă presupune constrângerea unor servicii astfel încât să ruleze doar pe noduri manager, astfel:

services:
    example:
        deploy:
            placement:
                constraints: [node.role == manager]

Această practică este utilă doar atunci când există un singur nod manager și astfel suntem siguri că taskurile ale căror containere au nevoie de volumele definite în configurație vor rula doar pe managerul unde exista volumele.

În cazul în care există mai multe noduri manager și dorim, de exemplu, să rulăm o bază de date într-un serviciu, dacă aceasta va fi orchestrată să ruleze pe alt nod față de cel pe care a fost prima oară orchestrată, nu va mai avea acces la volumul unde a stocat date inițial. În acest caz, va crea un volum nou pe noul nod, ajungându-se astfel la inconsistență.

Cea de-a doua variantă pentru a rezolva problema descrisă mai sus este configurarea volumelor astfel încât să folosească un sistem de stocare extern (cum ar fi NFS, GlusterFS, Samba, Amazon S3, etc.).

Din păcate, infrastructura de Play with Docker nu permite realizarea unui demo practic care să ilustreze folosirea volumelor cu stocare externă, având limitări la nivel de comunicație inter-mașini. Totuși, dacă aveți acces la un cluster de mașini Docker, vă recomandăm să încercați să vă configurați o stivă de servicii care folosește volume cu stocare externă.

NFS

Cea mai facilă metodă de a adăuga stocare externă în Docker este prin intermediul NFS (Network File System). Pentru aceasta, este în primul rând nevoie de existența unui server NFS, care poate fi rulat fie nativ (pe una din mașinile din cluster-ul Docker sau undeva în exterior), fie prin intermediul unui container Docker. Există multiple soluții de rulare a unui server NFS folosind Docker, însă noi vă recomandăm această soluție populară bazată pe Alpine Linux.

Soluția de mai sus reprezintă un container care rulează în mod privilegiat, având acces la resursele gazdei. Înainte să rulați containerul, trebuie să vă creați un director ce va fi partajat în rețea prin intermediul NFS.

Directorul partajat trebuie să nu fie de tipul OverlayFS.

Pentru a vedea sistemul de fișiere, se poate executa comanda df -Th (pe Linux).

Dupa ce s-a creat directorul ce va reține datele partajate în rețea, se execută comanda de mai jos pentru pornirea serverului de NFS și exportul directorului partajat:

$ docker run -d --name nfs --privileged -v /cale/director/partajat:/nfsshare \
      -e SHARED_DIRECTORY=/nfsshare itsthenetwork/nfs-server-alpine:latest

În comanda de mai sus, directorul pe care dorim să-l partajăm se află la calea /cale/director/partajat, fiind mapat pe serverul NFS la calea /nfsshare. Odată ce serverul NFS a fost pornit, se pot crea volume peste NFS în mai multe moduri. O variantă este crearea de volume prin intermediul API-ului din linia de comandă. Astfel, dacă se dorește crearea unui volum numit mynfsvol, care apoi poate fi atașat la alte containere sau servicii, se poate executa următoarea comandă:

$ docker volume create --driver local --opt type=nfs --opt o=nfsvers=3,addr=192.168.99.1,rw \
      --opt device=:/nfsshare mynfsvol

În comanda de mai sus, IP-ul serverului NFS este 192.168.99.1 și se folosește versiunea 3 de NFS. Se poate inspecta volumul nou-creat pentru a se observa caracteristicile sale:

$ docker volume inspect mynfsvol
[
    {
        "CreatedAt": "2021-03-31T17:26:11Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/mnt/sda1/var/lib/docker/volumes/mynfsvol/_data",
        "Name": "mynfsvol",
        "Options": {
            "device": ":/nfsshare",
            "o": "nfsvers=3,addr=192.168.99.1,rw",
            "type": "nfs"
        },
        "Scope": "local"
    }
]

Un astfel de volum extern poate fi dat ca parametru la pornirea unui container din linia de comandă, astfel:

$ docker run -v mynfsvol:/test -it alpine

În comanda de mai sus, se mapează volumul NFS la calea /test din interiorul containerului. Acest lucru se poate face simultan pe mai multe containere de pe mașini diferite, toate având aceeași mapare și deci acces la aceleași fișiere.

Putem folosi un volum creat în linia de comandă chiar într-un fișier de Docker Compose, fie la rularea locală, fie la rularea folosind Docker Swarm. Pentru acest lucru, este nevoie de câteva modificări în configurația volumelor din cadrul fișierelor YAML. Ca exemplu, presupunem că avem un serviciu de bază de date care are nevoie de volume pentru scriptul de configurație și pentru persistența datelor (pe modelul temelor de casă din laboratoarele precedente):

services:
    db:
        image: postgres:12
        volumes:
            - db-data-nfs:/var/lib/postgresql/data
            - db-config-nfs:/docker-entrypoint-initdb.d

volumes:
    db-data-nfs:
        external: true
    db-config-nfs:
        external: true

În exemplul de mai sus, se presupune că volumele db-data-nfs și db-config-nfs au fost create în prealabil folosind comenzile prezentate anterior. Este totuși posibil să se creeze volumele direct în fișierul Docker Compose, așa cum s-a prezentat și în laboratoarele precedente. În acest caz, volumele nu vor mai fi declarate ca fiind externe, ci trebuie configurate pentru a funcționa peste NFS, astfel:

volumes:
    db-data-nfs:
        driver: local
        driver_opts:
           type: nfs
           o: "nfsvers=3,addr=192.168.99.1,nolock,soft,rw"
           device: :/database/data
    db-config-nfs:
        driver: local
        driver_opts:
           type: nfs
           o: "nfsvers=3,addr=192.168.99.1,nolock,soft,rw"
           device: :/database/config

În exemplul de mai sus, s-a folosit același IP pentru serverul NFS (192.168.99.1), iar directoarele /database/data și /database/config trebuie să existe în interiorul directorului partajat de gazda containerului de server NFS (/cale/director/partajat din exemplul de pornire a serverului NFS).

O altă modalitate de a adăuga persistență folosind NFS ar fi montarea directoarelor de NFS pe toate nodurile (sau pe toți managerii) din cluster, și apoi utilizarea de bind mounts pentru a mapa căile de NFS montate local în interiorul serviciilor Docker.

GlusterFS

GlusterFS este un sistem de fișiere de rețea open-source, utilizat pentru stocare în cloud sau streaming media. Pentru a putea folosi volume peste GlusterFS, este necesară instalarea și configurarea sa pe fiecare nod din cluster. În continuare, sunt prezentate comenzile necesare instalării pe un sistem bazat pe Ubuntu:

$ apt-get install software-properties-common -y
$ add-apt-repository ppa:gluster/glusterfs-3.12
$ apt-get update
$ apt install glusterfs-server -y

Odată instalat, GlusterFS se pornește cu următoarele comenzi:

$ systemctl start glusterd
$ systemctl enable glusterd

În continuare, nodul leader al clusterului (care va fi, cel mai probabil, nodul coordonator GlusterFS) va trebui să execute următoarea comandă pentru fiecare din celălalte noduri din cluster, pentru a conecta nodurile pentru sistemul de fișiere:

$ gluster peer probe <HOSTNAME_NOD>

Conectarea nodurilor se poate verifica prin următoarea comandă dată pe manager:

$ gluster pool list

Următorul pas presupune crearea unui volum partajat pe întreg clusterul, printr-o comandă executată pe manager. În exemplul de mai jos, se presupune că avem un manager (cu hostname-ul docker-manager) și doi workeri (docker-worker1 și docker-worker2). Toate trei nodurile vor avea un volum partajat (numit mysharedvol) la calea /gluster/mysharedvol, deși nu este obligatoriu să fie aceeași cale la toate nodurile.

$ gluster volume create mysharedvol replica 3 docker-manager:/gluster/mysharedvol \
      docker-worker1:/gluster/mysharedvol docker-worker2:/gluster/mysharedvol force

În continuare, managerul trebuie să pornească volumul, astfel:

$ gluster volume start mysharedvol

Ultimul pas se referă la montarea volumului, astfel încât să se poate accesa și după un restart sau în alte situații. Comenzile de mai jos trebuie executate pe toate nodurile din cluster:

$ echo 'localhost:/mysharedvol /mnt glusterfs defaults,_netdev,backupvolfile-server=localhost 0 0' >> /etc/fstab
$ mount.glusterfs localhost:/mysharedvol /mnt
$ chown -R root:docker /mnt

În acest moment, în directorul /mnt se va găsi mapat, pe fiecare nod din cluster, volumul partajat de GlusterFS. Similar cu NFS, acesta va putea fi folosit în fișiere Docker Compose ca un bind mount pentru a asigura persistență distribuită în aplicațiile noastre, astfel:

services:
    db:
        volumes:
            - /mnt/db-config:/docker-entrypoint-initdb.d/
            - /mnt/db-data:/var/lib/postgresql/data

SSHFS

O altă variantă de a realiza persistență corectă într-un Docker Swarm este prin crearea de volume folosind alt driver de volum decât cel implicit (care le creează local). Un astfel de exemplu este driver-ul de SSHFS, numit vieux/sshfs. SSHFS este un client de sistem de fișiere folosit pentru a monta și interacționa cu directoare și fișiere aflate pe un server, prin intermediul unei conexiuni SSH.

Pentru a putea folos driver-ul de SSHFS, acesta trebuie instalat pe toate gazdele Docker:

$ docker plugin install --grant-all-permissions vieux/sshfs

Odată ce driver-ul a fost instalat, putem crea un volum peste SSFHS astfel:

$ docker volume create --driver vieux/sshfs -o sshcmd=remoteuser@remotenode:/home/remoteuser \
      -o password=remotepassword sshvolume

Astfel, se creează local un volum peste SSH, aflat pe serverul remotenode. La server, conectarea se face cu numele de utilizator remoteuser și parola remotepassword (dacă există chei partajate configurate între client și server, nu mai este necesară parola). Volumul astfel creat poate fi folosit ca orice alt volum, iar tot ce se scrie în el va fi persistat la server.

Volumul peste SSHFS se poate crea direct la rularea unui container, astfel:

$ docker run -d --volume-driver vieux/sshfs \
    --mount src=sshvolume,target=/myvol,volume-opt=sshcmd=remoteuser@remotenode:/home/remoteuser,volume-opt=password=remotepassword \
    alpine

Puteți testa SSHFS în acest sandbox de Play with Docker.

Kong API Gateway

În cadrul scheletului de cod este implementat un API Gateway minimal sub forma de server de NodeJS. Acesta are următoarele funcționalități:

  • expune rute din aplicație
  • funcționează ca un punct central de acces în sistem.

Cu toate acestea, implementarea programatică a unui API Gateway necesită timp și, de multe ori, munca depusă implică scriere repetitivă de cod.

Kong este unul dintre liderii din domeniul Cloud în materie de soluții de API Gateway declarative. Kong este nativ Docker, este bazat pe Nginx si nu necesită scriere de cod, ci doar furnizarea unei configurații (sau configurarea on-the-fly prin cereri HTTP).

Kong funcționează ca un serviciu de Docker și interceptează traficul venit, în funcție de regulile menționate, și apoi îl redirectează către alte servicii.

În plus, Kong oferă o gamă variată de plugins ce aduc funcționalități extra precum rate limiting, compression, logging, etc.

Arhitectura implementată

Arhitectura este identică cu cea a exercițiului din laboratorul precedent, însă, în loc de API Gateway programatic, vom folosi Kong. În plus, vom expune și serviciul Adminer tot prin intermediul Kong.

Comportamentul dorit va fi ca, în urma apelului IP_PUBLIC/api/books, să interacționăm cu serviciul Books (POST/GET) și, în urma apelului IP_PUBLIC/adminer, să interacționăm cu serviciul Adminer.

Implementare Kong

Kong poate fi rulat atât în modul DB-on, cât și în modul DB-less. Noi vom folosi abordarea DB-less, furnizând o configurație bazată pe un fișier .yml. În modul DB-on, Kong mai folosește o bază de date și configurația se face pe bază de cereri POST către API-ul intern de configurare.

Fișierul de configurație
_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 - reprezintă ce servicii se vor conecta la Kong pentru interceptare și forwarding de trafic
  • consumers - reprezintă ce opțiuni se pot seta fiecărui serviciu, în funcție de plugin (este opțional și se folosește doar în contextul pluginurilor)

Fiecare serviciu trebuie să aibă obligatoriu definite următoarele: name, url, routes.

  • services → name - numele serviciului din punct de vedere al configurării rezultate, trebuie să fie unic
  • services → url - calea de comunicare cu serviciul de Docker; în cazul nostru, reprezintă ruta din interioriul serviciilor de Docker unde se vor forwarda cererile HTTP

Observați că în URL se precizează NUME-STIVA_NUME_SERVICIU_DOCKER în loc de IP.

  • services → routes - rutele pe care se va mapa traficul din exterior
  • services → routes → name - numele rutei din punct de vedere al configurării rezultate, trebuie să fie unic
  • services → routes → path - calea de comunicare din exterior, care se va mapa pe ruta furnizată în URL

Pluginurile sunt opționale, însă am vrut să demonstrăm utilizarea unui plugin de autorizare pe bază de cheie de API trimisă în header. Deoarece pluginul este activat doar pe serviciul Books, numai calea /api/books este securizată.

Includerea în stiva de servicii Docker

Ca oricare alt serviciu de Docker, Kong se adaugă în fișierul de configurație al stivei.

services:
  kong:
    image: kong:latest
    volumes:
      - ./kong:/usr/local/kong/declarative # injectarea fișierului de configurare la calea specificată
    environment:
      KONG_DATABASE: 'off' # obligatoriu, dacă se vrea modul DB-less
      KONG_DECLARATIVE_CONFIG: /usr/local/kong/declarative/kong.yml # trebuie specificat unde anume se va găsi fișierul 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] # constrângerea de rulare doar pe manager, pentru a nu exista conflict la nivel de volume
    networks:
      - internal

Aveți grija să conectați toate serviciile pe care le vreți expuse în Kong în aceeași rețea cu el. Observați că, în cadrul configurației de mai sus, am folosit rețeaua internal. Atât serviciul Books cât și Adminer vor trebui să fie în rețeaua internal.

Kong ascultă pe porturile 8000 și 8443. Pentru a expune în public 80 și 443, este nevoie de mapare explicită.

Comportament așteptat

Dacă totul a decurs bine, apelarea rutei IP_PUBLIC_PLAY_WITH_DOCKER/adminer va rezulta în panoul de administrare a bazei de date, iar cererile din Postman pe ruta IP_PUBLIC_PLAY_WITH_DOCKER/api/books vor eșua în cazul în care nu există o cheie API în header, sau să funcționeze dacă se pune cheia mobylab în header.

Extindere Kong

Bineînțeles, exemplul arătat în cadrul acestui laborator este unul simplu. Kong se poate folosi pentru mult mai multe lucruri utile în lucrul cu servicii distribuite și microservicii, precum rate limiting, distributed logging, IP restriction, 3rd party authorization, CORS, etc.

Esențial, Kong se folosește ca un punct central de acces în sistem, care se introduce nativ în ecosistemul Docker. În plus, este indicat să dedicați cât mai multe funcționalități care au legătură cu traficul Web către API Gateway, pentru a nu îngreuna business logic-ul din interiorul serviciilor.

În continuare, sa va ilustra aplicarea următoarelor pluginuri:

  1. Rate Limiting - limitarea numărului de cereri pe anumite rute
  2. JWT - autorizarea serviciilor pe baza unui JWT
  3. CORS - adaugărea politicilor CORS pe anumite servicii
  4. Bot Detection - protecția împotriva boților web
  5. Prometheus Logging - suport pentru extragerea logurilor utilizând Prometheus.
_format_version: "2.1"

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

consumers:
  - username: lab-student
    
plugins:
  - name: rate-limiting
    config: 
      minute: 10
      limit_by: ip
      policy: local

  - name: cors
    service: books-service
    config:
      origins: 
       - "*"

  - name: bot-detection

  - name: prometheus

  - name: jwt
    service: books-service
    # config:
    #   claims_to_verify:
    #     - exp
    #   maximum_expiration: 60

jwt_secrets:
  - consumer: lab-student
    key: Moby Labs IDP
    algorithm: HS256
    secret: mobylab

Logging

Fișierul docker-stack-kong-plugins.yml integrează, pe lângă Kong-ul extins cu pluginuri, și Prometheus și Grafana pentru explorarea logurilor provenite din Kong.

Pentru a accesa Grafana, este nevoie să realizați următorii pași:

  1. intrați pe IP:3000
  2. conectați-vă cu admin / admin
  3. setați sursa de date http://prometheus:9090
  4. importați dashboardul oferit de Kong.
idp/laboratoare/03.txt · Last modified: 2023/04/10 20:40 by radu.ciobanu
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0