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