Amazon EC2: обновление ядра linux в AMI

Одним из первых вопросов системных администраторов, которые начинают работать с сервисами Amazon, является: "а как обновить ядро в моем инстансе?".

До сравнительно недавнего времени ответ был один: "никак". Точнее, ядро можно было сменить, но только на одно из предоставляемых Amazon. Однако, ничто не стоит на месте. Появилось сразу два решения этой проблемы.

Первое: Амазон выпустил свой Amazon Linux (на базе RedHat Linux, но с массой изменений, в частности, kernel версии 3.х.х). В случае использования этого дистрибутива, проблемы нет вообще: обычное обновление инстанса через обычный yum с репозитариев Amazon.

Второе: Amazon наконец-то позволил обновлять ядра и сторонних дистрибутивов. Правда, не для запущенного инстанса, а для AMI, но все равно - это уже намного лучше, чем было. По крайней мере, если очень нужно, то можно сделать, хоть и с бОльшими трудозатратами.

Вот про этот второй способ я и расскажу.


Для начала нужно пояснить, что Amazon предлагает в качестве виртуальных дисков два типа стораджа: Instance Store (IS) и Elastic Block Store (EBS). Строго говоря, можно запустить инстанс и с дисков на S3 storage, но я в своей практике это не использую и поэтому пропущу этот вариант.

Для каждого из вариантов используется свой метод обновления linux kernel (и создавать AMI нужно для каждого свой, они не взаимозаменяемы!).

INSTANCE STORE AMI
Алгоритм следующий:

1. Запускаем новый инстанс, с любой "заготовки" (AMI), которая доступна


2. Логинимся в запущенную систему, производим доустановку необходимого ПО, настройку и т.д.


3. Обновляем ядро общепринятым методом, например командой
   # yum install kernel
   ВАЖНО Ядро должно быть xen-совместимым, как. например, ядро CentOS 5 kernel-xen


4. редактируем /boot/grub/menu.lst, и изменяем старые названия vmlinux и initrd на новые (которые появились после установки нового ядра)


5. удаляем и чистим логи, ключи, лишних пользователей, историю команд и т.д., т.е. все, что нам не нужно в новой ВМ.


6. копируем амазоновские ключи локально, например, в /root/certs (они понадобятся для подписи образа и регистрации новой AMI)


7. создаем временный каталог на ephemeral устройстве
   # mkdir /media/ephemeral0/tmp


8. формируем образ диска:
   # ec2-bundle-vol -r x86_64 -d /media/ephemeral0/tmp -p CL-64-CentOS-5.8 -u 373682980683 --kernel aki-88aa75e1 -k certs/pk.pem -c certs/cert.pem -e /media,/root/.ssh,/root/certs
   Параметр --kernel указывает на соответствующий AKI (Amazon kernel image), содержащий pv-grub. Правильное имя aki нужно выбрать из списка, предоставленного в документации Amazon. Следует использовать AKI с -hd0 в имени (НЕ hd00)


9. выгружаем образ на S3 сторадж:
   ec2-upload-bundle -b my-amis -a -s -m /media/ephemeral0/tmp/CL-64-CentOS-5.8.manifest.xml


10. регистрируем новую AMI:
    # ec2-register -K certs/pk.pem -C certs/cert.pem my-amis/CL-64-CentOS-5.8.manifest.xml --name CL-64-CentOS-5.8-IS

Таким образом мы создаем новую AMI на Instanse store. И неважно, на каком сторадже исходная AMI. Таким образом можно также "конвертировать" готовые EBS AMI. Разумеется, не следует забывать о лимите в 10Gb диска для Instance store AMI.

EBS AMI

Однако, IS AMI не всегда подходят по той или иной причине. Поэтому приступим к созданию EBS AMI.

1. Запускаем новый инстанс. Удобно использовать инстанс уже с обновленным ядром, который мы создали на предыдущем этапе. Но, в принципе, особой необходимости в этом нет, просто придется повторить этапы 1,2,3,5.


2. создаем новый EBS диск нужного размера и приаттачиваем его к запущенному инстансу, в котором появится новое дисковое устройство (например, /dev/sdf )


3. Создаем раздел (например, при помощи fdisk) на новом устройстве и форматируем его (обычно ext3). Важный момент - раздел необходимо создать обязательно, это связано с ограничениями Amazon. Если нужно, создаем там же и swap (я swap не использую, т.к. скорость доступа к дисковым EBS устройствам оставляет желать лучшего)


4. отключаем проверку диска по количеству монтирований (себе же потом меньше проблем будет :) ):
   # tune2fs -c0 /dev/sdf1


5. если для монтирования разделов используются метки (label), не забываем выставить правильную метку на рут-раздел при помощи e2label. Или же на заключительных этапах нужно будет поправить fstab и menu.lst и прописать правильные имена устройств (/dev/sda1)


6. монтируем свежеотформатированный раздел куда-нибудь (например, в /mnt/target )


7. копируем файлы текущей OS на новый раздел:
   # rsync -avHx / /mnt/target
   Копировать /dev, /proc и /sys нет необходимости, оно создадутся самостоятельно при создании инстанса из новой AMI


8. подчищаем копию системы на /dev/sdf1. Удаляем ключи, историю, логи, домашние каталоги пользователей и т.д.


9. редактируем /boot/grub/menu.lst. Изменяем строчку root(hd0) на root(hd0,0). При необходимости, правим имя устройства корневого раздела (и заодно правим fstab)


10. # sync; sync && umount /mnt/target


11. отключаем EBS том от текущего инстанса. Инстанс останавливать не стоит, если где-то допущена ошибка, потом можно снова подключить том и, поправив ошибку, снова создать AMI


12. создаем снапшот тома


13. регистрируем снапшот как новую AMI:
    ec2-register -b "/dev/sda=::false" -b "/dev/sdb=ephemeral0" -n "CL-64-CentOS-5.8-ebs" -d"CentOS 5.8 EBS" -a x86_64 --kernel aki-b4aa75dd -K /root/certs/pk.pem -C /root/certs/cert.pem
    Правильное имя aki нужно выбрать из списка, предоставленного в документации Amazon. Следует использовать AKI с -hd00 в имени

Вот, собственно, и все. Создаем новый инстанс и радуемся обновленному ядру.