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.

Service Catalog Puppet

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

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

Para obtener más información:

Service Catalog Puppet es bastante fácil de aprender para los desarrolladores. Es necesario conocer CloudFormation para implementar las plantillas de aprovisionamiento de los productos y las plantillas de YAML para implementar los manifiestos. Hay buenos talleres disponibles para poner al día a los desarrolladores nuevos, como los talleres autoguiados.

Compatibilidad con el aprovisionamiento de los flujos de trabajo

Service Catalog Puppet utiliza el motor de orquestación de tareas de Python Luigi para implementar los 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 información general de Luigi y cómo se compara con otras herramientas de flujo de trabajo populares, consulte Airflow vs. Luigi vs. Argo vs. MLFlow vs. KubeFlow en el blog de Data Revenue.

Luigi permite a Service Catalog Puppet controlar la cantidad de trabajos 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 los productos y los pasos, y para organizar el aprovisionamiento de los productos. Esta característica es útil para implementar y administrar mediante operaciones las definiciones detalladas de los productos y las dependencias complejas.

Modos de aprovisionamiento

Service Catalog Puppet admite tres modos de ejecución: centralizado, radial y asíncrono. Los tres modos aprovisionan los productos en las 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 los roles de administrador y lanzamiento de Service Catalog para hacer el aprovisionamiento en esos destinos. Service Catalog Puppet lleva a cabo los pasos de arranque en la misma organización según 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 hacerse de manera manual 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 los productos de manera directa 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 existente de Service Catalog. Service Catalog Puppet utiliza esta información para hacer su propio aprovisionamiento con los flujos de trabajo de Luigi.

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

Modo centralizado

En el modo de aprovisionamiento centralizado, todos los flujos de trabajo de Luigi para las cuentas radiales se administran desde la cuenta central designada. La cuenta central asume un rol de IAM que le permite realizar acciones en una cuenta radial, pero la administración de las tareas se lleva a cabo desde la cuenta central. La cuenta central espera de manera sincronizada hasta que se completen todas las tareas de aprovisionamiento de la cuenta radial, correcta o incorrectamente. A continuación, informa sobre el estado final. El modo de cuenta central es el modo de aprovisionamiento más antiguo y avanzado. Sin embargo, muchos usuarios pasaron al modo de aprovisionamiento radial para lograr una mayor simultaneidad y velocidad de aprovisionamiento.

Modo radial

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

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

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

Modo asíncrono

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

Almacenamiento en caché

Otro mecanismo que utiliza Service Catalog Puppet para optimizar la velocidad de los flujos de trabajo es almacenar en la memoria caché las tareas comunes que representan los pasos del flujo de trabajo. Cuando finaliza una tarea en la memoria caché, se escriben sus resultados 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 la memoria caché en lugar de volver a ejecutar la tarea. Para más información, consulte Caching en la documentación de Service Catalog Puppet.

Compatibilidad con el ciclo de vida de DevSecOps

Service Catalog Puppet incluye compatibilidad para administrar la canalización de DevSecOps. Puede utilizar las acciones de las herramientas de Service Catalog (como se ilustra en la información general de Service Catalog Puppet) para automatizar las pruebas y promocionar los productos en todas sus cuentas de ciclo de vida de AWS, por ejemplo, la cuenta canaria recomendada. Para más información, consulte Managing your environments en la documentación de Service Catalog Puppet.

Para garantizar que los problemas relacionados con un cambio de producto se detecten 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 pruebe la versión nueva y gane confianza en esta, puede promocionarla entre las cuentas de producción que no sean canarias. Si detecta problemas, puede revertir la versión anterior y volver a introducirla cuando se hayan resuelto. Si utiliza este enfoque, es posible que haya problemas de producción si publica una versión canaria que tiene algún problema con las cuentas de producción. Como alternativa, puede hacer pruebas de regresión completas para cada cambio de producto antes de lanzar el cambio a la producción. Esto supone una carga adicional en el proceso de CI/CD, pero ayuda a evitar problemas de producción. Es responsabilidad del administrador de DevSecOps determinar los mejores escenarios y enfoques de lanzamiento de las características 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 de manera simultánea. Como práctica recomendada, varios desarrolladores no deben cambiar un producto al mismo tiempo. En su lugar, se pueden dividir los productos en componentes más detallados para modificarlos por separado y de manera simultánea.

Service Catalog Puppet también ayuda a automatizar las pruebas mediante una instrucción de afirmación que proporciona funcionalidades de pruebas estáticas y unitarias. Puede probar las políticas de control de servicios (SCP) y las políticas de IAM mediante simuladores de políticas. Desde el punto de vista técnico, se trata de pruebas integrales, pero se pueden utilizar en entornos de pruebas de integración de sistemas (SIT). Para más información, consulte Using policy simulations y Applying service control policies en la documentación de Service Catalog Puppet.

Madurez, integridad y compatibilidad

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