Archives par mot-clé : compose

Certificat Let’s Encrypt sur réseau local

On peut lire un peu partout qu’il n’est pas possible d’utiliser Let’s Encrypt sur son réseau privé. Cette assertion est trop rapide. C’est compliqué, pas supporté par défaut, mais amplement faisable.

Une solution consiste à utiliser les fonctions de challenge DNS de Let’s Encrypt et de récupérer et installer en local ces certificats.

Si l’on souhaite cacher l’architecture interne de notre infrastructure (sans la déclarer dans dans un dns public), il suffit simplement d’utiliser un wildcard de sous-domaine.

Le flux d’action est le suivant:

Pour fonctionner, cette procédure nécessite un serveur DNS public avec une api permettant de mettre à jour vos enregistrement DNS. Vous trouverez de tels services auprès par exemple de DigitalOcean, Namecheap.

Exemple avec un serveur DNS namecheap

dans un répertoire de votre serveur possédant docker (ou directement avec certbot et python), par exemple /data/certs

git clone https://github.com/heralight/certbot_dns_namecheap.git

créer le fichier namecheap.ini dans /data/certs

dans /data/certs/certbot_dns_namecheap

docker-compose run certbot-dns-namecheap  certonly \
  --non-interactive  -a certbot-dns-namecheap:dns-namecheap \
  --certbot-dns-namecheap:dns-namecheap-credentials=/namecheap.ini \
  --agree-tos \
  --email "dns-renew@mondomain.com" \
  -d *.mondomain.com

les certificats se trouvent dans /data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/

listes des certificats Let’s Encrypt certbot

docker-compose run  certbot-dns-namecheap  certificates  

renouvellement des certificats Let’s Encrypt certbot

Les certificats Let’s Encrypt ont une durée de validité courte, il vous faut les renouveler périodiquement.

docker-compose run  certbot-dns-namecheap  renew --force-renewal

dans un crontab ajouter -T en option pour éviter les problèmes. ex: docker-compose run -T …etc

Ensuite, à vous de configurer ou transférer (avec rsync, etcd ou consul par exemple) ces certificats ou bon vous semble.

Exemple – Lier Ingress avec ces certificats

Ci-après, un exemple d’utilisation pour un cluster Kubernetes avec une sur couche Rancher 2. Ingress va automatiquement utiliser vos certificats générés pour vos services exposés sur votre infrastructure.

Première étape, créer le secret contenant les certificats pour ingress.

kubectl -n devops-tools create secret tls tls-rancher-ingress \   --cert=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/cert.pem \   --key=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/privkey.pem

Ensuite automatiser la mise à jour avec crontab.

43 6 * * * cd /data/certs/certbot_dns_namecheap && /usr/local/bin/docker-compose run -T  certbot-dns-namecheap  renew --post-hook "kubectl -n devops-tools create secret tls tls-rancher-ingress    --cert=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/cert.pem   --key=/data/certs/certbot_dns_namecheap/out/certs/live/mondomain.com/privkey.pem --dry-run -o yaml |    kubectl apply -f - "

En conclusion, pas simple, mais faisable.

Pour information, l’api de Namecheap est disponible uniquement sur demande et sous condition d’avoir beaucoup de leur produit, mais à l’énorme avantage d’être compatible avec des domaines plus exotique, … comme les domaines islandais.

Déployer Docker Compose et Swarm sur coreOS

Cet article reprend une partie du post Running an etcd-Backed Docker Swarm Cluster
et de Installing Docker Compose in CoreOS
Le code source complet de cet article se trouve mis en application sur mon fork coreos-vagrant
il fait suite à l’article Docker sur CoreOS par Vagrant

Prérequis

git clone https://github.com/heralight/coreos-vagrant.git
cp config.rb.2.sample   config.rb
cp user-data.2.sample user-data
vagrant up
vagrant ssh core-01

Après un vagrant up, vérifions l’état du cluster etcd.

core@core-01 ~ $ etcdctl cluster-health
member 25d6ce33763c5524 is healthy: got healthy result from http://172.17.8.102:2379
member 6ae27f9fa2984b1d is healthy: got healthy result from http://172.17.8.101:2379
member ff32f4b39b9c47bd is healthy: got healthy result from http://172.17.8.103:2379
cluster is healthy
core@core-01 ~ $ etcdctl member list
25d6ce33763c5524: name=core-02 peerURLs=http://172.17.8.102:2380 clientURLs=http://172.17.8.102:2379 isLeader=false
6ae27f9fa2984b1d: name=core-01 peerURLs=http://172.17.8.101:2380 clientURLs=http://172.17.8.101:2379 isLeader=true
ff32f4b39b9c47bd: name=core-03 peerURLs=http://172.17.8.103:2380 clientURLs=http://172.17.8.103:2379 isLeader=false

Installer Docker Compose

Rapide

Vous retrouverez ce script dans la partie module du projet.
Vous n’avez pas besoins de l’executer à la main si vous utilisez vagrant, dans le fichier config.rb, modifier $vagrant_module_docker_compose à vrai (par défaut).
Ainsi vos instances seront provisionner avec Docker Compose.

En détails

Sur chaque noeud, executer:

curl -L https://github.com/docker/compose/releases/download/1.7.1/docker-compose-`uname -s`-`uname -m` > ~/docker-compose
sudo mkdir -p /opt/bin
sudo mv ~/docker-compose /opt/bin/docker-compose
sudo chown root:root /opt/bin/docker-compose
sudo chmod +x /opt/bin/docker-compose

Vérifions l’installation:

core@core-01 ~ $ whereis docker-compose
docker-compose: /opt/bin/docker-compose

Installer Docker Swarm avec support etcd

Dans l’article précédent, nous avons configurer nos 3 instances avec etcd2 en ip statique.
Nous allons profiter de cette fonctionalité pour configurer Docker Swarm.

Rapide

Vous retrouverez ce script dans la partie module du projet.
Vous n’avez pas besoins de l’executer à la main si vous utilisez vagrant, dans le fichier config.rb, modifier $vagrant_module_docker_swarm à vrai (par défaut).
Ainsi vos instances seront provisionner avec Docker Swarm.

En détails

Ainsi chaque noeud doit s’inscrire à etcd, comme les 3 instances coreos sont synchronizées, nous pouvons executer:

docker run -d swarm join --addr=monip:2375 etcd://monip:2379/swarm

Après cela, vérifions sont bon fonctionnement sur n’importe quel noeud.

core@core-01 ~ $ etcdctl ls /swarm/docker/swarm/nodes
/swarm/docker/swarm/nodes/172.17.8.101:2375
/swarm/docker/swarm/nodes/172.17.8.102:2375
/swarm/docker/swarm/nodes/172.17.8.103:2375

nous avons besoins d’un manager Swarm, par défaut nous prendre core-01.
Comme nous faisons tourner un moteur docker sur toutes nos instances, swarm simulant un moteur docker, nous aurons un conflit.
Pour palier à ce problème, nous allons rediriger le port de Swarm vers 8333.

docker run -d -p 32375:2375 swarm manage etcd://172.17.8.101:2379/swarm

nous pouvons vérifier notre installation:

docker -H tcp://172.17.8.101:32375 info