Use of default VPC with Rubber 3.2.1

Skip to first unread message

Feb 13, 2016, 7:11:59 PM2/13/16
to rubber
How do I use the default VPCs and default gateway in AWS with Rubber 3.2.1. What should my configurations be for:
  • VPC Alias
  • Subnet CIDR
  • Gateway

Kyle Schutt

Feb 15, 2016, 3:05:33 PM2/15/16
to rubber

We are also looking for some documentation on how to properly define VPC usage. I know this is a very new feature, but an example .yml file would be very helpful.

Kyle Schutt

Feb 24, 2016, 10:07:29 AM2/24/16
to rubber


Here is the only way we got it to work properly. We could only got it to work on a per-host basis because per-role isn’t available yet (that is what it seems like after digging through the code). The example rubber.yml doesn’t list it under the correct heading.

    availability_zone: us-east-1a
      gateway: public
    vpc_alias: "#{app_name}_#{Rubber.env == 'production' ? 'production' : 'development'}"


Feb 25, 2016, 12:04:44 AM2/25/16
to rubber
Thx Kyle. I will give it a shot.

Dave Benvenuti

Feb 28, 2016, 5:58:36 PM2/28/16
Hey Brian and Kyle,

Sorry I didn't respond to this sooner.  Kyle is correct - there is currently an outstanding issue that requires you define VPC configuration on a per-host basis.  There is an open pull request to address this that hasn't been merged yet.

I plan to finally update the Rubber wiki with VPC configuration and setup details this week.  When implementing VPC support, I very heavily leaned on this as a guide:

vpc_alias is just a human-readable unique identifier for your VPC.  Think of this as analogous to an instance alias.  If no VPC with a RubberVpcAlias AWS tag of this name exists, Rubber will automatically create it for you.

vpc_cidr is the IP Range that all of your subnets will fall under.

At the instance level, under the private_nic configuration, subnet_cidr is the IP subnet the instance should be created in.  If this Subnet doesn't already exist, Rubber will create it for you.  An important thing to keep in mind is that AWS requires that all instances in a given Subnet be in the same availability zone, so keep then in mind when creating instances.  The gateway configuration should be either the word "public", or the instance id of a NAT Gateway.  The difference here is that with a value of "public", Rubber will create an Internet Gateway for this subnet if one doesn't already exist, which makes the subnet publicly accessible.  This is where things like your load balancers should go; anything that needs to be reached by the outside world.  A gateway value of an instance id will designate the subnet as private, and instances on this subnet will connect to the outside world via the NAT Gateway.  Also note that we provide a nat_gateway template in Rubber, so a "rubber vulcanize nat_gateway" will install base configuration for a NAT Gateway.  One can then be created like you would a machine with any other role - rubber create, bootstrap, deploy, making sure the machine has the nat_gateway role.  Ideally, you should put any instances that don't need to accept connections from the outside world in a private subnet - database servers, app servers (since your load balancer would be in the public subnet), etc.  Note that by default, within a given VPC, security groups rules exist so that all subnets, public or private, can communicate with one another.

Let me know if you have any other questions.  While this is a very new feature, I admit we could have done a better job documenting it.  I will hopefully get the wiki updated at some point this week.

You received this message because you are subscribed to the Google Groups "rubber" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit

Reply all
Reply to author
0 new messages