Contents
1.
FIRST PART – DevOPs Foundatin ............................................................................... 3
1.
DevOps Foundation ................................................................................................................. 3
2.
1.1.
DevOps Basics................................................................................................................... 3
1.2.
DevOps: A Culture Problem.............................................................................................. 6
1.3.
The Building blocks of DevOPs ......................................................................................... 9
1.4.
Infrastructure Automation ............................................................................................... 9
1.5.
Continuous Delivery ....................................................................................................... 11
1.6.
Reliability Engineering .................................................................................................... 16
1.7.
Additional DevOps Resources ........................................................................................ 19
1.8.
The Future of DevOps..................................................................................................... 19
Second Part – DevOPs Foundatin DevOps Foundations: Continuous
Delivery/Continuous Integration.................................................................................... 23
3.
DevOps core concept: CI/CD.................................................................................................. 23
4.
Build your Own Pipeline ........................................................................................................ 27
3.
THIRD PART – Infrastructure as Code ............................................................... 36
5.
The Basics of Infrastructure Automation ............................................................................... 36
6.
1.1.
From code to Artifacts .................................................................................................... 36
1.2.
Unit Testing ..................................................................................................................... 38
1.3.
From Artifacts to Systems............................................................................................... 38
Infrastructure Options ........................................................................................................... 41
6.1.
Public Cloud with AWS ................................................................................................... 41
6.2.
Containers with Docker .................................................................................................. 42
7.
Serverless with Lambda ......................................................................................................... 42
8.
Provisioning Deployment and Orchestration ........................................................................ 42
Getting Started with DevOps [LinkedIn]
5 courses – 12h 29m
1. DevOps Foundation
2. DevOps Foundations: Continuous Delivery/Continuous Integration
3. DevOps Foundations: Infrastructure as Code
4. DevOps Foundations: Monitoring and Observability
5. DevOps Foundations: Your First Project
1. FIRST PART – DevOPs Foundatin
1. DevOps Foundation
1.1.
DevOps Basics
DevOps is the practice of operations and development engineers, participating together through
the entire service lifecycle, from the design and development process all the way to production
support.
Five levels of DevOps
I.
Values
II.
Principles
III.
Methods
IV.
Practices
V.
Tools
DevOPs Values: CAMS model :: CORE VALUES
C - Culture
A - Automation
M – Measurement : Mean time to recovery (MTTR), Cycle time. Costs, Revenue, Employee
Satisfaction
S – Sharing: Sharing ideas and problems
Most respected set of principles: The Three Ways
Systems Thinking: Make focus on the entire pipeline or value chain.
Amplifying feedback loops
Culture of continuous experimentation and learning.
Prevalent DevOps Methodologies
1. People over Process over Tools
It recommends identifying who's responsible for a job function first, then defining the
process that needs to happen around them, and then selecting and implementing the tool
to perform that process.
2. Continuous Delivery
Not to be confused with devops
3. Lean Management
4. Change Control
5. Infrastructure as Code
Ten practices for DevOps success
DevOps tools: The cart or the horse?
These tools can lead to amazing new capabilities but could also be a threat to those who
don't change their approach to take the new tools into account. Automating your systems
can just give you a way that crash them all at once. Instead of one, at a time, your tactics
will have to change in the face of these new tools to avoid that kind of effect, which is
why we stress the values, principles, and methods of DevOPs first, and the tools last.
1.2.
DevOps: A Culture Problem
Communication
Postmortem meetings
Run blameless postmortems.
Transparent Uptime – Opposite of blameless postmortems.
Do unto others
With chatbots like Cuba, you can even issue commands from within your chat client to the rest
of your tool-chain.
Throwing things over walls
Kaizen: Continuous Improvement
It is a popular DevOps Culture practice.
Kaizen means – change for the better or Continuous Improvement.
1.3.
The Building blocks of DevOPs
Major concepts related to DevOps :- Agile, Lean, ITIL.
Agile –
Lean – Important practice for successful company. Reduces wastes.
1.4.
Infrastructure Automation
Infrastructure as code – AWS CloudFormation, Terraform.
Configuration Management (CM) - Puppet , Chef, Ansible
Idempotent is the ability to execute the CM procedure repeatedly and end up in the same state
each time.
Immutable Deployment
JuJu.
Etcd, Zookeeper and Consul are a few common tools to perform service
discovery and state tracking across your infrastructure.
1.5.
Continuous Delivery
Continuous Integration is the practice of automatically building and unit testing the entire
application frequently, ideally on every source code check-in.
Continuous Delivery is the additional practice of deploying every change to a production likeenvironment and performing automated integration and acceptance testing
Continuous Deployment extends this to where every change goes through full enough automated
testing that it's deployed automatically to production. Large scale web properties like Facebook,
Etsy, and Wealthfront use Continuous Deployment.
One of the highly debated but important principles of Continuous Integration is the idea that
developers must work off of master or trunk. - One interesting finding of the State of DevOps
Survey is that having branches or forks with very short lifetimes, less than a day before being
merged into trunk and less than three active branches in total, all contribute to higher
performance. - Yeah. In short we're shrinking the amount of unintegrated changes that are the
software equivalent of work in progress.
Continuous Integration Practices
Best Practices
1. Builds should pass the coffee test (Less than 5 minutes)
2. Commit really small bits.
3. Don’t leave the build broken.
4. Use a trunk-based development flow. Trunk is better than branch-based development.
It takes less time.
5. Don’t allow flaky tasks. Fix them!
6. The build should return a status, a log, and an artifact.
The status should be a simple pass/fail, or a red/green. A build log is a record of all the
tests run and all the results of the run. The artifact should be uploaded and tagged with a
build number. This adds trust, assures audibility and the immutability of the artifacts.
Continuous Delivery
Five practices of continuous delivery
1. Only build artifacts once.
2. Artifacts should be immutable.
3. Staging (pre-production) should be a copy of production.
4. Stop deploying if a previous steps fail.
First if there's any failure encountered in the deployment system it's going to lock up and
it'll notify all the team in chat. Second, each stage of the deployment audits the previous
stage and checks that not only that no errors occurred but also that it's in the expected
state that it should be.
5. Deployment should be idempotent.
Role of QA
There are some fundamental changes you have to make when you’re moving to continuous
delivery.
One area that deserves extra attention is Testing.
Your CI Toolchain
Version Control – Git
Continuous Integration – Jenkins others are Bamboo, Travis CI, Circle CI
Build – Maven, Gulp, Make or Rake for Ruby
Test Unit Testing – Junit for Java
Golint or Gofmt
RuboCop for Ruby
Integration Testing – Robot, Protractor, Cucumber
Infrastructure Testing – Kitchen CI for CHEF
Gauntlet and Mitten for security testing
Artifact Repository - Artifactory, Nexus, Docker Hub, Amazon S3
Deployment – Rundeck, UrbanCode, THoughtWorks, Deployinator
1.6.
Reliability Engineering
Reliability Engineering is the third major practice area within DevOps.
In IT, this includes availability, performance, security, and all the other factors that allow your
service to actually deliver its capabilities to the users.
Mean Time to Recovery (MTTR), that's the measure of how quickly your service can recover from
a disruption and restore service.
Four Key Area of DevOps
Design for Operation: Theory
Circuit Breaker
Design for Operation: Practice
Operate for Design: Metrics and Monitoring
How to create feedback loops from the actual production runtime back to development
Six areas of monitoring that we suggest measuring.
1. Service performance and uptime
2. software component metrics
3. system metrics
4. app metrics
5. performance
6. security.
Operate for Design: Logging
Logs are great DevOPs monitoring tools.
Your SRE ToolChain
Sharing and Integration as features of the tool.
Monitoring: Nagios, Zabbix
Containers have brought their own set of monitoring tools with them.
Stuff like the open-source tools Prometheus and Sysdig
Log Management: Splunk, ELK Stack
Statuspage.io provides status pages as a service.
Orchestration: Rundeck, Saltstack, Ansible.
1.7.
Additional DevOps Resources
Conferences – DevOpsdays, Velocity
Books People and Blogs -
1.8.
The Future of DevOps
Cloud to Containers to Serverless
Serverless - It's also known as functions as a service or nano-compute, but Martin Fowler explains
to them as instead of relying on long running virtual machines, serverless applications are invoked
and provisioned as they're called and a deep provisioned afterwards.
The rugged frontier of DevOps: Security
Security is undervalued in many organizations and has different priorities than many other teams
which leads to natural friction. To make a generalization, we normally see ratios in organizations
of 100 developers to 10 operations to one security person.
Self-Learning
For example, you can sign up for a free tier Amazon web services account installed the AWS
command line tools and Docker on your PC or Mac, pull down a Docker image with Terraform
on it and another with Jenkins or some other tool on it and begin experimenting. - That's right.
You can learn and get from an online tutorial. You can fork someone else's code and just start
hacking on it. Any technical person can take these building blocks and pretty quickly create a
demo where from source control you spin up a server and put a running Jenkins server on it.
2. Second
Part
Foundations:
–
DevOPs
Continuous
Foundatin
DevOps
Delivery/Continuous
Integration
3. DevOps core concept: CI/CD
This can involve small scale deployment on a single server using mock environments created with
Docker containers or virtual machines to mimic a production environment so that you can run
those integration tests. Testing should generally end up with a deployment to a production-like
environment.
Benefits of continuous Delivery (CI/ CD Pipeline)
1. Empowering teams
2. Lowered Cycle Times.
Second benefit is that the total cycle time is decreased dramatically. This is the time from
code commit to running in production. Using older methods, this time was generally
measured in weeks or months. Now it's measured in hours or even minutes.
3. Better Security
Makes it easy to go through compliance audits.
4. Rhythm of practice
5. More time to be Productive.
The Benefit is to deliver more value. - Yeah, this goes hand-in-hand with the ability to
deliver value faster as we discussed earlier. Organizations and teams doing continuous
delivery find that they spend less time doing unplanned work or rework and more time
adding new features.
Build Pipelines in Practice (Tools and Practice)
A build pipeline is your sequence of operations and the tools that perform the operations
between your source code and your deployed system. How you compose your build pipeline and
the flow between its elements is much more critical than which exact tool you use in any
particular area.
Tool-wise
Source Code Repository: Git, Perforce, Subversion
•
•
•
•
•
•
•
•
Build System: Jenkins, Bamboo, Teamcity.
Build Orchestration Tools: Maven. Ant or Gradle
Unit Test: May be a separate unit but inside the Build System.
Packaging what you built into Artifacts: JAR file, WAR, or higher level Packaging
like RPM package or Docker image.
Artifact Repo: Nexus or Artifactory or Docker Registry.
Deployment: Use same tool for test environments and production environments.
Chef, Ansible etc
Test Environment: Integration Tests and E2E (End to End) Tests.
Production Environment: Use the same artifact used in test environment.
4. Build your Own Pipeline
Introducing the delivery pipeline
•
•
Version Control - Git with Github
Build System – With Jenkins
• Artifacts – Using Nexus for Artifact repository.
• Testing: - In four areas- Unit, Integration, UI and Security testing
Concentrate on how to test your application, from the inside, from the
outside and as a malicious user.
After application is tested, deployment is done via Chef
• Deployment: Chef
The path through a build system isn't always linear. Each stage has a feedback loop that
lets you incrementally improve each change before it gets released.
Version Control
Best Practices for version control
•
Always use version control – Even build scripts and cronjobs
•
Put it all in version control.
•
Commit Often – Always save it.
•
Use easy-to-understand commit messages.
•
Don’t commit broken code.
•
Branches – Consider using master branch approach or trunk based approach.
•
Branch by abstraction.
•
Commit hook enforce quality – Use pre commit hooks too.
•
Be careful with secrets.
Version Control in action with Git
Continuous integration systems
There are three main categories that we can look at
•
•
•
Open Source - Jenkins : Can be hosted either in cloud or on-prem.
Commercial (purchased) –
CI as a Service – Travis CI, Circle CI
Best Practices for CI system
•
•
Start with a clen environment: Each build should be a blank slate.
Build to pass the coffee test
From Code Commit to receiving results, the amount of time should be equivalent to the
time it takes for a person to get a cup of coffee and come back to their desk (5minutes).
•
•
A CI Culture
▪ Run all the tests locally.
▪ Don’t commit new code to broken builds
▪ Don’t leave the build broken
▪ Don’t remove the tests that fail
Use notifications to update your build progress - Monitoring tool DataDog
Building Artifacts
Testing and Continuous Delivery
Types of testing
1.
2.
3.
4.
Unit Testing
Integration testing
UI Testing
Security Testing
Unit Testing
Unit testing is performed at build time on a single unit of code and or artifact without the
use of external dependencies or deployment.
You unit test a module or a library using something like JUnit, XUnit, Rspec.
Integration testing
Integration testing is performed as you bring together pieces of your application, and as it
needs to use external dependencies like databases to actually do its thing. You integration
test a full application or an API or a running server.
For this you might use Abao/RAML and Serverspec.
End-to-end (E2E) testing / UI Testing
End-to-end testing, often implemented as UI testing, is when you test more of your
application in a way that the end user actually uses it.
This kind of testing might be done with things like Selenium or Protractor
Security Testing
Security testing looks for flaws in your code and the runtime to prevent compromises and
leaking of data in production.
Some common tools for this include FindBugs, Fortify, and Gauntlt.
Important Testing terminology
1.
2.
3.
4.
5.
6.
Shift Left
Test Fixture
System Under Test (SUT)
Cycle time
Lead Time
Mock
Unit Testing
Security Testing
3. THIRD PART – Infrastructure as Code
5. The Basics of Infrastructure Automation
1.1.
From code to Artifacts
Normal Code Flow Look Like
Consider what artifacts you intend to use as the deliverables in your infrastructure code
pipeline. For app code, it's usually executable binaries or JARs or similar. For
infrastructure, you usually see DEBs, RPMs, or other OS packages; Docker images, AMIs,
VM images, and stuff like that.
1.2.
Unit Testing
Formatters and Linters
Formatter: Rubocop
Linter: Foodcritic
1.3.
From Artifacts to Systems
Provisioning
Provisioning is the process of making a server ready for operation, including hardware,
OS, system services, and network connectivity.
Deployment
Deployment is the process of automatically deploying and upgrading applications on a
server. These two terms are different, mainly for historical reasons. People doing
infrastructure as code work may just refer to infrastructure creation as deployment, as
well.
Orchestration
Infrastructure and services need managing after their initial creation, of course.
Orchestration is the act of performing coordinated operations across multiple systems.
Initial provisioning is interesting, but that's done once and then the system runs for a long
time. Being able to control and upgrade a running system is critical.
Configuration management
Configuration management, or CM, is a slightly more overarching term dealing with
change control of system configuration after initial provision. But is often also applied to
maintaining and upgrading application and application dependencies.
There are also a couple important terms describing how tools approach configuration
management.
First is Convergent: CM automation that runs to converge systems on a desired state.
Systems that call the Chef or Puppet server and run against new versions of a provided
model to get themselves into compliance with that model are said to be convergent.
Idempotent
Idempotent is the ability to execute a CM procedure repeatedly and end up in the same
state. Declarative CM languages are usually idempotent. If you run a Chef recipe twice, if
the system is already in the right state, the second run won't make any changes.
Immutable
Immutable: Deployments that are not intended to be changed after deployment, but
instead are just redeployed if needed. Most Docker architectures and Netflix's baked
image, Amazon architecture are immutable. The deployed services do not use convergent
CM to change themselves. But instead, they're destroyed and recreated when you want
to affect change.
Self service
Self service: The ability for an end user to kick off one of these processes without having
to go through other people.
Push or Pull
Push versus pull indicates whether the producer or the consumer initiates an operation.
A system pulling a Chef server for changes is pull-based.
A system that pushes changes out to systems via command dispatch, like Ansible, is pushbased. It's best to make hand-offs between stages in your pipeline pull-based for control
and scalability reasons.
6. Infrastructure Options
6.1.
Public Cloud with AWS
Cloud Computing
AWS
EC2 Instance
AWS CLI
To run an instance with cli, install AWS cli on your system and run the following command.
$ ec2 run-instances --image-id ami0b33d91d --instance-type t2.micro --region us-east-1
6.2.
Containers with Docker
7. Serverless with Lambda
8. Provisioning Deployment and Orchestration
8.1.
Model-driven provisioning overview.
AWS CloudFormation
Hashicorp Terraform
Ubuntu Juju
8.2.
Provisioning with CloudFormation
Validating our template with CloudFormation
$ aws --region us-east-1 cloudformation validate-template --template-body file://./ec2.yml
Running our Template with CloudFormation
aws cloudformation create-stack --region us-east-1 --stack-name ec2wthClfn --parameters
file://./ec2-parameters.json --template-body file://./ec2.yml
8.3.
Container orchestration with Kubernetes
PODS
Deployments
Getting started in your Infrastructure
Maybe you come from a dev background, in which case you already understand the
approach, but if you have a purely operations background you might consider taking some
coding courses here from the library. It doesn't matter what language, Python can also be helpful
in the dev ops world but learning the process of development will help you understand how to
perform infrastructure automation. It's not just about using the tools it's following a
development process.