Build an IoT application with Node.js and Docker

i'm shubra i run product marketing and developer relations at joint and i'll be joined by quite a few developers uh wyatt show fans wyatt is my colleague is our lead node.js engineer and he has been a active contributor to different frameworks like happy seneca um and you know even for the microservices that we run ourselves at joint and even myself i've been in the express community and i've worked on frameworks like loopback and api gateways right so just to give you a context so the workshop today is going to be focused on building an iot app and we'll be using a variety of technologies i'll walk you to that stack but before i do that um you know want to put a disclaimer we are not going to be talking any proprietary or closed source products at joint ourselves we have been the progenitor of node we are kind of the first to incubate node.js and we are also the founding member of cncf and we believe that the entire cloud and all the technologies running within it should be in the open right and we are entirely community driven so with that um i want to you know give you our point of view on how we see the legacy stack and the modern stack and this is based on people we are working in the community our customers as well so if you look at the legacy stack right these were traditionally monolithic web apps and we're running code on different kind of blocking and bloated platforms right you could say jvm clrs what they wear and traditionally these were deployed in virtual machines right if you go back like 10 years and running inside a private data center now if you flip the stack like when you talk about modernization the app services are more message driven there are more micro services they are built for mobile first right you don't really build for you know they are build responsive they are not just built for the web you are building them for iot workloads as well as artificial intelligence workloads right and we can go to dirt i'm just gonna skim through a lot of these topics from a coding perspective you know you'll see the rise of node.js golang and a lot of different lightweight runtime platforms or languages the whole idea is like can you support concurrency can they work with async workloads right and from a runtime perspective you know if you take the case of microservices there's a perfect fit where you want to run them on containers if you take the case instance of node.js most of the processes are running single threaded running them on a traditional vm is probably an overkill so you probably want to just package it run it you know in package it in an immutable fashion push it to the cloud run it on a lightweight container right and the infrastructure supporting that is you know that's kind of you know i don't have to preach on that that's essentially cloud right now but there are differences in the cloud right so some of the projects we work on and we'll be discussing these in the framework of this workshop if you look at node we work on node core rustify these are restfusa framework d traces essentially a universal debugging tool that you can use in production happy you know it's another api framework mdb was again for memory leak debugging we're also going to talk about express gateway which was recently launched as recent as last week and again we have been investing we are polyglot ourselves we are not a hundred percent note shop so if you look at tooling and live projects that we are working and particularly in the golang community these are around terraform around um you know particularly for provisioning our containers for console for service management vault for security prometheus for monitoring uh packer and crypto and other core libraries and on the container side you know we started with containers 10 years back right we were running infrastructure or bare metal containers and then we put a docker but we had to make it run in production not like a mickey mouse like standalone project so we created the concept of an elastic docker host where we abstract the entire data center into a single docker host with a single docker api endpoint and you can just push based on a compose file or any artifact you have you can essentially push your application blueprint and get it deployed in matter of minutes and obviously we work on kubernetes and we have also created a micro app orchestration framework called as container pilot we are going to be using container pilot today right and finally on the cloud you know obviously our because our entire cloud is 100 open source we operate our public clouds but most of our users also deploy it on premises in their own private cloud managed private cloud settings and it's primary due to cost and performance so let's go into the details so there's a github link if you want to grab that url i'll be on this slide for a few seconds that's has all the contents of the code and the exercises so it's github.com joy slash joint slash summit workshop and just a show of hands if anybody was not able to get that all right perfect there are some prerequisites for this workshop we'll be primarily be using node.js so you'll have to install node.js if you haven't already you should while i'm and you can do that like when i'm walking through the rest of the slides uh you need to at least have a local docker install i think those are the primary uh prereqs and optional uh you know if you really want to push this out like once you test it on your laptop if you want to push this out into a public cloud um you can essentially sign up for joints public cloud we have 250 free credits and we won't be charging anything for the workshop right so but again that's optional if you really want to test it out like how it works in the cloud make sense so i'll just hang on to this slide for another few seconds so that you have the urls perfect all right so what are we going to build today we are going to build an iot app and it's a highly distributed micro service app uh we'll have a variety of uh end points that we'll consume data from so you know we'll be using um sensor data and out of the sensor data we'll be using a home automation platform called as smart things and smart things you know sells you sensors for you know motion sensors humidity sensors what not and once we get all that data we'll be uh monitoring uh the data feed that is coming in we'll be storing that into a database that's where we'll use influx db and we'll also gather some monitoring data for using agents like prometheus and then we have a variety of other components you know including an api gateway including redis and then we will all of these services um that are interconnected with each other uh each of them is running on a container of its own and we will orchestrate this and we will scale it out right so we'll start from scratch build you know test integrate deploy and scale okay so just few of the technology stacks that we'll be covering today right if you want to take a picture you could so at the very top right because we are consuming data from a smart things sensor and like we are not going to use real smart things we are going to simulate that data right but it's kind of the same experience if you had to get it from a real home automation system right to protect all these apis we are going to use a front-end component called as the express gateway and i'll get into the details of that this project was launched last week and we have uh irfan from the gateway team just raise your hands so you know if you have follow-up questions uh you can reach out to him on the express gateway we also have al al sang from the express gateway team so you know they're here to help and again with me i have wyatt and we have colin um his hands and we have fires as well so if you have any node questions or container questions you know reach out obviously we'll use node we'll be using frameworks like happy and seneca seneca is a microservices framework all written in node.js uh from a backend perspective like from the front end essentially we have prometheus endpoints and on the backend we'll be using influx db to store time series data and from a container perspective we'll be running traditional docker however to wire uh our entire application blueprint and to deploy it and scale it we'll be using container pilot and finally you know the option where we push it to the public cloud we'll be using uh triton from joint so when i get into all of these let's quickly run through some of these key concepts right i just showed you a bunch of technology and then we'll start really working the exercises so just architecturally how is smart things laid out right so it has a bunch of sensors and if like every um you know iot home device manufacturer this is not like industrial iot this is really home automation you have a hub right and the traditional way these connects uh there are a variety of protocols there are zigbee protocols and whatnot uh where in all of these devices that are present at your home they connect to a hub right and based on those connected connection endpoints then you essentially have device handlers and then you send up the data through an api gateway and that api gateway is consuming your events data and pushing it to a cloud processing system and on the cloud side and this cloud could be running anywhere traditionally it's a public cloud you have a set of core apis which let you not just monitor the data but if you have to take actions on your devices like hey i have a thermostat which is reporting 75 degree fahrenheit and i have to control it down i have to push it down to like 70. or maybe i have like a philips hue bulb right which i want to dim so there's an action that you need to take and that api call comes through an api gateway and then the api gateway communicates the same to your local hub which is sitting at the edge and then the edge hub translates the protocol and then sends out the control logic to the device that you want to control right so this is a very high level architecture so that's one component that we're going to use the second component is we talked about the express gateway so showa fans who has used express js pretty much everyone right um so brand new uh gateway it's an api gateway which was built on top of express was launched at a meet meet-up last week and highly successful and like all the core contributors of express like doug wilson and everybody is behind it um even from a joint perspective we are started pushing prs and we are actively contributing to it right and you have al's company lunch badger who is kind of the core maintainer and net net if you're really looking at uh you know what does the gateway do right you have a set of endpoints that you're protecting so there are functions like authentication authorization right you use a variety of tokens and then you have to configure policies right so when the apis come come in you set a you define a policies a set of policies which are applied on the pipeline of api calls coming in and if you start going beyond that then you have to really talk about role-based access control like you know on these apis what kind of permissioning you have right is it read write update all the cred permissions and then when you start going beyond that then you start about go around metering right so if you're still you know putting an api gateway in front of your api service you can actually meter the calls and you can extend this to charge back you can use extend it to throttle right saying hey you know what this is one public api endpoint and i don't want um you know all of these internet population hitting this end point maybe i can create on the load balanced one right so you can check this out i'll not go into a lot of details into this because we have a lot of ground to cover but this is one of the key components that we'll be using uh micro services you know we are here to build micro services just show off hands who has built a micro service running in production okay a few of them so you know i don't need to be preaching to the choir but essentially you know this is a very simple visual representation of what i said earlier you had a set of monolithic services i have written monolithic services myself traditional soa architectures where you had an orchestration bus and you had uh you know end points right these were essentially web service calls that you were making uh but again they were like um they were packaged they were not essentially like you didn't have a particular service endpoint for a particular small api call where you could just manage the whole life cycle so if that endpoint went down right you didn't really you know uh you couldn't just work on it and bring that back again uh you essentially had to work um you know recovering the entire uh soa tier right so these micro services you know right now the way you build it you know there are different variety of frameworks out there but once you start scaling these micro services um you know particularly on the container platforms there are frameworks like kubernetes any kubernetes users here this one okay so there are frameworks kubernetes came out of google there's you know docker swarm there's misos where you essentially can orchestrate right how you deploy these and how do you scale these um on containers right and this is a brand new stack right it's not on vms and you know these containers you know you could be scaling but it's not just scaling horizontally you have to account for what happens if around managing the life cycle of a micro service so we'll talk about that in a bit so this is a layout of our own cloud so joints entire cloud is built in microservices we did it like eight years back when nobody knew the term microservices uh we were built on ruby on rails so all of the ones that you see in green right whether it's actually at our external endpoint whether it's in our middleware our internal services or when we actually go ahead and access data we have object storage at the back end all of these are a set of apis and each api is managed by a standalone developer and a standalone team who can essentially manage the life cycle and all the way from development to build to deploy to scale and everything else right and we chose node.js and that was one of our primary drivers why we you know contributed and sponsored the project to use something for ourselves and then it caught on in the community and now it's in the foundation make sense cool another thing that's really coming to uh forte is going container native right so if you deploy containers on traditional vms right it's really a workaround that's not how containers were designed to run and that's not what will give you the efficiency of containers right so the stack that you see on the left is traditionally what most enterprises are doing today whether it's on-prem or it's in the public clouds and the reason is there was a lot of technical debt you had created your data centers and your clouds based on vms and you couldn't really run containers directly on bare metal um you could but on static bare metal but then you didn't have the flexibility of like how do you do cloud management and scheduling and all those features right if you really start going into container native and not just us there are other companies who are doing this as well instead of doing hardware virtualization using kvms we are going to doing os virtualization so we are essentially running a docker share very close to the kernel and we don't need any of the bin packaging libraries that or any of the overhead that you need for vms and we are running the app the docker app directly on that right cool another project that we are going to use today is the framework called as container pilot this is you know you can works with any scheduler if you're using swarm kubernetes or art triton or mesos but this lets you do micro orchestration so i'll tell you what that means um so when you you know create a bunch of micro services um you know it's not just start and stop right how and particularly when you're running these micro services in containers how do you manage the life cycle events so do you have you know health checks going into uh microservice how do you uh when when there is an event maybe there is a error or you know how do you handle that error how do you gracefully start it up and how do you gracefully stop it how do you understand the events when you know that particular micro service is choking and you need to provision more and scale out right so here's a very simple example um with mysql right it's a relational database um you would be using this in most projects very very widely used uh however like in production you don't want to be running one instance right you want to be continuously snapshotting your data and backing it up to some kind of an object general object storage so in our in this case what we are doing is we have one primary node and two replica nodes and we are continuously backing that data from the primary node to our manta which is essentially our object storage solution and you could do this on any cloud in s3 but then those replica nodes um you know we do async replication right and you can set this up on your own um now and on what we are doing is console we are using it as a service discovery uh tool right so when a client comes in and it goes to query it doesn't really go directly to the node it goes and queries console and says hey console by the way if you don't know console it's a tool from hashicorp you know similar tools are like hcd where you would use them in service management but console will say hey i have these three endpoints which are like all my sequel this one is the primary likes route the traffic there right so where you can see here that the call comes to uh from console to the primary and you're doing heartbeats so you're checking hey primary are you up and kicking right and as long as that's true the traffic will be routed there now let's assume that the primary goes down right and at that time you have a boot sequence where it says hey you know boot from replica but when that boot from replica happens console needs to be updated automatically saying hey now read out the traffic and get the data from the replica set and when and then i have to make those replicas aware and pooling hey does the as the primary come back again right so to do this you can use you know this is an entire pattern that has been created for application level micro orchestration um so this one essentially is doing monitoring right so the way we work is there are different type of events there's a you know periodic health check but you essentially whenever you provision a micro service you register the micro service so there's a registration event you register that into console and during the health checks you are saying hey are you the primary yes i am um should i just back up my data i said no you know i'm still in processing transactions don't do it or yeah maybe go ahead and do it and you know continuously tell i'm healthy i'm healthy i'm healthy now if something goes down the system has to self heal right all these micro services should be self healing because there are going to be thousands of micro services when you eventually go into the enterprise you cannot do manual type processing like you do it for traditional soa based services so what you could do is you know on that event that you see hey there was a change right and on the change what we said okay if the primary send me a change event maybe it went down first thing you do is stop replication right don't replicate anymore because i'll be sending corrupt data into my backup and at that time look at me i'm the primary right or should i just you know give up my lock or should i still retain my lock um so well you know you are down so you let the replica attain the lock and let that serve up right and now if i'm saying okay i'm back up again you know go ahead and retake the lock right but when you do this you have to propagate the changes upstream to your load balancer and to your service catalog so when we actually use this in context of the code that you're going to write today you'll see this how helpful it is and how simple it's going to manage so with that being said i'm going to turn it over to wyatt to walk you through the exercises and i'm assuming by this time you have node and a local copy of docker installed anybody who has not been successful doing that yet okay and we are here to help you know so we'll be walking around the floor thank you shibuya uh let me plug in here so you all have uh have you cloned the repo cool so if you look on the readme it'll turn this let me load this up if you look on the readme it lists the different challenges the first two are really geared to make sure that you have node installed correctly and then the second one is for docker so i think we'll probably spend about five minutes on each of those first exercises so if you if you look at the readme we're just trying to spin up a simple node application so the challenge is to start it with a port and in this case port 8080 which will be provided through an environment variable and once you have that up and running you'll you'll be able to go to your browser and see a chart with random data being displayed and if you have any questions feel free to raise your hand and we'll bring over a mic or just one of us will come and help you out there's also a solution file in each of the challenges that explains the solution so the pace of this will go like we'll spend five minutes on this first one and then i'll show you the solution and then we'll go to the next challenge and so forth but we want to keep this pretty laid back so again just raise your hand if you have a question or if you get stuck so i'm going to go ahead and walk through the solution to the first one it's okay if you didn't complete it because the remainder of the exercises are all using docker that was more of a test to make sure you have node installed and uh know how environment variables work so let's see here if i go into i'm going to make that larger for you if i go into the challenge1 folder so i have my let's see how did i set this up so i had already npm installed everything before i came here so i have that shortcut for me and then you can set environment variables just by pre-pending whatever you want before you run node so in this case i'm going to listen on port 8080 and if you go into your browser you'll see let's see localhost 8080 you should see a front end with this random sensor data and this is pretty much what we're going to see throughout the remainder of the exercises so while this will actually work with the smartthings hub we don't have a smartthings hub here especially for this many attendees and also the sensor data from uh like the real temperature data is kind of boring this is a little bit more exciting at least so anyway that's the solution to the first challenge npm install and then start node so the next challenge is using docker which is a little bit more fun so we want to let's go back to the challenge here so the next one we're going to dockerize that front end so this is just using that same front end that we had running it inside of a docker container and listening on a port again this will hopefully prove that you have docker installed correctly so again we'll give you say five minutes to work through challenge two and then i'll present the solution and if you get stuck just raise your hand how's everybody doing with that challenge is the network any better no well uh once you get that node alpine image that should speed up the next challenge hopefully so anyway let's walk through the solution here for challenge two so you're supposed to update the docker file so in this case we're building from an alpine distro of node which is actually the smallest one that you can find so i did that hoping that the network wouldn't be this slow but apparently it is so typically with your docker file on node you're going to copy over all your resources so your package your js files and then you'll need to run npm install so if you look in the solution here send a copy from that so we'll run npm install and you can see above this we had already established that the working directory is where our app was copied to and then i'm just going to run node period or node index or npm start however you want to start up your node process so that'll create the image that we need but we also needed the the port for the environment variable and that comes whenever we're actually only getting to the right folder and that comes whenever we're actually starting the container so i'll build the image which is super fast because i already have everything downloaded be cached and then you can run that image as a container so i'm going to set the environment variable with that e e and dash p is publish so i'm going to map the docker host port 8080 externally and then i'm going to give it a friendly name front end so that is now running if i run docker ps i can see so i have that image running and port 8080 is mapped so again if i go to localhost 8080 i should see the same front end that i saw whenever i had just node running locally okay so also in the solution it includes how to remove that so if you do docker rm that removes a container if you want to remove an image it's rmi so docker rm remove the front end so that's great pretty simple hopefully you all didn't get too stuck on the docker part so let's move on to challenge three where we're actually adding another container into the mix and for that we're going to use docker compose and we're also going to add in the express gateway which we've been talking about so the challenge here is to add uh to update the express gateway configuration to point to the two instances of the front end that we now have in the compose file so if you look in challenge three docker compose you can see that we are creating two front ends by having two different services front end one and front end two so we need to update the links for the gateway so that it has the correct ip addresses mapped inside of the gateway that represent the frontend one in front and two and then in gateway we have this configuration yaml file that you'll need to update with the the server and port for the front-end one and front-end two and since you're using links in this example links will update the hosts file inside the container with like a frontend one and then the ip of whatever that was started as okay so give you five minutes on this challenge and then i'll walk through the solution so you're going to use a different command also docker compose instead of just docker cool all right i'll let you get to it and again if you have any express gateway questions we have a couple of experts here so feel free to raise your hands all right i'm going to walk through the solution seems like things have sped up a little bit which is good so let's see first i'll update the links so just add front end one and front end two so that'll add a new etsy host entry for front end one with the ip address in the in the gateway container and if i go into here i can change the urls so this will the express gateway will load balance these two for me so let's see http and then the server will be frontend 1 and then 8080. 8080 and then let's go into the right folder challenge three and then it'll every time you refresh on the on 8080 it'll be load balanced to either the front end one or front end two and it'll just serve up either of those whatever you get at the time also i wanted to remind everybody that well i don't know if you were reminded of this at all but there's t-shirts up here and stickers popcorn come on up feel free to grab some yeah you can come up any time we have all sizes men's and women's help yourself so yeah you have to at least have completed challenge three by now though so there you go the first lord is your size right now we'll have more tomorrow at the joint booth up front so come on by if you want a second shirt or whatever one that fits so lynx is nice whenever you're doing local development but when you're actually trying to scale to more than just a couple of instances it's not not really a sustainable solution so as shubra was talking about earlier we have container pilot which takes out the issue of having to have a load balancer in between all of your services and relies on console which is a service discovery catalog and we'll use that we'll use console to discover you know what services are up and healthy and that's how we'll discover the front end instances so this next challenge is just to rely on the container pilot configuration to update the configuration let me show you that see so if you look in the gateway folder we have an etsy we have this json5 file which is just a very javascript friendly way to do json it just looks like javascript but anyway this is how we control container pilot so we describe what processes we want container pilot to start up in this case it's the gateway and since we're listening on a port container pilot will register the gateway with console for us and it'll start our server so a good way to think about container pilot is just a really useful container in it process so you have like tiny and dominant already that are made for running in containers for doing inet work container pilot is no different except it adds in the extra service discovery and health checking that you'd want to have so your challenge is to update the container pilot json 5 file here to add in a job to run this binary which gets copied which generates the and finds the front end addresses for you so yeah and if you look in the readme there's also links for the container pilot documentation but anyway i'll give you say 10 minutes but your main goal is just to add another job here and then spin it up and you should be able to go to port 8500 to see console and you should also be able to scale the number of front-end instances you have to whatever number you want and it'll automatically update the gateway and the gateway will load balance everything for you so 10 to 15 minutes and feel free to raise your hand if you have any questions so i'm going to go ahead and jump to the solution on challenge 4 mainly because challenge 5 is much larger and requires a few other images and our internet is not the fastest so let me go ahead and do that so you were supposed to add in a new job to run the generate config for you whenever you're starting up so you could do it just like this which would work but ideally you would also add in this extra part which tells the gateway not to even start until after i've been able to see until after this pre-start job is successful so we won't even start the server until we actually have some front ends to balance too and then we already had a watch down here so anytime so this last job let me explain that sorry the last job explain or will run anytime there's a change with the front end so if there's a change in the front end inside of console like you added more instances or one of them became unhealthy then the gateway will be notified about that and will execute this on change front end job which will just regenerate the configuration for us which was not entirely necessary for the challenge but it's good to just have that kind of responsiveness built in so if we start it all up we should just have one instance of the front end and let me show you i don't know did you all go to a console here on port 8500 if you didn't this is what it'll look like here when it loads so we have console registered here then the front end with two help passing checks and then the gateway and we can go to the gateway which is listening on port 8080 and we just have that one front end that's balanced but you can also scale the front end to say three instances so we'll create two more instances of the front end and those whenever they're healthy will register inside of console so if we refresh console here you can see now we have six passing health checks for each of the instances and then the gateway would have been notified that there's a change in console and we ran that generate config which went out to console and grabbed all the healthy addresses so now if you refresh the front end you should get balance to another back end and so on and so forth so the next challenge really builds on this and adds the other services that we actually care about so that the the dummy data is not just coming from the front end it's actually coming from a serializer which pulls the data from a worker which then pulls it from the smartthings hub so we'll just move on to challenge five which is a little bit more involved let's see let me zoom out a little so there's two parts to this you're supposed to update the sensor so if you look in the folder here for challenge five you now have see the front end we have the serializer and then the sensor which is the worker that pulls data from nats which is a message queueing service and pushes it to the serializer so your job is to update at the bottom here we have this write data function so use a module called piloted which will talk to a console for you and we'll handle that change event automatically so add in here something that uses piloted that pulls down the serializer address and then also you'll need to update the the container pilot configuration for the sensor so that it has the on change for the serializer plugged into it and since this involves a few more images i think it's probably going to take another 20 minutes or so but this challenge really encompasses i think a lot of what we're going for in the overall workshop so i'm going to give you more time on that and again if you get stuck feel free to raise your hand or if you just have any general questions also raise your hand so i realized i left you kind of hanging on the what pilot it is or why you even use it sorry about that so piloted is just a module that will do the load balancing for you inside of your service since we don't have any load balancer that we're going through we need some way to distribute you know our requests and and so piloted has a pretty simple api you can do piloted.service and just the name of the service that you care to get so in this case the serializer and it'll bring back the next healthy address for you for the serializer so in this case yeah we'll do serializer equals that so serializer in this case will have the address and port from console of the next healthy instance of the serializer because we can scale to multiple instances now if we want and the nice thing about this is we actually since we don't have a load balancer we can tell if there are any healthy serializers at all so if there aren't any serializers we can do what you're supposed to do in a microservice which is be able to you know respond to failure so in this case let's say we don't have any serializers i could return early and maybe try this again in like a second so i don't know set timeout and then write data this is of course going to consume more memory but but it'll work so that's the example there i think that's right so then the other part of the challenge again was just to update the the container pilot config which i'll leave you to that and downloading the images but any questions on piloted or why you'd use it or does that explain it okay cool so i'll show you the rest of the solution in say five minutes does that sound good to everybody i'm gonna show you the solution to challenge five here and then i'm going to go through the next two exercises since we're low on time and just show you those solutions as well which builds on what we already have here and then i'm going to hand it back over to shubra to close it out so let's see so we already have the serializer update done and i was talking to colin back there and he was pointing out that this is probably not a good solution because it's going to buffer up the data and memory and eventually probably exhaust exhaust your memory so since since it is sensor data and you probably don't care about it so much you could just return early and be done with it the other part of this was to update the container pilot configuration so that it responds anytime there's a serializer change in console and the way we do that i'm just going to copy from the solution file so we'll create another job let's go back so we need to create another job similar to what we have here for nats which says anytime there's a change to the serializer we're going to send a sig-up signal to node and that'll not restart the process but it'll just send that signal and then piloted will handle it and go out and fetch an updated list of healthy addresses from console because something changed and the other part was to add the actual watcher so container pilot will use these watches to just query console for changes to serializer or gnats so that allows us to let me go to the right folder here that allows us to spin up new instances of the serializer or tear them down and the sensor will be able to handle those changes which is very powerful okay so you can do docker compose up oh i think i have my previous one still running so so kill everything bring it up with the all right i'm gonna kill that ah challenge for so this is a good good habit make sure you remove everything from the current challenge before moving on to the next one which is what i failed to do there so challenge five docker compose up dash d so there's quite a few more images in this one we have influx gnats if we go back to the front end again we can see in this case since we don't have all the workers running we should just see the temperature data coming in wait for that to load and also if we look at console now we have more services that are registered so now we have smart things gnats so yeah we have the temperature sensor done because we have that worker added the next challenge would be to add the other workers so humidity and motion and the way you do that is to update the compose file so if you look down here we have temperature which is using that sensors folder so we can change this to humidity so add a new service named humidity and we just say the sensor type is humidity and it'll start subscribing to the nets message queue for any humidity messages and it'll report those into the serializer so if i do up again since i just added humidity give it a second here actually let me go to the next challenge since it'll be cached after me bring it all down so the next challenge would just add those two and then you'd see the data flowing but it's just essentially just copying and pasting from the temperature docker compose service here so the last challenge which is what i'm going to show now is adding in telemetry reporting so container pilot in addition to using console for service discovery also has telemetry support for prometheus so you can add in any metrics that you care to report on so if you looked at challenge seven say the front end you should see there's like a memory script here which will report on how much free memory is inside the front end container and if you look at the configuration for that we now have this telemetry entry so this will listen for on port 9090 and prometheus will know that there's telemetry data because we're registered inside of console we have a new entry for container pilot and then prometheus goes out and pulls all these metrics down and we'll report on them so i want to show what that looks like which is actually pretty powerful mainly because it's so flexible um yeah i'll just do that so again if you refresh console you'll now see prometheus whenever it comes along so it might be the last to come up and then prometheus listens on port 9090 and then you have these custom metrics that we just added so the free memory you can report on that and again this is completely dependent on whatever you want to report through prometheus and then if you scaled out the front end you would see more instances shown so scale front end say two and then if you refresh or execute that graph again you'll see more metrics coming through for each instance so that's that's what i have for the workshop i know we didn't get through everything but again you can take this home and and play around with it all the code's there solutions are all there and i also wanted to point out so you can deploy this to triton if you want in that final section and we also have another working example of this so if you go to github autopilot pattern we have tons of examples of using container pilot for solving the same type of problem but for other things like my sequel as schubru was pointing out we have jenkins we have wordpress but we also have another note example which is very similar to this one and it has a nice setup script and walks you through deploying everything to triton if you want to so that's what i have and i'm going to hand it back over to shubra to close us out and i'll be here throughout the week if you want to chat about any any of these topics or anything else thank you [Applause] um so all right folks i'm gonna wrap this up uh but that being said i think you're working towards different exercises and you have deployed it locally to your docker environment i'm gonna try and give you a quick overview of uh how we have architected uh triton so that if you want to push it uh to a real cloud and run it for yourself you can so essentially like when we build triton right we build it as a next generation of cloud and there are different ways you can run it right you can essentially build your own cloud your way uh with essentially open source software right so you can run it public you can run it private you can run different hybrid modes but there are three key components to it right there is compute and when we say compute this is essentially containers on bare metal and different containers like you know i'll go through that and then there is object storage that project is called manta so if you go to github um so you know github.com join slash triton that's essentially your compute and if you go to storage or analytics go to github.com join slash manta those two are the storage and converged analytics and converge analytics is a special project because if you really think of it right generally when people store object data somewhere and then you're running like big data jobs on that you essentially have to copy data over the network so whenever you are accounting for latency you have to take into account the time it takes to move data over and particularly if you're operating at petabyte exabyte level scale that's extremely time consuming so i'll tell you a little bit more architecturally but here's essentially a system architecture like how you can build your own cloud right so at the bot at the very lower and you will see the infrastructure which essentially is elastic bare metal what this really means it's os level virtualization instead of hardware virtualization and on top of it you are either running elastic docker host or you are running traditional vms right and even vms we essentially use kvm so you can bring your own kbm and then you can run any image on top right if you are really a window shop you can run windows on there but if you are running docker you can run rocker directly on the elastic docker host or you can bring a scheduler like kubernetes and make it work with that and so there are three different ways to run containers right so it's not like you know when you start speaking with other developers and ask them like what are you using to run microservices and containers like how do you decide um the first one that you see here kubernetes i've asked that in like devops conferences and show of hands like who's using kubernetes and 80 percent of them raise their hand and i said like why right oh because you know my co-worker told me to right you really need to take a pragmatic approach and say um hey you know what are the use cases behind it right if you are building a micro services application just like you were building now and you had a few end points right how many endpoints did you have like 10 12 those were the rest api endpoints start thinking about a large enterprise and a larger scale application where maybe you have a thousand endpoints and each of those endpoints need to run on a container each right and you need to orchestrate them at real time that for that kind of a heavy lifting i would think kubernetes type of a framework is a great fit but if you really want to run one container right having a small monolithic app or maybe 10 containers i think it's simply an overkill right or maybe you want to run stateful apps right databases or uh wherever you are caring about transient state and you know persistence i don't think kubernetes has yet nailed that right so that's where we kind of went category by category right so we created elastic docker host which is essentially great for if you're running you can run both stateful and stateless but it's really when you looked at container pilot uh with some of the use cases we talked about with mysql we are essentially dealing with persistent state right which you cannot do with a framework like kubernetes but if you really don't are really you know scratching the surface here and all you really care about is cost savings and performance you can just run bare metal but with the cloud flexibility right so that's where we have brought in this concept of infrastructure containers has anybody heard the term infrastructure container before this earlier this one guy yeah so if you have to do a little bit of reading right go search up uh lxc's right lxe containers or just pure infrastructure containers this didn't like docker didn't our containers didn't really arrive with docker in 2013 2014 people were doing containers like way back in 2006 and we originally used a project called open solaris which was derived from illuminos to build those but then there are the linux guys who have been using lxc containers to primarily achieve the same thing right you can have containers run them just like a virtualized infrastructure but you run them on bare metal without having to you know take the overhead off all the hardware virtualization and the bin packaging right so um another great project to look at i talked about manta when we get converged analytics so you can really store data at scale so joint like we got acquired by samsung and just as a use case right we are hosting all of samsung mobile's back in data and if you have to get some context how much how big that data looks like it's in exabytes a year right think about 250 million concurrent users pushing images videos what not to their phones and we are essentially tasking ourselves to handle that data right so one arm highly distributed open source object storage system so that's object storage but what we have done is a few years back when we ran this on a file system um we use zfs as the underlying flying sys file system and we were able to spin up a container in place uh where the object data resided so when you spin up a container what you can actually do with it is run a compute job right so hey i want to run a big data analytics right so let's say i have a map reduced job i want to run or maybe i want to do log processing or search text right just query the data um how do i do that right so if you just want to transcode the data hey i had these image files i want to create thumbnails of that or run any kind of arbitrary compute so because we spun up that container zone where right where the object data was you can essentially run converged analytics without having to move the data anywhere and when we did this we essentially followed the unix bible and said hey if you run unix commands you can write your own compute job you don't really have to learn a framework you could write your own compute job in awk right in perl or shell or any other language you can bring other languages but it's not framework dependent right and so i would highly encourage you to go to github check that out github.com join slash manta and net net right like with all these projects what we are really trying to build at the end of the day and we have built it ourselves we are trying to share this for the community is essentially build open and portable services right which don't have to be locked in into a particular framework a particular cloud or particular orchestration framework so these are some of the sample projects that got built by with container pilots so wyatt was just walking you through the github repo so check it out it's actually very simple to build uh self-managing and self-healing application patterns using this microservices and net-net i want to end by saying you know our goal is essentially to give the cloud back to the people and democratize the system and that's why we are here so you know we'll be at uh the booth in the rest of the conference swing by our boot talk to us and you know if you have not got any swag you know feel free to grab them i want to call out uh the express gateway guys one more time al sang and irfan and thanks colin and wyatt and fires for showing up and helping thank you [Applause]