Aucun risque de perdre les autres modules
Se positionner dans le container (portainer)
Exécuter le script :
wget -O - https://get.hacs.xyz | bash -
docker swarm init --advertise-addr xxx.xxx.x.xx
docker swarm join-token worker
docker swarm join-token managerdocker network create -d overlay --attachable cocooning-networksur chaque hote Elles seront préfixées par ENV. et peuvent être différentes d'un hote à l'autre
sudo nano /etc/environment
for line in $(cat /etc/environment) ; do export $line ; doneLa prise en compte des nouvelles variables se fera immédiatement et seront disponibles après reboot
visualisation des variables d'environnement
printenv
printenv | grep ENV_Si vous n'avez qu'un seul Manager, la méthode la plus propre pour changer l'IP sans tout reconstruire manuellement est de forcer une nouvelle initialisation.
Sauvegardez vos définitions : Avant toute chose, assurez-vous d'avoir vos fichiers docker-compose.yml ou vos commandes de création de services à portée de main.
Réinitialisez le Swarm :
Note : Cela stoppe les containers en cours, mais ne supprime PAS vos images ni vos volumes de données.
Réinitialisez avec la nouvelle IP :
Redéployez vos services : Vos volumes étant toujours là, il vous suffit de relancer votre stack :
Si l'IP d'un Worker change :
Sur le Manager : docker node rm <nom_du_worker>
Sur le Worker : docker swarm leave
Sur le Worker : Rejoignez à nouveau le cluster avec le token fourni par le manager.
Si l'IP du Manager change : C'est plus complexe car les Workers cherchent l'ancienne IP. La méthode la plus fiable reste de dissoudre le cluster (swarm leave) et de le recréer, car la base de données interne (Raft) du Swarm est très sensible aux changements d'identité réseau.
Volumes : Si vous utilisez des volumes locaux (ex: -v /ma/data:/data), vos données sont en sécurité sur le disque. Si vous utilisez des volumes réseau (NFS, GlusterFS), vérifiez que la nouvelle IP est autorisée sur le serveur de stockage.
Réseaux Overlay : Lors d'un swarm leave, les réseaux overlay sont supprimés. Ils seront recréés automatiquement lors du prochain stack deploy.
Firewall : N'oubliez pas d'ouvrir les ports nécessaires sur la nouvelle IP :
2377/tcp (Cluster management)
7946/tcp & udp (Communication entre nœuds)
4789/udp (Overlay network)
Conseil d'expert : Pour éviter ce problème à l'avenir, si votre infrastructure le permet, utilisez un DNS Interne ou une IP virtuelle (VIP) pour l'adresse d'annonce. Ainsi, si l'IP physique change, il suffit de mettre à jour le DNS sans toucher à la config Docker.
Souhaitez-vous que je vous aide à rédiger un script pour automatiser la sauvegarde de vos volumes avant de procéder au changement d'IP ?
Bash
docker stack deploy -c votre-fichier.yml nom_de_la_stackBash
docker swarm init --advertise-addr <NOUVELLE_IP>Bash
docker swarm leave --forceEn mode swarm le fichier .env n'est pas lu
Pour les variables du fichier docker-compose {$ENV_1}
- Elles se trouvent exclusivement sur le manager qui redistribue
- Elles se trouvent dans /etc/environment du master 1 pour gérer le redemarrage
- Pour portainer template dans les variables du template
A tester : Utiliser les secrets pour login tchube et password dans la swarm et portainer serveur
Déploiement possible du même docker-compose (
docker-stack)par docker stack deploy ou par un template d'application de PortainerVoir environnement de prod et recette
Elles sont préfixées par ENV_
Solution retenue :
/etc/environment
- Toutes variables exposés dans le docker-compose sous forme
${ENV_}quelle que soit leur portée (cocooning, cluster, hôte)- A définir également dans le template de portainer pour être initialisées au déploiement.
- Réinitialisées lors d'un reboot
# Variables globales à cocooning
ENV_ADMIN_LOGIN=
ENV_ADMIN_PASSWORD=
# Variables globales au cluster
ENV_SS_DOMAIN=
ENV_SYSLOG_IP=
ENV_NFS_IP=
# Variables de déploiement
ENV_DDCLIENT_NODE_DEPLOY=
# Spécifiques à une application
printenv | grep ENV_
export ENV_name=VALUE
unset ENV_namesudo nano /etc/environmentfor line in $( cat /etc/environment ) ; do export $line ; done/etc/environmentsudo sed -i '/^ENV_.*/d' /etc/environmentfor var in $(env | grep -E '^ENV_'); do unset ${var%%=*}; doneenv_file
- Spécifiques à l'application
- peuvent être de portée globale, cluster et node
- Les variables sont stockées dans des
file_name.envsitués :
- sur le master1
/.cocooning/data/environment- et dans le container portainer serveur sous forme de volume (bind)
/.cocooning/data/environment.
environment:
- Définir une règle
sudo nano /etc/dhcpcd.conf
# IP fixe
interface eth0
static ip_address=192.168.1.101/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1
# redemarrer le service /
sudo service dhcpcd restart# Changer le hostname (master1, worker1...) /
sudo nano /etc/hostname
# Ajouter un hostname (master1, worker1...) /
sudo nano /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
`127.0.1.1 worker1`
sudo apt-get install nfs-kernel-server -y
sudo nano /etc/exports
/.cocooning/data 192.168.1.100/24(rw,no_root_squash,async,no_subtree_check)
Repertoires
- /.cocooning/data
- /.cocooning/{$ENV_SS_DOMAIN}/hassio ou autre application
sudo exportfs -ra
Pour savoir quels ports NFS utilise, entrez la commande suivante:
sudo rpcinfo -p | grep nfs
sudo ufw allow 2049
sudo service nfs-kernel-server reload
gparted et affecter le label data à la partition primaire ext4 crééeA simplifier
- Repérer le disque et créer le répertoire .data à la racine
sudo fdisk -l # liste les partitions sudo blkid # liste les UUID et Labels sudo mkdir /media/data # créer le repertoire de montage temporaire sudo mount -t ext4 /dev/sda1 /media/data # Système de fichiers en ext4 sudo mkdir /media/data/.cocooning/data cd /media/data ls -a # pour vérifier la création du répertoire .data sudo umount /dev/sda1 # demonter la partition
{.is-warning}
/.cocooning/data sur chaque noeudsudo mkdir /.cocooning
sudo mkdir /.cocooning/data
sudo nano /etc/fstab
LABEL=data /.cocooning/data ext4 defaults 0 2
sudo reboot
ATTENTION ne pas installer docker-compose pour le moment. Son installation provoque la réinstallation de docker (version du dépôt de l'OS)
Si echec de l'install, vérifier les dépots /etc/apt/sources.list.d et sources.list
sudo su
cd /home/tchube
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh --channel stableUtilisation de Vscode possible après installation de ddclient
- portainer
- certbot
- haproxy
zigbee -> mosquitto
- mosquitto
- dmp
- zigbee
Hassio -> database
- mariadb, postgres (pour hassio)
- hassio
Monitoring (sur tchube)
syslog -> telegraf -> influxdb1 -> grafana
L'ordre de création :
- influxdb1 (sur tchube uniquement)
- telegraf (host, syslog)
- syslog
- grafana (sur tchube uniquement)
telegraf - influxdb2 -> grafana
- grafana
- infuxdb2
- telegraf
docker swarm leave
Ajuster la ligne de commande ci-dessous en fct des erreurs
sudo apt-get purge docker.io docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Supprimer le répertoire /var/lib/docker/ (suppression des images, des conteneurs, des volumes des réseaux).
sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd
docker node demote ID # Demote one or more nodes from manager in the swarm. Le noeud passe de manager à worker
docker node inspect # Display detailed information on one or more nodes
docker node ls # List nodes in the swarm
docker node promote # Promote one or more nodes to manager in the swarm
docker node ps # List tasks running on one or more nodes, defaults to current node
docker node rm # Remove one or more nodes from the swarm
docker node update # Update a node
docker system prune # ne supprime pas les volumes.
docker system prune -a -f --volumes # supprimera des volumes.
docker system prune -af --volumes # nettoiera toutes les ressources docker créées auparavant.
L'installation des containers se fera sur les nodes taggés du nom de l'application
docker node update --label-add foo --label-add bar worker1
docker node update --label-add foo=foox --label-add bar=barx worker1
docker node update --label-rm foo
Utilisation des labels dans le déploiement
deploy:
mode: replicated
replicas: 1
placement:
constraints:
- node.labels.hassio == true
Le numéro de version est important pour des mises à jours maîtrisées.
Les dépendances (dockerize)
Les opérations vers le registre docker hub
utiliser le fichier environnement spécifique à l'utilisateur (sous-domaine) /.cocooning/data/environment/${ENV_SS_DOMAIN}.env
for line in $( cat /.cocooning/data/environment/${ENV_SS_DOMAIN}.env) ; do export $line ; done
Pour la prise en compte des variables d'environnement dans l'environnement "portainer" il faut mettre à jour les variables dans le service portainer : copier/coller {ENV_SS_DOMAIN}.env (advanced mode)
Dans les app du template.json utiliser :
"env": [
{
"name": "ENV_ENVIRONMENT_FILE",
"label": "Environment file",
"description": "Nom du fichier d'environnement $ENV_SS_DOMAIN"
}
]
export ENV_foo=foox
Pour lister les variables d'envionnement préfixées
printenv | grep ENV_
printf "my_password" | docker secret create tchube -
secrets:
- source: tchube
target: /tchube/secret
command:
- 'export ENV_ADMIN_PASSWORD=oauat7579'
- ENV_ADMIN_PASSWORD=tchube/secret
secrets:
tchube:
external: true
A affiner. pour le moment des mot de passes seront stockés en tant que variable d'environnement.
sudo docker run --hostname container0 --name container0 -it ubuntu
Dans le container0
c=0; while true; do echo "$c: $(date) $HOSTNAME"; c=$((c+1)); sleep 60; done
Créer un docker-compose avec le driver syslog, modifier le container avec Portainer
Le server syslog-ng est installé sur un noeud (label syslog). Le driver syslog peut être installé soit globalement pour l'ensemble des services du Swarm soit pour chaque service déployé
Port UDP par défaut : 514
Noton que le protocole TCP ne fonctionne pas avec le server syslog-ng
Le logging driver est défini de manière générale dans le fichier /etc/docker/daemon.json sur chaque noeud.
{
"log-driver": "syslog",
"log-opts": {
"syslog-address": "udp://SYSLOG_IP:SYSLOG_PORT"
}
}
Relancer le service docker
Cette manière permet d'ajuster individuellement le driver au service
mais également de tagger les logs.
logging:
driver: "syslog"
options:
syslog-address: "udp://${ENV_SYSLOG_IP}:${ENV_SYSLOG_PORT}"
tag: "ddclient"
Pilote d'un container
docker inspect -f '{{.HostConfig.LogConfig.Type}}' <CONTAINER>
Pilote de journalisation global de docker
docker info --format '{{.LoggingDriver}}'
Par définition un fichier de configuration est statique (pas de mise à jour sur disque une fois créé). Il sera déployé (et dupliqué) automatiquement en fonction du mode choisi (global, duplicated).
Les fichiers de configurations se trouveront dans le répertoire /.cocooning/user/config et seront accessibles avec VSCODE
Le fichier de configuration sera créé en utilisant le template driver GOLANG pour la mise à jour dynamique des variables.
docker config create --template-driver golang ddclient /.cocooning/${ENV_SS_DOMAIN}/config/ddclient.conf
Les variables d'environnement seront passées dans le docker-compose sous la forme :
environment:
- ENV_DOMAIN=${ENV_DOMAIN}
- ENV_SS_DOMAIN=${ENV_SS_DOMAIN}
et accessibles dans le fichier docker config template golang sous la forme :
{{env "ENV_SS_DOMAIN"}}
docker network create -d overlay cocooning-network
Affiner la création
Plusieurs types de volume utilisés fonction du contexte avec l'objectif principal de limiter le plus possible les écritures sur la SD et utiliser le répertoire data du DD externe
Un volume monté de type bind généralement sur le répertoire data est utilisé. Le container sera exécuté sur ce même noeud pour accéder à data.
Le volume sera stocké dans /etc/docker et sera dupliqué sur chaque noeud exécutant le container. Les écritures devront être peu fréquentes sur la SD.
A voir
A voir
Ex le repertoire config de homeassistant peut être accessible en utilisant une instance HA sur le worker1 ou le master1
Ne pas utiliser de serveur NFS pour partager une BD. Dans le cas d'un haute disponibilité l'utilisation de Mariadb galera cluster est nécessaire
L'exécution du server se fera sur l'hôte portant le volume data (déclaration dans fsatb)
sudo nano /etc/exports
/.cocooning/data/mosquitto/data HOTE_IP/24(rw,no_root_squash,async,no_subtree_check)
sudo exportfs -ra
sudo service nfs-kernel-server reload
volumes:
homeassistant:
driver: local
driver_opts:
type: "nfs4"
o: "nfsvers=4,addr=$ENV_NFS_IP,rw,soft,nolock"
device: ":/.cocooning/$ENV_SS_DOMAIN/homeassistant/hassio/"
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.