Changes

<font color= THIS LAB IS 'red'>'''** DO NOT READY YET!!! = PLEASE WAIT UNTIL THE LAB IS PUBLISHED. IT IS CURRENTLY UNDER CONSTRUCTIONUSE - TO BE UPDATED FOR CENTOS 8.0 **'''</font>

In order to experience Fabric's features in a realistic way, we're going to set up several virtual machines. To begin with they are all going to have the same configuration. Please make sure that each VM has direct network connect with other VMs you wish to control and configure.

That should have worked, and you'd get output like this: <pre>$ fab --fabfile= LAB 7 SIGNfabfile.py -OFF H 192.168.56.11 getHostname[192.168.56.11] Executing task 'getHostname'[192.168.56.11] run: whoami[192.168.56.11] out: root[192.168.56.11] out:  [192.168.56.11] run: hostname[192.168.56.11] out: www[192.168.56.11] out:  worker1 Done.Disconnecting from 192.168.56.11... done.</pre> In the above you have:* Lines with an IP address telling you which worker the output is for/from.* Messages from the controller (e.g. "Executing task...", and "run: ...").* Output from the worker ("out: ...")* Output on the controller from your fab file ("worker1" which came from the "print()" call) You should get used to the above. It's a lot of output but it's important to understand where every part is coming from, so you are able to debug problems when they happen. == Part 2: Set up web server == Let's pretend that we needed to deploy a web server on several machines. We'll set up a simple example of such a deployment here. === Install Apache === Add a setupWebServer(SHOW INSTRUCTOR) function to your python file: <source lang="python"># Will set up a working web server with a pre-built websitedef setupWebServer(): run("hostnamectl set-hostname www") run("yum install httpd") run("systemctl enable httpd") run("systemctl start httpd")</source> Note that each call to "run()" will run a command on the worker. In this function we set the hostname of the machine to "www", install Apache, enable the Apache service, and start that service now. Pretty simple commands. If you try to run it the same way as before: <pre>$ fab --fabfile=fabfile.py -H 192.168.56.11 setupWebServer</pre> You'll find that yum prompts you to answer questions, which you don't want to do in an automated environment. And also yum prints too much output, which also isn't helpful in an automated environment. We'Have Ready ll fix it by adding two switches to Show Your Instructoryum:"-y" and "-d1": Notice also that all of the four commands can be run as many times as you want, the result will be the same. This is not always so easy. At this point if you log in to worker1 - you should see a new hostname, and httpd installed and running (try with "systemctl status"). === Deploy a website === Now that we have a web server running, we also want to put a website on it. The website can be of any complexity, but to keep this demonstration simple we'll have a single HTML file. You can pretend that it's as complex as you like. Create an '''index.html'''file like this: <source lang="html"><h1>My fancy web server</h1></source> And since we're pretending that it's a large website with many files and directories, we'll compress it into an archive named '''webcontents.tar.bz2''' using a tar command. You've done this since OPS235. Once you have your archive, make sure it's in the same directory as your fab file. Then add the following to your setupWebServer() function: <source lang="python"> with cd("/var/www/html/"): put("webcontents.tar.bz2", ".") run("tar xvf webcontents.tar.bz2") run("rm webcontents.tar.bz2")</source> There is something weird in the code above that you haven't seen before but it's required for some uses of Fabric: the '''with''' statement. The problem is that separate '''run''' commands each execute in a brand new session, each with its own shell. They are not like separate lines in a single shell script even though they look like they should be. That means if you run a cd command and then a tar command separately - the tar command will not run in the directory where you think it will. In order to fix this you have to nest commands inside a '''with''' - it's like a '''run''' but with persistant results. The code we added to the function will cd to the default web site directory on the worker, upload your web contents tarball from your controller to that directory on the worker, extract it, and delete the tarball. After it's done - you should have a working web server and simple website on your worker1. Except you won't be able to access it because of the firewall. We'll deal with that in the next section. == Part 2: Set up the firewall == Recall that in our OPS courses we've been using iptables instead of firewalld, which is installed by default in CentOS. Let's make sure that our workers have that set up as well. In the same '''fabfile.py''' you've been using all along, add a new function like this: <source lang="python"># Will uninstall firewalld and replace it with iptablesdef setupFirewall(): run("yum -y -d1 remove firewalld") run("yum -y -d1 install iptables-services") run("systemctl enable iptables") run("systemctl start iptables")</source> That should by now look prett obvious. On the worker you're going to uninstall firewalld, install iptables, and make sure that the iptables service is running. Execute the function for worker1 and double-check that it worked. === Allow access to Apache through the firewall === The default setup of iptables also doesn't allow access to our web server. We'll need to add some more to our function to allow it. This would probably make more sense in setupWebServer() but for now let's put it into setupFirewall(): <source lang="python"> run("iptables -I INPUT -p tcp --dport 80 -j ACCEPT") run("iptables-save > /etc/sysconfig/iptables")</source> Easy enough, but there's on problem - if we run this more than once, we're going to end up with duplicate iptables rules for port 80 (check with iptables -L). In order to avoid that - we have to first check whether the rule exists before we add it. We can do that like this: <source lang="bash">iptables -C INPUT -p tcp --dport 80 -j ACCEPT"</source> Unfortunately that command answers "yes" or "no" by succeeding or failing depending on whether that rule exists. In Fabric when a command fails - the entire fab file execution stops, assuming that it's an unrecoverable error. We need to prevent that with another with statement: <source lang="python"> with settings(warn_only=True): firewallAlreadySetUp = run("iptables -C INPUT -p tcp --dport 80 -j ACCEPT") if firewallAlreadySetUp.return_code == 1: ... move your iptables rules setup here ...</source> Test your new setupFirewall function on worker1, and make sure it opens access to Apache but does not create duplicate rules every time it's run. = INVESTIGATION 3: Multiplying your work = After completing all the previous parts of the lab - you should have a working fabfile.py with two working functions: setupFirewall() and setupWebServer(). You were asked to test them on worker1. Now let's run these two functions on all your workers at the same time. The command is almost the same, except for the list of IP addresses: <source lang="bash">fab --fabfile=fabfile.py -H 192.168.56.11,192.168.56.12,192.168.56.13,192.168.56.14,192.168.56.15 setupWebServer</source> Again - your IP addresses will be different but the command will be the same. You can also reconfigure the firewall on all the workers at the same time, using a command like this on your controller: <source lang="bash">fab --fabfile=fabfile.py -H 192.168.56.11,192.168.56.12,192.168.56.13,192.168.56.14,192.168.56.15 setupFirewall</source>