Real-Life Playbook: Mattermost Deployment

A free video tutorial from Packt Publishing
Tech Knowledge in Motion
Rating: 3.9 out of 5Instructor rating
1,262 courses
401,232 students
Real-Life Playbook: Mattermost Deployment

Lecture description

In this video, you'll see a real-life web application deployment. We'll be setting up Mattermost, an open-source alternative to the popular Slack team-chat application.

Learn more from the full course

Learning Path: Automation with Ansible, Puppet, and Salt

Use popular automation tools for a scalable, reliable, and secure IT environment.

13:55:42 of on-demand video • Updated May 2018

Configure and manage your infrastructure using Ansible Playbooks
Create task blocks and choose the right Ansible Strategy for the job
Understand the nuances of Ansible 2 and its new features
Write efficient, reusable, and modularized Puppet code
Write extensive tests for the code and run automated builds using Jenkins Integration
Create a pipeline for effective code management
Understand Salt’s state system and write and manage complex states
Use and react to real-time events across an infrastructure
English [Auto]
OK in this video we're going to be doing something really fun and that is taking a look at our first real life project. We're going to be deploying matter most matter most is something that's similar to slack or hip chat. Basically a team communication application where you can have group chat one on one chat image video file and document sharing. And the really nice thing about it is that it's open source and self-hosted. We're going to be deploying this as a single host web application with the web front end and the database back end on a single target host. But because of ansible rules this is split into a multi tier deployment with just a couple of variable changes. So here's what you'll be setting up when you're done. This is the lived in view of a tutorial and X group the different channels here direct messages and private groups available and just good old chat app I really enjoy using matter most and actually recommend it for small teams. And I used to think very similar for a company that has 260 employees and it still works very well for day to day communication. So this is the finished product essentially which will be setting up without further ado let's jump in. I've created some containers here you can see matter most to follow along with this lesson. You can just grab the set of matter most mark down cheat sheet in the cheat sheets directory. So what we'll do now is we'll just prepare all three hosts quickly and then jump into the rest of this lesson. So we're sitting here in the simple playbook examples directory and this is where our prepare ansible target playbook is because of a bug in Ansible right now. Some of the Adding servers to known hosts is not possible and willing to do that manually so will actually just connect quickly to all three of these hosts before running the first playbook. So we'll say S-sh going to hear Taipan Yes this is the part that we need. We actually don't even need to log in and we just need to add that to that same thing again. And the same thing for the third one. By the time you see this it's almost certain that this is not going to be an issue anymore. This is a regression. I saw that this was a bug in an earlier version of ansible and Teske Teske it's come back which means there was not adequate testing. It's totally normal for software though. So ansible is certainly no different than other automation or configuration management software. It's a bit of a younger project. So this kind of thing can happen a little more frequently than I'd like but I think it's still the most powerful option out there. I spend a lot of time with Chef day to day and I've spent a lot of time with it in the past and I would still choose ansible even if it's being a little bit unstable having a minor version in real life he would simply stick with a stable version until you're ready to move on but to keep this course up to date. I've just I'm using the most current version which is two to zero. So the next thing we've got to do is add our target hosts to an inventory. So I'm just going to them in and I'm going to add my hosts here. 1 12 1 5 8. And save that and we are ready to run with this playbook. So here's the command we're going to run into the playbook obviously. And then the playbook name when we've got the K or ask pass. Ask S-sh pass option and then unfortunately I've had to add ask souly pass. This is the bug I was talking about before. Normally the case should be enough and that that same password should be used for soup but it's not tried to do in the current version. I've done some reading on this that should be fixed soon. Passing it an inventory file. The one we just create so that contains our three new host. So I'm doing the same buntu password twice here because of this bug. If you're using a different version of ansible it's likely that you simply won't need to use this asks you to pass a flag and you'll just need to enter a single message password. You can see here this is the prepare Aspel target playbook and one of the things I'm doing is just an apt get update and upgrade. In production I would obviously recommend always starting with uptodate software on your machines. But this is going to take a while. So what you can do for yourself is just comment this out temporarily. The other things will do here are update packages. Installing Python 2 as before setting are authorized key as before with just the user that runs the ansible playbook there. Id say cloche we're setting up some environment variables just language and locale and the we're generating and reconfiguring locales. This is going to help us with a software install that requires those things to be set later and through the magic of movies we are done. So we've updated packages and upgraded packages and all of these machines installed Python to put our key into authorized keys set up our environment generated and reconfigured locales and were done from here we're going to change directory into our two playbooks to install mattered most. Install most outermost directory. This is the playbook director for installing matter mosts. They're going to edit the posts here as well and include those same three hosts in your case it'll be either one or two hosts in our case. This will just be one single host 10 0 3 1:12. The first thing you'll do when you start looking at a playbook is check out the group vars all file. It's a good practice to write down what the playbook expects for our case here. We expect one database server and one or more web servers. That's in the hosts file. We're using a single server deployment on a single Schene so we're fine there. The first thing we want to set is our domain. We're going to disable SSL mode for matter most. I've left a note here. Basically if you're doing a single server install we're not using SSL to connect to the database because it's all going to be all localhost. Which leads us into localhost. Since we're doing a single server deployment we're just going to run our database on local hosts if we're not doing this then what you would do is uncomment the DBI server line above and this is going to go ahead and set your database server to be the first database server's IP address I'm not supporting read replicas or anything crazy here it's just expecting a single database server. Hence the warning above in the what this playbook expects. So go ahead and leave this uncommented our Postgres version is 9 3 to check which postgresql version you're going to install. You could simply type in something like cache policy postgresql you know you can see that on my machine here. That would be 9 3. There are some other variables set here. But we can worry about those later. I can bump this because it's actually just released a new version so this will automatically download that new version now. So that's pretty much all you need to know right now. Just going to jump right in. Again this would be a nice simple command ansible playbook install matter mosts and then just the inventory file hostes you'll be asked for your key for each log in. So you'll have to type that in twice. And there it goes. Once this is done we'll just read through what's been done and then we'll verify that the applications are actually working. And then we'll work our way through the playbook piece by piece. OK we're done here. Let's have a look at what just happened. So this is where we start the playbook and the first play is our database setup. So we go ahead and enter that connect to the first host. We're running the common roll right now on this host. We're installing a couple of pieces of software that were running the database role in installing our packages that we need to run a database. We're creating an actual database and a database user to use for the application. Then we're cleaning up privileges a little bit for that user. And you can see that we're actually skipping two tasks here. This is allowing connections from external web server so not locally on this machine. And we are also not configuring this to listen on all IPs post-crisis clever and ships with a secure default configuration. It's not listening for external connections and it's not listening on any IPs. If you were doing a multi machine deployment if you change those variables I talked about in the beginning this would actually run and via's those things would be enabled because the required for two machines to talk to each other. So that's the end of our database play and we go into the web server set up play here we see the basic package install again now because this is not a split deployment but on a single host it actually checks twice because that common rule is applied to both groups web server and database hosts. This machine is playing both right now. That's one of the ways you can see how this stuff is applied in a perfectly straightforward deterministic manner. No surprises. And that's one of the ways that it's so easy to split things up once you've got them divided into roles you can say sure both of these roles will be played on a single server or. Each role gets its own machine. Once that's done we add the engine X personal package archive and install our engine X web server software. We remove the default hosts that it ships with. We configure a new virtual host for matter most our application. We make sure that edit I was running and able it this is actually done by the package install I believe. So it's already okay nothing had to change. We create a system user for our applications is just a good practice. Then we actually go and download the application. So this is a tar GZ file. We download it on archive it rename the downloaded directory do some application manging renaming things cleaning things up. We set up a config file format of most Mitra permissions or write check whether we're using System D or upstart. You can expand this to check for this 5 and it on another platform as well. We're skipping the system to unit cloud creation because these containers are 4000 for machines which are still using upstart. You're doing this on a web server out in the wild it's likely that you're using a new enough distribution. They've probably already integrated system. That's your init. In that case this would run and this one would be Skipton but we're creating an upstart in it file and then running the service and enabling that so little started. But now finally we reload engine X and restart matter most because config files have changed. Those are our handlers right. Running deferred at the end. In the next video we're going to be walking through the playbook code that actually just made all of this work. So I'll show you the.