Service Catalog Puppet

Service Catalog Puppet se implementa en Python mediante la API AWS Boto3. Esta herramienta ofrece varias funciones eficaces para configurar y aprovisionar los productos de Service Catalog. Los desarrolladores pueden configurar la información de aprovisionamiento de productos y carteras de Service Catalog mediante plantillas YAML que sirven como manifiestos. Los flujos de trabajo de aprovisionamiento de Service Catalog Puppet admiten productos que requieren procesos de implementación más complejos que los de Service Catalog. También admiten optimizaciones del rendimiento para aprovisionar productos a escala dentro de plazos exigentes.

Service Catalog Puppet accede a las CloudFormation plantillas de Service Catalog para el aprovisionamiento de productos en el momento de la implementación. Requiere implementar CloudFormation directamente la pila de plantillas de aprovisionamiento de un producto y evita las restricciones impuestas por el propio proceso de aprovisionamiento de conjuntos de pilas de Service Catalog. Si la plantilla de aprovisionamiento usa macros para incluir otros CloudFormation scripts o usa scripts anidados, debes proporcionar acceso a esos CloudFormation scripts en la cuenta de destino en la parte de arranque del flujo de trabajo de aprovisionamiento.

Para obtener más información:

• Consulte la documentación y el GitHubrepositorio de Service Catalog Puppet.

• Si desea utilizar el SDK Puppet de Service Catalog para interactuar con la herramienta mediante programación e iniciar el aprovisionamiento de productos y carteras, consulte la documentación del SDK.

• GitOpses el mecanismo predeterminado para administrar el entorno de Service Catalog Puppet.

Service Catalog Puppet es bastante fácil de aprender para los desarrolladores. Es necesario estar familiarizado con CloudFormation la implementación de plantillas de aprovisionamiento de productos y plantillas de YAML para implementar los manifiestos. Hay buenos talleres disponibles para poner al día a los nuevos desarrolladores, como los talleres a su propio ritmo.

Support para aprovisionamiento de flujos de trabajo

Service Catalog Puppet emplea el motor de orquestación de tareas Python Luigi para implementar flujos de trabajo de arranque y aprovisionamiento. Todos los pasos de estos flujos de trabajo se implementan como tareas del flujo de trabajo de Luigi. Para obtener una descripción general de Luigi y compararlo con otras herramientas de flujo de trabajo populares, consulte Airflow, Luigi, Argo y Argo, KubeFlow en el blog Data MLFlow Revenue.

Luigi permite a Service Catalog Puppet controlar la cantidad de trabajadores asociados a las tareas del flujo de trabajo y controlar otros aspectos de los flujos de trabajo para mejorar la escalabilidad y el rendimiento. Service Catalog Puppet también proporciona un mecanismo depends_on para administrar las dependencias entre productos y pasos, y para organizar el aprovisionamiento de productos. Esta función le ayuda a implementar y administrar operacionalmente definiciones de productos detalladas y dependencias complejas.

Modos de aprovisionamiento

Service Catalog Puppet admite tres modos de ejecución: hub, spoke y async. Los tres modos aprovisionan productos dentro de carteras que ya están definidas en Service Catalog. Confían en el uso compartido de los productos de Service Catalog con las cuentas de destino y utilizan las funciones de administrador y lanzamiento de Service Catalog para realizar el aprovisionamiento en esos destinos. Service Catalog Puppet lleva a cabo los pasos de arranque dentro de la misma organización en función de las configuraciones de roles que se proporcionan en los archivos de configuración de YAML. La herramienta también admite el aprovisionamiento a varias organizaciones desde una sola cuenta central. En este escenario, el arranque debe realizarse manualmente en las organizaciones externas para permitir que Service Catalog Puppet lleve a cabo las acciones de aprovisionamiento necesarias en las cuentas de la organización externa.

En todos los modos de aprovisionamiento, Service Catalog Puppet implementa el aprovisionamiento de productos directamente sin llamar al proceso de aprovisionamiento de Service Catalog. Puede configurar un manifiesto de aprovisionamiento para utilizar las especificaciones del rol y la cuenta de destino de una restricción de conjunto de pilas de Service Catalog existente. Service Catalog Puppet utiliza esta información para realizar su propio aprovisionamiento con los flujos de trabajo de Luigi.

Puede definir los objetivos para el aprovisionamiento de la cartera de productos basándose en un enfoque de etiquetado de cuentas, además de especificar las cuentas directamente. OUs En el aprovisionamiento basado en etiquetas de cuentas, se aprovisiona un producto de cartera para todas las cuentas que tengan todas las etiquetas del conjunto de etiquetas de aprovisionamiento de manifiestos especificado. Por ejemplo, si desea emitir un producto de cartera para todas las cuentas de producción institucionales de las regiones del este de EE. UU., puede especificar las etiquetastype:prod, y. partition:us-east scope:institutional-client También puede declarar las exclusiones de cuentas y unidades organizativas para prohibir el aprovisionamiento a OUs cuentas que tengan las etiquetas que usted especifique o a cuentas que sean miembros de los destinos especificados por la unidad organizativa. Para obtener más información sobre el etiquetado de cuentas, consulte la documentación de las herramientas de Service Catalog.

Modo hub

En el modo de aprovisionamiento de hub, todos los flujos de trabajo de Luigi para las cuentas radiales se gestionan desde la cuenta central designada. La cuenta central asume una función de IAM que le permite realizar acciones en una cuenta radial, pero la gestión de las tareas se lleva a cabo desde la cuenta central. La cuenta central espera de forma sincronizada hasta que se completen todas las tareas de aprovisionamiento de la cuenta radial, ya sea con éxito o sin éxito. A continuación, informa del estado final. El modo de cuenta central es el modo de aprovisionamiento más antiguo y avanzado. Sin embargo, muchos usuarios han pasado al modo de aprovisionamiento radial para lograr una mayor simultaneidad y velocidad de aprovisionamiento.

