So, let's get started. This talk is about how we can improve the monitoring and observability for Kubernetes using the open source tools. My name is Nilesh. I've been an enterprise architect for one of the leading bank here in Singapore and I'm also what they call as Microsoft's most valuable professional or MVP for last six years. And recently for my contributions to the Docker community, I was also awarded with the Docker captain recognition. You can find me on various social media, I put the links here and also a link to my YouTube channel where I talk about Kubernetes and various cloud native stuff. Let's get started with today's talk. Has anybody seen this iceberg picture related to Kubernetes before? So, if you're seeing this for the first time, maybe you can't see it right at the back. What it talks about is the different layers of different tools, technologies and information that is required when you start working with Kubernetes and when you want to make it like a production grade Kubernetes. So starting from the top, it's very easy to start with creating a deployment, getting your servers up and running and having multiple replicas, having a config map. But as you go down the different layers, your complexity keeps increasing. So it becomes very difficult or it is quite challenging for even a experienced Kubernetes administrator or a developer to manage things like stateful services, then having custom resource definitions and advanced things. And it's a very challenging aspect which most of the companies, they find when they start running Kubernetes in production. So how do we handle this? One way is to look at what CNCF provides in terms of some sort of guidance and these are some of the tools and technologies which they have published on what they call as the trail map. So if you are new to CNCF, these are some of the projects which have matured and these are some of the things you can start based on different things like containerization, CI-CD, looking at observability. Then we have the service discovery, networking, various things. This is good way to start. And then they also have these different landscapes. What I've taken here is just a landscape related to the observability part.  It talks about databases and various other things which the different CNCF projects are running or what are the different projects available in each of these categories. So we'll focus today in this discussion more on the observability landscape. And sometime back, this is almost like four years old now. There was also a CNCF observability radar which was created. I haven't found the updated version of this, but at that point in time, if you have heard about the technology radar which is published by ThoughtWorks, this is on the similar lines where CNCF gives its views about what you can adopt, what you should trial, what you should assess based on the maturity of the projects and what state those projects are in. So obviously over the last four years, these different projects which are listed here, they have gone through different phases and some of them would have gone from adopt to or some of them would have gone from trial to adopt space. So we heard about this in the morning sessions as well, the three pillars of observability starting with logs, matrix and traces. And that is what we will see in this session as well, how we can use open source tools to incorporate these three things with Kubernetes. Let's start with centralized logging and try to understand why do we need centralized logging. Now when we build cloud native applications, there are different aspects where we need centralized logging and there is a need to have centralized logging. Let's focus first on the container based applications. We might need logs which are application specific. I come from banking background and in many industries we need to retain the logs for a period of time, like six years, seven years, ten years, depending on the regulators. If we use the default logging mechanism, these logs are not available for this much duration. So we need to retain these logs for a longer period of time. That is one aspect. The other one is workloads which are scheduled on different nodes during the application restarts and updates. Traditionally when we were using, let's say, three tier applications, it was quite easy to just take the logs and store it in one central place or take a backup and archive them somewhere. But with cloud native applications, they are very dynamic in nature. We might enable auto scaling, we might have, we saw in the previous demo where K native was used to dynamically scale the number of instances. In such cases, if the node where your application was running and due to some reason the workload gets scheduled to a different node, then there is a potential that you might lose those logs. You might not have them after a certain period of time. In terms of Kubernetes infrastructure itself, some cloud providers, when you do the upgrade, they don't do an in place upgrade. They just replace your node with a different node and they drain the earlier node and they shift the workload to the new node. Now in this case again, if you lost the earlier node, your logs are gone. If we are talking of past services, not just Kubernetes based or container based, we also lose the control over where and how we store the logs. Things like when we use infrastructure as a service or platform as a service from cloud provider. We have very little control over where those logs are stored. We might just get a service to say, okay, you can fetch your logs from here. We don't have a finer control like that we have in our data centers. So these are some of the reasons why we need centralized logging. And if you've heard about this concept called or these patterns or recommendations called 12-factor app, centralized logging is one of the recommended practice there. This has been replaced or upgraded with 15-factor apps. But what it essentially says is you should treat your logs as a stream of logs instead of storing them physically on a machine or somewhere you should stream them and then as part of your infrastructure components store them in a centralized location. So in this example, I'm going to use a demo which is like financial services application which has got five different microservices running. There is a backend service, there is a account service, there is authentication service, a forex service, and a transaction service. And all these services, they write logs to a collector, which is Loki. Loki is again a open source project which does the log aggregation. And then I'm using open telemetry collector to write this logs onto the Prometheus and to visualize the logs, I'll be using Grafana. So let's go into a demo of this and see how this works. So here I have a postman which I will use to generate some workload. So I have this backend service which acts as an entry point for all these different microservices and it runs different calls to these other dependent services. So if you have used postman, I like one of these feature of postman which I can use like collections to generate different kinds of requests. I can send different post requests, get calls, and I can even call the Prometheus endpoints here. And then I can say how many iterations this has to run. And I can also specify some delay in microseconds. So here I'm going to run this for 500 iterations. And you can see that the numbers are going on here and also what is the response. So this particular collection has calls which are going through as normal calls. And there's also a failure call there to simulate some failures. So you can see most of the responses are 200. But there is also a 404 error which is thrown by one of the API calls. Now if I go into the Grafana dashboard here, I have a connection to Loki and Loki is the log aggregator. So it collects these logs from all these services and publishes it to Grafana. I can use Grafana to visualize. And here you can see that I have a filter for the back end service. The name of that service or a label associated with that service is back end service deployment. And below here you can see the heat map of how the logs are generated. I have been testing this since morning and just populating some logs. And you can also see the logs here at the bottom. So if we want to go into a specific log entry, we can go below and look at the logs. So here you can find somewhere that get customer details from account services called it's giving a start and end kind of info. So this is all real time. So what this means is I don't have to go into individual nodes or look at individual pod. All I have to do is to configure Loki in such a way that it collects logs from all of my services and sends it to Grafana. This is the application specific logs. I can also do the same for infrastructure related ones. So in here, I can build another query. And in the labels, I can here say look for a node. And I've got a three node Kubernetes cluster here. I can look at one of the node and I can get the logs which are coming from that particular node. So with this one component, I get the logs from both my application side as well as the infrastructure side. The next thing we are going to look at is the matrix. And again, why do we need matrix? Matrix, they help us to collect data at different point in time at aggregated level. Logs are good for knowing at an individual level or individual transaction what happened. Matrix are useful to know over a period of time how resources are getting used. So from application point of view, we might want to use matrix to collect things like the resource usage, things like scaling the needs to understand if our application needs to scale, if we need to enable autoscaling and things like that, and also to monitor any anomalies or outliers. From a Kubernetes point of view, again, we can look matrix for CPU and RAM usage, the health of APIs, and again, if we want to enable autoscaling. Autoscaling can be both at the pod or the application level or as well at the cluster level. So these matrix, they can help us to identify the needs for these kind of features. And same thing goes for the past services as well. We want to monitor resource usage. We want to see the scaling needs. And if there are any bottlenecks, matrix can help us identify that. So for the matrix demo, again, I'm going to use Prometheus and Grafana. And I use the same application. And I use what is called as a Kube Prometheus stack here. If you have used Helm charts to deploy any of the third party applications, I find this very handy where Kube Prometheus stacks comes with Prometheus, Grafana, Alert Manager, all these components combine together in one single Helm chart. And it sets up everything for us, even including some default dashboards. And for the application-specific services, the five microservices that I have here, I use a custom resource definition or CRD to collect the matrix using what is called as a service monitor. So that service monitor collects the matrix in the Prometheus format. And then using the open telemetry collector, it publishes them or it pushes them into the matrix storage, which is Prometheus. And then again, we use the Grafana to visualize this. So let's switch back again to the demo mode and see this in action. So here is an example of a dashboard, which is resource level dashboard. This is coming by default again with the Kube stack Prometheus. And I'm looking at the compute resources at the cluster level. There are various other dashboards which come through, but all this is provided by default for me. So I can look at what is my CPU utilization? What are the requests? What are the limits? This can again be at the different sources as well. In this case, I'm only using Prometheus as the source, but I can add multiple sources and all this is customizable. So all the widgets that we have here, they're based on the data which is coming in Prometheus matrix. So I can go and edit all these visualizations. I can use the Prometheus query language or promql and specify what query has to be used and I can also change the visualizations. So this is again something I find very handy where in order to get started with monitoring the cluster state, you don't have to spend too much time. You can use this built-in visualizations and get started very quickly using some of the community created dashboards. So if you want to know what are the other dashboards, you can just go into the dashboard section here and we can see that there are dashboards created for the alert manager, there is code DNS, there is the API server compute, there is the networking one. So all these different aspects related to our Kubernetes cluster, we can monitor them very easily using these different dashboards. And then I'm also using a dashboard provided by Istio for application-specific matrix. So here, again, if I go and generate the workload, we can see in real time that these different metrics here regarding what is the duration of my HTTP request, what is the throughput, how are the different processes consuming memory and all the threads, all that information I can visualize in real time using these dashboards. Think of trying to doing this manually without having something like this. If you were to do it using the legacy technologies, I'm pretty sure it would take quite a long time for us to come up with something like this. So that's on the matrix side. And in order to integrate these metrics, again, I'm using OpenTelemetry and OpenTelemetry has this support for different languages. My application is built using Spring Boot, which is a Java-based framework. So here you can see that it can automatically do instrumentation for Java language. So I don't have to make changes to the code for this to get started. I can define a custom resource of the type of instrumentation and I can specify the language. Java is one of the supported languages where it can automatically instrument and it can send the telemetry data to whatever backend we want to use. Now, with that, let's move on to the next part. The last part is about distributed tracing and again, earlier session where we talked about Yeager and using distributed tracing. This is a similar concept why we need distributed tracing. In terms of understanding the complexity of the application, when we do microservices-based development, there can be a lot of calls going from one microservice to another that can be calling another microservice. And when we need that visibility into how the flow is going between different microservices, distributed tracing helps us to understand the complexity of the system in terms of what calls are going where and with the traces, we can also identify how much time each call is taking. So if there is any performance issue, we want to monitor the performance, we want to optimize the performance. Distributed traces can help us identify those bottlenecks and obviously when there is problems in production, we want to debug the problems. Again, distributed tracing really comes into the picture to help us identify, let's take a scenario where you might be having five replicas of your service running and imagine that on one of the particular node where it is running, there is a problem. So distributed tracing can help you identify that particular node where that problem is happening. And I'll show you one example of this, how this can be identified. So in this setup, I'm using the same financial services app and I'm using Jagger as the distributed tracing framework where there is a micrometer component which spits out the matrix. And then there is a Jagger operator which I've deployed in the Kubernetes cluster which collects these matrix or which collects these traces. And using the open telemetry collector, it slides it to Jagger. So we visualize this using Jagger user interface. So let's see this in action. Again, let me run the same 500 iterations of the same backend service and switch over to the Jagger UI. So here I have got all those five different services, the account service, authentication service, backend service, forex service and transaction service. All of those traces related to these services are available here in Jagger. We'll focus on the backend service which is like the entry point for me. And when I say limit this search to 20 traces, we can see most recent 20 traces a few seconds ago. We had this and in this particular case, we can see that there were four spans involved and two of them had the errors. So in case of such scenarios, we can go, we can drill down into the method call level or the service call level and we can find out where exactly the error happened. And obviously we have the complete time span about how much time each of these operations takes. That's the failure scenario. In case of success one, we can also find that there are cases where it would have taken longer span. Let's increase to 200 traces. And here we can see another API call which has got 11 spans and it's taken about 20 milliseconds in here. So again, I can do the same thing in terms of drill down and identify how much time is being taken for each of that hop between different services. So we see that the backend service is calling the authentication service here. Then that returns the authenticated user information, then it goes into the account service and then it goes into the transaction service. So each of these call, we are able to trace right from the beginning till the end and we can identify what's the time taken for each of that span of the call. So in terms of the end to end observability, in this demo, what we saw that we have these five different microservices and we use low key for the log aggregation and we use Grafana for visualizing those logs. And when it comes to the metrics, we use Prometheus and Grafana as the combination. And for the distributed traces, we are using Yeager. All this is combined or all this is integrated using OpenTelemetry which is more like a standard. It doesn't tie into any of these specific tools. So if we want to switch from one of these backends to a different backend, it's possible. OpenTelemetry allows us to do that and it can be done very easily using the configuration changes. I like to use this analogy of using the right tool for the right purpose as well. If you look at many of these tools or many of these projects, they try to do many things at one time. I take this example of mode of transport. So if you want to move from one place to another, there are different modes. You could use a bicycle, you can use a bike, you can use a car. There are different factors which influence why you would choose one over the other. Let's say it's a holiday season now and you want to spend more time with your family. You might choose a cruise, but if you want to reach very quickly to your destination, you might use a plane. So it all depends on what is your requirement and what is the right tool for that purpose. Previously in earlier demos, I've used ELK for example for log aggregation. So there might be a case where ELK fits better in your scenario and you might want to use elastic stack for that matter instead of using Loki. So this is not a guidance or this is not a sure shot solution to say you should use only these tools. My suggestion is based on your mileage, find out what is the right tool for your purpose and use that particular tool. So in summary, I would say that the modern day cloud native applications, they need different ways to address the observability and monitoring. We can't rely on legacy ways of just looking at CPU and memory usage. And these modern day tools, they help us in announcing the observability of our applications. As applications become more and more distributed, we need different kinds and different ways of monitoring them and things like log aggregation matrix distributed tracing. They help us in doing that. So I hope you found this useful, what I demonstrated. There are some challenges when we get into this, things like if you're not using something like a open telemetry and you were to use these tools separately, individually by themselves, you might have to have too many agents running, you might have different SDKs to integrate to, that's one of the challenge. The way you overcome that is by using something like open telemetry which allows you to consolidate all those things in one place. You can see all your configurations in one place and it can be easier to maintain and manage your observability stack. The other one is instrumentation and vendor lock-in. In this case, the suggestion again is to use something which is open standard. If you don't want to have a vendor lock-in, try to stick to those tools and those products which support open standards so that it's easier for you to migrate if you want to in future. Things like cloud native locks, cloud native metrics, cloud native traces, these are new things and for that, you might have to use something which is recent and new. Things like fluent D, Prometheus, Thanos, we saw the example in the earlier demos. So these kind of things, again, when you use open technologies, they are easier to migrate to or they are easier to manage in my opinion. And then when you need a single pane of glass, Grafana is most commonly used nowadays, so I prefer to use Grafana. With that, I think I've come to the end of this session. In case you want to have some references here, I've put some links and these slides are published already to Slide Share and SpeakerDeck, so you can find the links there. I've also put some links to my earlier talks which I've done in other forums like Reactor and there is also this wonderful series of talks done by this guy called Usain Dalai where he talks about Prometheus Grafana. So if you are interested in implementing any of these in your projects, feel free to refer to them. The source code for this demo that I showed is available on GitHub and there is also a markdown file. If you want to reproduce this, you can create it from that markdown. And the Slide Share and SpeakerDeck links are there for this particular talk as well as my earlier talks which I have done in the past, they are available. So thank you, thanks for coming. I think we still have some three and a half minutes for Q&A, happy to take any questions before we break for lunch, yes. Sorry, I haven't heard about it. So the thing is all these catch words, right, they keep coming up nowadays. If you look at four hours, six hours, seven hours, so I think over a period of time as technology evolves, we see that these kind of things they keep added. A 12-factor app for example is a classic example. When it started, maybe 2010 or 2013, there were 12 factors which people were talking about. Now there are 15 factors, maybe six months down the line, we might hear about 18 factors. So I haven't heard about the fourth one but it's quite possible, it's there. And it's good if it is there. Thanks. Any other question? If not, thank you. I hope you enjoy the rest of the day.


