In this lesson we're going to discuss
how orchestration processes and concepts can be used
to do work more effectively than using simple automation.
So at this point, you're able to do some simple automation
on a small scale, using some basic scripts,
using the at service or the cron service.
But automation alone is not enough to manage the deployment
and maintenance of hundreds or thousands of systems
in large corporate infrastructures
that you may work for as a system administrator one day.
Now, orchestration is known
as the automated configuration management
and coordination of computer systems, applications
and services.
Orchestration helps IT and system administrators
to more easily manage complex tasks and workflows.
Our information technology teams have to manage a lot
of servers and applications every single day
but doing all of that manually just is not scalable at all.
The more complex an IT system becomes, the more complex
managing all the moving parts is going to be.
The need to combine multiple automated tasks
and their configurations across large groups of systems
or machines is going to increase very quickly
in large organizations.
And that's where orchestration can really help us.
So in this lesson, we're going to discuss how
orchestration does the work much more efficiently
than just using automation.
Now, when I talk about automation,
this is the process of accomplishing a configuration task
without human intervention.
This is different than orchestration though.
Automation refers to a single task.
Orchestration refers to managing a larger scale
of series of tasks.
So instead of a single task, we have lots of tasks.
For example, one system administrator might automate
the installation of the Python package
in a Linux deployment.
While another administrator might orchestrate the setup
of a combined web and database server
with all the necessary configurations
on a brand new Linux server.
Orchestration can be thought of as a series
of automation tasks to accomplish a large skilled deployment
of applications, virtual machines
or entire interrelated infrastructures.
Both terms automation and orchestration do imply
that things are happening without your direct intervention
but the way you get those results and the amount of things
that are going to happen are really different
between these two processes, including the tools you use.
Now, when you take a process
you have to first break it down into its component parts.
You need to understand what that workflow looks like.
So if I start at the green dot and I want to get
to the red dot, what things do I do to get there?
What are those, if, and then, and L statements
what are the different actions that go through?
Let's take an example.
Let's say you wanted to orchestrate adding a
new virtual machine to a load balance cluster.
Now this process might include lots of different things.
You're going to have to provision the VM.
You have to configure the VM.
You have to add it to the load balance cluster
and you need to configure that load balance cluster
weight distribution, to consider the fact
that you added this new virtual machine
as part of that cluster.
When you do all these things there might be 4, 5, 10,
15, 20 steps maybe a hundred steps,
but you can do all of this through orchestration
and then you can automate it.
So you can run those things
without having to do each of those steps yourself.
Now, when you talk about orchestration,
I want you to think about it this way.
Orchestration is the automation of automations.
Now, what does that mean?
Well each of those blocks in that flow chart
I just showed you, could be its own step.
And that step may be one action, or it could be 50 actions.
For instance, I have a flow chart and a path
that talks about when you buy a course,
everything that happens from the time you buy the course,
to the time you start taking the course.
And there's a lot of things that happen
because we have to create an account for you,
we have to reset your password,
we need to add the course to your account.
There's all these different steps.
And so each of those, isn't just one step either.
Some of those have multiple actions inside of it.
For instance, when you buy the course,
we have to send your receipt.
We have to log that inside of our purchase system,
we have to make sure we account it for the taxes
that we have to pay on that,
we have to account for the fact that we need
to create an account for that
and all those different things.
And so if we can think logically about what is the sequence,
then we can automate that sequence.
And then if we take lots of different sequences
and put 'em all together in one big automation
that is the orchestration piece.
Now, when we talk about cloud computing,
one of the biggest benefits in cloud computing,
is rapid elasticity.
When you go to my website, if there's one person
going to my website, we have one cloud server up.
If we have 10 people, we might have two cloud servers up.
If we have a hundred people,
we might have five cloud servers up.
If we have a hundred thousand people, we might have
I don't know, a thousand or 2000 servers up.
And what happens is this rapid elasticity,
it does this all on its own.
It rapidly adds new servers, adds the configurations,
configures them, copies the data
and then puts them into the cloud as well as
part of our load balance cluster.
All of that happens with automation and this all happens
because of the orchestration we've created.
Now, when you start talking about orchestration
there's really three types of orchestration.
The first one is resource orchestration.
This is to provision and allocate resources
within a cloud environment or other solution.
When you talk about workload orchestration,
this is for the management of applications
and other cloud workloads that need to be performed.
And basically looking at the components to create
the product you need.
The third one that we have is what's known
as service orchestration.
This is going to be used to deploy services
into cloud environments.
Notice the differences here.
Resources, is like an ec2 instance in Amazon.
You're going to start up a new server, new VM.
If you're dealing with workload orchestration,
this is about managing apps
and other things that are working together.
And then we talk about service orchestration.
This is working on those services themselves.
Now, when it comes to orchestration, I want you to remember,
you don't have to be locked into one vendor.
Everything you do, doesn't have to sit there on Amazon
or on Azure or on Google cloud.
You can pick 1, 2, 3, or multiple.
It really depends on you.
And if you do this, there is some platforms out there
that are known as third party orchestration platforms.
These allow you to work on your product
and your orchestration across multiple vendors
and allows you to prevent this vendor lock in.
Now, as we talk about orchestration
there is a handful of tools that you need to be aware of.
Now, for the exam, the tools I'm going to mention
in this lesson, you don't have to memorize them all.
You should just be able to associate what the tool is
and basically what it does
but nobody's asking you to actually know how to use
these tools, at least not for this exam.
So let's talk about some of these.
The first one we have is what's known as Chef.
Now, Chef is a way to automate configuration deployments
and the management of applications
and it does this using what they call cookbooks.
And this basically tells you how everything
should be configured.
There's lots of different recipes you can create
and you can basically take these different services
that are written inside of Ruby and put them together,
using Chef.
Chef has the ability to work with lots of virtual machines,
as well as physical machines, containers
and other cloud instances.
When we talk about Puppet,
Puppet is very similar to Chef.
But it requires the installation of a master server
and then client agents in the different targeted nodes
to be able to do it's orchestration.
Puppet, unlike Chef doesn't really rely on
as much programming.
So you really don't have to know Ruby,
but you do need to understand some more
traditional operations.
So Puppet is pretty popular,
especially with some of the older school folks.
The next one we have is Ansible.
Ansible, unlike Chef or Puppet, doesn't use user agents.
Instead, everything is done using what's called,
YAML, yet another markup language.
These are different configuration files or playbooks
and it allows the master to connect to the client machines
over SSH to configure them.
The next one we have is, Docker and you've probably heard
of this one before.
It's an open platform for developing, shipping, running
and deploying applications
using container based virtualization.
When we talked earlier about virtualization and containers
Docker is a good example of that container based system.
Now, another one we have is what's known as Kubernetes.
Now Kubernetes, provides an abstraction layer
for managing these containers.
So if you take Docker and you have all those containers
and you need to be able to manage them, using scripts
or other task reliably,
you can use something like Kubernetes to do that.
Another one we have is known as OpenStack.
Now, OpenStack was originally created as a joint rackspace
and NSA project, and it was actually deployed as an
IaaS or infrastructure as a service solution
to manage cloud resources.
OpenStack can orchestrate the deployment of Linux,
Apache, MySQL and PHP services known as lamp.
And then the last one we have is GitHub.
Now, GitHub is basically just a service that a lot
of developers use to share their code.
If you're programming and creating scripts,
you can actually put those on GitHub.
And if you're looking for some kind of an automation
chances are somebody's already built it.
So if you're thinking about how to orchestrate
some kind of a new cloud service, you should first check
on GitHub and see if other people
in their public repositories have made that code available.
If they have, you could take that as your starting point
and then modify it for your own use case.
Now all of these are different tools
and you don't have to be an expert in any of them
for the Linux plus exam.
But the idea here is for you to understand
when you hear these tools,
you should be thinking about orchestration.
Let's talk a little bit about agent versus agentless.
Agent-based orchestration tools require
that a software component resides on the managed device.
When you have an agentless tool, on the other hand,
it doesn't require additional software to exist
ahead of time on that managed system.
This is a big difference.
And agent systems usually have more in depth control
but you do have to preset them up,
where agentless you can take control afterwards,
without having installed tools.
Now, orchestration procedures are going to vary,
depending on which tool or solution you're going to use.
But in general, orchestration steps are going to
involve defining a desired configuration
and then delivering that configuration file
to the destination system.
The configuration definition will then be processed
and this will set up the system's configuration
to match the definition file.
For example, let's say your administrators configure
and test a Chef cookbook with all your configurations in it.
That cookbook will then be delivered to a specified
destination client system.
And then the chef client will process that cookbook
and configure that node appropriately based
on those configurations.
When you're doing orchestration,
the attributes are going to define tasks
that need to be managed by the orchestration process.
Administrators can use these attributes to identify specific
configurations that need to be set through
that orchestration process.
When you're using OpenStack, for example, it's going to rely
on attributes as you're doing all its processes.
Another thing you need to think about,
is inventory management.
Inventory management of hardware, virtual machines,
operating systems, applications and configurations
can all be managed through orchestration tools.
Different tools offer different features
for inventory management, including reporting.
Inventory management is crucial
because administrators cannot manage
what they don't know exists on the network.
And when you're doing orchestration,
the systems can be creating new systems
without you even knowing it
because we're using infrastructure as code.
Now, the benefits of configuration management
are also going to consistently use configured systems
and a more efficient build process by maintaining
a good solid configuration baseline for us.
Ensuring that all of our systems meet
a configuration baseline, will help enforce our
security requirements and our service-level agreements,
as well as making our change management much more efficient
in the long run.
So, when you think of orchestration,
think about a system that can apply the changes
and the baseline for you and build things
using infrastructure as code or infrastructure as a service.
When you think of automation, think about a single task
that is taking the hands off work from
the system administrator and doing it using a basic script.
So you can get more things done in less time.