Docker

Definicons

Imatge

Contenidor

Estats d'un contenidor

Comandes bàsiques

Docker s'utilitza amb la comanda docker mes l'eina a emprar que pot ser:

image

Gestió de les imatges

ls

pull

rm

container

[TODO]{.todo .TODO} run

  • –name="nom": Dona un nom determinat al contenidor.
  • -d: Detached fa que el contenidor corri en segon pla.
  • -p <extern>:<intern>: Mapeja un port del host (extern) cap al port del contenidor (intern).
  • -P: Publish all, publica o mapeja tots els ports exposats del contenidor a ports random del host.
  • -i -t: Interactua amb el contenidor mitjançant la tty.
  • –entrypoint=<executable>: Per sobreescriure el entrypoint de la imatge(la comanda a executar al iniciar el contenidor).
  • <imatge> paràmetres: Per sobreescriure el CMD del dockerfile.
  • –env <key>=<value>: Per sobreescriure una variable d'entorn.
  1. Gestió de recursos

    Sistemes amb gestors de paquets rpm ja ho suporten automàticament (RedHat, CentOS) però la resta no. Si al utilitzar alguna d'aquestes comandes retorna un WARNING cal activar-ho a nivell de SO editant en /etc/default/grub i afegint o modificant la següent línia:

    GRUB_CMDLINE_LINUX="cgroup_enable=memory wapaccount=1"
    

    Un cop establerts els paràmetres de restricció de recursos, si el volen canviar amb el contenidor ja creat es pot fer mitjançant la comanda:

    docker container update <paràmetres>
    
    1. Memòria

      • -m: Delimita la memòria RAM disponible per al contenidor. -m 1g
      • –memory-swap: Màxim de memòria SWAP.
      • –memory-swappiness: Percentatge de pàgines de memòria anònimes.
      • –memory-reservation: Marca la quantitat de RAM a partir de la qual s'avisarà a Docker que s'està utilitzant molta memòria. És un avis.
      • –kernel-memory: Limita memòria del nucli, valor mínim de 4m.
      • –oom-kill-disable: A menys que s'utilitzi aquesta opció, si el contenidor sobrepassa la memòria assignada el SO matarà el contenidor.
    2. CPU

      • –cpus: Numero de CPUs o nuclis que pot usar el contenidor, poden ser valors decimals (1.5). És una compactació o simplificació d'utilitzar --cpu-period + --cpu-quota.
      • –cpu-period: Temps d'ús del planificador de la CPU en microsegons.
      • –cpu~quota~: Temps d'ús de la CPU garantit al contenidor, en microsegons.
      • –cpuset-cpus: Nombre de CPUs utilitzades per el contenidor.
      • –cpu-shares: Estableix la prioritat del procés contenidor per a l'ús de cicles de la CPU.

attach

start

stop

rm

top

pause

ps

logs

inspect

ls

run

version

El DockerFile

S'utilitza per crear imatges personalitzades de docker. Cal un directori amb tots els arxius necessaris. L'únic imprescindible és el Dockerfile.

Opcions de DockerFile

Comentaris

Començats per el caràcter #.

Directives

[TODO]{.todo .TODO} Variables d'entorn

NOTA: Aquí el llibre no és clar ja que més endavant, en l'etiqueta ENV diu que les variables d'entorn es defineixen amb ARG i que aquest tan sols és visible al crear la imatge mentre ENV es manté durant la vida del contenidor. A part no torna a fer referència a aquesta manera de crear variables amb ${valor}.

``` {.bash org-language=”sh”} ENV hola=hello


Per utilitzar-la tenim dues formes:

``` {.bash org-language="sh"}
$hola
${hola}

.dockerignore

Si dins d'aquest arxiu creem patrons, directoris o rutes complertes, docker build les ignorarà. Un patró per línia podent utilitzar comodins (*?!)

FROM

Indica la imatge base, a part de les directives i el ARG és la primera instrucció del Dockerfile.

Un altre opció és crear imatges multi-fase. Aquí la idea és cobrir la necessitat d'un procés de varies etapes on la imatge final no necessita la totalitat de les imatges anteriors. Un exemple és un codi font que volem compilar en una imatge i que després voler que s'executi. A la imatge final, la APP no necessita per res el compilador, llibreries, etc. Així doncs utilitzarem dos FROM per crear varies etapes i que la imatge final sigui el més minimalista possible (ocupi el mínim espai).

FROM goland:1.9.1 AS builder
WORKDIR /go/src/github.com/libro-docker/multistge/
RUN go get -d -v gothub.com/gorilla/mux
COPY app.go .
RUN CGO_ENABLES=0 GOOS linux go build -a -installsuffix cgo -o app .
FROM alpine:latest 
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/libro-docker/multistage/app .
CMD["./app"]

Fixar-se també amb l'ús del paràmetre AS de la comanda FROM per a nombrar una fase i després poder-ne fer referència còmodament a la comanda COPY amb el paràmetre --from. Si no ho féssim així caldria indicar --from=0 ja que docker numera les fases començant per 0.

RUN

S'utilitza per llançar comandes per a la creació de la imatge. Hi han dues formes de fer-ho

RUN <comanda>
RUN ["<comanda>","<paràmetre 1>","<paràmetre 2>", ...]

El primer invoca una shell dins de la imatge i executa la comanda. Però a vegades hi han imatges que no tenen shell. El segon llança les comandes i son interpretades com una crida JSON, per tant les " son obligatòries i cal escapar les \ com sempre: \\.

CMD

Semblant a RUN s'utilitza per llançar comandes i o paràmetres per defecte. En aquest cas però no es llançaran al crear la imatge sinó al crear el contenidor. Té tres formats:

CMD["<comanda>","<paràmetre 1>","<paràmetre 2>",...]
CMD["<paràmetre 1>","<paràmetre 2>",...]
CMD <comanda> <paràmetre 1> <paràmetre 2>...

Igual que en RUN les dues primeres son interpretades com cadenes JSON mentre que el tercer es llançarà a la shell de sistema, si n'hi ha. La diferència entre el primer i el segon radica que el primer especifica una comanda o executable i el segon passara els paràmetres a la comanda especificada per ENTRYPOINT.

També cal notar que aquests paràmetres s'especifiquen com a "per defecte" i per tant poden ser modificats al llançar el contenidor, per exemple així:

Creació de imatge amb DockerFile:
FROM alpine
ENTRYPOINT ["/bin/echo","Hola"]
CMD ["pepsi-cola"]

