This is an old revision of the document!
Laboratorul 02 - Elemente adiționale în Docker
Publicarea unei imagini într-un registru
În laboratorul 1, am creat o imagine de Docker pe care am rulat-o local într-un container. Pentru a putea rula imaginea creată în orice alt sistem, este necesar să o publicăm, deci să o urcăm într-un registru pentru a putea să facem deploy de containere cu imaginea noastră în producție. Un registru este o colecție de repository-uri, iar un repository este o colecție de imagini (similar cu GitHub, cu diferența că, într-un registru Docker, codul este deja construit și se rețin modificările făcute în straturile imaginilor de Docker, nu în cod). Există numeroase registre pentru imagini Docker (Docker Hub, Gitlab Registry, etc.), iar la laborator vom folosi registrul public Docker, pentru că este gratuit și pre-configurat.
Pentru exemplificare, vom porni de la aplicația prezentată în laboratorul 1, care afișează o poză aleatoare într-o pagină Web și pe care o puteți găsi în această arhivă. Primul pas în publicarea unei imagini este crearea unui cont la https://hub.docker.com. Mai departe, logarea în registru de pe mașina locală se realizează prin următoarea comandă:
$ docker login Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one. Username: Password: Login Succeeded
Putem specifica numele de utilizator și parola direct în comandă, iar varianta generică a acesteia este (unde serverul implicit, dacă alegem să omitem acel parametru, este Docker Hub):
$ docker login [–u <UTILIZATOR> –p <PAROLĂ>] [SERVER]
Înainte de a publica imaginea în registru, ea trebuie tag-uită după formatul username/repository:tag. Tag-ul este opțional, dar este util pentru că denotă versiunea unei imagini Docker. Se folosește următoarea comandă pentru tag-uirea unei imagini (în exemplul de mai jos, unde vrem să tag-uim imaginea pe care am creat-o în laboratorul anterior, utilizatorul se numește raduioanciobanu, repository-ul este cloudcomputing, iar tag-ul este example):
$ docker tag testapp raduioanciobanu/cloudcomputing:example
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE testapp latest 74254b15e6ba About a minute ago 62.9MB raduioanciobanu/cloudcomputing example 74254b15e6ba About a minute ago 62.9MB alpine edge f96c4363411f 4 weeks ago 5.58MB
Odată tag-uită imaginea, ea poate fi publicată în registru:
$ docker push raduioanciobanu/cloudcomputing:example
Din acest moment, imaginea va fi vizibilă pe https://hub.docker.com, de unde poate fi descărcată și rulată pe orice mașină, server sau sistem Cloud:
$ docker run -p 8888:5000 raduioanciobanu/cloudcomputing:example Unable to find image 'raduioanciobanu/cloudcomputing:example' locally example: Pulling from raduioanciobanu/cloudcomputing cc5efb633992: Pull complete cd0af7ebab8a: Pull complete 41c55a3da379: Pull complete a779b27637f8: Pull complete dfaeccf28d0c: Pull complete 805843c75452: Pull complete Digest: sha256:25af18fb4ffa9bf439e90bd4baee9adf0ab1e2999a44aeaa216ebf0454201ce8 Status: Downloaded newer image for raduioanciobanu/cloudcomputing:example * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit) [...]
Alternativ, în loc să rulăm comanda de publicare a unei imagini de fiecare dată când modificăm ceva la codul sursă, putem să configurăm build-uri automate din contul de Docker Hub. Pașii necesari sunt descriși în continuare. În primul rând, este necesară existența unui repository Docker Hub și a unui repository pe GitHub (Docker Hub funcționează și cu BitBucket, dar în acest exemplu ne vom concentra pe GitHub). Toate fișierele necesare creării unei imagini Docker (adică Dockerfile-ul și toate fișierele sursă și de configurare) trebuie să fie prezente în repository-ul GitHub. Mai departe, de pe pagina repository-ului de Docker Hub, se selectează tab-ul Builds și apoi opțiunea „Configure Automated Builds”, așa cum se poate observa în imaginea de mai jos.
În continuare, va fi necesară completarea unor informații despre repository-ul GitHub și opțiuni de testare automată înainte de build, după care trebuie specificate regulile de build. O regulă de build conține informații despre: tipul build-ului (bazat pe un branch sau pe un tag Git), sursa (numele branch-ului sau tag-ului de pe care se face build-ul), tag-ul care va fi asignat noii imagini Docker construite, numele și adresa fișierului Dockerfile în repository-ul GitHub, calea către sursele ce vor fi compilate, opțiuni de auto-build (dacă se va face build automat la fiecare push pe branch-ul sau cu tag-ul specificat), opțiuni de build caching (dacă se vor cache-ui fișiere la build în cazul unor repository-uri de dimensiuni mari). În exemplul de mai jos, atunci când are loc un push pe branch-ul master, se va crea automat o imagine Docker cu tag-ul latest folosindu-se fișierul Dockerfile aflat în rădăcina repository-ului de GitHub.
În continuare, pe pagina de Builds de pe Docker Hub vor exista opțiuni pentru pornirea unui nou build, precum și informații despre build-urile precedente și statusurile lor.
Networking
Subsistemul de networking Docker este de tip pluggable și folosește drivere. Mai multe astfel de drivere există implicit, ele oferind funcționalitate de bază pentru componenta de rețea. Driverul de rețea implicit este bridge, și presupune crearea unui bridge software care permite containerelor conectate la aceeași rețea de acest tip să comunice între ele, oferind totodată izolare față de containerele care nu sunt conectate la această rețea bridge. Driverul de bridge Docker instalează automat reguli pe mașina gazdă astfel încât containerele de pe rețele bridge diferite nu pot comunica direct unele cu altele. Rețelele de tip bridge se aplică doar containerelor care rulează pe aceeași mașină Docker.
Pentru comunicație între containere care rulează pe mașini Docker diferite, se poate gestiona rutarea la nivel de sistem de operare, sau se poate folosi o rețea de tip overlay. Așa cum se va detalia în laboratorul 3, rețelele de tip overlay conectează mai multe mașini Docker și permit serviciilor dintr-un swarm să comunice între ele. Rețelele overlay se mai pot folosi și pentru a facilita comunicația între un serviciu swarm și un container de sine stătător, sau între două containere care rulează pe mașini Docker diferite.
Alte drivere de rețea Docker mai sunt host (pentru containere de sine stătătoare, eliminând izolarea de rețea dintre container și gazda Docker, folosindu-se astfel infrastructura de rețea a gazdei direct), macvlan (permite asignarea de adrese MAC unui container, făcându-l să apară ca un dispozitiv fizic pe rețea), sau none.
Containerele din aceeași rețea pot comunica fără să expună porturi, prin intermediul named DNS. Acest lucru înseamnă că putem să accesam un container nu prin IP, ci prin numele său. Pentru comunicarea cu lumea exterioară (gazda, containere din afara rețelei, etc.) trebuie expuse porturi.
Pentru a demonstra modul în care funcționează rețelele de tip bridge în Docker, întâi vom porni două containere ce vor rula Alpine. În mod implicit, orice container Docker nou-creat se va afla într-o rețea numită „bridge”, așa că, pentru a demonstra faptul că două containere care nu sunt în aceeași rețea nu pot comunica, va trebui întâi să le scoate din acea rețea.
$ docker container run --name c1 -d -it alpine f5a8653a325e8092151614d5a6a80b04b9410ea8b8a5fcfc4028f1ad33239ad9
$ docker container run --name c2 -d -it alpine b063ad1ef7bd0ae82a7385582415e78938f7df531cef9eefc33e065af09cf92c
$ docker network disconnect bridge c1
$ docker network disconnect bridge c2
În acest moment, containerele c1 și c2 nu fac parte din nicio rețea. Mai departe, vom încerca să dăm ping dintr-un container în altul.
$ docker exec -it c1 ash / # ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) / # ping c2 ping: bad address 'c2' / # exit
Se poate observa mai sus că c1 nu are decât o adresă IP loopback și că nu poate accesa c2. De asemenea, ar fi interesant de menționat faptul că ne-am atașat la container folosind comanda docker exec rulând un shell (ash este shell-ul de pe Alpine).
Pentru a crea o rețea de tip bridge în Docker, putem folosi următoarea comandă:
$ docker network create -d bridge c1-c2-bridge
8644b8accd2a14d10c9911c36635ca6b161449b3aa527db878a727ec1bf980d0
Mai departe, putem vizualiza rețele existente astfel:
$ docker network ls NETWORK ID NAME DRIVER SCOPE ecd72738aa59 bridge bridge local 8644b8accd2a c1-c2-bridge bridge local 615363cafefa host host local 1e3b8e49b20d none null local
Putem adăuga un container într-o rețea fie atunci când pornim containerul, fie atunci când el deja a fost pornit. Pentru cazul de mai sus, unde c1 și c2 erau deja pornite, le putem adăuga în rețea astfel:
$ docker network connect c1-c2-bridge c1
$ docker network connect c1-c2-bridge c2
Dacă c1 și c2 nu ar fi fost deja pornite, le-am fi putut porni deja atașate la rețeaua c1-c2-bridge astfel:
$ docker container run --name c2 -d -it --network=c1-c2-bridge alpine 67dde5da9b793de63903ac85ff46574da77f0031df9b49acf44d58062687729c
$ docker container run --name c1 -d -it --network=c1-c2-bridge alpine 4de3e000700f81d31e0458dbd034abe90dfce6b1b992d23d760a44f748c0de0d
Putem vedea containerele dintr-o rețea astfel:
$ docker network inspect c1-c2-bridge [...] "Containers": { "b063ad1ef7bd0ae82a7385582415e78938f7df531cef9eefc33e065af09cf92c": { "Name": "c2", "EndpointID": "a76463662d110804205e9211537e541eb0de2646fa90e8760d3419a6dc7d32c7", "MacAddress": "02:42:ac:12:00:03", "IPv4Address": "172.18.0.3/16", "IPv6Address": "" }, "f5a8653a325e8092151614d5a6a80b04b9410ea8b8a5fcfc4028f1ad33239ad9": { "Name": "c1", "EndpointID": "95d9061b47f73f9b4cc7a82111924804bdc73d0b496549dec834216ee58c64ed", "MacAddress": "02:42:ac:12:00:02", "IPv4Address": "172.18.0.2/16", "IPv6Address": "" } } [...]
În acest moment, cele două containere fac parte din aceeași rețea și pot comunica:
$ docker exec -it c1 ash / # ping -c2 c2 PING c2 (172.18.0.3): 56 data bytes 64 bytes from 172.18.0.3: seq=0 ttl=64 time=6.258 ms 64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.109 ms --- c2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.109/3.183/6.258 ms / # exit
$ docker exec -it c2 ash / # ping -c2 c1 PING c1 (172.18.0.2): 56 data bytes 64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.111 ms 64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.268 ms --- c1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.111/0.189/0.268 ms / # exit
Volume și bind mounts
În Docker, datele dintr-un container nu sunt persistate în exterior. Pentru a ilustra acest lucru, putem rula un container simplu de Alpine, în care creăm un fișier apoi ieșim.
$ docker container run --name c1 -ti alpine sh Unable to find image 'alpine:latest' locally latest: Pulling from library/alpine 88286f41530e: Pull complete Digest: sha256:f006ecbb824d87947d0b51ab8488634bf69fe4094959d935c0c103f4820a417d Status: Downloaded newer image for alpine:latest / # mkdir /test && echo hello > /test/hello.txt / # exit
$ docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 97492cd1349b alpine "sh" 15 minutes ago Exited (0) 15 minutes ago c1
Odată ce un container a fost rulat, chiar dacă execuția sa s-a oprit, layer-ele sale pot fi accesate până când containerul este șters cu comanda docker container rm (sau docker system prune). În mod implicit, Docker folosește OverlayFS sau AUFS (ambele sisteme de fișiere de tip union) ca driver de storage pentru gestiunea imaginilor. Putem verifica acest lucru folosind docker info:
$ docker info | grep -i storage Storage Driver: overlay2
Pentru fiecare layer dintr-un container Docker, se vor stoca în AUFS/OverlayFS informații despre cum arăta inițial și despre ce fișiere s-au modificat (au fost adăugate, șterse sau schimbate). Aceste informații se găsesc în /var/lib/docker/aufs/diff (pentru AUFS) sau /var/lib/docker/overlay2 (pentru OverlayFS), unde există directoare pentru fiecare layer al fiecărui container care a fost rulat pe sistem fără să fi fost șters. Putem astfel să vedem din exteriorul containerului, după ce acesta a terminat de rulat, fișierul care a fost creat în interiorul containerului:
$ cd /var/lib/docker/overlay2/
$ ls -latr [...] drwx------ 4 root root 4096 Oct 21 07:12 5b3f2aeff7a90abd5c1a2eb50e5bbf9bde38983bda84728ab3788a12ea2399dc-init drwx------ 4 root root 4096 Oct 21 07:12 5b3f2aeff7a90abd5c1a2eb50e5bbf9bde38983bda84728ab3788a12ea2399dc
$ ls 5b3f2aeff7a90abd5c1a2eb50e5bbf9bde38983bda84728ab3788a12ea2399dc/diff/ root test
$ cat 5b3f2aeff7a90abd5c1a2eb50e5bbf9bde38983bda84728ab3788a12ea2399dc/diff/test/hello.txt hello
Totuși, aceste date nu sunt persistente, ci sunt șterse împreuna cu layer-ul. Astfel, dacă se șterge containerul, datele vor fi pierdute:
$ docker container rm 97492cd1349b
$ ls 5b3f2aeff7a90abd5c1a2eb50e5bbf9bde38983bda84728ab3788a12ea2399dc/ ls: 5b3f2aeff7a90abd5c1a2eb50e5bbf9bde38983bda84728ab3788a12ea2399dc: No such file or directory
Pentru persistența datelor dintr-un container, în Docker se folosesc mecanisme de persistență numite volume, care sunt o mapare între fișierele din cadrul unui container și fișiere de pe sistemul gazdă sau NFS (Network File Storage). Volumele Docker au câteva proprietăți și beneficii:
- sunt ușor de salvat și migrat
- pot fi controlate și configurate cu comenzi CLI sau cu API-ul de Docker
- funcționează pe containere Linux și Windows
- pot fi partajate între containere
- prin driverele de volume, se pot stoca date persistente pe gazde remote sau pe provideri de cloud, se pot cripta datele, etc.
- conținutul unui volum nou poate fi pre-populat de un container
- utilizarea unui volum nu crește dimensiunea unui container care îl folosește, pentru că un volum există în afara ciclului de viață al containerului.
Volumele se mai numesc și „named volumes” și sunt gestionate de Docker. Există mai multe metode pentru a defini și utiliza un volum atunci când se rulează un singur container de Linux. Dacă se creează o imagine custom, atunci volumul se poate defini în fișierul Dockerfile, prin comanda VOLUME. Dacă se rulează, de exemplu, un container bazat pe o imagine existentă (cum ar fi Alpine în exemplul din laboratorul 1), atunci se poate defini un volum la runtime. În exemplul de mai jos, rulăm o imagine de Alpine în background care face ping într-un fișier localizat într-un volum /test, pe care îl creăm folosind flag-ul -v:
$ docker container run --name c2 -d -v /test alpine sh -c 'ping 8.8.8.8 > /test/ping.txt'
$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 59d0785188a6 alpine "sh -c 'ping 8.8.8..." About a minute ago Up About a minute c2
În timp ce containerul rulează, putem să îl inspectăm și observăm că este legat de o componentă de tip Volume cu destinația /test. Astfel, putem afla unde este localizat volumul. Dacă ne uităm în acel director, vom vedea fișierul în care se face ping din container:
$ docker container inspect -f "{{ json .Mounts }}" c2 | python -m json.tool [ { "Destination": "/test", "Driver": "local", "Mode": "", "Name": "2afac5683222a3435549131a931a4c0628b775ecd3d79cb3fd597b3501418288", "Propagation": "", "RW": true, "Source": "/var/lib/docker/volumes/2afac5683222a3435549131a931a4c0628b775ecd3d79cb3fd597b3501418288/_data", "Type": "volume" } ]
$ ls /var/lib/docker/volumes/2afac5683222a3435549131a931a4c0628b775ecd3d79cb3fd597b3501418288/_data ping.txt
$ cat ping.txt PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=38 time=58.619 ms 64 bytes from 8.8.8.8: seq=1 ttl=38 time=58.498 ms
Dacă oprim și ștergem containerul, volumul va exista în continuare:
$ docker container stop c2 c2
$ docker container rm c2
c2
$ ls /var/lib/docker/volumes/2afac5683222a3435549131a931a4c0628b775ecd3d79cb3fd597b3501418288/_data ping.txt
O a treia metodă de a lucra cu volume în Docker este direct prin API-ul de volume, adică prin comenzi CLI de genul docker volume create, docker volume ls, etc. Dacă vrem să creăm volume pentru o stivă de servicii, acest lucru poate fi făcut în fișierul YAML folosit pentru Docker Compose, așa cum vom vedea în laboratorul 3.
Pe lângă volume, mai există și noțiunea de bind mounts. Acestea sunt similare cu volumele, dar nu sunt gestionate de Docker, ci se pot afla oriunde în sistemul de fișiere al gazdei pe care rulăm containerele, și pot fi modificate extern de orice proces non-Docker. Diferența principală dintre un bind mount si un volum este că bind mount-ul este o cale fizică de pe mașina gazdă, în timp ce volumul este o entitate Docker care utilizează, în spate, un bind mount abstractizat. În imaginea de mai jos (preluată din documentația oficială), se poate observa în mod grafic diferența dintre volume și bind mounts.
Atunci când pornim un container prin comanda docker container run, atât argumentul -v (sau –volume), cât și –mount permit utilizarea de bind mounts și volume. Totuși, în cadrul serviciilor (așa cum vom vedea în laboratorul 3), nu putem folosi decât –mount. Acesta este totuși considerat oricum mai expresiv, pentru că necesită specificarea efectivă tipului de legătura (volum sau bind mount). Astfel, exemplul anterior unde atașam un volum /test containerului pe care îl rulam ar arăta în felul următor:
$ docker container run --name c2 -d --mount source=test,target=/test alpine sh -c 'ping 8.8.8.8 > /test/ping.txt'
Pentru a verifica efectul acestei comenzi, putem rula comanda de inspectare:
$ docker container inspect -f "{{ json .Mounts }}" c2 | python -m json.tool [ { "Destination": "/test", "Driver": "local", "Mode": "z", "Name": "test", "Propagation": "", "RW": true, "Source": "/var/lib/docker/volumes/test/_data", "Type": "volume" } ]
Docker pe Windows și pe MacOS
Docker a fost creat nativ pentru Linux, utilizând componente de kernel specifice Linux, cum ar fi cgroups sau namespaces, folosite pentru a izola procese și alte componente ale sistemului de operare. Începând din 2016, el poate rula nativ și pe Windows, dar doar pentru versiunile Windows Server 2016 și Windows 10. De aceea, pentru a rula pe un sistem de operare desktop precum un Windows mai vechi sau MacOS, Docker necesită rularea virtualizată.
Pe Windows, se folosește izolare Hyper-V pentru a rula un kernel Linux cu un set minimal de componente suficiente pentru a executa Docker. Pe MacOS, Docker for Mac este o aplicație nativă care conține un hypervizor bazat pe xhyve și o distribuție minimală de Linux, peste care rulează Docker. Astfel, se oferă o experiență mult mai apropiată de utilizarea Docker pe Linux, sistemul de operare pentru care a fost creat.
Ca un exemplu, pentru a avea acces în mașina virtuală de Docker pentru MacOS, se poate folosi screen (pentru a se termina sesiunea, se folosește combinația de taste Ctrl+a, k):
$ screen /Users/<UID>/Library/Containers/com.docker.docker/Data/vms/0/tty linuxkit-025000000001:~# pwd /root
Comenzi utile
Comenzi de lucru cu un registru
$ docker login [–u <UTILIZATOR> –p <PAROLĂ>] [SERVER] # loghează un utilizator într-un registru $ docker tag <IMAGINE> <UTILIZATOR/REPOSITORY:TAG> # dă un tag unei imagini pentru upload în registru $ docker push <UTILIZATOR/REPOSITORY:TAG> # uploadează o imagine în registru
Creare și interacțiune cu rețele
$ docker network create -d <DRIVER> <REȚEA> # creează o rețea cu un driver dat $ docker network ls # afișează rețelele existente $ docker network rm # șterge o rețea $ docker network connect <REȚEA> <CONTAINER> # conectează un container la o rețea $ docker network disconnect <REȚEA> <CONTAINER> # deconectează un container de la o rețea $ docker network inspect <REȚEA> # afișează informații despre o rețea $ docker container run --network=<REȚEA> <IMAGINE> # pornește un container într-o rețea
Creare și interacțiune cu volume sau bind mounts
$ docker volume create <VOLUM> # creează un volum $ docker volume ls # afișează volumele existente $ docker volume rm <VOLUM> # șterge un volum $ docker container run -v <VOLUM> <IMAGINE> # rulează un container cu un volum atașat $ docker container run -v <SURSĂ>:<DESTINAȚIE> <IMAGINE> # rulează un container cu un volum sau un bind mount atașat $ docker container run --mount source=<SURSĂ>,target=<DESTINAȚIE> <IMAGINE> # rulează un container cu un volum sau bind mount atașat
Exerciții
Pentru exercițiile din acest laborator, veți porni de la această arhivă, care conține o aplicație NodeJS care realizează un API peste o bază de date PostgreSQL. Exercițiile de mai jos vă trec prin pașii necesari pentru a rula un container pentru o bază de date PostgreSQL și containerul cu aplicația în aceeași rețea, având persistență la oprirea containerelor.
- Pe baza surselor și a fișierului Dockerfile din arhiva de laborator, construiți o imagine cu numele api-laborator-2-image.
- Creați o rețea numită laborator2-db-network.
- Creați un volum numit laborator2-db-persistent-volume.
- Porniți un container pentru o bază de date cu următorii parametri:
- se va atașa un bind mount care va face o mapare între fișierul init-db.sql de pe mașina locală (acesta va fi sursa la flag-ul de bind mount și se găsește în arhiva de laborator) și fișierul /docker-entrypoint-initdb.d/init-db.sql din containerul care se va rula (acesta va fi destinația)
- se va atașa volumul laborator2-db-persistent-volume creat anterior (sursa) la calea var/lib/postgresql/data din containerul care se va rula (destinația)
- se va rula containerul în rețeaua laborator2-db-network creată anterior
- se vor specifica următoarele variabile de mediu (într-o comandă de docker run, acest se lucru se face astfel: docker run -e NUME=valoare):
- variabila POSTGRES_USER cu valoare admin
- variabila POSTGRES_PASSWORD cu valoarea admin
- variabila POSTGRES_DB cu valoarea books
- containerul rulat se va numi laborator2-db
- se va rula imaginea postgres din registrul oficial.
- Porniți un container cu imaginea api-laborator-2-image creată anterior, cu următorii parametri:
- se va rula containerul în rețeaua laborator2-db-network creată anterior
- se vor specifica următoarele variabile de mediu:
- variabila PGUSER cu valoare admin
- variabila PGPASSWORD cu valoarea admin
- variabila PGDATABASE cu valoarea books
- variabila PGHOST cu valoarea laborator2-db
- variabila PGPORT cu valoarea 5432
- containerul rulat se va numi laborator2-api
- containerul va expune portul 80 și îl va mapa la portul 5555 de pe mașina locală.
- Verificați că cele două containere rulează corect și au conectivitate:
- folosind Postman sau orice altă aplicație similară, realizați cereri de GET și POST pe localhost:5555/api/books
- la cererile de POST, se așteaptă un body JSON cu formatul
{"title":"titlu","author":"autor"} - cererile de GET vor returna o listă de cărți adăugate prin cereri de POST.
- Verificați că volumul pe care l-ați adăugat păstrează persistența datelor:
- opriți și ștergeți cele două containere
- reporniți cele două containere cu aceleași comenzi ca anterior
- trimiteți o cerere de GET
- dacă ați configurat corect, veți primi o listă cu cărțile adăugate anterior.
