Cómo desplegar InfluxDB v2.0 con Traefik y soporte SSL en DigitalOcean usando Terraform
Si te gusta automatizar como a mi, este artículo te va a gustar. Aprende sobre esta receta para desplegar InfluxDB v2.0 con Traefik, en DigitalOcean usando Terraform.
Hace rato no hacía nada nada como esto, así que la semana pasada me puse a jugar para crear un automatismo en Terraform que permita desplegar InfluxDB v2.0 atrás de Traefik con soporte SSL de Let's Encrypt en DigitalOcean.
El motivo es el inminente lanzamiento de InfluxDB v2.0 OSS y es parte de la contribución que hago hacia la comunidad como parte del programa InfluxAces.
¿Qué es lo que hace esta receta?
Esta receta de Terraform hace lo siguiente:
- Inicializa el proveedor de DigitalOcean
- Lleva tu llave SSH hacia DigitalOcean
- Crea un dominio .com y un subdominio llamado influx.tudominio.com
- Crea la máquina virtual y luego asocia el subdominio a ese droplet.
- Crea archivos y carpetas necesarias para luego poder montar los volúmenes en los contenedores.
- Instala Docker y Docker Compose.
- Despliega los contenedores de InfluxDB y Traefik.
- Se crea el certificado SSL con Let's Encrypt para que el acceso y la inyección de data hacia InfluxDB se haga por SSL.
Esta receta la pueden encontrar aquí, con bastante explicación (En inglés).
xe-nvdkCómo desplegar esta receta
Antes de comenzar a configurar y a desplegar, debemos descargar la receta y hacer la modificación a los archivos dependiendo de nuestras necesidades.
Lo primero que vamos a hacer es hacer un git clone de esta receta:
$ git clone https://github.com/xe-nvdk/terraform-recipes.gitEso va a bajar todo el repositorio, así que navegamos hasta la carpeta llamada "influxdbv2.0-traefik-do"
$ cd influxdbv2.0-traefik-doAhí adentro vamos a encontrar estos archivos:
drwxrwxrwx 1 nacho nacho 4096 Sep 17 12:12 ./
drwxrwxrwx 1 nacho nacho 4096 Sep 17 11:11 ../
-rwxrwxrwx 1 nacho nacho 107 Sep 17 11:11 auth.tf*
-rwxrwxrwx 1 nacho nacho 282 Sep 17 11:11 copy.tf*
-rwxrwxrwx 1 nacho nacho 295 Sep 17 11:11 dns.tf*
-rwxrwxrwx 1 nacho nacho 1540 Sep 17 11:11 docker-compose.yml*
-rwxrwxrwx 1 nacho nacho 267 Sep 17 11:11 droplet.tf*
-rwxrwxrwx 1 nacho nacho 756 Sep 17 11:11 id_rsa.pub*
-rwxrwxrwx 1 nacho nacho 532 Sep 17 11:11 readme.md*
-rwxrwxrwx 1 nacho nacho 150 Sep 17 11:11 ssh.tf*
-rwxrwxrwx 1 nacho nacho 195 Sep 17 11:11 userdata.yaml*Veamos cuales archivos debemos modificar:
El archivo auth.tf y el copy.tf no deberíamos tocarlo. El que si debemos modificar es el dns.tf, ahí debemos especificar nuestro dominio y el subdominio que vamos a crear.
resource "digitalocean_domain" "cduser" {
name = "cduser.com"
}
# create subdomain for influxdb
resource "digitalocean_record" "influx" {
domain = "digitalocean_domain.cduser.name"
type = "A"
name = "influx"
ttl = "35"
value = "digitalocean_droplet.influxdb.ipv4_address"
}En este ejemplo 👆 vemos que el dominio que estoy especificando es cduser.com y luego poquito más abajo específico que el subdominio se va a llamar influx, con lo que quedaría influx.cduser.com.
Lo siguiente a modificar el docker-compose.yml que la receta copiará al droplet para desplegar los contenedores:
version: "3.3"
services:
traefik:
container_name: traefik
image: "traefik:latest"
command:
- --entrypoints.web.address=:80
- --entrypoints.websecure.address=:443
- --providers.docker
- --api
- --certificatesresolvers.leresolver.acme.httpchallenge=true
- --certificatesresolvers.leresolver.acme.email=<tu-email>
- --certificatesresolvers.leresolver.acme.storage=/acme.json
- --certificatesresolvers.leresolver.acme.httpchallenge.entrypoint=web
ports:
- "80:80"
- "443:443"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "./acme.json:/acme.json"
labels:
# global redirect to https
- "traefik.http.routers.http-catchall.rule=hostregexp(`{host:.+}`)"
- "traefik.http.routers.http-catchall.entrypoints=web"
- "traefik.http.routers.http-catchall.middlewares=redirect-to-https"
# middleware redirect
- "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"
influxdbv2:
container_name: influxdb
image: quay.io/influxdb/influxdb:2.0.0-beta
volumes:
- /influxdb:/root/.influxdbv2/
labels:
- "traefik.http.routers.influx.rule=Host(`influx.cduser.com`)"
- "traefik.http.routers.influx.entrypoints=websecure"
- "traefik.http.routers.influx.tls=true"
- "traefik.http.routers.influx.tls.certresolver=leresolver"
- "traefik.http.services.influx.loadbalancer.server.port=9999"
- "traefik.http.routers.influx.service=influx"Acá 👆, lo que deberías modificar sería la siguiente línea, poniendo tu dirección de email. Esto es para el registro de Let's Encrypt.
- --certificatesresolvers.leresolver.acme.email=<tu-email>Lo siguiente es esta línea, que iría con tu dominio y el subdominio que hayas elegido en el dns.tf
- "traefik.http.routers.influx.rule=Host(`influx.cduser.com`)"El siguiente archivo para modificar, aunque es totalmente opcional, es el droplet.tf, este archivo, tiene información sobre el nombre del droplet que se va a crear y el tamaño del mismo. Esto puede cambiarse pero para este proyecto podemos dejarlo tal como está.
El siguiente archivo para modificar, también de forma opcional es el ssh.tf. Esto lo que va a hacer es llevar un archivo id_rsa.pub (tu llave publica). Lo único a tener en cuenta aquí es el path donde está esa llave para poder subirla.
El archivo userdata.yml contiene la instrucciones de que es lo que va a hacer apenas el droplet esté creado. Si haces un cambio aquí, sobre todo en la parte de generación de archivos, asegurate que estén reflejados en el docker-compose.yml de más arriba.
Una vez que tenemos todo pronto, pasamos el token de autenticación como variable. Pueden consultar este pique sobre cómo tener una y pasarla como variable de autenticación para luego usarla con Terraform.
Ignacio Van Droogenbroeck
Una vez que pasamos esta variable ejecutamos...
$ terraform initEl resultado debería ser algo como esto:
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/null...
- Finding latest version of digitalocean/digitalocean...
- Installing hashicorp/null v2.1.2...
- Installed hashicorp/null v2.1.2 (signed by HashiCorp)
- Installing digitalocean/digitalocean v1.22.2...
- Installed digitalocean/digitalocean v1.22.2 (signed by a HashiCorp partner, key ID F82037E524B9C0E8)
Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/plugins/signing.html
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.
* digitalocean/digitalocean: version = "~> 1.22.2"
* hashicorp/null: version = "~> 2.1.2"
Terraform has been successfully initialized!Luego, ejecutamos el plan.
$ terraform planEn el siguiente resultado, nos aseguramos de que lo que va a hacer es lo que queramos que haga:
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# digitalocean_domain.cduser will be created
+ resource "digitalocean_domain" "cduser" {
+ id = (known after apply)
+ name = "cduser.com"
+ urn = (known after apply)
}
# digitalocean_droplet.influxdb will be created
+ resource "digitalocean_droplet" "influxdb" {
+ backups = false
+ created_at = (known after apply)
+ disk = (known after apply)
+ id = (known after apply)
+ image = "ubuntu-20-04-x64"
+ ipv4_address = (known after apply)
+ ipv4_address_private = (known after apply)
+ ipv6 = false
+ ipv6_address = (known after apply)
+ ipv6_address_private = (known after apply)
+ locked = (known after apply)
+ memory = (known after apply)
+ monitoring = false
+ name = "influxdb"
+ price_hourly = (known after apply)
+ price_monthly = (known after apply)
+ private_networking = (known after apply)
+ region = "nyc1"
+ resize_disk = true
+ size = "s-1vcpu-1gb"
+ ssh_keys = (known after apply)
+ status = (known after apply)
+ urn = (known after apply)
+ user_data = "8e8667350e70e051949e95c4ca5f40e09870abf7"
+ vcpus = (known after apply)
+ volume_ids = (known after apply)
+ vpc_uuid = (known after apply)
}
# digitalocean_record.influx will be created
+ resource "digitalocean_record" "influx" {
+ domain = "digitalocean_domain.cduser.name"
+ fqdn = (known after apply)
+ id = (known after apply)
+ name = "influx"
+ ttl = 35
+ type = "A"
+ value = "digitalocean_droplet.influxdb.ipv4_address"
}
# digitalocean_ssh_key.influx will be created
+ resource "digitalocean_ssh_key" "influx" {
+ fingerprint = (known after apply)
+ id = (known after apply)
+ name = "influx"
+ public_key = "id_rsa.pub"
}
# null_resource.copy-docker-compose will be created
+ resource "null_resource" "copy-docker-compose" {
+ id = (known after apply)
}
Plan: 5 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.Si todo está bien, ejecutamos...
$ terraform applyAparecerá un output como el del terraform plan, la diferencia es que solo tipeamos "yes".
Después de confirmar, veremos algo como esto (Reduje el output para no hacerlo tan largo):
digitalocean_ssh_key.influx: Creating...
digitalocean_ssh_key.influx: Creation complete after 3s [id=28453867]
digitalocean_droplet.influxdb: Creating...
digitalocean_droplet.influxdb: Still creating... [10s elapsed]
digitalocean_droplet.influxdb: Still creating... [20s elapsed]
digitalocean_droplet.influxdb: Creation complete after 24s [id=208013743]
null_resource.copy-test-file: Creating...
null_resource.copy-test-file: Provisioning with 'file'...
null_resource.copy-test-file: Still creating... [10s elapsed]
null_resource.copy-test-file: Creation complete after 20s [id=8765686804275944894]
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.Después de unos minutos (de 2 a 3 minutos) podremos apuntar nuestro navegador al subdominio y deberíamos ver el setup de InfluxDB. Ten en cuenta que tal vez aún no esté el certificado SSL pero eso es cuestión de apenas unos minutos más.
Si todo salió bien, deberíamos ver la página de bienvenida de InfluxDB.
Para ir cerrando
Automatizar es una de las cosas que más me gusta hacer y sobre todo hacerlo combinando varias tecnologías y proveedores como es este caso, si ves, combine no solo software, sino también servicios.
Algo importante, al momento de escribir este artículo, InfluxDB v2.0 no esta listo para producción, lo que se despliega con esta receta es la Beta 16. Para cuando salga 2.0, seguramente actualizaré esta receta para que soporte esa versión y ver si puedo agregarle el setup de InfluxDB para que simplemente, después de ejecutar estemos listos para loguearnos.
Espero les haya gustado, ojala lo prueben y me cuenten qué les pareció.
