[AWS] Quickly create autoscale using AWS CLI!

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

When using autoscaling on AWS, there are many things you need to do, such as creating startup settings and autoscaling groups, both during development and after operations begin.
It takes time to do it every time from the AWS console, and if you do it many times, you may end up missing something.

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

There is so much content of this kind that I don't even know what number it is, but that's about it. This is this. So, let's go right away!

 

Autoscale startup settings and autoscale groups

For autoscaling, you first need to create a startup configuration that becomes a template.
At this time, you need to register the AMI, but once you create the startup settings, you cannot change them.
In other words, if you forget to include a necessary command in the AMI, change user data, or change the environment settings, you will need to recreate the launch configuration.

If the startup settings change, the autoscale group will also have to be recreated from the new startup settings, so I would like to do this all at once.

Commands starting with aws are installed when an instance is launched from an AMI in Amazon Linux, which is provided by Amazon, but they must be installed in other AMIs or in the local environment.

Installing and configuring AWS CLI - Amazon Kinesis Streams has detailed information, so install it using the installation method appropriate for each OS.

 

"aws autoscaling create-launch-configuration" command to create an autoscaling launch configuration

To create an autoscaling launch configuration, use the "aws autoscaling create-launch-configuration" command.
If you don't know how to use it or what options are available, you can check the list of options at "aws autoscaling create-launch-configuration help" (in English).

Some options are required, so the basic form is as follows.

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

There is nothing special to note about the above command, but when configuring the security group, you need to list multiple "sg-xxxxxxx" separated by spaces.
When creating a shell script using bash, you can do the following:

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

Multiple security groups are often registered, so if you arrange them in an array, you can easily manage them by simply expanding them.
Since I often build environments with multi-az, I think it would be a good idea to list the AZs as well, as shown below.

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

 

"--user-data" option to specify user data in startup settings

When launching an EC2 instance with autoscaling, there are many cases where initial settings are performed using user data.
User data is registered when creating the startup settings, so if there are any changes, the startup settings will have to be recreated, so consider re-creating the startup settings as many times as you need to try to see if it works as expected. , I think it would be better to automate it.

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

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

Specify a local file for user data.
If you add an absolute path after "file://" like "/path/to/user-data.sh", AWS CLI will attempt to retrieve the file from the corresponding path on the machine running the CLI.

If you specify the path without slashes (two slashes) like "file://user-data.sh", it will try to retrieve it from the current directory.

As you can see by reading the help, there is an option to register in base64 from the AWS console, but from the cli you can just specify the file path.

 

"aws autoscaling create-auto-scaling-group" command to create an autoscaling group

After creating the launch configuration, create an autoscale group.
Suppose you create a 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"

With the above command,

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

That's what it means.
For some reason, the VPC settings are complicated by using comma-separated values, but this is how it is, so you have no choice but to memorize it.

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

 

Try setting it

If you use the AWS console, it can be annoying to select various items and forget to check them so it doesn't work properly, but once you set it up, you should be able to do basically the same thing, so you can recreate the AMI to your heart's content. You can also verify user data.

Honestly, I think it's okay to think of it as a waste of time if you don't use it.

It is possible to automate this process by linking with SQS, etc., but if you do something too elaborate, you may lose sight of the purpose, so be careful.

That's it.