We have the requirement that at the point of the first deployment (or release creation) that we get the latest AWS AMI ID and store it with the release. So when we deploy to other environments we always have a consistent variable.
The potential solutions we have are:
Save the AMI ID as an artifact
How it could work:
On first deployment, we check for an octopus artifact, if it’s not present we get the latest AWS AMI ID via a call to AWS. The custom auto scaling group step will get the latest AMI ID it’s saved into an Octopus artifact and also set-OctopusVariable.
Any subsequent deployment, we check do we have an octopus artifact with the AMI ID, if we do we use it and save it locally, set-OctopusVariable.
Pros:
We have most the code for getting AMI IDS and saving artifacts, so it would be quick enough to implement.
Cons:
We are unsure how we can get artifacts (Is there a PWSH command?)
The AMI ID isn’t obvious, it’s hidden away in an artifact, a misuse of Octopus flow? Hacky?
Publish the AMI IDS as an artifact in the artifact repo
How it could work:
We have a build process that get’s all the latest AMI IDs and saves them in a format (json/yml) which are then saved as a deployment package (nupkg) and push them to our artifact server.
The deployment refers to this package and the auto scaling group will read this package and get the correct AMI ID.
Pros:
Visibility of the AMI ID is a little clearer, it’s in a package which is consumed by the auto scaling step
You can pick an older package when creating a releaqse; if you need to deploy an older AMI ID
Cons:
More work to implement than the first solution
Two steps need to be updated, add “get package” and update “auto scaling group” steps.
Use a database to persist the AMI IDs used
How it could work:
On the first deployment we would check the database, if we have an AMI ID we would use it, if we don’t have it we would get the latest and then insert it into the database.
Pros:
…
Cons:
Also a reasonable amount of development to achieve it
Additional hardware of the RDS needed, with associated costs.
AMI ID hidden away in a system outside of Octopus, not great visibility.
Ideal solution:
What we would ideally like is that when you click “create release” that there is a hook where the can get the AMI ID and save it as a snapshot variable. Is this possible?
If the above isn’t possible, is it possible that when we run the first deployment that when we get the AMI ID that we can save it back into the snapshot, so that it is available in the next deployment?
If neither of the above two options aren’t available, is there an option that we haven’t considered that would be viable?