User Tools

Site Tools


access:new_aws_vpc

This is an old revision of the document!


How to set up a new VPC in AWS for testing or production

These instructions indicate how to create a new VPC for an AGTEK Access server. This is useful for either testing, or migration of an entirely new constellation of server components. These instructions do not indicate how to add multiple EC2 instances to the VPC for load balancing or failover error recovery.

  1. Create the VPC
    1. Name the VPC “ProdNet” or “TestNet”, etc. We'll use XNet or XSubnet for examples from here on out.
    2. Assign an IPV4 CIDR Block - 10.0.0.0/16
    3. Set “tennancy” to default
    4. Tag VPC for “class” as “access” or “development”, etc.
    5. Create at least one subnet in the VPC - Name something resembling the VPC name, e.v. XSubnet.1
      1. Map zones to subnets, suggest the following (Using the Virginia region)
        1. 1a to XSubnet.0
        2. 1b to XSubnet.1
        3. 1c to XSubnet.2
        4. etc.
    6. Create an internet gateway, attach it to the VPC.
    7. Edit the VPC route table
      1. Associate at least 1 subnet with the route table.
      2. For Access, one subnet is enough, generally our instance work has been in zone 1b, so XSubnet.1
      3. Add the internet gateway to the Route Table, with destination 0.0.0.0/
  2. Create EC2 instance
    1. Name the EC2 instance, e.g. 'Production-A', 'Production-B', etc.
    2. Tag EC2 instance with same tag from VPC
    3. Name the EC2 security group to 'XNet-EC2-SG'
    4. Edit the EC2 security group to:
      1. allow for all incoming on 34015 - 0.0.0.0/0
      2. allow for incoming SSH on port 22 - consider filtering to Agtek corp IP and developer's home IP
      3. allow for EFS incoming from within the VPC
      4. allow for MySQL/Aurora incmoing within the VPC
      5. allow for ALL outgoing from the EC2 instance
  3. Create RDS instance
    1. Edit RDS security group to allow for traffic from within the VPC, specific subnet
      1. e.g. source 172.30.0.0/16 or use the EC2's security group
      2. Do not allow any traffic from outside of the VPC
    2. Set RDS backup to low impact time (currently 1AM), retain 5 days worth
      1. Set minor maintenance window to midnight, 30 minutes wide
      2. Set major maintenance window to Saturday evening 6 PM, 30 minutes wide
  4. Create access store EBS, used to hold server code
    1. Currently (3/31/2017) tracks on store.
    2. If possible restore access store from current access store snapshot (otherwise you'll need to do a tar backup later)
  5. Create and EFS store to hold tracks (future)
  6. Log into EC2 instance
    1. sudo yum update
    2. sudo yum install mysql (tools needed for mysql client)
    3. mkdir /mnt/access (create mount point for access store)
    4. Attach access store to EC2 instance via EC2 console
    5. Attach EFS store to EC2 instance
    6. Copy following files
      1. /mnt/access/tools/bashrc to ~/.bashrc
      2. /mnt/access/tools/menu.sh to ~
      3. /mnt/access/tools/agtekaccess to /etc/init.d
      4. /mnt/access/tools/agtektomcat to /etc/init.d
  7. Log into old EC2 instance
  8. Shutdown (only if migrating!) old server on old EC2-instance
  9. Dump old RDS MySQL to /tmp/dump.sql
  10. Copy /tmp/dump.sql to new EC2 instance
  11. On new EC2 instance, restore sql via:
    1. mysql -u access -p -h new-rds-endpoint.rds.amazonaws.com < /tmp/dump.sql
  12. Connect to MySQL, fix DBHost column in access:customer to be new-rds-endpoint.rd.amazonaws.com
  13. Assign elastic IP to new EC2 Instance
  14. Change DNS entry if new elastic IP
  15. Start server on new EC2
  16. Test server
  17. Monitor server
access/new_aws_vpc.1490897299.txt.gz · Last modified: 2017/03/30 18:08 by mjallison