Differenze tra Deployment e DeploymentConfig
Published: 2023-10-03 14:27:03

---
title: Differenze tra Deployment e DeploymentConfig
published: true
date: 2022-11-03 00:00:00 UTC
tags: 
canonical_url: 
---

Gli oggetti Deployment e DeploymentConfig in OpenShift forniscono due metodi simili ma diversi per gestire in maniera precisa il comportamento delle applicazioni. I due oggetti, spesso confusi, hanno grandi differenze nella loro esecuzione e gestione: quali?

Andiamo ad analizzare nel dettaglio questi due _controller_!

# Cosa vedrai

- [DeploymentConfig](#deploymentconfig)
- [Deployment](#deployment)
- [ReplicaSet vs ReplicationController](#replicaset-vs-replicationcontroller)
- [Risorse utili](#risorse-utili)

# DeploymentConfig

Gli oggetti di tipo **DeploymentConfig** coinvolgono uno o più _Replication Controllers_, ossia delle risorse che contengono un _point-in-time_ dello stato di uno o più pod, di cui ne gestiscono peraltro la numerosità.

Sarà proprio il Replication controllers ad assicurarsi che il numero specificato di pod siano in esecuzione; qualora un pod venisse eliminato o andasse in errore, sarà sua cura istanziarne uno in sostituzione.

La cosa interessante è la possibilità di gestire le **versioni** dell’applicazione per supportare i rollback manualmente o automaticamente in caso di un deploy che fallisce, oltre alla possibilità di catturare ogni cambiamento alla configurazione dell’oggetto attraverso un **trigger** : questo fa sì che una modifica all’environment del DeploymentConfig o delle sue risorse, produca una nuova versione.

Non a caso, i DeploymentConfig creano dei Replication Controller i cui nomi riportano la versione di riferimento: se, ad esempio, il DeploymentConfig si chiama _mongodb_, il suo Replication Controller si chiamerà _mongodb-1_, perché fa riferimento al rollout (o versione) numero 1.

![](https://theredcode.it/img/dc-mongodb-1.png)

Quando crei un oggetto DeploymentConfig, viene creato un _Replication Controller_ che rappresenta il modello pod dell’oggetto DeploymentConfig.

Se il DeploymentConfig **cambia** , viene creato un nuovo Replication Controller con il template aggiornato e viene eseguito un processo di deploy che porti a termine la precedente versione del Replication Controller, per avviare quello nuovo.

## Esempio di DeploymentConfig

```
apiVersion: v1
kind: DeploymentConfig
metadata:
 name: frontend
spec:
 replicas: 5
 selector:
 name: frontend
 template: { ... }
 triggers:
 - type: ConfigChange
 - imageChangeParams:
 automatic: true
 containerNames:
 - helloworld
 from:
 kind: ImageStreamTag
 name: hello-openshift:latest
 type: ImageChange
 strategy:
 type: Rolling

```

## Esempio di Replication Controller

```
apiVersion: v1
kind: ReplicationController
metadata:
 name: frontend-1
spec:
 replicas: 1
 selector:
 name: frontend
 template:
 metadata:
 labels:
 name: frontend
 spec:
 containers:
 - image: openshift/hello-openshift
 name: helloworld
 ports:
 - containerPort: 8080
 protocol: TCP
 restartPolicy: Always

```

# Deployment

Allo stesso modo, gli oggetti di tipo **Deployment** lavorano grazie a degli oggetti chiamati _Replica Set_, i quali rappresentano un successore dei _ReplicationController_.

Simile a un Replication controller, un _ReplicaSet_ è un oggetto API nativo di Kubernetes che garantisce che un numero specificato di pod sia in esecuzione in un dato momento.

I ReplicaSet possono essere usati in modo indipendente, ma vengono usati dai Deployment per gestire la creazione, l’eliminazione e gli aggiornamenti dei pod. I Deployment gestiscono automaticamente i ReplicaSet, motivo per cui non andrebbero utilizzati come oggetti a sé stanti.

Il vantaggio dell’utilizzo dei Deployment è che supportano il **rollback** automatico all’ultimo ReplicaSet che ha avuto esito positivo nel deploy in caso di errore; questo vuol dire che se viene avviata una nuova versione del ReplicaSet, in caso quest’ultima vada in errore, sarà possibile sfruttare la versione precedente che verrà riavviata in maniera automatica.

## Esempio di Deployment

```
apiVersion: apps/v1
kind: Deployment
metadata:
 name: hello-openshift
spec:
 replicas: 1
 selector:
 matchLabels:
 app: hello-openshift
 template:
 metadata:
 labels:
 app: hello-openshift
 spec:
 containers:
 - name: hello-openshift
 image: openshift/hello-openshift:latest
 ports:
 - containerPort: 80

```

## Esempio di ReplicaSet

```
apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: frontend-1
 labels:
 tier: frontend
spec:
 replicas: 3
 selector:
 matchExpressions:
 - {key: tier, operator: In, values: [frontend]}
 template:
 metadata:
 labels:
 tier: frontend
 spec:
 containers:
 - image: openshift/hello-openshift
 name: helloworld
 ports:
 - containerPort: 8080
 protocol: TCP
 restartPolicy: Always

```

# ReplicaSet vs ReplicationController

La differenza tra un ReplicaSet e un Replication Controller sta nel fatto che il primo supporta la possibilità di gestire i selettori sulla base di alcune espressioni che ne controllino il _match_, mentre nel caso del Replication controller viene utilizzato un selettore che si basi sull’uguaglianza.

In altre parole, nel ReplicaSet ci possiamo aspettare una label come _matchExpressions_ che riporta i criteri per individuare i pod sulla base di una chiave, un operatore e dei valori.

Nel primo caso di esempio, la chiave è _tier_, l’operatore è _In_ (verifica l’esistenza in un insieme definito) e i valori sono espressi tramite un array pari a_frontend_.

Nel secondo caso, si esprime una label la cui chiave _tier_ deve matchare il valore _frontend_.

## Esempio di ReplicaSet con matchExpressions

```
apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: frontend-1
 labels:
 tier: frontend
spec:
 replicas: 3
 selector:
 matchExpressions:
 - {key: tier, operator: In, values: [frontend]}
 ...

```

## Esempio di ReplicaSet con matchLabels

```
apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: frontend-1
 labels:
 tier: frontend
spec:
 replicas: 3
 selector:
 matchLabels:
 tier: frontend
 ...

```

Il campo _.spec.selector_ rappresenta un selettore di etichette. Un **ReplicationController** gestisce tutti i pod con label che corrispondono al selettore. Non fa distinzione tra pod creati o eliminati e pod creati o eliminati da un’altra persona o processo. Ciò consente di sostituire ReplicationController senza influire sui pod in esecuzione.

## Esempio di ReplicationController

```
apiVersion: v1
kind: ReplicationController
metadata:
 name: frontend-1
spec:
 replicas: 1
 selector:
 name: frontend
 template:
 metadata:
 labels:
 name: frontend
 ...

```

# Risorse utili

- [Docker](https://amzn.to/3cSVvUG) - per cominciare bene con Docker e Kubernetes
- [Kubernetes](https://amzn.to/44bLfyR) - Guida per gestire e orchestrare i container
- [Canale di Emmecilab](https://www.youtube.com/c/EmmeCiLab/about)