Hi, welcome back everybody. We're here at the Cassandra Summit 2012 live, Santa Clara at the Hyatt. I'm Jeff Kelly, lead big data analyst with Wikibon. Our next guest, Ben Connors, Worldwide Head of Alliances for JasperSoft. JasperSoft, as you know, open source business intelligence reporting and analytics company. Thanks so much for coming on theCUBE. Great, thanks for having me. Really enjoyed being here. Great, so why don't we just start talking a little bit about what JasperSoft is doing with, you know, doing here in a big data world and I know you've got an announcement this morning with data stacks, so talk a little bit about kind of how BI fits in with kind of the big data world. Great, be happy to. So, JasperSoft, as you know, is, as you mentioned, open source, this intelligence company. We do reporting analytics dashboards from a variety of databases. We started from the relational side, but we've been making a big push now into big data. The announcement this morning is the latest in a chain. We're really excited to be working with data stacks. We see that they have a great team, great product, great ecosystem, lots of customers. Everything's going really up and to the right, so that's really strong. The reason that we're focusing a lot in the big data space with data stacks and others is because we believe really that the value of the big data is not in, you know, the traditional 3Ds or the velocity, the variety and the volume of data, but it's really the time to insight. It's the value, the fourth V, the value that you get from that big data, and that's what we try to bring to the party, and that's what Cassandra does really well, because as you know, they are a very high volume, but very low latency data source, and that plays very well to our strategy of low latency reporting and analytics. So they have the idea of as close to real time as you can get. Some of these other big data platforms are more batch oriented, not quite as real time low latency, so Cassandra sounds like it's as a data source for Jaspersoft is something that can really support more of the real time. Exactly. Yeah, they have a focus on low latency or near real time as do we, and so it makes for a very close fit. Right. So you mentioned, you know, you're, as most BI companies kind of start in the relational world, connecting to a central data warehouse, running reports, providing some level of kind of interactive analytics. Talk to me about as, you know, we transition to this big data world. I mean, certainly relational databases aren't going away, but we're going to see more and more big data sources come online, and that means BI companies and BI technology now have to shift to be able to support these kind of no sequel, non-relational tools, more data sources. So what are the challenges associated with doing that? Adapting traditional BI that was built in that kind of relational centralized data warehouse world to a big data world. Yeah, so great question. It actually, maybe by fortunate coincidence, fits in very well with something that we did a while ago, and that was we built, we're open source, and so we're completely open, we publish all our APIs, including custom data sources, custom connectors. We did that before the days of big data, but as it turns out, that fits perfectly into what big data requires, because as you know, these are multi-structured, unstructured, multi-structured data sources, and so we use that underlying architecture to build our various connectors, including, originally, curiously, to Cassandra using their APIs, and as you know, they've now gone to Cassandra Query Language, CQL, data stacks is fully supporting that with not only the data itself, but also through the solar interface, as you know, for search, so we support all of that. Now the interesting thing for this intelligence to your question is that traditionally companies weren't thinking in those dimensions, and so they're married to SQL, and what that means is you have to try to figure out how to make whatever you have in front of your fit SQL, and people do that through, for example, ETL, taking whatever the big data is and trying to push it into a relational data source. Well, that has its challenges in terms of latency, in terms of volume, in terms of all the things that big data does very well, which is why people invented big data to begin with, or they try to use traditional SQL approaches, and that leads to some things like, for example, the Hadoop world using Hive as a connector, which is fine, but again, that's a batch-oriented approach, as you alluded to earlier. So what we're doing and what we think is the way for BI to effectively address these big data sources is to go natively to them and go directly to them for the near real-time analytics and the flexibility and the power of the underlying database. So maybe could you walk us through one or two kind of use cases, specifically of Jaspersoft working against Cassandra, what are the most popular use cases you're seeing, what are you hearing from customers, how are your two technologies really going to work, practically speaking, what are the real value, what do you bring the real value? Yeah, okay, so some typical use cases are for things like log analysis, things like gaming applications where people want to see from many, many thousands of users and how they're tweaking the game and what that's meaning to their use, so forth, whatever. And what we help to provide is insights into that by visualizing, digesting, presenting the information in a meaningful way. So in that scenario, a company might be using Cassandra really to support their real-time gaming platform and Jaspersoft can kind of come in and help you understand that data as it's being created and exactly who's playing, how they're playing, what are maybe some bottlenecks, whatever the case may be. Exactly, one way I like to think of it is we try to make big data small. So by presenting it in a way, instead of having this sea of information, you have a nicely packaged table or graph or dashboard to reduce it all into something that we mere mortals can digest. Well, that brings up another interesting point. So when you're actually trying to visualize and present big data, what kind of challenges does that present in terms of versus smaller data sources where you knew what you were looking for in a sense? With big data, you don't necessarily know what you're looking for. You want to do more ad hoc type analysis and it might not always be clear the best way to visualize so many data sources and all the different potential correlations you can draw between data sources. So how does that impact product development on your end and actually building user interfaces that are in fact intuitive and easy to understand? Is it just the case? I mean, can you just take what traditional BI and put it on top of big data or did it require a new way of thinking? It really does require a new way of thinking and the reason that is severalfold. Number one, being able to efficiently access the data sources and take advantage of their capability but also it comes back, I think interestingly, to the near real-time latency aspect. What I mean by that is, as you point out, when you have all this data from all these different sources and all these different structures and formats and so forth, it can lend itself very nicely to iterative or live exploration and that's what we facilitate very well. So as you point out, you look at it and you say, gee, let's use a gaming example, just as an example. Gee, you know, how is this game compared to that game? Well, that's interesting. I wonder if that's true in North America and Europe. No, it looks like over in Europe that game is a little more popular. Gee, why is that? How does that compare by age demographics? Or since we introduced that new weapon into the system or whatever. So one question leads to another. If you have to wait around, again, for latency, if you have to wait around until tomorrow, to figure out what it is, it makes it a very cumbersome tool, a very cumbersome analysis. When you have this near real-time, you can operate more or less at speed of thought and quickly, the creativity, the human mind can quickly formulate new ways to think about it, new ways to look at it, and derive some interesting interrogations that way. So, you know, as we've talked about, you're an open-source company, and, of course, Cassandra got their vibe in an open-source community. So I wonder if you could talk a little bit about how the two communities mesh and maybe how they're similar, how they're different. And what's it like trying to bring together two different communities like that? Is there a lot of overlap? What are the challenges in terms of negotiating that kind of landscape? It's very complementary, very synergistic. So as you point out, both companies have very similar business models. We have free versions of the product, and then we have commercial versions. As you know, the open-source model is, or so-called premium model, typically the vast majority of the users use it for free, and they're happy to do that, and the company's happy too, because it seats the market and gets more input into the product and so forth, whatever. People who do pay for the product in both cases are really paying for it for one or several of three reasons, either professional support, the ability to embed and resell the software in another product, or thirdly for some premium features, some extra lit. That's the data stacks model that's Jaspersoft model, and so it really plays very well together. Yeah, interesting. So yeah, I mean in terms of the use cases, we mentioned the gaming use case, looking forward, where do you see this kind of going, not just with Cassandra and data stacks, but in general, how is BI going to evolve in this big data world? I mean, we talked a little bit about the technical challenges, but I mean, is BI going to be, are we going to be able to recognize it compared to what it is today in five years from now, when we were talking about where the term big data might not even exist, it's just a given, you've got all this data. What's this going to do to the BI industry? Okay, so what we see happening is trend towards what we consider self-service BI at scale, and what we mean by that is with all this big data and all these hidden messages, these gems of information that are buried in there, more and more people are going to find value from that because you're collecting information that's interesting to this group or that group or this function, that function, et cetera. So what that means is you're going to want to be able to have easy to use BI tools that will let the user reconfigure, re-sort, re-examine the information in a way meaningful to them. So the days of static reports, I think, are going to fade from us as we get to the point where you want to empower the users to see it in a way that makes their life easy, their insights faster, et cetera. Secondly, as I mentioned, self-service BI at scale, the at scale part is very interesting in a couple of ways. Well, what it means is that you don't want to have, again, you want to make the data available to lots of users in lots of ways, and things like desktop BI, I think, are going to fade because they're expensive and technically, it's hard to scale and support large user communities. Big data, I think, is going to lead to big user communities and that's where you want both the technical and economic models, financial models, to make BI able to serve hundreds, thousands, tens of thousands of users. And I think that will be the trends we'll be seeing is empowering the users to do more of the self-service analytics and having a technical and financial model that makes it feasible to put it in the hands of all those people. Well, let's dig into that a little bit. What will that technical and financial model look like? So, technically, what it means is that you want to have easy-to-use web-based tools that don't require the desktop installation. It means you want to have them intuitive and flexible and secure to be able to put in the hands of so many users and let them sort and filter the data. It means you want to support lots of end-user platforms, not only desktop but web and even mobile. And, for example, at Jaspersoft, we now support the Apple iPhone, the iPad, and Android.


