By default, most Spinnaker users bake AMIs via EBS volumes. However, we've found that faster AMI bake times can be achieved using chroot. In this video, I'll show you how it's done:

If you'd like to learn more about Spinnaker, and Armory Spinnaker in particular, take a look here.

Here's the transcript:

Daniel: Hey, guys. It’s DROdio. We just did a video on enterprise Spinnaker audit logging. And we actually have one more for you. So Ben is going to set this one up as well.

Ben: Yeah. Another problem that we’ve heard from customers is just the baking times within Spinnaker can sometimes be up to 20 minutes or longer. And so Isaac is investigating ways to speed that up.

Isaac: Here you’re looking at a configuration inside of Spinnaker, which does two types of bakes, just on Amazon for now, which are the chroot bakes and then the ebs baking. And the traditional one has been the ebs baking. That’s been around for a while where you stand up an instance. You wait for the SSH port to be open. And then you log into the machine, provision the machine, log back out, and then terminate the machine, or create an image for that machine and then terminate the machine. However, the newer one is this chroot bake which is much faster because you don’t wait for a machine to be stood up and wait for ssh port to be open. Instead, you just create an ebs volume and attach it to an existing machine. So you can have a pool of existing machines up and ready for you to be baking on. And this is much faster than just standing them up on your own. So here you can see that this is the one that’s running here. The chroot bake is already done and took six minutes. And the ebs bake is running at about 13 minutes. It should be done soon. So you can see that it takes off about four to five minutes, maybe sometimes even longer, depending on what operations are taking place inside of the machine.

But since you don’t have to wait, so let me give you an idea of what this looks like. We’ll just start a new bake process here. You can see that it’s starting. I’m going to go into the logs of each one. And we go and see. So here, you can see that this is the chroot log. And it’s creating the volume. And it’s already started work. It’s already doing work. Whereas here, in this one, we’re just waiting. This one is the Amazon ebs volume. And we are waiting for this instance to get up and running and to kind of warm up. So you see I’m refreshing. Nothing is happening. That refresh on the chroot one. And I scroll down. It’s actually doing work and starting to provision the machine so that it can take a snapshot. And this is why it’s so much faster. Even now going back to the ebs volume or the ebs packer script.

Finally, it’s just now thinking about getting started. It’s got to wait for everything to continue to warm up once it has association to the machine. It gives you an idea why it’s so much faster than just using the traditional one.