¿Cómo puedo decidir qué tipo de componente crear?
¿Cómo decide si debe crear un módulo, una arquitectura desplegable o apilar arquitecturas desplegables? Vamos a comparar las diferencias y evaluar los casos de uso en las secciones siguientes para ayudarle a decidir.
Comparación de arquitecturas y módulos desplegables
La tabla siguiente proporciona una comparación y un resumen rápido de las diferencias clave entre módulos y tipos de arquitecturas desplegables.
| Método | Ámbito | Acoplamiento | Desplegable | Autor |
|---|---|---|---|---|
| Crear un módulo | Inteligencia | apretado | No | Desarrollador |
| Crear una arquitectura desplegable | Medio a amplio | apretado | Sí | Desarrollador |
| Arquitecturas desplegables de pila | Amplia | Suelto | Sí | Cualquier usuario |
La siguiente tabla puede ayudarle a decidir si utilizar un módulo, una arquitectura desplegable o apilar arquitecturas desplegables en función de su caso de uso.
| Finalidad | Método recomendado | Notas |
|---|---|---|
| Acelere la automatización de codificación | Utilizar módulos | Los módulos proporcionan una automatización reutilizable y comisariada para que los desarrolladores de arquitecturas desplegables puedan codificar más rápidamente. Los módulos son para desarrolladores, no para consumidores. |
| Asegúrese de que el cloud sea seguro y compatible | Utilizar una arquitectura desplegable | Las arquitecturas desplegables imponen la seguridad y la conformidad para una arquitectura. Si una arquitectura desplegable es demasiado pequeña en el ámbito, no puede imponer la conformidad. Por ejemplo, una arquitectura desplegable que solo despliega una instancia de servidor virtual no puede garantizar la seguridad de la red. |
| Ofrecer a los usuarios una opción con guardaraíles | Apilar arquitecturas desplegables | Al apilar arquitecturas desplegables, puede intercambiar arquitecturas desplegables o añadir arquitecturas desplegables y ofrecer a los usuarios más opciones. Puesto que las arquitecturas desplegables aplican la seguridad y la conformidad, el apilamiento ayuda a garantizar que la solución global sigue siendo compatible. El apilamiento de arquitecturas desplegables es un enfoque excelente para cosas como la selección de la base de datos que se va a utilizar. |
| Soluciones o arquitecturas creadas por el usuario | Apilar arquitecturas desplegables | El apilamiento de arquitecturas desplegables permite a los usuarios crear y publicar sus propios patrones repetibles que siguen siendo seguros, ya que se componen de arquitecturas desplegables seguras y conformes. |
| Componentes de arquitectura desacoplados | Apilar arquitecturas desplegables | Las arquitecturas desplegables pueden desarrollarse y versionarse de forma independiente, pero luego apilarse para su despliegue. |
| Experiencia de usuario simplificada | Utilizar una arquitectura desplegable | Las arquitecturas desplegables pueden proporcionar una lista pequeña o simple de entradas al usuario incluso para arquitecturas grandes o complejas. Las arquitecturas desplegables son sencillas de comprender y desplegar. En comparación, el apilamiento de arquitecturas desplegables es un poco más complejo a medida que se exponen las arquitecturas desplegables. |
Los proyectos deIBM Cloud garantizan que los recursos se despliegan a través de arquitecturas desplegables del catálogo y operan dentro de los guardaraíles de seguridad y conformidad de la organización. También aseguran que estos recursos se mantengan actualizados y no se desvían.
Dependencias para arquitecturas implementables
Las dependencias surgen cuando los recursos que proporciona una arquitectura implementable son necesarios para otra. Es decir, los recursos que proporciona una arquitectura implementable se utilizan durante la implementación de otra arquitectura, como se ilustra en la siguiente imagen.
Una forma de trabajar con dependencias es apilar arquitecturas desplegables y añadir referencias entre ellas en un proyecto. Por ejemplo, la VSI on VPC landing zone arquitectura desplegable incluye una variación que amplía la arquitectura desplegable de Red Hat OpenShift Container Platform en VPC landing zone. Considere apilar estas arquitecturas juntas en un proyecto. Este enfoque funciona bien si aún no se ha implementado la arquitectura de requisitos previos. Tampoco es necesario editar el código para apilar arquitecturas implementables.
Muchas arquitecturas implementables son independientes y no son extensiones de otras arquitecturas, pero puede optar por ampliar algunas arquitecturas implementables en el Arquitectura sección de la página de detalles del catálogo. Seleccione una opción del ¿Cómo quieres construir esta arquitectura? menú.
Sin embargo, si ya implementó Red Hat OpenShift Container Platform y necesita implementar VSI, los recursos necesarios para VSI ya están aprovisionados. No es necesario implementar el Red Hat OpenShift Arquitectura de plataforma de contenedores nuevamente. Dado que la arquitectura VSI es una extensión de la Red Hat OpenShift Container Platform, puede implementar VSI y la arquitectura utiliza los recursos del Red Hat OpenShift Plataforma de contenedores según sea necesario.
Arquitecturas desplegables opcionales e intercambiables
Se trata de una función experimental que está disponible para fines de evaluación y prueba y podría cambiar sin previo aviso.
Cuando incorporas una arquitectura desplegable a un catálogo privado, puedes ampliarla apilándola con otras arquitecturas. De este modo, podrá crear una solución más personalizable para sus usuarios.
- ¿Por qué apilar durante la incorporación?
- El apilamiento de arquitecturas durante la incorporación es similar al apilamiento de arquitecturas en un proyecto. Al incorporar una arquitectura, puede incluir dependencias apilando las arquitecturas necesarias junto con ella. Sin embargo,
a diferencia del apilamiento de arquitecturas en un proyecto, el apilamiento de arquitecturas durante la incorporación incluye las siguientes capacidades:
- Puede añadir arquitecturas opcionales adaptadas a diferentes casos de uso.
- Puede añadir arquitecturas intercambiables entre las que los usuarios puedan elegir.
- Arquitecturas opcionales
- Tal vez su arquitectura funcione bien con otra arquitectura desplegable, pero no sea necesaria para cumplir una dependencia o satisfacer la conformidad. Puede añadir la arquitectura desplegable como opcional, y los usuarios pueden elegir incluirla cuando añadan su arquitectura desplegable a un proyecto. Por ejemplo, una arquitectura de supervisión podría ser útil pero no necesaria.
- Arquitecturas intercambiables
- Cualquier arquitectura que se apile con la propia durante la incorporación puede intercambiarse con otras arquitecturas. Las arquitecturas intercambiables permiten a los usuarios elegir entre varias opciones que ofrecen la misma funcionalidad. Por ejemplo, puede incluir dos arquitecturas desplegables que creen bases de datos diferentes, y el usuario puede decidir qué opción de base de datos desea utilizar con su arquitectura.
Para obtener más información, consulte Ampliación de una arquitectura desplegable durante la incorporación.
Se pueden añadir arquitecturas opcionales e intercambiables a medida que se incorpora una arquitectura desplegable a un catálogo privado. Actualmente, el apilamiento de arquitecturas desplegables en un proyecto no admite arquitecturas opcionales o intercambiables.
Terraform frente a Ansible
En IBM Cloud, una arquitectura desplegable debe utilizar Terraform para declarar las entradas y salidas de la arquitectura desplegable (la interfaz) ya que Ansible no tiene una definición de interfaz legible por máquina. De lo contrario, el autor de una arquitectura desplegable puede utilizar cualquier combinación de scripts anteriores o posteriores de Ansible y Terraform para ejecutar el trabajo de la arquitectura desplegable. Entonces, ¿cómo decide un desarrollador qué tecnología utilizar y para qué?
| Terraform | Ansible | |
|---|---|---|
| Idioma | Declarativo | Procedimiento |
| Sintaxis | HCL (similar a JSON) | YAML (y llamadas a otros scripts) |
| Enfoque predeterminado | Infraestructura mutable | Infraestructura inmutable |
| Foco | Infraestructura | Configuración |
| Desviación | Comparación con el estado deseado | Tareas idempotentes |
Terraform es excelente para crear y gestionar infraestructura, mientras que Ansible es excelente para configurar el software y los sistemas operativos que se ejecutan en dicha infraestructura. Puesto que Ansible es procedimental, también puede crear un script de operaciones de una sola vez. Las tareas de mantenimiento, como la restauración a partir de una copia de seguridad, son fáciles en Ansible.
| Finalidad | Idioma de configuración recomendado | Notas |
|---|---|---|
| Desplegar infraestructura o servicios cloud | Terraform | Terraform se dirige a este caso de uso y es mejor para manejar la infraestructura cambiante. IBM Cloud proporciona módulos de Terraform y arquitecturas desplegables soportadas para acelerar patrones de infraestructura seguros y compatibles. El modelo de estado de Terraform permite a los desarrolladores obtener una vista previa de los cambios. Estos cambios se pueden explorar en busca de conformidad. |
| Instalar o configurar software | Ansible | Si una imagen de contenedor o máquina virtual precompilada no es adecuada para el caso de uso, Ansible es mejor para manejar la instalación y configuración de software. Ansible tiene un amplio soporte para operaciones automatizadas como, por ejemplo, ediciones de configuración, gestión de paquetes y reinicios de procesos. Hay disponible una gran biblioteca de módulos y playbooks de Ansible para facilitar la configuración de miles de paquetes de software utilizados habitualmente. |
| Integración de CCDB | Ansible | La realización de una llamada dinámica a un servicio local como un CCDB se puede realizar en Terraform o Ansible, pero es más fácil de realizar en un lenguaje de procedimientos o scripts. |
| Validación de entrada | Terraform o Ansible | Terraform tiene una capacidad limitada para realizar la validación de entrada, pero es declarativo y puede ser utilizado por las interfaces de usuario. Ansible añade la posibilidad de realizar la validación de entrada dinámica donde las entradas de una arquitectura desplegable se comprueban con un servicio remoto. |
| Acciones de mantenimiento del día 2 | Ansible | El mantenimiento del día 2 suele ser de naturaleza procedimental y se realiza mejor en Ansible. Los ejemplos incluyen la copia de seguridad manual, la restauración o las rotaciones de claves. |
| Gestión de desviación |
|
|
Para obtener más información sobre cómo incluir scripts anteriores o posteriores con las arquitecturas desplegables, consulte Creación de scripts para la arquitectura desplegable.
Pasos siguientes: Decidir dónde publicar
Después de planificar la arquitectura y decidir qué tipo de componente crear, debe considerar dónde tiene previsto compartir o publicar la solución, para que otros usuarios puedan aprovechar la solución que cree. En función de dónde tenga previsto compartir o publicar, es posible que tenga distintos niveles de requisitos o aprobaciones para completar.