 Hi everyone, my name is Jeff Lynn Holm, I'm with SUSE, how you doing today? Got a couple people out in the audience. Like thank you for joining us today, hope the sessions are going well, it's a summit for you. Today we're going to be talking about Linux Image Template Maintenance, good ways to build Linux images for mixed cloud environments. I'm a sales engineer with SUSE, my name is Jeff Lynn Holm, I'm from Detroit, Michigan. Today's session is going to be talking about an open source project called Kiwi, which is a part of SUSE Linux Enterprise Server, and the system has been integrated with our SUSE OpenStack cloud environment. For today's demo, we'll go through a really brief overview of what is Kiwi, its use cases, how it works, and then we'll actually show you Kiwi in action. When we ask the question, what is Kiwi? Kiwi is a number of different things. Kiwi ultimately, from a SUSE perspective, is a Linux image build system. In terms of looking at SUSE Enterprise Server 11 and SUSE Enterprise Server 12, the Kiwi image build system has been an integral component of SUSE Enterprise for a number of years. It's GPL software for the open source, it's mostly written in Perl, and it's a cross distribution build environment. Today we can build virtualization images as well as physical images, and the technology itself is actually a component that is underlying of SUSE Studio. If you're familiar with SUSE Studio.com, which we'll look at here in a few moments, it's a web application that will allow you to build custom instances of SUSE Linux Enterprise Server and output those images for a number of different formats. If you're running a mixed cloud environment, you may have KVM hypervisors, you may have XN hypervisor, VMware, or even Hyper-V, other public cloud provider formats. What Kiwi provides is a way to build an image one time and then package it for multiple hypervisor environments. What this ultimately works down to is the ability to build an efficient deployment system in a more DevOps-centric manner. If we look at Kiwi as a central hub for maintaining your appliance images and your templates that are going to be consumed in the cloud environment, the contents of the images can come from a number of different sources. We have the open build service, which is part of a hosted environment out of openSUSE.org that can feed Kiwi images in terms of not only the operating system but also the application wares that are part of the images that you're going to be creating. You may have content distribution systems and content management environments, Git repos, where code is being compiled. You may have different software update repositories related to the operating system. When we assemble these images, it's really combining the operating system, the applications, and the configuration to create an appliance image that can be output in a number of different formats. In terms of the output formats, as I mentioned, we can build all of the virtual machine platforms that were on the previous slide, but we can also build physical instances in terms of looking at physical disk images, custom installation media, and or things like Docker containers. It's quite extensible. So Kiwi, at the end of the day, is a command line tool. The tool itself is used by SUSE Studio and the other graphical build tools that we provide as part of the SUSE Linux Enterprise server distribution. Kiwi will typically be run as root, meaning that it needs access to the package management, user management, and systems configuration subsystems. When you install Kiwi, you really have two different sources available to you. You can go with the version that's included with the SUSE Linux Enterprise server distribution, which SUSE is happy to support for our customers. In terms of building not only SUSE Linux Enterprise server images, but RPM-based Red Hat type images, looking at Fedora, CentOS, or even Red Hat Enterprise Linux, can also build open SUSE images. There are weekly releases and a Git repo available and a number of other help resources that we can overview here in a few minutes as we're wrapping up. So at a high level, when we think about Kiwi and the build process, I mentioned earlier that we can build a consistent image that can be consumed in a number of different areas. So that's one of the two-step process that's used to build the images that we can deliver on that. So what you'll see here is a prepare process where we, in essence, install to a directory structure and then the create step is outputting that root directory, that pseudo root file system into the image environment for whatever consumption mechanism you're looking for. So let's take a look at the demo. To explain what I have here, I have a SUSE OpenStack cloud environment that we'll use for testing the environment. Once I create the images, I also have a SUSE Linux Enterprise Server 12 image. This SUSE Linux Enterprise Server 12 image has the Kiwi packages installed. If you did a zipper SE for Kiwi, what the system will do is show you the packages that are representative of the environment. You need to base Kiwi packages as well as the build templates in order for the environment to function. If you do a Kiwi list, which is minus L, you can see a list of the templates that are available. If we zoom in on this a little bit, making this a little bit bigger, you'll see that we have base templates for the open SUSE environment, the SUSE Linux Enterprise environment, as well as REL 6 and 7. There are a number of other templates available in the open build service repositories as well. If we go to the template locations, you'll see a corresponding directory structure and if I went into the SUSE SLEE 12 juice environment, juice stands for just enough operating system, a very lightweight image, you'll see a couple of configuration files and a directory structure that will be used as part of the boot process. We look at the config XML, what you'll see is that we have a default template that's been put together by the developer that has profiles put together for different types of virtual machines, physical server environments. What you can actually do is copy these default templates to a directory structure that you can customize for your requirements. So if I go to the slash Kiwi directory, and we look at the directory listing here, I have a JLIN home SLEE 12 juice environment, and if we look at this config XML, this one has been customized for my build infrastructure. So the author is listed as me, in this case I'm going to build a KUKAW 2 KVM image that we're going to upload to our OpenStack cloud. You'll notice that from a package manager point of view, the native package management tooling is used, meaning that we're using Zipper on SUSE Linux Enterprise Server 11 and SUSE Linux Enterprise Server 12. Many of the questions that I would typically answer in an auto-yes profile or in our installer are also answered in this profile in terms of looking at localization, time zone, user configuration, just about any aspect of the operating system can be customized within these templates. So I've got a root user configured. For simplicity I did put a password in here, but we can also include a cloud init package that will pull its SSH key infrastructure and its security groups from the cloud infrastructure as the templates are being deployed. You'll also see that I'm picking up different software installation sources. The software repos can be overlaid, meaning that we can have the installation media as well as the updates being taken into account when creating the image. You can also add third party repositories of software with full dependency management. Beyond that, we have selections for what packages are going to be included. And if we start the build process by doing a Kiwi-dash-build, I'm going to go up on level, Jalen Home Sleep 12 juice, and we're going to do a destination of the same directory slash build group. What the system will do is it will start compiling this image. So it's going through and creating the sudo root file system. It's doing the installation to the directory, the build root directory, and phase one is completing at this point. When this is cooking here, we will do a quick switch back to the slides for one second so I can talk to you about the profile templates and provide a little bit of detail on how these work. So as I mentioned earlier, it's a two-step process. We have an image description. You can overlay tarball archives, specific directory structures with other non-RPM software that can be overlaid into the image in terms of injecting third party binaries, configuration files, or executing additional scripting as part of the image creation process. If we look at the configuration tree, the required configuration directive is provided in the config.xml file. The config shell is a file that will be executed when the system is finished building in terms of last-mile scripting. Images.shell will do customization of whatever image flavor you're trying to output, whether it's a VMware image, whether it's a Kukau 2 image or a Zen image. And the archives and root directory structures will actually just overlay into the resulting image. So these details are in the slides. We're happy to make the slides available to anybody who's interested as well. Stop by the booth. Our image is finishing up here in tree cooking show style here. I went ahead and completed this a few minutes before we got started. So the system has finished building. And we have a resulting Kukau 2 image. If I go into the Jlin Home Slee 12 build root directory, this file right here, it's about 290 megabytes, very small file. If we come back to our browser where I have my OpenStack cloud environment, I'm logged into a demo project. And what I can do is upload this image for consumption. So we'll call this SLEZ12 juice. And we're going to point this at an image file. And this is the SLEZ12 juice file. 1 gig of RAM. I'm sorry, 1 gig of disk, 512 megabytes of RAM, public image. We'll let this image upload, at which point the image is available for deployment. You can also upload the image using any of the other typical OpenStack tool sets. If we launch it from the web browser here, we can pick our availability zone, all this SLEZ12 juice. Make this a small instance. And we're going to boot from image. And the system will go through and launch. So it's in the process of provisioning this machine. After it's done spawning, we can pull up the console and let it boot. The other thing I wanted to demonstrate to you that we can take a look at is the building of other Linux distributions within this environment. So again, if I go back to the Kiwi directory where I have my custom templates, when we go into the Jlin home rel7 juice, and we edit the config XML here, this file's a little bit different. This is a base template for rel7. At this point, we're using the package manager YUM, which is the default for Red Hat. To set our time zones, we're specifying what type of image we want to create in the case of a QCOW2 format image. Again, we're specifying a user and package directives, and the system will build. We've already built this image as well. If we upload this and launch it, we could actually take a look at its functionality as well. So we come over here and we open up the console. This is our SLEE12 server that's booted up. And if we just look at that COS release, this is Enterprise 12. So that's interesting. What makes this even more useful is the ability to provision multiple flavors. So if I terminate this instance and upload the rel image, you'll see that we can get that going here as well. So SUSE is supporting mixed hypervisor environments with OpenStack, as well as mixed Linux vendor versions. In this case, I'm going to create a rel7 demo image. Again, this is going to be an image file. Browse out. We'll let that image copy up and we can launch it and take a closer look at that. So as soon as I get this launched, we've got one other small piece of the demo. We'll get finished up with our last five minutes here. So this guy is provisioning. Another tool I'd like to show you as we're finishing up here is a graphical user interface that we've put together for Kiwi as well. How many of you are familiar with SUSE Studio or have seen it previously? See a couple of hands. SUSE Studio is a product that's been in the market from SUSE for a couple of years now. It was brought out with SUSE Linux Enterprise Server 11. What it allows for is a graphical environment either at our website or on-premise with an appliance that allows you to customize your SUSE Linux operating system builds and build custom appliance templates that have embedded application infrastructure. So when we look at an appliance, an appliance from SUSE Studio's point of view is going to include the base operating system at the specified patch level, additional last mile config as well as the application binaries and a pre-compiled image. When we look at the hosted environment at SUSEStudio.com, it has the ability to build SUSE flavored Linux distributions, specifically Open SUSE as well as SUSE Linux Enterprise. There are a number of different templates out there as well as a gallery. In the on-site version, you can publish your own GoldBuild images where you could share those templates with others in your organization and use those as a validated base template from a branch development point of view. We also have direct integration with Amazon EC2, Microsoft Azure, as well as OpenStack Cloud Environments for directly uploading from this web service interface to the image repositories of the respective cloud environments. The other benefit that is provided by SUSE Studio is image reversion management and version cloning, meaning that you can freeze and clone an appliance at any point. There's a prototyping environment that will also allow you to customize the appliances in terms of working with them. So if you go out to SUSEStudio.com, you can log in with your SUSE login account or your Novelli login account, Facebook account, Google account. We authenticate here. You'll see that I'm presented with my home screen here. This service is provided free charge. You can build our enterprise distributions as well as Open SUSE. If you download an image template, you can customize it and then activate it against our customer center for patches. If we look at this OpenStack demo virtual machine, I'll walk you through the configuration dialogue here really quick, getting on the website. Meantime, we'll come back and look at our REL appliance that deployed here. We'll open up the console. So this is our REL7 server. We've got, that's the OS release here. This is definitely REL7. You can overlay the update repositories and third-party software and do the same type of customization at the command line as well. We'll go back to our SUSEStudio side. You'll see that I have some default statistics around the image. It's a 180 megabyte download, 630 megabytes uncompressed in this case. If you follow the wizard here, you can pick and choose what software repositories are added. You can add single RPMs or packages like if I search for the Apache web server here. Scroll down a little bit. Helps if you spell it correctly. It not only adds Apache, but it resolves all the dependencies that are required for Apache to be functional in terms of adding not only Apache, but it's dependent RPMs. We can brand the appliance from a configuration point of view. We can give it default time zone and locales. You can skin it with your own logo, change background color, and ultimately we can create an appliance that can be automatically instrumented with SUSE OpenStack Cloud or SUSE OpenSusa Manager, which is our spacewalk implementation. Once we build the image, we have the ability to test drive it. And if I click test drive within the web browser here, it actually boots it within a virtual environment. And you have the ability to go in and customize this appliance and collect the changes and put them into subsequent image builds. We're building our SUSE OpenStack 2015 image here. What's unique about these images is that they will resize and repartition their disk to take advantage of available space that's been made available to the virtual machine config. They can also be policy managed using SUSE Manager or any of the advanced configuration management frameworks. We'll also go through and do some minor hardware detection when making it RD. The ULA here is optional. Once you have a subscription with us, at which point we can log in and make changes. These changes actually can be collected in this Modified Files tab. So if we log in, I do something simple like editing Etsy host, sync the disk out. If I go to the Modified Files tab here, you've got a complete list of every file that's changed in this appliance since the appliance has been built. I can look at the diff on the file that we just modified in terms of the line that was added. More importantly, this is the line, more importantly, I can collect these files and put them into an archive or actually overlay them into the appliance. By adding the overlay into the appliance, if I come back to the appliance configuration, on the Files tab, you'll see that I now have a host file that we placed at the slash Etsy directory. So at this point, we're getting pretty close to time. Were there any questions? Okay, I really appreciate the 20 minutes we've had here to show you a little bit about Kiwi and SUSE OpenStack Cloud and our infrastructure. We have a booth over in the back. If you guys would like some more information or would like a copy of the slides, I'm definitely gonna be available later today and tomorrow with the booth. Really wanna thank you for your time. Have a good day.