0

I'm running EC2 EBS images on instances with instance stores on /dev/xvdb and /dev/xvdc. I have managed to create a script to raid these two drives on first boot and mount them as /mnt. What I really want to do is raid them, copy over the EBS /var, and then mount them as /var. I'm assuming that I'll need to do this in the ram disk image during early boot. I'm quite out of touch with systemd and boot order - I last got dirty with building ram disks in 2009. What is the "proper" way to integrate a script that runs during the first boot and does the necessary setup?

Don't want to use cloud-init. Its slow and poorly documented. And certainly happens to late in the boot process.

jamie
  • 101
  • 2

1 Answers1

0

In EC2 you should take a look at cloudinit (https://help.ubuntu.com/community/CloudInit) and the user-data (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html). With this you're able to provide scripts which will run during the instance launch based on data you can send to the AWS API.

But besides that: Why are you doing a RAID and copy over data from the boot volume to the RAID on launch? Without knowing your exact use case but that sounds wrong ;-) Maybe you can elaborate more on this so we're able to actually provide a better solution without the need of doing launch scripts and so.

Osterjour
  • 845
  • 8
  • 12
  • I'm running on instances with 2 or more large SSD instance stores. If this were in a datacenter, /var would be on these drives. /var is where docker images, log files, and other noisy things live. Putting /var on the local SSDs therefore seems like a good idea. In the old days, /var would be its own partition, and be rw, while the rest of root would go ro. – jamie Aug 04 '16 at 02:00
  • Oh now I get it - you want to use the instance storage for the data which you have on the EBS volumes (sorry, I didn't really get that). That's actually a hard thing to do imho, especially if you don't want to work with cloud-init. – Osterjour Aug 04 '16 at 12:38