Es crea la imatge de forma normal.
Si es llança amb "docker run --rm <imatge>" sortirà: "Hola pepsi-cola".
Si es llança amb "docker run --rm <imatge> Mundo" sortirà: "Hola Mundo".

ENTRYPOINT

Defineix la instrucció que es llançarà en iniciar el contenidor, típicament l'aplicació o servei objectiu del container. Com en casos anteriors té dues maneres de cridar-se, un com a JSON i l'altre mitjançant shell.

ENTRYPOINT ["<comanda>",<paràmetre 1>,"<paràmetre 2>",...]
ENTRYPOINT <comanda> <paràmetre 1> <paràmetre 2> ...
  1. [TODO]{.todo .TODO} Crear un script per configurar el container

    Si volem crear un script que faci la configuració final del container (per exemple configurar usuaris i passwords per una base de dades, el normal és crear un script que s'executi al entrypoint, miri si esta configurat o no i un cop feta la configuració llanci el servei. És important que el procés que generi aquest script s'associi al PID 1 per a que així pugui rebre les señals UNIX enviades al contenidor. Per fer-ho cal utilitzar la comanda exec.

LABEL

S'utilitza per afegir metadades a una imatge. Es recomana utilitzar
per afegir varis valors a una sola etiqueta LABEL

LABEL maintainer="madyyelf@gmail.com" \
      version="1.0" \
      description="Exemple d'ús etiqueta LABEL"

EXPOSE

Permet especificar els ports exposat cap a fora del contenidor, on escoltarà, i també el protocol TCP / UDP. Això permetrà també mapejar el port quan s'executi el contenidor a un port concret amb el paràmetre -p o un port aleatori amb -P. Si no es mapeja, el contenidor no serà accessible des del host. Tanmateix els contenidors que comparteixin la mateixa xarxa virtual es veuran entre ells.

Un exemple d'ús:

EXPOSE 80
EXPOSE 80/TCP

ENV

Permet definir variables d'entorn que heredaràn totes les imatges que derivin d'aquesta. A diferència de ARG, ENV es manté durant l'execució dels contenidors i per tant es pot accedir des d'ells.

ENV nom="Raul Gimenez" nick="MadElf" correu="madyyelf@gmail.com"

ADD

ATENCIÓ: Es recomanable tan sols utilitzar-ho quan volem copiar quelcom remot per URL o volem auto-descomprimir un arxiu al copiar-ho. Per la resta de casos millor utilitzar COPY pq té un comportament més previsible. S'utilitza per incloure i copiar arxius i carpetes des del sistema base (o URL) a dins de la imatge. Té moltes punyetes i per això és desaconsella, per exemple si es copia un arxiu comprimit el sistema el descomprimirà automàticament, o per exemple si el path destí no existeix es crearà sol. També cal anar amb ull amb els permisos que assigna per defecte. El origen es pren des de el directori del dockerfile i el destí des del WORKIDIR.

ADD ["/root/web/inici.html", "/var/www/html/index.html"]

COPY

Semblant a ADD però en aquest cas el comportament és el mateix que un cp normal. A més implementa una funció exclusiva i és que pot copiar coses entre imatges intermitges (les fases):

FROM golang AS builder
...
FROM alpine
...
COPY --from=builder /var/tmp/certificats/* /root/.ssh/

VOLUME

Especifica un o més punts de muntatge que poden ser configurats al llançar el contenidor o per defecte emmagatzemats. El format com sempre pot ser doble:

VOLUME /var/www/html /var/www/moodledata
VOLUME ["/var/www/html","var/www/moodledata",...]

Al crear la imatge Docker tan sols pren consciencia dels punts de muntatge, és a la creació del contenidor on l'usuari pot marca on es munten amb els paràmetres --volumen o --mount. Si no s'indica per defecte es muntarà a /var/lib/docker/volumes/{nom del volum}/_data.

USER

Per defecte els RUN, CMD i ENTRYPOINT s'executen com a usuari root i grup root. Si ho volem modificar cal utilitzar USER. ATENCIÓ: Al ser l'usuari que executa el ENTRYPOINT, i per tant el procés del contenidor, cal que sigui un usuari amb mínims permisos per evitar, que si un atacant s'escapa del contenidor tingui permisos de root al sistema amfitrió (principi de mínims permisos).

FROM busybox
USER nobody

Es recalca que es pot utilitzar la comanda USER més d'un cop per anar canviant de permisos, però es recomana minimitzar-ho fent primer tot el que requereixi root i després canviar a un usuari amb menys privilegis.

WORKDIR

És el path on s'executaràn, dins de la imatge, les instruccions CMD, ENTRYPOINT, COPY i ADD i es crearà to ti que no s'executi cap d'aquestes instruccions. Es poden especificar path absoluts i relatius i més d'una instrucció WORKDIR.

WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd

En l'exemple anterior la comanda pwd obtindrà el path /a/b/c.

ARG

Aquesta instrucció permet que l'usuari passi paràmetres alhora de crear la imatge amb la comanda docker image build. Permet establir, o no, valors per defecte.

FROM busybox
ARG user1=someone
ARG buildno

Aquí user1 tindrà per defecte el valor someone mentre buildno no té valor per defecte. ATENCIÓ: No té persistència entre capes o fases. ATENCIÓ: Ja existeixen unes variables predefinides a Docker relacionades amb Proxys.

ONBUILD

S'utilitza per llançar comandes al fer una derivada d'aquest imatge. És a dir, si es crea una imatge tenint com a base aquesta s'executaràn els ONBUILD. El format és: ONBUILD [COMANDA] I es poden utilitzar totes les comandes de Dockerfile excpete aniuar ONBUILD.

from ruby:2.4
WORKDIR /usr/src/app
ONBULD COPY Gemgile /usr/src/app/
ONBUILD RUN bundle install
ONBUILD COPY . /usr/src/app

STOPSIGNAL

Defineix la señal (codi o nom) que s'enviarà al contenidor al parar-lo. El format és:

STOPSIGNAL <signal>

HEATLHCHKECK

S'utilitza per consultar l'estat d'un contenidor, té dos formats:

HEALTHCHECK NONE
HEALTHCHECK [OPTIONS] CMD command

Les opcions poden ser

  • –interval=DURATION (default: 30s)
  • –timeout=DURATION (default: 30s)
  • –start-period=DURATION (default: 0s)
  • –retries=N (default: 3)

Es pot desactivar o definir. Si es defineix es sobreescriu el de la imatge pare. Els retorns poden ser:

  • 0: Tot OK.
  • 1: El contenidor no funciona correctament.
  • 2: Reservat.

Un exemple:

HEALTHCHECK --interval=5m --timeout=3s CMD url -f http://localhost/ || exit 1

SHELL

Permet definir la shell per defecte. Alguns exemples:

SHELL["powershell","-command"]
SHELL["cmd","/S","/C"]
SHELL["/bin/bash"]

Paràmetres

-t o –tag

Per nombrar y/o etiquetar la imatge

Recomanacions per la creació d'imatges

  • Utilitzar imatges base petites.
  • Utilitzar imatges base especialitzades.
  • Especificar versió de la imatge base.
  • Reduir el nombre d'instruccions de DockerFile: Reduir el nombre de capes.
  • Borrar arxius no necessaris: al directori de Dockerfile.
  • Aprofitar la multi-fase
  • Reduir nombre d'arxius enviats al dimoni Docker.
  • Vigilar l'ordre de les instruccions: Primer les que variïn poc, després les que introdueixin canvis sovint. D'aquesta manera les capes amb pocs canvis s'aprofiten.
  • Reutilitzar imatges.

Exemple final de Dockerfile

Com a exemple final, tot i que per depurar i millorar, el Dockerfile que he creat per a dockeritzar l'aplicació python cmanoSWB:

FROM python:2.7
RUN pip install --upgrade pip
LABEL maintainer="madyyelf@gmail.com" \ version="1.0" \ description="Petita app per cercar escenaris$
HEALTHCHECK --interval=1m --timeout=3s CMD curl -f http://localhost:4444/ || exit 1
EXPOSE 4444
WORKDIR /app
RUN groupadd -r cmanoswb && useradd --no-log-init -r -g cmanoswb cmanoswb && chown -R cmanoswb /app
VOLUME ["/app/Scenarios/"]
COPY . .
RUN ["pip","install","-r","REQUIREMENTS.TXT"]
RUN pip install flask
USER cmanoswb
ENTRYPOINT ["python","cmanoSWB.py"]

Es crea la imatge amb:

docker image build -t rgimenezh/cmanoswb:v1.0 .

I es llança el contenidor amb:

docker run -d --name cmanoswb -v /root/Documents/scenarios/:/app/Scenarios/ -p 80:4444 rgimenezh/cmanoswb:v1.0

Imatges

Baixar imatges

De forma directa amb

docker pull [<servidor>:<port>/<usuari>/]<imatge>[:<etiqueta>]

Indirectament al executar un contenidor o crear una imatge derivada.

La etiqueta latest

És la etiqueta per defecte i alhora perillosa pq si tens descarregada una imatge latest i el creador puja una nova versió (de nou latest) el teu sistema no actualitzarà pq ja té la versió que vols executar… al menys a nivell d'etiqueta!!!

Pujar imatges

Registres

O repositoris, dockerHub per defecte però tan sols deixa tenir 2 privades i la resta públiques. Son Opensource per tant en podem crear un nosaltres:

docker container run -d -p 5000:5000 --name registre registry:2

Es crea una etiqueta sobre una imatge i es puja. *No entenc pq dues instruccions, o al menys la de la etiqueta.*
docker image tag rgimenezh/nova_imatge:latest alquimiabinaria.cat:5000/rgimenezh/nova_imatge
docker push alquimiabinaria.cat:5000/rgimenezh/nova_imatge

Per recuperar la imatge
docker image pull alquimiabinaria.cat:5000/rgimenezh/imatge_nova

Esborrar i netejar repositori d'imatges

Hem de tenir present que anirem acumulant les diferents capes que composen les imatges que utilitzem/creem així com versions antigues de latest que aniran quedan orfes. Per això tenim les comandes següents:

docker image rm <imatge:tag>
docker image prune
docker image prune -a

La primera comanda elimina una imatge concreta. La segona elimina totes les imatges i capes orfes i la tercera elimina tot el que no s'estigui utilitzant per cap contenidor. ATENCIÓ: Si estem en un entorn on es creen imatges automàticament (integració i deploy) cal fer neteja de forma regular per evitar que ocupi molt espai, però fer-ho amb cap per aprofitar la reutilització de capes en la creació de noves imatges. En el llibre hi ha algun exemple més utilitzant grep per eliminar imatges concretes de forma automàtica.

Contenidors

Estats dins del cicle de vida d'un contenidor:

  • created:
  • restarting:
  • running:
  • removing:
  • paused:
  • exited:
  • dead:

Algunes comandes més interessants son:

ls

Per llistar, té varies opcions entre elles --filter que permet filtrar la sortida per varis criteris.

run / create

run crea i llança un contenidor des d'una imatge i create tan sols el crea. Les opcions més significants son:

–restart

Entre altres paràmetres un de interessant és --restart que marcarà en quins casos es reiniciarà el contenidor, les opcions suportades son:

  • no: Mai el reiniciar, és la opció per defecte.
  • on-failure: Es reinicia el contenidor si el codi de sortida del procés principal retorna !0.
  • unless-stopped: A menys que el contenidor o el procés de docker hagi estat parat de forma explicita, reiniciarà el contenidor.
  • allways: Sempre intentarà reiniciar el contendior si està parat.

–name

Anomenar un contenidor per referenciar-lo més fàcilment.

–hostname

Canvia el nom del sistema que conté el contenidor, per entrar a la tty i no liar-nos tant.

–dns

Per especificar quin DNS volem que utilitzi un contenidor, aquesta IP anirà a parar a //etc/resolv.conf/

–add-host

Per omplir entrades del //etc/hosts/ des de la creació del contenidor.

docker container run --add-host=NOMINAS_DB:10.23.0.5 -it ubuntu

Limitació de recursos

Veure apartat de Bones pràctiques de seguretat.

–mount

S'utilitza per persistència de dades o dades fora del contenidor. Depenent del type tindrem varis tipus de volumns….

docker run -d -it --mount type=bind,source="/var/dades_contenidor",target="/var/www/html" nginx

Les opcions son:

  • type: Tipus de momtatge, pot ser:

bind: Per linkar a un espai del FS del host. – volume: És la millos opció per persistència de dades, entre les seves avantatges: — Docker porta API. — Fàcils d'utilitzar, respaldar, etc… — Funcionen en Windows i linux. — Es poden compartir entre contenidor de forma més encima-li i segura. — Permeten emmagatzemament remot, al nuvol, encriptat, etc. — El contingut pot ser pre-carregat. – tmpfs: Per crear el espai compartit a la swap del host. Lògicament en parar el contenidor s'esborra tot.

  • source: Directori o fitxer origen del host.
  • destination: Directori o arxiu destí dins del contenidor.
  • readonly: Opció per fer-ho tan sols lectura.

–net

Per fer que el contenidor utilitzi una xarxa concreta.

docker container run --net=xarxa_probes1 -itd --name=contenidor_nginx nginx

rename

Per renombrar un contenidor ja creat.

port

Serveix per consultar el mapeig del ports, tot i que hi han altres forma de fer-ho com llistar els contenidors tot aplicant un filtre de format de la sortida o fent un inspect del contenidor. En aquest cas utilitzem una comanda directa de docker.

docer port amazing_barhmagupta

inspect

Mostra les metadades que docker manté sobre el contenidor en format JSON. Donat que la informació retornada és molt amplia, s'acostuma a utilitzat el paràmetre --format per filtrar els resultats. Per exemple:

docker container inspect my-server --format=""

logs

Mostra els logs del porcés dins del contenidor amb PID 1. Per això la importància de crear bé el dockerfile. Amb el paràmetre -f es queda enganxat al contenidor si està corrent i actualitza automàticament la sortida.

top

Igual que GNU/Linux mostra els processos corrent.

stats

Mostra estadístiques de Docker d'un contenidor concret o de tots si s'afegiex el paràmetre -all.

exec

S'utilitza per llançar comandes dins d'un contenidor que ja està corrent, per exemple:

docker container exec my_server cat /var/www/html/index.html

docker container exec -it my_server /bin/bash

cp

Per copiar des-de o cap al contenidor arxius. Pot ser útil si cal fer modificacions i el contenidor no té editor de textos, en comptes de instal·lar s'edita l'arxiu al host i es torna a copiar.

docker container cp my-nginx:/etc/nginx/nginx.conf ~/Desktop/

docker containser cp ~/Desktop/nginc.conf my-nginx:/etc/nginx/

export

S'utilitza per exportar TOT el sistema de fitxers d'un contenidor.

docker container export -o fs.tar my-nginx

attach

Serveix per enganxar-se a un contenidor, que bàsicament és connectar STDIN, STDOUT i STDERROR al PID 1 o ENTRYPOINT/CMD del contenidor. Cal notar aquí que amb Ctrl-C es sortirà i matarà el contenidor, si tan sols voler desenganxar-nos cal fer Ctrl-P + Ctrl-Q.

diff

Mostra els canvis realitzats als arxius del contenidor respecta la imatge original.

[TODO]{.todo .TODO} Compose

Permet definir una estructura de server interconnectats i dependents, és a dir, varis contenidors que es comuniquen i entre tots donin un servei (p.e.: Un servidor web amb WordPress, junt amb un contenidor de base de dades i un altre amb un volum per fer persistència de dades.) Tot això es defineix en un arxiu de text pla al estil de DockerFile. Les opcions i paràmetres que podem configurar son molt i per aquest motiu deixo aquí un enllaç. Un exemple d'ús per muntar un servei de WordPress amb dos contenidors, un per el Apache i l'altre per MySQL i a més tenir les dades de la base de dades en un volum per donar-hi persistència, seria aquest:

version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
volumes:
    db_data:

Aquí deixo també una cerca a GitHub on podrem trobar varis exemples més d'arxius de Compose per muntar varis serveis, alguns d'ells força el·laborats. ATENCIÓ: Donada la complexitat i opcions no s'ha fet apunts. Cal investigar i ordenar la informació per Internet ja que el llibre no aprofundeix res i tan sols dona alguns exemples. Comentar l'opció replicas per a docker swarm.

Xarxes

En principi Docker crea una interfície virtual anomenada docker0 amb IP 172.17.0.01/24. Si mirem quines xarxes crea docker internament veurem que son tres (amb la comanda docker network ls:

  • Bridge: Que va associada a la xarxa de tipus bridge que crea docker internament i és on es connecten tots els contenidors.
  • Host: Que va associada a eth0 del host i seria quelcom com a VirtualBox d'adaptador pont.
  • None: s'utilitza com a xarxa per interfícies lo.

En crear un contenidor es creen dues interficies virtuals més per a ell:

  • La primera va associada a la subxarxa de docker0 i serà la eth0 al contenidor.
  • La segona serà un lo.

Tipus de xarxes

A docker podem crear diferent tipus de xarxes per a assignar als contenidors depenent de si els volem comunicar entre ells, que tinguin sortida o no, aïllar-los, agrupar-los, etc.:

  • bridge: Dins del mateix host es crea un name space especific i es connecten aquí tots els contenidors, quedant aïllats del host i exposant tan sols els ports concrets amb un NAT (com a VirtuaBox).
  • host: Dins del mateix host es fa servir directament el name space del host quedant directament exposat el contenidor, seria un adaptador pont de VirtualBox.
  • overlay: Per comunicar contenidors entre diferents hosts, especialment en mode swarm. Permet opcions de xifratge de comunicacions.
  • macvlan: Com el bridge però en aquest cas ens permet crear vLans i per tant seccionar subxarxes de contenidors separats.

Comanda network

La comanda docker network s'utilitza per gestionar les xarxes. Les seves opcions son:

ls

Per llistar les xarxes.

create

Per crear noves xarxes

docker network create --driver=bridge --subnet=10.1.1.0/24 --gateway 10.1.1.254 xarxa_proves1
docker network create --driver=bridge --subnet=192.168.1.0/24 --gateway 192.168.1.1 xarxa_proves2

connect

Si un contenidor està en execució i volem afegir-lo a una xarxa.

docker network connect xarxa_probes1 wp_container

disconnect

La inversa que connect.

rm

Per eliminar una xarxa.

[TODO]{.todo .TODO} Enllaçar contenidors {#enllaçar-contenidors}

(No està gens explicat al llibre, cal investigar més) També existeix una manera especial de connector contenidors i és enllaçant-los. D'aquesta manera els contenidors no és necessari exposar els contenidors a cap xarxa per a que es puguin comunicar i l'enllac és unidireccional. Al utilitzar-ho és crea una entrada al arxiu etc/hosts del equip amb el alies corresponent.

docker container run -it --name apache3 --link apache2:alias_apache2 httpd /bin/bash

Swarm

Tot i que DockerSwarm ve integrat en Docker per fer l'orquestració i clustering de contenidors, és Kubernetes de Google i la Cloud Native Computing Fundation qui s'ha convertit en l'estàndard. Així doncs Swarm gestionarà un cluster de servidors Docker i mantindrà/modificarà la configuració dels contenidors depenent l'indicat. Això vol dir que si volem aixecar tres servidors web per absorbir la càrrega de treball i un equip falla, Swarm s'ocuparà automàticament d'aixecar els docker caiguts en un altre equip per mantenir tres contendiros funcionant. Existeixen dos tipologies de nodes a Swarm, tanmateix un node pot realitzar tots dos rols alhora si es vol:

  • Manager: Responsable de gestionar el Swarm.
  • Worker: Treballador sense gestió.

A Swarm també existeix el concepte de Compose però en aquest entorn s'anomena Stack. Adicionalment Docker Swarm crea varis "serveis interns" com son un balancejador de càrrega, un servei DNS per fer descobriment de serveis…

Comandes

Algunes comandes per gestionar Docker Swarm son:

docker-machine

Per gestionar màquines virtuals des de Docker, no és necessari però pot ser útil per fer proves

  1. docker-machine create

    Serveix per crear màquines virtuals, no és necessari per fer un swarm però pot anar bé per fer proves.

  2. docker-machine ls

    Per llistar le màquines virtuals creades.

  3. docker-machine ssh

    Per entrar per ssh a una màquina virtual.

  4. docker-machine rm

    Per eliminar màquines virtuals.

docker swarm

Per gestionar el swarm.

  1. init

    S'utilitza per crear i inicialitzar un swarm. Es pot especificar l'adreça de gestió del swarm. Retorna el token necessari per poder afegir els treballadors al swarm.

    docker swarm init --advertise-addr 192.168.99.100
    
  2. join

    S'utilitza per crear un treballador i afegir-lo a un swarm existent.

    docker swarm join --token <token>
    
  3. leave

    Per sortir del swarm on està el node, tan sols poden sortir de forma norlmat els que tenen rol de worker. La forma correcta és desmpromocionar i després sortir.

    docker swarm leave
    

    El últim node d'un swarm, sempre Manager, no es podrà des-promocionar. Per eliminar-lo i per tant eliminar l swarm cal utilitzar el paràmetre --force.

docker node

Per gestionar els nodes del swarm.

  1. ls

    Per llistar els nodes del swarm.

    docker node ls
    
  2. promote / demote

    Serveixen per promocionar o des-promocionar un node a manager

    docker node promote worker1
    docker node demote worker1
    
  3. update

    Update serveix per actualitzar algun paràmetre d'un node. En concret és interessant per modificar l'estat d'aquest. Els nodes poden tenir tres estats:

    • Active: Funcionament normal, corre serveis i accepta nous serveis.
    • Pause: No accepta noves assignacions, però les actuals continuen corrent.
    • Drain: No accepta noves assignacions i les actuals son parades.

    Per canviar els estats:

    docker node update --availability drain worker2
    

docker service

Per gestionar el serveis o treballs que s'executen dins d'un cluster.

  1. create

    Per crear un nou servei.

    docker service create --replicas 3 --name webserver nginx:alpine
    

    Es poden passar configuracions i secrets alhora de crear el servei:

    docker service create --name mynginx --config my_config --secret my_secret nginx:alpine
    
  2. ls

    Per llistar el serveis que s'estan executant en el cluster.

  3. scale

    Permet escalar o des-escalar un servei en funcionament, indicant les repliques que volem.

    docker service scale webserver=2
    
  4. rm

    Per eliminar un servei.

docker stack

Com s'ha comentat anteriorment stack és a docker swarm el que compose a docker, permet la definició de serveis complexos, que treballen de forma conjunta compartit recursos i dependències i que permetrà escalar-los i orquestrar-los de forma conjunta. Stack utilitza la mateixa configuració que Compose, per tant és tot aplicable aquí. Un exemple d'arxiu yml que desplega 5 imatges de servidor web i un contenidor per visualitzar el cluster és aquest:

version: "3"
services:
  web:
    image: nginx:alpine
    deploy:
      replicas: 5
      resources:
        limits:
      cpus: "0.1"
      memory: 50M
    restart_policy:
      condition: on-failure
    ports:
      - "80:80"
    networks:
      - webnet
  visualizer:
    image: dockersamples/visualizer:stable
    ports:
      - "8080:8080"
    volumes:
      - "var/run/docker.sock:/var/run/docker.sock"
    deploy:
      placement:
        constraints: [node.role == manager]
    networks:
      - webnet
networks:
  webnet:
  1. deploy

    Per desplegar els serveis definits en un arxiu de compose .yml.

    docker stack deploy -c docker-compose.yml mystack
    
  2. ps

    Per veure l'estat de les tasques d'un stack concret.

    docker stack ps mystack
    
  3. rm

    Per eliminar un stack sencer.

Configuracions i secrets

La idea aquí és separar les configuracions i els secrets de la creació d'imatges de la imatge en si mateixa, de manera que podem fer imatges genèriques i incorporar aquests dos conceptes en la creació del servei o contenidor. La diferència entre una configuració i un secret és que la primera s'emmagatzema en text pla i la segon en un text encriptat i tan sols hi poden accedir els serveis associats. Els secrets tan sols estan disponibles des de swarm i actualment no poden superar els 500Kb. Per gestionar-los tenim:

docker config

  1. create

    Per crear una configuració:

    echo "la meva configuracio" | docker config create my_config
    
  2. rm

docker secret

  1. create

    Per crear un secret

    echo "el meu secret" | docker secret create my_secret
    
  2. rm

Bones pràctiques de seguretat

Partició apart per a /var/lib/docker

Dins del host, per evitar que Docker es mengi el disc i bloquegi el host, cal separar la carpeta /var/lib/docker que és on s'emmagatzemen les imatges i contenidors.

[TODO]{.todo .TODO} Limitar usuaris que poden utilitzar Docker. {#limitar-usuaris-que-poden-utilitzar-docker.}

Per defecte el dimoni de Docker requereix root per ser gestionat. Tanmateix un usuari que s'afegeixi al grup docker podria crear un contenidor i mapejar l'arrel del sistema com a volum tenint accés a aquest amb permisos de root, fent una elevació de permisos de forma efectiva sobre el host. Per evitar-ho podem activar l'autenticació d'usuaris a Docker mitjançant certificats digitals. Per habilitar-ho s'ha d'habilitar l'autenticació TLS al llançar el dimoni de Docker. A partir d'aquí també es podran utilitzar diferents plugins d'autentificació.

dockerd --tlsverify --tlscacert=ca.cert --tlscert=server-cert.prm --tlskey=server-key.prm -H=0.0.0.0:2376

A partir d'aquí si un client es vol connectar al dimoni necessitarà un certificat vàlid i correctament configurat en el seu "~./docker". Per fer-ho de forma genèrica cal:

mkdir -pv ~/.docker
cp -v {ca,cert,key}.pem ~/.docker
export DOCKER_HOST=tcp://localhost:2376 DOCKER_TLS_VERIFY=1 #Per a dimonis Docker locals

Auditar arxius de Docker

Com que Docker corre amb permisos de root és bona idea auditar els canvis en els seus arxius i la seva activitat. A Linux existeixen el Linux Audit Daemon que permet, entre d'altres:

  • Auditar accessos i modificacions d'arxius.

– Veure qui modifica un arxiu en particular. – Detectar canvis no autoritzats.

  • Monitoritzar syscalls.
  • Detectar anomalies, com finalitzacions abruptes de processos.
  • Establir trampes per a detectar intrusos.
  • Registrar les comandes executades per diferents usuaris.

Configurar dimoni dockerd

Deshabilitar la visibilitat de xarxa entre contenidors per defecte

Per defecte els contenidors que creem formaran part de la mateixa xarxa i per tant es podran veure entre ells i realitzar atacs (MitM). Si volem deshabilitar-ho, i que tan sols formin part de la mateixa xarxa els contenidors que així ho fem constar expressament, cal utilitzar la següent opció al llançar el dimoni de docker.

dockerd --icc=false

Cal fer notar però que tot i així els contenidors tindran accés als ports oberts del host local.

Permisos a usuaris

Docker dona permisos totals als usuaris que tenen accés a ell mitjançant el grup docker o, si s'ha activat l'autentificació, a aquells que s'han autenticat amb certificat com s'ha explicat més amunt. Si volem granular més els permisos (qui pot llançar contenidors, o fer pull d'imatges, etc) haurem d'utilitzar pluguins extres que ens ho permetin. Un exemple de pluguin en aquest aspecte podria ser Twistlock.

Gestió remota/centralitzada de logs

Per extreure els logs dels contenidor, i després reportar-los a un servidor central, tenim varies opcions:

  • docker logs i docker service logs: Ens permetran extreure els logs del STDOUT i STDERR tant d'un contenidor com d'un servei (compose).
  • dockerd –log-driver: Permet especificar al dimoni de docker el driver de logs a utilitzar per els contenidors. Els disponibles son:

– none – json-file – syslog – journald – gelf – fluentd – awslogs – splunk – etwlogs – gcplogs

  • dockerd –log-level: Permet especificar el nivell de logs enviat al log-driver:

– info – warn – error – fatal

Independència dels contenidors i del dimoni dockerd

Quan el dimoni dockerd mor, per qualsevol motiu, els contenidors també moren sigui quina sigui la seva política de re-inici. Per evitar-ho podem utilitzar el següent paràmetre al cridar el dimoni:

dockerd --live-restore

D'aquesta manera el que aconseguim és que si el dimoni mor, els contenidors continuïn funcionant i quan detectin de nou el dimoni funcionant es re-connectin, aconseguint la independència entre aquests elements.

Permisos recomanats en arxius de configuració

Arxiu Usuari:Grup Permisos ————————————————— ————- ——————– docker.service root:root 644 o + restrictiu docker.socket root:root 644 o + restrictiu /etc/docker root:root 755 o + restrictiu daemon.json root:root 644 o + restrictiu /etc/default/docker root:root 644 o + restrictiu Certificat del registre docker root:root 444 o + restrictiu Certificat CA del TLS root:root 444 o + restrictiu Certificat del servidor docker root:root 444 o + restrictiu Clau privada del certificat de servidor de docker root:root 400 Socket de docker root:docker 660 o + restrictiu

Configuració d'imatges i arxius Dockerfile

Execució de contenidors amb usuari no root

Per defecte els contenidors s'executen amb l'usuari root. Per tant és recomanable al crear la imatge definir un usuari amb permisos adequats i que sigui aquest l'encarregat de llançar el servei. Això ja està explicat a l'apartat de Deockerfile.

[TODO]{.todo .TODO} Signatura d'imatges

Permet signar les imatges al publicar-les i també verificar les signatures d'imatges descarregades. Bàsicament calen dues variables d'entorn:

export DOCKER_CONTENT_TRUST=1 # Per activar la verificació de les capes i la seva signatura.
export DOCKER_CONTENT_TRUST_SERVER="https://notary.docker.io/" # Servidor d'autenticació de les signatures.

Eliminació de permisos de setuid i setgid

Aquests son uns permisos especials que permeten executar aplicacions amb permisos de root a usuaris que no ho son, per fer tasques específiques. Així doncs és recomanable eliminar aquests permisos de la imatge. Per fer-ho:

RUN find / -perm +6000 -type f -exec chmod a-s {} \; || true

Amb això eliminarem tots aquests permisos d'arxius executables, però compte pq potser eren necessaris. Per tant cal fer-ho amb cap.

COPY en comptes de ADD

Com que ADD afegeix comportaments extres com descarregar arxius de URL remotes i/o descomprimir de forma automàtica arxius amb extensions conegudes, es recomana utilitzar COPY per tenir més "controlat" i present el comportament de la comanda. Es recomana per descarregar arxius remots (amb URL) utilitzar wget o curl i així concatenar més comandes en la mateixa instrucció RUN de manera de configurin tan sols una nova capa en el contenidor.

No emmagatzemar secrets al Dockerfile

Com que el contingut del Dockerfile pot ser revisat des del propi contenidor fent un docker history, i de fet és normal publicar el Dockerfile al Docker Hub, és recomanable no incloure-hi secrets (passwords, certificats, etc). Una manera de solucionar-ho és utilitzar una eina d'orquestració (com Docker Swarm o Kubernetes) que aprovisioni els secrets als nous contenidors. Un altre manera d'aprovisionar seria incorporar un script al Dockerfile per a que el contenidor utilitzi un servei d'aprovisionament Key Management Service com per exemple Lemur de Netflix o Vault de HashiCorp.

Contenidors en temps d'execució

Habilitar SELinux/AppArmor

Tots dos aïllen els processos dins del sistema. Les seves principals diferències son:

  1. SELinux

    SELinux permet mitjançant regles complexes implementar restriccions d'accés als diferents objectes del sistema i implementar de forma complerta diferents paradigmes de seguretat. SELinus s'aplica per defecte a tot el sistema. En aquest cas per llançar docker amb SELinux cal fer dos passos:

    # Primer llançar el dimoni habilitant SELinux
    dockerd --selinux-enabled
    # Després llançar el contenidor amb una determinada opció de seguretat
    docker container run -it --security-opt lavel=level:TopSecret centos /bin/bash
    
  2. AppArmor

    AppArmor té un enfocament semblant però molt més simplista especificant permisos mínims a cada procés per definir que pot i que no pot fer. AppArmos s'aplica a determinats processos.

    docker container run -it --security-opt apparmor=docker-default centos /bin/bash
    

Restringir capabilitis del contenidor

Per defecte els contenidors tenen permís per executar determinades operacions com a root sobre el Kernel de sistema. Si un contenidor en necessita menys és recomanable deshabilitar-les al llançar-lo (també es poden afegir. Les opcions son --cap-drop i --cap-add respectivament i les capabilities que per defecte tenen actius els contenidors son:

Capability Descripció —————— ————————————————————————————————————————————— AUDIT~WRITE~ Escriure als registres logs d'auditoria del kernel. CHOWN la comanda DAC~OVERRIDE~ Bypass de les comprovacions de permisos d'un arxius. FOWNER Bypass de les comprovacions de permisos de propietari UID. FSETID No modifica els permisos setuid i setgid al modificar un arxiu. KILL Bypass de comprovació de permisos per enviar senyals de sistema. MKNOD com la comanda. NET~BINDSERVICE~ Permet enllaçar un servei a un socket privilegiat (<=1024). NET~RAW~ Permet us de socket raw i socket packet. SETFCAP Permet establir capabilities d'un arxiu. SETGID Mapeja GID a namespace d'usuari. SETPCAP Si un arxiu no té capabilities afegeix o elimina les capabilities al conjunt de permeses del invocant a/desde qualsevol procés ¿? SETUID Permet mapejar UID al namespace del usuari. SYS~CHROOT~ Ús de chroot.

No permetre l'execució de contenidors privilegiats

Resumit és no executar contenidors amb el paràmetre --privileged al llançar el docker container run. Aquest paràmetre fa que el contenidor tingui totes les capabalities i per tant pugui fer amb el Kernel tot el que el propi host pot fer.

SSH no permès dins dels contenidors

És molt des-aconsellable que els propis contenidors tinguin un servidor SSH executant-se per gestionar-los. El motiu simplement és l'escalada de complexitat i gestió de la infraestructura. Per a accedir remotament a un contenidor el procediment habitual seria connectar-se per SSH al host i des d'allà accedir a una shell del contenidor desitjat.

No mapejar ports privilegiats dins del contenidors

No associar ports per <=1024 a menys que implementin els serveis associats a aquests ports. ATENCIÓ: En el llibre no explica pas la raó, ni a nivell operatiu ni a nivell de seguretat per aquesta mesura, més enllà de mantenir la coherència d'aquests ports.

Assegurar que le namespace de xarxa host no es compartit

Llançar un contenidor amb el paràmetre --network=host implica que el contenidor tindrà accés directe i pla a totes les interfícies de xarxes amb les implicacions de seguretat que això comporta. Per tant és recomanable no utilitzar aquesta opció al llançar un contenidor sempre que es pugui evitar.

Limitar el us de recursos dels contenidors com RAM i CPU

Donat que per defecte al llançar un contenidor aquest no té limit en l'ús dels recursos del sistema, això podria provocar la consumició total d'aquestos i provocar un DoS. Per evitar-ho cal utilitzar paràmetres en el llançament dels contenidors per a limitar l'ús dels recursos del sistema per part del contenidor. Si invoquem l'ajuda de docker container run podrem veure varies opcions per fer això:

docker container run --help

Usage:  docker container run [OPTIONS] IMAGE [COMMAND] [ARG...]

Run a command in a new container

Options:
      --add-host list                  Add a custom host-to-IP mapping
                                       (host:ip)
  -a, --attach list                    Attach to STDIN, STDOUT or STDERR
      --blkio-weight uint16            Block IO (relative weight),
                                       between 10 and 1000, or 0 to
                                       disable (default 0)
      --blkio-weight-device list       Block IO weight (relative device
                                       weight) (default [])
      --cap-add list                   Add Linux capabilities
      --cap-drop list                  Drop Linux capabilities
      --cgroup-parent string           Optional parent cgroup for the
                                       container
      --cidfile string                 Write the container ID to the file
      --cpu-period int                 Limit CPU CFS (Completely Fair
                                       Scheduler) period
      --cpu-quota int                  Limit CPU CFS (Completely Fair
                                       Scheduler) quota
      --cpu-rt-period int              Limit CPU real-time period in
                                       microseconds
      --cpu-rt-runtime int             Limit CPU real-time runtime in
                                       microseconds
  -c, --cpu-shares int                 CPU shares (relative weight)
      --cpus decimal                   Number of CPUs
      --cpuset-cpus string             CPUs in which to allow execution
                                       (0-3, 0,1)
      --cpuset-mems string             MEMs in which to allow execution
                                       (0-3, 0,1)
  -d, --detach                         Run container in background and
                                       print container ID
      --detach-keys string             Override the key sequence for
                                       detaching a container
      --device list                    Add a host device to the container
      --device-cgroup-rule list        Add a rule to the cgroup allowed
                                       devices list
      --device-read-bps list           Limit read rate (bytes per second)
                                       from a device (default [])
      --device-read-iops list          Limit read rate (IO per second)
                                       from a device (default [])
      --device-write-bps list          Limit write rate (bytes per
                                       second) to a device (default [])
      --device-write-iops list         Limit write rate (IO per second)
                                       to a device (default [])
      --disable-content-trust          Skip image verification (default true)
      --dns list                       Set custom DNS servers
      --dns-option list                Set DNS options
      --dns-search list                Set custom DNS search domains
      --entrypoint string              Overwrite the default ENTRYPOINT
                                       of the image
  -e, --env list                       Set environment variables
      --env-file list                  Read in a file of environment variables
      --expose list                    Expose a port or a range of ports
      --group-add list                 Add additional groups to join
      --health-cmd string              Command to run to check health
      --health-interval duration       Time between running the check
                                       (ms|s|m|h) (default 0s)
      --health-retries int             Consecutive failures needed to
                                       report unhealthy
      --health-start-period duration   Start period for the container to
                                       initialize before starting
                                       health-retries countdown
                                       (ms|s|m|h) (default 0s)
      --health-timeout duration        Maximum time to allow one check to
                                       run (ms|s|m|h) (default 0s)
      --help                           Print usage
  -h, --hostname string                Container host name
      --init                           Run an init inside the container
                                       that forwards signals and reaps
                                       processes
  -i, --interactive                    Keep STDIN open even if not attached
      --ip string                      IPv4 address (e.g., 172.30.100.104)
      --ip6 string                     IPv6 address (e.g., 2001:db8::33)
      --ipc string                     IPC mode to use
      --isolation string               Container isolation technology
      --kernel-memory bytes            Kernel memory limit
  -l, --label list                     Set meta data on a container
      --label-file list                Read in a line delimited file of labels
      --link list                      Add link to another container
      --link-local-ip list             Container IPv4/IPv6 link-local
                                       addresses
      --log-driver string              Logging driver for the container
      --log-opt list                   Log driver options
      --mac-address string             Container MAC address (e.g.,
                                       92:d0:c6:0a:29:33)
  -m, --memory bytes                   Memory limit
      --memory-reservation bytes       Memory soft limit
      --memory-swap bytes              Swap limit equal to memory plus
                                       swap: '-1' to enable unlimited swap
      --memory-swappiness int          Tune container memory swappiness
                                       (0 to 100) (default -1)
      --mount mount                    Attach a filesystem mount to the
                                       container
      --name string                    Assign a name to the container
      --network string                 Connect a container to a network
                                       (default "default")
      --network-alias list             Add network-scoped alias for the
                                       container
      --no-healthcheck                 Disable any container-specified
                                       HEALTHCHECK
      --oom-kill-disable               Disable OOM Killer
      --oom-score-adj int              Tune host's OOM preferences (-1000
                                       to 1000)
      --pid string                     PID namespace to use
      --pids-limit int                 Tune container pids limit (set -1
                                       for unlimited)
      --privileged                     Give extended privileges to this
                                       container
  -p, --publish list                   Publish a container's port(s) to
                                       the host
  -P, --publish-all                    Publish all exposed ports to
                                       random ports
      --read-only                      Mount the container's root
                                       filesystem as read only
      --restart string                 Restart policy to apply when a
                                       container exits (default "no")
      --rm                             Automatically remove the container
                                       when it exits
      --runtime string                 Runtime to use for this container
      --security-opt list              Security Options
      --shm-size bytes                 Size of /dev/shm
      --sig-proxy                      Proxy received signals to the
                                       process (default true)
      --stop-signal string             Signal to stop a container
                                       (default "SIGTERM")
      --stop-timeout int               Timeout (in seconds) to stop a
                                       container
      --storage-opt list               Storage driver options for the
                                       container
      --sysctl map                     Sysctl options (default map[])
      --tmpfs list                     Mount a tmpfs directory
  -t, --tty                            Allocate a pseudo-TTY
      --ulimit ulimit                  Ulimit options (default [])
  -u, --user string                    Username or UID (format:
                                       <name|uid>[:<group|gid>])
      --userns string                  User namespace to use
      --uts string                     UTS namespace to use
  -v, --volume list                    Bind mount a volume
      --volume-driver string           Optional volume driver for the
                                       container
      --volumes-from list              Mount volumes from the specified
                                       container(s)
  -w, --workdir string                 Working directory inside the container

Docker Swarm

Respecte a Swarm es recomana principalment dues coses:

  • Que existeixi el nombre mínim de nodes Manager.
  • Que la comunicació entre nodes vagi xifrada.

Docker becnh security

Es tracta d'un script que realitza una bateria de proves per verificar si s'estan duent a terme les bones pràctiques de seguretat que es consideren estàndard a Docker. El projecte el podrem trobar a aquí.

SecDevOps

Dintre del entorn de DevOps l'apartat de seguretat ha de garantir varies coses com per exemple:

  • El bon funcionament del procés de Integració - Delivery - Deployment).
  • Seguretat de la nova aplicació.
  • Seguretat de la infraestructura que suporta l'aplicació.

Anàlisis de les imatges estàtic i dinàmic

Entenent que els dos últims punts venen encapsulats a Docker es recomana utilitzar tant anàlisis estàtic com dinàmic de les imatges generades. Existeixen varies eines per fer això, tanmateix la que més punts cobreix actualment i és Open Source.

  • Recopilació de vulnerabilitats de diferents fons.
  • Anàlisis de paquets i llibreries instal·lades des dels repositoris del sistema.
  • Anàlisis amb ClamAV dels executables i llibreries de tercers.
  • Anàlisis del DockerFile.
  • Anàlisi estàtic de imatges.
  • Anàlisis remot de imatges (des de repositoris).
  • Anàlisis de contenidors en execució.
  • Anàlisis de les syscall de contenidors en execució a la cerca de comportaments anòmals.

Signatura d'imatges

Un cop verificada la imatge, tot i que es generis Hash tant de la imatge com de les capes, cal xifrar i signar la imatge. Per fer-ho és recomana Notary que permet la gestió i publicació continguts signats de qualsevol tipus.

Servei de registre propi

Si es munta un registre privat d'imatges cal tenir en compte els conceptes tradicionals d'aquest tipus de servei:

  • Certificats digitals.
  • Comunicacions xifrades.
  • Autenticació d'usuaris.
  • Registres i logs d'ús.
  • etc.

Derivats emergents

S'està coent diferents projectes que utilitzen Docker per crear sistemes modulars i totalment personalitzables que responguin a diferents necessitats. Exemples com:

  • Moby Project: Per crear sistemes de gestió de contenidors personalitzats.
  • InfraKit: Orquestació d'infraestructures.
  • LinuxKit: LinuxKit, a toolkit for building custom minimal, immutable Linux distributions.
  • BuildKit: BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner.
  • Containerd: containerd is an industry-standard container runtime with an emphasis on simplicity, robustness and portability
  • SwarmKit: A toolkit for orchestrating distributed systems at any scale.

Enllaços d'interès

  • Play with docker: Web on poder fer proves amb Docker.
  • Katacoda: Web amb cursos per aprendre varies tecnologies, especialment molt de Docker. Té unes shells interactives i guiades on anar fent exemples i aprendre, molt pràctic i concís.