La filosofía DevOps, por fortuna cada vez más común, utiliza herramientas para acelerar y automatizar la entrega de software, a través de las cuales los equipos de desarrollo y operaciones colaboran para crear, probar y desplegar aplicaciones con calidad y seguridad.
Las aplicaciones de DevOps en los productos de software normalmente se basan en un conjunto integrado de soluciones o ToolChain para eliminar pasos manuales, reducir errores y escalar con mayor facilidad, logrando así reducir el time to market y mejorar la calidad de los entregables.
Consciente de ello, Github presentó a finales de 2018 Github Actions, su herramienta de CI/CD. Con Github Actions podemos crear nuestros workflows en base a eventos de Github/git como “push”, “release”, “pull request”, etc.
En el siguiente diagrama se muestran los principales componentes de Github Actions.
Sobre los “Runners”
Github disponibiliza algunos “Runners” ya preparador para consumir en la nube:
- Ya configurados
- Sin mantenimiento
- Para varios S.O. disponibles, Windows, macOS, Linux y contenedores docker.
- Pago por uso (en función del plan).
- Puede no ser útil si tu configuración es muy específica.
Para evitar estos últimos puntos Github nos ofrece los “Self-Hosted Runners”:
- Podemos tenerlos en nuestra red y acceder a recursos propios.
- Configuración a medida
- No hay pago por uso.
- Hay que montar infraestructura propia y mantenerlo.
Automatizar con Github Actions el despliegue de recursos en AWS
El objetivo del caso de uso es conocer el funcionamiento de un workflow de Github Actions, y además utilizar algunas de las actions destinadas a interactuar con AWS. En este caso simplemente vamos a desplegar un bucket de S3 en una cuenta determinada.
Para ello vamos a seguir los siguientes pasos:
1. Creamos en Github un repositorio con un template de Cloudformation para la creación de un bucket en S3
2. Consultar “Actions” para AWS.
Como se ha comentado anteriormente las “actions” las podemos construir nosotros mismos, pero para procedimientos habituales suelen estar construidas por terceros, para este caso nos interesan las creadas por AWS.
En el siguiente enlace tenemos todo el listado de acciones disponibles:
https://github.com/aws-actions
Para nuestro ejemplo vamos a utilizar las siguientes acciones ya desarrolladas por Github y AWS:
- actions/checkout@v2
https://github.com/actions/checkout
Esta acción nos permite hacer checks-out bajo nuestro repositorio y que el workflow pueda acceder al él.
- aws-actions/configure-aws-credentials@v1
https://github.com/aws-actions/configure-aws-credentials
Nos permite establecer las credenciales de un usuario IAM (o asumir un rol) para poder realizar llamadas a la API de AWS.
- aws-actions/aws-cloudformation-github-deploy@master
https://github.com/aws-actions/aws-cloudformation-github-deploy
Esta acción recibe como argumento un nombre de stack de CloudFormation y el fichero con el template, y se encargará de crear el stack si existe o crear un “change set” si no existe. En la documentación de la acción podemos observar ejemplos de uso, y ejemplo de uso dentro de un workflow, también nos indica que debemos disponer de un usuario IAM para poder realizar el despliegue de la infraestructura en AWS, junto con las “policies” necesarias.
3. En AWS, creamos usuario IAM y policies asociadas tal y como nos indica la documentación
Creamos usuario IAM con la policy indicada en la documentación de la acción. Descargamos las credenciales generadas para ese usuario.
Añadimos las siguientes policies al usuario:
- Permisos sobre CloudFormation
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"cloudformation:DeleteStack"
],
"Resource": "*"
}
]
}
- Permisos creación de Buckets
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketPublicAccessBlock"
],
"Resource": "*"
}
]
}
4. En Github, a nivel de repositorio creamos los secretos con la “access key” y “secret key” asociadas al usuarios creado, y restringidas a los permisos dados por las políticas anteriormente explicadas.
5. Añadimos en el repositorio que hemos creado el archivo con el workflow que automatiza el despliegue de recursos en AWS
Los workflows se deben añadir siempre como ficheros yaml en la siguiente ruta: “.github/workflows”.
El workflow tiene la ventaja de ser un componente más de nuestro repositorio, con lo cual quedará registrado en git con sus cambios y evolución.
A continuación el workflow que vamos a utilizar:
on:
push:
branches:
- master
pull_request:
branches:
- master
name: Deploy to AWS
jobs:
deploy:
name: Github Actions Deploy
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Configure AWS credentials
id: creds
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: eu-west-1
- name: Deploy S3 Bucket
id: s3-bucket
uses: aws-actions/aws-cloudformation-github-deploy@v1
with:
name: s3-bucket-stack
template: iac/template.yml
no-fail-on-empty-changeset: "1"
capabilities: CAPABILITY_IAM,CAPABILITY_AUTO_EXPAND
En el apartado “on:” se indica qué evento de Github va a disparar la ejecución del workflow, para este caso, cuando se haga “pull” o “pull request” sobre la rama master.
A continuación se indica el nombre del workflow y del job, también en ese lugar se hace referencia al tipo de Runner sobre el que se ejecutará el workflow, en este caso “ubuntu-latest”.
En el apartado “steps”, es el lugar donde se añadirán las acciones secuencialmente, en este caso las que hemos definido anteriormente.
6. Visualización de workflows en Github Actions
En la pestaña “Actions” podemos visualizar todos los workflows ejecutados y sus correspondientes “jobs”:
Si vamos al detalle del “job”, se mostrará la ejecución de ese job y sus steps, indicando el resultado del “step” y la información que pueda sacar por consola.
Como se puede observar en la imagen, todos los pasos se han ejecutado correctamente, con lo cual el despliegue del bucket de S3 en AWS se ha realizado correctamente.
Alternativas a Github Actions
El mercado de herramientas CI/CD es muy amplio, quizá el que más destaca es Jenkins debido a su gran comunidad y maduración en el mercado. Pero últimamente están ganando terreno servicios SaaS que ofrecen también ventajas como una infraestructura gestionada, y gran integración con los servicios que las ofrecen.
A continuación un listado de soluciones de CI/CD equivalentes a Github Actions:
- GitLab Runner (SaaS)
- Bitbucket Pipelines (SaaS)
- CloudBees (Jenkins as a Service)
- CircleCI (SaaS)
- TravisCI (SaaS)
- buddy.works (SaaS)
- AWS CodePipeline
- Azure DevOps
Material Para profundizar en Github Actions
Finalmente algunos enlaces de interés para adentrarse en este mundillo:
- Repositorio con enlaces a documentación, Actions, recursos de la comunidad, utilidades, ejemplos, etc.
https://github.com/sdras/awesome-actions
- Github Actions
- AWS for Github Actions
https://github.com/aws-actions
- Documentación oficial
https://docs.github.com/en/actions
- Repositorio usado para el ejemplo
https://github.com/cantalejo84/github-actions-aws-deployer
Deja tu comentario