Awesome

terraform-aws-jenkins-ha-agents

A module for deploying Jenkins in a highly available and highly scalable manner.

Related blog post can be found on the Neiman Marcus Medium page.

Features

• Highly available architecture with agents and master in an autoscaling group
• EFS volume used for master node persistence
• Jenkins versions incremented through variable
• Complete Infrastructure as code deployment, no plugin configuration required
• Spot instance pricing for agents
• Custom user data available
• Auto update plugins

Terraform & Module Version

Terraform 0.13 - Pin module version to ~> v3.0. Submit pull-requests to master branch.

Terraform 0.12 - Pin module version to ~> v2.0. Submit pull-requests to terraform12 branch. Only bug fixes will be accepted. All new developement will be on Terraform 0.13.

Terraform 0.11 - Deprecated in this module.

Usage

To be used with a local map of tags.

Minimum Configuration

module "jenkins_ha_agents" {
  source  = "neiman-marcus/jenkins-ha-agents/aws"
  version = "x.x.x"

  admin_password  = "foo"
  bastion_sg_name = "bastion-sg"
  domain_name     = "foo.io."

  private_subnet_name = "private-subnet-*"
  public_subnet_name  = "public-subnet-*"

  r53_record = "jenkins.foo.io"
  region     = "us-west-2"

  ssl_certificate = "*.foo.io"
  ssm_parameter   = "/jenkins/foo"

  tags     = local.tags
  vpc_name = "prod-vpc"
}

Full Configuration with Custom Userdata and Plugins

main.tf

module "jenkins_ha_agents" {
  source  = "neiman-marcus/jenkins-ha-agents/aws"
  version = "x.x.x"

  admin_password    = "foo"
  agent_max         = 6
  agent_min         = 2
  agent_volume_size = 16

  ami_name          = "amzn2-ami-hvm-2.0.*-x86_64-gp2"
  ami_owner         = "amazon"
  api_ssm_parameter = "/api_key"

  auto_update_plugins_cron = "0 0 31 2 *"

  efs_mode                   = "provisioned"
  efs_provisioned_throughput = 3

  application     = "jenkins"
  bastion_sg_name = "bastion-sg"
  domain_name     = "foo.io."

  agent_lt_version  = "$Latest"
  master_lt_version = "$Latest"

  key_name          = "foo"
  scale_down_number = -1
  scale_up_number   = 1

  custom_plugins              = templatefile("init/custom_plugins.cfg",{})
  extra_agent_userdata        = data.template_file.extra_agent_userdata.rendered
  extra_agent_userdata_merge  = "list(append)+dict(recurse_array)+str()"
  extra_master_userdata       = data.template_file.extra_master_userdata.rendered
  extra_master_userdata_merge = "list(append)+dict(recurse_array)+str()"

  retention_in_days = 90

  executors                = 4
  instance_type_controller = ["t3a.2xlarge"]
  instance_type_agents     = ["t3a.xlarge", "t3.xlarge", "t2.xlarge"]
  jenkins_version          = "2.249.1"
  password_ssm_parameter   = "/admin_password"

  cidr_ingress        = ["0.0.0.0/0"]
  private_subnet_name = "private-subnet-*"
  public_subnet_name  = "public-subnet-*"

  r53_record      = "jenkins.foo.io"
  region          = "us-west-2"
  ssl_certificate = "*.foo.io"

  ssm_parameter = "/jenkins/foo"
  swarm_version = "3.23"
  tags          = local.tags
  vpc_name      = "prod-vpc"
}

data "template_file" "custom_plugins" {
  template = file("init/custom_plugins.cfg")
}

data "template_file" "extra_agent_userdata" {
  template = file("init/extra_agent_userdata.cfg")

  vars {
    foo = "bar"
  }
}

data "template_file" "extra_master_userdata" {
  template = file("init/extra_master_userdata.cfg")

  vars {
    foo = "bar"
  }
}

init/custom_plugins.cfg

---
#cloud-config

write_files:
  - path: /root/custom_plugins.txt
    content: |
      cloudbees-folder
    permissions: "000400"
    owner: root
    group: root

init/extra_agent_userdata.cfg

---
runcmd:
  - echo 'foo = ${foo}'

init/extra_master_userdata.cfg

---
runcmd:
  - echo 'foo = ${foo}'

Examples

• Full Jenkins-HA-Agents Example
• Minimum Jenkins-HA-Agents Example

Inputs

Outputs

Known Issues/Limitations

N/A

Notes

• It can take a decent amount of time for initial master bootstrap (approx 11 minutes on t2.micro).
  • This is normal, and sped up by higher instance types.
  • After the master is built and EFS is populated with Jenkins installation configuration, master boot times come down considerably.
• During initial bootstrapping the master reboots several times.
• You should not need to change the admin password in the Jenkins wizard.
  • This is done through bootstrapping.
  • If you run through the wizard and it asks you to change the admin password, wait a short time and reload the page.
  • Do not click 'Continue as admin' on the password reset page, just wait and reload.

