1

I'm a very young systems engineer/contractor sysadmin with a bandwidth-heavy workload that just moved to an area where I get 2mbps download and 20 upload on my internet connection. I'm moving my Debian 10 workstation to AWS because of that, and I need some advice.

I want to manage my workstation setup with terraform (99% done), packer, and ansible. I want to create a script to run every time I change my ansible setup that will create a new AMI with packer+ansible and deploy it with Terraform.

I want to keep my home directory the same in all versions of my infrastructure since I have a ton of vagrant boxes and pip venvs populated with packages that I want to have consistent no matter what the base system configuration is. The home directory will be slightly managed as I add ssh keys, create a hotwired vagrant setup (which is worthy of another post), etc. That is the main roadblock right now.

I was thinking about using a second EBS volume and mounting it at /home/. The issue with that is when you create an AMI from another instance, it will copy the EBS, and get its own EBS ID. The next time I create an AMI with Packer, I will need to snapshot, attach, and mount the EBS volume on the running instance and I don't see a clear way to do that with Packer or Ansible. EFS is too slow to consider.

Basically, what is a way to keep data from the production instance when moving to a new instance in AWS without creating an ami from the older instance, while avoiding slow or expensive components such as EFS. I can't just ami-create a new instance because I want my AMI's to be generated from the base Debian 10 image to prevent configuration drift.

scetoaux
  • 1,289
  • 2
  • 12
  • 26
  • Do you have to build the new AMI with the second EBS volume attached or can you build it with an empty `/home`? You can then attach the additional volume to the new instance when you boot it with Terraform. – bodgit Dec 04 '19 at 13:49

1 Answers1

0

This is a left field answer, and probably won't be accepted, but I think it's an option worth mentioning. Please avoid the urge to vote me down because I'm not answering exactly as expected.

Using EFS is probably best practice. It's a bit more expensive with a bit more latency, but it's good for this task.

AWS Workspaces

Have you considered AWS Workspaces? It's Ubuntu, but might solve your problem of a cloud based workstation.

S3 Storage

Storage on S3 is cheap, and usually fast enough, especially if you have an S3 gateway in your VPC.

Your two main options with S3 are:

  • Use S3FS to mount an S3 bucket as storage, with an S3 gateway in the VPC you should get acceptable performance
  • Sync your data with S3 on startup, shutdown, and you could do it with cron as well. I believe bandwidth to S3 is free when you use a VPC gateway, but you still pay for the put / get operations, which should be a fairly low cost.
Tim
  • 31,888
  • 7
  • 52
  • 78
  • The more I'm looking at this problem, the more I like EFS. Its much slower than EBS but it's independence from the VM itself would make it really easy. Thank you for your time on this answer. –  Dec 04 '19 at 19:42
  • Upvote if you like it, and mark it as the answer if you go that way :) – Tim Dec 04 '19 at 20:10
  • I did upvote it, my upvotes don't count until I have 15 reputation. Marked as answer :) –  Dec 04 '19 at 23:33
  • Great, hope it helped :) EFS might be a bit more expensive but is pretty much ideal for what you need. S3FS is less reliable but could make the storage cheaper. – Tim Dec 05 '19 at 08:47