ferricoxide
commented
3 months ago @mrabe142
Ok, to make this testable in a scalable way, I've converted what you've described into a userData script. That script looks like:
#!/bin/bash
#
# Bail on errors
set -euo pipefail
#
# Be verbose
set -x
#
################################################################################
# Log everything below into syslog
exec 1> >( logger -s -t "$( basename "${0}" )" ) 2>&1
# Patch-up the system
dnf update -y
# Allocate the additional storage
if [[ $( mountpoint /boot/efi ) =~ "is a mountpoint" ]]
then
if [[ -d /sys/firmware/efi ]]
then
echo "Partitioning for EFI-enabled instance-type..."
else
echo "Partitioning for EFI-ready AMI..."
fi
growpart --free-percent=50 /dev/nvme0n1 4
lvm lvresize --size=+4G /dev/mapper/RootVG-rootVol
xfs_growfs /dev/mapper/RootVG-rootVol
lvm lvresize --size=+8G /dev/mapper/RootVG-varVol
xfs_growfs /dev/mapper/RootVG-varVol
lvm lvresize --size=+6G /dev/mapper/RootVG-auditVol
xfs_growfs /dev/mapper/RootVG-auditVol
else
echo "Partitioning for BIOS-boot instance-type..."
growpart --free-percent=50 /dev/nvme0n1 2
lvm lvresize --size=+4G /dev/mapper/RootVG-rootVol
xfs_growfs /dev/mapper/RootVG-rootVol
lvm lvresize --size=+8G /dev/mapper/RootVG-varVol
xfs_growfs /dev/mapper/RootVG-varVol
lvm lvresize --size=+6G /dev/mapper/RootVG-auditVol
xfs_growfs /dev/mapper/RootVG-auditVol
fi
# Reboot
systemctl rebootThe above should function for either BIOS-boot or EFI-boot EC2s launched from the various spel AMIs and replicate what you described as your process. Some notes:
-
The line:
set -euo pipefailCauses the script to immediately abort if there are any errors in its execution. If this script aborts itself, the system will not reboot. Conversely, if you login to the system and check the boot-history (something like
[[ $( journalctl --list-boots | wc -l ) -gt 1 ]] && echo "UserData succeded") -
The line:
set -xMakes the script "chatty" in its execution.
-
The line:
exec 1> >( logger -s -t "$( basename "${0}" )" ) 2>&1Takes the userData script's execution-output (see previous bullet) and sends it to the
syslogservice. You'll then be able to see all of the logged userData script's activity in/var/log/messagesby doinggrep -P ' part-001\[\d*]: ' /var/log/messages -
The line:
if [[ $( mountpoint /boot/efi ) =~ "is a mountpoint" ]]Checks to see if the the path,
/boot/efiis a mountpoint (as it is on EC2s launched from EFI-ready AMIs). This selector determines whether to execute (your)growpart --free-percent=50 /dev/nvme0n1 4orgrowpart --free-percent=50 /dev/nvme0n1 2. Note that issuing thegrowpartcommand is obviated if your userData payload includes a#cloud-configsection that looks like:growpart: mode: auto devices: [ '/dev/xvda2', '/dev/xvda4', '/dev/nvme0n1p2', '/dev/nvme0n1p4', ]
To launch a batch (of 30) instances, I use a BASH one-liner like:
mapfile -t INSTANCES < <(
aws ec2 run-instances \
--image-id ami-021ba76fc66135488 \
--instance-type t2.xlarge \
--subnet-id <SUBNET_ID> \
--security-group-id <SECURITY_GROUP_ID> \
--iam-instance-profile 'Name=<IAM_ROLE_NAME>'
--key-name <PROVISIONING_KEY_NAME> \
--block-device-mappings 'DeviceName=/dev/sda1,Ebs={
DeleteOnTermination=true,
VolumeType=gp3,
VolumeSize=100,
Encrypted=false
}' \
--user-data file:///tmp/userData.spel_695 \
--count 30 --query 'Instances[].InstanceId' \
--output text | \
tr '\t' '\n'
)This saves all of the newly-launched instance's IDs to a BASH array (named INSTANCES), that I can then loop over to do things like reboot each instance an arbitrary number of times and check that each has returned from said reboots.
mrabe142
Creating new ticket as it seems like OP for #691 may no longer be having issues (no comment since June 14th) and don't want to continue spamming if such is the case.
Originally posted by @mrabe142 in https://github.com/plus3it/spel/issues/691#issuecomment-2168365155:
And, per @mrabe142 in https://github.com/plus3it/spel/issues/691#issuecomment-2187415382:
And, per @mrabe142 in https://github.com/plus3it/spel/issues/691#issuecomment-2189641239: