Archives pour la catégorie ‘Administration’

Terraform : gérer ses zones DNS Gandi

Voici la marche à suivre pour gérer vos zones DNS Gandi avec Terraform. Je pars du principe que votre zone est existante, ce qui implique l’importation de l’ensemble des ressources dans Terraform. Ce n’est pas strictement obligatoire, mais seule l’importation garantit la correspondance exacte de votre code à l’existant.

Installation du provider Gandi

# go get github.com/tiramiseb/terraform-provider-gandi
# cd $GOPATH/go/src/github.com/tiramiseb/terraform-provider-gandi
# go build -o terraform-provider-gandi

Comme précisé par l’auteur du provider, cela ne marche qu’avec la nouvelle infrastructure LiveDNS de Gandi; il convient donc de migrer vos zones et également créer votre clé API.

Projet Terraform

Débutons par la création d’un project Terraform basique :

# mkdir ~/Projects/terraform
# cd ~/Projects/terraform
# touch main.tf providers.tf variables.tf outputs.tf terraform.tfvars

Fichier provider.tf :

provider "gandi" {
    key = "${var.gandi_key}"
}

Fichier variable.tf :

variable "gandi_key" {}

Fichier main.tf :

resource "gandi_zone" "hbis_fr" {
  name = "hbis.fr"
}

resource "gandi_domainattachment" "hbis_fr" {
    domain = "hbis.fr"
    zone = "${gandi_zone.hbis_fr.id}"
}

resource "gandi_zonerecord" "root" {
    zone = "${gandi_zone.hbis_fr.id}"
    name = "@"
    type = "A"
    ttl = 3600
    values = [
        "51.15.171.130"
    ]
}
resource "gandi_zonerecord" "www" {
    zone = "${gandi_zone.hbis_fr.id}"
    name = "www"
    type = "A"
    ttl = 3600
    values = [
        "51.15.171.130"
    ]
}

Je ne m’étends pas sur le code des ressources, seule une variable Terraform sera utilisée en CLI pour fournir la clé API.

Le projet est à initialiser :

$ terraform init

Avant de débuter l’importation de la zone DNS, l’étape essentielle est de récupérer son identifiant. Pour ce faire :

$ curl -s -H "Content-Type: application/json" -H "X-Api-Key: ******" https://dns.api.gandi.net/api/v5/zones|jq -r
[
 {
 "retry": 3600,
 "uuid": "72e4069e-eeef-11e7-8db5-00163e6dc886",
 "zone_href": "https://dns.api.gandi.net/api/v5/zones/72e4069e-eeef-11e7-8db5-00163e6dc886",
 "minimum": 10800,
 "domains_href": "https://dns.api.gandi.net/api/v5/zones/72e4069e-eeef-11e7-8db5-00163e6dc886/domains",
 "refresh": 10800,
 "zone_records_href": "https://dns.api.gandi.net/api/v5/zones/72e4069e-eeef-11e7-8db5-00163e6dc886/records",
 "expire": 604800,
 "sharing_id": "4aace8e0-b393-11e7-bcf1-00163ec388ae",
 "serial": 1514825087,
 "email": "hostmaster.gandi.net.",
 "primary_ns": "ns1.gandi.net",
 "name": "hbis.fr"
 }
]

La valeur UUID est l’identifiant à récupérer. Lancez l’importation :

$ terraform import -var 'gandi_key=******' gandi_zone.hbis_fr 72e4069e-eeef-11e7-8db5-00163e6dc886

Terraform devrait confirmer l’importation de la ressource dans son fichier d’état. Vérification :

$ terraform show
gandi_zone.hbis_fr:
id = 72e4069e-eeef-11e7-8db5-00163e6dc886
name = hbis.fr

La ressource d’association zone DNS au domaine est également à importer:

$ terraform import -var 'gandi_key=******' gandi_domainattachment.hbis_fr hbis.fr

La zone est à présent reconnue et la création de nouveau records par Terraform est possible. Reste donc à importer les records existants :

$ terraform import -var 'gandi_key=******' gandi_zonerecord.root 72e4069e-eeef-11e7-8db5-00163e6dc886/@/A
$ terraform import -var 'gandi_key=******' gandi_zonerecord.blog 72e4069e-eeef-11e7-8db5-00163e6dc886/www/A

La commande import nécessite le nom de la ressource et son identifiant interne. Dans le cas des records, le format est : <UUID>/<NAME>/<TYPE>.

Le fichier d’état étant peuplé de toutes les ressources nécessaires, vérifiez que le plan Terraform ne requiert aucune modification :

$ terraform plan -var 'gandi_key=******' -out plan.out

Vous pouvez à présent utiliser Terraform pour créer et gérer votre zone DNS.

Python : serveur web ad hoc

$ python3 -m http.server 9000

Debian : forcer l’utilisation d’IPv4 pour apt

# echo 'Acquire::ForceIPv4 "true";' > /etc/apt/apt.conf.d/99forceipv4

Amazon EC2 : configuration routage asymétrique

# vim /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
   post-up ip route add default via 172.16.100.1 dev eth0 tab 1
   post-up ip rule add from 172.16.100.99 tab 1
   pre-down ip rule del from 172.16.100.99 tab 1
   pre-down ip route del default via 172.16.100.1 dev eth0 tab 1

auto eth1
iface eth1 inet dhcp
   post-up ip route add default via 172.16.111.1 dev eth1 tab 2
   post-up ip rule add from 172.16.111.169 tab 2
   pre-down ip rule del from 172.16.111.169 tab 2
   pre-down ip route del default via 172.16.111.1 dev eth1 tab 2

Debian : activer l’IPv6 sur une instance EC2

