Terraformando el serverless en GCP.

Últimamente se habla mucho de la IaC (Infraestructura como Código), principalmente de sus bondades. En este post, vamos a conocer las ventajas de aplicar IaC con Terraform a proyectos serverless en Google Cloud Platform.

¿En qué consiste la IaC?

La Infraestructura como Código es el tratamiento de la infraestructura y su configuración como se trata el código de una aplicación. Estas técnicas son posibles gracias a las APIs de las que disponen los proveedores de Cloud y es parte fundamental en la cultura DevOps.

Sus principales ventajas son:

• Una única fuente de verdad para la infraestructura y su configuración.
• Es automatizable y replicable.
• Mayor control gracias al uso de técnicas de control de calidad como las Merge Request.
• Al usarse con GIT tenemos la evolución de la infraestructura.
• Reducimos la complejidad de la gestión de grandes infraestructuras gracias al uso de módulos.

Entre las distintas herramientas del mercado para hacer IaC hemos seleccionado Terraform para este post por lo extendido de su uso y por estar mantenida, en parte, por trabajadores de Google. Nos vamos a centrar en el uso de Terraform para proyectos serverless y, si quieres conocer más sobre Terraform te recomendamos estos dos post, Terraform, la navaja suiza, y Terraform vs cloudformation.

¿Tiene sentido para proyectos serverless?

Después de escuchar estas ventajas seguro que no hay nadie que rechace abiertamente usarlo… a no ser que hagas serverless y entonces tu proceso lógico sea algo así: “Si IaC es Infraestructura como código y Serverless no tiene infraestructura que gestionar,
entonces Serverless no necesita IaC”.

Pues bien, en contra de esta lógica, veremos que usar IaC en entornos serverless nos aporta muchas ventajas. Además, cada vez, será más común ver IaC en desarrollos serverless, ya sea específicamente en este tipo de proyectos o como parte del stack de las compañías, integrando IaC en sus procesos DevOps.

Manos a la obra

Una vez que ya hemos visto los conceptos básicos vamos a empezar a usar Terraform con GCP. En cada apartado veremos cómo sacar partido de Terraform en distintas situaciones.

Instalando Terraform en la cloud shell

Una de las maneras más fáciles de instalar Terraform es hacerlo en nuestro entorno de trabajo a través de la cloud shell. Cloud shell es un terminal linux accesible desde la web que nos deja acceder a una máquina virtual que está asociada a nuestra cuenta de usuario en GCP y es independiente del proyecto. Una vez instalado Terraform podremos usarlo desde cualquier ordenador sin necesidad de tener una máquina funcionando… como dijo aquel: “si vamos a serverless, vamos a serverless”.

Si en lugar de tener que hacer la descarga y la validación a mano lo hace un contenedor por nosotros, mucho mejor. Aquí tenéis los comandos para instalar Terraform y dar los permisos necesarios.

$ docker run -v $HOME/bin:/software sethvargo/hashicorp-installer terraform 0.11.10
$ sudo chown -R $(whoami):$(whoami) $HOME/bin/
$ export PATH=$HOME/bin:$PATH

Una vez instalado solo nos queda crear un directorio con algún fichero .tf, inicializar el git y lanzar estos tres comandos:

1 - Para instalar dependencias, solo se ejecuta una vez:

$ terraform init 

2 - Para ver los cambios a realizar:

$ terraform plan 

3 - Para aplicar los cambios:

$ terraform apply

Creando un proyecto

Aunque muchas veces empezaremos a usar Terraform sobre proyectos ya creados (en ese caso indicaremos el proyecto como variable), en otras ocasiones nos será muy útil poder crear proyectos directamente desde Terraform. En este ejemplo, vemos cómo crear una carpeta en nuestra organización y luego cómo crear un proyecto dentro de esa carpeta. Recordemos que es una buena práctica tener todos los proyectos que necesitamos y usar una estructura de carpetas para facilitar la gestión de los proyectos.

resource "google_folder" "department1" {
     display_name = "Business department"
     parent       = "organizations/1234567"
}
resource "google_project" "my_project-in-a-folder" {
     name       = "My amazing Project"
     project_id = "my-project-id"
     folder_id  = "${google_folder.department1.name}"
}

Seguridad - Control de la infraestructura

Según el principio de la proble-dinámica los problemas no se crean ni se destruyen, sino que se transforman. En este caso, los problemas de recursos no suelen existir en proyectos cloud a cambio de tener mucho cuidado con no arruinarnos usando configuraciones demasiado altas o parametrizando mal algún servicio. Por supuesto, esto no quita la necesidad de establecer budgets y alertas a los proyectos.

Gracias a la IaC es mucho más fácil controlar y revisar que los parámetros usados son los necesarios y no hay ninguna barbaridad.

Activando las APIs y gestionando las cuentas de usuario

La teoría está clara y nos la sabemos todos: dar solo los permisos necesarios, no reutilizar cuentas de usuarios y activar solo los servicios que vamos a usar. Pero, en la práctica, todo se complica y se suele tender a ser más “pragmático”. Terraform nos ayuda a solucionar esto de dos maneras:

• Proceso revisable y auditable. Al quedar en el repositorio la persona que realiza el cambio en los permisos es fácil añadir un paso de revisión. Por ejemplo, mediante Merge request y separando los roles de las personas que definen y las que aplican los cambios.
• Reutilización. Las configuraciones de permisos entre proyectos son mucho más fáciles de reutilizar cuando usamos Terraform y especialmente con el uso de variables.

En este ejemplo vemos como crear una service account y darle un rol:

resource "google_service_account" "cicd-sa" {
         project = "${var.projectId}"
         account_id   = "cicd-sa"
         display_name = "A service account for cicd"
     } 
resource "google_project_iam_member" "createTokenForGAEsa" {
         project = "${var.projectId}"
         role    = "roles/iam.serviceAccountTokenCreator"
         member = "serviceAccount:${var.projectId}@appspot.gserviceaccount.com", 
     }

Aquí tenemos un ejemplo de cómo habilitar el servicio de vision API:

 resource "google_project_service" "project" {
         project = "example-project"
         service = "vision.googleapis.com"
         disable_dependent_services = true
     }

Como podemos ver en los ejemplos, de esta manera es muy fácil crear todas las cuentas de usuarios necesarias independientemente del número de proyectos y entornos que tengamos.

Control de las zonas de los servicios

Por motivos que se escapan a mi entendimiento, la región donde configuramos App Engine por primera vez no puede ser modificada y, encima, esta configuración también afecta a la región donde se ejecutará datastore. Al automatizar el proceso con Terraform nos aseguramos de que los servicios se crean en las zonas correctas (cumpliendo la GDPR). A parte de este ejemplo, otros muchos servicios GCP no funcionan si no están en la misma zona o, peor, funcionarán con mayor latencia y mucho más coste al generar tráfico entre regiones. Gracias al uso de variables en Terraform nos aseguramos que todos nuestros componentes están en la zona esperada.

En este ejemplo vemos cómo podemos definir una variable zona para luego usarla al inicializar App Engine:

variable "projectId" {
         type = "string"
         default = "example-project-id"
}
variable "regionGAE" {
         type = "string"
         default = "europe-west"
}
resource "google_app_engine_application" "app" {
         project = "${var.projectId}"
         location_id = "${var.regionGAE}"
}

Conclusión

Como hemos visto, es muy sencillo tener todas las ventajas al aplicar IaC con Terraform para proyectos GCP centrados en serverless.