Planning failed. Terraform encountered an error while generating this plan.

 

Error: invalid value for name (must only contain alphanumeric characters, hyphens, underscores, commas, periods, @ symbols, plus and equals signs)

Solutions : please check data type in associtaed variable block 

How to use variable in terraform ?

 

main.tf

provider "aws" {

    region = "us-east-1"

  

}

resource "aws_security_group" "allow_ssh" {

    name = "allow_ssh_oracle_mssql_port"

    description = "allow_ssh_oracle_mssql_port "

    ingress {

    description      = "ssh-port"

    from_port        = 22

    to_port          = 22

    protocol         = "tcp"

    cidr_blocks      = [var.my_ip]

  }

  ingress {

    description      = "Oracle-port "

    from_port        = 1521

    to_port          = 1521

    protocol         = "tcp"

    cidr_blocks      = [var.my_ip]

  }

  ingress {

    description      = "MSSQL-Port"

    from_port        = 1433

    to_port          = 1433

    protocol         = "tcp"

    cidr_blocks      = [var.my_ip]

  }

  egress {

    from_port        = 0

    to_port          = 0

    protocol         = "-1"

    cidr_blocks      = ["0.0.0.0/0"]

    #ipv6_cidr_blocks = [var.my_ip]

  }

  tags = {

    Name = "allow_imp_port_Oracle_MSSQL_ssh"

  }

} 

  

variables.tf

variable "my_ip" {

  default = "34.207.6.67/32"

}

Terraform commands

terraform init

terraform plan

terraform apply

How to Print output from resources using terraform ?

test_output.tf 

provider "aws" {

    region = "us-east-1"

  

}

resource "aws_eip" "eip1" {

    domain = "vpc"

  

}

output "My_Public_ip" {

  

   value = aws_eip.eip1.public_ip

}

Terraform commands

terraform init

terraform plan

terraform apply

How to Create github repository using terraform ?

terraform {

  required_providers {

    github = {

      source  = "integrations/github"

      version = "~> 5.0"

    }

  }

}

# Configure the GitHub Provider

provider "github" {

    token = "Put-Github-Token"

}

resource "github_repository" "MyFirstRepo" {

  name = "terraform-module1"

  description = "This Module contain code for Start"

  visibility = "public"

}

Terraform commands

terraform init

terraform plan

terraform apply

How to Create / launch AWS EC2 instance using Terraform ?

MyFirst-EC2.tf

####Define credential to connect with providers

provider "aws" {

    region = "us-east-1"

    access_key = "Put-Your-Access_Key"

    secret_key = "Put-Your-Secret_Key"

  

}

#### Create Resource i.e. EC2 

resource "aws_instance" "MyEc2" {

 ami = "ami-05548f9cecf47b442"  

 instance_type = "t2.micro"

 

}

Terraform commands 

terraform init

terraform plan

terraform apply

AWS Oracle Classic RDS Features & Limitataion

Edition and licensing => License included (SE2) or BYOL (SE2/EE)

Multitenant PDB in CDB (licence & Maint cost reduction)  => 1 PDB

No of Database => 1 DB per RDS instance

Applications require access to underlying OS =>  N/A

Applications require access to underlying DB Env =>  N/A

sysdba privilege access  => N/A

Huge Pages (better Performance) => N/A

Local Undo => N/A

Data Guard Max Availability => with Multi AZ (no access on secondary) 

RDS database Patching =>  AWS Managed

Create a Multi-AZ deployment => Yes

Change CPU cores and threads per core on DB instance class => Yes

Turn on storage autoscaling => Yes

Automatic minor version upgrade => Yes

Kerberos authentication. => Yes

Performance Insights => Yes

TDE Encryption => Yes

Billing can be stopped => Yes

Scaling AWS          => Yes

High availability =>  AWS Managed

Database backups =>  AWS  Managed

Database software install => AWS Managed

OS patching =>  AWS Managed

OS installation => AWS Managed

Storage Limit => 64TB

Migrate Oracle Database to Any Cloud (AWS,Azure,Google,IBM etc ) Using Native Tool - Datagaurd

Oracle Database Migration to Any Cloud (AWS,Azure etc )

 Pre-communication (No-Downtime)

• Ensure and agreed with plan & cutover window 
• Ensure all stakeholder should be on same page 
• Ensure everyone copid in mail and meetings
• Ensure all issue should be documented database & application wise during iteration/testing
• Dicussed and aggred who is from available during cutover winodw (application owner,database lead,infa lead etc)   

Pre-Migration Pahse (No-Downtime) 

On Source Database 

