Saltar al contenido

Etiqueta: c#

Integrando AWS Lambda a un Pipeline de Azure Devops

Hola, espero que estén bien. Este post es una continuación al post anterior, en el cual revisamos como podemos realizar el deploy de un api en un AWS Lambda. Ahora seguiremos con lo que es más lógico que suceda luego de hacer esto, automatizar este proceso. En post anteriores, he mostrado el uso de Azure Devops para los procesos de devops que uso, veamos como realizamos en este caso.

Primero, debemos tener creado un rol en IAM para que nuestro pipeline de devops se pueda authenticar. Con esto realizado, ingresar a azure devops y nos dirigimos a la siguientes opción.

Configuramos una nueva credencial
Elegimos AWS

Con esto hecho, vamos a AWS para crear un bucket, que es donde configuraremos luego para que nuestra pipeline deje los archivos.

Creamos un nuevo bucket

En nuestro pipeline, vamos a seleccionar la siguiente tarea.

Tarea a seleccionar
Información a completar

Para que funcione nuestro proceso de devops, es necesario crear una serie de archivos en nuestro proyecto, son dos los archivos, el primero es “serverless.template” y “aws-lambda-tools-defaults.json”. Les dejo el detalle de la información que va en cada archivo y les comento cual es la información que debe variar.

serverless.template

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Transform": "AWS::Serverless-2016-10-31",
  "Description": "An AWS Serverless Application that uses the ASP.NET Core framework running in Amazon Lambda.",
  "Parameters": {},
  "Conditions": {},
  "Resources": {
    "AspNetCoreApi": {
      "Type": "AWS::Serverless::Api",
      "Properties": {
        "StageName": "Prod",
        "BinaryMediaTypes": [
          "*~1*"
        ]
      }
    },
    "AspNetCoreFunction": {
      "Type": "AWS::Serverless::Function",
      "Properties": {
        "Handler": "Exphadis.Services.WebApi::Exphadis.Services.WebApi.LambdaEntryPoint::FunctionHandlerAsync",
        "Runtime": "dotnetcore3.1",
        "CodeUri": "",
        "MemorySize": 512,
        "Timeout": 30,
        "Role": null,
        "Policies": [
          "AWSLambda_FullAccess"
        ],
        "Environment" : {
          "Variables" : {
            "ASPNETCORE_ENVIRONMENT" : "",
            "SENTRY_CONNECTION" : "",
            "DATABASE_CONNECTION" : "",
            "JWT_KEY" : "",
            "JWT_EXPIRATION" : ""
          }
        },
        "Events": {
          "ProxyResource": {
            "Type": "Api",
            "Properties": {
              "Path": "/{proxy+}",
              "Method": "ANY",
              "RestApiId": {
                "Ref": "AspNetCoreApi"
              }
            }
          },
          "RootResource": {
            "Type": "Api",
            "Properties": {
              "Path": "/",
              "Method": "ANY",
              "RestApiId": {
                "Ref": "AspNetCoreApi"
              }
            }
          }
        }
      }
    }
  },
  "Outputs": {
    "ApiURL": {
      "Description": "Site for Exphadis Support",
      "Value": {
        "Fn::Sub": "https://${AspNetCoreApi}.execute-api.${AWS::Region}.amazonaws.com/site/"
      }
    }
  }
}

Consideren, que deben modificar de esta plantilla:

  • Handler
  • Environment – Variables

aws-lambda-tools-defaults.json

{
    "Information" : [
        "All the command line options for the Lambda command can be specified in this file."
    ],
    "profile"     : "default",
    "region"      : "us-east-1",
    "configuration" : "Release",
    "framework"     : "netcoreapp3.1",
    "s3-prefix"     : "exphadis-service/",
    "template"      : "serverless.template",
    "template-parameters" : "",
    "s3-bucket"           : "exphadis-service",
    "stack-name"          : "Exphadis-Service-Serverless"
}

Consideren modificar la información que visualizan, de-acuerdo al escenario que tengan.

Veamos como tendría que quedar nuestro archivo “pipeline.yml”.

trigger:
  - feature/deploy-lambda

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
  - task: LambdaNETCoreDeploy@1
    name: 'Deploy_Lambda'
    displayName: 'Deploy to lambda'
    inputs:
      awsCredentials: 'AWS Admin'
      regionName: 'us-east-1'
      command: 'deployServerless'
      packageOnly: false
      lambdaProjectPath: '$(System.DefaultWorkingDirectory)\\Exphadis.Services.WebApi'
      stackName: 'Exphadis-Service-Serverless'
      s3Bucket: 'exphadis-service'
      s3Prefix: 'Exphadis.Services.WebApi/'


Notemos especificamente estas partes.

Información importante

Fuera de elegir las credenciales que ya hemos configurado previamente, la región, es necesario indicar:

  • lambdaProjectPath: La ruta en nuestro proyecto donde está nuestro entrypoint para lambda.
  • stackName: El nombre de nuestro lambda
  • s3Bucket: El nombre del bucket en S3 que hemos creado
  • s3Prefix: El prefijo de la carpeta en la que se va a desplegar nuestra proyecto compilado.