Modo radio

En el modo radial, la cuenta hub de Service Catalog inicia los flujos de trabajo de Luigi para que se ejecuten en las cuentas radiales inicializadas designadas. La cuenta hub recibe una notificación cuando se completan los flujos de trabajo radiales. Los errores en una cuenta radial se convierten en la cuenta hub. La cuenta central sondea la cuenta radial para ver si está finalizada y determinar su estado.

Es menos probable que el modo radial requiera aumentar la Servicio de AWS cuota, ya que casi todo funciona en cuentas radiales independientes. El modo de radio también proporciona una simultaneidad mucho mayor que el modo hub y, al mismo tiempo, conserva el control central. Puede mejorar la velocidad de aprovisionamiento en un 800 por ciento en comparación con el modo hub. El modo Spoke permite encadenar los productos a través de DependsOn las relaciones entre ellos, lo que garantiza que el producto del que se depende ya se haya aprovisionado. Un producto que incluye productos encadenados también puede aprovisionar un producto encadenado por componentes. También puede utilizar llamadas a AWS Lambda funciones especializadas para realizar los pasos necesarios. Los fallos en un radio se aíslan de los demás radios.

El modo Spoke lo utilizan las empresas que tienen más de 980 cuentas en hasta 7 regiones. Por lo general, estas empresas pueden aprovisionar un producto a todas las regiones y cuentas de su infraestructura en una hora.

nota

Estos resultados pueden variar en función de factores como la infraestructura de red, la carga de trabajo y las cuotas establecidas para las cuentas centrales y radiales de la AWS organización. También dependen de los recursos del producto que se aprovisionen, de sus tiempos de creación inherentes y de su dependencia de otros recursos.

Modo asíncrono

El modo asíncrono inicia los flujos de trabajo de aprovisionamiento en las cuentas de radio, pero no espera ni recibe las respuestas de finalización de las cuentas de radio.

Almacenamiento en caché

Otro mecanismo que utiliza Service Catalog Puppet para optimizar la velocidad de los flujos de trabajo es almacenar en caché las tareas comunes que representan los pasos del flujo de trabajo. Cuando se completa una tarea en caché, escribe su resultado en Amazon Simple Storage Service (Amazon S3). La próxima vez que se invoque la tarea en la misma sesión con los mismos parámetros, Service Catalog Puppet utilizará los valores en caché en lugar de volver a ejecutar la tarea. Para obtener más información, consulte Almacenamiento en caché en la documentación de Service Catalog Puppet.

DevSecOps soporte de ciclo de vida

Service Catalog Puppet incluye soporte para administrar la DevSecOps canalización. Puede usar las acciones de las herramientas de Service Catalog (como se ilustra en la descripción general de Service Catalog Puppet) para automatizar las pruebas y promocionar productos en todas sus cuentas de AWS ciclo de vida, incluida la cuenta canaria recomendada. Para obtener más información, consulte Administrar sus entornos en la documentación de Service Catalog Puppet.

Para garantizar que cualquier problema relacionado con un cambio de producto se detecte antes de su uso generalizado en producción, Service Catalog Puppet requiere al menos una cuenta canaria para la implementación inicial. Una vez que pruebes la nueva versión y ganes confianza en ella, puedes promocionarla entre cuentas de producción que no sean canarias. Si identificas algún problema, puedes anular la versión anterior y volver a introducirla cuando se hayan resuelto los problemas. Si utilizas este enfoque, es posible que se produzcan problemas de producción si publicas una versión estándar que tiene algún problema con las cuentas de producción. Como alternativa, puedes realizar pruebas de regresión completas para cada cambio de producto antes de lanzar el cambio a producción. Esto introduce una sobrecarga adicional en el proceso de CI/CD, pero ayuda a evitar problemas de producción. Es responsabilidad del DevSecOps administrador determinar los mejores escenarios y enfoques de lanzamiento de funciones para sus equipos de desarrollo.

Service Catalog Puppet permite a varios equipos desarrollar y probar el aprovisionamiento de las soluciones de productos de Service Catalog simultáneamente. Como práctica recomendada, varios desarrolladores no deberían cambiar un producto al mismo tiempo. En su lugar, puedes dividir los productos en componentes más detallados para modificarlos por separado y de forma simultánea.

Service Catalog Puppet también ayuda a automatizar las pruebas mediante una declaración de afirmación que proporciona capacidades de pruebas estáticas y unitarias. Puede probar las políticas de control de servicios (SCPs) y las políticas de IAM mediante simuladores de políticas. Se trata de end-to-end pruebas técnicas, pero se pueden utilizar en entornos de pruebas de integración de sistemas (SIT). Para obtener más información, consulte Uso de simulaciones de políticas y Aplicación de políticas de control de servicios en la documentación de Service Catalog Puppet.

Madurez, integridad y soporte

Aunque Service Catalog Puppet no tiene soporte oficial Servicio de AWS, se ha adoptado ampliamente. Las grandes organizaciones han utilizado esta herramienta durante los últimos años para aprovisionar productos de forma eficaz y centralizada a cientos de cuentas de unidades organizativas dentro de los plazos de aprovisionamiento deseados. Se ha demostrado que proporciona un aprovisionamiento de productos a escala y tolerante a fallos. Los usuarios que tengan algún problema con Service Catalog Puppet pueden registrarlo en el GitHub repositorio para que los colaboradores de esta solución de AWS Labs lo resuelvan.