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 predeterminada de MongoDB está diseñada para la 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 principal de un conjunto de réplicas deje de estar disponible debido a una interrupción de la infraestructura, mantenimiento programado o cualquier otra interrupción, los clústeres de Atlas se autorreparan promoviendo un nodo secundario existente al rol de nodo principal en una elección de conjunto de réplicas. Este proceso de conmutación por error es totalmente automático y se completa en segundos sin pérdida de datos, incluidas las operaciones en curso en el momento del fallo, que se reintentan después del fallo si las escrituras reintentables están habilitadas. Tras una elección de conjunto de réplicas, Atlas restaura o reemplaza el miembro que falla para garantizar que el clúster vuelva a su configuración de destino lo antes posible. El controlador del cliente de MongoDB también conmuta automáticamente todas las conexiones de cliente durante y después del fallo.
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, puede elegir entre una variedad de niveles de clúster disponibles en los tipos de implementación Dedicado, Flexible o Gratuito. El nivel de clúster en MongoDB Atlas especifica los recursos (memoria, almacenamiento, vCPU e IOPS) disponibles para cada nodo del clúster. Escalar a un nivel superior mejora la capacidad del clúster para gestionar picos de tráfico y aumenta la fiabilidad del sistema gracias a una respuesta más rápida a cargas de trabajo elevadas. Para determinar el nivel de clúster recomendado para el tamaño de su aplicación, consulte Guía de tamaño 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.
Escalar su paradigma de implementación para la tolerancia a fallas
La tolerancia a fallos de una implementación de Atlas se mide por la cantidad de miembros del conjunto de réplicas que pueden dejar de estar disponibles mientras la implementación sigue operativa. En caso de una interrupción en la disponibilidad de una zona, región o proveedor de nube, los clústeres de Atlas se autorreparan promoviendo un nodo secundario existente al rol de nodo principal en una elección de conjunto de réplicas. La mayoría de los nodos con derecho a voto en un conjunto de réplicas deben estar operativos para ejecutar una elección de conjunto de réplicas cuando un nodo principal experimenta una interrupción.
Para garantizar que un conjunto de réplicas pueda elegir un servidor principal en caso de una interrupción parcial en una región, debe implementar los 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 misma región de proveedor de nube, cada uno con su propia infraestructura de energía, refrigeración y red. Atlas distribuye automáticamente el clúster entre las zonas de disponibilidad cuando la región de proveedor de nube seleccionada las admite. De esta manera, si una zona sufre una interrupción, los nodos restantes del clúster seguirán admitiendo los servicios regionales. La mayoría de las regiones de proveedores de nube compatibles con 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, consulte Proveedores de nube y regiones.
Para mejorar aún más la tolerancia a fallos de sus aplicaciones más críticas, puede escalar su implementación añadiendo nodos, regiones o proveedores de nube para soportar interrupciones de disponibilidad en zonas, regiones o proveedores, respectivamente. Puede aumentar el número de nodos a cualquier número impar, con un máximo de 7 nodos seleccionables y 50 nodos en total. También puede implementar un clúster en varias regiones para mejorar la disponibilidad en una geografía más amplia y habilitar la conmutación por error automática en caso de una interrupción en toda la región que deshabilite todas las zonas de disponibilidad dentro de su región principal. El mismo patrón se aplica a la implementación de su clúster en varios proveedores de nube para soportar una interrupción total de un proveedor de nube.
Para obtener orientación sobre cómo elegir una implementación que equilibre sus necesidades de alta disponibilidad, baja latencia, cumplimiento y costo, consulte nuestra documentación de Paradigmas de implementación de Atlas.
Prevenir la eliminación accidental del clúster
Puede habilitar la protección contra terminación para evitar que un clúster se termine accidentalmente y requiera tiempo de inactividad para restaurarlo desde una copia de seguridad. Para eliminar un clúster con protección contra terminación habilitada, primero debe deshabilitarla. De forma predeterminada, Atlas deshabilita la protección contra 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.
Prueba de conmutaciones por error automáticas
Antes de implementar una aplicación en producción, le recomendamos encarecidamente que simule varios escenarios que requieren conmutaciones por error automáticas de nodos para evaluar su preparación ante tales eventos. Con Atlas, puede probar la conmutación por error del nodo principal para un conjunto de réplicas y simular interrupciones regionales para una implementación multirregional.
Usar majority Nivel de confirmación de escritura
MongoDB permite especificar el nivel de confirmación solicitado para las operaciones de escritura mediante la preocupación de escritura. Atlas tiene una preocupación de escritura predeterminada de,majority lo que significa que los datos deben replicarse en más de la mitad de los nodos del clúster para que Atlas informe que la operación se ha realizado correctamente. Usar majority en lugar de un valor numérico definido como 2 permite que Atlas se ajuste automáticamente a la necesidad de replicar en menos nodos si se produce una interrupción temporal en un nodo, lo que permite que las escrituras continúen tras la conmutación por error automática. Esto también proporciona una configuración consistente en todos los entornos, de modo que la cadena de conexión permanece igual, independientemente de si se tienen tres nodos en un entorno de prueba o un mayor número de nodos en producción.
Configurar lecturas y escrituras de bases de datos reintentables
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 la utilización de sus recursos
Para evitar problemas de capacidad de recursos, le recomendamos supervisar su utilización y realizar sesiones periódicas de planificación de la capacidad. Los Servicios Profesionales de MongoDB ofrecen estas sesiones. Consulte nuestro Plan de Recuperación ante Desastres de Capacidad de Recursos para obtener recomendaciones sobre cómo recuperarse de problemas de capacidad de recursos.
Para conocer las mejores prácticas para alertas y monitoreo de la utilización de recursos, consulte Guía para monitoreo y alertas de Atlas.
Planifique los 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 es posible cambiar a una versión anterior de MongoDB mediante la interfaz de usuario de Atlas. Por ello, le recomendamos que trabaje directamente con los Servicios Profesionales o Técnicos de MongoDB al planificar y ejecutar una actualización de versión principal para evitar cualquier problema que pueda surgir durante el proceso.
Configurar ventanas de mantenimiento
Atlas mantiene la disponibilidad durante el mantenimiento programado aplicando actualizaciones de forma continua a un nodo a la vez. Siempre que el nodo principal actual se desconecta por mantenimiento durante este proceso, Atlas elige un nuevo nodo principal mediante una elección automática de conjunto de réplicas. Este es el mismo proceso que ocurre durante la conmutación por error automática en respuesta a una interrupción imprevista del nodo principal.
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: Atlas High Availability
Los siguientes ejemplos configuran la topología de implementación de conjunto/fragmento de réplica de nodo de región3 única mediante herramientas Atlas para 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 una implementación por proyecto
Para sus entornos de desarrollo y pruebas, ejecute el siguiente comando para cada proyecto. En el siguiente ejemplo, cambie los ID y los nombres para usar sus valores.
Nota
El siguiente 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. Consulte la pestaña "Entornos de prueba y producción" para ver ejemplos que habilitan 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, ejecute 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, consulte el comando atlas clusters create.
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 }
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.
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 }
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.
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.