[AWS] Quickly create auto-scaling using AWS CLI!

Hello,
I'm Mandai, the Wild Team member of the development team.

When using autoscaling with AWS, you will likely need to create launch settings, autoscaling groups, and other tasks during development and after operations begin.
Repeating these steps from the AWS console takes time, and doing them repeatedly can lead to oversights.

AWS has a command line tool called AWS CLI, so once you create it, you can create it quickly, safely, and reliably

There's so much content like this out there that it's hard to tell how many times it's been done before, but that's that. This is this. So, let's get started!

 

Autoscale startup settings and autoscale groups

To autoscale, you must first create a launch configuration that will serve as a template.
At this point, you will need to register the AMI, but once you have created the launch configuration, it cannot be changed.
In other words, if you forget to include a required command in the AMI, or if there are changes to user data or environment settings, you will need to recreate the launch configuration.

If the startup settings change, the autoscaling group will also need to be recreated from the new startup settings, so it would be best to do this all at once

Commands beginning with aws are installed when you launch an instance from the AMI provided by Amazon Linux, but you will need to install them on other AMIs or in your local environment

Installing and Configuring AWS CLI - Amazon Kinesis Streams , so install it using the appropriate method for your OS.

 

The "aws autoscaling create-launch-configuration" command creates an autoscaling launch configuration

To create an autoscaling launch configuration, use the "aws autoscaling create-launch-configuration" command.
If you're not sure how to use it or what options are available, you can see a list of options by running "aws autoscaling create-launch-configuration help" (in English).

Some options are required, so the basic format is as follows:

aws autoscaling create-launch-configuration \ --launch-configuration-name [Name of the launch configuration] \ --image-id [AMI ID of the AMI to use] \ --security-groups [List of security groups to apply] \ --instance-type [Type of EC2 instance to launch]

There is nothing to be particularly careful about with the above command, but when setting up security groups, you need to list multiple "sg-xxxxxxx"s separated by spaces.
If you are creating a shell script in bash, you can do it as follows.

sg=( "sg-xxxxxxx1" "sg-xxxxxxx2" "sg-xxxxxxx3" ) aws autoscaling create-launch-configuration \ --launch-configuration-name hogehoge \ --image-id ami-xxxxxxxx \ --security-groups ${sg[@]} \ --instance-type t2.micro

Since multiple security groups are often registered, if you organize them into an array, you can easily manage them by simply deploying them.
Since environments are often built in multi-az, it is a good idea to list the AZs in the same way, as shown below.

az=( "ap-northeast-1c" "ap-northeast-1a" )

 

"--user-data" option to specify user data in launch configuration

When launching an EC2 instance with auto-scaling, it is common to use user data for initial configuration.
User data is registered when creating the launch configuration, so if there are any changes to this, the launch configuration will need to be recreated. Considering the number of times you'll need to try to make sure it works as expected, it may be better to automate the process.

When registering user data in a launch configuration from the AWS CLI, in addition to the basic format above, you must specify a file using the "--user-data" option

aws autoscaling create-launch-configuration \ --launch-configuration-name [Name of the launch configuration] \ --image-id [AMI ID of the AMI to use] \ --security-groups [List of security groups to apply] \ --instance-type [Type of EC2 instance to launch] \ --user-data "file:///path/to/user-data.sh"

User data can be specified as a local file.
If you add an absolute path after "file://" such as "/path/to/user-data.sh", the AWS CLI will attempt to retrieve the file from the corresponding path on the machine where you are running the AWS CLI.

If you specify a path without a slash (two slashes), such as "file://user-data.sh", it will attempt to retrieve it from the current directory

As you can see from the help, there is an option to register using base64 in the AWS console, but from the CLI you can simply specify the file path

 

Create an autoscaling group with the "aws autoscaling create-auto-scaling-group" command

Once you have created the launch configuration, create an autoscaling group.
If you create the launch configuration as follows:

aws autoscaling create-launch-configuration \ --launch-configuration-name my-test-lc \ --image-id ami-123123 \ --security-groups sg-xyzxyz \ --instance-type t2.large

The command to create an autoscale group is as follows:

aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-test-asg \ --launch-configuration-name my-test-lc \ --min-size 2 \ --max-size 4 \ --desired-capacity 2 \ --target-group-arns "arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxxxx:targetgroup/hogehoge-group/1234567890abcdef" --availability-zones "ap-northeast-1c" "ap-northeast-1a" \ --vpc-zone-identifier "subnet-aaaaaaaa,subnet-bbbbbbbb"

The above command,

• The name of the autoscale group is "my-test-asg"
• The launch setting name used in the autoscale group is "my-test-lc"
• The minimum size is 2 units
• Maximum size is 4 units
• Desired number of instances: 2
• The target group ARN is "arn:aws:elasticloadbalancing:..."
• The availability zones used are "ap-northeast-1c" and "ap-northeast-1a"
• VPC subnets are "subnet-aaaaaaaa" and "subnet-bbbbbbbb"

The VPC settings are somehow confusingly separated by commas, but that's just how it is, so you just have to remember it .

Also, since we have selected two availability zones this time, the initial two machines should be housed in different availability zones

 

Try setting it up

Using the AWS console, you have to click around to select various items, and if you forget to check something it might not work properly, which can be a bit of a hassle, but once you set it up, you should be able to create basically the same thing, so you can recreate the AMI to your heart's content and verify user data

To be honest, I think if you don't use it, you can just think of it as a waste of time

It is possible to automate this type of processing by linking with SQS, but if you do something too elaborate you may lose sight of your purpose, so be careful

That's all