Az AWS ezen a héten újra emlékeztetett mindenkit: az Amazon Linux 2 támogatása 2026. június 30-án véget ér. Ez elsőre még kényelmesen távolinak tűnik, aztán az ember végiggondolja, hány helyen bújik meg az AL2. EC2 launch template-ekben, golden AMI-kban, EKS managed node groupokban, ECS hostokon, Packer buildekben, CI runner gépeken, régi Lambda feltételezésekben és olyan admin boxokon, amikhez 2021 óta senki nem nyúlt.

Én ezt nem operációs rendszer frissítésként kezelem, hanem infrastruktúra migrációként. Ez fontos különbség. Ha az első reflex az, hogy majd belépek SSH-val és kézzel frissítem a gépeket, akkor már rossz irányba indultunk. A tiszta út nálam: inventory, újraépítés, fokozatos rollout, megfigyelés, majd a régi kapacitás törlése.

A legtöbb AWS workloadnál az Amazon Linux 2023 a cél. Ez nem egyszerűen AL2 frissebb csomagokkal. Van benne pár valódi viselkedésbeli különbség: DNF a YUM helyett, cgroup v2, systemd-networkd, más SSH alapbeállítások, csak Python 3, AWS CLI v2, journald alapú logolás, és a /tmp alapból tmpfs. A legtöbb alkalmazást ez hidegen hagyja. A köréjük ragasztott kis üzemeltetési scripteket viszont nagyon nem.

Először meg kell találni az összes AL2 gépet

Tag-ekre nem bízom ezt. A tag azt mondja meg, mit szeretett volna valaki két éve. Az SSM azt mutatja, mi fut ténylegesen most.

aws ssm describe-instance-information \
  --query "InstanceInformationList[?contains(PlatformName, 'Amazon Linux 2')].[InstanceId,ComputerName,PlatformName,PlatformVersion]" \
  --output table

Ha az SSM lefedettség nem teljes, akkor EC2 image adatokból indulok ki:

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query "Reservations[].Instances[].[InstanceId,ImageId,Tags[?Key=='Name']|[0].Value]" \
  --output text | while read id ami name; do
    aws ec2 describe-images \
      --image-ids "$ami" \
      --query "Images[0].[Name,Description]" \
      --output text | sed "s/^/$id $name $ami /"
  done | grep -i 'amzn2\|amazon linux 2'

EKS-nél közvetlenül a node-ok operációs rendszerét nézem:

kubectl get nodes -o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.osImage,KERNEL:.status.nodeInfo.kernelVersion'

Ez a parancs pont azért jó, mert nyers. Ha azt írja, hogy Amazon Linux 2, akkor az a node migrálandó.

Mi romlott el először

Az első teszt migrációm egy kis belső szolgáltatás volt Auto Scaling group mögött. Maga az alkalmazás elindult. A bootstrap script nem.

A régi user data körülbelül ilyen sorokat tartalmazott:

yum install -y jq amazon-cloudwatch-agent python2
service rsyslog restart
pip install awscli

Ez négy sorból három probléma AL2023-on. A dnf az alapértelmezett csomagkezelő, a Python 2 eltűnt, az AWS CLI v2 pedig sok környezetben már eleve az alap. Ha a logolásod rsyslogra épít, azt is érdemes külön ellenőrizni, mert AL2023-on a systemd journal sokkal hangsúlyosabb.

A takarított bootstrap nálam inkább így nézett ki:

#!/usr/bin/env bash
set -euo pipefail

dnf install -y jq amazon-cloudwatch-agent python3-pip
systemctl enable --now amazon-cloudwatch-agent
aws --version

Ez volt az egyszerű eset. A bosszantóbb egy olyan temp fájl workflow volt, ami nagy köztes fájlt írt a /tmp alá. AL2023-on a /tmp tmpfs. Gyors, de kellemetlen, ha az app csendben gigabájtokat pakol oda. Ezt a workloadot áttettem /var/tmp/myapp alá, és kapott egy systemd tmpfiles szabályt.

cat >/etc/tmpfiles.d/myapp.conf <<'EOF'
d /var/tmp/myapp 0750 app app 7d
EOF
systemd-tmpfiles --create /etc/tmpfiles.d/myapp.conf

Terraform rollout EC2 és ASG esetén

