Lista bloccata dei servizi personalizzati

Per impostazione predefinita, Migrate to Containers disabilita i servizi non necessari su una VM quando ne esegui la migrazione in un container. Questi servizi a volte possono causare problemi con il container di cui è stata eseguita la migrazione o non sono necessari in un contesto di container.

Puoi anche definire un elenco personalizzato di servizi da disattivare in un container di cui è stata eseguita la migrazione utilizzando una lista bloccata personalizzata. Con una lista bloccata, puoi specificare uno o più servizi da disattivare in un contenitore di cui è stata eseguita la migrazione.

Definizione della lista bloccata

Definisci la tua lista bloccata personalizzata in un file .yaml, nel formato:

service_list:
  - name: <var>group-name-1</var>
    services:
      - <var>service-name</var>
  - name: <var>group-name-2</var>
    services:
      - <var>service-name</var>
      - <var>ervice-name</var>

Dove:

I gruppi sono una raccolta logica di servizi che consente di raccogliere servizi simili in un singolo gruppo. Specifica un valore stringa per il nome del gruppo.
Il nome del servizio specifica il servizio da disabilitare nel container di cui è stata eseguita la migrazione.

Ad esempio, definisci il file my-blocklist.yaml come:

service_list:
  - name: lvm-related
    services:
      - lvm2-lvmetad
  - name: hardware-related
    services:
      - microcode
      - microcode.ctl

Applicazione di una lista bloccata personalizzata

Applica la tua lista bloccata personalizzata a un contenitore in uno dei seguenti modi:

Creazione di un configmap Kubernetes contenente la lista bloccata e aggiunta alle specifiche di deployment del container.

Questo metodo ti consente di aggiungere la lista bloccata senza dover ricreare il contenitore. Tuttavia, devi ricreare configmap su ogni cluster utilizzato per ospitare il container.
Modifica il Dockerfile del container e ricrea l'immagine container.

Questo metodo richiede di ricreare l'immagine container per aggiungere la lista bloccata. Poiché la lista bloccata è ora inclusa nel container, non è necessario eseguire alcuna configurazione aggiuntiva sul cluster prima del deployment.

Utilizzo di una mappa di configurazione

Per creare una lista bloccata utilizzando un configmap:

Eseguire la migrazione della VM di origine in un container.
Crea un file .yaml della lista bloccata come mostrato sopra che elenchi il servizio da disattivare. In questo esempio, assegna al file il nome my-blocklist.yaml.

Crea un configmap dal file .yaml della lista bloccata:

kubectl create configmap configmap-name --from-file=path-to-yaml

In questo esempio, la mappa di configurazione si chiama blocklistcm:

kubectl create configmap blocklistcm --from-file=./my-blocklist.yaml

Visualizza la mappa di configurazione:
```
kubectl describe configmaps
```
Modifica il deployment_spec.yaml creato quando hai eseguito la migrazione del contenitore:
```
vi deployment_spec.yaml
```
Nella specifica del deployment, aggiungi quanto segue:
1. Aggiungi un nuovo volume per configmap in volumes:
```
volumes:
- configMap:
     name: blocklistcm # Name of the config map you created above.
   name: blocklistvol # Name of the configmap volume.
```
2. Aggiungi un montaggio del volume per la configmap:
```
spec:
  containers:
    volumeMounts:
    - mountPath: /etc/bl # Mount path for the configmap volume.
      name: blocklistvol # Name of the configmap volume.
```
3. Aggiungi una nuova variabile di ambiente denominata HC_CUSTOM_SERVICE_BLOCKLIST che specifichi il percorso al file .yaml della lista bloccata. Il nome della variabile di ambiente deve essere HC_CUSTOM_SERVICE_BLOCKLIST:
```
containers:
 - image: container-image-location
   env:
   - name: HC_CUSTOM_SERVICE_BLOCKLIST
     value: "/etc/bl/my-blocklist.yaml"
```
  Il percorso specificato dal valore è la concatenazione del mountPath della configmap e del nome del file .yaml della lista bloccata, my-blocklist.yaml.
4. Salva il file.
Esegui il deployment del container:
```
kubectl apply -f deployment_spec.yaml
```

Dopo aver eseguito il deployment del container, puoi esaminarlo per assicurarti che i servizi non siano in esecuzione. Ad esempio:

# Get pod name.
$ kubectl get pod
# Connect to pod.
$ kubectl exec -it POD_NAME -- /bin/bash
# View running services. This step is OS dependent. For example:
$ service --status-all```

Modifica del Dockerfile

Questa sezione descrive come creare una lista bloccata personalizzata modificando il Dockerfile creato dalla migrazione.

Eseguire la migrazione della VM di origine in un container.
Apri il Dockerfile in un editor.
Aggiungi il seguente comando COPY per aggiungere il file .yaml della lista bloccata al file system del container:
```
COPY src dest 
```
Ad esempio:
```
COPY my-blocklist.yaml /etc/mybl/my-blocklist.yaml
```
Il percorso di destinazione può essere qualsiasi percorso all'interno del container.
Aggiungi una nuova variabile di ambiente denominata HC_CUSTOM_SERVICE_BLOCKLIST specificando il percorso al file .yaml della lista bloccata in base alla destinazione del file specificata dal comando COPY. Il nome della variabile di ambiente deve essere HC_CUSTOM_SERVICE_BLOCKLIST:
```
ENV HC_CUSTOM_SERVICE_BLOCKLIST /file-path
```
Ad esempio:
```
ENV HC_CUSTOM_SERVICE_BLOCKLIST /etc/mybl/my-blocklist.yaml
```
Aggiorna l'immagine container.

Il modo in cui aggiorni l'immagine container dipende dall'ambiente di build. Puoi utilizzare:
1. gcloud per creare l'immagine e caricarla in Container Registry come descritto in Guida rapida: creazione.
2. docker build come descritto in Creare ed eseguire l'immagine .
Dopo aver creato la nuova immagine, apri il file deployment_spec.yaml in un editor per aggiornare il percorso dell'immagine:
```
spec:
  containers:
  - image: new-image-location
```
Ad esempio, new-image-location potrebbe essere gcr.io/my-project/my-new-image:v1.0 se hai utilizzato gcloud per creare l'immagine e l'hai caricata su Container Registry.
Esegui il deployment del container:
```
kubectl apply -f deployment_spec.yaml
```

Dopo aver eseguito il deployment del container, puoi esaminarlo per assicurarti che i servizi non siano in esecuzione. Ad esempio:

# Get pod name.
$ kubectl get pod
# Connect to pod.
$ kubectl exec -it POD_NAME -- /bin/bash
# View running services. This step is OS dependent. For example:
$ service --status-all