Where do I use AWS::AutoScaling::LaunchConfiguration? - amazon-web-services

Per the docs in my beanstalk folder, I have ~/myapp/.ebextensions/appname.conf:
OptionSettings:
AWS::AutoScaling::LaunchConfiguration:
InstanceType: t2.medium
I also tried it in env.yaml:
AWSConfigurationTemplateVersion: 1.1.0.0
OptionSettings:
AWS::AutoScaling::LaunchConfiguration:
InstanceType: t2.medium
But beanstalk utterly refuses to provision anything but a micro. What am I doing wrong? Where do I put this?

Turns out that eb config save --cfg AllTheStuffISetupInTheUI writes out all the stuff I setup in the UI and pretty much writes the env file for me.
To that end, all three options need to be present for this to work:
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
InstanceType: t2.medium
EC2KeyName: mysecretkeys

Related

AWS Elastic Beanstalk set root volume through .ebextensions

The AWS documentation is so large and confusing, I can't seem to get this working.
I have a docker image that I am deploying onto elasticbeanstalk t2 instance. I want to set the volume to 50 gigs.
It creates the Docker running on 64bit Amazon Linux 2/3.0.1 Platform.
Instance created with:
eb create --single --tier webserver --instance_type t2.nano
I have tried a few solutions suggested and none of them seem to work when i redeploy or create the instance.
Attempt 1:
Inside .ebextensions/options.config
option_settings:
aws:autoscaling:launchconfiguration:
RootVolumeType: gp2
RootVolumeSize: "50"
Attempt 2:
Resources:
AWSEBAutoScalingLaunchConfiguration:
Type: AWS::AutoScaling::LaunchConfiguration
Properties:
BlockDeviceMappings:
- DeviceName: /dev/xvda
Ebs:
VolumeType:
'gp2'
VolumeSize:
'50'
followed by:
eb deploy
Neither of these change the size of the volume, it's staying put at default.
What am I missing?
I figured out my problem, my .gitignore was setup to ignore the config files.
Both seem to be valid options, not sure which is better.

Cloud9 and CloudFormation - access EC2 instance

I'm creating a cloud9 instance in cloudformation as follows:
Resources:
DevEnv:
Type: 'AWS::Cloud9::EnvironmentEC2'
Properties:
SubnetId: !Ref PublicSubnet
Name: MyEnvironment
InstanceType: !Ref Cloud9InstanceType
Subsequently, I want to run a bash script on that EC2 instance (within the cloudformation script) to set it up properly. How do I do that?
Unfortunately you can't. AWS::Cloud9::EnvironmentEC2 doesn't expose UserData or something like that and you cannot run SSM Documents against Cloud9 instances.
The closest you can get is using Repositories to clone a AWS CodeCommit into the instance, and that repository has a script that you run manually first time you connect...

AWS CloudFormation: update-stack fails if VolumeAttachment specified

we're encountering a strange issue with AWS CloudFormation.
We're using CloudFormation in order to automate the deployment of some our machines; our CloudFormation yml describes the deployment, which contains a persistent EBS volume which was created outside the stack, and we don't want to remove or recreate along such stack (it contains a lot of the state of our application).
The relevant CloudFormation yml snippet is:
DataVolumeAttachment01:
Type: AWS::EC2::VolumeAttachment
Properties:
Device: "/dev/xvdm"
InstanceId: !Ref EC2Instance01
VolumeId: !Ref DataVolumeId
EC2Instance01:
Type: "AWS::EC2::Instance"
Properties:
ImageId: "ami-6f587e1c"
KeyName: !Ref "KeyName"
InstanceType: !Ref "InstanceType"
BlockDeviceMappings:
# Root device
- DeviceName: "/dev/sda1"
Ebs:
VolumeType: "gp2"
DeleteOnTermination: "true"
VolumeSize: 20
So, the root device is "transient" (every time the stack is updated, such volume is deleted and gets reprovisioned with userdata), while /dev/xvdm should contain our persistent data; such device gets mounted at the end of the userdata, and added to fstab.
Following AWS own documentation, I created a script that unmounts such volume from inside the VM, and I even tried deattaching such volume from the EC2 Instance, something like:
${SSH_CMD} "cd /home/application && application stop && sudo umount /data && echo data volume unmounted"
echo "detaching data volume"
VOLID=$(aws ec2 describe-volumes --filters Name=tag-key,Values="Name" Name=tag-value,Values=persistent-volume --query 'Volumes[*].{ID:VolumeId}' --output text)
aws ec2 detach-volume --volume-id "${VOLID}"
I have verified the umount and the detach succeed.
The creation of a new stack with my template and parameters succeeds.
And yet, when I launch
aws cloudformation update-stack --capabilities CAPABILITY_IAM --stack-name $STACK_NAME --template-body file://single_ec2_instance.yml --parameters file://$AWS_PARAMETERS_FILE
The update fails, with this error:
Update to resource type AWS::EC2::VolumeAttachment is not supported.
Even though I'm not changing anything within such resource.
What's up? How can I solve or work around?
It seems that the thing was a non-issue.
Either CloudFormation is influenced by exhausted t2 cpu credits (which we had exhausted, we were trying to change the instance type for that exact reason in order to use m3 or m4) or we got a bad day for EC2/CloudFormation in Ireland. Today, with the same exact setup, every update succeeded.
I just had this problem and found the solution was to Terminate my stack which creates EC2 instances and then redploy.

