Tipos de activos comunes

Los activos pueden adoptar muchas formas en su canal de distribución:

• Confirmaciones de código fuente- El código que se está construyendo y probando
• Imágenes de contenedor- Docker imágenes producidas por sus compilaciones
• Artefactos de implantación: manifiestos Kubernetes, gráficos Helm o archivos de configuración
• Ejecución del pip eline - La propia ejecución del pipeline

El siguiente diagrama muestra los distintos tipos de activos admitidos en DevSecOps:

Cómo identificar los activos

Cada activo debe identificarse de forma única e inmutable. Esto garantiza que las pruebas recopiladas para un activo siempre se refieran exactamente al mismo artefacto, aunque su canalización se ejecute varias veces.

Formatos de identificación de activos:

• Commit Asset: Repositorio y hash del commit

  https://repo.url/org/repo#<COMMIT-SHA>
  

• Activo de imagen: Docker image and its digest

  docker://registry.URL/name@sha256:<SHA256-DIGEST>
  

• Pipeline Run Asset: Pipeline e ID de ejecución

  pipelinerun://<PIPELINE_ID>/<RUN_ID>
  

• Otros activos: Ejemplos totalmente cualificados URL

  • Confirmar activo con nombre de archivo (gráfico de timón o archivo de configuración):

    https://repo.url/org/repo#<COMMIT-SHA>/<filename>
    

  • Activo artefacto:

    <artifactory-url>/artifact.<filetype>
    

Utilice identificadores inmutables (SHA de confirmaciones, compendios de imágenes) en lugar de etiquetas mutables (etiquetas, ramas) para garantizar que las pruebas siempre hagan referencia a la versión exacta del artefacto.

Guardar información del repositorio

Cuando su pipeline comprueba el código fuente, utilice save_repo comando para registrar los detalles del repositorio. Esto asocia sus artefactos de compilación con el commit específico que los produjo.

Ejemplo:

save_repo app-repo \
  url=<app_url> \
  path=my-app \
  commit=commit1 \
  branch=master \
  buildnumber=1

Guardar información sobre artefactos

Después de crear artefactos (imágenes, archivos de despliegue, etc.), utilice save_artifact comando para registrar sus detalles. En él se recogen el nombre, el tipo, el resumen y la procedencia del artefacto.

Cuándo utilizarlo:

• Después de crear una imagen Docker
• Después de generar los manifiestos de despliegue
• Después de crear cualquier artefacto que vaya a desplegarse

Ejemplo: Guardar una imagen Docker

Después de que su pipeline construye y empuja una imagen Docker:

save_artifact app-image \
  name=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  type=image \
  digest=sha256:sha2561 \
  tags=mytag1 \
  source=<source_url> \
  signature=sign-1 \
  provenance=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561

Ejemplo: Guardar un artefacto de despliegue

Para artefactos que no sean imágenes, como los manifiestos de Kubernetes o los gráficos de Helm:

save_artifact artifact-1 \
  name=my-app_IKS_deployment \
  type=deployment \
  signature=sign2 \
  deployment_type=IKS \
  provenance=<url>

Comprender los parámetros de inventario

Utilice el comando cocoa inventory add con los siguientes parámetros:

Creación de entradas de inventario

Los siguientes ejemplos muestran cómo crear entradas de inventario para distintos tipos de activos. Observe cómo los parámetros coinciden con la información guardada anteriormente con save_artifact.

Ejemplo: Registro de una imagen Docker en el inventario

Este ejemplo crea una entrada de inventario para la imagen Docker que guardamos anteriormente:

cocoa inventory add \
  --artifact=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  --name=my-app \
  --app-artifacts='{ "app": "my-app", "tags": "20230828074614-master-commit1" }' \
  --signature=sign1 \
  --provenance=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  --sha256=sha256:sha2561 \
  --type=image \
  --repository-url=<repo_url> \
  --commit-sha=commit1 \
  --version=commit1 \
  --build-number=1 \
  --pipeline-run-id=pipeline-run-1 \
  --org=Org \
  --repo=my-inventory-20230421184544472 \
  --git-provider=github \
  --git-token-path=./inventory-token \
  --git-api-url=<api_url>

