How to Increase Session Time in Laravel?
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Hi Dev,
This article goes in definite on the most proficient method to increment meeting break in laravel. you will figure out how to set meeting lifetime in laravel. I might want to tell you the best way to set meeting break in laravel 7. we will assist you with giving illustration of laravel increment meeting break.
You can undoubtedly increment meeting lifetime in laravel 5, laravel 6, laravel 7, laravel 8 and laravel 9 rendition.
To build your meeting life time then you can undoubtedly do it from setup record in laravel. laravel give session.php there is a ‘lifetime’ key choice for setting time in minutes. in meeting design record there is a likewise a few choice for set driver, break, expire_on_close and encode and so on.
Fundamentally, you can not set lifetime meeting everlastingly yet you can set in minutes for meeting lapse time. so I will set 1 year time for meeting lapse.
Here i will show how to increase Time from env file and configuration file. so let’s see both example as bellow:
Solution 1: Using .env File
you can simple define value in minutes in your env file as bellow:
.env
SESSION_LIFETIME=86400Solution 2: Using Config File
config/session.php
<?php
use Illuminate\Support\Str;
return [
.....
'lifetime' => env('SESSION_LIFETIME', 86400),
.....
]
I hope it can help you….
Day 7 – Git Assignment & Project
Git Lab Exercise & Assignment & Project: Part – 10
Q1. What are differences between the git distributed model and SVN server-client model?
Distributed Version Control System
Q1. What are differences between the git distributed model and SVN server-client model?
Distributed Version Control System
In distributed version control most of the mechanism or model applies the same as centralized. The only major difference you will find here is, instead of one single repository which is the server, here every single developer or client has their own server and they will have a copy of the entire history or version of the code and all of its branches in their local server or machine. Basically, every client or user can work locally and disconnected which is more convenient than centralized source control and that’s why it is called distributed.
You don’t need to rely on the central server, you can clone the entire history or copy of the code to your hard drive. So when you start working on a project, you clone the code from the master repository in your own hard drive, then you get the code from your own repository to make changes and after doing changes, you commit your changes to your local repository and at this point, your local repository will have change sets but it is still disconnected with the master repository (master repository will have different sets of changes from each and every individual developer’s repository), so to communicate with it, you issue a request to the master repository and push your local repository code to the master repository. Getting the new change from a repository is called pulling and merging your local repository’s set of changes is called pushing.
It doesn’t follow the way of communicating or merging the code straight forward to the master repository after making changes. Firstly you commit all the changes in your own server or repository and then the ‘set of changes’ will merge to the master repository.
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
Day 9 – Terraform Assignment & Project
Terraform Project – Assignment – Exercise – Lab#1: Variables
Assignment – 1
Write a terraform script using aws ec2 instance and github and apply following kind of variables
Types of Terraform variable – Number
Types of Terraform variable – String
Types of Terraform variable – List
Types of Terraform variable – Map
Types of Terraform variable – Boolean
and Declare variables in
Terraform file
Override through Command Line
Example – https://www.devopsschool.com/blog/terraform-variables-complete-reference-guide/
Terraform File: Main.tf
provider “aws “{
region = “us-east-1”
access keys = “AKIASPXG6ABZXM2HHJYG”
security_ keys =” 7Vihp703qJ8iMBqbM4QXtngD4MRMNF6vjMPSCCJ4”
}
resource “aws_instance ec2” “aws” {
ami = “ami-2757f631”
instance_ type = “t2. micro”
}
provider “github” {
token = “……… “
organization = “devopsschool-sample-projects “
}
variable “num_of_users” {
description = “The is for number of users”
type. = “number”
default = 3
}
variable “aws-region” {
description = “The AWS region”
type. = “string”
}
variable “users” {
description = “This is for list variable”
type. = “list”
default = [“benz1”,” benz2”,” benz3”]
}
variable “ami” {
description = “mapping region to ami instance”
type. = “map”
default = {
“us-east-1” = “ami-b374d5a5”
“us-west-2” = “ami-4b32be2b”
}
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”
}
}