Probemos ahora toda nuestra configuración.

Despliegue en lambda desde azure devops

Finalmente, validamos en AWS este cambio.

Publicación visualizada desde AWS
Consumo del api

La demo de todo lo anteriormente explicado, pueden revisarla en el siguiente video.

Espero que les sea util, si tienen alguna duda, los espero en la sección de comentarios.

Saludos.

Deja un comentario

Caching en Web API Net Core 2.2

Para nadie es sorpresa que la tendencia en el desarrollo con tencologias Backend de Microsoft se orienta cada vez más a NetCore, estando como release candidate (a la fecha de hoy) la versión 3.0.

Hace un tiempo que vengo trabajando con NetCore, inicialmente en proyectos personales y luego en el trabajo. El tema que hoy nos reclama es como aplicar caching y concurrency en las web api cuando se trabaja con Net Core. Para ello, primero recordemos un poco que implica caching.

Cuando nos referimos a caching es válido entender que brindamos un determinado tiempo de vida a una solicitud http, lo cual nos permite no volver a consultar el mismo recurso por el tiempo que se ha determinado, esto nos permite optimizar los tiempos de respuesta y el consumo de recursos en el servidor.

Existen tipos de caching, para entender mejor esta idea, revisemos la siguiente imagen:

caching types

  • Client Cache: Usualmente podemos encontrarlos en el navegador, almacenan las respuestas de las peticiones http individualmente si estas así lo indican, es privado porque los recursos que se están almacenando no se comparten con nadie más.
  • Gateway Cache: Es un cache compartido, los recursos son usados por multiples aplicaciones.
  • Proxy Cache: Tambien es un cache compartido, sin embargo su embergadura es mayor, es usualmente usado por corporaciones grandes o provedores de internet.

Del mismo modo, cuando se trabaja con caching, tenemos que tener un poco más claro que significa el “Modelo de expiración”, esta es una forma de indicarle a los clientes, cuanto tiempo va a durar una solicitud, lo cual permite indicarle a las aplicaciones clientes por cuanto tiempo se va a entender que una respuesta http se considera activa. Para conseguir este objetivo se usan dos header comunmente:

  • Expires Hader: Es el más simple, contiene una marca de tiempo de la expiración, pero se asume que las horas entre el cliente y el servidor están sincronizadas.
  • Cache Control Header: Permite indicar el tiempo como “max-age” lo cual indica estará activo por 60 segundos, y public indica quienes pueden realizar el caching de esta respuesta http (client, gateway o proxy).

Es necesario hablar también sobre los modelos de validación o “Validation Model” , estos nos permiten validar si la solicitud http ha sido modificada y de este modo mantenemos la integridad de nuestra solicitud.

  • Strong Validators: Usan los “ETag” para validar si la respuesta ha sido modificada.
  • Weak Validators: No siempre cambian cuando la respuesta lo hace, sólo cambian en cambios considerables, se basan en una etiqueta de “Last-Modified”, recordemos que los horarios deben estar sincronizados. También poseen weak Etag.

Finalmente, para culminar con la teoría, es necesario hablar sobre “Cache-control directives”, las cuales son las directivas que se pueden enviar en el request y el response http:

  • Response: Tenemos elementos de control que nos indican el tiempo de duración máximo (en segundos) de la solicitud, si es posible almacenarla en el navegador (private) o en el servidor (public) entre otras.
  • Request: Del mismo modo, tenemos elementos que nos valida el tiempo de duración de la respuesta mínimo y máximo entre otras.

Para la demo que vamos a realizar, usaremos un nugget llamado “Marvin.Cache.Headers”, luego de instalarlo nos dirigimos al archivo de configuración “Startup” de nuestro web api.

Es necesario agregar en el “ConfigurationService” y en el “Configure” que se debe añadir el uso de cacheheader al pipeline de ejecución, adicionalmente estoy sobreescribiendo el timepo de expiración de la solicitud e indicandole que se debe revalidar.

Sólo con está configuración, ya tenemos habilitado el uso de caching, en su modo más básico. Probemos en postman el uso de lo implementado, primero debemos habilitar el envío de “cache-control” en el header, esto se hace de la siguiente manera:

La petición que llevaremos a cabo, es la siguiente:

Como pueden ver es un GET a un endpoint que en el query esta buscando los libros de un determinado autor. Pongamos un punto de interrupción para validar que la petición a llegado, y veamos la respuesta que recibimos.

Como podemos ver, el tiempo de vida de la petición es 30 segundos, de modo que si se volviera a hacer otra petición, esta no llegaria a nuestro endpoint, en cambio nos indicaria el timepo de vida que aún tiene la solicitud que hemos realizado.

Les dejo link al repositorio en github en el cual pueden encontrar el proyecto completo y el video de youtube donde pueden visualizar las pruebas.

REPO: GITHUB

Saludos.

Deja un comentario