LXD and Ansible

hello i'm stephan greber i'm the project here for lxd and today i'd like to take a look at third party intel third party integrations with flexty specifically for this video we're gonna be looking at ansible ansible is probably the most common devops tool these days it can be used to deploy and manage and some extent maintain workloads across many um many different systems on many different operating systems and linux distributions and and has a lot of different plugins to to maintain a lot of different things in the case of flex d there are four plugins that interact with lexi one is a connection plugin so effectively an alternative to ssh which uses the lxd api to access instances and run commands or transfer files in and out of them then there is a plugin that connects with lexi and pulls the list of all instances into the ansible inventory there's also a plugin that lets you create delete and update configuration for xd containers and lastly a plugin that lets you update lexi profiles from ansible for this video i'm just going to be focusing on the first one it's because it's possibly the most basic but also the the the most feature complete of the bunch it's the other three in my experience don't currently deal with a lot of the things i like to use in my demos they don't really support projects they don't play super well with remotes was the first one works just fine so gonna be focusing on that and seeing kind of you know what's possible with it at this point so switching over to a terminal i'm in an empty directory on a system on my local system what we need to do here is uh actually one first create a few instances that can be used from ansible and then setup and symbol to to deploy something on them so i'm in an mtlxd project so i'm just going to be launching two instances one is going to be an ubuntu 2004 container called c1 and the other will be a virtual machine also ubuntu 24. so going down v1 all right um now the best one depending on the version of ansible you you might be running uh you may need to refresh the community general plugin which includes the connection plugin for xt that's because specifically remotes and projects have only been added to ensembl about a year ago and some linux distributions the one i'm using here included can be a tiny bit behind and so need an update for that you can use ansible galaxy and then do an install of community.general because it's bundled with ansible you actually need to do f4 so that it will redownload it and download the latest version of it that doesn't take particularly long and after that regardless of the version of principle you might be running you're gonna have the latest version of all the general plugins in this case version 4.0 which is gonna be in for this particular demo including all we need for xd all right so back to rmt directory the first thing i'm going to be doing is create an ansible.config file and in there i'm going to be specifying that i want my inventory to be hosts.yaml this will get ansible to look at the host.jml file within that directory instead of looking for itsy and subal host's ini file as it would by default i'm not super fond of ansible having system wide configuration like that i much prefer having everything in the same directory which is why i'm doing doing it this way i also prefer the yaml format for the um for the inventory it's easier to to make a tree of groups that makes sense to me so i'm going to be creating that file now and just create a basic tree so starting at all and then applying some variables that will apply to everything inside of this deployment so ansible connection this overrides the uh default connection plugin available which is normally ssh and tells it to use text instead now because lexi exec will always get you root there's no point in ansible assuming it's going to be a different user and lastly because it's always roots there's no point in using sudo to become root so that's what that config does then let's add some children so we're going to be creating one child node called local for the the local containers and some more variables there so there's ansible lexi remote and we want to use the default remote the local remote and then ansible next a project and in this case my project is called demo and then defining the instances we've got c1 we won and that's it saving not ansible inventory dash dash 3 should show us oops sorry not 3 graph will show us that local group with c1 and v1 inside it okay now we need to actually have something to deploy so let's let's create a playbook let's call it demo.yaml with a play called setup apache which will run on everything and has a couple of tasks the first one would be install the apache package this is going to be done through apps the package is called about sheet2 and we want it to be in the state present and then make sure a battery is running and it's going to be done through systemday the unit is called apache2.service and the state we'd like it to be in is started save that and then ansible playbook with the file and i'm going to be limiting it to just that local group right now that's the only thing i've got in my inventory but that might be that kind of shows how to restrict the the scope of the deployment so it first once in both instances and fetched some system information like network network information um what was it running a bunch of other things to put that into the the facts that are then exposed to ansible plays and plugins and then it deployed a battery and make sure it's running and we're done so if we go inside of c1 you can see that she's running here and going into v1 process this is a bit longer because it's a virtual machine but same thing apache can be seen as running in this instance that's pretty much the basic for just deploying a service and making sure it's running um against legacy insurance of all no need to like create sage keys or stop any of that stuff it just works uh so long as you've got the lxc command line tool configured to to access the right thing everything just works out now to look at interacting with remote xd systems i've got a raspberry pi here which i'll quickly configure so let's just do standalone everything so just enter for pretty much everything except the question asking whether we wanted to use a network because we do need it on the network so just pick the defaults there enter a password and we're done now i need the ip address and i need to add it to my call system okay with that done i can now do i can remotely list what's running on it which is nothing and now let's get a couple of instances on there so let's create our pi c2 as ubuntu 224 so that's going to be still ubuntu 2204 but this time running on arm 64-bit and then to change things up a bit with the last instance gonna be using debian buster also on the raspberry pi 64-bit so debian buster you might call c3 there's one small catch with the debian instances which is that they don't they don't include python 3 out of the box so that needs to be that needs to be added prior to being able to use the instrumentable otherwise ansible will fail so just go in the instance with elexy exec and then install python3 give it a few seconds to install and then we'll be all set all right and running the playbook again so if i run with local it's just going to be checking the existing two instances and not not see anything interesting okay here we go but now we can go and add the raspberry pi to the inventory so i'm going to be doing a new node here called rpi in the variables it's going to be going and adding remote rpi there's no need to add the project because it's in the default project i'm just having c2 and c3 that way again if i just run against local it's only going to be selecting those two and there's not going to be anything new going on but now if i run against arpai it's gonna be remotely talking to that legacy to similarly install apache now in both of those instances and then making sure they're running obviously ansible can do far far more than this um you can also within the same playbook specify um what should run on what groups you could totally have a single playbook that runs against both debian based systems and red based systems and just the right package manager and do the right thing everywhere in there or even skipping some tasks for some specific groups or that kind of stuff but this is not meant to be like a full demo of ansible's capabilities but just how ansible can interact with xd and just how easy it is to to deploy in this case a battery on top of lexi instances driven through ansible on a remote system okay but she is installed in both of them so that they should just be running out of the box yeah we're good and now i can also run without the restriction which will actually run against all four and just making sure that they're all uh behaving so you can see that the local sim goes slightly faster not necessarily because it's local but just because it's faster than it's very high and yeah everything is all nice and clean i can go check on the raspberry pi that both of the instances do in fact run a battery but similar to what was done locally that's going to be the case and that's it that's a look at and how it works with ansible again this is just one of four different plugins um if you are managing your local system the other three plugins might work really well for you uh and i'm hoping they're gonna be evolving in a similar way as the connection plugin and will be more use usable for those of us with with remote servers and projects it's just a more complex lxd environment this web page on our website on broadband integrations also includes a number of other tools that lexi has a direct has integrations with so you might want to go through that and see whether your tool of choice is on the list and how that works or maybe you are missing some of the tools that are that support xd in which case uh either contribute directly to your website by sending a support request or letting us know in the comments here or on our forum similarly if you if you need any help with those in general uh because it's those but party tools integrating with flex day rather than rather than the other way around you tend to be better served by directly reaching out to those communities rather than done to us um but like we're always happy to to help artists give a few pointers when we can um for those users um directly on our forum or here in the comment section i hope this was useful to you and see you in the next video thanks

Channel: LXD

Views: 513

Keywords: lxc, lxd, containers, linux, virtual-machines, devops, Ansible

Id: 3ROBfRKSiI8

Length: 14min 18sec (858 seconds)

Published: Thu Nov 04 2021