Hey, this is Brett, and this 2017 Chevy Silverado 3500 Double Cab Long Box Single Rear Wheel is stock number 12870Z. I'm here at Summit Automotive in Fond du Lac, Wisconsin, near New and used heavy duty truck headquarters. This 2017 Chevy Silverado 3500 Double Cab Long Box has the 6.6 liter Duramax diesel engine. The first steer of the L5P engine puts out 445 horsepower, and it's paired up with the Allison Heavy Duty 6-speed automatic transmission. This truck has been fully safety inspected by Summit's service shop, has a fresh oil and filter change. All the fluids have been checked and topped off, and this truck is 100% ready to go. It has four brand new tires as well. Fire red is the color, and I shoot all my videos in 4K, so if you have HD capabilities on your computer, tablet, smartphone, or television, I highly recommend turning them on right now, because it is your best way to check out the quality, condition, options, and cleanliness of the vehicle before seeing it in person. And if you like the video and how I do things here at Summit Automotive, consider clicking the subscribe button in the lower right hand part of the screen, and then click the bell notifications, and you will get updates every time I do videos of our new and used inventory here at Summit Automotive. This one comes with the 18-inch chrome alloy rims, and it has brand new General Grabber LT26570R18 tires. They still have the little wear knobs on them. We put those on in our safety inspection.  Didn't see hardly any corrosion on there. Front fender is absolutely perfect. No dents or dings, and it does come with the projector's lamp-style headlamps. Bumpers in fantastic conditions and see any dents or dings on there. Comes with the chrome-trimmed grille. That looks really good, and it comes with the fully functional, true cowl induction hood. Did not see any dents or dings on that hood. Looks really good, and I'll show you how that cowl induction works in just a little bit when we start the truck up. Passenger side front fender, no dents or dings on there, and this passenger side front rim, no scuffs or scrapes. Now as you go down this side of this 2017 Chevy Silverado 3500 Cab Longbox, take note of how clean that body is, how reflective and mirror-like that paint is. We take these HD videos so if you are far away, or even if you're close by and you just cannot make the trip down, but you're still interested in purchasing the vehicle, you can see the truck, hear the truck, and have confidence in the vehicle that you're looking at before you even get here. So when you do get here, there's absolutely no surprises. You can make a smart and informed buying decision from wherever you're at. And if this video helps you make that buying decision, let your salesman know that you saw the video that it was helpful and that Brett sent you. Very clean down that side. Doors look really good as does the box. This back rim is in excellent shape as well, no scuffs or scrapes. And the back tires are brand new too, you can still see little wear knobs on there as well. Like I said, frame and underbody, other than being a little dusty, is very nice and clean. And it is dusty like that all the way underneath, but does have all the remaining factory exhaust. But I didn't see any corrosion or anything. And lower rockers all look really good as well. Comes with some nice aftermarket chrome step bars, passenger side box, didn't see any major scuffs or scrapes, does have just a little bit of touch up on the rear corner there. The rear bumper is in nice condition, didn't see any major dents or dings in there. It does have the rear bumper steps, full towing package, which includes the receiver hitch four pin and seven pin wiring. And the tailgate is in very nice condition as well. Does have a locking tailgate, shock down assist tailgate, spray and bed liner, and a goose neck hitch. Also comes with seven pin wiring back here. And that spray and bed liner is in very nice condition. And you can see that it was done in El Dorado, Kansas, which is where I'm guessing this truck is from, comes with a nice painted trail effects tool box. Tailgate shuts nice and solidly and as you go down the driver's side, just as clean as that passenger side. Didn't see any dents or dings on the box on this side, looks really good. And for full disclosure, this back rim is in fantastic condition as well. No scuffs or scrapes on there. So going down the rest of the side of the truck, doors and the cab all look very nice. Comes with the telescopic tow mirrors. They have built in directional signals, LED side lights. They telescope out like so. They also fold in like that. Inside the LT1 package gives you the black cloth interior, 40, 20, 40 split bench seating in the front here. No rips or tears on the seats. They're in really nice shape. Comes with a nice set of husky all-weather floor mats in the front. Auto headlamps turned out four-wheel drive and factory brake controller does have tilt steering wheel, power windows, power locks, and power mirrors. We'll hop inside, check out the miles, the radio, and everything that this truck has to offer on the interior. All right, you can see that this truck has 42,714 miles. You do get a digital speedometer and compass display. Comes with the leather-wrapped steering wheel, cruise controls on the left, and Bluetooth and information center controls on the right. No major rips or tears on the steering wheel does have the Allison heavy-duty six-speed transmission with the optional tap shift. This one comes with the Chevy MyLink radio AMFM and Sirius XM radio capabilities on here. And it also has a projection manager where you can reject your cell phone to the screen via Android AutoRap or CarPlay. So if you have a nav system on your cell phone, such as Waze or Google Maps, project it right to the screen. It's like you have nav right on the screen. Pretty nice system there. You do get your heated mirror and climate controls down here. Does come with the stability control. That's for your LED side lights and your cargo lamps and your factory exhaust brake. You also get a 12-volt PowerPoint down here. See just how nice and clean that carpeting and passenger side floor are. No rips or tears on the seats on the passenger side. And the hood headliner is in nice shape as well. You do get map lights up here and on-star and SOS capabilities in the rear view mirror. We will take a quick look at the back seats. And then we'll start it up and take a look under the hood. Back seats are just as clean as the front seats. No rips or tears back here. And it does have the latch child safety system for any child car seats you may want to put back here. And then it does have a fixed glass rear window. These seats fold up. There is a nice storage bin back here. And the factory all-weather floor mats are back here as well. Bottoms of the doors all look really good. And the inside of the doors look very nice as well. There are those LED side lights. They are extremely bright. Very handy at night. We'll start it up and take a look under the hood. Starts right up. No check engine lights or anything like that. There is your tire and loading information sticker. And then there is your vignet sticker. And we'll take a quick look under the hood. I would personally like to thank you for checking out the video today. And hopefully from this HD video, you'll have been able to verify the quality condition options and cleanliness of this truck all the way around. Once again under the hood, we have the 6.6 liter Duramax diesel engine, L5P. Engine bay is very clean, runs very smooth. Once again, 445 horsepower. And this truck has been fully safe and inspected by our service shop. As a fresh oil and filter change, all the fluids have been checked and topped up. And this truck is 100% ready to go. There is your emissions sticker. And that co-induction hood air comes up from the middle there, comes down to the side, right into the air box, nice fresh air in there. And I would highly recommend this 2017 Chevy Silverado 3500 double cab long box LT1 in red hot from a quality and condition standpoint. And to see more pictures of this truck or one of other 400 and 50 new and used cars, trucks, SUVs, minivans, wranglers, half tons, three quarter tons, one tons, you name it, we got to go to that website right there, summitauto.com. Full pictures and descriptions of every single vehicle from two locations all at summitauto.com. And if you'd like to check out more HD videos, you can go to youtube.com slash summitauto. Remember to like, subscribe, and share. On this video and all the videos that you see there, click the bell notifications. You'll get updates on the videos we do each and every day here at Summit Automotive. In fact, in a second, you will see a link to subscribe to our YouTube channel on the upper left. And for more Chevy 3500 truck videos like this one, the upright link to this vehicle on our website in the lower left and a link to one of our latest YouTube videos in the lower right. Click those, check us out. And we're super excited to help you with this Ultra Clean 2017 Chevy Silverado 3500 double cab long box LT1 Duramax diesel in red hot clear coat. Thanks again for checking out the video. Remember to like, subscribe, and share on our YouTube channel. I really appreciate it. Thanks again.


