Creating a build environment and connect the Jenkins master server to the build server

1. Plan the build environment

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.

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.

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.

2. Create an IAM role for the build server

Identity and Access Management roles, or IAM roles for short, help manage the credentials that AWS resources need when they access other AWS resources. In our case, we need to create credentials for our build server and to find the resources the build server has permission to access.

Click on Role,

Click on Create role,

Select trusted entry type is AWS service and select EC2 common use cases under Use case.

Click on Next,

Filter policy name, in our case elasticbeanstalk

Select AdministratorAccess-AWSElasticBeanstalk and click on Create policy.

Enter the role name,

Add Tag details,

Click on Create role.

3. Create a security group and key pair for the build server

We've already created an EC2 IAM role, now we need to create a security group and a key pair. This will be similar to the security group and key pair we created for the instance running the Jenkins Master, but creating these specifically for the build server improves the security of our build environment. Let's start with the security group.

Click on Security Groups,

Click on Create security group,

Enter the details,

Enter the Inbound rules, Type-ssh and Source-custom and select Jenkins-master security group.

Enter the Tag details and click on Create security group.

So when we attach this rule to the EC2 instance running our build server, the build server will only be accessible from the Jenkins Master server and only by SSH. As I mentioned before, this improves security by limiting access to this server from a very specific location. And I'll click create security group. Now we need to create the key that our Jenkins Master will use to connect to the build server.

Click on Key Pairs,

Click on Create key pair,

Enter the details, For this key, it's important to select the PEM format, even if you're running Jenkins on a Windows computer, and I'll click create key pair.

Enter the Tag details and click on Create key pair.

After the key downloads, we need to open the key. Unlike the key we used to connect to our Jenkins Master, we'll be entering the content of this key into the Jenkins interface.

To do that, I'll need to open the key in an editor. I have the private key open in my text editor and I also have a browser window open where I'm logged into the Jenkins Master. I'm going to copy the contents of the key file so I can use it later in the Jenkins console, so I will select all, and then copy it to the clipboard. Okay, now let's switch to the Jenkins console. We need to store this key in a place where Jenkins can use it.

Starting with manage Jenkins, and then manage credentials.

Click on Credentials,

Click on global,

Click on Add Credentials,

First, we need to select the kind of credential we're storing. In this case, it's an SSH username with a private key.

For the ID, I'll enter jenkins-build-server.

For the username, we'll enter ec2-user. This is the username that Jenkins will use when it connects with the key, and it's also the name of the default user for Amazon Linux.

When we create the build server, we'll be using a machine image based on Amazon Linux. So we'll enter ec2-user here to match the AMI we'll select.

For the private key, we need to select the radio button next to enter directly. This opens up a form where we'll enter the private key. And there's one more click, we have to click the add button. Now I can paste in the key. And we'll leave the passphrase and description empty, and I'll click okay to save it.

4. Create the build server

At this point, we have everything in place to spin up our build server instance. A role for accessing AWS resources, a security group for managing network access, and a key pair that Jenkins can use to connect to the server.

From the EC2 Dashboard, we can start by clicking the launch instance button.

For the AMI, let's choose the Amazon Linux two AMI. For the instance type, we'll stick with the T2 Micro.

Select Key pair – (jenkins-build-server)

Now let's configure the security group. Since we created a security group specifically for our build server, we'll use the option to select an existing security group, and then select the build server security group - (jenkins-build-server)

Click on advanced details,

On the instance details page, we can set the IAM role. Of course, we'll select the role we created specifically for the build server. This is the role that will give the instance full access to S3, Elastic Beanstalk, and other AWS resources.

And specifically we need to enter a user data script. This is the script that will install Java, the Elastic Beanstalk CLI tools, and any other dependencies. We can't log into the server to install anything, but fortunately, we can use the user data form to enter some basic installation commands.

#!/bin/bash

# install dependencies
yum -y group install "Development Tools"
yum -y install \
        bzip2-devel.x86_64 \
        java-11-amazon-corretto-headless \
        libffi-devel \
        ncurses-devel \
        openssl-devel \
        python3 \
        readline-devel.x86_64 \
        sqlite-devel.x86_64 \
        zlib-devel

# install the elastic beanstalk CLI
curl -O https://bootstrap.pypa.io/get-pip.py
/usr/bin/python3 get-pip.py
/usr/local/bin/pip3 install awsebcli

Click on Launch instances.

5. Connect the Jenkins master to the build server

Let's connect our Jenkins Master to the build server. I'm logged into the EC2 Dashboard with the build server's details displayed. In another tab, I'm logged into the Jenkins Master. We need to get the private DNS name of the build server for the connection to the Jenkins Master.

It's important that we use the private IP address to keep traffic inside the AWS network. This will reduce costs associated with network ingress and egress, and also keep the connection fast.

In Jenkins, I'll click the build executor status link. This opens a page where we can manage the master server and add build servers called nodes.

First, let's remove all of the executors from the build master. This will prevent any jobs from starting on the master. I'll click the sprocket here next to master, and on the master configuration page, all we need to do is set the number of executors to zero, and then click save. The immediate change we see is there are no longer any executors under build executor status.

Now let's add the build server. I'll click back to list and then new node. For the node name, I'm going to enter Jenkins-build-server-one. I'm adding the one here just in case we decide to add more servers down the line.

We need to select permanent agent, which is really the only option, and then click okay. On the node configuration page, we need to add a few more details. For the description, let's give details on the server, specifically the type of OS it's running. So I'll enter Amazon Linux two.

For the number of executors, I'll set it to four. Ideally, this number should match the number of CPUs on a node, but since this is our only build server at the moment, we need to set it a bit higher. This will keep jobs from getting backed up if we launch multiple jobs at the same time.

The remote root directory is one of the mandatory fields on this form. This will be the directory that Jenkins uses on the build server to create workspaces where our jobs will run, so it's pretty important that this directory is defined and exists. For the Amazon Linux instances, Jenkins will be connecting with the default account, so we can use that account's home directory for the remote route. And that is /home/ec2-user.