Ref Arch: How do I update the deployed Jenkins version?
A customer asked: > How do I update the version of Jenkins that is running in our Shared account and backing our CI/CD / GW pipelines solution? --- <ins datetime="2022-07-07T20:03:35Z"> <p><a href="https://support.gruntwork.io/hc/requests/108940">Tracked in ticket #108940</a></p> </ins>
Clone your infrastructure-live repository to your machine. Find your `build_jenkins_server.sh` script: `find . -iname "*jenkins*" -not -path '*/.*'` For example, if your PrimaryRegion (as defined in your reference-architecture-form.yml file) were `us-east-1` then your path would be `shared/us-east-1/_regional/amis/build_jenkins_server.sh` Open the `build_jekins_server.sh` and search for `args` which will look something like the following: ```bash args=( \ --packer-template-path "git::$PACKER_TEMPLATE_REPO?ref=$PACKER_TEMPLATE_REPO_REF" \ --var service_catalog_ref="$SERVICE_CATALOG_REF" \ --var version_tag="$PACKER_TEMPLATE_REPO_REF" \ --var aws_region="$REGION" \ --var ami_users="$ami_account_ids" \ --var vpc_filter_key="tag:Name" \ --var vpc_filter_value="mgmt" \ --var vpc_subnet_filter_key="tag:Name" --var copy_to_regions="$pkr_copy_regions" \ --var encrypt_boot=true \ --var encrypt_kms_key_id="arn:aws:kms:us-east-1:$shared_account_id:alias/ami-encryption" \ --var region_kms_key_ids="$pkr_kms_key_ids" \ --var instance_type="t2.medium" # This is the instance type used to build the packer image, so you want it on the larger side for sufficient memory / vCPU. Consider bumping this to a larger instance. ) ``` Notice that within [[the Jenkins packer build file that we package into the service-catalog](https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/modules/mgmt/jenkins/jenkins-ubuntu.pkr.hcl)](https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/modules/mgmt/jenkins/jenkins-ubuntu.pkr.hcl), we expose a variable named `jenkins_version`: ```bash variable "jenkins_version" { description = "The version of jenkins to install." type = string default = "" } ``` Now, extend the args you’re passing in the `build_jenkins_server.sh` script to include `jenkins_version` set to your desired Jenkins version: ```bash args=( \ --packer-template-path "git::$PACKER_TEMPLATE_REPO?ref=$PACKER_TEMPLATE_REPO_REF" \ --var service_catalog_ref="$SERVICE_CATALOG_REF" \ --var version_tag="$PACKER_TEMPLATE_REPO_REF" \ --var jenkins_version="2.346.1" \ --var aws_region="$REGION" \ --var ami_users="$ami_account_ids" \ --var vpc_filter_key="tag:Name" \ --var vpc_filter_value="mgmt" \ --var vpc_subnet_filter_key="tag:Name" --var copy_to_regions="$pkr_copy_regions" \ --var encrypt_boot=true \ --var encrypt_kms_key_id="arn:aws:kms:us-east-1:$shared_account_id:alias/ami-encryption" \ --var region_kms_key_ids="$pkr_kms_key_ids" \ --var instance_type="t2.medium" # This is the instance type used to build the packer image, so you want it on the larger side for sufficient memory / vCPU. Consider bumping this to a larger instance. ) ``` Note that, if a Jenkins AMI was already built and is available in the shared account, you will either need to de-register that older AMI and recreate a new one with the same tags - or update your `version_tag` and or `service_catalog_ref` variables. Otherwise, the `build_jenkins_server.sh` script will see the target AMI as already existing, so it will abort early without building anything. Authenticate to the shared account and build the new Jenkins AMI: `aws-vault exec <your-org>-shared -- bash ./build_jenkins_server.sh` Wait until the new AMI’s status has changed from Pending to Available. At this point, you can now attempt to re-deploy the Jenkins AutoScaling group with the updated AMI. To do so, cd into the `infrastructure-live-<your-org>shared/<primary-region>/mgmt/jenkins` . Authenticate to the shared account and run terragrunt plan: `aws-vault exec <your-org>-shared -- terragrunt plan` You should see the AMI being updated. Ensure that the target AMI for the replacement is identical to the AMI you just built. This should force replacement of the Jenkins instance’s launch configuration, as Jenkins is deployed within an Auto Scaling Group. If the plan looks good, run apply: `aws-vault exec <your-org>-shared -- terragrunt apply --auto-approve` Once the new Jenkins host comes up cleanly, you should be able to log back into it with an existing login. Rolling the Jenkins version forward should not result in database changes that touch any existing accounts, so any admin accounts that were already defined should still work fine in the updated Jenkins instance.