 Hi, everybody. I'm Ann Gentel. This is my colleague, Hart Hoover. And we wanted to talk through what it's like to deploy apps on OpenStack today. And it turns out it's actually a lot of fun. But I thought of something the whole time I was trying to learn all of these things related to cloud deployment. And somehow it was Anthony Bourdain. So he's a famous chef in America. And he's written books and traveled the world. And he tells this great story the first time he ever worked in a real kitchen. And I tell you what, he was really excited watching everyone cook, seeing how great they were. Their movements were very accurate. And they were completely professional in every way. And he accidentally picked up a burning hot pan and got a blister on his finger. And he goes up to the lead cook and says, do you have a band-aid or some salve or something? And the guy was like, what you want a band-aid? And he grabs a searing hot pan, holds it up, puts it back down, and holds up his hand. Blisters, red as can be, this guy was not phased. And so that is kind of what happened to me. While I was trying to learn how to deploy apps on OpenStack, you get some cuts, you get some bruises, you put a band-aid on, or not, and you go on. So anyway, that's my little story. But let me talk about who we are, why we're here. We're both technical product managers at Cisco. I started at Cisco about six months ago. And I've always been in documentation community here in OpenStack. So partially, this is about me going from an OpenStack contributor to more of an OpenStack user. And at and gentle on Twitter. So go ahead and introduce yourself. I'm Hart Hoover. I am also a technical product manager at Cisco. I've been at Cisco about a year. And before that, I was at Rackspace, where I was a user of OpenStack in public cloud, private cloud, everywhere. So it is great to be here. The person I can learn from. And I'm at each Hoover on Twitter. And we're from Texas. And you say y'all, and I don't really say y'all. I say y'all a lot. I said it opening this. I said y'all. I did. So what are we going to talk about today? So we're going to find out what tools work well for app deployment. How do you get better at this? How do you practice deploying? And then what did we learn, including demos? So you can get the slide deck. I uploaded it today. Slideshare.net slash and gentle. It should be the top one. And you can always ask for us at the Cisco stand or even in the cloud apps lounge. We're there too. So what happens when you make the infrastructure boring? I actually think a lot of us have already experienced this. We're like, yes, give me a server already. It's done. And so what happens next? Well, let's play. And let's find out what you can do on OpenStack. So go ahead. Give us some use cases. So some use cases that are common to an OpenStack cloud. There they are. There they are. So what we've seen from our customers and what we've done ourselves, web apps, mobile apps, people using OpenStack for different environments, such as maybe just a dev environment or they're running in production or both. They're using OpenStack to manage their testing environment. It's part of a CI CD pipeline. We have e-commerce customers running your e-commerce environments on OpenStack. We have some media networks and ad networks on OpenStack. We have big data customers. Really, you name it, right? The OpenStack infrastructure lets you run the gamut of whatever you're trying to do. Your imagination is the limit. Yes, exactly. So how do you do this? Well, configuration management is a huge part of this. That's how you have repeatable processes that work every time. And there's a lot of options. So we sort of put them in the categories. If you want to stay within the OpenStack ecosystem only, then you would use orchestration, which is the heat project, and perhaps the application catalog, such as Murano, which are OpenStack projects in the OpenStack community. Now, if you want to use the surrounding ecosystem, you can use Ansible, Chef, Puppet, Cloud in it. All of these are maintained outside of OpenStack governance, but very much work on different infrastructure pieces of OpenStack, right? And what we actually want to demonstrate a little bit of today is how you can use those in combination as well. So what if you take an orchestration template and run an Ansible playbook? So I'm very careful not to say Ansible script. That is inaccurate. So what if you want to make sure it's repeatable? Use a Puppet configuration. You may have things already in-house. How useful is that to you, especially if you already have people trained on Puppet? Well, great. You can just reuse that configuration management knowledge here in the cloud. I keep going the wrong way, sorry. So it's great about orchestration templates in combination with configuration management is that, like it says up here, orchestration templates can automate networking. So if you have a floating IP, private network situation, it's easier to put that in a template and have everything ready when the instance launches. You can pass parameters into your application through configuration management, through heat parameters. And with later releases, heat can control your software deployments for the deployment of your actual app, which we've been waiting for. It's great to be able to take a bunch of resources together, combine it with a configuration management platform so that heat takes care of building the raw things that you need, and then configuration management takes care of building the software on that infrastructure. Right. So of course, the next thing you tend to think of with app deployment is containers. So where do containers fit into the OpenStack community, the OpenStack use case? You can have Docker resources in your orchestration templates, but how many of you have run across that in the greater provider space? Are providers giving us that? We haven't run into a cloud yet that has that. And then you can also, and I think this is awesome, is use it locally, but have the orchestration of the containers, like Docker Swarm, running somewhere else, running by other people. And that's even better, because then I don't have to do all of the really heavy lifting on my little MacBook, right? Like seriously, a lot of times when I run Docker images, my little fan goes, so yeah. But yeah, we haven't really seen a lot of clouds supporting the Docker resource. The Docker resource. So as far as practicing your deployment on an OpenStack cloud, to step one, find an OpenStack cloud. Sometimes this will be a public cloud, like a dream host, a rack space. Sometimes this may be a private cloud that your company is providing you, such as a MetaCloud, Marantus, RPC type cloud environment. Find the services you want to install. So those services, we mean the app itself, your code. Then what infrastructure do you need to run that application? So you need to find heat template examples or just heat templates that will deploy that for you, if it's a standard off-the-shelf app. Or if you're going to combine it with a configuration management platform like Ansible, you could look on Ansible Galaxy. Maybe there's some playbooks or roles on there that will deploy that app for you. And finally, play around, try it out, throw it at the wall, see what sticks, and test, test, test, test, sleep, and then test again to make sure it's until it's right. I think I put the sleep in there because it took me a long time to wrap my head around each piece in part. But I think it's important to find what's interesting to you. If a web app is boring by now, find something else that's more interesting to you. So I run my son has type 1 diabetes. He has a sensor in his arm. I run a Pebble app on my watch to monitor his blood glucose. So it's a super personal use case, right? So that's what I think you also have to think about when you're trying to figure out how to learn this stuff. Now, this was the part that surprised me. You have to get credentials, right? So first of all, we found an Opusat Cloud that will give us credentials. Also, upload a key pair. Not a big deal. I think most developers are going to have a good sense of that. But the thing that really surprised me was that I didn't realize that different cloud providers, depending on how they made their images, might have different OS usernames. So the operating system username on TriStack tends to be Fedora Ubuntu CentOS. There are two clouds at Cisco. One uses cloud for all of the image operating system username. Another one uses cloud-user for all of the operating systems. And so that was kind of a surprise. And so since I'm cloning GitHub repos that I want to deploy, I actually had to upload a GitHub key so that I could authenticate as cloud-user or cloud. And so that just became an extra layer of complexity that I wasn't expecting at all. You also need to find a demo application, right? What do you want to run? So some of these can be web servers, Apache, Nginx, databases. MySQL is on here. It could be a MongoDB type database. You could run etherpad. The point of this is find something you can show off in your company or to peers. That's open source, and everyone kind of understands how it works. But Jekyll and WordPress are on here. Everybody loves to demo WordPress. It was like the Interop demo today was WordPress. But it's a multi-tier app. Everyone knows it by now. I mean, everyone that's awfully elitist of us. But anyway, I also find that you find that people deploy OpenStack because it's truly free open source software. There's a difference between etherpad and etherpad light. You need, when you're just playing around, you're going to probably deploy etherpad light and kind of take what you get, right? And what's great about demo software too that is like this, so these examples is that there's lots of examples out there of other people using heat templates and configuration management that are already kind of set up for you to learn with. And so that's what I started doing was like, OK, what's on GitHub that's current, that's recent? Are there heat template examples? I mean, I'm really lucky to have where I can just ask him daily, like, well, what's the latest on this heat template? Or do you think this one would work for us? Or what might stop me from using this one? I mean, yeah, I think we did that often where I was still looking for, why can't I install the right Ruby manager or Ruby version manager? But there's also, depending again on what's in your company, Chef Cookbooks, Puppet Forge, Ansible Galaxy. And so I think I spent some time looking for this magic incantation that would take care of everything for me. And of course, it's more complicated than that. I had to learn that myself. So some of it doesn't exist for a Liberty Cloud because the projects have moved forward. But we're still doing calls against solid, rock solid eye as clouds. There are some clouds out there that are still Ice House. Right, and we're saying that. I'm probably preaching to the choir. But yeah, I think you guys understand that you have to understand that there could be a couple of years distance between the API that you're using and what you can do today. So some things we found while playing around. Which clouds support orchestration? That's a fun thing to run into. This contrasts kind of well with the interop challenge earlier. Yes. Tri-Stack, for example. No orchestration service. And the error message is super sad. It has Region 1 in it. And that's meaningless except for understanding regions. So that just made me go, oh, we need a better error message. So which CLI tool do you use? Are you using the Python Nova client? Are you using the OpenStack client? Sometimes, based on your role as a user, for example, like admin versus user, the Neutron client may give you better results than the OpenStack client, even though the Neutron client is supposed to be deprecated. Well, and there's a cloud where I have admin access. And I went to list the floating IPs and got everyone's floating IP across all the projects with the OpenStack client. And I literally couldn't figure out how to filter it. So finally, it was a Nova command that brought back a filtered list with only the two floating IPs I could get. And there was no, like, grep for the project ID. No. I mean, I really tried to solve it. And I ended up filing a bug for the OpenStack client because there's admin users everywhere, and I cannot look at 200 floating IPs and pick mine out. You'll run into which version of OpenStack is this particular cloud running? And then within that, which particular version of orchestration is it running? So which resources does this version or this cloud support in heat? Can I use the Docker resource? Can I use things like software config and software deploy to manage my app lifecycle? Or is this heat version kind of so far back that it doesn't have that yet? Yeah. Yeah. And that's not even mentioning microversions where you ask your cloud what version are you at. And we're still working on the API documentation for how do you tell someone that the Compute2 API for Liberty froze at, like, 2.21 for all microversions? And we don't even have a way to display that in the documentation yet. So that's what else we found while playing around. More things we found while playing around. You go ahead with the orchestration-ready images. Yeah. So the images that you get from the one I'm more familiar with is just the Ubuntu cloud image. Doesn't have heat-ready things automatically in it, such as os underscore collect underscore config. You've got to kind of pre-install those as you go. And as you deploy, they're not in every image that you run into across clouds. Some clouds will take images from upstream and put that stuff in there knowing their customers are going to want to run heat-type stuff. And so they're ready to go, but not every cloud. And then this project called Murano, the application catalog, looks so awesome. And we really want that kind of push button, easy button, for our users as well. But I haven't seen it on a cloud provider yet. So where is it? And then, yeah, I guess this one's my story, because I get my entire app deployed, and I cannot access EngineX in any way, shape, or form. And I'm SSH-ing into the server. It's fine. It's fine. EngineX is running. The service is fine. But I launched the instance with the default security group and someone had changed it out from under me, so I had no web traffic whatsoever. So set up your own security group so you know what traffic is in and out, and no one else can change it on you. Basically, they never assume anything. Never assume anything. The classic rule that I didn't, yeah, realize. That's what I found out the hard way. So another good lesson learned we kind of touched on earlier. Containers, it kind of just works. So by that we mean, and I think that's kind of funny just to say that, because Docker has its own issues. But as far as just I want to build a container on my local laptop, I want to make an image out of it and then push it to a swarm that I've built on a cloud somewhere, or deploy to a container service. Yay, that just works so well. Yeah, I mean, someone else had already figured out in a Docker image all the Ruby version management that I needed to know. But I couldn't just resolve it with their image without making their image or something, like some weird work around. So it just took so much less time, though, because the hard part was done, the image with all the dependencies was done. So I also found that I was admin on one cloud and just a plain user on the other. And so that was kind of what I was hinting at with the whole floating IP list debacle. And having to know, am I cloud user or cloud dash user? So that was, it wasn't even, like, I really thought, oh, it's a credentials thing. And so you can get even confused by what the message is telling you, where things just don't work. And it's like, well, of course it's not going to work. You're cloud dash user on this image. You'll never SSH in. And so you end up troubleshooting the SSH, but it's the user name every time. And I also had to do some kind of work arounds, and we'll show this in the demo, of what in my configuration management what user am I acting as. Yeah. I think this is mine, because so here's what I found. I had to learn a lot more Linux than I already had on board because at the bottom of all of these was some shell script that I had to make sure worked. So I found out very early on that I needed to understand what was happening in the user data, what was happening in the scripts. I also found out what a terrible typist I am, so I literally found m1.smell in my script. That's supposed to be small. And I also just didn't realize that it took too much time for me to debug cloud init and the bash script inside of it, plus ansible and the ansible syntax, plus heat and the heat syntax. And how many spaces do I need to indent this correctly? And is there a yaml parser that will tell me it's OK? And I mean, it was just overwhelming at the end of the day. And so this is actually a true screenshot of the kind of conversations I would have with heart. So I'm launching my second stack. Now I get bad router requests. And I changed the cider of the subnet. Nothing else changed. And so do I have to delete the router and then delete a subnet? And then I would try to delete the network. And the network would be like, you can't delete because there's all this stuff connected. Or it's connected. Yeah. So it took me so long to figure out how to reliably repeat my test case every time. And hearts just like, you do this over and over. And I'm like, oh my god, no. Welcome to debugging. You do it until it works. Yes. Yes. Take your developer hat, put it on. All right, so you guys want to see some of the things we made while we were playing around. Let's demo this thing. Yeah. Yeah. All right, yours is first. OK. So I made a heat template that uses Ansible to deploy everyone's favorite game, Minecraft. It's mine. So because conference Wi-Fi is always terrible, I recorded a video. This is on GitHub in Cisco's DevNet organization. So you can see I'm passing parameters to Minecraft via Ansible. I'm also passing parameters. This is heat parameters to my particular cloud to use for Minecraft things. So an image, flavor, the public network UID I'll use for a floating IP address. Then I'll start making resources. So still in the template, make a key, make all my networking stuff, make sure my floating IP is done, create a security group with the right ranges. Finally, it's just a single node. Nothing super fancy. That uses the parameters from earlier. And then it's some bash for cloud in it to actually install Ansible and Python and such. And then get my Ansible code from GitHub also, and then use the parameters I set in heat to pass to Ansible. So turkey out of the oven. Hooray, it's done. Cooking show. Yeah, exactly. Shows all the resources, shows all the parameters, including my SSH key. Don't worry, this is long deleted. Oh yeah, we played a lot of issues. And then it shows all my parameters, what I actually passed to Minecraft, and shows the resources here. Each resource has its own UID, of course. I can click on the server, look at the log. And this is where you can debug your Ansible, make sure it all deployed correctly. Then go back to your parameter screen, grab the IP address, throw it into Minecraft, and then play. Awesome. So it's night, of course. Yeah, that IP address won't work anymore. Darn it. It is running. It's just nighttime. But you're full health, and you're not hungry. It's creative mode. Creative mode. Oh yeah, creative mode. Because you parameterized it. Awesome. So yeah, this is basically deploying Minecraft on OpenStack while playing around. We do that at conferences, so we can demo interesting things. So mine's a little less exciting, but still kind of interesting. So I wanted to be able to run something with Ansible, but show a little bit of a differentiation from Hearts demo, where I'm running it just with Cloud in it and not through a heat template. So I made this Jekyll site. And I've been to all the summits, except for the first one. So I have a bunch of photos on Flickr. And so what I wanted to do is be able to deploy a Jekyll site that would then kind of rotate through these photos that I have from different summits. So I have, and I mean, this is part of the playing around. Do I write it with Cloud in it, which is one particular syntax? And it's hard to see, I know. But you can download them later. Or do I run it as a bash script? And it turns out that I was a little better at debugging a Cloud in it script, like, I don't know why. Bash wasn't always making sense. But I just want to show that it really depends on where your knowledge lives, how to run this. And then the Ansible playbook itself was when I found on Git but then modified for what I was doing so that I could then do my own summit example website. And my video isn't nearly as awesome as Hearts, but oh, I had it for a second. But basically, what I wanted to show is that I could take this Jekyll site and change something small on it. So in this case, it was showing the Hong Kong summit photos. But there's a piece of JavaScript in the Jekyll site that lets me change out to a different Flickr album ID. So I'm going to go grab the Paris album ID off of Flickr and see what pictures come up out of that. It will just pick three pictures out of the album and display them online. So it's kind of dull. That's why we fast forwarded very quickly. But basically, I'm just changing out the album ID so that we can get a different album to display. The idea is that once I have this change, I'm going to upload it to GitHub with a Git push to the GitHub remote. But because I've made this cloud server that also runs something similar to GHPages, basically, which is a Jekyll site, I can also, from after I merge this pull request, I can do a Git push remote staging. And so the staging server is the one running on an OpenStack cloud. And so Git push staging, I think I called it Jekyll staging, gives me the truly running website in the whole nginx running with the right ports open and everything else. So check out the gallery. And I can now get, oh, I flipped them. I can do Paris Summit or the Hong Kong Summit. So that's just kind of a quick way to show this is a way to, because I totally believe in the power of Git for documentation. Like it's amazing. And so that I can just quickly do a staging server for the tech writers to have very easily deploying just by basically giving them a cloud in its script and a link to an Ansible playbook is incredible to me. So that's the doc site example. So, all right, do you want to summer? Sure, in summary, learn tools for deployment. So that is, is that automation for? Various tools. Heat, your config management platform, Docker, whatever you want to use. Make sure you're using cloud ready images. So, most OS providers, OS maintainers have cloud ready images ready to go. You can easily download them and use them. If you're going to use heat or a config management platform, parameterize everything you can. As much as possible, it will make it easier in the long run when you're testing and eventually deploying and maintaining. Get the best of both worlds. Use infra management and configuration management. A lot of configuration management platforms will manage your infra as well. Make sure you're putting those things together and storing them in version control. And I mean, I actually was really impressed with Ansible. Learning Ansible was the most valuable exercise out of this because I still remember when I was like, I can redeploy this while I'm debugging it. And it was amazing. And he's like, welcome to the dark side. I should have captured that. Let me check. We have cookies. I'm converted. Ansible was amazing to use and gave me that long log that I could read through and kind of understand what had happened along the way. And so that's, I think, the sort of commonality between our two demos. But also to show that you can launch it in different ways and keep the configuration management strong, sturdy on top of your infrastructure. And both the demos are on GitHub. And both the demos are on GitHub. GitHub.com slash Cisco DevNet. And you can find Metacloud samples. Yep. And we've also written these up as learning labs. And so that actually shows you step by step how we did each of these. So that you could take your credentials from any open-stat cloud. And you should be able to run these because of the Ansible commonality. So. And that's a half hour of prepared things. Do you guys want to ask us anything? Or do you have any questions? Rant and rave. Talk about your typos. In one smell. In one smell. OK. Well, cool. Come find us at the Cisco booth. A25. Come get stickers. Yep. We have stickers. Thank you for coming.