
For this How To, I’m going to assume a few things:
- You have a Jenkins server configured in AWS
- You have the EC2 Plugin Installed (its called Amazon EC2 Plugin)
EC2 Policy For Jenkins
First thing we’re going to do is create a Policy for our Jenkins server. This Policy will allow jenkins to talk to EC2.
If you have terraform configured then great, feel free to build a Policy using that. For the purpose of this guide we’ll be doing everything step by step.
- Login to AWS Console (https://console.aws.amazon.com)
- From the Services drop down on the top bar, select IAM
- Select Policies on the left hand side and then press “Create Policy”
- On the folders tab select JSON
- Copy the policy below into the json text editor. This policy is the standard policy that the plugin developers suggest.
- On the Review Screen, Name your Policy – Make note of this you’ll need it for the next step.
- Provide a good Description. I like to use something like:
“This Policy is used for jenkins to start and stop slaves on “servername” - Then Press Create Policy
EC2 Role For Jenkins
I prefer to use Roles vs Users and API Keys for a few reasons:
- Roles only work on the instance they’re defined
- There is no API key that can be used elsewhere
- These keys automatically rotate
- Select Roles on the left hand side and press Create Role
- On the Role type screen press AWS Service, select EC2. Then, press Next: Permissions
- Find the Policy you previously created, select it and press Next: Tags
- You may skip tags if you want, by Pressing Next: Review
- On Review Screen, Name your Role – Make note of this you’ll need it for the next step.
- Provide a good description I like to use something like:
“This Role is used for jenkins to start and stop ec2 slaves on “servername” - Press Create Role
You’ve now created the Policy and Role required for Jenkins to start slaves.
Attach your EC2 Role to your Jenkins Master
- Logon to the AWS console
- From the Services drop down on the top bar, select EC2
- Select Instances from the left navigation Menu
- Find and Select your Jenkins Server
- Press Actions then from the drop down select Instance Settings –>Add / Replace IAM Role
- On the Add/Replace Role screen, find and select your role, then on the right hand side click Apply.
Done! Jenkins now has a IAM role attached to the EC2 instance that can be utilized to Create Slaves.
Create a security group for jenkins to talk to it’s slaves
- Logon to the AWS console
- From the Services drop down on the top bar, select VPC
- On the left hand side under Network and Security, select Security Groups
- From the top press Create Security Group
- In the security group window input as needed, in the picture below, we’re using the security group for Jenkins to allow all inbound traffic to the security group of our slaves.
- Press Create
- Make note of the security group name you will need it shortly.
Find the subnet you will be using
- Logon to the AWS console
- From the Services drop down on the top bar, select VPC
- On the left hand side under Virtual Private cloud, select subnets
- Find the subnet ID you want your jenkins slave to run in. Make note of this, and the region’s availability zone
In our case our subnet would be subnet-14740d7c in us-west-1c
Find the AMI ID
- Logon to the AWS console
- From the services dropdown of AWS, select EC2
- On the left hand side Under Instances select Instances
- From the top bar select Launch Instance
- On the next page, find the AMI and OS you’d like to use. For this how to we’ll be configuring Linux. I prefer ubuntu so my ami would be ami-06397100adf427136
Create a SSH Key in AWS
- Logon to the aws console
- From the services dropdown of AWS, select EC2
- On the left hand side Under Network and Security select Key Pairs
- Find and select Create Key Pair
- Name your Key Pair. Since you may have different regions, and services i’d suggest something like servername-jenkins-slave-<region>
- Then select Create
- AWS will present you a file to download, it will only allow you to download this once. You’ll need it in the next step.
Configure EC2 Plugin
- Logon to your Jenkins server
- From the left hand side select Manage Jenkins
- Now select Configure System
- Scroll to the very bottom of configure system until you find “Add new cloud”
- Press the dropdown Add a new cloud and select Amazon EC2
- Name your integration, I usually use AWS Linux Oregon (or other religions).
- Select the checkbox Use EC2 Instance Profile obtain credentials
- Select your Region
- From the key pair we generated above, open the file in your text editor and copy its contents into the EC2’S Key Pair Key box.
- Click Test Connection you should receive a success
Add AMI to EC2 Plugin
- Under the AWS configuration in Jenkins you just created find and select add AMI
- Now we’re going to fill out the ami creation with information we’ve gathered above.
- Description – This can be anything you want, it shows up on every node name in jenkins.
- AMI ID – This is the ami you want jenkins to start, as referenced above we’re using ami-06397100adf427136
- Instance Type – Use your best judgement (I prefer T3 Series currently)
- Availability Zone – this corresponds with where your subnet is: For our example its us-west-1c
- Use Spot Instance – Since these nodes are usually designed to be spun up and torn down, it makes sense to run them on the spot market.. But again use your best judgement
- Security Group Names – This is our security group name, as referenced above we’re using jenkins-slave
- FS Root – This is where your jenkins workspaces will be ran from.
- For most cases the user home directory will be fine
- For Ubuntu its /home/ubuntu/
- For Centos it’s /home/centos/
- For Windows it could be a folder you’ve made C:\jenkins
- For most cases the user home directory will be fine
- Remote User – The user you’d ssh or winRM into your slave
- This varies by OS
- For Ubuntu it’s ubuntu
- For Centos its centos
- For Windows you’d use administrator
- Windows will also require a static password, at time of writing dynamic is not supported
- This varies by OS
- AMI Type – Either unix or windows
- Labels – This will be the label you’ll use in your job to call a slave
- Usage – We usually change this to “Only Builds with jobs label expressions matching this node”
- Idle Termination time – For purpose of testing I set this to -5
- Init Script – Since there’s no source control here, i’ll usually pull my init script from a source code repository. (you’ll need to use sudo to execute)
- Number of Executors – Set this to a reasonable level, usually 2 by default
- Subnet IDs for VPC – The subnet identifier you want to start this slave in, as referenced above we’re using subnet-14740d7c
- Maximum Total uses – This lets you select how many times jenkins can use this node before it has to destroy it. By default its -1 (unlimited)
- You’re done, you can configure other options as required
- Find and select the save button
Testing our slave startup
- On the left hand side of jenkins find and select Build Executor Status
- On the drop down – Provision via Linux AWS Oregon (or your aws connection name) Select your newly configured AMI
- Jenkins should now start provisioning your new slave. It may also indicate where you have a misconfiguration
- You can also look at the executor logs itself on the slave to see where further problems exist