- [Instructor] Before we create any more resources,
let's plan the rest of the build environment.
So far, we already have a server running our Jenkins master.
We'll follow best practices
for a distributed Jenkins environment
by removing all executors from the Jenkins master.
This will prevent any build
from starting on the master server.
Not running builds on the master frees up resources
for Jenkins to do what it does best,
managing builds on other servers.
To connect our master server to build servers,
we'll need a key pair for connections via secure shell
and a security group to limit access
to only the master server,
and of course, we'll need at least one build server.
This is where the real action happens.
Any code that gets checked out
will be written to these servers
and commands will be run by local processes.
The results of the build
will get sent back to the Jenkins master
for any post-build processing like archiving or reporting.
Because our build server will be manipulating AWS resources
on our behalf, we'll need to create an IAM role
that gives the correct permissions
to the services we want to deploy to.
The role will allow our build servers to run AWS commands
and interact with AWS APIs
without having to enter credentials.
As automators, this is an enormous benefit for us
because we don't want to have to worry about storing
and retrieving credentials every time
we want the build server to do something.
Once we have all of these resources in place,
we'll be able to create Jenkins jobs
that can deploy and manage resources
like S3, EC2 and Elastic Beanstalk.
For the rest of this course,
we'll be focusing on Elastic Beanstalk.
Our goal will be to set up a pipeline
triggered by pushes to a GitHub repository
so that code changes are deployed automatically.
Essentially, we'll be building the infrastructure
for a continuous integration
and continuous delivery pipeline, also known as CI/CD.
Let's get started.