Support for version upgrade migration of Amazon Linux, which is no longer supported (using Terraform)

Purpose

It will be soon, but by the end of 2020, Amazon Linux will expire and move to maintenance support. https://aws.amazon.com/jp/blogs/news/update-on-amazon-linux-ami-end-of-life/

Maintenance support After December 31, 2020, the Amazon Linux AMI will have a new maintenance support period (which will continue until June 30, 2023). During this new maintenance support period, the Amazon Linux AMI will only offer critical and critical security updates as a reduced package set. However, we do not guarantee support for new EC2 platform capacity or new AWS features.

This article summarizes the steps and precautions to take when migrating from Amazon Linux to Amazon Linux 2.

environment

This example is the following version upgrade of EC2 running on Amazon Linux.

Migration

Migrating to Amazon Linux2 does not support ** in-place upgrade (a method of directly upgrading a running system) **, so ** replace upgrade (prepare an upgraded system separately from the running system) Switching method) ** must be done.

Therefore, follow the procedure below to migrate.

  1. Create a new instance using the Amazon Linux 2 AMI separately from the current instance.
  2. Temporarily move two units in parallel and move necessary data such as public key from the current instance to the new instance.
  3. Switch IP.
  4. Delete the current instance and run only the new instance.

Since you need a data copy, create a new instance in the same VPC, subnet, and AZ as you currently have.

AL2_1.png

Prior confirmation

** Since the packages that can be installed are different between Amazon Linux and Amazon Linux 2, it is necessary to confirm in advance whether migration is possible. ** ** First, on the current Amazon Linux, run the Pre-Upgrade Assistant to check the impact of migrating to Amazon Linux 2 and check the impact.

#Install Pre-Upgrade Assistant
sudo yum install -y preupgrade-assistant preupgrade-assistant-al1toal2
#Assistant run
sudo preupg

The detailed execution result is output as the following HTML file, so check the contents. image.png The check results and scores of the 6 rules are displayed. Regarding the rule check, there is a result that one case inspection is required for Python, but since there is no particular problem, we decided that it is possible to migrate.

In addition, check the official documentation for detailed differences.

Create a new instance

Since terraform manages AWS resources, copy the module ec2 of the current instance, change only name and AMI, and create ec2_new as a module for the new instance. Create the ssm_parameter data for the AMI in backend.tf to get the latest version of Amazon Linux 2.

backend.tf


data "aws_ssm_parameter" "this" {
  name = "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"
}

main.tf


module "ec2_new" {
  source = "../../../../../../modules/external/github/terraform-aws-modules/terraform-aws-ec2-instance"

  name          = "ec2_new_name"
  ami           = data.aws_ssm_parameter.this.value
  instance_type = "t3.nano"
  key_name      = var.ec2_key_name
  monitoring    = true

  vpc_security_group_ids = [
    data.terraform_remote_state.security_group.outputs.sg_internal_id,
    module.sg.this_security_group_id,
  ]

  subnet_id                   = element(data.terraform_remote_state.vpc.outputs.public_subnets, 0)
  disable_api_termination     = true
  associate_public_ip_address = true
  user_data                   = data.template_cloudinit_config.config.rendered
  iam_instance_profile        = "${title(var.app_name)}ec2_new_name"

After terraform apply, make sure the new instance is created correctly. image.png

Data copy

Check the Private IP assigned to the new instance and copy the following data from the current instance.

*/etc/sudoers: Manage sudo-enabled users and possible commands */etc/passwd: Manage users and passwords */etc/shadow: Manage encrypted passwords for each user */etc/group: Manage permission group */etc/gshadow: Manage encrypted passwords for permission groups */home: Local directory containing the public key for each user

Precautions when copying data

When copying data, it is necessary to ** migrate to directories owned by root or other users that the working user does not have permission to **. Even if you simply specify/home as the copy source with scp, a permission error will occur and copying will not be possible. Therefore, I took the method of tarning the remote destination/home with tar and copying it locally at the time of ssh as follows.

#When executing on the new instance side
ssh user@Current instance"tar zxvf -C /home -" < /tmp
cp -a /tmp/home/user /home

After copying the/home data, you will be able to ssh to the new instance by specifying the Grobal IP dynamically assigned by AWS. At this time, ** check for permission differences and missing files **. Each user will use the existing local private key and authenticate and ssh using the public key copied from the current instance to the new instance.

EIP switching

Replace the existing EIP with the new instance. Change the module specified by resorce of EIP from ec2 to ec2_new and switch.

main.tf


#After change
resource "aws_eip" "this" {
  vpc      = true
  instance = element(module.ec2_new.id, 0)
}

Confirm that the assigned instance of EIP is switched by terraform plan and apply.

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place
Terraform will perform the following actions:
  # aws_eip.this will be updated in-place
  ~ resource "aws_eip" "this" {
        association_id    = "eipassoc-0e291430b051514f9"
        domain            = "vpc"
        id                = "eipalloc-060bc8d30f11a933f"
      ~ instance          = "i-039fe23cd242331a7" -> "i-05c1fa53ee28cd971"
        network_interface = "eni-03180ae1d6eaeeeb9"
        private_dns       = "ip-xx-xx-xx-xx.ap-northeast-1.compute.internal"
        private_ip        = "xx.xx.xx.xx"
        public_dns        = "ec2-yy-yy-yy-yy.ap-northeast-1.compute.amazonaws.com"
        public_ip         = "zz.zz.zz.zz"
        public_ipv4_pool  = "amazon"
        tags              = {
            "Name" = "ec2"
        }
        vpc               = true
        timeouts {}
    }
Plan: 0 to add, 1 to change, 0 to destroy.

Verification

When the EIP switching is completed and you try ssh again, the following warning message will be displayed.


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:.
Please contact your system administrator.
Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/username/.ssh/known_hosts:6
ECDSA host key for xx.xx.xx.xx has changed and you have requested strict checking.
Host key verification failed.

Since it is a warning due to the change of EIP, you can ssh by deleting the line of the target instance of .ssh/known_hosts once.

Delete current instance

Delete the module ec2 that you copied from when you created the new instance. Make sure that terraform plan deletes only the current instance.

After deleting the current instance, change the module name given for the new instance from ec2_new to ec2 and the migration is complete.

reference

Recommended Posts

Support for version upgrade migration of Amazon Linux, which is no longer supported (using Terraform)
[Is it explosive !?] Setup for using the GPU version of Tensorflow on OS X