Elixir on Elastic Beanstalk

We love instructions. And this time let’s talk about basic setup for Elastic Beanstalk. Little reminding for those who do not (yet) using this service: Elastic Beanstalk is a cloud deployment service that automates the process of setting applications up on the AWS (Amazon Web Services). So how to deploy Elixir on Elastic Beanstalk?

What are required steps for deployment Elastic Beanstalk app to AWS? To see the whole procedure we recommend you see the original article Elixir on Elastic Beanstalk. Part 1 — Virtual Private Cloud with some in-detailed explanations and screenshots. In our material we will just stop on the most important milestones.

VPC
Let’s create a new Virtual Private Cloud (VPC) and associate Classless Inter-Domain Routing block. This is a network mask for all addresses inside VPC — 10.0.0.0/16. All instances in subnets will have CIDRs starting from 10.0.subnet.xxx/24 or 10.0.subnet.xxx/32. You can use 172.31.0.0/16 instead 10.0. Dedicated Tenancy should make your cloud work faster.

Create new VPC
New DHCP option set will be added automatically to assign ip addresses to all instances under current VPC. You will be able to connect from outside only with DNS hostnames and DNS resolution. But this is not the best idea. If you have any other plan how to migrate and seed data like running deployment node into VPC, than you don’t need to give an access from outside.

Crate subnet
While it’s a kind of a playground for now, we will create only public subnets. Here we define a new subnet into 1a Availability Zone with a CIDR block 10.0.64.0/20. That means we have 4K ip addresses available. In Subnet Actions menu we select not to assign public IP addresses to instances.

Auto-assign IP address
To communicate we should create an Internet Gateway. And then we should define a Routing Table. On subnet associations we select all created subnetworks. Now all of them are linked to the router and able to connect with each other and with internet too.

Subnetworks in RT
Defining a subnetwork ACL is provided for protected all traffic on a subnetwork’s layer. Security Groups do the same but on instance layer. Another difference between ACL as SG is that you define in security group who can access the content, but in ACL you define who can’t. In future don’t allow to come in and out of subnetwork. The last one is “other” case if any case have been successed. Later you can insert rules between 100 and 200 just by setting it’s value for example to 120.

Security Groups
We need 3 Security Groups for — EC2 instances, Elastic Load Balancer and RDS. We need to open port 80 for HTTP and 22 for SSH. HTTP inbound rules is set to ELB security group. We don’t want to accept any other HTTP traffic. For communication between each other, you should set EC2 security group to accept EC2 SG connections. Outbound rule is — open to all ports to any ip address.

EC2 Outbound Rules
ELB security group has inbound rule set to HTTPS. This is the only one port we want to use on a connection. When we decide to use SSH to communicate with instances, we can set a public IP to the instance and connect directly to it. Outbound rules set to accept all

ELB Inbound Rules
RDS security group has 3 rules, all 3 is for accepting connections on a Postgres port 5432. Here we specify source groups — it can get a connection from itself (means from all instances in RDS SG), from EC2 SG and from developer’s IP. Outbound rules set to accept all.

That’s all for the basic setup. Now VPC is ready to handle Elastic Beanstalk application and a database. We can move on to RDS. We start not from a database itself but from parameters setup. We need to create a new Subnet Group. DB instance will operate in a group of subnetworks and we want specify them. We want to use all subnets in a a selected VPC.

RDS Parameter Group
We are ready to create a database. To avoid database destruction in case we decide to completely remove EB environment we will make database separated from EB application. As our database and production tier we can select PostgreSQL in RDS console.

Production tier
All settings are quite strightforward: Postgres version — 9.6.3-R1; Instance class — medium should be enough for now; Multi-AZ — set to NO (we can sey YES later); General Purpose (SSD) — two other options are magnetic and provisioned IOPS (SSD).

Choose your favorite username and super-secured password for settings. DB Instance Identifier will appear in the database DNS.

After all check security settings — there are no difficulties. And don’t forget to set database name and DB Parameter Group. If you don’t really want to backup your database, set retention period to 0.

Your VPC is ready to handle Elastic Beanstalk application.

p.s. Documentation can be found here.