Referencia del modelo de integración - AWS CodePipeline
Cómo funcionan los tipos de acciones de terceros con el integradorConceptosModelos de integración compatiblesModelo de integración de LambdaModelo de integración de procesos de trabajo

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Referencia del modelo de integración

Existen varias integraciones prediseñadas para servicios de terceros que ayudan a incorporar las herramientas existentes para los clientes en el proceso de lanzamiento de la canalización. Los socios, o proveedores de servicios externos, utilizan un modelo de integración para implementar los tipos de acciones que se utilizarán en CodePipeline.

Utilice esta referencia cuando planifique o trabaje con tipos de acciones que se gestionen con un modelo de integración compatible en CodePipeline.

Para certificar el tipo de acción de un tercero como socio de integración CodePipeline, consulte la Red de AWS socios (APN). Esta información es un complemento de la AWS CLI Reference.

Cómo funcionan los tipos de acciones de terceros con el integrador

Puede añadir tipos de acciones de terceros a las canalizaciones de los clientes para completar las tareas relacionadas con los recursos de los clientes. El integrador gestiona las solicitudes de trabajo y ejecuta la acción con él. CodePipeline En el siguiente diagrama, se muestra un tipo de acción de terceros creado para que los clientes lo utilicen en su proceso. Una vez que el cliente configura la acción, ésta se ejecuta y crea solicitudes de trabajo que administra el motor de acciones del integrador.

Imagen que muestra cómo el motor de acción del integrador gestiona los tipos de acciones y artefactos de terceros

