Skip to content
This repository has been archived by the owner on Jul 19, 2019. It is now read-only.

Latest commit

 

History

History
66 lines (48 loc) · 4.03 KB

Deployment-Upgrade_InPlace-OS.md

File metadata and controls

66 lines (48 loc) · 4.03 KB
Raw

Upgrading The Jenkins Service - Master Node

Purpose

This document is intended to walk the automation-user through the process of upgrading an Jenkins-hosting EC2 instance from a previous, template-based deployment.

This procedure is essentially the same as that used for doing an "in-place" upgrade of the Jenkins Service - minus changing the version of the Jenkins service that is deployed.

Caveats

While this procedure has proven to be fairly reliable, it does depend on success of the to-be-upgraded instance's backups. It is best to verify that the available sync-backups are good before initiating this procedure. Overall, this process should be vetted and run under any relevant site-local policies regarding upgrades.

Dependencies

In order to use these templates, the following things will be necessary:

  • Access to an AWS account
  • An IAM user or role with (at least) enough permissions to:
    • Modify classic Elastic LoadBalancers (ELBs)
    • Create/Modify CloudWatch Logs log-groups (Optional: only required if deploying to a region that supports the use of the CloudWatch Logs service and wishing to take advantage of same)
    • Create/Modify DNS records in Route53 (Optional: only required if deploying to a region that supports Route53 and use of Route53 DNS service is desired)
  • Access to a computer that has a modern git client
  • Access to a computer that has Python installed (and is pip-enabled)
  • Access to a computer that has a modern web browser
  • Access to a computer that has the AWS CLI installed or installable (e.g., pip install awscli)
  • Ability to configure the AWS CLI to use the previously-described IAM user or role

Assumptions/Dependencies

  • The automation user has a verified backup of the running configuration (or the ability to do so immediately prior to attempting th e upgrade)
  • The Jenkins-hosting EC2 instance was deployed using the make_jenkins_EC2-Master-instance.tmplt.json template
  • The "JenkinsRpmName" parameter-value was specified as a version-pinned value in the previous deployment
  • Automation user has sufficient privileges to execute an instance-replacing CloudFormation stack-update action

Workflow Description

While this task can, notionally, be done through both the CloudFormation web UI and the AWS CLI, only procedures for use with the we b UI have been validated.

Update Via Web UI

  1. Login to the CloudFormation web console
  2. Locate the previously-deployed stack
  3. Select the previously-deployed stack
  4. Select the "Update Stack" option from the Action button/menu
  5. Select "Use current template" from the "Select Template" page.
  6. Change the value of the "AmiId" parameter to the AMI you wish to update to
  7. Note: Other parameters may also be modified. However, doing so is out of scope for this document.
  8. Click on the "Next" button to get to the "Options" page
  9. Click on the "Next" button to get to the "Review" page
  10. Validate all values are as desired. Note that the instance should be shown for replacement in the "Preview your changes" section.
  11. Click on the "Update" button to commence the process.
  12. Track the update process
    • If the update succeeds, the previous instance will be terminated
    • If the update fails, the new instance will be terminated. If — per the caveats section — the previous instance wa stopped, it will need to be restarted for services to resume.
  13. Login to the Jenkins service and verify that previous functionality is present on the replacement node.

Update Via AWS CLI

TBD

"Under the Covers"

When the stack-update executes, a new EC2 instance is launched in parallel. The application installation/configuration scripts will attempt to find a recent sync-backup in the associated S3 bucket's Backups/sync/ folder. If it finds a good backup, it will attempt to auto-recover from that data as part of the deployment processes. Once complete, the original instance will be terminated and a new, upgraded instance should be online with all of the data of the prior instance's last sync-backup.