docker swarm init --advertise-addr xxx.xxx.x.xxdocker swarm join-token worker
docker swarm join-token managerdocker network create -d overlay --attachable cocooning-networksudo 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`
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
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.