Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade AWS AMI for brainard-archiva server #68

Open
benjamin-heasly opened this issue Apr 7, 2016 · 1 comment
Open

Upgrade AWS AMI for brainard-archiva server #68

benjamin-heasly opened this issue Apr 7, 2016 · 1 comment

Comments

@benjamin-heasly
Copy link
Contributor

We got an email from Amazon saying we should upgrade the software we're using for our brainard-archiva server.

We haven't encountered problems yet. So this is not urgent. But we want to keep track of it here.

Dear Amazon ECS customer:

We recently released a new Amazon ECS-optimized AMI that includes Amazon Linux 2016.03 and addresses an issue that causes the agent to stop accepting incoming requests. You can see all of the recent updates in our agent release notes. 1

We recommend that you update to the latest Amazon ECS-optimized AMI. You can find the latest Amazon ECS-optimized AMI version and the process to launch container instances in the documentation. 2

If you are using an Auto Scaling group for the EC2 instances in your cluster, you should create a new launch configuration with the latest Amazon ECS-optimized AMI. 3

Sincerely,
The Amazon ECS Team

@benjamin-heasly
Copy link
Contributor Author

I think this would take at least half a day.

I don't expect any service interruption because we can stand up a new Amazon instance "on the side". Once the new one is working, we can swap over our dynamic IP address.

To do this upgrade, we'll have to remember how we did the original. I wrote a lot of it down:
https://github.com/isetbio/RemoteDataToolbox/wiki/Archiva-Deployment-on-AWS
#22

What's tricky about this upgrade is that we can't just swap in the new AMI that Amazon released. We have to start with the new AMI and then apply two customizations from the command line:

  • mount the volume that contains our data and config
  • set up daily backups

I tried to avoid this kind of command line customization because it's a pain to maintain. But I don't know another way to accomplish those two tasks.

When we do this upgrade, we should put all the customizations in a script that we can "just run", and add wiki documentation for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant