Archives de catégorie : cloud

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.

Monter en miroir un volume synology

But

Monter un volume, par exemple le /volume1 du synology, dans un répertoire de partage /volume1/volume1 afin de tout sauvegarder y compris les répertoires cachés ou cryptés.

Procédure

  • créez un répertoire partagé nommé volume1
  • connectez-vous en ssh
  • ajoutez un fichier S99MountBind.sh dans /usr/syno/etc.defaults/rc.d
  • le contenu du fichier:


#!/bin/sh

start()
{
/bin/mount -o bind /volume1 /volume1/volume1
}

stop()
{
/bin/umount /volume1/volume1
}

case "$1" in
start) start ;;
stop) stop ;;
*) ;;
esac

  • chmod 755 S99MountBind.sh
  • S99MountBind.sh start

voilà! Ca devrait même marcher au démarrage du nas…

Trucs et astuces pour systemd

Monter un répertoire nfs avec systemd

Il vous faut créer un fichier .mount normalisé.
Le nom du fichier, par convention, doit correspondre au path du point de montage, par exemple à /mnt/nfs correspond le fichier mnt-nfs.mount
Cette unit devant être gérer par le système, il doit se trouver dans /etc/systemd/system .

vi /etc/systemd/system/mnt-nfs.mount
        [Unit]
        Description = nfs mount core to host
        
        [Mount]
        What = votreserveurnfs:/votrepartage/
        Where = /mnt/nfs
        Type = nfs
        Options = vers=3,nolock,udp
        
        [Install]
        WantedBy = multi-user.target

testez

systemctl daemon-reload
systemctl start mnt-nfs.mount
systemctl status mnt-nfs.mount

Avoir accès aux variables systemd dans une unit mount

Malheureusement systemd ne donne pas accès à ses variables (par exemple %H) dans la requête nfs créée.
Si vous avez besoins par exemple d’avoir un partage propre à chaque machine, pour contourner cette limitation vous pouvez passer par des variables d’environnement comme ceci:

        [Unit]
        Description = nfs mount core to host
        
        [Mount]
        What = votreserveurnfs:/votrepartage/${HOST}
        Environment="HOST=%H"
        Where = /mnt/nfs
        Type = nfs
        Options = vers=3,nolock,udp
        
        [Install]
        WantedBy = multi-user.target

Monter automatiquement avec Systemd

automount suit la même convention que mount.
Il vous faut créer un fichier .automount normalisé.
Le nom du fichier, par convention, doit correspondre au path du point de montage, par exemple à /mnt/nfs correspond le fichier mnt-nfs.automount
Cette unit devant être gérer par le système, il doit se trouver dans /etc/systemd/system .

        [Unit]
        Description = nfs auto mount core to host
        
        [Automount]
        Where = /mnt/nfs
        
        [Install]
        WantedBy=multi-user.target

Ajouter une dépendance à automount pour Docker

Votre unit .automount n’ayant pas de dépendant, il ne s’executera pas au démarrage de vote système.
Si par exemple, vous avez besoins de ce point de montage pour docker, vous pouvez modifier votre unit docker.
Dans le cas d’un système CoreOS, modifier /etc/systemd/system/early-docker.service comme suit.
Regarder le paramètre Requires
Tips 2 : Changer le home de Docker sur support nfs : modifier ExecStart en ajoutant –graph et –storage-driver.

        [Unit]
        Description=Early Docker Application Container Engine
        Documentation=http://docs.docker.com
        After=early-docker.socket
        Requires=early-docker.socket mnt-nfs.automount  mnt-nfs.mount
        
        [Service]
        Environment=TMPDIR=/var/tmp
        MountFlags=slave
        LimitNOFILE=1048576
        LimitNPROC=1048576
        ExecStartPre=-/usr/bin/mkdir -p /mnt/nfs/early
        ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// --bridge=none --iptables=false --ip-masq=false --graph=/mnt/nfs/early --pidfile=/var/run/early-docker.pid --storage-driver=overlay $DOCKER_OPTS
        
        [Install]
        WantedBy=early-docker.target

Mountage Automatique avec Systemd sur CoreOS dans user-data

Et l’on prend les points ci-dessus pour les mettre dans un user-data coreOS…

  - name: mnt-nfs.mount
    content: |
        [Unit]
        Description = nfs mount core to host
        
        [Mount]
        What = votreserveurnfs:/votrepartage/${HOST}
        Environment="HOST=%H"
        Where = /mnt/nfs
        Type = nfs
        Options = vers=3,nolock,udp
        
        [Install]
        WantedBy = multi-user.target
  - name: mnt-nfs.automount
    content: |
        [Unit]
        Description = nfs auto mount core to host
        
        [Automount]
        Where = /mnt/nfs
        
        [Install]
        WantedBy=multi-user.target
    
  - name: docker.service
    content: |
        [Unit]
        Description=Docker Application Container Engine
        Documentation=http://docs.docker.com
        After=docker.socket early-docker.target network.target
        Requires=docker.socket early-docker.target

        [Service]
        EnvironmentFile=-/run/flannel_docker_opts.env
        MountFlags=slave
        LimitNOFILE=1048576
        LimitNPROC=1048576
        ExecStartPre=-/usr/bin/mkdir -p /mnt/nfs/docker
        ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// $DOCKER_OPTS $DOCKER_OPT_BIP $DOCKER_OPT_MTU $DOCKER_OPT_IPMASQ --graph=/mnt/nfs/docker --storage-driver=overlay  

        [Install]
        WantedBy=multi-user.target
        
    command: restart
  - name: early-docker.service
    content: |
        [Unit]
        Description=Early Docker Application Container Engine
        Documentation=http://docs.docker.com
        After=early-docker.socket
        Requires=early-docker.socket mnt-nfs.automount  mnt-nfs.mount
        
        [Service]
        Environment=TMPDIR=/var/tmp
        MountFlags=slave
        LimitNOFILE=1048576
        LimitNPROC=1048576
        ExecStartPre=-/usr/bin/mkdir -p /mnt/nfs/early
        ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// --bridge=none --iptables=false --ip-masq=false --graph=/mnt/nfs/early --pidfile=/var/run/early-docker.pid --storage-driver=overlay $DOCKER_OPTS
        
        [Install]
        WantedBy=early-docker.target

pour que ces units s’éxecutent au démarrage vous pouvez jouer avec leur flags
runtime: true
enable: true

voir la documentation de coreOs sur user-data unit