Containers + DevOps + Microservices + Kubernetes Flashcards
Da cosa sono composti le software units? Cosa sono i linking e a cosa servono?
Quali sono i tradeoff tra Linking statico e quello dinamico?
Quali sono le problematice dei pacchetti che contengono i software dell’installazione?
Le componenti di un software sono:
- Processi: con codice statico. e status dinamico (registri, memoria e risorse allocate)
- Codice statico: programmi, libs e linking statico e dinamico
- Pacchetti sw
____
I programmi utilizzano repository di codice aggiuntivi come librerie di funzioni comuni e per questo utilizziamo 2 tipi di linking:
- Statico : i simboli vengono risolti dal linker in compile time come i file
- .o Oggetto creato dal compilatore
- .a Librerie
- Dinamico: risolti dal linker ma si sommano i tempi di compilazione con quelli di binding in runtime.
- .o object
- .a stub libreria
- .so oggetti condivisi
__
Linking statico ha file eseguibili grandi mentre quello dinamico piccoli, nel primo caso interagiamo solo con il kernel, non ci sono dipendenze durante l’installlazione e va ricompilato per aggiornare, mentre nel secondo caso, lavoriamo con oggetti condivisi, dipende dalla disponibilità delle librerie, si possono aggiornare le librerie anche senza toccare l’eseguibile.
es. static -> distro linux
____
Per i pacchetti che contengono sw come .apk o .dev contengono metadati sulle librerie e possono soffrire di grafo delle dipendenze complesso, conflitti e problemi d’aggiornamento delle dipendenze.
Che cosa sono i container? Cosa permettono di fare?
Su cosa si basano i container
Quali sono le differenze con le VM?
Quali sono i vantaggi e selling point dei container?
I container sono unità softwareche operano sull’OS dell’host. Non hanno bisogno di essere adattati all’ambiente host.
__
I container permette il trasferimento di software auto contenuto (librerie, config e file) facile da condividere e installare.
__
E’ basato su chroot dove un processo crea dei child che lavorano con un root dir diversa, inoltre c’è anche il jail per l’isolamento di rete dell’intero stack. Però isola a livello di filesystem non di risorse. Usiamo namespace che isolano i processi su più livelli e cgroups che sono meccanismi del kernel per l’allocazione delle risorse. I processi nello stesso namespace vedono la stessa immagine del file system
__
I container hanno un astrazione a livello OS, eseguito nello stesso OS dell’host con utilizzo di memoria e start up minime.
___
I container sono utili perchè sono autocontenuti e possono essere eseguiti su diversi sistemi (portabilità), da supporto allo sviluppo DevOps aggiungendo solo config e codice inerente al servizio, hanno tempo di avvio rapido, isolati anche a livello di prestazioni, efficienti, sono isolati quindi non c’è propagazione di codice dannoso, inoltre sono facili da gestire il ciclo di vita, rete e gestione dell’archiviazione.
Esempi:
* Docker
* Kubernetes (Google)
Che cos’è il DevOps?
Quali sono le best practice del DevOps?
Qual’è il rapporto con il paradigma a microservizi?
Il DevOps consiste nel creare un processo contiguo tra Development e Operations, che permette il design, l’aggiunta e testing di features a un’applicazione in modo seamless. Questo permette lo sviluppo e feedback rapido con cicli brevi “sprint” e l’aggiunta di testing automatizzato. In questo modo abbiamo un applicazione a cui viene fatta la release in tempi brevi e senza problemi. Inoltre è facile da scalare ed è sicuro con un controllo fine.
Ogni volta che aggiorniamo testiamo in locale e poi facciamo commit che deve essere convalidato.
Facciamo una integrazione continua nella code base(CI), delivery (testing e approvazione) e distribuzione continua (resa disponibile allo user in automatico post approvazione).
___
Le best practice del Dev Ops sono le seguenti:
- IaaS -> sicuro e affidabile, definiamo l’infrastruttura tramite codice
- Monitoraggio e logging (traceability)
- Infrastructure as code: usiamo file per configurare networking (nat..), replicas, policies
es. il deployment fallisce se manca una lib in requirements.txt
- Policy as Code: check durante il build time per rilevare le non compliance e possiamo prendere certificati come PCIDSS per pagamenti o HIPAA per privacy sanitaria
- Monitoring automatizzato in modo cost effective, oppure analisi in run time e post mortem per gestione di problemi e crash
___
I microservizi hanno un vantaggio rispetto ai monoliti perchè non mi devo sposare a una sola tecnologia, ho release brevi, test brevi e riesco a scalare. Si basa su una comunicazione HTTP-based API.
Abbiamo un singolo elemento da sviluppare e gestire, se si schianta, schianta solo lui e non tutto il monolite. Abbiamo meno rischi e l’applicazione non diventa una big ball of mud di dependencies.
Cos’è Docker?
Cos’è containerd?
Com’è l’architettura Docker?
Quali sono gli stati di un container?
Docker è un software per la gestione dei container e del loro ciclo di vita. L’engine è di Docker, la gestione da parte di containerd, Data management dai file system. Docekr ha le seguenti funzionalità:
- costruzione container
- gestione container
- run dei container
Containerd è un tool per la gestione dei container usato da Docker e Kubernetes. Il suo compito è di eseguire container con runc, gestione delle immagini e fare push e pull ai registri. Si occupa solo di questo ed espone i suoi servizi tramite API. E’ composto da layers per isolare migliorare la portabilità tra container runtime e OS.
E’ composta da daemon dockerd, client che invoca i servizi chiesti da daemon tramite rest API e registry.
Running, stopped, paused, created.
Come funziona Docker Compose?
Docker Swarm?
Com’è l’architettura di swarm
Docker compose è un un estensione di Docker che permette di creare un ecosistema multi container tramite la dichiarazione di file YAML(gerarchico tramite ident), da esso possiamo definire varie policy come la rete, volumes, replicas e altro.
______
Docker Swarm è un software d’orchestrazione, a livello dihiarativo definisce il deployment e ha meccanismi di state reconcilitation, inoltre ha le seguenti funzioni:
- Service Discovery DNS
applicare meccanismi di service discovery tramite DNS server integrato e discovery tramite nomi univoci dei nodi.
- Load Balancing: Built in nella gestione di rete, possiamo bilanciare il carico e possiamo definire il mapping sui nodi, possiamo usare diverse policy
- Scaling: automatico per ogni servizio
- Networking multi host: connessioni su più nodi tramite overlay network, la config è automatica
- Sicurezza: Sicuro con comunicazioni criptate e TLS
- Rolling updates: Aggiornamenti incrementali per evitare butst di traffico sugli host/volumi/registry
Un Swarm è una rete di nodi che sta all’interno di un host che può essere:
- Worker: Esegue i servizi swarm, riceve ed esegue tasks (che sono anche monitorati).
- Manager: Manda in esecuzione i servizi swarm, conosce la descrizione per il deployment e distribuisce tasks (a volte funziona anche come worker)
E’ possibile avere più nodi per macchina.
Come funziona Kubernetes?
In cosa consistono le componenti di kubernetes?
Kubernetes è un software per la orchestrazione dei container organizzato in clusters, cioè nodi master e worker. Pensato per datacenters.
Kubernetes ha funzioni auto riparanti rileva guasti di un container come crash o controlli definiti dall’utente. Permette di orchestrare volumi and montare anche dal cloud, load balancing, DNS, rete, rollback e rollout per il desired state, supporta anche la creazione e rimozione dei container nonchè la migrazione delle risorse dei vecchi container.
Abbiamo:
- Nodi: server fisico o virtuale, si coordinano per la distribuzione dei container
- Deployment: 1 o più pod, possono contenere un replica set
- Replica set: set di pod uguali, il numero può cambiare per scalability.
- Label: key-value per identificare pods
- Selector: Regola per identificare risorse, possiamo usare le labels
- Pods: Unità eseguibile in un nodo, che può raggruppare container, volumes e rete. Possiamo replicarli. Hanno un ip e i container interni comunicano in loopback. Hanno un ip e label
- Control Plane: Punto di riferimento per i nodi per coordinarsi nell’esecuzione dei container tramite API calls, le config sono salvate in forma (key,value).
- Service: Definisce come esporre un pod su una rete interna/esterna. Praticamente un endpoint per la nostra applicazione, mappato su uno o più pods e puo fare anche ldn).
- Scheduler (kube-scheduler): tiene traccia dei pods, si occupa di assegnarli ai nodi e dare task ai pod. Implementa bin packing per placement e distribuzione delle ridondanze.
- Controller Manager: Gestisce i processi del controller specifico per il cloud cioè kube-controller-manager che ha accesso alle API del manager.
Ha diverse funzionalità per vari aspetti dell’architettura - node -controller
- cloud controller
- replication controller
- cloud-controller
- endpoint-controller
- route-controller
- service-controller
In cosa consiste il container filesystem?
Quali sono i vantaggi?
Quali sono gli altri approcci?
Cosa sono i volumes?
Comandi interessanti del dockerfile?
Il filesystem dei container è di natura layered quindi AuFS, simile a quello VM. Il file system di un container è composto da solo read only tranne quello superiore che è writeable, i file modificati sono quelli copiati nel layer read-write. L’immagine è la union dei layer read only.
Ogni layer è una director con un nome stringa esadecimale. Il layer più baso ha un file di collegamento e directory diff.
Risparmiamo spazio su disco e tempo di avvio.
Unione(AuFS): veloce da avviare e modificare, inefficiente per file grandi.
Snapshot dei FS: è efficiente e a buon mercato
Copy on write (blocchi):: veloce, ma costoso e utilizza molta memoria e usa in modo inefficiente il disco.
I volumes sono un meccanismo di persistenza dei dati, che possono esserre montati ai container e sono gestiti interamente da Docker. Hanno una lifecycle diversa da un volume.
Copy. Run (per un comando), Workdir per definire la directory su cui stiamo lavoorando, USER per definire lo user per i comandi seguenti, CMD è un comando alla startup.
Apache Tomcat:
com’è strutturata la directory?
Abbiamo un <prefix>:
- bin: file eseguibili apache
- conf file config
- htdocs documeni web
- cgi-bin script cgi
- logs</prefix>
Conviene usare Kubernetes su bare metal?
No, conviene usare delle VM apposite perchè il set up può diventare complicato.
Che co’è Minikube?
Com’è la gerarchia in Kubernetes?
Come funzionano gli ip in kubernetes?
Quali sono altri tipi di servizi ip?
Minikube è una versione utile per il testing su singolo nodo.
Abbiamo deployment -> replicaset -> pod
Ogni pod ha un ip accessible attraverso il service che a sua volta ha un suo ip virtuale. I pods e replicaset possono cambiare per scaling/fault tollerance. Anche il cluster ha un ip, non supporta NAT e viene usato solo per applicazioni locali.
____
Node port: per esporre un nodo, anche con nat, oppure per fare lb su replicaset
Load balancer: Balancing tra nodi
External Name: espone IP usando il record CNAME DNS
Com’è strutturato lo YAML in kubernetes?
api version:
kind: pod o service
metadata: contiene name e labels
spec: definisce il container o il pod del service con un selector
(possiamo definire le porte)