How to I set the Elastic Beanstalk solution stack via a config file?

I would like to change my solution stack name to
64bit Amazon Linux 2016.03 v2.1.0 running Ruby 2.2 (Puma)
...and I would like to do this WITHOUT using the management console or the command line, but by placing a config file in my repository.
The reason for this is that I would like everything about my environment to be defined in code, rather than by using the CLI or the online management console.
I have tried placing the following in ./ebextensions/autoscaling_group.config:
option_settings:
aws:autoscaling:launchconfiguration:
SolutionStack: "64bit Amazon Linux 2016.03 v2.1.0 running Ruby 2.2 (Puma)"
InstanceType: t2.micro
IamInstanceProfile: "aws-elasticbeanstalk-ec2-role"
EC2KeyName: "eb-services"
....but nothing happens and my solution stack name doesn't change.
Does anyone happen to know an example of a configuration file I can use to change the solution stack when I deploy?
Thanks,
Louise
It looks like your .ebextension file is incorrectly formatted. Try the format below:
option_settings:
- namespace: 'aws:autoscaling:launchconfiguration'
option_name: InstanceType
value: 't2.micro'
- namespace: 'aws:autoscaling:launchconfiguration'
option_name: SolutionStack
value: '64bit Amazon Linux 2016.03 v2.1.0 running Ruby 2.2 (Puma)'
- namespace: 'aws:autoscaling:launchconfiguration'
option_name: IamInstanceProfile
value: 'aws-elasticbeanstalk-ec2-role'
- namespace: 'aws:autoscaling:launchconfiguration'
option_name: EC2KeyName
value: 'eb-services'

How to set the instance type with Elastic Beanstalk?

How can I change the instance type of an existing Elastic Beanstalk application?
Currently I am changing it in the web interface:
I tried changing it with the command line tool:
eb setenv InstanceType=t2.medium
It didn't throw an error, but also didn't change the instance type.
The setenv command is for changing Environment Variables. Hence the command you tried is bash equivalent of:
export InstanceType=t2.medium
And doesnt really do anything for your beanstalk environment.
You can create an environment using the -i option during create
eb create -i t2.micro
Or, you can use eb config to edit a currently running environment. This will open up a text editor. Look for the section that looks like:
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
EC2KeyName: aws
InstanceType: t1.micro
And edit the t1.micro to t2.micro. (save and quit)
But just to make your life easier, you can save the below as .elasticbeanstalk/saved_configs/default.cfg.yml and the CLI will use all these settings on all future creates.
AWSConfigurationTemplateVersion: 1.1.0.0
OptionSettings:
aws:elb:loadbalancer:
CrossZone: true
aws:elasticbeanstalk:command:
BatchSize: '30'
BatchSizeType: Percentage
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
EC2KeyName: aws
InstanceType: t2.micro
aws:elb:policies:
ConnectionDrainingEnabled: true
aws:autoscaling:updatepolicy:rollingupdate:
RollingUpdateType: Health
RollingUpdateEnabled: true
aws:elb:healthcheck:
Interval: '30'
More scriptable way:
aws elasticbeanstalk update-environment --environment-name "your-env-name" --option-settings "Namespace=aws:autoscaling:launchconfiguration,OptionName=InstanceType,Value=t2.micro"
The accepted solution didn't work for me in 2020.
As of today (26th, February 2020), in my .ebextensions/02_python.config I had to add the following under option_settings:
option_settings:
# ...
aws:ec2:instances:
InstanceTypes: 'm5.large'
Reference: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.as.html#environments-cfg-autoscaling-namespace.instances