3

I'm pretty new to AWS, but I've got a very small Amazon Linux EC2 instance that's used for a simple, occasional PHP process so I'm not using CodeDeploy, Load Balancers, etc. My boss wants to use WinSCP to upload some PHP code from time to time.

I'm wondering what the best approach to persisting those PHP changes in the event the instance is terminated or rebooted. Currently the only way I see to do this is to update the files, then create a new AMI, then create a new Launch Configuration with this new image and apply it to the Auto Scaling group. This seems like a lot of work just to keep the files on the EBS volume up to date.

Am I missing something? Perhaps there’s something could be done with EBS volumes and snapshots?

Thanks for any advice.

Michael Hommé
  • 133
  • 6
  • You can create a snapshot and then create AMI off of it, then build from that. You should probably look at managing this differently, maybe upload changes to S3 bucket and just download from there. – Schrute Jan 25 '18 at 18:48

4 Answers4

1

This seems like a lot of work just to keep the files on the EBS volume up to date

It is a lot of work. But the problem is not the amount of work. It's that you're asking for more than just keeping files on an EBS volume up-to-date. Your asking for updates on your EC2 instance to persist onto other EC2 instances.

EBS volumes are like your hard drive in your local computer. AWS does some work behind the scenes to ensure the data is replicated, but that's all within the confines of a single EBS volume.

Terminating an EC2 instance and deleting the volume is like me coming to your house and smashing your computer with a sledgehammer. Do you expect your data to magically replicate to your new computer without having first done something to protect that data? Of course not.

If an EBS volume is deleted, the data is gone. AWS does not magically replicate the data elsewhere. That's up to you, if you need it beyond the lifetime of the EBS volume. And that's a key point: not everyone needs the data to persist beyond the lifetime of an EBS volume.

When you turn off the "Delete on Terminate" flag for an EBS volume, it simply means that when the EC2 instance is terminated, the EBS volume is not deleted. When this happens, that EBS volume will sit unused in your AWS account.

The unattached EBS volume can be attached to another EC2 instance so you can use it, but again, that's not magically done for you. You need to do it yourself.

AWS:

  1. ensures your data is as protected as it can, where it can, and
  2. provided the tools for you to go further.

Know where #1 stops and where you need to take over with #2.

So yes, preserving the files on an EBS volume is up to AWS. However, again, that's not what you want. You want more.

If you want the data to persist after an EC2 instance is terminated, then you need to do more. Creating an AMI image and updating your Auto Scaling group's Launch Configuration is what you need to do.

Matt Houser
  • 10,053
  • 1
  • 28
  • 28
0

If you are using an EBS volume with your instance, changes you make persist through reboots unless you delete the EBS volume. Older instance types though used an ephemeral instance store that was wiped each time you terminated the instance - is that your problem?

If you're looking to spread your data across a cluster or autoscaling group then EFS is the best answer https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html

Jonathon Sim
  • 1
  • 1
  • Thanks, and yes, I'm using an EBS volume. I honestly assumed it would persist as you stated, but that's not what I'm seeing, unfortunately. For example, when an instance is launched I connect to it, upload a new file, then manually terminate the instance, then the ASG spins up another instance and the file is gone. However, the new instance is connected to a volume that was created at the same time of the manual termination. I tried setting Delete On Termination to false, but still no luck. – Michael Hommé Jan 25 '18 at 21:24
0

You shouldn't have to worry about the instance rebooting. Make sure the instance's Shutdown Behavior is set to Stop and not Terminate.

Next, my recommendation for maintaining changes to your code would be to use a version control system, such as Git or SVN. If, for some reason, these are not an option, then the next most appropriate solution will be to store the code modifications externally, in S3 or a similar service, then configure User Data on your EC2 instance to download the latest code from your S3 bucket. You can access the User Data section when launching an EC2 instance, on the Configure Instance Details page. You will have to expand the Advanced Details at the bottom.

See: https://stackoverflow.com/questions/39280251/ec2-user-data-to-fetch-s3-object

See: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-dynamic-data-retrieval

Aaron St Clair
  • 11
  • 1
0

If it’s a small change, I recommend using beanstalk, if you don’t want to build a system out. Store your code in source control and zip your files to S3 using the EB Beanstalk deploy tool by Amazon. Then, deploy to your instances. In case your instances go down, it’ll be marked for re-provision, and you can deploy the application. In this case, you can use options for configuring ELB.

Mika Wolf
  • 169
  • 3