Las organizaciones, los Proyectos y los clústeres son los cimientos de tu patrimonio empresarial Atlas:
A nivel de la organización, puede implementar controles de seguridad y crear usuarios que trabajen en uno o más proyectos.
Los proyectos ofrecen un aislamiento de seguridad más detallado y un límite de autorización más preciso.
Los clústeres son sus bases de datos en la nube en Atlas.
Utiliza la orientación fundamental de esta página para diseñar la disposición de tus organizaciones, proyectos y clústeres según la jerarquía de tu empresa y el número esperado de clústeres y proyectos. Esta orientación te ayuda a optimizar tu seguridad y rendimiento desde el principio, alineándose con las necesidades de facturación y acceso de tus empresas.
Funcionalidades para Atlas Orgs, Proyectos y clústeres
Puede utilizar los siguientes niveles de jerarquía para definir la configuración de seguridad y gobierno de su patrimonio empresarial de Atlas:
Nivel de jerarquía de Atlas | Descripción |
|---|---|
(Opcional) Organización pagadora | Uno Una organización puede ser una organización que paga para otras organizaciones. Una organización pagadora te permite configurar facturación entre organizaciones para compartir una suscripción de facturación entre varias organizaciones. Para obtener más información sobre cómo configurar su organización pagadora al establecer la suscripción de Atlas, consulte Administrar facturación. Para habilitar la facturación entre organizaciones, el usuario que realiza la acción debe tener un rol de Propietario de la organización u Administrador de facturación en ambas organizaciones que desee vincular. Para obtener más información, consulta Roles de usuario. Una organización pagadora es común para grandes empresas con muchos BUo departamentos que operan independientemente pero donde el contrato o la factura es propiedad de una autoridad central. |
Una organización puede incluir varios proyectos, y brinda un contenedor para aplicar configuraciones de integración y seguridad compartidas en esos proyectos y los clústeres que los componen. Si se gestionan varias organizaciones de Atlas, la Consola de gestión de Atlas Federation permite a los usuarios con rol de Propietario de organización gestionar IdPs para SSO y luego vincularlos a múltiples organizaciones. Una organización generalmente corresponde a una BU o departamento dentro de una empresa. El Atlas Cost Explorer de funcionalidad incorporada agrega el gasto en la nube a nivel de la organización y desglosa las partidas a nivel de Proyecto y clúster debajo de él. Se puede personalizar aún más usando la API de facturación. | |
La configuración de seguridad para el plano de datos (incluidos los clústeres de la base de datos, la seguridad de la red y otros servicios de datos) se realiza a nivel de proyecto. Un Proyecto a menudo se asigna a una aplicación y entorno (por ejemplo: Portal del cliente - entorno de producción). Para cada proyecto, según el proveedor de nube seleccionado, hay una VPC o VNet dedicada por región en AWS y Azure. | |
Atlas aprovisiona cada clúster dentro de una o más VPC/VNet dedicadas para un proyecto. La configuración de seguridad se comparte entre los clústeres del Proyecto, excepto los roles de usuario de base de datos y la autorización, que pueden aplicarse a acciones en nivel de clúster, base de datos y colección. |
Recomendaciones para organizaciones, proyectos y clústeres de Atlas
Recomendaciones de implementación multi-región y multi-nube
Para implementaciones multiregión y multi-nube, considera las siguientes recomendaciones adicionales para optimizar el rendimiento, la seguridad y el cumplimiento en diferentes fronteras geográficas:
Arquitectura de red y latencia
Implementa clústeres en las regiones más cercanas a los usuarios de tu aplicación para minimizar la latencia.
Use VPC/VNets dedicados por región dentro de cada proyecto para mantener el aislamiento de la red.
Configure nodos privados en cada región donde implementes clústeres para garantizar conexiones seguras y de baja latencia.
Localidad de datos y cumplimiento
Cree proyectos separados para diferentes jurisdicciones regulatorias (por ejemplo, proyecto de la UE conforme al GDPR, proyecto de EEUU conforme a SOX) para garantizar el cumplimiento de los requisitos de residencia de datos.
Utilice clústeres globales con fragmentación de zonas para enrutar automáticamente lecturas y escrituras a la región geográfica adecuada en función de los valores de clave de fragmentación.
Etiqueta proyectos y clústeres con requisitos de clasificación de datos y cumplimiento regional para propósitos de auditoría y gobernanza.
Recuperación ante desastres entre regiones
Implemente clústeres con réplicas de lectura en múltiples regiones para habilitar capacidades de conmutación por error.
Mantén cronogramas de copia de seguridad coherentes en todas las regiones dentro del mismo entorno de aplicación.
Prueba los procedimientos de recuperación ante desastres regularmente en las regiones para garantizar la continuidad del negocio.
Consideraciones multi-nube
Utilice convenciones de nomenclatura consistentes entre los proveedores de nube para simplificar la administración y la supervisión.
Estandariza las configuraciones de seguridad en todos los entornos de nube dentro del mismo proyecto.
Tenga en cuenta las características y limitaciones específicas del proveedor de la nube al planificar la replicación de datos entre nubes y la conectividad de red.
Todas las recomendaciones paradigmáticas de implementación
Las siguientes recomendaciones aplican a todos paradigmas de implementación.
Entornos de desarrollo, pruebas, puesta en escena y producción
Le recomendamos que utilice los siguientes cuatro entornos para aislar su entorno aislado y sus proyectos y clústeres de prueba de sus proyectos y clústeres de aplicación:
Entorno | Descripción |
|---|---|
Desarrollo (Dev) | Permitir a los desarrolladores probar libremente cosas nuevas en un entorno sandbox seguro. |
Prueba (Test) | Prueba componentes o funciones específicas creados en el entorno de desarrollo. |
Staging | Prepare todos los componentes y funciones juntos para garantizar que toda la aplicación funcione correctamente antes de implementarla en producción. La preparación es similar al entorno de pruebas, pero garantiza que los nuevos componentes funcionen correctamente con los existentes. |
Producción (Producción) | El back end de su aplicación que está activo para sus usuarios finales. |
implementaciones locales de Atlas
Para fines de desarrollo y pruebas, los desarrolladores pueden usar la CLI de Atlas para crear una implementación local de Atlas. Al trabajar localmente desde sus equipos, pueden reducir los costos de entornos externos de desarrollo y pruebas.
Los desarrolladores también pueden ejecutar comandos de Atlas CLI con Docker para compilar, ejecutar y administrar implementaciones locales de Atlas utilizando contenedores. Los contenedores son unidades estandarizadas que contienen todo el software necesario para ejecutar una aplicación. La contenerización permite a los desarrolladores construir implementaciones locales de Atlas en entornos de prueba seguros, confiables y portátiles. Para obtener más información, consulte Crea una implementación local de Atlas con Docker.
Jerarquías de organizaciones y proyectos
Generalmente, recomendamos una organización de pago con gestión centralizada y una organización para cada unidad de negocio o departamento vinculado a ella. A continuación, cree un proyecto con un clúster para cada entorno (de desarrollo o de pruebas) y otro para el entorno superior; puede crear clústeres en estos proyectos. Para obtener más información, consulte la siguiente información sobre la jerarquía recomendada.
Si planeas alcanzar fácilmente el límite de 250 proyectos por organización, se recomienda crear una organización por entorno, como una para entornos inferiores y otra para entornos superiores, o una para desarrollo, prueba, puesta en escena y producción. Esta configuración tiene el beneficio de un aislamiento adicional. También puedes aumentar los límites. Para obtener más información, consulta Límites de servicio de Atlas.
Las configuraciones de red y seguridad, como las IP permitidas y las claves API, se comparten a nivel de proyecto, por lo que si necesitas controles de acceso a nivel detallado para equipos que trabajen en diferentes aplicaciones, recomendamos crear proyectos separados para cada aplicación.
Jerarquía recomendada
Considera la siguiente jerarquía, que crea menos organizaciones Atlas, si tienes equipos y permisos comunes en toda la BU y menos del límite susceptible de 250 proyectos por organización.
Jerarquía recomendada 2: Unidades de negocio/departamentos descentralizados
Considere la siguiente jerarquía si su organización está altamente descentralizada y no cuenta con una función centralizada que actúe como responsable del contrato y la facturación. En esta jerarquía, cada unidad de negocio, departamento o equipo tiene su propia organización Atlas. Esta jerarquía es útil si cada equipo es relativamente independiente, no comparte personal ni permisos dentro de la empresa, o si desea adquirir créditos por sí mismo a través del marketplace de proveedores de la nube o directamente con su propio contrato. No existe una organización que pague en esta jerarquía.
Cluster Hierarchy
Para mantener el aislamiento entre entornos, recomendamos implementar cada clúster dentro de su propio proyecto, como se muestra en el siguiente diagrama. Esto permite a los administradores mantener diferentes configuraciones de proyecto entre entornos y respetar el principio de mínimo privilegio, que establece que a los usuarios solo se les debe conceder el nivel de acceso mínimo necesario para su rol.
Especialmente en entornos de producción, recomendamos crear proyectos separados para cada aplicación y entorno. Dado que estas configuraciones se gestionan a nivel de proyecto, este enfoque reduce la posibilidad de tener que transferir datos manualmente entre clústeres de entornos de producción si cambian los requisitos de una aplicación determinada.
Puedes compartir configuraciones a nivel de proyecto, como nodos privados y CMKs, entre clústeres utilizando herramientas de automatización, como Terraform, al crear el clúster. Además, la automatización de la creación de clústeres puede generar ahorros de costos al estandarizar la creación de entornos superiores e inferiores paralelos para entornos de producción y desarrollo, respectivamente.
Para obtener más información, consulta Cuándo considerar múltiples clústeres por proyecto.
Cuándo considerar múltiples clústeres por proyecto
El siguiente diagrama muestra una organización cuyos proyectos contienen a su vez varios clústeres de Atlas, agrupados por entorno. El despliegue de múltiples clústeres dentro del mismo proyecto simplifica la administración cuando una aplicación utiliza múltiples clústeres de respaldo, o el mismo equipo es responsable de múltiples aplicaciones en diferentes entornos. Esto facilita el costo de configuración de funcionalidades como nodos privados y claves gestionadas por el cliente, porque todos los clústeres en el mismo Proyecto comparten la misma configuración de Proyecto.
Sin embargo, esta jerarquía de clúster podría violar el principio de mínimo privilegio.
Implemente varios clústeres dentro del mismo proyecto solo si se cumplen las dos condiciones siguientes:
Cada miembro del equipo con acceso al proyecto está trabajando en todas las demás aplicaciones y clústeres del proyecto.
Estás creando clústeres para entornos de desarrollo y prueba. En los entornos de staging y producción, recomendamos que los clústeres en el mismo proyecto pertenezcan a la misma aplicación y sean administrados por el mismo equipo.
Etiquetado de recursos
Recomendamos que etiquetes los clústeres o proyectos con los siguientes detalles para facilitar el análisis de reportes e integraciones:
BU o Departamento
Nombre del equipo
Nombre de la aplicación
Entorno
Versión
Contacto por correo electrónico
Criticidad (indica el nivel de datos almacenados en el clúster, incluidas las clasificaciones confidenciales como PII o PHI)
Para obtener más información sobre cómo analizar datos de facturación mediante etiquetas, consulte Características de los datos de facturación de Atlas.
Guía sobre el tamaño del clúster Atlas
En una implementación dedicada (tamaño de clúster M10+), Atlas asigna recursos de forma exclusiva. Recomendamos implementaciones dedicadas para casos de uso en producción porque ofrecen mayor seguridad y rendimiento que los clústeres compartidos.
La siguiente guía de tamaño de clúster utiliza el "tamaño de camiseta", una analogía común en el desarrollo de software e infraestructura para describir la planificación de la capacidad de forma simplificada. Utilice las recomendaciones de tamaño de camiseta solo como puntos de partida aproximados en su análisis de tamaño. El dimensionamiento de un clúster es un proceso iterativo basado en la evolución de las necesidades de recursos, los requisitos de rendimiento, las características de la carga de trabajo y las expectativas de crecimiento.
Importante
Esta guía excluye aplicaciones críticas, cargas de trabajo con alto consumo de memoria y de CPU. Para estos casos de uso, contacte con el soporte de MongoDB para obtener orientación personalizada.
Puedes estimar los recursos de clúster que requiere tu implementación utilizando el tamaño aproximado de los datos y la carga de trabajo de tu organización:
Almacenamiento total requerido: 50% del tamaño total de datos en bruto
RAM total requerida: 10% del tamaño total de los datos en bruto
Total de Núcleos de CPU Requeridos: operaciones de lectura/escritura de base de datos pico esperadas por segundo ÷ 4000
IOPS de almacenamiento total requeridos: operaciones de base de datos de lectura/escritura máxima esperadas por segundo (IOPS mín. = 5%, IOPS máx. = 95%)
Utilice la siguiente guía de tamaño de clúster para seleccionar un nivel de clúster que garantice el rendimiento sin sobreaprovisionamiento. Esta tabla muestra las capacidades predeterminadas de almacenamiento y rendimiento para cada nivel de clúster, así como si el nivel de clúster es adecuado para entornos de ensayo y producción.
La guía de tamaños de clúster también incluye valores esperados para el tamaño total de datos de un clúster y el IOPS por defecto, que puedes aumentar con configuraciones adicionales. Ten en cuenta que las siguientes recomendaciones de almacenamiento son por fragmento o partición, no para todo el clúster. Para obtener más información, consulta Orientación para la escalabilidad de Atlas.
Talla de camiseta | Nivel de clúster | Rango de almacenamiento: AWS/Google Cloud/Azure | CPUs (#) | RAM por defecto | IOPS por defecto | Tamaño de datos mediana esperado | Lecturas/escrituras máximas esperadas | Adecuado para |
|---|---|---|---|---|---|---|---|---|
Pequeño |
| 2 GB a 128 GB | 2 | 2 GB | 1000 | 1 GB a 10 GB | 200 | Sólo desarrollo/pruebas |
Med |
| 8 GB a 512 GB | 2 | 8 GB | 3000 | 20 GB a 50 GB | 3000 | Prod |
Grande |
| 8 GB a 4 TB | 16 | 32 GB | 3000 | 360 GB a 420 GB | 11000 | Prod |
XL |
| 8 GB a 4 TB | 32 | 128 GB | 3000 | 1200 GB a 1750 GB | 39000 | Prod |
| [1] | M10 es un nivel de CPU compartida. Para industrias altamente reguladas o datos confidenciales, tu nivel mínimo y más pequeño de inicio debe ser M30. |
Por ejemplo, considere una empresa fintech ficticia, MongoFinance, que debe almacenar un total de 400 GB de datos procesados. En horas pico de actividad, los empleados y clientes de MongoFinance realizan hasta 3000 lecturas o escrituras en sus bases de datos por segundo. Los requisitos de almacenamiento y rendimiento de MongoFinance se satisfacen mejor con un nivel de clúster grande (M50).
Para obtener más información sobre los niveles de clúster y las regiones que los admiten, consulta la documentación de Atlas para cada proveedor de nube:
Ejemplos de automatización: Atlas Orgs, proyectos y clústeres
Tip
Para ejemplos de Terraform que aplican nuestras recomendaciones en todos los pilares, consulta uno de los siguientes ejemplos en GitHub:
Los siguientes ejemplos crean organizaciones, proyectos y clústeres utilizando las herramientas de Atlas para la automatización.
Estos ejemplos también aplican otras configuraciones recomendadas, entre ellas:
El nivel de clúster está configurado en
M10para un entorno de desarrollo y pruebas. Consulta la guía de tamaño de clúster para conocer el nivel de clúster recomendado para el tamaño de tu aplicación.Topología de implementación de un solo set de réplicas/región con 3nodos y partición.
Nuestros ejemplos usan AWS, Azure y Google Cloud de manera intercambiable. Puede utilizar cualquiera de estos tres proveedores de servicios en la nube, pero debe cambiar el nombre de región para que coincida con el proveedor de nube. Para obtener más información sobre los proveedores de nube y sus regiones, consulte Proveedores de nube.
El nivel de clúster está configurado en
M30para una aplicación de tamaño mediano. Consulte la guía de tamaño de clúster para conocer el nivel de clúster recomendado para el tamaño de su aplicación.Topología de implementación de un solo set de réplicas/región con 3nodos y partición.
Nuestros ejemplos usan AWS, Azure y Google Cloud de manera intercambiable. Puede utilizar cualquiera de estos tres proveedores de servicios en la nube, pero debe cambiar el nombre de región para que coincida con el proveedor de nube. Para obtener más información sobre los proveedores de nube y sus regiones, consulte Proveedores de nube.
Nota
Antes de poder crear recursos con la CLI de Atlas, debes:
Crea tu organización pagadora y crea una clave de API para la organización pagadora.
Conéctese desde la Atlas CLI siguiendo los pasos para Programmatic Use.
Crear las organizaciones
Ejecuta el siguiente comando para cada BU. Cambia las IDs y los nombres para usar tus valores reales:
atlas organizations create ConsumerProducts --ownerId 508bb8f5f11b8e3488a0e99e --apiKeyRole ORG_OWNER --apiKeyDescription consumer-products-key
Para obtener más opciones de configuración e información sobre este ejemplo, consulte crear organizaciones atlas.
Puede crear una organización y vincularla con su organización de pago automáticamente utilizando la API de administración de Atlas. Para ello, envíe una POST solicitud al endpoint https://cloud.mongodb.com/api/atlas/v2/orgs e indique el Identificador de la Organización de pago en el federationSettingsId campo. La cuenta de servicio o la clave de API que realice la solicitud debe tener el rol "Propietario de la organización" y la organización solicitante debe ser una organización de pago.
El siguiente ejemplo usa cURL para enviar la solicitud:
curl --location '/api/atlas/v2/orgs?envelope=false&pretty=false' \ --header 'Content-Type: application/vnd.atlas.2023-01-01+json' \ --header 'Accept: application/vnd.atlas.2023-01-01+json' \ --data '{ "name": "<organization name>", "apiKey": { "desc": "<organization description>", "roles": [ "ORG_MEMBER" ] }, "federationSettingsId": "<ID of org to link to>", "orgOwnerId": "<organization owners ID>", "skipDefaultAlertsSettings": false }'
Para obtener más información sobre la llamada a la API anterior, consulta la documentación de la API atlas organizations create.
Para obtener los ID de usuario y de organización, consulte los siguientes comandos:
Crea los proyectos
Ejecuta el siguiente comando para cada aplicación y par de entornos. Cambia los IDs y nombres para usar tus valores:
atlas projects create "Customer Portal - Prod" --tag environment=production --orgId 32b6e34b3d91647abb20e7b8
Para obtener más opciones de configuración e información sobre este ejemplo, consulte crear proyectos atlas.
Para obtener los ID del grupo, consulta el siguiente comando:
Configurar el cifrado con gestión de claves del cliente
Para los entornos de staging y producción, recomendamos que active el cifrado con gestión de claves del cliente al aprovisionar sus clústeres. Para desarrollo y pruebas, considera omitir el cifrado con gestión de claves del cliente para ahorrar costos, a menos que estés en una industria altamente regulada o almacenando datos confidenciales. Para obtener más información, consulte Recomendaciones para Atlas Orgs, Proyectos y Clústeres.
No puedes usar la Atlas CLI para gestionar el cifrado con la gestión de claves del cliente. En su lugar, utiliza los siguientes métodos:
Crear un clúster por proyecto
Para crear un clúster de una sola región para tus entornos de desarrollo y prueba, ejecuta el siguiente comando para cada proyecto que hayas creado. Cambia los IDs y nombres para usar tus valores:
Nota
También puede utilizar la API de administración de Atlas de clústeres para crear un clúster.
Este ejemplo no habilita el escalado automático para controlar los costos en entornos de desarrollo y pruebas. Para entornos de prueba y producción, elescalado automático debe estar habilitado.
atlas clusters create CustomerPortalDev \ --projectId 56fd11f25f23b33ef4c2a331 \ --region EASTERN_US \ --members 3 \ --tier M10 \ --provider GCP \ --mdbVersion 8.0 \ --diskSizeGB 30 \ --tag bu=ConsumerProducts \ --tag teamName=TeamA \ --tag appName=ProductManagementApp \ --tag env=Production \ --tag version=8.0 \ --tag email=marissa@example.com \ --watch
Para configurar un clúster multiregional, crea el siguiente archivo cluster.json para cada proyecto que creaste. Cambia las IDs y nombres para usar tus valores.
{ "name": "CustomerPortalDev", "projectId": "56fd11f25f23b33ef4c2a331", "clusterType": "REPLICASET", "diskSizeGB": 30, "mongoDBMajorVersion": "8.0", "backupEnabled": true, "replicationSpecs": [ { "numShards": 1, "regionConfigs": [ { "providerName": "GCP", "regionName": "EASTERN_US", "members": 3, "priority": 7, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } } }, { "providerName": "GCP", "regionName": "CENTRAL_US", "members": 2, "priority": 5, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } } }, { "providerName": "GCP", "regionName": "WESTERN_US", "members": 2, "priority": 4, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } } } ] } ], "tags": [ { "key": "bu", "value": "ConsumerProducts" }, { "key": "teamName", "value": "TeamA" }, { "key": "appName", "value": "ProductManagementApp" }, { "key": "env", "value": "Production" }, { "key": "version", "value": "8.0" }, { "key": "email", "value": "marissa@example.com" } ] }
Después de crear el archivo de configuración anterior, ejecuta el siguiente comando para crear el clúster:
atlas clusters create --file <path to your configuration file>
Para crear un clúster de una sola región para sus entornos de preparación y producción, cree el siguiente archivo cluster.json para cada proyecto que haya creado. Cambia los IDs y nombres para usar tus valores:
{ "clusterType": "REPLICASET", "links": [], "name": "CustomerPortalProd", "mongoDBMajorVersion": "8.0", "replicationSpecs": [ { "numShards": 1, "regionConfigs": [ { "electableSpecs": { "instanceSize": "M30", "nodeCount": 3 }, "priority": 7, "providerName": "GCP", "regionName": "EASTERN_US", "analyticsSpecs": { "nodeCount": 0, "instanceSize": "M30" }, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "readOnlySpecs": { "nodeCount": 0, "instanceSize": "M30" } } ], "zoneName": "Zone 1" } ], "tag" : [{ "bu": "ConsumerProducts", "teamName": "TeamA", "appName": "ProductManagementApp", "env": "Production", "version": "8.0", "email": "marissa@example.com" }] }
Después de crear el archivo cluster.json, ejecute el siguiente comando para cada proyecto creado. El comando usa el archivo cluster.json para crear un clúster.
atlas cluster create --projectId 5e2211c17a3e5a48f5497de3 --file cluster.json
Para configurar un clúster multiregional, modifica el arreglo replicationSpecs en el archivo cluster.json anterior para especificar varias regiones, como se muestra en el siguiente ejemplo:
{ … "replicationSpecs": [ { "numShards": 1, "regionConfigs": [ { "electableSpecs": { "instanceSize": "M30", "nodeCount": 3 }, "priority": 7, "providerName": "GCP", "regionName": "EASTERN_US", "analyticsSpecs": { "nodeCount": 0, "instanceSize": "M30" }, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "readOnlySpecs": { "nodeCount": 0, "instanceSize": "M30" } }, { "electableSpecs": { "instanceSize": "M30", "nodeCount": 3 }, "priority": 5, "providerName": "GCP", "regionName": "CENTRAL_US", "analyticsSpecs": { "nodeCount": 0, "instanceSize": "M30" }, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "readOnlySpecs": { "nodeCount": 0, "instanceSize": "M30" } }, { "electableSpecs": { "instanceSize": "M30", "nodeCount": 3 }, "priority": 6, "providerName": "GCP", "regionName": "WESTERN_US", "analyticsSpecs": { "nodeCount": 0, "instanceSize": "M30" }, "autoScaling": { "compute": { "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "readOnlySpecs": { "nodeCount": 0, "instanceSize": "M30" } } ], "zoneName": "Zone 1" } ], … }
Después de crear el archivo de configuración anterior, ejecuta el siguiente comando para crear el clúster:
atlas clusters create --file <path to your configuration file>
Para obtener más opciones de configuración e información sobre estos ejemplos, consulte Crear clústeres de atlas.
Nota
Antes de poder crear recursos con Terraform, debe:
Crea tu organización pagadora y crea una clave de API para la organización pagadora. Guarde su clave API como variables de entorno ejecutando el siguiente comando en el terminal:
export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>" export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
Importante
Los siguientes ejemplos utilizan MongoDB Atlas Terraform proveedor versión 2.x (~> 2.2). Si estás actualizando desde la versión 1.x del proveedor, consulta la 2.0.0 Guía de actualización para cambios disruptivos y pasos de migración. Los ejemplos utilizan el recurso mongodbatlas_advanced_cluster con la versión v2.x sintaxis.
Crear los Proyectos y implementaciones
Para tus entornos de desarrollo y prueba, crea los archivos siguientes para cada aplicación y par de entornos. Coloca los archivos de cada aplicación y par de entornos en su propio directorio. Cambia las IDs y los nombres para usar tus valores:
main.tf
# Create a Project resource "mongodbatlas_project" "atlas-project" { org_id = var.atlas_org_id name = var.atlas_project_name } # Create an Atlas Advanced Cluster resource "mongodbatlas_advanced_cluster" "atlas-cluster" { project_id = mongodbatlas_project.atlas-project.id name = "ClusterPortalDev" cluster_type = "REPLICASET" mongo_db_major_version = var.mongodb_version # MongoDB recommends enabling auto-scaling # When auto-scaling is enabled, Atlas may change the instance size, and this use_effective_fields # block prevents Terraform from reverting Atlas auto-scaling changes use_effective_fields = true replication_specs = [ { region_configs = [ { electable_specs = { instance_size = var.cluster_instance_size_name node_count = 3 } auto_scaling = { compute_enabled = true compute_scale_down_enabled = true compute_max_instance_size = "M60" compute_min_instance_size = "M10" } priority = 7 provider_name = var.cloud_provider region_name = var.atlas_region } ] } ] tags = { BU = "ConsumerProducts" TeamName = "TeamA" AppName = "ProductManagementApp" Env = "Test" Version = "8.0" Email = "marissa@example.com" } } # Outputs to Display output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv } output "project_name" { value = mongodbatlas_project.atlas-project.name }
Nota
Para crear un clúster multirregional, especifique cada región en su propio objeto region_configs y anímelas en el objeto replication_specs. Los campos priority deben definirse en orden descendente y deben constar de valores entre 7 y 1, como se muestra en el siguiente ejemplo:
replication_specs = [ { region_configs = [ { electable_specs = { instance_size = "M10" node_count = 2 } auto_scaling = { compute_enabled = true compute_scale_down_enabled = true compute_max_instance_size = "M60" compute_min_instance_size = "M10" } provider_name = "GCP" priority = 7 region_name = "NORTH_AMERICA_NORTHEAST_1" }, { electable_specs = { instance_size = "M10" node_count = 3 } auto_scaling = { compute_enabled = true compute_scale_down_enabled = true compute_max_instance_size = "M60" compute_min_instance_size = "M10" } provider_name = "GCP" priority = 6 region_name = "WESTERN_US" } ] } ]
variables.tf
# MongoDB Atlas Provider Authentication Variables # Legacy API key authentication (backward compatibility) variable "mongodbatlas_public_key" { type = string description = "MongoDB Atlas API public key" sensitive = true } variable "mongodbatlas_private_key" { type = string description = "MongoDB Atlas API private key" sensitive = true } # Recommended: Service account authentication variable "mongodb_service_account_id" { type = string description = "MongoDB service account ID for authentication" sensitive = true default = null } variable "mongodb_service_account_key_file" { type = string description = "Path to MongoDB service account private key file" sensitive = true default = null } # Atlas Organization ID variable "atlas_org_id" { type = string description = "Atlas Organization ID" } # Atlas Project Name variable "atlas_project_name" { type = string description = "Atlas Project Name" } # Atlas Project Environment variable "environment" { type = string description = "The environment to be built" } # Cluster Instance Size Name variable "cluster_instance_size_name" { type = string description = "Cluster instance size name" } # Cloud Provider to Host Atlas Cluster variable "cloud_provider" { type = string description = "AWS or GCP or Azure" } # Atlas Region variable "atlas_region" { type = string description = "Atlas region where resources will be created" } # MongoDB Version variable "mongodb_version" { type = string description = "MongoDB Version" } # Atlas Group Name variable "atlas_group_name" { type = string description = "Atlas Group Name" }
terraform.tfvars
atlas_org_id = "32b6e34b3d91647abb20e7b8" atlas_project_name = "Customer Portal - Dev" environment = "dev" cluster_instance_size_name = "M10" cloud_provider = "AWS" atlas_region = "US_WEST_2" mongodb_version = "8.0"
provider.tf
# Define the MongoDB Atlas Provider terraform { required_providers { mongodbatlas = { source = "mongodb/mongodbatlas" version = "~> 2.2" } } required_version = ">= 1.0" } # Configure the MongoDB Atlas Provider provider "mongodbatlas" { # Legacy API key authentication (backward compatibility) public_key = var.mongodbatlas_public_key private_key = var.mongodbatlas_private_key # Recommended: Service account authentication # Uncomment and configure the following for service account auth: # service_account_id = var.mongodb_service_account_id # private_key_file = var.mongodb_service_account_key_file }
Para sus entornos de prueba y producción, cree los siguientes archivos para cada aplicación y entorno. Coloque los archivos de cada aplicación y entorno en su propio directorio. Cambie los ID y los nombres para usar sus valores:
main.tf
# Create a Group to Assign to Project resource "mongodbatlas_team" "project_group" { org_id = var.atlas_org_id name = var.atlas_group_name usernames = [ "user1@example.com", "user2@example.com" ] } # Create a Project resource "mongodbatlas_project" "atlas-project" { org_id = var.atlas_org_id name = var.atlas_project_name } # Assign the team to project with specific roles resource "mongodbatlas_team_project_assignment" "project_team" { project_id = mongodbatlas_project.atlas-project.id team_id = mongodbatlas_team.project_group.team_id role_names = ["GROUP_READ_ONLY", "GROUP_CLUSTER_MANAGER"] } # Create an Atlas Advanced Cluster resource "mongodbatlas_advanced_cluster" "atlas-cluster" { project_id = mongodbatlas_project.atlas-project.id name = "ClusterPortalProd" cluster_type = "REPLICASET" mongo_db_major_version = var.mongodb_version use_effective_fields = true replication_specs = [ { region_configs = [ { electable_specs = { instance_size = var.cluster_instance_size_name node_count = 3 disk_size_gb = var.disk_size_gb } auto_scaling = { disk_gb_enabled = var.auto_scaling_disk_gb_enabled compute_enabled = var.auto_scaling_compute_enabled compute_max_instance_size = var.compute_max_instance_size } priority = 7 provider_name = var.cloud_provider region_name = var.atlas_region } ] } ] tags = { BU = "ConsumerProducts" TeamName = "TeamA" AppName = "ProductManagementApp" Env = "Production" Version = "8.0" Email = "marissa@example.com" } } # Outputs to Display output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.standard_srv } output "project_name" { value = mongodbatlas_project.atlas-project.name }
Nota
Para crear un clúster multiregional, especifique cada región en su propio objeto region_configs y anídelos en el objeto replication_specs, como se muestra en el siguiente ejemplo:
replication_specs = [ { region_configs = [ { electable_specs = { instance_size = "M10" node_count = 2 } provider_name = "GCP" priority = 7 region_name = "NORTH_AMERICA_NORTHEAST_1" }, { electable_specs = { instance_size = "M10" node_count = 3 } provider_name = "GCP" priority = 6 region_name = "WESTERN_US" } ] } ]
variables.tf
# MongoDB Atlas Provider Authentication Variables # Legacy API key authentication (backward compatibility) variable "mongodbatlas_public_key" { type = string description = "MongoDB Atlas API public key" sensitive = true } variable "mongodbatlas_private_key" { type = string description = "MongoDB Atlas API private key" sensitive = true } # Recommended: Service account authentication variable "mongodb_service_account_id" { type = string description = "MongoDB service account ID for authentication" sensitive = true default = null } variable "mongodb_service_account_key_file" { type = string description = "Path to MongoDB service account private key file" sensitive = true default = null } # Atlas Organization ID variable "atlas_org_id" { type = string description = "Atlas Organization ID" } # Atlas Project Name variable "atlas_project_name" { type = string description = "Atlas Project Name" } # Atlas Project Environment variable "environment" { type = string description = "The environment to be built" } # Cluster Instance Size Name variable "cluster_instance_size_name" { type = string description = "Cluster instance size name" } # Cloud Provider to Host Atlas Cluster variable "cloud_provider" { type = string description = "AWS or GCP or Azure" } # Atlas Region variable "atlas_region" { type = string description = "Atlas region where resources will be created" } # MongoDB Version variable "mongodb_version" { type = string description = "MongoDB Version" } # Atlas Group Name variable "atlas_group_name" { type = string description = "Atlas Group Name" }
terraform.tfvars
atlas_org_id = "32b6e34b3d91647abb20e7b8" atlas_project_name = "Customer Portal - Prod" environment = "prod" cluster_instance_size_name = "M30" cloud_provider = "AWS" atlas_region = "US_WEST_2" mongodb_version = "8.0" atlas_group_name = "Atlas Group"
provider.tf
# Define the MongoDB Atlas Provider terraform { required_providers { mongodbatlas = { source = "mongodb/mongodbatlas" version = "~> 2.2" } } required_version = ">= 1.0" } # Configure the MongoDB Atlas Provider provider "mongodbatlas" { # Legacy API key authentication (backward compatibility) public_key = var.mongodbatlas_public_key private_key = var.mongodbatlas_private_key # Recommended: Service account authentication # Uncomment and configure the following for service account auth: # service_account_id = var.mongodb_service_account_id # private_key_file = var.mongodb_service_account_key_file }
Para obtener más opciones de configuración e información sobre este ejemplo, consulta MongoDB y HashiCorp Terraform y la Entrada de Blog de MongoDB Terraform.
Después de crear los archivos, navega hasta el directorio correspondiente al par de aplicación y entorno de cada uno y ejecuta el siguiente comando para inicializar Terraform:
terraform init
Ejecute el siguiente comando para ver el plan de Terraform:
terraform plan
Ejecute el siguiente comando para crear un proyecto y una implementación para la aplicación y el entorno. El comando utiliza los archivos y el Terraform de MongoDB y HashiCorp para crear los proyectos y clústeres:
terraform apply
Cuando se le indique, escriba yes y presione Enter para aplicar la configuración.
Próximos pasos
Una vez que planifique la jerarquía y el tamaño de sus organizaciones, proyectos y clústeres, consulte los siguientes recursos sugeridos o utilice la navegación izquierda para encontrar funcionalidades y mejores prácticas para cada pilar del Marco Bien Arquitectado.