bumping with an update
An x86_64 AMI is now available via our account here.
4 Likes
Thank you for the update. For those of us who prefer to avoid AWS Marketplace (for various reasons), can someone please provide a listing of AMIs for each of the regions? Thanks!
1 Like
I see that even if I get the ami ID, I had to subscribe to the product before using the AMI. Would it be possible to share the AMI from an account like CentOS is shared from Fedora’s official account?
Could you publish AWS Marketplace product codes as well please?
Could you please publish images from a known account outside of the AWS Marketplace?
I think a fairly common pattern is to deploy images using datasources in something like terraform to find the latest available image. Currently if you filter for “Rocky Linux 8.4*” in the AWS Marketplace account you will end up with a 3rd party image from CIQ which adds an extra support cost of the image (and I don’t know if the image itself has been tampered with).
I think it would be much better if one could just filter on images from your Owner ID (this was possible with CentOS), or at least publish clear guidance on the product codes that represent the official images.
1 Like
@albgus have you seen these: AWS Marketplace: Rocky Linux as from as far as I see, these are official Rocky 8 AMI images with only infrastructure costs.
Yes I know. But the problem is that you’re only publishing to the AWS Marketplace, which has a vulnerability where other vendors can create images with the same name and if you’re searching for the most recent marketplace images you run the risk of a 3rd party image getting picked up.
This isn’t a problem if your workflow is clicking through the quick-start guide for each server you deploy of course, but if you’re building AMIs with for instance packer and want it to automatically select the latest available AMI.
I know that this sucks and I don’t understand why AWS doesn’t seem to care about this - but the CentOS project, and AlmaLinux for that matter, publishes images under a specific account ID which makes it easier to filter for images from a validated official source.
Publishing the product code would be nice as well. This didn’t appear to happen in the issue that @jorp referenced seeing as it’s closed with no product code to be found.
1 Like
+1 regarding publishing the images outside of Marketplace, like CentOS did. In our case, we publish terraform configs using CentOS as the base image. When we had to use the Marketplace, a lot of users didn’t subscribe to the Marketplace listing before running terraform which results in errors. Images outside doesn’t require a subscription first, making the user experience better.
Hey folks - (ccing @syin , too)
We’ve had a page published for a bit now which shows this information like CentOS does - https://rockylinux.org/ami . I don’t think the release was very well announced to the community, though.
I’m still waiting on an internal ticket with AWS regarding our aarch64 images for 8.5, but once that is completed that page will be updated with the IDs for 8.5, as well as deploy links. Ideally, we’ll have the information available just via JSON, too.
I’d love to know what information would be most useful to everyone. I’ve heard both account (owner) ID as well as Product Code – both of which I think are things we can publish, as well as some scripts/guidance on how to find this information using AWS command line. I’ll take this as an action item for this week to get a document up on the wiki that details this, and link to it from the website.
Thank you so much for your patience, and please do let me know what information would be most useful, aside from the AMI IDs themselves. I definitely understand the plight of waiting for the subscription to do its thing, so the direct AMI IDs completely have their places.
1 Like
All images published on the marketplace will have an owner ID of 679593333241 AKA “aws-marketplace”
From a Terraform point of view, we look up images using “owner” and filter by “name”. For deployments where we don’t know the region in advance, that’s easier to manage than listing all the AMI IDs for different regions.
See this example here where ami_owner is “125523088429” which is the AWS account for CentOS and name is “CentOS 7*x86_64” to get the latest of CentOS 7.
If we have to use a Marketplace image, the ami_owner would be “aws-marketplace” or equivalently “679593333241”. “name” would be whatever the image name is called. I noticed that the current 2 marketplace AMI names are:
- Rocky Linux 8.4-d6577ceb-8ea8-4e0e-84c6-f098fc302e82
- Rocky-8-ec2-8.5-20211114.2.x86_64-d6577ceb-8ea8-4e0e-84c6-f098fc302e82
It would be nice if the name is more consistent, so that for example, I can filter for “Rocky Linux 8*” to get the latest 8.x, or “Rocky Linux 8.5*” to get the latest 8.5 image.
One thing to be careful of is there could be multiple images with names starting with “Rocky Linux” from different vendors. So if someone searched the marketplace for “Rocky Linux*”, an image from another vendor might be returned. In that case, adding “product-code” would ensure you get the image you expected. The product code of Rocky Linux is already publicly available: “cotnnspjrsi38lfn8qo4ibnnm”. This wouldn’t have been an issue if the AMI was just a public image rather than a marketplace image, since we would then be able to filter by “ami_owner”
Note another issue with Marketplace is that it’s a bit difficult to keep track of what version in the marketplace listing is deprecated. You do get an email notification from Amazon when the owner of a listing deprecates a version, but a subscriber can see/use all versions of a marketplace listing since the date of subscription, regardless of deprecation status. That makes my use of marketplace more complicated as my code could point to a deprecated AMI I have access to, but not my users who subscribe to Rocky Linux later than me.
Hope this make sense. I’m still trying to understand all the little quirks of publishing in AWS marketplace.
2 Likes
@jorp @neil :
Could the Rocky Linux AMI be built without a swap partition? That would allow the storage to be configured seamlessly.
I’m pulling in Rocky Linux 8 (ami-04826709428f49157) and when we log into the console we can see it has been provisioned with 8Gb disk and a 511Mb swap partition.
The problem is that if we provision the image (via Terraform in my case) and specify a larger disk e.g. 15Gb, then the root partition does not automatically get expanded
sh-4.4$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 15G 0 disk
├─nvme0n1p1 259:1 0 7.5G 0 part /
└─nvme0n1p2 259:2 0 511M 0 part [SWAP]
The reason is the swap partition prevents it. The only way around it requires that the swap partition be deleted so we can run growpart and resize2fs. To delete the partition requires running fdisk, which is a UI and requires human interaction to delete a partition.
In other words, with the existing RockyLinux AMI, if we need a partition larger than 7.5Gb, it requires manual intervention which doesn’t work well with our otherwise-automated pipeline.
The CentOS AMI marketplace doesn’t create a swap partition, I believe for this very reason.
To reproduce: launch a RockyLinux AMI from AWS console, but specify a larger storage size than 8 e.g. 10.
Connect to the console and confirm there is only 7.5Gb available to the root partition.
If you repeat the same exercise but with a CentOS image, you’ll see the root partition is automatically expanded to match the disk size as specified in the launch parameters.
Hi,
we are not getting any swap partition and our disk size is 200GB
[ ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 200G 0 disk
└─nvme0n1p1 259:1 0 200G 0 part /
[l ~]# free -m
total used free shared buff/cache available
Mem: 1778 448 1030 18 300 1171
Swap: 0 0 0
We are using below AMI
Its AMI ID is ami-0a10fe11f3e1bf41e and OWNER ID is 792107900819
Thank you @linuxlover : I indeed had the wrong AMI. My filter was “Rocky Linux 8*” in us-east-1 and that picked up an older one, 8.4 from June 2021. Looks like the newer images have since fixed the issue.
And the working one is an 8.5 version (AMI name Rocky-8-ec2-8.5-20211114.2.x86_64)
With the above one there is no longer a swap partition, and resizing from the AWS console works as expected.
1 Like
And for any future readers of this thread wondering about community AMIs owned by 792107900819, this is indeed the Rocky Linux account. To confirm follow the link
This includes a reference to https://rockylinux.org/cloud-images/. Following the link we see
And picking one of those AMIs shows the RockyLinux owner