Rwy'n gweithio, wrth gwrs. As I was talking to people last night and today, I could tell people what I was speaking today, I started to dread the inevitable question. What's your talk about then? I would tell them the title, Managing WordPress of Ansible and then wait for the typical response of Managing WordPress with what? So I'd give a quick summary of the talk and then explain that since I'm pretty new to WordPress and wanting to get involved in the WordPress community I took topics that I was comfortable with and hopefully made them relevant and well, here we are. Now, there are lots of David Murphy's in the world so the easiest way to find me is to use my online alter ego, Shrock. I've been using this name since the late 90s and as far as I know I'm the only one using it. There's a story behind the name but it's really not that interesting. I've been messing around with computers since I was around seven years old and working professionally getting paid to mess around with them for over 20 years. Aside from my long standing interest with computers and technology I'm also a husband, a father of four two schools and I live in the very north west of England. I'm also an automatician. I joined automatic just over a year ago and my journey there was a slightly different one than most of my colleagues. Despite being a long time WordPress user in fact my WordPress.com account is over nine years old and a long term fan of open source software I never became involved in developing or extending it. Similarly, while I was aware of the WordPress community I did not actively participate in it. Before automatic I was a canonical working on and with Ubuntu for seven and a half years. And as very predominantly a python shop I haven't even touched PHP for nearly eight years. What brought me to automatic was the company itself of automatic that is inspiring me to become more involved in this, our community. So I titled my talk Managing WordPress of Ansible but the reality is that once it is deployed WordPress especially when combined with plugins like WP, CLI, Jetpack and others is really good at managing itself. That means what we're really talking about today is deploying WordPress of Ansible. I'm going to show you one way to replicate and improve upon the famous five minute install. Now hopefully some of you are asking yourselves why bother? And that's an important question to ask. There are so many great choices out there for hosting, so many options for one-click installs and pre-configured services that you may never have actually installed or deployed WordPress yourself. Or maybe you're lucky enough to have someone or a team do it for you. Then again maybe you don't. Perhaps you still follow the five minute install and FTP your files up and to your web post unaware that there are things, tools that will make your life easier. But before I dive into how to do this I would like to talk a little bit more about why I do it this way. I believe the best way to learn is to do it yourself. Being able to do it yourself is an important life skill. We can learn any subject we put our minds to and exercising that knowledge reinforces our learning more fully than just trying to soak up the knowledge. No matter how much we hated them both tests in school helped us. Remember what we had been taught and led us to put that knowledge into practice. Don't worry there's no quizzes today. Of course while we can learn any skill we still need to be pragmatic. If you primarily consider yourself a designer you may not think learning any form of systems administration is any use. The best use of your time. I disagree with that and that is because it is knowing how to do it yourself but it's the most important part here. When I first got involved with Linux I was looking to replace my copy of Microsoft Windows with something better. I had no idea what I was doing. I would buy books and magazines and I would install the latest distroges from the accompanying CDs and DVDs. Yeah I never quite got what I wanted or anything truly working for that matter. Then a friend introduced me to OpenBSD and it was pretty bare bones that I had been trying. That forced me to learn some basic principles first. When it came time to try something else I was much more comfortable and successful. I did the same thing with email. Running my own server and knowing how it worked. These days like most people I let Google take care about for me but I still have that basic knowledge of how email works. So when there's a problem I can try and figure things out and it's not just with technology but with supplies either. Picking up basic DIY skills around the house when you're dealing with contractors or dealing with a mechanic for your car so it's just that little bit of knowledge really does help you in life. So speaking of getting people to do the work for us it's time to talk about automation. Whoops! It is really hard to spell that with just two Ts these days. That's better. Automation is one of those things that makes our lives easier and we're going to use automation to deploy WordPress. Why automate things? Why bother? Doing the same thing repeatedly is inefficient, prone to error and let's be honest, dull. By automating things we make that same task efficient, consistent and most of all easily reproducible both by ourselves and by others. Sure you may only deploy WordPress once but you know the men let it upgrade itself but what happens if that server crashes or is hacked or if you're lucky you need to add more capacity because your site has blown up in popularity. A little bit of effort now can be huge rewards later on and if you don't have time and then you don't have to remember or even Google how to do things again. Okay, that's enough of why I don't do it this way. Let's talk about what. We have lots of choices in life. Some are easy, some are hard. Some are inconsequential and some are life changing. The choices here aren't quite as significant as that but since I'm talking about my preferred approach to this I wanted to explain some of the thinking behind the choices I made in putting this together. Our first choice is what are we going to deploy. Of course that's easy WordPress. But in reality most of this talk can be applied to any type of software deployment. Our second choice is what are we going to deploy on to. We need an operating system to run our software on and the decision we make will affect our solution as you'll see. There are plenty of platforms to choose from and these are just some of the best ones for us in speech ones. It should be obvious by now but my preference is to run this laptop and I use Linux on all my other machines. Fortunately they're all good. They each have their strengths and weaknesses so pick one, learn it, try it out see if it works for you, if you don't like it try something else. These days my personal preference is for Debian. I'm sure some of you expected to see Ubuntu here but I've come to appreciate the simpler and more consistent approach of Debian when running it on my servers and my other machines. If I was still running Linux on my laptop perhaps my choice would be different. There's an even greater choice here catering for all tastes and requirements since there is so much choice let's take a closer look. Shared hosting is the easiest and cheapest choice but it can be restrictive both in terms of performance and control. It can be a great starting point but it is not to my taste. If you have grow shared hosting it used to be that the only alternatives were to lease a dedicated server or co-locate your own box both of which can be as expensive as they sound. There's a little ground bow and that's virtual private servers. They're exactly what they sound like real machines carved up into lots of little virtual ones. They can provide complete control and can be very flexible but at a fraction of the cost of a dedicated server. A natural progression of the growth of virtual private servers gave us the cloud. On-demand computing which is incredibly flexible and powerful and can be as cheap or as expensive as you choose. However you should be prepared to invest upfront in automation or it can be incredibly inefficient to manage. You also need to be aware that they are not all equal. Just as the different hosting types have their own strengths and weaknesses so do the companies providing them. Do your homework and choose wisely. My choice for local development is vagrant. This is a set of automation tools wrapped around virtual machines so you can get pretty close to the experience of using a virtual private server on your local machine. In addition it has the advantage of keeping your work isolated within those virtual machines to mix and match different operating systems and different software versions and not worry about things tools conflicting. For actual hosting my choice is digital ocean. I find them incredible value for money and they have just the right amount of control. They actually bridge the gap between traditional virtual private servers and a full-blown cloud service like Amazon or Google compute engine. Final choice. What tool are we going to use to deploy? These are just some of the well-known software configuration management that anyone who's paid attention to the title of this talk will know full well that I'm going to use Ansible. In their own words Ansible is a powerful automation tool that you can learn quickly which I definitely do agree with. I've tried them all out and with Ansible I found the scripts quite closely resemble the manual steps that I would take which combined with the fact that everything is done over secure shell and nothing is installed that I don't ask for there's no software agents running. It makes it feel more like true automation compared to some of the other ones which feel programming languages. Ansible has three core concepts that we need to understand. Inventory, playbooks and roles. Today we're only going to look at inventory and playbooks. Roles allow us to break down our playbooks into manageable, reasonable chunks but should be considered a more advanced topic. Let's get started with inventory. Okay, so this is a sample inventory taken straight from their documentation. It is in plain text using the easy to understand any format. Here we can see there are four hosts. Two web servers and two database servers contained within two groups. Ansible makes it easy to target as few or as many machines as we want. For example, we could just specify all or only web servers or even just the DB1 host. We can have multiple groups and hosts can be defined by host name or IP address. Now, what if we have lots of hosts? Here is another example containing 50 web hosts and six database servers using only four lines of text and the naming pattern. A positive argument for naming servers sensibly rather than just after Lord of the Rings characters. Apart from supporting lots of hosts we can also be very clever with our inventory by using groups of groups. Here we have three hosts and two groups. You'll notice that host two is in both the web and database groups and both groups are contained within the site group at the bottom. Ansible allows us to target the union, intersection and difference between groups. For example, if we include the web group but exclude the database group only host one will actually be targeted. So with a simple text file we can describe and target large amounts of servers with ease. You can have multiple inventory files and if you're using a cloud-based computing solution like Amazon EC2 or GCE you can actually have a dynamic generation of this inventory from your running instances. Here is my inventory for the purpose of this talk. The local vagrant host and the production host running on digital ocean, both are running Debian. Now, not all instances are equal but we can easily accommodate that in our inventory. For example, you can see here but I'm telling Ansible to always use the sudo command to elevate privileges on the vagrant host. As by default there we use the vagrant user. While that is not needed on my droplet because we have a root user there which is a security problem in itself but this is just a demonstration. Let's see Ansible in action. That's a lot smaller than I expected it to be. First we're going to run the Ansible command which you might not be able to see and tell it to target all hosts which inventory file we want to use and then tell it to use the ping module. Execute that ping command on both hosts simultaneously and get a successful response just as we would expect. Next we target just the development host of the same command. That works just as we expected. We have a working inventory file now we need something to run against for them. Let's have a look at playbooks. Playbooks are instruction sets. They consist of plays which in turn consist of tasks. Plays can define the inventory groups that they apply to and each play and task will be completed in sequence until the playbook is complete. Again, that's very small. Here is a sample playbook again taken from Ansible's own documentation. This time it is in the Yamel format yet another markup language that provides more structure whilst retaining readability. This contains two plays. The first targeting web servers the second DB servers. Both say the play should be run as the root user and both contain two tasks. For the web servers it uses yum for Fedora package manager to install the latest version of Apache and then creates a configuration file using a template. For the database servers it again uses yum to install the first SQL and ensure that it is running. Each task specifies a module to be used so let's dig into some of those modules. Most Ansible modules and tasks are idempotent. They can be run multiple times and the end result will be the same. There are three types of results from tasks. Changed meaning something was changed. Okay meaning nothing was changed but the command completed successfully and failed which failed. If we ran that example playbook twice we would get multiple change results because something was changed. If we ran it again we would get multiple okay results because nothing was changed but everything was successful. If we changed something and then ran it again it would actually go back and revert our work to set the server back to its expected state. Here are four examples for using the yum module which installs, upgrades and removes packages using the yum package manager. The first one is installing the latest version of Apache as we saw in the playbook. Specifying latest as opposed to present will apply upgrades if available each time the playbook is run. The next one tells yum to remove that same package then use an alternate repository and finally specify a specific version of the package. Since I'm using Debian I'll be using the apt module but they're basically the same principles. Template was the next module that we saw and it is used to create and modify files using variables. It uses Ginger 2 templates which use the same style of curly braces surrounding a variable but you'll be familiar from other templating languages. In both examples we specify a local source stored alongside our playbook and a remote destination along with the ownership and permissions for the resulting file. We can also back up an existing file before using our template so as not to lose anything. Here we see how to use the service module to control services on a remote host well maybe you can't see it actually. We can ensure that it's started or stopped but we don't force it to be restarted or reloaded or just ensure that the service is enabled so that it will start automatically after a reboot. There are lots and lots of modules plenty of official ones and plenty of third party ones too including some specifically for WordPress these are a few of the ones that I regularly use. Command for running arbitrary commands and get URL for well you know getting URLs various apt modules for managing Debian or Ubuntu packages and repositories modules for controlling cloud instances from a variety providers modules for sending notifications I mean who doesn't use Slack these days modules for controlling databases and users and modules for accessing code and version control you can deploy your site straight from Git if you wanted and this is just scratching the surface but you may have noticed a couple missing but you might have expected like Apache or PHP but reality is we already have everything we need to manage rows The common pattern here is to install the package software and control the service in terms of modules all we need are apt to install, template to configure and service to control ok so now we have everything we need to actually deploy WordPress so let's look at what we're going to do now I'm sure most of you will be familiar with these steps first we download and unzip WordPress itself then we create a database we edit the configuration file and finally we upload it but since we're going to be doing this directly on the server we can skip that step however, anyone who's done this before will realise there's some missing details so let's look at a better example we're going to install the packages we need we're going to create the database and the database user to go along with it we're going to download and unzip WordPress we're going to edit the configuration file we're going to configure our web server and ensure that it's running and since we're automating this we also want to be able to reuse our playbook so that we can and will do this by using variables the first part of our playbook is to define values that we want to use and here we have a database name a user and a password as well as the site name in alias with those in place we can install the packages here we're installing the four main packages we need along with two more to help Ansible this does the job but it is very verbose and when we run it it will be very noisy because it's actually running six tasks and of course there's a better way to do this here we're doing exactly the same thing but we're now installing those multiple packages using an array and a variable and a loop, much neater so there we go, we're going to install MySQL server Apache 2, ModPHP5 PHP5, MySQL and a couple of Python libraries once we've got those installed we can set up the database time to use some of those variables that we defined earlier we're going to create the database and the user and grant the user access to the database this requires one of those Python modules I just mentioned so Ansible can talk directly to MySQL next we're going to install WordPress these tasks should be getting pretty easy to understand by now and it's clear to see here but you create a directory download WordPress and then zip it into that directory next configuring WordPress anyone who's installed WordPress before will know that we need some unique and random keys and salts we should create them by hand and there is a we could create them by hand but there is a nice API endpoint that will do that for us and so we're just going to retrieve that using the URI module we also specify that it will create a file to make it idempotent otherwise it would generate new ones every time we run the playbook and that would be pretty bad with our keys and salts in place we can create our config using a template let's have a look at that that or maybe not if that should look familiar if you could see it it's for defaultwpconfig.php with the comments removed, variables added and an include statement added for our keys file almost there we just need to configure our web server here we're going to use another template but now we're going to do a couple of different things first we're asking to restart Apache handler to be notified after we create our config second we're using a command module to execute commands right on the box to control Apache itself to enable and disable sites and surely we'd need to be able to restart Apache again after doing that but the reality is those handlers execute at the very end of the playbook so we can queue them up as many as we like and they'll wait till we end and how do we define handlers they just work like any of a task here it's just calling the service okay that's it our playbook is done and time for another demo this time we're going to use the ansible playbook command in very small writing along with my sensibly named playbook wordpress.yaml and specifying our inventory file okay first it's going to gather some details from the servers that's very quick and then it goes to install the packages that'll take about 15-20 seconds on the boxes I configured this is definitely the longest part of the process while it updates that package list downloads the packages and installs them okay done on one server and done on the second one and then it runs very quickly through the rest of the process you can see that it is returning a change response for all of those events it creates the database and the user it installs wordpress by creating the directory and extracting it generates the keys from our config and manages the web server and there we go that's it we now have a bare bones wordpress site obviously we now have to go through the manual setup but let's go a bit further and do another demo this time I've added four extra hosts to our inventory file it's just going to run through exactly the same process but here we see some of the power of Ansible by reusing and automating so it checks all six servers it hits our first two servers first and there's nothing to do because both packages are already installed so it returns an okay response we're going to wait for a changed response to come from those other four servers and then it will run through the rest of the install process there we go so okay on the first two servers changed on the next four and the rest of the process is just as quick so we now have six servers deployed in exactly the same way at exactly the same state and you could deploy six or six hundred using this process and our original hosts have remained untouched the new hosts have configured exactly the same way and all I did was add a new host into my inventory file now clearly these hosts are not production ready but by combining all the steps shown we can improve on this in lots of ways like installing additional packages PHPGD or downloading plugins we could call WPCLI directly using the command module switch out a patchy for engine X as most people would want to and installing and configuring firewalls as most people should we could also use Ansible for building out a more scalable infrastructure for example multiple web servers speaking to a single database this was a deliberately superficial intro to Ansible and I hope it's whetted your appetite a bit and like all good talks this one was opinionated as I may have mentioned once or twice this is what I've shown here is not best practices for deploying WordPress so please don't use this in production but by sharing my passion for systems administration automation I hope that I've inspired some of you to look further into these topics and see where you can improve your own processes and practices and finally as an ex-pearl hacker I always keep a pearl motto in mind there's more than one way to do it it's all about expanding knowledge and what you do with it try your tools, try distributions see what works for you in return if you have your own solutions I would love to hear about them so I can expand my own knowledge and that's it, thank you ok, if there are any questions then there's a microphone in the middle of the room but I'm sorry but just one have you ever tried to use Ansible with Docker? I haven't I've used Docker but I haven't and I've used Ansible but I've not combined the two yet what would you like to do? based on what you're doing with Vagrant I want to figure out how to do with Docker because I'm trying to move from Vagrant to Docker so I know that you can manage your Docker instances or images using Ansible and use that to deploy into those images as well but it's not something I've actually done myself yet thank you great job there's an open source project Roots Trellis that's like a full featured Ansible set of playbooks even production ready but I was wondering did you know of any more or do you have like any open source set of playbooks for WordPress? there are a couple and I haven't actually got the links on me but I will dig them up afterwards if you want to come and see me there are a couple of very full featured ones there's so many different ways to do this you find something that works for yourself but there are a couple of playbooks come and see me ok thank you any more? Vagrant, Ansible and Puppet or Chef? so I'm definitely going to be opinionated on I've used Puppet quite extensively I disliked it because mainly because of the amount of Ruby in it the manifest that you would write within Puppet were basically full blown scripts with extensive logic and I would find them far too complicated for other people to understand and sometimes a bit magical ansible to me is a lot more logical and does things the way I would do them if I wasn't scripting it how do you handle keeping database credentials and stuff like that out of your repo but still have them accessible to ansible when you do your deployments ok so there's two solutions for this the first one is to use environment variables so I specified the variables within the playbook but you can also do them directly through the environment the second option is a ansible module called Bolt which will store details encrypted so that they can be committed or passed around within the team but they're not visible until ansible actually runs any more? ok that's it thank you