Saltar al contenido

Etiqueta: vsts

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

CI and CD con VSTS

Hola, aún en cuarentena aprovecho para hacer un breve post sobre integración y deploy continuo. Como deben de haber notado, luego de todo el proceso de desarrollo que hemos cubierto en algunos post que he realizado antes y con distintas tecnologías, siempre terminamos la demo realizando una prueba de nuestra aplicación mientras esta en debugging. Sin embargo, en un escenario real sabemos que esto es inviable. Dado, que necesitamos que nuestra aplicación este desplegada en un ambiente productivo. Cuando uno inicia en el mundo del desarrollo, probablemente no es quien se encargue de hacer los pases a producción y es muy probable dependiendo en que empresas estés trabajando, que este pase sea un simple «copiar y pegar» de una carpeta a otra manualmente, o que tengan una solución automatizada para llevar esto a cabo.

Esta última es la que me encargaré de desarrollar en este post. Yo he podido vivir ambos tipos de despliegue, siendo el más gratificante los últimos por que puedes ver que si bien es cierto la configuración inicial requiere más trabajo, además de tener ciertos conceptos claros, te permite automatizar los despliegues futuros eliminando el factor humado.

Primero, tengamos claro que para conseguir un proceso de CI y CD tenemos distintos stacks de tecnologías, entre las más grandes podríamos mencionar a azure, aws, jenkins, etc. Y también podemos encontrar variantes entre las que son libres y las que te ofrecen una serie de servicios adicionales como escalamiento y demás. Para la demo que voy a realizar, he decidido optar por hacerla usando VSTS (Visual Studio Team Services) que es basicamente un servicio ofrecido por microsoft que nos permite mapear todos los procesos del desarrollo de software, desde la gestión que se debe realizar hasta el despliegue. La estoy usando por sobre otras, por que es gratuita con sus limitaciones, y es accesible sólo con tener una cuenta de microsoft.

Mi idea, es generar un proyecto MVC con net core de 0, mapearlo a un repositorio como puede ser github, luego vincular nuestro repositorio a nuestro pipeline en VSTS y desde ahí configurar los archivos YAML indicandole los pasos que debe seguir. Para el hosting de nuestra aplicación demo, no estoy usando ninguna de las alternativas que ofrece Azure, por que quise hacerlo en un hosting propio en el que tengo una cuenta así que por medio de una tarea FTP, paso los archivos.

Primero, debo comentar que cuando queremos generar un proyecto con netcore desde la consola y no queremos usar la última versión que tengamos instalada, en cambio queremos indicarle una es necesario crear en la carpeta una archivo «global.json» indicandole esto al cli. Empecemos poniendo los comando que debemos usar para crear nuestra aplicación demo:

$ mkdir demo-mvc-ci-cd # creamos la carpeta donde alojaremos nuestra aplicación
$ cd demo-mvc-ci-cd # ingresamos a la carpeta
$ echo > global.json

En el archivo que hemos creado en necesario ingresar un json con la siguiente estructura.

{
    "sdk": {
      "version": "2.2.401"
    }
}

En el cual, como ven indicamos la versión del sdk queremos que se use. Una ves creado esto, podemos crear nuestra aplicación netcore.

$ dotnet new mvc # nuestra aplicación tendrá el mismo nombre de la carpeta
$ dotnet restore

Hasta aquí, tenemos nuestra aplicación en netcore creada, ahora inicializemos nuestra repositorio con git, previamente en mi caso he creado un repositorio en github para almacenar ahí nuestra aplicación.

$ git init
$ git add .
$ git commit -m "hola"
$ git remote add origin https://github.com/walberth/demo-mvc-ci-cd.git
$ git remote -v
$ git push origin master
$ git checkout -B "master" "origin/master"

Ya con nuestro código en github, es momento de ir a VSTS, les comento que con sólo tener una cuenta en microsoft (outlook, live, etc) ya tienes acceso a este servicio. Al inciar debemos crear un proyecto si es que aún no lo tenemos, en mi caso es un proyecto que he llamado demo.

Proyectos VSTS

En nuestro proyecto demo, podemos hacerle seguimiento a todos los procesos de desarrollo de software de nuestra aplicación. Sin embargo, nosotros vamos a centrarnos sólo en la integración y el deploy continuo. Vamos a la siguiente opción.

Opción del menú

Creamos un nuevo pipeline, y nos preguntará donde está nuestro código, en mi caso mi repositorio está en github así que le indicaré que lo obtenga de ahí señalándole el nombre del repositorio. Luego de esto nos pide que elijamos el tipo de tecnología que deseamos compilar, en nuestro caso elegimos net core y nos carga la siguiente plantilla:

Plantilla YAML

Acá debemos realizar varios cambios, veamos uno a los lo que debemos poner.

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'select'

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: false

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

En steps, debemos añadir tareas de netcore, la primera es para restaurar los nuggets que necesitemos, la segunda es realizar un build de nuestro código indicando que es en release, la tercera es realizar la publicación de nuestro compilado con netcore, dejándolo en «$(Build.ArtifactStagingDirectory)» que es una variable de entorno de VSTS y finalmente, la última tarea es para copiar ese compilado a la carpeta final en la que la tendremos lista para poder obtenerla desde nuestra tarea de despliegue continuo. Grabamos todos los cambios realizados.

Grabamos cambios

Cuando empieza a correr, tenemos la siguiente vista.

Actividad en la cola
Realiza las actividades

Como podemos ver en la última imagen, el proceso se a llevado a cabo de-acuerdo a lo que le hemos indicado, ha realizado todos los pasos y al final a desplegado el artefacto donde le indicamos que lo haga. Ahora vamos a ver como realizar el despliegue continuo.

Para esto, vamos a la opción de releases y creamos uno nuevo.

Creando un nuevo release

Seleccionamos el artefacto que vamos a usar y se lo indicamos al release.

Luego de añadirlo, es necesario que le indiquemos los pasos que vamos a usar acá tenemos un sin fin de opciones y de las más variadas, en mi caso simplemente realizaré una tarea FTP para que se conecte al site donde debe dejar el compilado. Si intentamos entrar a este site ahora tendremos la siguiente respuesta.

Respuesta del site antes de publicar

Agregamos nuestra tarea FTP.

Tarea FTP
Información FTP
Grabamos nuestro release
Realizamos el deploy
Realiza el proceso de despliegue

Si en este punto, validamos nuestra web, debería de tener nuestra aplicación ya desplegada.

Aplicación

Finalmente, hagamos un cambio en la aplicación, luego realizar un commit y push a master y luego de unos minutos deberíamos de tener nuestra despliegue realizado.

Cambio en la app

Luego de unos minutos que todo nuestro proceso automatizado se lleva a cabo, vemos nuestra web nuevamente y el cambio esta reflejado.

Cambio reflejado

Bueno, con esto concluyo el post que al final no salio tan chico. Espero que les sea de utilidad, igual pueden dejarme algún comentario o comunicarse conmigo por alguna de las redes sociales. No dejo link de github en este caso por que esta demo no iba enfocada en código.

Saludos.

1 comentario