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

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

When using autoscaling with AWS, you'll likely have to perform many tasks, both during development and after deployment, such as creating launch configurations and autoscaling groups.
Doing this repeatedly through the AWS console is time-consuming, and mistakes are more likely to occur over time.

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

Autoscaling requires you to first create a startup configuration template.
This involves registering an AMI (Application Model Interface), but once created, the startup configuration cannot be modified.
This means that if you forget to include necessary commands in the AMI, or if user data or environment settings change, you will need to recreate the startup 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

The AWS CLI installation and configuration processis detailed in Amazon Kinesis Streams, so please install it using the method appropriate for your operating system.

 

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 unsure how to use it or what options are available, you can find a list of options by typing "aws autoscaling create-launch-configuration help" (it's 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's nothing particularly noteworthy about the command above, but when configuring security groups, you need to list multiple "sg-xxxxxxx" entries separated by spaces.
If you're writing a shell script in bash, you can do it like this:

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 security groups are often registered in multiples, organizing them into an array makes management easy as you only need to expand them. Similarly,
since environments are often built using multi-az, you can list Availability Zones (AZs) as follows.

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

 

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

When launching EC2 instances with autoscaling, it's common to use user data for initial setup.
Since user data is registered when creating the launch configuration, any changes to this data require recreating the launch configuration. Considering the need to recreate the launch configuration multiple times to test whether it works as expected, it seems better to automate this 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 is specified as a local file.
If you add an absolute path after "file://", such as "/path/to/user-data.sh", it will attempt to retrieve the file from the corresponding path on the machine 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 finished creating the startup configuration, create an autoscaling group.
If you created the startup 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"

That's how it works.
The VPC settings are a bit complicated because they're separated by commas for some reason, but that's just how it is, so you'll have to memorize 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