Las organizaciones, los proyectos y los clústeres son los componentes básicos de su 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 y un límite de autorización más detallados.
Los clústeres son sus bases de datos en la nube en Atlas.
Utilice la guía básica de esta página para diseñar la distribución de sus organizaciones, proyectos y clústeres según la jerarquía de su empresa y el número previsto de clústeres y proyectos. Esta guía le ayuda a optimizar la seguridad y el rendimiento desde el principio, ajustándose a las necesidades de facturación y acceso de su empresa.
Funciones para organizaciones, proyectos y clústeres de Atlas
Puede utilizar los siguientes niveles de jerarquía para definir la configuración de seguridad y la gobernanza de su patrimonio empresarial de Atlas:
Nivel de jerarquía del Atlas | Descripción |
|---|---|
(Opcional) Organización pagadora | Uno Una organización puede ser la organización que paga a otras organizaciones. Una organización que paga permite configurar la facturación entre organizaciones para compartir una suscripción de facturación entre varias. Para obtener más información sobre cómo configurar su organización que paga al establecer la suscripción a Atlas, consulte "Administrar facturación". Para habilitar la facturación entre organizaciones, el usuario que realiza la acción debe tener el rol de propietario de la organización o administrador de facturación en ambas organizaciones que desea vincular. Para obtener más información, consulte "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 las VPC/VNet dedicadas para un proyecto. La configuración de seguridad se comparte entre los clústeres del proyecto, excepto los roles de usuario y la autorización de la base de datos, que se pueden aplicar a acciones a 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 multirregionales y multinube, considere las siguientes recomendaciones adicionales para optimizar el rendimiento, la seguridad y el cumplimiento en todos los límites geográficos:
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.
Utilice VPC/VNets dedicadas por región dentro de cada proyecto para mantener el aislamiento de la red.
Configure puntos finales privados en cada región donde implemente 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.
Etiquete proyectos y clústeres con clasificación de datos y requisitos de cumplimiento regional para fines 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.
Mantenga programas de respaldo consistentes en todas las regiones dentro del mismo entorno de aplicaciones.
Pruebe periódicamente los procedimientos de recuperación ante desastres en todas las regiones para garantizar la continuidad del negocio.
Consideraciones sobre la multinube
Utilice convenciones de nomenclatura consistentes entre los proveedores de nube para simplificar la administración y la supervisión.
Estandarice 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 del paradigma de implementación
Las siguientes recomendaciones se 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) | Pruebe componentes o funciones específicos creados en el entorno de desarrollo. |
Puesta en escena | 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 (Prod) | 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 CLI de Atlas con Docker para crear, ejecutar y administrar implementaciones locales de Atlas mediante contenedores. Los contenedores son unidades estandarizadas que contienen todo el software necesario para ejecutar una aplicación. La contenedorización permite a los desarrolladores crear implementaciones locales de Atlas en entornos de prueba seguros, confiables y portátiles. Para obtener más información, consulte Crear 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 alcanza fácilmente el 250 límite de proyectos por organización, le recomendamos crear una organización por entorno, por ejemplo, una para cada entorno, ya sea inferior o superior, o una para desarrollo, pruebas, pruebas de ensayo y producción. Esta configuración ofrece la ventaja de un mayor aislamiento. También puede aumentar los límites. Para obtener más información, consulte Límites del servicio 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
Considere la siguiente jerarquía, que crea menos organizaciones Atlas, si tiene equipos y permisos comunes en toda la unidad de negocio y menos del límite elevable 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.
Puede compartir configuraciones a nivel de proyecto, como puntos finales privados y CMK, entre clústeres con herramientas de automatización como Terraform, durante la creación del clúster. Además, automatizar la creación de clústeres puede generar ahorros al estandarizar la creación de entornos paralelos de nivel superior e inferior para los 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 varios clústeres Atlas, agrupados por entorno. Implementar varios clústeres dentro del mismo proyecto simplifica la administración cuando una aplicación utiliza varios clústeres de respaldo o el mismo equipo es responsable de varias aplicaciones en diferentes entornos. Esto reduce el costo de configuración de funciones como endpoints privados y claves administradas por el cliente, ya que todos los clústeres del mismo proyecto comparten la misma configuración.
Sin embargo, esta jerarquía de clústeres puede violar el principio del 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á creando clústeres para entornos de desarrollo y pruebas. En entornos de prueba y producción, recomendamos que los clústeres de un mismo proyecto pertenezcan a la misma aplicación y sean administrados por el mismo equipo.
Etiquetado de recursos
Le recomendamos que etiquete los clústeres o proyectos con los siguientes detalles para permitir un análisis sencillo para informes 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 de tamaño de clústeres Atlas
En una implementación dedicada (tamaño de clúster M10+), Atlas asigna recursos de forma exclusiva. Recomendamos implementaciones dedicadas para casos de producción, ya que 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.
Puede estimar los recursos del clúster que requiere su implementación utilizando el tamaño de datos y la carga de trabajo aproximados de su organización:
Almacenamiento total requerido: 50% del tamaño total de los datos sin procesar
RAM total requerida: 10% del tamaño total de los datos sin procesar
Total de Núcleos de CPU Requeridos: operaciones de lectura/escritura de base de datos pico esperadas por segundo ÷ 4000
IOPS totales de almacenamiento requeridas: pico esperado de operaciones de lectura/escritura de base de datos por segundo (IOPS mínimas = 5%, IOPS máximas = 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ño de clúster también incluye valores esperados para el tamaño total de datos y las IOPS predeterminadas del clúster, que puede ampliar con configuraciones adicionales. Tenga en cuenta que las siguientes recomendaciones de almacenamiento son por fragmento, no para todo el clúster. Para obtener más información, consulte la Guía de escalabilidad de Atlas.
Talla de camiseta | Nivel de clúster | Rango de almacenamiento: AWS/Google Cloud/Azure | CPUs (#) | RAM por defecto | IOPS predeterminadas | Tamaño de datos mediano 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 | Solo desarrollo/prueba |
Med |
| 8 GB a 512 GB | 2 | 8 GB | 3000 | 20 GB a 50 GB | 3000 | Prod |
Grandes |
| 8 GB a 4 TB | 16 | 32 GB | 3000 | 360 GB a 420 GB | 11000 | Prod |
X-Large |
| 8 GB a 4 TB | 32 | 128 GB | 3000 | 1200 GB a 1750 GB | 39000 | Prod |
| [1] | M10 Es un nivel de CPU compartido. Para industrias con alta regulación o datos confidenciales, el nivel inicial mínimo 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, consulte la documentación de Atlas para cada proveedor de nube:
Ejemplos de automatización: organizaciones, proyectos y clústeres de Atlas
Tip
Para ver ejemplos de Terraform que aplican nuestras recomendaciones en todos los pilares, consulte uno de los siguientes ejemplos en GitHub:
Los siguientes ejemplos crean organizaciones, proyectos y clústeres utilizando herramientas Atlas para la automatización.
Estos ejemplos también se aplican a 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 conjunto de réplicas/fragmentos de región única y 3nodos.
Nuestros ejemplos utilizan AWS, Azure y Google Cloud indistintamente. Puede usar cualquiera de estos tres proveedores de nube, pero debe cambiar el nombre de la región para que coincida con el del proveedor. 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 conjunto de réplicas/fragmentos de región única y 3nodos.
Nuestros ejemplos utilizan AWS, Azure y Google Cloud indistintamente. Puede usar cualquiera de estos tres proveedores de nube, pero debe cambiar el nombre de la región para que coincida con el del proveedor. 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, debe:
Crea tu organización pagadora y crea una clave de API para la organización pagadora.
Conéctese desde la CLI de Atlas siguiendo los pasos para Programmatic Use.
Crear las organizaciones
Ejecute el siguiente comando para cada BU. Cambie los ID y los nombres para usar los 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 a su organización pagadora mediante programación mediante la API de Administración de Atlas. Para ello, envíe una solicitud POST al punto final https://cloud.mongodb.com/api/atlas/v2/orgs y especifique el ID de la organización pagadora en el campo federationSettingsId. La cuenta de servicio o la clave API solicitante debe tener el rol de "Propietario de la organización" y la organización solicitante debe ser una organización pagadora.
El siguiente ejemplo utiliza 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 API anterior, consulte la documentación de creación de API de las organizaciones del atlas.
Para obtener los ID de usuario y de organización, consulte los siguientes comandos:
Crear los proyectos
Ejecute el siguiente comando para cada par de aplicaciones y entornos. Cambie los ID y los nombres para usar sus 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 proyecto, consulte el siguiente comando:
Configurar el cifrado con la gestión de claves del cliente
Para entornos de prueba y producción, recomendamos habilitar el cifrado con administración de claves del cliente al aprovisionar los clústeres. Para desarrollo y pruebas, considere omitir el cifrado con administración de claves del cliente para ahorrar costos, a menos que trabaje en un sector altamente regulado o almacene datos confidenciales. Para obtener más información, consulte Recomendaciones para organizaciones, proyectos y clústeres de Atlas.
No se puede usar la CLI de Atlas para administrar el cifrado con la administración de claves del cliente. En su lugar, utilice los siguientes métodos:
Crear un clúster por proyecto
Para crear un clúster de una sola región para sus entornos de desarrollo y pruebas, ejecute el siguiente comando para cada proyecto creado. Cambie los ID y los nombres para usar sus 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, ejecute 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 ensayo y producción, cree el siguiente archivo cluster.json para cada proyecto. Cambie los ID y los nombres para usar sus 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 multirregional, modifique la matriz replicationSpecs en el archivo cluster.json anterior para especificar múltiples 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, ejecute 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, debes:
Cree su organización pagadora y genere una clave API para ella. Guarde su clave API como variables de entorno ejecutando el siguiente comando en la 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 la 2 versión.x () del proveedor Terraform de MongoDB Atlas.~> 2.2 Si actualiza desde 1 la versión.x del proveedor, consulte la 2.0.0 Guía de actualización para conocer los cambios importantes y los pasos de migración. Los ejemplos utilizan el mongodbatlas_advanced_cluster recurso con la2 sintaxis v.x.
Crear los proyectos y las implementaciones
Para sus entornos de desarrollo y pruebas, cree los siguientes archivos para cada aplicación y entorno. Coloque cada archivo en su propio directorio. Cambie los ID y los nombres para usar sus valores:
principal.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"
proveedor.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:
principal.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 multirregional, especifique cada región en su propio objeto region_configs y anídelas 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"
proveedor.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, consulte MongoDB & HashiCorp Terraform y la publicación del blog de MongoDB Terraform.
Después de crear los archivos, navegue al directorio de cada par de aplicaciones y entornos y ejecute 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 solicite, escriba yes y presione Enter para aplicar la configuración.
Próximos pasos
Después de planificar 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 características y mejores prácticas para cada pilar de Well-Architected Framework.