Docker Swarm or Kubernetes or Mesos - pick your framework! by Arun Gupta

Birgit you play it do it make sure I say again good afternoon all right I know this is the last session right before lunch but he soon should have some leftover energy from breakfast all right my name is Aaron Gupta I work for Amazon Web Services we're going to talk about darker and kubernetes what are the two frameworks and how we can choose between one or the other so I'm a docker captain I'm very proud to be darker captain there are about 70 of us around the world that are recognized by the company Gawker ranked because I've been talking about docker since very early version like 0.3 point footage I've written a book about docker I literally finished authoring my book for O'Reilly on kubernetes so I know a few things about both of those technologies and I've been a Java one rockstar for four years in a row so I know about these technologies so open you should get some tips from here I always end up learning more from the audience than I share with the audience so thank you for showing up so let's take a look at a very high level by the way this is not going to be a docker 101 I don't don't expect me to teach you the basic darker here how many people are using docker in some shape and form today cool okay almost 90% of the room for others I will say RTFM and I'll go find out your docker basics over there but at a very high level what is the docker flow now we have got three main components we got a client which is on the left here then there is a docker host in the middle and then there is a docker registry which is on the far right end of the day you want to run a container so the client says here on a container the container is for a particular image so you say the download this image and run the container well download is implicit in the run part of it but then you give the command to a host and then the host age oh I don't have the image I'm going to go download the image by default from docker hub which is the registry or hobknocker com it downloads the image on the host it stores the image on the host and it runs the container the client in that sense is completely stateless it gives the command it's a CLI under the wire it goes as a REST API which goes to the host and the host and that rest api does the right thing basically downloading the image from the hub or a private registry you know let's say host it on Amazon ECR it can download the image and once the image is downloaded it will run the container over there the entire state is essentially managed on the host in this case I'm showing a single host but this could very easily be a multi host solution as well and that's exactly where your orchestration framework kick in you don't want to build a distributed application on a single host because that's a single point of failure when you build it on a multi host that's exactly where you need hey I'm going to run a java application which consists of a application server or database server or caching different components and possibly multiple instances of those so your typical Java application is a multi container application in order to run that multi container application on a multiple host you need that orchestration framework that will basically not only do the container scheduling but will also be able to manage your cluster give you the life cycle management and all those operations so essentially what we will do in this talk is compare darker and kubernetes how are those two what are the capabilities pros and cons of each of those so what we're going to cover in this talk is first from the developer perspective we're going to cover the core concepts like when you are building the application you need to understand what the core concepts are cluster single master or multi master how do you do that you know service discovery and load balancing persistent volumes which is required typically for a stateful container and then how do i do my local development and then from the ops perspective we get a little bit into the architecture side of it how can I do a multi master how does my scheduling algorithm work particularly in a multi host environment what are my rules and constraints by which I can say run a container on a specific host how can I do monitoring rolling updates so we'll talk about each of these features in the stock jump straightaway you know in darker and darker swarm is a feature that is one of the features of docker engine itself at least starting with version 1.1 the way you downloader is you go to docker calm is a get docker and then there are there is a community edition and there is our Enterprise Edition Community Edition is typically what I use in Community Edition there is a stable which is done pretty much every three months or there is a edge build which is done once a month which is basically the bleeding edge build so I like to be on the bleeding edge and so what I have is darker ce4 Mac edge that's sort of my classification here now once I download the docker see for Mac here then I say docker swarm in it and that's going to start my cluster it's a feature that needs to be explicitly enabled and that's how you enable orchestration or container scheduling in docker I can I need to say what is the address where I might be listening because I may have a multi host a network card here so I just need to specify that address the yellow indicates that by default is going to be a single master the master gives me a worker token or a manager token I can grab the worker token I can say in what take this docker new node which is basically a new machine or a VM doesn't matter but then I can say hey this node is going to join the original master and by giving the worker token or the manager token I can create the cluster accordingly so very easy to create a multi node cluster using docker so here what I have is single master and five workers essentially I can very easily create a multi master cluster as well because in this case you can see there is a primary there is a secondary and five workers surrounding it from the client perspective when you're making a request you could make a request to the secondary it is automatically proxy to the primary and the primary is the one that is responsible for actually executing the results or scheduling containers across the different workers by default your containers will run on the manager as well but you can say in what the manager is only administrative in which case the containers will run only on the worker so those configurations are possible depending upon how you configure your docker host so some of the further core concepts now you have multiple masters and you know multiple workers over here all the managers so to say manager / master is no equivalent terminology but all the masters are configured in a rack consensus protocol it is highly recommended or a very strong design pattern where you have odd number of managers you know you don't want to have even number of managers because if the network splits then it's very difficult to figure out which one is the leader and so if you have one three or five number of worker managers in case of a network split at least one portion of the network has no more managers and they can select a leader and that's sort of defined by how craft consensus protocol works on the bottom layer what you see is your workers these workers talk to each other using gossip network and you can see the red ones are sort of one container and this is essentially one service spread over multiple hosts and similarly the green containers are spread across multiple hosts so service is a concept of docker where is a service can have multiple tasks and each task is essentially a container now how do i fire up a service let's say Java developer are going to fire up a wildfly container so all I will do is docker service create so docker is a CLI service is the main command and then I am saying create which is a sub command of service and then I'm saying - - replicas three what that means is create three replicas of this service I'm giving the service a name called as web and and then I'm giving the image so in this case basically it downloads the image on the three holes that have been identified by docker host and it runs a container on that there are ways by which you can influence where to run it but by default it pretty much works now certain concepts can happen where unknown may fail once your service is running or once a container is running out there what if the node failed dr. ho sees the desired is not matching the equal or the actual so you know it does a reconciliation in that case and it says oh by the way the node has gone down the heartbeat has failed some now reschedule this container on a different host so it's a declarative state of the service that you give which docker host and sure so you say three replicas doctor make sure that I'm going to run through the opticals if the host goes down well the host may not go down but the container may go down in that case if the container goes down same thing says hey desire is not equivalent to actual so I'm going to spin up the container based upon the scheduling algorithm and I will make sure the service state is reconciled at any given point of time you said three containers need to run or three exactly cars need to run and I'm going to run through replicas scaling the service is pretty easy as well I'm going to scale the number of replicas for the service instead of three now I'm going to run six replicas of the service so all you do is docker service which is my main command then scale is a sub command give the service name and then you see the number of replicas the docker service scale web equals six and that's about it that runs basically automatically scales it to six different replicas we saw the replicated service there is a concept of a global service let's say I want to run a single instance of a container on each node of the cluster so Prometheus for example is a good example where you log in service which reports metrics about your hosts so you can say - - mode equal global now it's running a single instance of your service on each node of the cluster and if a new node is added to the cluster it will automatically have that service running or the container running on it so think about replicated service versus global service what do you want to start typically deprecated service is what you intend to start that's my sort of core concepts of docker now let's take a look at kubernetes now kubernetes is again a scheduler or container orchestration platform the typical confusion is scheduler is the concept where the core of the orchestration platform says I know how to schedule the container and different hosts but if you up level yourself the orchestration means you are also responsible for the cluster management and those aspects are certificates etc so kubernetes and docker both are in that sense orchestration platforms but they also have a scheduler built into them now kubernetes is container agnostic but pretty much 99% of the times the occur is the primary container that they're using anybody familiar with Rocket container here anybody using Rocket in production there was one hand that went up familiar with Rocket that's pretty much what I have seen and it's okay because by default I've been giving this talk workshop for almost two two and a half years now that's pretty much the consistent feedback that I've seen in terms of rocket adoption so yes kubernetes is container agnostic but pretty much docker is sort of the big gorilla over there that's the container format that it supports so in terms of kubernetes you have a node and the node you have a docker host running so to say kubernetes defines this concept of a pod pod is a co-located group of containers that share IP storage volume name space so to say together where all the containers are running in a pod they can talk to each other using localhost they don't have to rely upon an IP address but what that means is or what that doesn't mean is rather you would not put your database and an application server and a cash-in together in the same pod they need to be in separate parts because the scalability requirements are different so you would put for example maybe a wild flight container and maybe a login container or a proxy container or a cache container over there but that's about it so you really have to think about your unit on which you want to scale and that's basically what define the pod now you would typically wrap your part in a replica set because you want to run a certain number of replicas of the pod so replica set is basically saying okay run so many replicas so the way we have endorse a docker service scale instead of that you have a replica set here how do we start this how do we run this how do we create this hang in there for a second now pods just like containers are ephemeral what that means is if a pod on a host and it comes up on a different host it may be assigned a different IP address but as a Java developer if you're building a java application and relying on a database you cannot really rely upon the IP address so the service comes in service is a single stable name for a set of pods and it also acts as a load balancer so you can say here is the DB service name so I'm running to culture based parts I cannot rely upon their IP address but I what I will do is I will refer from my java application to the DB service and then behind the scene it will do the load balancing for me and pick the right part for me and how does it done essentially what you're saying is now I each part when it comes up the part has a certain label those labels are stored in HCD which is a distributed watchable registry and services I am watching for those labels so the pods and the service they really talk to each other using very loosely coupled model of labels essentially now the start from the developer perspective from the mode from the ops perspective if you look at it how is my kubernetes cluster set up well there is a node that we need there's a worker node just like docker and a master node node is essentially a machine or a VM in the cluster master just like docker there is a master which is a central control plane which allows you to manage the entire cluster by default it runs as a single node master but there are lots of new tools coming along which allows you to create a multi master cluster as well and on the worker of course you know where your containers are running now in case of kubernetes pods only run on the worker as opposed to docker where it was running by default on the master as well the when the worker is running the docker host is monitored by systemd on sent OS or one it on BB and depending upon the operating system that you're doing so that way you know you have some integration built into the operating system core life cycle as well so if I were to look at a broader kubernetes diagram how it's going to look like so of course I have a master master has my key components like API server essentially I have a queue cutter which is a CLI by which I create the stack I have a dog or CLI I have a queue cutter CLI that cube turtle CLI allows me to create resource in kubernetes the Q Carell CLI gives a command to the API server that okay create a part create a service create a replica set behind the scene it goes as a REST API to the API server API server then talks to the controller manager oh you mean create a replica set and the replica set has such and such labels that means I need to look for the pod with such and such labels that that's the job of the controller manager scheduler on the other hand says okay you have identified that I need to create this part let me go talk to all the parts or the workers that are available and schedule the pods accordingly and tell you exactly where the pod need to be scheduled and a controller manager of course gets that information from HCD now you could have multiple workers so the API server really talks to the cubelet which is basically sort of the node agent so to say on worker of each node and that's how these nodes are pods are created so it requests to the cube cubelet then creates the part and then there is a proxy which is basically what allows you to access the application using the pause on the right side what you see is my client so my client is my internet so to say that goes to a load balancer load balancer front ends my proxy and then it reaches out to the part to actually give you your response back and then this is sort of the final animation on this slide where you can see this is my kubernetes cluster and these are how all the components work now you may not need to know all these things you know when you're creating resources but I like to lift the hood and see what's going underneath all right let's talk about a little about service discovery and load balancer as we said when you are running your java application typically there are multi containers application running on multi hosts so in case of darker we have this concept of darker compost that allows you to run multi container applications very easily what you do is you define your application in a docker compose dot Yambol file and in that basically you say here are the services that I'm going to define and in this services and here are the images here are the replicas here are the labels whatever I want to define we define all of that in docker Campos or Campbell there are multiple ways by which you can specify the service name override the file name all those things I won't go dig into the details but essentially once you have your darker Campos dot Yambol defined then you say alright take this and deploy this on a multi host cluster which was created by swarm earlier one of the beauties of docker Campos is how it allows you to cut down the impedance mismatch between your different stages so you can have one darker campos file there are ways by which you can have multiple darker campos files like one for now for example you have a base darker campos file then you can have the configuration file depending upon the pour the configuration values the different images which can then be combined together and then essentially cut down your impedance mismatch let me show you an example of that so here's a simple example if you look at it i'm saying on line one for for example I'm giving the version first of all on line - I'm saying what are my services line 3 and line 10 is where I'm saying these are my two services this is the DB service and a web service and essentially what I want to do is I want to have my web service come up and the web service be able to talk to the DB service the key part here is on line 11 is where I give is a simple Java EE application deployed in a wildfly container and all that Java EE application is relying upon is a culture base URI environment variable which is then pointing to DD service essentially so the T part to understand here is you can build some sort of dependency where you can say Oh have the DB container come up before the web container but that is only at the container level how your application reacts how your application starts up could be completely separate for example the wild fly container typically comes up in three to four seconds but if you are firing a potato based container it could take much longer so your application that resiliency logic need to be baked into your java application where it is pinging database hey are you up or maybe the database for example call space has a REST API by which you can invoke the REST API and say hey are you up if you are up then I'm ready to make an invocation so the container level dependency can be defined by service dr. Campos but the actual application level dependency and resiliency is developer's responsibility you can take this dr. Campos file and they can you can just deploy this to a multi host docker so essentially you have a big stack and a stack you will have multiple services and a service will have multiple tasks where each task will belong to it is basically a container running how does the load balancing work well in this case for example I could run a service I'm running this valve like container the key part to look at is the dash P 8080 colon 8080 so all I'm saying is expose a port 8080 on the host to 8080 on the container hey but I am running on a multi host how does 8080 work essentially for all the worker nodes it exposes a 8080 ingress port now when you are setting up a load balancer load balancer or host aware they are not container aware so essentially what happens is it exposes port 8080 on each of the hosts independent of whether the container is running or not because today the container might be running on a particular host but then if it gets terminated it may be rescheduled on a different host so what happens is from your client the request comes in to load balancer it can be redirected to any of the hosts and then if it's redirected to a host where the container is not running using IP tables it just automatically redirect it to the right host where the container is running so the single hop it's not a huge cost for you but it's very seamless in terms of scaling your services up and down because you are ensured that your requests will go to a host where a container is running how to service discovery work in kubernetes well a service as we talked about is an abstract or sets of pods and now using a single IP and a port is a stable endpoint let's take a look at the configuration file right away now the way we create resources part service replicas said all of that is using configuration files and if you look at this this service configuration file is broken into three pieces if you look at line 17 and 37 those three dashes indicate that there are three pieces to this configuration file one before one in between and one after now if you look at say line let's look at line 39 first it's a replica sec first of all that I'm creating now in the replica set I have some metadata from lines 40 to 43 then in 44 I am saying this is a specification of the replica set I want to have a single replica on line 45 then I got some labels in there and then finally if I go down then in that replica said I'm defining what containers need to be run I'm giving the replica set of the container unnamed wildfly RS pod essentially and line 53 is basically where I am specifying the container or the pod that needs to be done this is the exact same thing that we use for darker compost as well in here I'm using culture base URI which is my environment variable what does it point to it points to the Couchbase service which is then created by as part of the kubernetes configuration file so now if you look at say line 2 then I'm saying this is a service that I'm creating the service name is cultivate service I got a bunch of ports that I'm exposing over here the key part to look at is line 6 and 7 in the service I am saying hey these are the labels that I'm looking for label is nothing but a name value pair in this case is app : cultivation or as pod and where is that which pod has that label if I look at it on line 19 I'm creating a new replica set and that is a Couchbase part line 31 se is the image name and then line 24 el 25 through 27 says this is my metadata associated with the pod so now this metadata associated with the part and that's exactly what service is looking for and that's where the connection is being made and last but not the least as we said earlier this is sort of my connection where I'm saying hey use this service now think about this I got my service up and running and service has a set number of replicas I can scale my replicas replica setback background up and down but each part of the replica set will have the right label and then it will be included as part of the service accordingly so from a developer perspective you just refer to the service and then behind is back ended by the replica set that's cool to you so essentially I have a wall flight pod which is then talking to a cultivate service which then goes talks to the polish base pod in the backend yeah or just for fun I could have a front-end service talking to a Couchbase service which can then talk to a Couchbase back end so you could have multiple services and expose them now one of the concepts that we'll talk a little bit later is how a service by default a service for replicas set all of these have an IP address well at least pod has an IP address and so a service but the IP address is only within the cluster but if need be you can actually have a service exposed outside the cluster and we'll talk about that a little bit later now stateless containers are cool is it a good idea to run stateful containers there are lots of different thought processes you know if you really can run stateful containers yes you can scalability is bit of an issue sometimes you know how would you scale it if a container comes down particularly in a database world how would the database rebalancing restarting etcetera would work it a lot of it depends upon the database architecture but let's take a look at it what are my options for running stateful containers or persistent containers now there are in docker there are four different methodologies that you need to be aware of there is implicit per container what that means is if you fire up a stateful container say Couchbase or mysql or mariadb whatever it is then you can fire up the container it has a default sandbox that means the state that means anything stored into the database is stored into the container itself what that means is this container goes away data is lost or you can create a explicit volume so you can say Gawker volume create you can create a volume and then that's where the data could be stored or you can say I can do the volume mapping where you can say whatever is stored into the container actually map it to a directory on my host so if the container goes away the data is still with me on the host or you can do a multi host which is a more reasonable solution for a production environment where you can say yes my container is running on a multi host but I would like to store my data on a network somewhere where the mapping could be automatically done so those are sort of the four approaches now by default if you are running it on implicit per container the data is stored into war lib docker that is the directory where it's stored or worldly blocker volumes on the host when you explicitly create a volume then again the data is stored on war lib docker volumes per host of course is mounted within the container now all you're saying is like for example I know when Couchbase is storing data is opt call space war all I'm doing is hey mount that opt call space war to slash tilde culture base or tilde slash culture base so then you mounted a container directory into your host and then if you're doing multi host and there are lots of solutions like SEF cluster FS and NFS what happens if a container crashes well of course in this case the directory is unavailable because the container has crashed yes you can get into the VM where the docker host is running and have access to the volume is you tend to lose it pretty fast in case of explicit per container the directory is unavailable but you have a means to be able to get to it because you explicitly created the volume in case of per host of course this is on your host so you have access to it and multi host access to in case of host crash of course the implicit the first two cases the directory is gone but in per host of course the directory is gone too but when you get to the multi host then you still have access to it and this is sort of the last thing that I want to share here is in terms of running persistent containers so if it is shared then of course your well weather is shared or not in terms of implicit sandbox that volume cannot be shared but in case of explicit volume you can share the volume but it really depends upon whether your database is able to handle that shared volume or not and then in terms of per host and multi host there are similar strategies as well so I think it's very important to consider when you are doing stateful containers sort of these are the strategies that are available to me one of the concepts that I also want to talk about is docker volume plugin which basically goes with the concept of docker batteries included but replaceable now by default when you run a docker container it says hey you fired up a database container allowing you to save the data into the container that's the default behavior but now I want to change it and change it as in I want to write it to a network drive or one do something else so that's sort of what this concept is so there is a default driver for host based volumes you can use a plugin to be integrated with external storage systems so you may want to store the data on EBS or GC persistent disk or whatever comes to your fancy so this is one of the architecture you look at the blue boxes that is available to you by default which is darker client talking to docker host and there is a local storage engine that is available to you where the container is storing the data but if you an extend it you can use plugin client or plugin daemon which connects to the docker host and allows you to store data on a variety of network storages or whatever kind of storage you are not tap into so the one that I have played with is port works port works basically comes in two flavors it allows you to write stateful containers so you can have the one that I trade with this px dev and essentially px dev is a container that you will run that will tap into the docker host and allows you to store data very easily on Amazon EBS and there is a port works client which essentially allows you to gather the more state about the container and the different volumes that are attached to a host now look at my blog blog blog dot or own gupta dot me and i have lot more details about how this entire footworks driver would work with docker for example in terms of kubernetes the directory well kubernetes again the concept is very similar essentially what you have is a directory that is accessible to your container or the container in a pod and the directory typically outlives the containers there are certain common types that are available to you you could have a host path you could have an NFS you could have the directory living on EBS and that sort of the important part now how does these volumes work in kubernetes is basically a three step process first of all somebody on the network you know an administrator essentially will provision the volume and that's called as a persistent volume there is a configuration file for that you provision the volume then the application developer will write a configuration file which is called as a persistent volume claim he says you know what I have provisioned the volume which is 50 gigabytes but now I need only ten gigabytes because multiple people can still share that persistent volume so here is my persistent volume claim and then finally in your application which is your pod or your replica set or whatever it is you're going to use that PVC so it's important to understand it's a three-step process persistent volume PVC and then finally using the plain so that's something to keep in your mind and but that really gives you that scalability part of it and again I have a link over here this is where I blogged about when I used to work for Couchbase but you can definitely take a look at it how can you run stateful containers so essentially here if you look at it I have a kubernetes cluster running with one master and two worker I gotta cultivate pod running up there which is storing the data onto my local worker in this case and the purple box says I can expose the service to network externally now in this case you know that is sort of the recommended model that you know if you are using color space then the data should be stored locally on the device itself but if need be I can move that out to EBS as well and that's sort of the scalable model essentially but then of course there's a network cost associated with it because now you are storing the data across the network as opposed to on the host so it's a lot of considerations that you have to think about it when you're actually adopting the continuous solutions essentially you can do persistent containers with port works on my github repo there is an example detail example which says how can you do stateful sets that's the terminology that kubernetes calls it now as a 1.6 well it was introduced in 1.5 which used to be pet sets in 1.4 was introduced as the Alpha terminology but 1.5 the change into stateful set and now in 1.6 is a beta concept so take a look at this blog it does talk about how can you create a stateful set using port works on kubernetes so if you are into persistent containers that will give you some idea over there let's talk about the development aspect of it now as we talked about it docker has two versions c e and ee in terms of c e we talked about the stable version which has done every three months there's the edge version which is done every month starting with 1703 which is 2017 march when this is 1704 1705 1706 and the cool thing is you download RCE for mac edge for example is a dmg now it just runs as a docker on your taskbar and it automatically updates you know if there is a new edge build available it just pushes out to you so that makes it really easy for you to get started with it if you're looking at docker see e again it has three different options essentially for you to look at you can do it for desktop which is C well with a Mac or Windows then there is a server which is a variety of Linux and then there is a cloud so you could run for example docker for AWS which is essentially a CloudFormation template and then there is something for Azure as well in kubernetes I prefer to use mini cube many cube is a good way for me to get started if you want to do a single node kubernetes cluster so I pretty much use mini cube quite heavily you know whenever I'm doing development with kubernetes that's a good way to get started for a multi node cluster there are plenty of choices actually Cox is the sort of most prominent one that is you know being actively developed it allows you to set up a multi node kubernetes cluster on AWS as of today but there is experimental support for coming for GCE and other cloud providers as well there is a cube up which used to be able to start kubernetes cluster but that is now getting deprecated but then there is tectonic installer by core OS there is cube AWS which sort of kind of getting abandoned as well so this area is evolving very rapidly one of the areas if you wanna if you are looking at kubernetes on AWS there is a kubernetes AWS cig that meets every other friday so I would say Google and kubernetes Awl sake and join that sake you know if you want to see some difference on how kubernetes is run on AWS let's take a look at it how will we do rolling update what is rolling update mean so essentially what I have is I have a multi node cluster in that cluster I have a particular version of an image running let's say wall fly app colon one now all I want to do is I want to do a rolling update where one by one I want to change all the images from one version to second version so the command that I gave for that is dr. service update service name and I here I'm saying the new image is while fly : - and so that's part of my new image instead of whatever the older image was because it's going by the service name and then it's saying update two at a time which is update parallelism - and then he says after two images have been updated settle down the cluster for ten seconds and then go to the next state then update the next - so essentially what happens in this case it updates to wait for 10 seconds update next - wait for 10 seconds and then update next to that sort of simple rolling update that is available to you as part of docker how does rolling update work in kubernetes now as we said when you are running multiple replicas those are typically run as part of replica set or the previous generation replication controller now all I have is a replication controller created with version 1 now each pod in that replication controller has a label that is in HCD so essentially well now and then I have a application service sitting in front of it it says I'm going to watch this HDD and I'm going to take the pods that come as part of the labels and that's sort of the pods that I'm going to expose here now here I got three pods in this application controller the way rolling update works is you know you give the command now and full details are available on this my github repo which talks about it in detail but essentially what happens is kubernetes behind the scene creates another replication controller by the same name and append some dash dash xxx no images or some random characters to end of it so with the same labels so essentially what happens is now application service will have three parts from the older service and three parts from the newer service or the newer replication controller but kubernetes rather rapidly terminate the part once the new pods have been spin up then it removes the older replication controller and it renames an application controller so that sort of the process but well that happens for you behind the scene but the exact command is shown on my github repo so I would say you know if you're looking at replication controller that's the concept to look for let's take a look at the monitoring aspect of it now docker by itself has plenty of commands built into it you know for monitoring it so there is a simple docker container stacks CLI which allows you to say I want to monitor the continued attack so it basically gives you data every second and on a console and you can take a look at it it gives you things like CPU utilization it gives you like network utilization disk utilization so usual statistics but those are minimal though okay so that's important to understand now let's say you wanna get fancy data then you can use docker remote API so that's another aspect that you want to look at doctor remote API if you recall we talked about how client communicates to the docker server it uses a simple command but underlying it uses the docker REST API so rest slash remote in the same word essentially in this case so everything in docker is a REST API I know as you're communicating with the docker host so what you can do is you can use the darker remote API to get more data about a container that is running and again on my blog I have given lot more details about the Windows Server Windows machine as always a little bit finicky and a little bit touchy in this case so depending upon what flavor of Windows you are using you will have to configure docker remote API accordingly but on my blog have given complete details here is a container that I am running I want to use docker remote API to monitor the container and have given details about Mac Windows know how will you configure it now another aspect of it where you're running a multi host cluster you know what is for cluster what a host goes down or a container on a particular host goes down so for that you have dr. docker system events API so you can start monitoring that and it will give you more detail about your holistic state of the cluster so container going up and down service scaling up and down those are the kind of things now with docker 112 or 113 a TD I think which was sometimes last year in November I believe there is an inbuilt prometheus endpoint still in the early stages but essentially you silk start getting some more data it is N built primitives endpoint all you need to do is put our scraper in front of it and it starts grabbing data and then you can front-end with a very easy-to-use like elk or a Gibbon or some systems out of a dashboard essentially and last but not the least option is where you can use C advisor C advisor is a tool by Google c means container advisor and it gives you complete details about you know containers running in your docker environment now one of the things that C advisor is where it only gives data for last 60 seconds so what you need to do is when you're running C advisor to gather the data you really need to capture the data and once you capture the data that data needs to go into a time series database so like an influx VB or something like that and once you have it in flux DB then of course you can front-end weather elk or a Cabana or a Griffin or dashboard whatever you going to do with it so that's sort of and those options are again well documented and on my blog I talked about it how would you use si advisor to monitor your containers and plot a keep on a dashboard so this is sort of a preview of how the Prometheus endpoint looks like so you can see all sorts of different metrics that are available to you over here so if you particularly look two at the bottom on the left here its thoughts about HTTP requests and our response all those metrics that are available to you and on the right what you're seeing is some of the metrics that are available to you so this was running on my machine so you can see for example in the middle it talks about usage per core or the total usage you can get some fancy details there monitoring in kubernetes how does that work the good thing is it is big into kubernetes itself just like darker as well so here is my typical cluster I got a master on the top I got three workers on the bottom there is a sea advisor container that is automatically running depending upon where you fire up kubernetes so if you fire up cuban edits for example using cops then you see it was the container is running for you and what you also have is a hipster hipster is the one that is responsible for your entire state of the cluster it captures the state of the cluster and it does so by talking to different cube lengths so it talks with different cube let's capture the state of the cluster and it automatically stores the data into in flux DB and gives you a graph on our dashboard on front of it now depending upon again remember if you are using mini cube this is not enabled by default but there are add-ons available to mini cube so it really depends upon where you are running kubernetes and these containers or this monitoring system is available to you if not then this can be enabled using different add-ons so my hipster is really talking to different cubelets grabbing the data storing into influx DB and then you have your graph on a dashboard so this is sort of one of the drew fauna dashboards that I created well there's a default one available but I kind of tweaked it around on what kind of data I want to capture for my containers you can see there are lots of different data fancy charge that is available so do what it makes sense for your containers and your application of course there are lots of commercial tools available some of them have a 30 day time bomb evaluation so we works for example has a very nice integration with kubernetes so I would say take a look at that I have particularly played with cystic and New Relic and I've liked those two tools and how their integration works with kubernetes those are good I'm not sure if data dog is here but those are sort of the four primary tools that I've seen that have provided very nice integration with both docker and kubernetes boy that was the end of it that's it no so docker of course your reference is or dot IO kubernetes all the information that I get is from kubernetes or IO and the slides are of course available so you can go to this github repo and the slides are already live available over there and I may not be able to take questions up on the stage but I'm definitely hanging out down here and I'm here rest of the day feel free to talk to me thank you [Applause]

Channel: Devoxx

Views: 79,756

Rating: 4.7527676 out of 5

Keywords: DVUK17

Id: 1dgUXNVQS5o

Length: 45min 37sec (2737 seconds)

Published: Wed May 17 2017