Elixir on Elastic Beanstalk. Part 1 — Virtual Private Cloud.
Distributed Systems Development A-Z Guide.
Give us a message if you’re interested in Blockchain and FinTech software development or just say Hi at Pharos Production Inc.
This time we will look at steps we require to depl0y Elastic Beanstalk app to AWS. We will not use default VPC(virtual private cloud) but will configure all required services from scratch.
VPC
Let’s create a new Virtual Private Cloud. Here we define VPC name and associate CIDR block — Classless Inter-Domain Routing. This is a network mask for all addresses inside VPC — 10.0.0.0/16. Addresses will look like 10.0.xxx.xxx/16. All instances in subnets will have CIDRs starting from 10.0.subnet.xxx/24 or 10.0.subnet.xxx/32. Also, you can use 172.31.0.0/16 instead of 10.0. Surely all names should contain something more informal rather than word “production”. But our current setup is just a playground. We don’t add IPv6 address resolution and leave Tenancy as default. You can change this later, Dedicated Tenancy should make your cloud work faster, surely for the additional cost.
New DHCP options set will be added automatically to assign IP addresses to all instances under current VPC.
Also, we should add DNS hostnames and DNS resolution to the VPC, otherwise we’re not able to connect from outside. Actually, this is not the best idea, but we will deploy the database into VPC subnetworks and we want to run migrations from a developer’s workstation. 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 access from outside.
Subnets.
Now let’s add subnets to the VPC. We will create only public subnets for now. 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 the subnet. For sure this can cover all our needs.
In Subnet Actions menu we choose not to assign public IP addresses to instances. We want to access the only database from outside and not instances itself.
Another thing we should create is an Internet Gateway it possible to communicate with the internet.
Next, we should define a Routing Table. Here we’re attaching created internet gateway and VPC IP address. 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 the internet too.
Also, we should define subnetwork ACL — to protect all traffic on a subnetwork’s layer. We have also Security Groups, they 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. To simplify all our setup for now we define that everyone can come in and out of subnetwork. We should change this in the future. It’s a good practice to define rules with numbers like 100, 200, 300 etc. The last one is “other” case if any case has been succeeded. Later you can insert rules between 100 and 200 just by setting its value for example to 120.
Security Groups.
Let’s add required Security Groups. We need 3 groups for — EC2 instances, Elastic Load Balancer, RDS.
All HTTPS traffic termination should be done in ELB, so inside the subnetwork all traffic is HTTP. Security group assigns its security on a per-instance basis. So we need to open port 80 for HTTP and 22 for SSH. Also, we can open ICMP port for the ping, but there is not much sense to do this. HTTP inbound rules are set to ELB security group. We don’t want to accept any other HTTP traffic. If you want to make instances communicate between each other, you should set EC2 security group to accept EC2 SG connections. An outbound rule is — open to all ports to an IP address.
ELB security group has an 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
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!
RDS.
We start not from a database itself but from parameters setup. Let’s move from bottom to top of the menu.
We need to create a new Subnet Group. DB instance will operate in a group of subnetworks and we want to specify them. We want to use all subnets in a selected VPC.
Next, we create a Parameter Group. This is our future Postgres settings including everything you can tune in Postgres.
Now we’re ready to create a database. We make database separated from EB application to avoid database destruction in case we decide to completely remove EB environment but leave database alive.
In RDS console we select PostgreSQL as our database and production tier. We can select Dev/Test too, there is no difference.
All settings are quite straightforward. Here we selecting:
- Postgres version — 9.6.3-R1;
- Instance class — medium should be enough for now;
- Multi-AZ —set to NO, this is to maintain standby replica in case of failure, better to set it to yes, but we can do that later;
- General Purpose (SSD) — two other options are magnetic(this really sucked even for test purposes) and provisioned IOPS (SSD). Here is a description:
General Purpose (SSD)storage is suitable for a broad range of database workloads. Provides a baseline of 3 IOPS/GB and ability to burst to 3,000 IOPS.
Provisioned IOPS (SSD)storage is suitable for I/O-intensive database workloads. Provides flexibility to provision I/O ranging from 1,000 to 30,000 IOPS.
Magnetic storage may be used for small database workloads where data is accessed less frequently.
Fill settings with your favorite username and super-secured password. DB Instance Identifier will appear in the database DNS.
Also a new feature at RDS console, we check a price— supercool!
Network and Security. We select our VPC, subnet group, set database publicly accessible to make migrations from the development workstation. We have no preferences in the availability zone and select RDS Security Group.
Other settings are quite straightforward. Just don’t forget to set database name and DB Parameter Group here. If you don’t really want to back up your database, set retention period to 0.
That’s all for the basic setup. All other parameters like max connections, ACL settings etc you can set by yourself depends on your application and requirements. Now VPC is ready to handle an Elastic Beanstalk application!
End of Part 1. Next time we will look at how to set up and deploy basic EB application into this environment.
Thanks for reading!
