La alta disponibilidad es la capacidad de su aplicación para garantizar un funcionamiento continuo y minimizar el tiempo de inactividad durante interrupciones de la infraestructura, mantenimiento del sistema y otras interrupciones. La arquitectura de implementación predeterminada de MongoDB está diseñada para alta disponibilidad, con funciones integradas de redundancia de datos y conmutación por error automática. Esta página describe opciones de configuración adicionales y mejoras en la arquitectura de implementación que puede elegir para prevenir interrupciones y ofrecer mecanismos robustos de conmutación por error ante interrupciones de zonas, regiones y proveedores de nube.
Funciones de Atlas para alta disponibilidad
Replicación de base de datos
La arquitectura de implementación por defecto de MongoDB está diseñada para redundancia. Atlas implementa cada clúster como un Conjunto de réplicas con un mínimo de tres instancias de base de datos (también denominadas nodos o miembros del conjunto de réplicas), distribuidas en zonas de disponibilidad independientes dentro de las regiones de su proveedor de nube seleccionado. Las aplicaciones escriben datos en el nodo principal del conjunto de réplicas y, a continuación, Atlas replica y almacena esos datos en todos los nodos del clúster. Para controlar la durabilidad del almacenamiento de datos, puede ajustar la prioridad de escritura del código de su aplicación para que la escritura se complete solo cuando un número determinado de nodos secundarios la hayan confirmado. El comportamiento predeterminado es que los datos persistan en la mayoría de los nodos elegibles antes de confirmar la acción.
El siguiente diagrama representa cómo funciona la replicación para un conjunto de réplicas predeterminado de tres nodos:
Conmutación por error automática
En caso de que un nodo primario de un set de réplicas quede fuera de servicio por una Interrupción del servicio de infraestructura, mantenimiento programado u otra interrupción, los clústeres de Atlas se autorreparan promoviendo un nodo secundario existente al rol de nodo primario en una elección de set de réplicas. Este proceso de conmutación por error es completamente automático y se completa en segundos sin pérdida de datos, incluyendo las operaciones que estaban en curso en el momento de la falla, que se reintentan tras la falla si se activan escrituras reintentables. Tras una elección del set de réplicas, Atlas restaura o reemplaza el nodo con problemas para garantizar que el clúster vuelva a su configuración objetivo lo antes posible. El controlador cliente de MongoDB también conmuta automáticamente todas las conexiones de clientes durante y después de la falla.
El siguiente diagrama representa el proceso de elección del conjunto de réplicas:
Para mejorar la disponibilidad de sus aplicaciones más críticas, puede escalar su implementación añadiendo nodos, regiones o proveedores de nube para soportar interrupciones por zona, región o proveedor, respectivamente. Para obtener más información, consulte la recomendación "Escalar su paradigma de implementación para tolerancia a fallos" a continuación.
Recomendaciones para la alta disponibilidad de Atlas
Las siguientes recomendaciones describen opciones de configuración adicionales y mejoras en la arquitectura de implementación que puede realizar para aumentar la disponibilidad de su implementación.
Elija un nivel de clúster que se ajuste a sus objetivos de implementación
Al crear un nuevo clúster, puedes elegir entre un rango de niveles de clúster disponibles en los tipos de implementación Dedicados, Flex o Gratuitos. El nivel de clúster en MongoDB Atlas especifica los recursos (memoria, almacenamiento, vCPU e IOPS) disponibles para cada nodo en su clúster. Escalar a un nivel superior mejora la capacidad de tu clúster para gestionar picos de tráfico y aumenta la fiabilidad del sistema mediante una respuesta más rápida a cargas de trabajo elevadas. Para determinar el nivel de clúster recomendado para el tamaño de tu aplicación, consulta el Guía de tamaños de clústeres Atlas.
Atlas también admite el escalado automático para que el clúster se ajuste automáticamente a los picos de demanda. Automatizar esta acción reduce el riesgo de interrupciones debido a limitaciones de recursos. Para obtener más información, consulte la Guía para el aprovisionamiento automatizado de infraestructura de Atlas.
Escala tu paradigma de implementación para tolerancia a fallos
La tolerancia a fallos de una implementación de Atlas puede medirse como el número de miembros del set de réplicas que pueden volverse inactivos mientras tu implementación sigue siendo operativa. En caso de una Interrupción del servicio de la zona de disponibilidad, región o del proveedor de nube, los clústeres de Atlas se autorrecuperan promoviendo un nodo secundario existente al rol de nodo primario en una elección del set de réplicas. La mayoría de los nodos votantes en un set de réplicas deben estar operativos para realizar una elección del set de réplicas cuando un nodo primario experimenta una Interrupción del servicio.
Para garantizar que un set de réplicas pueda elegir un primario en caso de una Interrupción del servicio parcial de la región, se debe implementar clústeres en regiones con al menos tres zonas de disponibilidad. Las zonas de disponibilidad son grupos separados de centros de datos dentro de una única región del proveedor de nube, cada uno con su propia energía, refrigeración e infraestructura de red. Atlas distribuye automáticamente su clúster entre zonas de disponibilidad cuando estas son compatibles con la región del proveedor de la nube seleccionado, asegurando que si una zona experimenta una Interrupción del servicio, los nodos restantes en su clúster sigan soportando los servicios regionales. La mayoría de las regiones de proveedores de nube soportadas por Atlas tienen al menos tres zonas de disponibilidad. Estas regiones están marcadas con un icono de estrella en la interfaz de usuario de Atlas. Para obtener más información sobre las regiones recomendadas, consulta Proveedores de nube y regiones.
Para mejorar aún más la tolerancia a fallas de tus aplicaciones más críticas, puedes escalar tu implementación añadiendo nodos, regiones o proveedores de la nube para resistir interrupciones de zona de disponibilidad, región o proveedor, respectivamente. Puedes aumentar el número de nodos a cualquier número impar, con un máximo de 7 nodos elegibles y 50 nodos en total. También puedes implementar un clúster en múltiples regiones para mejorar la disponibilidad en una geografía más amplia y permitir la conmutación por error automática en caso de una Interrupción del servicio total de la región que desactive todas las zonas de disponibilidad dentro de tu región principal. El mismo patrón se aplica cuando se implementa tu clúster en múltiples proveedores de nube para resistir una Interrupción del servicio total del proveedor de nube.
Para obtener orientación sobre cómo elegir una implementación que equilibre tus necesidades de alta disponibilidad, baja latencia, cumplimiento y costo, consulta nuestra documentación de Paradigmas de implementación de Atlas.
Prevenir la eliminación accidental del clúster
Puedes habilitar la protección contra terminación para garantizar que un clúster no se termine accidentalmente y requiera tiempo de inactividad para la restauración desde una copia de seguridad. Para borrar un clúster que tiene habilitada la protección contra terminación, primero debes desactivar la protección contra terminación. Por defecto, Atlas desactiva la protección contra la terminación para todos los clústeres.
Habilitar la protección contra la terminación es especialmente importante cuando se aprovecha HerramientasIaC como Terraform para garantizar que una redistribución no suponga la provisión de nueva infraestructura.
Pruebe las conmutaciones automáticas por error
Antes de implementar una aplicación en producción, recomendamos encarecidamente que simules varios escenarios que requieran conmutaciones por error automáticas de nodos para medir tu preparación ante tales eventos. Con Atlas puedes probar el failover del nodo primario para un set de réplicas y simular interrupciones regionales para una implementación de multiregión.
Usar majority Nivel de confirmación de escritura
MongoDB permite especificar el nivel de confirmación solicitado para las operaciones de escritura mediante nivel de confirmación de escritura (write concern). Atlas tiene un nivel de confirmación de escritura (write concern) por defecto de majority, lo que significa que los datos deben replicarse en más de la mitad de los nodos de tu clúster antes de que Atlas informe éxito. Usar majority en lugar de un valor numérico definido como 2 permite que Atlas se ajuste automáticamente a requerir replicación en menos nodos si se experimenta una Interrupción del servicio temporal de nodos, permitiendo que las escrituras continúen después de una conmutación por error automática. Esto también provee un ajuste coherente en todos los entornos, por lo que tu cadena de conexión permanece igual tanto si tienes tres nodos en un entorno de prueba como si tienes un mayor número de nodos en producción.
Configura operaciones de lectura y escritura en base de datos con reintentos
Atlas admite operaciones de lectura y escritura reintentables. Cuando está habilitado, Atlas reintenta las operaciones de lectura y escritura una vez como medida de protección contra interrupciones intermitentes de la red y elecciones de conjuntos de réplicas en las que la aplicación no puede encontrar temporalmente un nodo principal en buen estado. Las escrituras reintentables requieren una solicitud de escritura confirmada, lo que significa que su solicitud de escritura no puede {w:
0} ser.
Supervise y planifique su utilización de recursos
Para evitar problemas de capacidad de recursos, te recomendamos que supervises el uso de recursos y realices sesiones regulares de planificación de capacidad. Los Professional Services de MongoDB ofrecen estas sesiones. Consulta nuestro Plan de recuperación ante desastres por capacidad de recursos para conocer nuestras recomendaciones sobre cómo recuperarse de problemas de capacidad de recursos.
Para aprender las mejores prácticas para alertas y supervisión de la utilización de recursos, consulte Orientación para la supervisión y las alertas de Atlas.
Planifica tus cambios de versión de MongoDB
Le recomendamos que ejecute la última versión de MongoDB para aprovechar las nuevas funciones y las garantías de seguridad mejoradas. Asegúrese siempre de actualizar a la última versión principal de MongoDB antes de que su versión actual deje de estar disponible.
No puedes degradar tu versión de MongoDB usando la interfaz de usuario de Atlas. Por ello, recomendamos trabajar directamente con los Professional Services o los Servicios técnicos de MongoDB al planificar y ejecutar una actualización de versión importante, para ayudarte a evitar cualquier problema que pueda surgir durante el proceso de actualización.
Configure las Windows de mantenimiento
Atlas mantiene el tiempo de actividad durante el mantenimiento programado aplicando actualizaciones de manera progresiva a un nodo a la vez. Siempre que el primario actual se apague para mantenimiento durante este proceso, Atlas elige un nuevo primario mediante una elección de set de réplicas automática. Este es el mismo proceso que ocurre durante la conmutación por error automática en respuesta a una Interrupción del servicio imprevista del nodo primario.
Recomendamos que configurar un periodo de mantenimiento personalizado para su Proyecto para evitar elecciones de sets de réplicas relacionadas con el mantenimiento durante las horas críticas para el negocio. También puedes establecer horas protegidas en la configuración de tu periodo de mantenimiento para definir un intervalo diario en el que no pueden comenzar las actualizaciones estándar. Las actualizaciones estándar no implican reinicio ni resincronización del clúster.
Ejemplos de automatización: Alta disponibilidad de Atlas
Los siguientes ejemplos configuran la topología de implementación de set de réplicas / partición de región única, 3 nodo 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 utilizan AWS, Azure y Google Cloud de manera intercambiable. Puedes usar cualquiera de estos tres proveedores de nube, pero debes cambiar el nombre de la región para que coincida con el proveedor de nube. Para conocer los proveedores de nube y sus regiones, consulta Proveedores de Nube.
Nivel de clúster establecido en
M30para una aplicación de tamaño mediano. Utiliza la guía de tamaños 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 utilizan AWS, Azure y Google Cloud de manera intercambiable. Puedes usar cualquiera de estos tres proveedores de nube, pero debes cambiar el nombre de la región para que coincida con el proveedor de nube. Para conocer los proveedores de nube y sus regiones, consulta 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 una implementación por proyecto
Para sus entornos de desarrollo y pruebas, ejecute el siguiente comando para cada proyecto. En el siguiente ejemplo, cambia los IDs y los nombres para usar tus valores.
Nota
El siguiente ejemplo no habilita el escalado automático para ayudar a controlar los costos en los entornos de desarrollo y prueba. Para los entornos de staging y producción, el escalado automático debe estar habilitado. Consulta la pestaña "Entornos de staging y producción" para ver ejemplos que permiten el escalado automático.
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=dev \ --tag version=8.0 \ --tag email=marissa@example.com \ --watch
Para sus entornos de prueba 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, ejecutar el siguiente comando para cada proyecto. El comando usa el archivo cluster.json para crear un clúster.
atlas cluster create --projectId 5e2211c17a3e5a48f5497de3 --file cluster.json
Para obtener más opciones de configuración e información sobre este ejemplo, consulta el comando atlas clústeres create.
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 }
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.
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 }
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.
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.