Sima EC2 és Auto Scaling group esetén új launch template verziót és instance refresh-t használok. Nincs kézi barkácsolás élő gépeken.

data "aws_ami" "al2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-2023.*-x86_64"]
  }

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = data.aws_ami.al2023.id
  instance_type = "t3.medium"

  user_data = base64encode(templatefile("${path.module}/userdata.sh", {}))
}

resource "aws_autoscaling_group" "app" {
  name                = "app"
  vpc_zone_identifier = var.subnet_ids
  desired_capacity    = 3
  min_size            = 3
  max_size            = 6

  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }

  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 90
      instance_warmup        = 180
    }
  }
}

A refresh-t tudatosan, olyan időablakban indítom, amikor tényleg tudom figyelni:

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name app \
  --preferences MinHealthyPercentage=90,InstanceWarmup=180

A csapda itt a health check. Ha az ASG szerint minden zöld, de a szolgáltatás csak félig állt fel, akkor végig tudsz görgetni egy rossz verziót az egész groupon. Most már rendes readiness endpointot kötök a load balancer target health mögé, és csak utána indítom a refresh-t.

EKS node groupokhoz külön terv kell

EKS-nél biztonságosabb párhuzamos node groupot létrehozni, átterelni a workloadokat, majd törölni a régit. Nem szeretem a meglévő node groupot módosítani, aztán reménykedni, hogy minden szépen lefut.

aws eks describe-nodegroup \
  --cluster-name prod \
  --nodegroup-name workers-al2 \
  --query 'nodegroup.{amiType:amiType,version:version,releaseVersion:releaseVersion}'

Az AL2023 node groupot a szokásos IaC-vel hozom létre. Terraformnál ez többnyire egy második managed node group:

module "eks" {
  source = "terraform-aws-modules/eks/aws"

  eks_managed_node_groups = {
    workers_al2023 = {
      ami_type       = "AL2023_x86_64_STANDARD"
      instance_types = ["m7i.large"]
      min_size       = 2
      desired_size   = 3
      max_size       = 6

      labels = {
        os = "al2023"
      }
    }
  }
}

Miután az új node-ok beléptek a clusterbe, először kézzel cordon és drain egy régi node-on. Csak utána bízom automatizmusra.

kubectl cordon ip-10-0-12-34.eu-central-1.compute.internal
kubectl drain ip-10-0-12-34.eu-central-1.compute.internal \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --grace-period=60

Itt szoktak igazat mondani a DaemonSetek. CNI plugin, log agent, runtime security agent, node exporter, backup sidecar, ezek a szokásos gyanúsítottak. Ami cgroup v1-et feltételez, annak kell egy rendes teszt production előtt.

Az én záró ellenőrző listám

Szándékosan unalmas:

# EC2 inventory ne mutasson több AL2 gépet
aws ssm describe-instance-information \
  --query "InstanceInformationList[?contains(PlatformName, 'Amazon Linux 2')].InstanceId" \
  --output text

# Kubernetes node-ok AL2023-at jelentsenek
kubectl get nodes -o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.osImage'

# Ne maradjon régi AMI ID launch template-ben
aws ec2 describe-launch-template-versions \
  --launch-template-id lt-1234567890abcdef0 \
  --versions '$Latest' \
  --query 'LaunchTemplateVersions[0].LaunchTemplateData.ImageId'

CloudWatchban legalább egy napig nézem a diszk, memória és restart jellegű riasztásokat. Az AL2023 a tesztjeimben gyorsabban bootol, de a gyors boot nem ment meg egy hibás bootstrap scripttől.

Amit sokan alábecsülnek

A nehéz rész nem az AMI ID cseréje. A nehéz rész megtalálni, hol lett a régi operációs rendszerből csendben dokumentálatlan szerződés.

Nálam ezek apró, unalmas dolgok voltak: yum, Python 2, /tmp, rsyslog, saját CIS script, és egy backup agent, amelyet érdekelt a cgroup felépítés. Egyik sem indokolna külön migrációs drámát. Együtt viszont már bőven elég kockázatot jelentettek egy közvetlen cutoverhez.

2026 júniusa elég közel van ahhoz, hogy ne várnék egy nagy migrációs sprintre. Válassz egy ASG-t, egy EKS node groupot vagy egy CI runner poolt, és vidd át most. Az első tíz százalék többet tanít, mint bármelyik tervező spreadsheet.