On 9/1/24 17:08, Colin Percival wrote:
On 9/1/24 16:46, Dan Langille wrote:
On Sun, Sep 1, 2024, at 6:26 PM, Colin Percival wrote:
On 9/1/24 12:09, Dan Langille wrote:
On Sun, Sep 1, 2024, at 2:46 PM, Colin Percival wrote:
I'm planning on adding a new flavour of FreeBSD/EC2 AMIs: "Small"
AMIs,
which are the standard FreeBSD "base" images minus some bits which
are
optional or generally less likely to be useful for production
systems:
[...]
I’m going to guess the main benefit is lower memory usage. Which
means smaller instances can be used.
This should have no effect on memory usage aside from the fact that
getting rid of some of the large debug files will make freebsd-update
use less memory. These are all bits which are never loaded from disk
aside from that.
The goal is to improve freebsd-update?
No, the goal is to avoid wasted disk space. A t4g.nano instance costs
$3/month and gp3 EBS volumes cost $0.08/GB/month, so if you shave off
4 GB of disk usage and make your EBS volumes 4 GB smaller you've reduced
your instance cost by 10%.
this seems like a good idea from my POV as an admin. Although I think
it may be helpful to keep the AWS CLI install on boot step in some
use-cases. My general workflow is to use packer to build a site
specific AMI where I install our specific configs and run freebsd-update
then disable it on subsequent boots. My goal in those scenarios is to
improve first-boot time for auto-scaling.
When I do use "vanilla" AMI's its usually for a
research/testing/debugging task so having the awscli get installed on
firstboot would save me some hassle of having to do that by hand. It's
certainly not a deal breaker though, just my two bits.
-pete
--
Pete Wright
[email protected]
