¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Tomás Calleja 09/01/2020 Cargando comentarios…
Ú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.
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:
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.
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.
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.
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
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}"
}
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.
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:
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.
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}"
}
Como hemos visto, es muy sencillo tener todas las ventajas al aplicar IaC con Terraform para proyectos GCP centrados en serverless.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Estamos comprometidos.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.