A New Way to Manage Your Fleet of IoT Connected Devices
Connected devices are just a part of everyday life-smart devices, home automation, and manufacturing and logistics are some of the common IoT examples that are commonplace. And in order to help you take your IoT solutions to the next level to help your customers gain even more efficiencies, you need to understand the behavior of your fleet in real time, iterate your solutions to address any behavior issues of the IoT connected devices as well as continue to innovate your solution at lightning speed. Whether we are talking about home automation or industrial manufacturing, understanding your fleet of devices in real time is critical.
In this webinar, Ronald McCollam, Solutions Architect at Resin.io & Jack Zampolin, Developer Evangelist from InfluxData, will show you a new way to monitor, develop, deploy, and manage code running on remote devices-quickly, safely, and at scale.
Using Resin.io, you can develop iteratively, deploy safely, and manage at scale. With InfluxData, you can always have a direct view into the state of each of your devices so you know what changes you need to make to keep them running efficiently. The combination of these two solutions will allow you to focus on writing great applications without the stress of keeping your devices running correctly and up to date.
Watch the Webinar
Watch the webinar on a new way to use deploy, monitor, and manage your fleet of IoT connected devices with Resin.io & InfluxData by filling out the form and clicking on the download button on the right. This will open the recording.
[et_pb_toggle _builder_version="3.17.6" title="Transcript" title_font_size="26" border_width_all="0px" border_width_bottom="1px" module_class="transcript-toggle" closed_toggle_background_color="rgba(255,255,255,0)"]
Here is an unedited transcript of the webinar “A New Way to Use, Deploy, Monitor, and Manage your Fleet of IoT Connected Devices with Resin.io & InfluxData.” This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.
Speakers: Chris Churilo: Director Product Marketing, InfluxData Brian Mullen: VP Business Development, InfluxData Jack Zampolin: Evangelist, InfluxData Ronald McCollam: Solution Architect, Resin.io
Chris Churilo 00:02.086 Okay. As promised, it’s three minutes after the hour, so we’ll go ahead and kick it off and I’ll just help out the other attendees that are going to be joining us as we start this presentation. So today’s webinar is on managing your fleet of IoT devices with resin.io and InfluxData, and to kick it off we have our new VP of business development, Brian Mullen. Brian?
Brian Mullen 00:28.976 [inaudible]. I lead this development here, InfluxData, and we are very excited to bring you today’s session which was put together with our friends at resin.io. So the world of connected devices is changing pretty quickly. Whether we’re talking about a home automation or industrial manufacturing, understanding your fleet of devices in real time is critical, and so in today’s session, we’ll show you a new way to monitor, develop, deploy and manage code running on those remote devices. Our host for today is Jack Zampolin, developer evangelist at InfluxData. And also joining us is Ron McCollam, solutions architect at Resin. And so during today’s session, Jack will talk you through the two solutions and then conduct a brief demo. And as Chris mentioned, if you have any questions along the way, please feel free to submit a question through the meeting console. We’ll save some time at the end for some Q&A. And now to get started, let me hand it over to Jack.
Jack Zampolin 01:39.008 Brian, thank you very much. Welcome to Running the TICK Stack with resin.io. My name’s Jack Zampolin and we’ve also got Ronald McCollam here. He’s a solutions architect over at resin.io. So I’ll be doing some slides over here in the webinar area, and then I’m going to do a little screen share. So just to talk through what we’re going to be going over today, I’m going to give you a brief intro to what is the TICK stack, and then a brief intro to what is Resin, and then we’re going to talk about how to run the TICK stack on a Raspberry Pi using Resin and then go through sort of the steps to do that, and then I’m going to show you a running demo. And just a reminder, if you have any questions throughout this entire period, please feel free to ask those. Ronald and I will both be here to answer any specifics on either InfluxData and the TICK stack or on Resin. So let’s go ahead and get started. So, first off, what is InfluxData? What is InfluxDB? We’re a full stack of open source products for dealing with time series data. So what is time series data? Time series data is anything that comes with a timestamp. So, as you can imagine, whether or not you’re monitoring servers or IoT devices, they’re periodically kicking off measurements: temperature, humidity, or events, doors opened and closed, anything like that. No audio.
Chris Churilo 03:27.302 I’ll take care of it, Jack.
Jack Zampolin 03:28.343 Okay. Oh, thank you, Chris. So anything like that. And if you’re going to be dealing with time series data, the primary things that you need to do are collect it. We have an agent called Telegraf, it’s very lightweight and it’s plug-in based, so it can collect data from any one of its 80 different input plug-ins and output it to any one of its 20 different output plug-ins. So a very capable data collection and shipping agent. In this demo, Telegraf is going to be collecting metrics off of our Raspberry Pi as well as some metrics about the networking environment around it. A common issue that we run into when we’re dealing with IoT devices is trying to figure out what the network environment is like in order to help troubleshoot some issues.
Jack Zampolin 04:30.895 Another thing that you’re going to need to do with that data is store it. That’s where InfluxDB comes in. That’s the core of our stack and the first product we built. It’s a database that’s specifically built for dealing with time series data. There have been other time series databases in the past, Graphite. Even going back further, RRDtool, which some of you IoT folks might know. And there’s other ones as well, built on top of Cassandra, OpenTSBD built on top of HBase, and other time series databases. InfluxDB is the most performant open source time series database and also the most popular as well. And it’s excellent for applications just like this. After the data comes into Influx, you might want to act on that, so alert based on the levels of your measurements. Let’s say if the water level in your tank is getting too high, you might need to alert and kick off an action based on that-maybe drain the tank a little bit. And that is the job of Kapacitor. It’s a stream processing engine designed to work with our time series data stack. Kapacitor takes in an incoming stream of data from the database, it subscribes to data coming into InfluxDB, and kicks off alerts based on rules that you give it. And then the last piece of our stack is Chronograf. That’s a visualization and management user interface for the whole stack. And we’ll be demoing that later. And, finally, all of those pieces are open source. And then we do have a closed source offering, InfluxDB Cloud, which is a hosted version of our stack, as well as InfluxDB Enterprise, if you want to run clusters of InfluxDB on premises. So I’ve also got [inaudible] here on Resin. The way I understand Resin is it’s kind of a Heroku for IoT. It enables a git push to my devices. And, Ronald, do you want to speak to Resin here for a few minutes?
Ronald McCollam 06:51.787 Yeah, sure, I’d love to. Really what Resin is, is a way of managing and deploying code running on embedded devices that are out in the field. And Heroku for IoT is a great way of putting it. The whole workflow is really based around using the same tooling that you would use in web development or cloud development, but using that tooling on embedded devices. So you can write your code, work with it locally, then when you’re ready, do a deploy just with a simple git push and your updated code will land on those devices out in the field. And Resin uses Docker under the hood to manage the deployment and running of those applications. So application updates can be atomic. If you lose power in the middle of an update that’s fine because you’ve still got the old Docker container still running on the device, and it gives you the ability to roll back in case you do a bad push. So, even if you push an update that breaks part of your application, that may not be the best thing in the world, but the device will stay online and it’s safely running, so you can roll back or push another fix out to that application in the field and not worry about breaking your devices. So you can really think about-once you’ve built your application using this TICK stack, you can use Resin to push updates or security patches, or even feature upgrades, to that application, to devices out in the field, safely.
Jack Zampolin 08:18.716 Ronald, thank you. And I just want to say, working with Resin for the last couple of weeks, being able to remotely manage my Raspberry Pi at home has been extremely easy. I’ve set them up in a number of different configurations just hacking on various different projects, but I’ve not run into anything that’s quite as easy to get up and running as Resin. And we’ll go through what that workflow is like here, later in the webinar as well. So here’s a few links that you’re going to need to get started with this demo here. We’ve got the full code up on GitHub in the InfluxData resin-influx repo. And in order to deploy that, you’re going to need to have a Raspberry Pi running with resin.oi. And we’ll talk through that in a minute, but I’m just going to leave these slides up here for a minute and allow you guys to go check that out. [silence]
Jack Zampolin 09:52.645 Okay. So I’m going to talk through this setup and intermittently screen share throughout this to sort of walk you through the workflow here. And, Ronald, please stop me or chime in if there’s anything that I’m missing here. So the first thing you’re going to need to do is go to resin.io and start a new Resin application. And just to talk through this at high level, this is the workflow for pushing this code in the repo to your Resin device. So we’re going to start a new Resin application. We have to flash our Raspberry Pi with the ISO that Resin gives us. And then once we’ve installed that and plugged it in, it’s all web-based from there. So that’s the only IoT part there. Where’s my-? Here it is. Okay. So I’m going to screen-share here for a minute. There’s this excellent Getting Started Guide on Resin - Getting Started with Raspberry Pi. Follow the Getting Started Guide for your particular board. So I’ve got some Pi 2s and Pi 3s at home. If you’re doing a Pi 3, this is the right Getting Started Guide here. But, essentially, you just unplug your SD card, put it into an SD reader, and then move it onto your device. When you create a new application, Resin will give you a new copy of resinOS that’s specifically for your architecture and has some things baked into. So the ID of your application, so that when it starts reporting to Resin, Resin knows which application that device is associated with. You pick the resinOS version. You could also bake in some Wi-Fi credentials there, as well. So, if you have a wireless device that’s connecting to a network, you would put those in there.
Jack Zampolin 12:15.942 Yeah. And then once you’ve done that you’re going to use Etcher, which is just an open source tool to-it’s essentially a UI to help you with flash SD cards. You can think of it as like DD with a nicer UI on top of it. And then you’re going to use Etcher to write that image that you get over here onto your SD card. Okay. So, once that’s happened, you plug in your SD card, plug in your Raspberry Pi. It takes about 10 minutes, and it’s going to connect to Resin. And what that looks like is-I’ve already got an application up and running with a couple of devices on it and you should see it running. I have had this up for a little while when I’ve been testing this project here and you’ll see them online. You’re not going to see any code on them. That part you’re going to need to sort of get repo for.
Jack Zampolin 13:30.512 So let’s [inaudible] over to that part. This is resin-influx. It’s the project repo here. What this is going to do is spin up our full stack-Telegraf, InfluxDB, Kapacitor and Chronograf, all running on your Raspberry Pi. This has kind of meant as a starter project. InfluxDB and the full stack are meant to help you monitor and collect metrics, and being a Time Series Database, also serves those in its graphs. So you can think of this bundle here as just a way to help you troubleshoot your local environment and your networking stack and understand resource consumption. One thing to note, if you have an existing application that you’d like to add some monitoring to, installing Telegraf and having it shift metrics to either a remote or sort of a network global InfluxDB instance would be the right way to do that. And I think we’re going to have some future webinars where we talk through that as well, but you can look through the Docker file for a way to install Telegraf.
Jack Zampolin 14:44.450 So, to get started, you’re going to need to fork this into your own repo and clone it locally. So, for example, I would just fork this to my GitHub and clone it down. So, once we’ve forked it, you’re going to see a git remote. Add Resin at the top of your Resin project, and you’re going to just add the remote to your local fork. And then you’re going to push your project to Resin. And then after the code’s built and it’s pushed down to your Raspberry Pi, which takes another few minutes, you can log into your Chronograf dashboard. So let’s go ahead and check that out. So, once you’ve pushed the code to Resin, you’ll see some stuff in your build logs. You’ll have a few failed builds here. It’s not the end of the world. And they do save full logs for all of your builds, so it is pretty easy to troubleshoot there. And if you’ve got a successful build, you can check your device logs and you should see the device down here. All of the processes that start are there. So, once that’s done, you can grab your IP address, pop it in your browser and open up Chronograf.
Jack Zampolin 16:23.366 So, again, just to talk through the stack, you have Telegraf collecting data, going to InfluxDB, and then Chronograf is pulling that data to give you some charts. So here’s our Raspberry Pi, and if you’re running Telegraf we give you a bunch of charts for free. So system load, disk usage, disk writes and reads. And then we build some network statistics in here as well-ping response time. You can see that as I’ve been putting the Raspberry Pi in to load, those ping responses have gone up a little bit. Then you can see that as we loaded the dashboard here, the CPU did increase. So some nice monitoring metrics out of the box. There’s also a data explorer. So, if you’re just going to have this Telegraf database with a little bit of data in it, these are all the different plug-ins we have enabled-CPU, disk I/O. DNSQuery is quite nice. This is going to show you your DNS response times here, so an easy way to figure out whether or not you’re able to connect to the outside world. I have it, by default, pulling the Google DNS, but, obviously, any DNS servers, whether they’re local or any of the other large DNS providers you can connect to fairly easily. And you can see that as I’ve been warming up this demo, my DNS response times have periodically spiked.
Jack Zampolin 17:54.960 And then dashboards, we do have custom dashboarding. So, if you’ve got a few other devices maybe feeding data into this device, you would build some custom dashboards with your temperature, water level data, and this is the same editor as the data explorer we showed you earlier. So, for example, our DNS Query Graph. So we’ve got that. And then let’s pull this. Thanks. Next, we also have alerting. So I was talking about taking action based on your tasks, based on your data. Kapacitor gives you an easy way to do this, and we do have a nice user interface to help you do this. So the same sort of drilldown data explorer that you have in the data explorer as well as the dashboarding. And, threshold alerting, very easy to do. You can set your threshold at whatever you need. So this is CPU usage user. So, if my CPU usage spikes, I do want to receive an alert. Thresholding, relative alerting. So standard deviations [inaudible]. Dead man. If this stops reporting, please alert me.
Jack Zampolin 19:31.025 Obviously, if this particular device stops reporting, all of the code on it might not be running anymore [laughter], so you might want to have that kind of alert up in the cloud. So, if you’re feeding data from a bunch of different devices into a cloud InfluxDB, this would be the alert you would run on there. And, then, sending words to a Slack channel. All the data that comes out of the alert you can use the templates to feed that into a message to any operator. We also do have a number of different alert output providers: OpsGenie, PagerDuty, VictorOps, that sort of thing. And then there’s some additional administrative functions. So that’s the demo. And I do want to take some time for some questions. Also, if Ronald wants to run through any particular features of Resin or talk through common use cases here, I’d love to hear some input there as well. So questions?
Chris Churilo 20:41.954 Thank you so much, Jack. Yes. And, if you have questions, please make sure you put them in the Q&A panel or in the chat panel so the guys can read them out loud and we can get those questions answered. [silence]
Chris Churilo 21:27.727 This part of our webinar is always kind of funny. Sometimes we get really chatty people and lots and lots of questions, and sometimes we get kind of shy people. So what we’ll do is we’ll just keep the lines open for a few more minutes. And look at that. Just as I say that, a question pops up. Jack, do you see the question in the Q&A panel?
Jack Zampolin 21:55.705 Yeah, absolutely. Ronald, you might want to take this one. Can you please elaborate more on resin.io device management capability and cost?
Ronald McCollam 22:08.535 Oh, I’m sorry about that. I was muted. Absolutely. So the device management capability is really around deployment and management of software on devices. So what we build as resinOS is really just a strip down lightweight Linux install. So everything on that device, everything in resinOS is open source, by the way. So the whole idea with resinOS is to minimize the amount that needs to be managed directly on the device and limit that really only to the Linux kernel, the networking stack, and the Docker runtime. Really just the minimal amount to get containers on that device. Everything else, then, can be done inside of a container, meaning that we don’t have to do any sort of device reboots, or any sort of in-depth management of the host operating system on the device. It’s interesting. Because this is Docker containers, we can even do things like insert device drivers into the running kernel on the host of the device without having to do a reboot or without having to touch that base OS. So you can manage hardware directly from within those containers, but the advantage, again, is things like atomic updates, the ability to not brick a device if you do a bad update, and not having to reboot in between updates there.
Ronald McCollam 23:35.250 The one other thing I want to point out is that there are some capabilities and some functionality built into both resinOS and Resin that do make it easier for you to do things like load bandwidth deploys. We will do deltas from what is running on the device to what you just push to us, so you could have a 4-gigabyte image running on your device and if you make 1k of changes, we’re only going to deploy 1k of updates over the air, not the full 4 gigabyte image out to that device. Costing, it depends a little bit on scale. It is a Software as a Service, so the larger number of devices you have, the less per device we charge but it’s a very simple per user and per device charge that we use for Resin, and very happy to talk with folks more about that offline. I don’t want to turn this into a Resin sales pitch but yeah, it’s a pretty simple model. And I think maybe the next question is directed at me as well around Unikernels since the Docker containers. Jack, unless you want to hit that, I’m happy to talk about that.
Jack Zampolin 24:47.614 You’re more than welcome to take that one [laughter].
Ronald McCollam 24:51.096 Yeah, it’s something that we’ve got our eye on. Honestly, right now as Resin, we are fairly tied to Docker, mostly because it is where we see the momentum in the industry. There’s nothing specific to Docker itself that would restrict us to always having to use Docker as a component. We have explored things like Unikernels, we have looked at LXC containers. There’s a lot of different technologies that we could pretty well swap in and out of Resin if we ever decided that that was the right technical solutions. Having said that, Docker really seems like the right solution right now. It’s got a lot of momentum behind it, meaning there’s a lot of great tooling out there, a lot of great expertise, so people already understand how to work with Docker. And it really has a rich ecosystem that we can inherit from. So we can pull existing Docker containers, we can plug into existing Docker registries, things like that. We don’t have any plans to switch off of Docker right now, but there’s nothing in the technical infrastructure of Resin that would prevent that. And if that’s something you’re interested in, it’s open source, so we definitely love to see what you would do with that.
Jack Zampolin 26:08.577 And, Ronald, one more. We talked about Raspberry Pi in this demo. What other types of devices do you commonly see with other Resin customers or developers?
Ronald McCollam 26:18.173 Oh, good question on that, too. Yeah, Resin is a very cross-platform environment, so we produced resinOS for 25 or 30-some-odd devices right now. So, really, anything that has enough oomph to run Linux and the Docker runtime, you should be able to run resinOS on. So we produced resinOS images for Raspberry Pi, BeagleBone, Intel NUC and Edison, and so forth. Although those are, I think, going away now. The Edison’s being end of life. But really all of the very common IoT development platforms already have resinOS builds but it’s very easy to get that up and running on other devices or on custom hardware as well. Again, being open sourced, we sort of get to pick and choose where we see the most momentum and the most support in the industry. So we’re based on Yocto Linux, which is really the de facto embedded Linux environment. So anything that has a Yocto build already, it’s very easy to add to resinOS.
Chris Churilo 27:28.039 Looks like we have another question in the chat, probably for you again. Are you also looking at IoT gateway management and systems with resinOS?
Ronald McCollam 27:42.380 Again, it would be something that would be very easy to add. We tend not to add support for new devices or support for new functionality unless there are people that ask for it, but if there’s demand for it, we’ll absolutely look at it. And, again, not to keep harping on this, but it’s open source. So we’re very happy to have people contribute, or to work with people directly, to add support for new functionality on our new devices. I feel like I’m stealing all the questions here [laughter].
Chris Churilo 28:15.671 No. No worries [laughter]. So we’ll keep the lines open for just a few more minutes. If you guys have any questions, feel free to put them in the chatroom Q&A panel. [silence]
Chris Churilo 28:54.258 All right. Looks like we’ve got another question. So is device hardening also handled by resin.io?
Ronald McCollam 29:02.742 Yeah, that’s an interesting question. What I will say is that the resinOS, the operating system and the software that sits directly on the physical device, is absolutely as secure as we can make it. The state of hardware in IoT is still a little shaky in some places on the security front. As we see things like Trust.Zone, Trusted Boot-those sort of technologies-roll out to these devices, we’ll be able to do a much better job of adding secure password storage and things like that on these devices. Until the hardware support is there, it’s a bit of a different story. There’s a sort of a chicken and an egg problem with device hardening, where if somebody has physical access to your device, they can probably pull any data off of that device that they want. So we also provide a pretty robust system to let you deploy and manage devices and keys for devices. So, if a device is compromised, you can remove that device from your fleet without having to issue a patch to all of the devices. Just say, “I don’t want this compromised device being managed anymore. Just remove it from my fleet.”
Ronald McCollam 30:18.341 Beyond that, it’s really kind of up to you what you’re running in your application container. So we treat your application as a black box. We really don’t know what the right thing for you to do is, what’s right for your application. So, if you push insecure applications in your docker container to those devices, then you have insecure applications running on the device. So we’re not going to add any additional security to your application, beyond making sure that the OS on the device is absolutely as secure as it can be. We also don’t open any ports or anything like that. By default, everything is encrypted and so all traffic between the device and Resin is encrypted, all of the management, all of the log data that’s sent back is encrypted, things like that. So we’re secure as we can be by default, but it’s still up to you to make sure your application is secure. [silence]
Chris Churilo 31:23.852 Awesome. Thank you so much. So, as we just wrap up here, just want to remind everybody that I will put this recording up on our website, and you’ll be getting an email from us so that you can take another listen to this topic. And if you do have any questions subsequent to this webinar, just shoot me an [email protected] I’ll make sure that I forward those questions on to the guys and they can get them answered as quickly as possible. Alternatively, https://community.influxdata.com/ is also a fantastic place to put all of your questions from these webinars or our training webinars. And Jack is the owner of that, and he does a fantastic job of making sure that he gets your questions answered as quickly as possible. And, finally, if you have any other topics that you’d like us to cover or if you’d like us to go in a little bit deeper with topics like the one that we presented today, once again, just let me know and we’d be happy to facilitate. So, with that, I’m going to end our session today, and I want to thank our speakers. You guys did a really fabulous job, and I look forward to having you guys at another one of our webinar sessions. Thanks, everybody.
Jack Zampolin 32:39.406 Absolutely. Thank you, Chris. Thank you, Ronald.
Ronald McCollam 32:40.996 Thank you.
Jack Zampolin 32:41.696 Thank you, Brian.
Brian Mullen 32:42.479 Thank you very much.
[/et_pb_toggle]
