variable “create_vm” {
        description = “If set to true, it will create vm”
       type.           = “bool”
} 
 
 
Assignment – 2
Write a Terraform script which create a ubuntu ec2-instance and copy a ansible playbook, install ansible and run it.
Step 1 – Create ec2-instance with key and group
Step 2 – Copy playbook using file terraform provisioner
Step 3 – Install Ansible using remote terraform provisioner
Step 4 – Run Ansible playbook command using remote terraform provisioner
 
Step-1 – Create ec2-instance with key and group
 
 
data “aws_ami” “ubuntu-linux-2004” {
    most_recent = true
    owners        = [“099720109477”] 
    filter {
          name      = “name”
         values      = [“ubuntu/images/hvm-ssh/ubuntu-focal-20.04-amd64-server-*”]
 
}
 
resource “aws_instance_ ec2” “aws” {
      ami                 = “ami-2757f631”
      instance_ type = “t2. micro”
      key_name.     = “${aws_key_pair.generated_key.key_name}”
      tag                  = {
      name               = “Helloworld”
 }

 
resources “aws_key_pair” “key_pair” {
    key_name  = “linux-key-pair”
    public_key = tls_private_key.key_pair. public_key_openssh
 
}
 
resource “local_file” “ssh_key” {
       filename = “${aws_key_pair.key_pair.key_name}. pem”
       content  = tls_private_key.key_pair. private_key_pem
  
}
 
resource “aws_security_group” “sg” {
       tags = {
       type = “terraform-test-security-group”
   }

 
resource “aws_network_interface_sg_attachment” “sg_attachment” {
          security_group_id      = aws_security_group.sg.id
          network_interface_id = aws_instance. Instance.primary_network.interface_id
}
 
 
Step 2 – Copy playbook using file terraform provisioner:
 
provisioner “file” {
    source       = “myapp\ansible playbook. yaml”
    destination = “/etc/myapp.conf”
 
connection {
        type.        = “ssh”
        user         = “root”
        password  = ”${var.root_password}”
host = “${var.host}”
 
         }
}
 
Step 3 – Install Ansible using remote terraform provisioner
 
 
provisioner  “remote-exec” {
      inline =  [
      “sudo apt-get update”,
      “sudo apt-get  install ansible”,
“sudo systemctl start ansible”,
     “sudo systemctl enable ansible”
    “echo ““,
     “ansible –version”
       ]
}
 
Step 4 – Run Ansible playbook command using remote terraform provisioner
 
provisioner “ remote-exec” {
   inline = [ “ansible all -a “df -h” -u root”]
 
connection {
type = “ssh “
user = “ubuntu”
private_key =” ${file(var.ssh_key_private)}”
  }
 
}
 
Assignment – 3
 
Write a 2 Module in Terraform. One Local Module, Second remote module.
Local Module Spec – in Ubuntu – Setup a webserver
Remote module – Setup VPC
 
 Local Module to setup Ubuntu webserver.
 
provider “aws” {
  region          = var.web_region
  access_key  = var. access_key
  secret_key   = var. secret_key
}
 
module “ubuntu-webser” {
source                    = “. /module”
web_instance_type = “t2. large”
}
 
output “public_ip_ec2” {
value. = module. public_ip_ec2
description = “public ip of ec2”
}
  
 Remote Module to setup VPC.
 
module “vpc” {
    source = “terraform-aws-modules/vpc/aws”
 
    name = “my-vpc”
    cidr    = “10.0.0.0/16”
 
 azs            = [“eu-west-1a”, “eu-west-1b”, “eu-west-1c”]
      private_subnets = [“10.0.1.0/24”, “10.0.2.0/24”, “10.0.3.0/24”]
      public_subnets = [“10.0.101.0/24”, “10.0.102.0/24”, “10.0.103.0/24”]
 
     enable_nat_gateway = true
     enable_vpn_gateway = true
 
 tags                                = {
        terraform                = “true”
        environment           = “dev”
 }
}
 
 
 
 
 

Centralized Version Control SystemIn centralized source control, there is a server and a client. The server is the master repository that contains all of the versions of the code. To work on any project, firstly user or client needs to get the code from the master repository or server. So the client communicates with the server and pulls all the code or current version of the code from the server to their local machine. In other terms we can say, you need to take an update from the master repository and then you get the local copy of the code in your system. So once you get the latest version of the code, you start making your own changes in the code and after that, you simply need to commit those changes straight forward into the master repository. Committing a change simply means merging your own code into the master repository or making a new version of the source code. So everything is centralized in this model. 
There will be just one repository and that will contain all the history or version of the code and different branches of the code. So the basic workflow involves in the centralized source control is getting the latest version of the code from a central repository that will contain other people’s code as well, making your own changes in the code, and then committing or merging those changes into the central repository. 

Basic Difference between Git distributed model and SVN server client model: 
 
Git distributed model:
·      Git software is installed on a workstation and acts as a client and a server.
·      Git is more difficult to learn, it has more concepts and commands. 
·      It does not have good UI as compared to SVN.
·      Git deals with large number of files like binary files that change quickly that why it become slow.
·      In git we create only .git directory.
·      In git we do not required any Network to perform git operation. 
·      Git is open source distributed version control system developed by Linus Torvalds in 2005.
·      It emphasis on speed and data integrity.
·      In git every user has their own copy of code on their local like their own branch.
·      Git has a Distributed Model.
·      Every developer has a local copy of the full version history of the project on their individual machine. 
·      Git changes happen locally. So, the developer doesn’t have to be connected all the time.
·      Once all the files are downloaded to the developer’s workstation, local operations are faster.

SVN server-client model:

·      SVN has a separate server and client.
·      Apache Subversion is an open source software version and revision control system under Apache license.
·      SVN has a Centralized Model.
·      In SVN we required Network for runs the SVN operation. 
·      In SVN there is central repository has working copy that also make changes and committed in central repository.
·      SVN is much easier to learn as compared to git.
·      SVN control the large number of binary files easily.
·      In SVN we create .svn directory in each folder.
·      SVN has simple and better user interface .
·      Only the files a developer is working on are kept on the local machine.
·      The developer must be online, working with the server. 
·      Users check out files and commit changes back to the server. 

Q2. Explain the use of Git Workspace – Staging – Repository area in detail with few use cases.

The workspace: Is where files that are not handled by Git or is a private development area where you can keep your work and those contributions that are shared by your team members.These files are also referred to as untracked files. Staging area is files that are going to be part of the next commit, which lets Git know what changes in the file are going to occur for the next commit. Your work is private to the workspace until you decide to deliver it to a team flow target such as a shared stream.

Git staging area: This means that if you made 100 new changes to your code, you can break these 100 changes into 10 or 20 or more commits each with their own comments and their own detailed explanation of what just happened. You would use patch staging if you and a co-worker are both working on the same file and you only want to commit a particular function that you have worked on.
 

Repositories area:

Git contains a collection of files of various different versions of a Project. These files are imported from the repository into the local server of the user for further update and modifications in the content of the file. A Version Control System is used to create these versions and store them in a specific place termed a repository. The process of copying the content from an existing Git Repository with the help of various Git Tools is termed cloning. Once the cloning process is done, the user gets the complete repository on his local machine. Git by default assumes the work to be done on the repository is as a user, once the cloning is done. Users can also create a new repository or delete an existing repository. To delete a repository, the simpler way is to just delete the folder containing the repository.

 
Q3. Write down the Types of git branch and use cases of it:
Branching means diverging from the mainline and continue to work separately without messing with the mainline. Nearly every VCS has some form of branch support. In Git, a branch is simply a reference to the commit, where the following commits will be attached. 

The two primary branches in Git flow are master branch and development branch. A branch represents an independent line of development . A branch as discussed earlier is a separate line of development as git stores branch as a reference to commits.
 

Use cases of Git branch: Git branch is used to list, create, rename and delete branches and it’s easier to logically divide up your work than have big beefy branche. 

Q4. Explain the Types of Merging and use cases of it.
 
The concept of git merging is basically to merge multiple sequences of commits, stored in multiple branches in a unified history or to be simple you can say in a single branch. There is a proper merging algorithm in git, with the help of which git performs all of these operations and presents conflicts if there are any.
What happens is when we try to merge two branches, git takes two commit pointers and starts searching for a common base commit in those two specified bit branches. When git finds the common base commit it simply creates a “merge commit” automatically and merges each queued merge commit sequence.
In our case, we have two branches one is the default branch called “main” and the other branch named “dev” and this is how our git repo looks before merging.
Here git finds the common base, creates a new merge commit, and merged them.
A git merge operation is performed by running the command “git merge <name of the branch to be merged (in our case it is dev). When we perform merging, git always merges with the current branch from where we are performing the operation(in our case it is main). By this, the branch being merged is not affected.
Types of merges:
1.     Fast-forward merge
2.     Three way merge
 
Fast forward merge: Happens when the tip of the current branch (dev in our case) is a direct ancestor of the target branch (main in our case). Here instead of actually merging the two branches git simply moves the current branch tip up to the target branch tip. Fast-forward merge is not possible if the branches have diverged.
 
3-way merge: Which uses a dedicated commit to merge two histories or you can say branches.

  Use cases: The merge command is used to integrate changes from another branch. The target of this integration (i.e., the branch that receives changes) is always the currently checked out HEAD branch.
 
In the most frequent use cases, git merge is used to combine two branches.
Here we have created two branches one is the default “main” and another is “dev”. We have also committed two changes in two branches.
Now to merge these two branches first we have to follow the below steps
·      checkout to the target branch to merge the current branch
·      then run the below command

Now we have successfully merged our two branches and as you can see we have same changes or you can say commits in our both branches.

Q5. Create a Table with Top 20 Git commands along with one line explanations like self cheatsheet.

Summary of Top 20 Git Commands in table form.Command Use
git init . = Initialises a Git repository in that directory
git add = Adds all changes to the staging area to be committed
git add file_name = Adds changes to the specified file to the staging area to be committed
git commit = Commits staged changes and allows you to write a commit message
git checkout SHA. = Checks out a past commit with the given SHA
git checkout SHA — file_name =Checks out the past version of a file from the commit with the given SHA
git checkout -b branch_name =Creates and switches to a new branch
git checkout branch_name =Switches to the specified branch
git merge branch_name =Merges the branch you are on into the specified branch
git log =Outputs a log of past commits with their commit messages
git status =Outputs status, including what branch you are on and what changes are staged
git diff =Outputs the differences between the working directory and most recent commit
git diff thing_a thing_b =Outputs the differences between two things, such as commits and branches
git clone URL =Makes a clone of the repository at the specified URL
git remote add origin URL =Links a local repository and an online repository at the specified URL
git push origin branch_nam =Pushes local changes to the specified branch of the online repository
git pull origin branch_name =Pull changes from the online repository into local repository