AWS VPC - Basic Set Up

This blog is a collection of notes that were taken while settings up a virtual private cloud in AWS. The scenario presented here is described as below
  • A chef server for configuration management.
  • Jenkins CI server.
  • Knife plugins to create and deploy application artifact.
  • Load Balanced Web servers.
  • DB servers.



The AWS VPC scenario is Scenario 2 .
 
Most of the basic setup is mentioned in the article above. The basic parts of this setup are as follows

PUBLIC NETWORK
  • This network is exposed to the internet.
  • Each node set up in the public network can talk to the internet (outbound).
  • For inbound traffic, each node needs to be associated with an Elastic IP.
  • Each node should have the Ephemeral Ports open since ACLs are stateless.
  • Ephemeral ports are ports opened on the client end when the client machine tries to connect to a server machine on a specific port.
PRIVATE NETWORK
  • This network is a protected network.
  • Mostly used to host back-end servers like database servers etc.
  • In our set up we are using mongo databases and replica sets along with an arbiter.
  • All the nodes in the private network connect to the internet (outbound) via a NAT server.
NAT SERVER
  • The NAT server is set up automatically while setting up the VPC using the VPC wizard.
  • Masquerading is configured by default on the NAT instance.
  • Elastic IP is associated by default on the NAT instance.
LOAD BALANCER
  • Elastic Load Balancing can be configured using the ELBs provided by AWS.
CHEF-SERVER
  • Configuration management server to help in automated configuration of the nodes created.
  • All nodes are bootstrapped to chef-server and roles are applied to them to configure them as db servers or web servers.
DB ARBITER
  • Arbiter is used to take part in elections in case of a mongo replica setup.
DEPLOYER NODE
  • This node is created to deploy the application tar ball.
  • Since we are using custom knife plugins for deployment, we need to set up this node as an admin client of the chef-server.
  • This node would run the knife commands and query the chef-server.
Here are some notes to make the above set up more coherent and workable..
  • The CHEF-SERVER is placed in the EC2 network outside the VPC. One would argue that this chef-server can be placed within the VPC as well. Yes, it can.
  • The DEPLOYER node queries the chef-server and is used for automated bootstrapping of new nodes.
  • The VPC networks are configured in a way that the public nodes act as jump boxes for the private nodes. No external access to the private nodes is provided, to safeguard the database servers.
  • The DB Servers can only be SSH'ed into via the deployer/ web server nodes.
  • Once the deployer has bootstrapped a new node to the chef server, appropriate role can be applied to the server and the node would be deployment ready.
  • In case of a chef-server, make sure that the NAT Security Group has an exception to allow traffic to and from port 4000, where the chef-server is running since the DB nodes would need to talk to the server via 4000. (Chef Server 10).
  • The public network needs to talk to the private network via port 22 (SSH) and the DB default port (27017 for Mongo).
  • In the private network, the nodes can SSH into each other but it'll always be good to not configure outbound ssh into the public network.
  • The web servers in the public network talk to the db servers only via the port which is listening for the database service in the private network.
  • The DEPLOYER nodes have both inbound and outbound SSH configured to be able to deploy to the Public and Private Networks and talk to the chef server using knife bootstrap/ ssh plugins.
  • After the Production deployment this node should disconnected by revoking ssh access into the public and private networks, to secure the VPC.
  • A Load Balancer is set up between the web servers in case of application with heavy traffic. Elastic Load Balancers are provided by AWS. However, make sure that your application has proper health check pages for the load balancer to check the state of the applications on the web servers.

Comments

  1. Sam Darwin6 January 2014 at 05:46

    Hi Pratima,
    this is very interesting. is the DEPLOYER just a machine with knife installed on it? it seems like that's the "trick" to making all this work, to have knife inside the VPC, while chef is still outside the VPC. Do you also have to make some manual steps to assign EIP or private IP, or can knife handle that? do you use the --ssh-gateway flag at all?
    thanks,
    Sam

    ReplyDelete
    Replies
    1. Pratima Singh5 September 2014 at 15:44

      Hi Sam,
      Apologies about the delayed response. I was caught up relocating. Well as for your question. You are right. The "trick" is to set up the deployer node to have knife inside the VPC. This node should be in the public subnet of the VPC. After configuring the securoty groups properly you won't need to use the --ssh-gateway flag as this node would be added to the CI server as an agent as well. With that I do want to clarify that this node should have Elastic IP addresses attached and should be started only when a deployment is scheduled in terms of production environment. In case you guys follow ideal continuous deployment where all every commit goes into production after thorough automated testing, then the security groups and ACLs "must" be robust enough to not allow any outside access other than the CI since this node is in all essence the jumpbox to the environment's secured VPC.

      Delete

Post a Comment

Popular posts from this blog

To DR or Not To DR

Image
Most organizations these days look at strategies and ways of implementing a "working" DR solution. Often a DR plan of action is a manual process based on multiple approvals at each level from Incident Management Teams to Product Ownership teams. What if there was a way to keep an active DR running where failure of a primary site would seamlessly transfer the traffic to the secondary site. In fact if the DR is active or warm then the only manual bit would be disabling the primary site via DNS. A few tips and tricks that would help in a simple implementation of a warm DR for an application hosted on AWS. AMI  Make sure that the AMIs are built across both the primary and secondary region.  The fastest way to build multi-region AMIs would be to use different builds for each region using the same configuration management code altering the "REGION" parameter each time. This would make the AMIs consistent and available in each region. PACKAGE REPOSITORY
Read more

High Availability NAT for AWS VPC with Multiple Private Subnets.

Image
VPCs have become the de-facto architectural choice when deploying enterprise applications. They are highly secure, keep your infrastructure logically separated which when combined with the power that AWS has to offer become highly available and robust. The one thing, however, that still feels like a point of failure are the NAT instances that need to be created for all private subnet outbound connectivity to the internet or any service that is external to the VPC. This brings us to create a sort of NAT failover mechanism. High Availability for Amazon VPC NAT Instances by Jinesh Varia offers a solution for a simple VPC that has active NATs per private subnet and each keeps pinging the other till one of them loses connectivity. The active NAT, at that moment, "takes over" the route for the failed NAT. An edge case to this solution is when you have private subnets per AZ and there is a loss of connectivity between AZs. We were faced with the same issue, which brought the t
Read more

Load Balancer with SSL offloading - nginx + HAProxy

Image
HAProxy and nginx can be configured together to work as an SSL offloader and a load balancer. Listed below are the steps to achieve the same on a centOS instance. Assume 192.168.1.1 and 192.168.1.2 running web servers on port 80 and 192.168.1.3 running haproxy on port 8181. Starting with HAPROXY set up. 1.  Install haproxy.        yum install -y haproxy 2.  Edit the haproxy configuration to update the backend web servers and keep it at the basic log level.     global   log 127.0.0.1   local2   chroot          /var/lib/haproxy   pidfile         /var/run/haproxy.pid   maxconn         4096   user            haproxy   group           haproxy   daemon   defaults                      mode            http   log             global   option          httplog   option          dontlognull   option          http-server-close   option          forwardfor except 127.0.0.0/8   option          redispatch   retries         3   timeout         http-request    20s   timeout        
Read more