Configuring a new application with a t2.micro environmnet

[Juan Carlos González González]

Hi Aldrin,

Everything is working fine now with 1.3.3 release (I've just seen the 1.3.4 release is out).

I'd like to test with t2 instances. Currently we have the default vpc and I can create a new application from console on a t2.micro instance, providing the default vpc id and the subnet id. I'd like to accomplish the same with beanstalker plugin and I've included the following in my configuration:

<beanstalk.vpcId>my vpc id</beanstalk.vpcId>

<beanstalk.vpcSubnets>my subnet id</beanstalk.vpcSubnets>

so the profile now looks like this:

    <profile>

  <id>aws-beta-deploy</id>

  <properties>

  <platform.prefix>beta</platform.prefix>

       <maven.install.skip>true</maven.install.skip>

        <maven.deploy.skip>true</maven.deploy.skip>        

  <beanstalker.serverId>beta.aws.amazon.com</beanstalker.serverId>  

  <beanstalker.region>us-east-1</beanstalker.region>

  <beanstalk.environmentType>SingleInstance</beanstalk.environmentType>  

  <beanstalk.solutionStack>64bit Amazon Linux running Tomcat 7</beanstalk.solutionStack>

  <beanstalk.instanceType>t2.micro</beanstalk.instanceType>

  <beanstalk.vpcId>my vpc id</beanstalk.vpcId>

  <beanstalk.vpcSubnets>mysubnet id/beanstalk.vpcSubnets>

  <beanstalk.keyName>${platform-prefix}atlas</beanstalk.keyName>

<beanstalk.env.aws.elasticbeanstalk.control.LaunchType>Migration</beanstalk.env.aws.elasticbeanstalk.control.LaunchType>

<beanstalk.env.aws.autoscaling.updatepolicy.rollingupdate.RollingUpdateEnabled>false</beanstalk.env.aws.autoscaling.updatepolicy.rollingupdate.RollingUpdateEnabled>

<beanstalk.iamInstanceProfile>ec2 role</beanstalk.iamInstanceProfile>

<beanstalk.env.aws.autoscaling.asg.MaxSize>1</beanstalk.env.aws.autoscaling.asg.MaxSize>

<beanstalk.notificationTopicARN>arn:aws:sns:us-east-1:XXXXXXXXX:ElasticBeanstalkNotifications-Environment-${platform.prefix}-${api.name}</beanstalk.notificationTopicARN>

<beanstalk.notificationEndpoint>mys...@domain.com</beanstalk.notificationEndpoint>

<beanstalk.notificationProtocol>email</beanstalk.notificationProtocol>

</properties>

  <build>

  <defaultGoal>deploy</defaultGoal>

        <plugins>

           <plugin>

               <groupId>br.com.ingenieux</groupId>

               <artifactId>beanstalk-maven-plugin</artifactId>

               <executions>

                 <execution>

                   <id>default-deploy</id>

                   <phase>deploy</phase>

                   <goals>

                     <goal>upload-source-bundle</goal>

                     <goal>create-application-version</goal>

                     <goal>replace-environment</goal>

                   </goals>

                 </execution>

               </executions>

           </plugin>

       </plugins>

  </build>

</profile>

The application is deployed on a new environment, but the instance type remains with t1.micro.

Please, could you take a look and tell me if there is anything missing or misconfigured?.

KR,

Juan Carlos González

[Aldrin Leal]

Beats me. 

Particularly, I was never able to properly fire up a t2.micro in AWS Elastic Beanstalk - even from the console. I believe it is worthy to open an AWS Support Case and keep me on copy just in case - this is one of the edge cases where I haven't stopped to look in more detail, but sure t2 micros are interesting.

--
-- Aldrin Leal, <ald...@leal.eng.br>

Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/

--
You received this message because you are subscribed to the Google Groups "beanstalker-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beanstalker-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aldrin Leal]

Anyway, I've fired a t2.medium using the config below:

    <properties>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

        <app.mainClass>org.mycompany.myapi.Main</app.mainClass>

        <beanstalker.region>us-east-1</beanstalker.region>

        <environmentName>${project.artifactId}-dev</environmentName>

        <beanstalk.applicationName>${project.artifactId}</beanstalk.applicationName>

        <beanstalk.environmentName>${environmentName}</beanstalk.environmentName>

        <beanstalk.cnamePrefix>${environmentName}</beanstalk.cnamePrefix>

        <beanstalk.environmentRef>${environmentName}.elasticbeanstalk.com</beanstalk.environmentRef>

        <beanstalk.useStagingDirectory>true</beanstalk.useStagingDirectory>

        <beanstalk.solutionStack>64bit Amazon Linux 2014.* running Docker 1.*</beanstalk.solutionStack>

        <beanstalk.applicationHealthCheckURL>/health/check</beanstalk.applicationHealthCheckURL>

        <beanstalk.environmentType>SingleInstance</beanstalk.environmentType>

        <beanstalk.instanceType>t2.medium</beanstalk.instanceType>

        <beanstalk.vpcId>vpc-2121604f</beanstalk.vpcId>

        <beanstalk.vpcSubnets>subnet-992465f7</beanstalk.vpcSubnets>

        <beanstalk.keyName>ald...@leal.eng.br</beanstalk.keyName>

        <beanstalk.iamInstanceProfile>aws-elasticbeanstalk-ec2-role</beanstalk.iamInstanceProfile>

        <!--

        <beanstalk.availabilityZones>us-east-1d</beanstalk.availabilityZones>

        <beanstalk.blockDeviceMappings>/dev/sdb=ephemeral0</beanstalk.blockDeviceMappings>

        -->

    </properties>

But then I looked into the original question, which reminded me something: Those properties are only used for create/update/put environment, not replace-environment (by defaul).

replace-environment is a bit tricky. if copyOptionSettings is set to true, *AND* there is no option settings, it copies. However, in order to set those option settings, it uses a legacy format (not used anymore), thus ignoring any variables.

Either way, replace with a different configuration completely defeats the purpose, so I'll add to my backlog and review if this misleading code could be removed somehow (it smells bad - a lot).

Current case? So, you need to first set your environment to use a t2.micro (thus with some downtime) from CLI or Console, then replace-environment will pick it up the new instance type. In my case, I used update-environment to apply the change and it worked like a charm.

Am I missing something?

--
-- Aldrin Leal, <ald...@leal.eng.br>

Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/

[Juan Carlos González González]

Hi Aldrin.

Thank you very much for the explanation and support. I'll test the proposed way.

KR,

Juan Carlos González

<beanstalk.notificationEndpoint>myself@domain.com</beanstalk.notificationEndpoint>