Как использовать Cloud Init Для подключения неформатированного тома EBS
контекст
Я использую https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin для jenkins, который позволяет мне динамически предоставлять новые облачные экземпляры в качестве ведомых сборок в AWS EC2.
Я запускаю ami-d834aba1
(Amazon Linux 2017.09.1).
Плагин также поддерживает предоставление пользовательских данных и отображение блочных устройств, в настоящее время я предоставляю конфигурацию, подобную этой, после прочтения https://cloudinit.readthedocs.io/en/latest/
Данные пользователя
#cloud-config
repo_update: true
repo_upgrade: all
package_upgrade: true
bootcmd:
- [ cloud-init-per, once, mkfs, -t, ext4, /dev/nvme1n1 ]
fs_setup:
- cmd: mkfs -t %(filesystem)s -L %(label)s %(device)s
label: jenkins
filesystem: 'ext4'
overwrite: false
device: '/dev/nvme1n1'
mounts:
- [ /dev/nvme1n1, /jenkins, "ext4", "defaults,nofail", "0", "2" ]
users:
- default
- name: jenkins
homedir: /jenkins
lock_passwd: true
ssh_authorized_keys:
- a-key
Отображение блочных устройств
/dev/sdd=:100:true:gp2::encrypted
Желаемое поведение
Экземпляр запустится и подключит новый зашифрованный том EBS объемом 100 ГБ, который будет отформатирован как ext4
и установлен в /jenkins
в качестве домашнего каталога пользователя jenkins.
Наблюдаемое поведение
Экземпляр запускается, зашифрованный том EBS объемом 100 ГБ создается и подключается к экземпляру EC2 (отображается как используемый и подключенный в консоли AWS). Тем не мение,
1) df -h
не показывает файловую систему.
2) cat /etc/fstab
/dev/nvme1n1 /jenkins ext4 defaults,nofail,comment=cloudconfig 0 2
действительно показывает это
3) sudo file -s /dev/nvme1n1
/dev/nvme1n1: data
показывает объем как data
отформатированный, а не ext4
4) sudo mount-a не работает из-за того, что файловая система не является ext4.
Ручной взломать
Если я вручную SSH к машине после загрузки и запуска:
sudo mkfs -t ext4 /dev/nvme1n1
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: 7a434f7a-c048-4c3d-8098-b810e2ff8f84
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
затем sudo mount -a
кажется, чтобы смонтировать объем.
Вопросы
Есть ли способ автоматически отформатировать и смонтировать устройство? Я пробовал с и без
bootcmd:
- [ cloud-init-per, once, mkfs, -t, ext4, /dev/nvme1n1 ]
В идеале это должно произойти до того, как пользователь будет создан, поскольку домашний каталог нового пользователя будет находиться на этом новом монтировании.
Если экземпляр остановлен и запущен / перезапущен, я бы не хотел, чтобы в идеале все данные терялись из-за повторного форматирования при загрузке.
5 ответов
cloud-init на Amazon Linux не поддерживает fs_setup
модуль. Следовательно, ваш диск не отформатирован. Кроме того, домашний каталог /jenkins создается для пользователя и используется в качестве точки монтирования. Это скрывает домашний каталог.
Я бы предложил:
bootcmd:
- test -z "$(blkid /dev/nvme1n1)" && mkfs -t ext4 -L jenkins /dev/nvme1n1
- mkdir -p /jenkins
mounts:
- [ "/dev/nvme1n1", "/jenkins", "ext4", "defaults,nofail", "0", "2" ]
runcmd:
- useradd -m -b /jenkins jenkins
Вы можете легко сделать это с помощью скрипта пользовательских данных при запуске экземпляра EC2. Вот пример пользовательского скрипта:
# make a directory for a drive
sudo mkdir /data
# format disk
yes | sudo mkfs.ext4 /dev/sdb
# mount it
sudo mount /dev/sdb /data
# persist
uuid=$(sudo blkid /dev/sdb | sed -n 's/.*UUID=\"\([^\"]*\)\".*/\1/p')
sudo bash -c "echo 'UUID=${uuid} /data ext4 defaults' >> /etc/fstab"
Я не знал, как этого добиться, используя AMI по умолчанию и скрипт инициализации в облаке.
Я решил эту проблему, создав собственный AMI на основе требуемого AMI с зашифрованным томом EBS. Теперь я просто запускаю этот AMI по идентификатору и не беспокоюсь о форматировании EBS, подключении, монтировании и т. Д.
Это проще, требует меньше настроек. Однако, большим недостатком является то, что, когда выходит новый базовый AMI, я не могу просто обновить AMI ID до последней. Мне нужно создать новую базу AMI самостоятельно.
Не идеально, но это работает. Если кто-нибудь знает, как сделать это "правильно", я хотел бы услышать больше об этом.
Волшебный x-systemd.makefs
Параметр fstab можно использовать в cloud-init. Затем модуль монтирования systemd будет автоматически форматироваться в указанную файловую систему (не используйтеauto
) перед монтированием, если на устройстве еще нет файловой системы.
Примечание: установка вручную с помощью mount
не запускает форматирование, но запускается через systemd либо напрямую (systemctl start mnt-foo.mount
) или зависимостью от единиц (см. RequiresMountsFor
в https://www.freedesktop.org/software/systemd/man/systemd.unit.html) работает.
См. https://www.freedesktop.org/software/systemd/man/systemd.mount.html.
Это более чистый способ получитьuuid
без трубопровода кsed
.
blkid /dev/sdxx -S UUID -o value