• Delete/Remove all backup tables /unused objects from database with help of application team 
• Do username & password backup  
• Get read only access to database server
• Ensure db_unique_name is the same as the db_name
• Set and crosscheck all parameter related to dataguard configuration 
• check remote connectivity is working fine and port should be open at firewall level 
• check and validate database corruption 
• prepare & test  shared mout point  (NFS/EFS/S3FS)  
• Take the database backup including archivelogs and standby control file to create standby database
• check and backup networkfiles (tnsnames.ora,listiner.ora)
• check if wallet is configured
• check if any encryption (TDE )is enables 

Prepare Target envirnoment (No-Downtime) 

• Install oracle binrary software & Build the target database server 
• Install Grid software if required 
• Install Oracle database binary 
• Configure & enable SSH & SCP (with help of root account - Infra team)
• Configure and validate all  mount points (database/aplication)
• Configure and validate same shared  mount points (NFS/EFS/S3FS) in the target server/s.
• Restore the database backup and configure standby database 
• Incase ASM add spfile to grid software using srvctl 
• Validate remote database connctivity  
• Setup dataguard replication  from primary (source) to standby (target) database 

Migration pahse (Downtime start)

• check and validate primary and standby database in sync and no GAP 
• Stop Application associated database 
• create test user/test tablespace and test table on primary database 
• Do 4-5 archive log switch on primary (source) database .
• Again check  and validate primary and standby database in sync and no GAP
• Check active database sessions in primary (source)  database. if still acitve after stopping the application ,  kill those users  
• Create a guaranteed flashback restore point - for this enough FRA space should be available 
• Multiple way to do 
• Using manual swithover 
• Using DGMGRL ( need to configure DGMGRL )
• Using manual Failover (No rollback in this case) 
• Validate the migated database
• Setup & validate connection with application  
• Configure & update on premise DNS with new IP address (target) and create load balancer rules (if using)
• Handover to application team for validation 

Post Migration phase (No-downtime) 

• Take golden database backup after successful migration 
• Configure & schedule  database jobs 
• Configure & setup database monitoring

Rollback Phase 

• Stop the application on target database 
• Rollback the database using restore point (source database)
• Update the DNS with old entry for rollback (if required)
• Start and validate the database 
• Connect with database & start the application 

 

High Level Oracle Database Migration Plan – Datapump

 Pre-Migration Phase: No Downtime

• Review the Source database configuration
• Build target environment in AWS Cloud
• Prepare target database 

 Migration Phase (cutover) : Downtime

• Source database backup 
• Transfer the backup to target
• Import backup in target database
• Validate the migrated database

 

Post-Migration Phase : Downtime

• Handover database to application team
• Application team start validation
• Decide Go-Live /No Go-Live
• Target database golden backup
• Release database and application

 

Note : Normally good for small database 

High Level Maria DB Migration Plan

Pre-migration Phase (No -downtime)

• Validate source and target database versions and engines.
• Identify hardware requirements for the target server instance.
• Identify storage requirements (storage type and capacity).
• Choose the proper instance type based on capacity, storage features, and network features.
• Identify the network access security requirements (firewall, port etc. ) for source and target databases.
• Prepare target database
• Configure and start an Amazon RDS DB instance running MariaDB.

 

Migration Phase (downtime)

• Using native tools to migrate database objects and data.
• In the source database, use mysqldump or mariadb-dump to create an output file that contains database objects and data.
• Transfer the backup to target (AWS RDS)
• In the target database, use mysql or mariadb to restore the data.
• Validate the migrated database.

 Post-migration Phase (downtime)

• Handover database to application team
• Switch the application clients over to the new migration database in AWS RDS .
• Application team start validation
• Decide Go-Live /No Go-Live
• Target database golden backup
• Release database and application

Rollback Plan 

• Start source database (Assume no data chnage on target database  after migration)
• Connect & validate Application with source database 

What Is a RACI Matrix ?

What Is a RACI Matrix ?

RACI matirix is very important when we are working on project  and this helps to align  who is reposible for what .

Like who will take decision , who will resposible for technical task , what resposiblity of cutomer and what information needs to share with custmers etc . 

R  => (Responsible)  : This member is resposible to taks done ---- like create infrastructure goes to infra team - Person1 ,Person2

A  => (Accountable) : This member is taking decision and ensure everythig is aligned and meet all standards ----which tool going to use for database assessment goes to db team -  Person2,Person1

C  => (Consulted) : Share the outcome and should be meet all criteria with input & feedback to improve the business process  - Person 3

I  = > (Informed) : Any other team ,team memebers, stakeholder who needs to informed about project status,progress ,blockers  etc -  Person 4 , Person 5