# vim /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
   post-up sleep 2
iface eth0 inet6 dhcp

RaspberryPI : installation de Kodi 17.1

# echo 'deb http://pipplware.pplware.pt/pipplware/dists/jessie/main/binary /' | sudo tee --append /etc/apt/sources.list.d/pipplware_jessie.list
# wget -O - http://pipplware.pplware.pt/pipplware/key.asc | apt-key add -
# apt update
# apt install kodi

zabbix-docker : version 0.2.1

Zabbix-docker est un agent de monitoring Docker pour Zabbix, permettant de récupérer l’ensemble des métriques des containers Docker pour un host voire un cluster (aggrégation des métriques côté serveur Zabbix). Les métriques actuellement supportées sont les suivantes :

  • statut des containers (dont le health check de Docker 1.12)
  • statistiques des containers (RAM, CPU, interfaces réseau et périphériques de stockage)
  • processus en exécution dans les containers
  • évenèments des containers

La version 0.2 apporte en particulier l’exécution par l’API Docker de commandes distantes dans les containers monitorés. Ainsi, en ajoutant vos scripts de collecte des métriques trapper à vos images Docker, les métriques applicatives peuvent être détectées (parsing de la sortie console) et envoyées au serveur Zabbix.

Let’s Encrypt : gestion des certificats avec le client dehydrated

Ayant un peu de temps, je me suis décidé – moi et ma flemme sacrée – à virer mon certificat StartSSL. Pour les désinformés, il y a une bien triste histoire à connaître sur les pratiques de StartSSL/WoSign.

Pour gérer les certificats de Let’s Encrypt, l’installation du client CLI dehydrated permet d’automatiser leur génération et leur renouvellement étant donné leur validité de trois mois :

# apt install dehydated

Premier étape, lister les certificats et les domaines associés (1 certificat par ligne) :

# vim /etc/dehydated/domains.txt
blog.hbis.fr www.hbis.fr

Enfin, le fichier de configuration :

# vim /etc/dehydratd/conf.d/letsencrypt.sh
BASEDIR="/var/lib/letsencrypt/"
WELLKNOWN="/var/www/hbis.fr/blog/html/.well-known/acme-challenge"
CONTACT_EMAIL="postmaster@hbis.fr"

Reste à lancer la génération :

# mkdir -p /var/lib/letsencrypt /var/www/hbis.fr/blog/html/.well-known/acme-challenge
# dehydrated -c --force

Les différents services sécurisés sont à réconfigurer:

# vim /etc/nginx/ssl-enabled/hbis
ssl on;
ssl_certificate /var/lib/letsencrypt/certs/blog.hbis.fr/fullchain.pem;
ssl_certificate_key /var/lib/letsencrypt/certs/blog.hbis.fr/privkey.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /var/lib/letsencrypt/certs/blog.hbis.fr/chain.pem;
# vim /etc/postfix/main.cf
smtpd_tls_CAfile = /var/lib/letsencrypt/certs/blog.hbis.fr/chain.pem
smtpd_tls_cert_file = /var/lib/letsencrypt/certs/blog.hbis.fr/cert.pem
smtpd_tls_key_file = /var/lib/letsencrypt/certs/blog.hbis.fr/privkey.pem
# vim /etc/dovecot/conf.d/10-ssl
ssl_cert = </var/lib/letsencrypt/certs/blog.hbis.fr/fullchain.pem
ssl_key = </var/lib/letsencrypt/certs/blog.hbis.fr/privkey.pem

Dernière étape, il est nécessaire de mettre en place un cron pour les renouveller automatiquement et relancer les services nécessaires:

# vim /etc/cron.montly/dehydrated
#!/bin/bash

/usr/bin/dehydrated -c &amp;amp;&amp;amp; systemctl restart nginx postfix dovecot
# chmod +x /etc/cron.montly/dehydrated

OpenSSL: récupérer la chaîne de certificats SSL d’un host

$ echo | openssl s_client -connect my.host.com:443 -showcerts 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > mycert.pem

Docker : inspecter les commandes healthcheck

Pour voir en temps réel les commandes healthcheck effectuées sur chacun des containers :

$ docker system events --filter event=exec_start
2017-01-19T14:53:32.979634882+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 fa7c8221a53e2a76e61f290c4008f67ea2548b923cc42a11e9234ee0db4cab54 (com.docker.compose.config-hash=b4b13e5e0066bd757aa944cc01869736eb1d150ac04516e19028d070ef5f502c, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=zabbix-agent, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/zabbix-agent, name=dev_zabbix-agent_1)
2017-01-19T14:53:33.985556968+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 a009ecbbb3cdce6da2bdf6ae073b9d323bcc2921eafc82206f7e4719e37a617a (com.docker.compose.config-hash=2e83302dfa763cf4185883bed56a64cd8e9207d3a78f06fd250bc158aafedde6, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=rabbitmq, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/rabbitmq, name=dev_rabbitmq_1)
2017-01-19T14:53:35.252389013+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 a7398fd76d95544ac6cd8d02fbacb9608d5fd3443c1afb4fa0b4606dc032476c (com.docker.compose.config-hash=3c3cae569ff98e6a7e91b8e6734bfed22e9c5df90c8bd593539ef4876e2bda25, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=mariadb, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/mariadb, name=dev_mariadb_1)
2017-01-19T14:53:39.875116453+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 1f41e9a3b5b63601042dbf5dcd758342e217f0f5d5685d76e9f61b2a2c155a5a (com.docker.compose.config-hash=733b83db2c39e867d08158e3101decdc5e3d70fa0653fea7f44139e29b47d2fa, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=dynamodb, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/dynamodb, name=dev_dynamodb_1)
Haut de page