Breaking Changes

v2.5.0

• Giving custom names to ASG's has been removed. This should only impact external resources created outside of the module.
• ASG's no longer rehydrate with launch template/configuration revisions. You will need to manaully rehydrate your ASG's with new instances.
• Spot pricing variable has been removed as the agent ASG was moved to launch template, and does not require this parameter (defaults to on-demand max price).
• Instance type variable has been changed to a list to accomodate multiple launch template overrides. If you use a non-default value, you will have to change your variable to a list.

v2.1.0

• This version of the module pulls all public and private subnets using a wildcard.
  • This allows for more than two hardcoded subnets.
  • You may have to destroy several resources and create them again, including mount targets.
  • As long as you do not delete your EFS volume, there should be no data loss.
• CIDR blocks have been consolidated to reduce redundant configuration.

How it works

The architecture, on the surface, is simple, but has a lot of things going on under the hood. Similar to a basic web-application architecture, a load balancer sits in front of the master auto scaling group, which connects directly to the agent autoscaling group.

Master Node Details

The Master node sits in an autoscaling group, using the Amazon Linux 2 AMI. The autoscaling group is set to a minimum and maximum of one instance. The autoscaling group does not scale out or in. It can be in one of two availability zones. It is fronted by an ELB which can control the autoscaling group based on a health check. If port 8080 is not functioning properly, the ELB will terminate the instance.

The name of the master autoscaling group is identical to the master launch configuration. This is intentional. If the launch configuration is updated, the master autoscaling group will be recreated with the new launch configuration.

Data are persisted through an EFS volume, with a mount target in each availability zone.

During initial launch, the master will generate an API key and publish it to SSM Parameter store.

Agent Nodes Details

Agent nodes are also set in an autoscaling group, using the Amazon Linux 2 AMI, set in the same availability zones.

Agents connect to the master node through the Jenkins SWARM plugin. The agents are smart enough to get the master's IP address using the AWS CLI and API key from the parameter store. Agents launch, configure themselves, and connect to the master. If agents cannot connect or get disconnected, the agent will self-terminate, causing the autoscaling group to create a new instance. This helps in the case that the agents launch, and the master has not yet published the API key to the parameter store. After it is published, the agents and master will sync up. If the master is terminated, the agents will automatically terminate.

Agents are spot instances, keeping cost down.

Agent Scaling Details

Agents scale based on CPU, and on the Jenkins build queue. The master node will poll itself to see how many executors are busy and send a CloudWatch metric alarm. If the number of executors available is less than half, then the autoscaling group will scale up. If executors are idle, then the agents will scale down. This is configured in the cloud-init user data.

Updating Jenkins/SWARM Version

To update Jenkins or the SWARM plugin, update the variable in the terraform.tfvars files and redeploy the stack. The master will rebuild with the new version of Jenkins, maintaining configuration on the EFS volume. The agents will redeploy with the new version of SWARM.

Auto Updating Plugins

The master has the ability to check for plugin updates, and automatically install them. By default, this feature is disabled. To enable it, set the auto_update_plugins_cron argument. Finally, it saves the list of plugins, located in /var/lib/jenkins/plugin-updates/archive for further review. You are encouraged to use something like AWS Backup to take daily backups of your EFS volume, and set the cron to a time during a maintenance window.

Diagram

FAQ

Why not use ECS or Fargate?

ECS still requires managing instances with an autoscaling group, in addition to the ECS containers and configuration. Just using autoscaling groups is less management overhead.

Fargate cannot be used with the master node as it cannot currently mount EFS volumes. It is also more costly than spot pricing for the agents.

Why not use a plugin to create agents?

The goal is to completely define the deployment with code. If a plugin is used and configured for agent deployment, defining the solution as code would be more challenging. With the SWARM plugin, and the current configuration, the infrastructure deploys instances, and the instance user data connects. The master is only used for scaling in and out based on executor load.

Possible Improvements

Below are a list of possible improvements identified. Please feel free to develop and test. These may or may not be implemented.

• Fargate agents instead of instances
• Fargate master with EFS mount
• EFS mount helper
• Add instance protection to agents actively executing jobs
• Add signaling to the master and agent bootstraping process
• IAM policy document resources instead of plain json
• Add the ability to include custom iam policy details from variable inputs / Added in v2.5.0
• Move towards launch templates instead of launch configuration / Added in v2.5.0

Authors

• Raul Dominguez - Project maintenance.

Conduct / Contributing / License

• Refer to our contribution guidelines to contribute to this project. See CONTRIBUTING.md.
• All contributions must follow our code of conduct. See CONDUCT.md.
• This project is licensed under the Apache 2.0 license. See LICENSE.

Acknowledgments

• Cloudonaut.io Template - Original cloudformation template, this project is based on.
• Special thanks to Clay Danford for the creation and development of this module.