Ejemplo: Registro de un artefacto de despliegue en el inventario

Para los artefactos de despliegue, el proceso es similar pero se utiliza el tipo deployment:

cocoa inventory add \
  --artifact=my-app_IKS_deployment \
  --name=my-app_IKS_deployment \
  --app-artifacts='{ "app": "my-app", "tags": "20230828074614-master-commit1" }' \
  --signature=sign2 \
  --provenance=<provenance_url> \
  --sha256=sha256:sha2562 \
  --type=deployment \
  --repository-url=<repo_url> \
  --commit-sha=commit1 \
  --version=commit1 \
  --build-number=1 \
  --pipeline-run-id=pipeline-run-1 \
  --org=Org \
  --repo=my-inventory-20230421184544472 \
  --git-provider=github \
  --git-token-path=./inventory-token \
  --git-api-url=<api_url>

Recopilación de pruebas de activos

Utilice el comando collect-evidence después de cada exploración o prueba. El parámetro asset-key debe coincidir con la clave utilizada al guardar el activo con save_artifact o save_repo. Para obtener información detallada sobre el comando collect-evidence, incluidos todos los parámetros, los formatos de herramienta admitidos y el uso de la CLI, consulte el script collect-evidence.

Ejemplo: Recopilación de pruebas para ensayos sobre código fuente

Para las pruebas realizadas en el repositorio de código fuente:

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.unit_tests" \
  --asset-type "repo" \
  --asset-key "repo-1"

Ejemplo: Recopilación de pruebas unitarias de un artefacto

Tras ejecutar las pruebas de aceptación, recopile pruebas sobre el artefacto:

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.acceptance_tests" \
  --asset-type "artifact" \
  --asset-key "app-image"

Tras ejecutar las pruebas de aceptación, recopile pruebas en múltiples artefactos:

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.acceptance_tests" \
  --evidence-per-asset \
  --assets "app-image:artifact" \
  --assets "artifact-1:artifact"

Utilizar identificadores inmutables

Utilice siempre los SHA de las confirmaciones y los compendios de imágenes en lugar de etiquetas o nombres de ramas. Las referencias mutables pueden cambiar, rompiendo el vínculo entre las pruebas y los activos.

Mantener una nomenclatura coherente

Mantenga los nombres de los artefactos estáticos durante toda la ejecución de la canalización. Evite incrustar valores dinámicos, como marcas de tiempo, en el campo de nombre para garantizar un seguimiento y un cierre automático adecuados de las incidencias.

Emparejar tipos de activos

Asegúrese de que el parámetro type de cocoa inventory add coincide con el tipo utilizado en save_artifact. Los tipos no coincidentes pueden provocar fallos en la recogida de pruebas.

Procedencia de referencia en las implantaciones

En los conductos de CD, utilice el campo provenance para descargar artefactos en lugar del campo artifact. La procedencia URL proporciona la ubicación completa e inmutable del artefacto.

Reutilización de pruebas para la ejecución optimizada de pipelines

Para optimizar el tiempo de ejecución del pipeline y el uso de recursos, puede activar la reutilización de pruebas. Esta función permite omitir exploraciones o pruebas cuando el activo (artefacto o repositorio) que se está explorando no ha cambiado desde la última exploración.

Para obtener más información sobre la reutilización de pruebas, incluidas las condiciones de reutilización, los periodos de validez y la configuración avanzada, consulte Reutilización de pruebas en los procesos de RP y de IC.

En la interconexión de CD, el despliegue debe hacer referencia a un campo de procedencia en lugar de a un artefacto para descargar el artefacto.