En el diagrama se muestran los siguientes pasos:

  1. La definición de la acción se registra y está disponible en CodePipeline. La acción de terceros está disponible para los clientes del proveedor de terceros.

  2. El cliente del proveedor elige y configura la acción en CodePipeline.

  3. La acción se ejecuta y los trabajos se ponen en cola. CodePipeline Cuando el trabajo está listo CodePipeline, envía una solicitud de trabajo.

  4. El integrador (el trabajador de las encuestas de terceros APIs o de la función Lambda) recoge la solicitud de trabajo, devuelve una confirmación y trabaja en los artefactos de las acciones.

  5. El integrador devuelve el success/failure output (the job worker uses success/failure APIs or the Lambda function sends success/failure resultado (s) con el resultado del trabajo y un token de continuación.

Para obtener información sobre los pasos que puede seguir para solicitar, ver y actualizar un tipo de acción, consulte Trabajar con tipos de acciones.

Conceptos

En esta sección se utilizan los siguientes términos para los tipos de acciones de terceros:

Tipo de acción

Un proceso repetible que se puede reutilizar en canalizaciones que realizan las mismas cargas de trabajo de entrega continua. Los tipos de acciones se identifican mediante Owner, Category, Provider y Version. Por ejemplo:


            {

                "Category": "Deploy",
                "Owner": "AWS",
                "Provider": "CodeDeploy",
                "Version": "1"
            },

Todas las acciones del mismo tipo comparten la misma implementación.

Acción

Una instancia única de un tipo de acción, uno de los procesos discretos que tienen lugar dentro de una etapa de una canalización. Por lo general, esto incluye los valores de usuario específicos de la canalización en la que se ejecuta esta acción.

Definición de la acción

El esquema de un tipo de acción que define las propiedades necesarias para configurar la acción y los artefactos de entrada/salida.

Action execution (Ejecución de acciones)

Conjunto de trabajos que se han ejecutado para determinar si la acción realizada por el cliente se ha realizado correctamente o no.

Motor de ejecución de acciones

Propiedad de la configuración de ejecución de acciones que define el tipo de integración utilizado por un tipo de acción. Los valores válidos son JobWorker y Lambda.

Integración

Describe una pieza de software ejecutada por un integrador para implementar un tipo de acción. CodePipeline admite dos tipos de integración correspondientes a los dos motores de acción compatibles JobWorker yLambda.

Integrador

La persona propietaria de la implementación de un tipo de acción.

Trabajo

Un trabajo con el contexto del proceso y del cliente para ejecutar una integración. La ejecución de una acción se compone de una o más tareas.

Proceso de trabajo

El servicio que procesa las entradas del cliente y ejecuta un trabajo.

Modelos de integración compatibles

CodePipeline tiene dos modelos de integración:

  • Modelo de integración Lambda: este modelo de integración es la forma preferida de trabajar con los tipos de acciones en. CodePipeline El modelo de integración de Lambda utiliza una función de Lambda para procesar las solicitudes de trabajo cuando se ejecuta la acción.

  • Modelo de integración de proceso de trabajo: el modelo de integración del proceso de trabajo es el modelo utilizado anteriormente para las integraciones de terceros. El modelo de integración de trabajadores laborales utiliza un trabajador laboral configurado para ponerse en contacto con él y CodePipeline APIs procesar las solicitudes de trabajo cuando se ejecuta la acción.

A modo de comparación, en la siguiente tabla se describen las características de los dos modelos:

Modelo de integración de Lambda Modelo de integración de procesos de trabajo
Descripción El integrador escribe la integración como una función Lambda, que se invoca CodePipeline siempre que haya un trabajo disponible para la acción. La función de Lambda no sondea los trabajos disponibles, sino que espera hasta que se reciba la siguiente solicitud de trabajo. El integrador escribe la integración como un proceso de trabajo que consulta constantemente los puestos disponibles en la cartera del cliente. A continuación, el trabajador ejecuta el trabajo y envía el resultado del trabajo a través de. CodePipeline CodePipeline APIs
Infraestructura AWS Lambda Implemente el código de Job Worker en la infraestructura del integrador, como EC2 las instancias de Amazon.
Esfuerzo de desarrollo La integración solo contiene la lógica empresarial. La integración debe interactuar con la lógica empresarial, CodePipeline APIs además de contener la misma.
Esfuerzo operativo Menor esfuerzo operativo, ya que la infraestructura es solo AWS recursos. Mayor esfuerzo operativo porque el proceso de trabajo necesita su hardware independiente.
Tiempo máximo de ejecución de un trabajo Si la integración debe ejecutarse de forma activa durante más de 15 minutos, no se puede utilizar este modelo. Esta acción está destinada a los integradores que necesitan iniciar un proceso (por ejemplo, iniciar una creación a partir del artefacto de código del cliente) y devolver un resultado cuando finalice. No recomendamos que el integrador siga esperando a que finalice la compilación. En su lugar, devuelva una continuación. CodePipelinecrea un nuevo trabajo en otros 30 segundos si se recibe una continuación del código del integrador para comprobar el trabajo hasta que finalice. Con este modelo se pueden mantener trabajos de larga duración (horas/días).

Modelo de integración de Lambda

El modelo de integración de Lambda compatible incluye la creación de la función de Lambda y la definición del resultado para el tipo de acción de terceros.

Actualice su función Lambda para gestionar la entrada de CodePipeline

Puede crear una función de Lambda nueva. Puede añadir lógica empresarial a la función de Lambda, que se ejecuta siempre que haya un trabajo disponible en su proceso para su tipo de acción. Por ejemplo, dado el contexto del cliente y del proceso, es posible que desee empezar a desarrollar su servicio para el cliente.

Utilice los siguientes parámetros para actualizar la función Lambda desde la que gestionar la entrada. CodePipeline

Formato:

  • jobId:

    • El ID exclusivo del trabajo generado por el sistema.

    • Tipo: cadena

    • Patrón: [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}

  • accountId:

    • El ID de la AWS cuenta del cliente que se utilizará al realizar el trabajo.

    • Tipo: cadena

    • Patrón: [0-9]{12}

  • data:

    • Otra información sobre un trabajo que una integración utiliza para completar el trabajo.

    • Contiene un mapa de lo siguiente:

      • actionConfiguration:

        • Los datos de configuración de la acción. Los campos de configuración de la acción son una asignación de pares clave-valor para que el cliente introduzca valores. Las claves vienen determinadas por los parámetros clave del archivo de definición del tipo de acción al configurar la acción. En este ejemplo, los valores los determina el usuario de la acción especificando la información en los campos Username y Password.

        • Tipo: asignación de cadena a cadena, presente de forma opcional

          Ejemplo: 

          
    "configuration": {
        "Username": "MyUser",
        "Password": "MyPassword"
    },

      • encryptionKey:

        • Representa información sobre la clave utilizada para cifrar los datos del almacén de artefactos, como una AWS KMS clave.

        • Contenido: tipo de tipo de datos encryptionKey, disponible opcionalmente

      • inputArtifacts:

        • Lista de información sobre un artefacto en el que se va a trabajar, como, por ejemplo, una prueba o un artefacto de compilación.

        • Contenido: lista de tipo de datos Artifact, disponible opcionalmente

      • outputArtifacts:

        • Lista de información sobre el resultado de una acción.

        • Contenido: lista de tipo de datos Artifact, disponible opcionalmente

      • actionCredentials:

        • Representa un objeto de credenciales AWS de sesión. Estas credenciales son credenciales temporales emitidas por AWS STS. Se pueden usar para acceder a los artefactos de entrada y salida del bucket de S3 que se utiliza para almacenar los artefactos de la canalización CodePipeline.

          Estas credenciales también tienen los mismos permisos que la plantilla de declaraciones de política especificada en el archivo de definición del tipo de acción.

        • Contenido: tipo de tipo de datos AWSSessionCredentials, disponible opcionalmente

      • actionExecutionId:

        • El ID externo de la ejecución de la acción.

        • Tipo: cadena

      • continuationToken:

        • Un token generado por el sistema, como un ID de implementación, que necesita un trabajo para continuar con el trabajo de forma asíncrona.

        • Tipo: cadena, presente de forma opcional

Tipos de datos:

  • encryptionKey:

    • id:

      • El ID utilizado para identificar la clave. Para una AWS KMS clave, puede usar el ID de clave, el ARN de clave o el alias ARN.

      • Tipo: cadena

    • type:

      • El tipo de clave de cifrado, como una AWS KMS clave.

      • Tipo: cadena

      • Valores válidos: KMS

  • Artifact:

    • name:

      • El nombre del artefacto.

      • Tipo: cadena, presente de forma opcional

    • revision:

      • El ID de revisión del artefacto. Según el tipo de objeto, podría ser un ID de confirmación (GitHub) o un ID de revisión (Amazon S3).

      • Tipo: cadena, presente de forma opcional

    • location:

      • La ubicación de un artefacto.

      • Contenido: tipo de tipo de datos ArtifactLocation, disponible opcionalmente

  • ArtifactLocation:

    • type:

      • El tipo de artefacto en la ubicación.

      • Tipo: cadena, presente de forma opcional

      • Valores válidos: S3

    • s3Location:

      • Ubicación del bucket de S3 que contiene una revisión.

      • Contenido: tipo de tipo de datos S3Location, disponible opcionalmente

  • S3Location:

    • bucketName:

      • Nombre del bucket de S3.

      • Tipo: cadena

    • objectKey:

      • La clave del objeto en el bucket de S3 que identifica de forma exclusiva el objeto en el bucket.

      • Tipo: cadena

  • AWSSessionCredentials:

    • accessKeyId:

      • La clave de acceso secreta de la sesión.

      • Tipo: cadena

    • secretAccessKey:

      • La clave de acceso secreta de la sesión.

      • Tipo: cadena

    • sessionToken:

      • Ll token de la sesión.

      • Tipo: cadena

Ejemplo:

{
    "jobId": "01234567-abcd-abcd-abcd-012345678910",
    "accountId": "012345678910",
    "data": {
        "actionConfiguration": {
            "key1": "value1",
            "key2": "value2"
        },
        "encryptionKey": {
            "id": "123-abc",
            "type": "KMS"
        },
        "inputArtifacts": [
            {
                "name": "input-art-name",
                "location": {
                    "type": "S3",
                    "s3Location": {
                        "bucketName": "inputBucket",
                        "objectKey": "inputKey"
                    }
                }
            }
        ],
        "outputArtifacts": [
            {
                "name": "output-art-name",
                "location": {
                    "type": "S3",
                    "s3Location": {
                        "bucketName": "outputBucket",
                        "objectKey": "outputKey"
                    }
                }
            }
        ],
        "actionExecutionId": "actionExecutionId",
        "actionCredentials": {
            "accessKeyId": "access-id",
            "secretAccessKey": "secret-id",
            "sessionToken": "session-id"
        },
        "continuationToken": "continueId-xxyyzz"
    }
}

Devuelve los resultados de la función Lambda a CodePipeline

El recurso del proceso de trabajo del integrador debe devolver una carga útil válida en caso de éxito, fracaso o continuación.

Formato:

  • result: el resultado del trabajo.

    • Obligatorio

    • Valores válidos (no distingue entre mayúsculas y minúsculas):

      • Success: indica que un trabajo se ha realizado correctamente y es terminal.

      • Continue: indica que un trabajo se ha realizado correctamente y debe continuar, por ejemplo, si se vuelve a invocar al trabajador del trabajo para ejecutar la misma acción.

      • Fail: indica que se ha producido un error en un trabajo y es terminal.

  • failureType: un tipo de fallo que se va a asociar a un trabajo fallido.

    La categoría failureType de acciones de los socios describe el tipo de error que se produjo al ejecutar el trabajo. Los integradores configuran el tipo junto con el mensaje de error al devolver el resultado de un error en el trabajo a. CodePipeline

    • Opcional. Obligatorio si el resultado es Fail.

    • Debe ser nulo si result es Success o Continue

    • Valores válidos:

      • ConfigurationError

      • JobFailed

      • PermissionsError

      • RevisionOutOfSync

      • RevisionUnavailable

      • SystemUnavailable

  • continuation: el estado de continuación se pasará al siguiente trabajo dentro de la ejecución de la acción actual.

    • Opcional. Obligatorio si el resultado es Continue.

    • Debe ser nulo si result es Success o Fail.

    • Propiedades:

      • State: un hash del estado que se va a aprobar.

  • status: estado de la ejecución de la acción.

    • Opcional.

    • Propiedades:

      • ExternalExecutionId: un ID de ejecución externo o un ID de confirmación opcional para asociarlo al trabajo.

      • Summary: un resumen opcional de lo ocurrido. En los escenarios de error, se convierte en el mensaje de error que ve el usuario.

  • outputVariables: conjunto de pares clave/valor que se transfieren a la siguiente ejecución de la acción.

    • Opcional.

    • Debe ser nulo si result es Continue o Fail.

Ejemplo:

{
    "result": "success",
    "failureType": null,
    "continuation": null,
    "status": {
        "externalExecutionId": "my-commit-id-123",
        "summary": "everything is dandy"
    },
    "outputVariables": {
        "FirstOne": "Nice",
        "SecondOne": "Nicest",
        ...
    }        
}

Utilice los tokens de continuación para esperar los resultados de un proceso asíncrono

El token continuation forma parte de la carga útil y el resultado de la función de Lambda. Es una forma de transmitir el estado del trabajo CodePipeline e indicar que es necesario continuar con el trabajo. Por ejemplo, cuando un integrador inicia una compilación para el cliente a partir de su recurso, no espera a que la compilación se complete, sino que indica CodePipeline que no tiene un resultado definitivo devolviendo el result as continue y devolviendo el identificador único de la compilación a CodePipeline as continuation token.

nota

Las funciones de Lambda se pueden ejecutar durante un máximo de 15 minutos. Si el trabajo necesita ejecutarse durante más tiempo, puedes usa los tokens de continuación.

El CodePipeline equipo invoca al integrador después de 30 segundos con el mismo continuation token en su carga útil para comprobar si se ha completado. Si la compilación se completa, el integrador devuelve el resultado de éxito o error del terminal; de lo contrario, continúa.

Proporcione CodePipeline los permisos para invocar la función Lambda del integrador en tiempo de ejecución

Agrega permisos a la función Lambda de su integrador para proporcionar CodePipeline al servicio permisos para invocarlo mediante CodePipeline el principio del servicio:. codepipeline.amazonaws.com Puede agregar permisos mediante la línea de comandos AWS CloudFormation o. Para ver un ejemplo, consulta Trabajar con tipos de acciones.

Modelo de integración de procesos de trabajo

Una vez designado el flujo general de trabajo, puede crear el proceso de trabajo. Aunque los detalles específicos de la acción de terceros determinan lo que se necesita para el proceso de trabajo, la mayoría de los procesos de trabajo para acciones de terceros incluyen la siguiente funcionalidad:

  • Encuesta para obtener trabajos a partir del CodePipeline usoPollForThirdPartyJobs.

  • Reconocer los trabajos y devolver los resultados al CodePipeline usar AcknowledgeThirdPartyJobPutThirdPartyJobSuccessResult, yPutThirdPartyJobFailureResult.

  • Recuperar artefactos o insertarlos en el bucket de Amazon S3 de la canalización. Para descargar artefactos del bucket de Amazon S3 debe crear un cliente de Amazon S3 que utilice la versión 4 de Signature (Sig V4). Se requiere la firma V4 para AWS KMS.

    Para cargar artefactos al bucket de Amazon S3, también debe configurar la PutObject solicitud de Amazon S3 para que utilice el cifrado mediante AWS Key Management Service (AWS KMS). AWS KMS usos AWS KMS keys. Para saber si debe utilizar la clave Clave administrada de AWS o una gestionada por el cliente para cargar artefactos, su empleado debe revisar los datos del trabajo y comprobar la propiedad de la clave de cifrado. Si la propiedad está establecida, debe utilizar ese identificador de clave gestionado por el cliente al realizar la configuración AWS KMS. Si la propiedad clave es nula, utilice la Clave administrada de AWS. CodePipeline usa el, Clave administrada de AWS a menos que se configure de otra manera.

    Para ver un ejemplo que muestra cómo crear los AWS KMS parámetros en Java o.NET, consulte Especificar los parámetros AWS Key Management Service en Amazon S3 mediante AWS SDKs. Para obtener más información sobre el bucket de Amazon S3 para CodePipeline, consulteCodePipeline conceptos .

Elegir y configurar una estrategia de administración de permisos para el proceso de trabajo

Si quiere contratar a un empleado para su actividad externa CodePipeline, necesita una estrategia que integre la administración de usuarios y permisos.

La estrategia más sencilla consiste en añadir la infraestructura que necesita para su trabajador mediante la creación de EC2 instancias de Amazon con un rol de instancia AWS Identity and Access Management (IAM), lo que le permitirá ampliar fácilmente los recursos que necesita para la integración. Puede utilizar la integración integrada AWS para simplificar la interacción entre su empleado y CodePipeline.

Obtén más información sobre Amazon EC2 y determina si es la opción correcta para tu integración. Para obtener más información, consulte Amazon EC2 : Virtual Server Hosting. Para obtener información sobre la configuración de una EC2 instancia de Amazon, consulte Introducción a las instancias de Amazon EC2 Linux.

Otra estrategia que puede considerar es utilizar federación de identidades con IAM para integrar los recursos y el sistema de proveedor de identidad que ya tiene. Esta estrategia resulta útil si ya tiene un proveedor de identidad corporativo o una configuración que admita usuarios que utilicen proveedores de identidad web. La federación de identidades le permite conceder un acceso seguro a AWS los recursos CodePipeline, incluso sin tener que crear ni gestionar usuarios de IAM. Puede utilizar características y políticas sobre los requisitos de seguridad de contraseñas y la rotación de credenciales. Puede utilizar aplicaciones de ejemplo como plantillas para su propio diseño. Para obtener información, consulte Administrar federación.

Para dar acceso, agregue permisos a los usuarios, grupos o roles:

A continuación se muestra una política de ejemplo que puede crear para utilizarla con un proceso de trabajo de terceros. Esta política es solo un ejemplo y se ofrece "tal cual".

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codepipeline:PollForThirdPartyJobs",
        "codepipeline:AcknowledgeThirdPartyJob",
        "codepipeline:GetThirdPartyJobDetails",
        "codepipeline:PutThirdPartyJobSuccessResult",
        "codepipeline:PutThirdPartyJobFailureResult"
      ],
      "Resource": [
        "arn:aws:codepipeline:us-east-2::actionType:ThirdParty/Build/Provider/1/"  
      ]              
    }
  ]
}