Getting started with Traefik, the Edge Router & Reverse Proxy by Northern Virginia Linux Users Group

we are now recording so again if you do if you have your camera on and your microphone on you are consenting to the fact that your face and voice will be on youtube if you have any questions and don't want to use your microphone please put them in the chat and i will interrupt uh phil and mike michael as necessary to uh ask the question so our topic of the day is introduction to traffic uh the container edge rotor and reverse proxy and with us today we have michael irwin and phil fenstermacher phil michael works at virginia tech and there's a docker captain phil works at william and mary doing all all things docker um so i will go ahead and hand off to them uh and thanks thanks for joining us and take it away absolutely thanks um let me go ahead and share my screen here just because we've got slides to help i think keep us on track um hopefully they add value too um there we go i think i think i did that right yeah perfect okay so make sure um so uh thanks john for the intro um i'm phil fenstermarker i work at william mary i'm a manager in our systems design and architecture team um i don't really know what that means yet but um really we work on all the devops container config management um including just some traditional sysadmin stuff that's leftover because universities just have lots of weird stuff sitting around um and that'll kick it over to michael yeah and i'm michael irwin i've been uh full time at virginia tech for about 10 years now um rolled in right after i graduated and i've worn a lot of different hats since i've been there so doing software development and i probably say the last five years have been focusing a lot in the devops space the cloud engineering cloud architecture that kind of stuff to you so i'm i'm helping our our it force transition to using public cloud and uh been doing a lot with docker and whatnot and since uh john mentioned earlier that i'm a docker captain to kind of answer the question what the heck is a docker captain it's somebody that's been recognized by docker for their expertise in the field um and there's about 60 to 65 of us globally right now and uh and so yeah i don't work for docker i'm not paid by them or anything like that but just kind of the recognition and and it's actually kind of fun to get to uh have private slack channels with a lot of their engineers and that kind of stuff to you so there's a good chance if i don't know the answer to it i can ping somebody that wrote the code that did it so um anyways happy to be here and uh excited to talk about traffic today i guess i should also mention too because patricia would get after me if i didn't um actually both phil and i are traffic ambassadors as well too so that's kind of how we got ripped into this as well and so it's a similar thing there we've kind of just been recognized by traffic for knowing stuff about traffic and and just to verify clarify patricia is patricia dugan who i believe correctly is the uh community manager for traffic and hopefully later in the in our meeting she will show up and say hi and and do a little more marketing type stuff probably but but still worth the time sure yep so we should mention too that similar to the docker captain arrangement michael and i both don't have any formal kind of affiliation with traffic we don't work for them we're not paid for them we just kind of use it in our jobs um and because we started using it and sharing what we were doing with it they kind of like hey here's a t-shirt kind of deal and help you know we'll put you on the list when somebody wants a speaker um so here we are um just to give a little bit of background i guess on why like what traffic kind of why we need it um kind of do a quick kind of problem sort of thing so obviously your typical web requests um you know you make a request something comes back pretty boring we're all pretty used to it um if you're not too familiar with a reverse proxy um reverse proxy really just kind of sits in the middle but it's more on the server side the client talks to it it turns around or talks to the right server sometimes on a different port um and then just like that the request comes back also through the reverse proxy sometimes reverse proxies will do things like ssl termination um rewriting you can do weird stuff it's a layer seven type thing so you could sit there and say oh they're requesting this path let's send them here versus there or different domain names go to different backends um so nginx is a popular reverse proxy in the traditional sense um i should have mentioned this a few minutes ago too if anybody has questions please just interrupt us and one it's a small group too you know we don't really know what everybody's background is we're new to the group so please just interrupt um whatever if you have questions um and then kind of once we're through this i'm sure we're gonna pull because we wanna hear experience and background on a couple other things so in this case we would just say if you're listening on port 80 turn around and you know immediately pass it to this other server dot local domain on a different port um highlight that piece so if you have multiple servers you can do that too and it can load balance between them um this starts to get into what you would see in like a traditional like you know an f5 an a10 some enterprise level load balancer application delivery controller i think is one of the marketing buzzwords for it now um this thing so in a case like that uh you may just uh you know say on port 80 pass it to these two services um we can do a quick demo on this too i've got one set up locally so if i just say localhost um so this is going to go to my laptop we can see the hostname up here at the top of the server and if i ask it again we should see that i got the raspberry pi that i've also got running here at home and then you just write a whole bunch of times and it should effectively round robin and just kind of bounce back and forth um a fairly boring way um so to config that like i've shown the example i've got to have each server kind of configured up in this little upstream section here um and uh it's all manual config at this point they've got you know fancy service discovery things out there you can use to try and automate some of it but this is kind of the true full traditional sense without any kind of assumptions getting made let me see there we go um so in a container world i i know this is probably a good place to stop for questions too um or stop for questions and kind of find out not sure how to pull the audience maybe the raise hand feature in zoom works i'm not sure um does anybody like what's kind of the experience in the room with containers or if somebody wants to speak up too um they can kind of help us i don't want to like recap things everybody's heard 100 times um are people running them um [Music] michael maybe you have a better idea of how to ask the question i think you'll find that the group here is pretty wide from obvious to professionals so i don't know that you can go too low or too high but probably want to keep it basic once mr kennedy has has different opinions there yeah no and and also we just um last uh two months ago our uh peter larson did an intro to containers and then last month did an intro to openshift so this is our follow-on from that okay and then i've got two questions one what is the syntax language for the config and um i'll let you answer that one sure so i'm assuming they're asking about the nginx config yeah the nginx config so the example i'm using for the proxy on here um is this is just an nginx configuration file um i don't know if they have a name for their configuration syntax or not um in this case i'm just picking on nginx because it's really popular it's a reverse proxy um kind of in the traditional sense and even in the container world you find it pop-up fairly often so okay and then the second question based on this and i think i know the answer but i'll let you officially answer it the slash after location um what is that represent yeah so what that's basically saying is that the root of my application um if i make a web request to http colon localhost um there's kind of that implicit slash after that request um so it's saying slash and then anything beyond that um but i should talk about in just a minute we've got a slide where we'll kind of show what what other things we might put in that kind of situation awesome those are those are the only questions so far okay and please continue to interrupt with questions um it's uh i want to make this useful and i think we've got a small enough group it's pretty reasonable just to handle them all as we go so in a container world uh if you're talking about a spectacular host or certain clustering systems even you can only publish each port one time so we'll just pick on port 80 on the obvious for web things so it can only get published once so if you have an application in this case i'm just gonna use this who am i um example that we used it can only since we can only publish it once from a set of containers um it gets really hard to publish multiple applications which is kind of why we use reverse proxies for a lot of these things we maybe have one ip address or one kind of load balancer front end type thing and then based on what the contents of the request which host name you're requesting are you requesting in my case maybe i want wm.edu versus um you know business.wm.edu for our business school um so we take those requests and then we may look at it and see what is it you actually want and then from there we can decide which you know what to actually send you back but on the back end we may not want everything on one server and in one configuration file so in a container world that gets a little bit tricky so in this case i could talk about we've got multiple containers and now they're just load balanced across port 80 so that doesn't help us a whole lot so now we're back in this you know we need something to split the traffic up um so if we need to split it up and this is kind of going back to your question about the multiple path things is we can say like if i request slash who am i then send it to this who am i service if i'm requesting custom app send it to you know the custom app http endpoint um similarly we can change the server name and we can say if you're asking for a different hostname respond back with a completely different page entirely that way you can have one instance in this case the example configuration is for nginx we can have this listening once and it can respond for a number of different websites domains different paths and we can split all this up across whether it's multiple in our case we're eventually going to get containers but we can also talk about multiple servers and everything else sometimes you'll see patterns like this like i mentioned earlier in kind of the more enterprise dedicated hardware environment things like f5 a10 um there's other non-commercial solutions for this other than nginx things like aj proxy um apache can do this as well um and then a lot of times people will sprinkle other things in like maybe authentication on slash who am i but not on custom app so at this point once you've got a config file you can just extend it as much as you might need to do so in a container world what we end up things end up looking like is we have people talk to since we can only publish port 80 once they talk directly to our proxy server and the proxy turns around and says oh you want who am i or custom app and we route the requests accordingly because this proxy layer handles all of our web requests and it might even do ssl termination if you want to have encrypted traffic for everything and then once you're inside your container world you can either continue to do encrypted traffic or you could consider it a trusted network um approaches vary and in the container world this it goes really wild really quick so we're not going to get into that stuff today we're just going to kind of focus on this proxy piece and what it might need to do so one thing immediate thing that i know a lot of us that work in the id space want to do is well there's one of everything here um which is bad because things inevitably break we want to do maintenance so we can add more of them and we can just have it proxy and load balance across the different you know who am i services or custom app and a reverse proxy sometimes can do smart things too like if you need persistent sessions um persistent sessions being in the sense that when i log into let's say custom app and i'm on this top one we'll call it the you know instance a when i first log in instance a now kind of knows who i am we've established the session token thing that will pass around back and forth to make make it work a little better i think michael's going to talk a little bit more about that um here just a little bit um but i identify myself to custom app and it knows who i am but if i suddenly if my traffic is to custom at b it may not know who i am and it would forget about things so that proxy can add some other value things like persist hey when when phil gets here make sure he goes to a because that's the one that actually knows who he is and can log him in um so similar to how we have the configuration for the the nginx proxy where we would say okay if you want who am i then talk to you know my raspberry pi and my laptop with the other thing running um container gets an ip address um so i'm not going to spend too much time on this because we're more setting up the problem rather than this isn't a practical solution um if you go in and you inspect a container in docker you run these commands you'll get an ip address we can turn around and plug that into the nginx config you can do everything and you can build this kind of thing that looks almost like this um where we want to have separate you know servers for during you know separate containers running each of our different components and we're going to spread it all out through one central reverse proxy and we're going to encrypt it on 443 in this case i just realized that the line coming out of the little cloud client i don't think it's straight it's going to bug me now um so so far we've kind of talked about this in the abstract we haven't talked about particular servers so in this case let's say we have three servers and these things are running there um we also want to make this highly available like we said there's failover at least at the app level so if you think about what we had to do to configure this nginx container um we're having to do this docker inspect command and grab ip addresses of all these different components and we've then we've got to go and plug the configurations in and keep track of them when a container restarts because the ip address will probably change um and then we want to make it highly available so we're going to add a whole bunch of lines everywhere and it gets really complicated really quickly and a giant pain to maintain and then just to make it extra fun and paint the whole picture we're also going to usually run all of this behind some kind of load balancer because now we have multiple pieces of hardware we need to fail over between this can be you know an f5 an elastic load balancer if you're running in amazon um anything kind of like that will work so clearly this looks like a giant pain and is really hard to maintain and nobody actually wants to do this um so and that's kind of so we kind of said well what if the proxy could actually talk to docker directly or kubernetes or a whole bunch of other things and figure out where does stuff run and that's exactly what traffic is designed to solve um it it will dynamically look the stuff up and kind of go from there so i think now it's probably a good stopping point to see if there's any questions and from here we're going to go and explain traffic in depth this is kind of just like i said setting up the why traffic why do we need yet another tool when we already have reverse proxies up there yeah and one thing i'll just add to if go back two slides to your your picture of the the cluster um yeah this is hard to set up just once but also recognize in a lot of containerized environments these containers are coming and going all the time um and and that's kind of the whole point of containers and and you know the devops movement is to be able to build apps respond to user needs as quickly as possible all this kind of stuff and and and expedite the the ability to to deliver value for your organization and uh and so yeah if you know custom app for example is being replaced you know maybe every couple hours or you know even every couple days where you know something's got to be sitting there watching that and updating config and all that kind of stuff and depending on how large the cluster is that starts to get really complicated really quickly um and so yeah especially in these yeah containerized clustered environments things are constantly changing constantly adapting and so keeping up can be quite difficult there we we have a question um if the if there's a nest ssl cert on the reverse proxy it that terminates on the reverse proxy is the connection encrypted to the client container so from from in this case you know you're thinking about like this area right here or this arrow um i'm gonna assume it is that arrow the person who who asks the question can update that in the chat if i'm wrong um so yeah so that's kind of one of those it can go either way kind of scenarios um in the example that i've put here it's not encrypted um but it can be now encrypting contain traffic there's a lot of different ways to encrypt traffic um obviously with everything there's a lot of different ways but within a container environment there's some additional tooling that's available to us and i don't want to go too deep into the weeds here but there's a lot there's even more options that traditionally in a um not containerized environment would be really difficult and a pain to set up for essentially the exact same reasons that we valued here with these reverse proxies and everything changing like michael said where it's just too much to keep up with um so like so for the simplicity here we've done this on the the quick options are you can just encrypt the entire network you can set up like um i think it's docker's got some methods of doing ipsec there's service meshes with mutual ssl authentication um there's a whole bunch of different options like it's kind of out of the scope of this but to answer the questions straight up in this case no but they can be yeah and and i'll add to that too so um like like john said at the at the beginning here the end users when they actually access the app a lot of times in architectures like this the ssl termination might actually be happening even further upstream so at the elb the f5 a lot of times it may be even happening outside of the cluster and so then it coming into the cluster um you know even nginx 443 may not be the the final cert you know that that end users are terminating with it could just be a in cluster certificate that the elbs f5s are trusting um and then from you know in this case nginx to the who am i that again like phil said it could be encrypted there's nothing stopping you from doing that just of course your containers themselves would have to be communicating over encrypted channels have https endpoints or you know whatever encrypted means for the the app you're running um and so they would have to have those private keys or whatnot so it there's nothing preventing that from happening um just the the end users aren't seeing it so a lot of times it comes down to what are the requirements for your application for your network for the the architecture and so actually a lot of times i see a lot of times people say well in internal to the network i'll just use ipsec but not go anything beyond that and because i'm already internal to the network at that point and so who cares kind of thing unless the application requires me to have full end to end that as many layers as possible kind of thing and quite often times those internal certificates are self-signed um just so you don't have cell sign exposed um that's exactly how we run this at william area in fact we are we replace nginx here with traffic um we have a load balancer sitting in front and the public termination is there and then internally we use some self-signed stuff and with it and with this particular slide the indication of it is nothing is encrypt that goes to or from port 80 in those four instances exactly um and i think that's where i knew michael kind of said you might you just use ipsec or something and then um by using ipsec for a lot of those different parts that uh you're encrypting the traffic from a machine in this case the red box to another red box um because of how containers work um if you're on the machine it's not quite like a i guess even on a vm you'd have the same issue once somebody's on the physical machine you've got bigger concerns so traditionally as long as we can move traffic between machines and encrypted area um or in our case we have still a physical data center [Music] i should say one of our container clusters is a physical data center the other one is in the cloud but the physical data center when they're all plugged into the same switch the top of a row in a secured room so we can kind of we can make some reasonable assumptions about traffic between the machines as well so it kind of depends on the environment of what fits um you can see there's another question about yeah i know people have timeouts um you can um so i don't want to get too in the depths of traffic quite yet we'll dive into the config here in a minute but um reverse proxies typically let you configure really whatever you want on a per kind of back end basis um and you can support different things like uh maybe you need to use web sockets or something where there's another kind of http upgrade kind of protocol type thing going on and i will say go ahead i was just going to say that full question was can you set different idle slash keep alive timeouts for each web context that way somebody's listening thank you later thank you um and i will say too just because i'm in the middle of it right now um we're replacing we have an f5 load balancer on the very end so we're in the middle of kind of replacing it and porting all that configuration over having to manually configure your reverse proxies in this case this example we were using nginx think of every time a container changes like you replaced a new server with a new ip address and you've got to go in and reconfigure it and um after living in the container world for a while and now having to go back and do some of that front-ending maintenance again um i realized i was very happy to leave the manual configuration behind so this i'm going to stop sharing my screen here and i'm going to hand it over to michael to kind of pick up the next section for us okay and so now we're gonna start talking kind of traffic and um before we get too much directly into traffic i'm going to uh um talk a little bit about just docker and may go a little bit deeper than what you guys might have covered in previous discussions because it provides a good foundation of some of the things that we need to know in order to understand the value that we're getting from traffic and how it works and but then also how that extends to maybe other situations that we may be running applications so um i'm going to start off with a little bit of marketing blurb here and this is was actually from the the traffic website i don't know a while ago and so this exact quote isn't on the site anymore but i liked it enough that i've continued using it and so i'm going to read it first so traffic is a modern http reverse proxy and load balancer that makes deploying microservices easy traffic integrates with your existing infrastructure components and configures itself automatically and dynamically pointing traffic at your orchestrator should be the only configuration step you need okay now i know that there's like a lot of you know this is the one solution to rule them all kind of thing but actually as we get into this you'll see that it's a it is as simple as it says here um one of the things i do want to just mention is it says makes deploying microservices easy originally when traffic did start it was very focused towards the microservice based uh environments where you may be you know breaking your app into lots of pieces and that kind of stuff but but i'll extend that and say that it's not just for microservices it can just be for any apps in general um and so we'll see examples of that as we move forward here so again traffic again like like phil was just talking about is a reverse proxy um that kind of replaces the nginx layer and uh theoretically makes things easy so the way that it does this is um can everybody see the mouse pointer is it showing up or do i need to use the laser pointer yes no we can reconsider okay cool all right good um so as as requests come in from the internet or from you know wherever and lands at the the reverse proxy um it's gonna send them off to the the right place doing load balancing and it can also do some advanced things like uh canary and mirroring which maybe i'll define those real quick but we're not going to we're not going to do examples of this so canary based deployments are it's it's a reference back to the canary in the coal mine where um in in the coal mines as methane levels uh would rise obviously they'd become dangerous to or and even probably carbon monoxide just poisonous gases in general they they would become poisonous to the miners and so a way to detect that is they they put a canary in a cage in the coal mine and canaries would be susceptible to those poisonous gases much earlier than people and so if you see a canary dead in the cage you know you need to get out of there because obviously there's there's dangerous gases there and so it's probably a pretty gruesome thing and peta might get after us for that but whatever but this idea has kind of held on in which if i'm going to deploy an update to my application and a containerized environment i can deploy a canary and maybe send a very small amount of traffic to it maybe five percent of my user base to the canary and make sure that the app is still working and if it's working then i i've got a good assurances that as i increase that that percentage that capacity then you know i i know that the app is going to be working and so again the kind of this canary testing is has become quite popular and traffic can help support that and mirroring is something very similar instead of sending just maybe five percent of traffic what it does is it actually sends all of the requests to the original service but then mirrors it to the next one and so then you can you know check metrics and see are my response times similar um you know are my memory utilization so it's it's sending the request to the the original service as well as a secondary service and so you can do some pretty neat stuff there too um some traffic from canada to canaria and so the the blue boxes down here are the routing mechanisms similar to what we just saw with nginx so it's just forwarding request as as expected but what's unique about traffic are the the top pieces here especially the the purple box here the auto discovery so what traffic does is instead of relying on a config file that maybe is getting updated by an external script or something like that traffic has built-in mechanisms to observe the environment around it and update its own config based on what it sees and hears from the environment around it and what this allows traffic to to be is a basically an event-driven system so as events are are happening and various in this case orchestration frameworks and it mentions kubernetes and swarm there are lots of other providers that it plugs into but as it hears of changes going on in these orchestration frameworks it says well hey here's a new container that's spun up let me go ahead and update my own config and and respond to it and and be able to start sending traffic to it so again it becomes very event-driven rather than now if somebody's got to update a config file or a script has to update that config file and then nginx loads that additional config nginx for the most part is is a very dumb system in the sense that it it doesn't know how to update itself and you have to use other tools to update the config well traffic on the other hand is a very smart and event-driven system and is responding to what's going on around it okay so that that's that's one of the really really big differences here allows it to be very dynamic and adjust to what's going on observability and tooling we're not going to talk too much about we may be able to drop some hints of it towards the end but it's got a lot of really nice uh observability endpoints where it exposes metrics and and tracing and that kind of stuff to see what's going on or what endpoints are going slow all that kind of stuff all right so let's talk about docker and how traffic integrates with docker and we'll start with this as the first example here because it kind of builds on what you've talked about in over the last couple sessions and we'll then continue to give you the firehose treatment and give you more so when you run docker on your local machine or on you know a server docker at the end of the day is running a docker demon in which that that demon is starting containers and managing volumes and basically everything but the way that it works is that the docker daemon actually exposes a rest api around it okay and this rest api in fact maybe i'll just open it up here the rest api has tons and they've got all documents so if i wanted to do anything with the container here all the endpoints for a container the list containers create containers inspect export stop kill rename pause attach to network all these different things and that's just the container spot and networks and volumes there's there's lots of different endpoints for all the different things so if i wanted to list a container for example i can make a get to slash container json and here's the structure here's all the fields there's a ton of stuff here okay but docker recognized cool we're we've got this api here but we don't expect most people to interact with the api directly that's that's kind of lame but but it does allow for a lot of extensibility so what they did is they bundled in the docker cli and so when i do a docker run at the end of the day the docker run is really just an http rest client that's invoking commands against that api okay and that api then is the behind that api is a server and that's what's actually starting containers or providing the metadata all that kind of stuff okay and and again this allows lots of extensibility so the docker cli is a client the docker compose um tooling that's another just another tool that interacts with that same rest api the docker socket is how that that api is exposed locally on a machine if you're not familiar with the unix sockets um it's basically a way to do network type communications but still local on the machine so rather than open up a port that you know somebody can access from you know using an ip address it's a file based mechanism and in fact um let's let's do an example here i'll zoom in a little bit okay i'm gonna do a curl against a unix socket at var run docker dot sock and i'm going to query the endpoint um containers slash sorry sounds like i'm getting some feedback too mike i think you might just be sharing your web browser am i really am i really i am okay there we go there we go okay so now the curl unix socket and um the i'm going to specify unix socket and the docker socket and i'm going to the the host name here doesn't matter but i'm going to hit the container json endpoint and right now i don't have anything running so maybe let's just run nginx in the background let that start up and now when i yeah i've already got that started so now i got to start that's all right and now when i i run this i get this huge json blurb which if i pipe at the jq now i can see a bunch of information about the containers okay so quite a bit there and i do see a note in chat the introduction to containers we did we used the demolish podman that doesn't require socket and root access so yeah there there's lots of different ways to run containers um and yeah podman does it a little bit differently and so if you're using the docker or docker engine this is how it would work as well so again this this api endpoint gives me a lot of access to the the the engine and everything else that's going on everything else that's going on all right and peter i will jump into real quick um the the socket you can kind of treat it like a file in linux which is why if you're on a if you're on a linux machine and you add a user to the docker group by default the docker group has right access to that socket so while the docker daemon itself is still running doing root things in the background the docker command line itself doesn't necessarily have to use roots so it is kind of a weird way though but the caveat is if somebody gives them if somebody is in the docker group they can effectively become on your box just because of they could share you know whatever directory they wanted into a container running is root um so rootless is a whole weird thing in the container world but there are ways around um how you want to control access to that file for the socket file yep and that that's a great point and so that's it i think phil it's phil are you echoing yeah i think i'm hearing my um okay i'm not hearing it now yeah that's good okay interesting okay um and so yeah this last bullet point be careful with who or what has access to the docker socket um and so yeah that's exactly one of the things to be careful of even if i don't have root on the machine if i'm in the like docker group i have access to that socket and so i can launch containers and i could theoretically launch a container that mounts the root of the file system into the container and if i run as root inside that container i theoretically have done a privilege escalation so you do have to be a little careful of who has access to that that docker socket and yeah that's exactly what peter just said i can create an escalated container and gain root access on any docker demon box and there are ways to to work around that um and we won't get too much in the sidebar but there's a capability called username spaces in which if i run a container i can be quote root inside the container but root inside the container is not root on the host and so there could be a difference between that and so the username spacing basically creates a mapping that uid1 inside the container is uid 1426 or whatever on the host so that there are ways to to keep that safe too yep um yeah and so yeah podman does that as well all right so listening to docker events one of those endpoints um lets us listen to events that are going on in in the system and and and so as things happen as containers start and stop and die or you know whatever it's publishing events and the screenshot down here i'm doing a docker events and i'm just saying i want to hear the container event so i'm not here like networks and volumes and all the other kinds of things and just starting and killing the container i see all these different events so there's a create there's an attach there's a start there's a resize there's a die there's a destroy there's all these different events that are going on and what this allows is the the ability for other tools to to listen to those events and respond to to what's going on the system and that's that's what helps this become an event-driven system and and again this is just docker's way of doing things but kubernetes has its own api system and and there's basically every container orchestration system that you can use to run containers support this event-driven mechanism because at the end of the day that's what they're doing internally as well if i want to ensure that i've got three replicas of an application running and if i hear a container die if i hear that event the internal orchestration framework is saying hey i wanted three of these but one of them just died let me spend another one back up so they're event driven themselves internally and uh by exposing those events it allows other tooling to do things on top of that as well okay um so starting traffic um what we're going to do here is i'm going to start traffic and and i'm going to use traffic 2.4 which is i think 2.5 just dropped but that's okay um not much of a difference for what we're doing today and what we're going to do is we're going to specify and tell traffic hey you know traffic you've got lots of different mechanisms to be able to discover containers and what we you know back ends but what we're going to do is we're going to use the the docker provider and so what that's going to tell traffic is is it's going to start listening to the docker socket and the events that come along that socket and as containers come and go great we it'll update itself i'm also going to add a dash dash api.insecure and i'm just going to do that for local testing and demonstration purposes right now what that does is it launches a dashboard and that dashboard will allow me to see its configuration just kind of in a in a gui environment in the browser and that dashboard is available at port 80 uh 8080. so i'm going to expose port 80 so that web services that it will act as a reverse proxy and then 8080 so that i can access the dashboard i'm going to mount the docker socket in so it can listen to the events and go from there the reason that there's a insecure at the end of this is because the traffic api by default anyways exposes the ability to make changes to the internal configuration of traffic so if you want to have an external tool and kind of push updates into traffic you can certainly do that and so by default that's not protected and you you can add additional middleware and that kind of stuff which we will talk about a little bit later but um again just for local testing local demonstration i'm just gonna let it run okay um and so we'll start this up here in just a second i'm going to uh show one more slide and then we'll actually start things up here so once traffic is running there we go the question is how do we know what to route to it okay and this kind of goes to the question that just came up how does traffic differentiate between internal and external services or containers you know what sorts of things do we want to expose versus the things we don't want to expose and the way that it does this is it uses labels on the containers so when i launch a container i can attach labels to the container and labels are really just key value metadata for the most part it it's well it's not going to change how a container runs but it can be used to again attach additional metadata so if i wanted to do a docker ps or for example and i want to say i want to find all the containers that have this label on it or whatever i can do filters that way um you know maybe i put labels on this group of of containers to say they're in a logical app unit and and so i can say i want to query all of app a versus app b or whatever and so you can do things like that but labels can also be used for extensibility and and that's exactly what traffic's doing here so i can add labels to a container in this case traffic.http.routers.servicename or an app name dot rule and what that will do is specify the rule of when should when should incoming request be sent to this container okay and and we can look at the rules here in just a minute and i've got a link here we'll share the slides and that kind of stuff to you so um and you can make some pretty sophisticated rules we're going to keep it pretty simple and just do like hostname based routing but you can do regex or path based or a combination of things you can do some pretty sophisticated routing rules and then from there i can add another label to say traffic http services service name load balancer um server.port which i know is a long label there and specify hey when traffic is going to make that connection from traffic to my container what port should it use um it's going to default to port 80 but as we've seen you know a lot of times people aren't using port 80 you know i may use port 3000 or 80 80 or 5000 or whatever and so traffic needs to know well what what port am i going to make an http request to in order to send this request to you kind of going back to the slide i'm going to go back a ways here you know this slide if engine x was sending a request to custom app well in this case custom app is running on port 80 but if it were not on port 80 it would need to know how do i send the request what what port am i connecting to and so that's what that label is doing here okay so as an example of adding some containers and we'll do this and we'll start it up we'll take a look at the dashboard and everything in just a second so i've got my proxy and then i've i'm starting up a an app that i i call cats it's just one of my demo apps that i use quite a bit and what this will do is it's going to specify i want to run this image my c7 cat's version 1.0 and i'm going to attach two labels to this the the routing rule is going to say any requests that have the hostname of cats.localhost i'm basically telling traffic hey i want that to be routed to me and then i want it to go on port okay when it makes the request and just for kicks i'm going to add another service here nginx in which i'm running nginx and it's going to have a different hostname and run it on port 80. and so what that ends up doing is it basically deploys something like this where traffic will be exposed on port 80 and regardless of how the the web traffic and the http requests get to it it's going to send the request either to the little cats app or nginx and the way that it knows this is because we're using the docker engine provider and it's listening to the labels and everything so enough talk let's actually do things and i'm going to do one change here okay so if we look at my the docker compose yaml file here it's the same thing we were just looking at um and so let's spin this thing up here um and i'm going to use docker compose to spin this up docker compose up and then the dash d is saying i want to run this in detach mode which basically says start the containers in the background rather than keeping it as part of this um my shell inside of any of the containers or following logs or whatnot um so this is going to start the container you'll see some additional warnings and that kind of stuff because i'm running also swarm on here you can just ignore those right now and this tells me okay it's created those containers if i do a docker ps i should see this three and um i've got a the nginx these were from earlier i just forgot to remove them so you can ignore those as well that was the the docker runs that i did so let's go back to the browser and if i open up localhost 8080 which was the dashboard what we'll see here is okay it's running on 80. that's cool if we jump over to http we should see a couple different things here so we see some routing rules for nginx.localhost and we see another one for cats.localhost it also by default puts routing rules for the container name so if i look at this um elastic elastic elastic grinder here on here and so it's it's automatically just put one in there i can't hit that one because i don't have obviously dns going there but anyways so if i open up cats.localhost yeah sorry about the echoes there um what i'll see is is basically what's going on here so the the entry point if i go to traffic on port 80 there's a router here for cats at docker so the dockers tell me this came from the docker provider i theoretically could run lots of different providers but i'm just doing a docker right now here's the routing rule and if the routing rule is uh is valid if if it matches then we'll send it off to this service and if i go to the http service and look at cats at docker it'll tell me that the backend server is at 192.168.32.3 and if i look at my container docker inspect that container id we'll see that on the it has that that address okay so it's picked it up it's it's seen it and now if i go to cats.localhost i'll see the the cats app just simply displays a kind of a random gif of some cat action or whatever now so one of the things i can do is let's actually do a little update here and i'm going to run cats 2.0 and let's launch this and so this is going to recreate and kind of restart that container and if i go back to the dashboard i think i have to just refresh this page it's still launching okay and if i refresh this page maybe it ended up just using the same ip address but now if i refresh this i get version 2.0 which is dogs because dogs are better than cats and so that's why they're version 2.0 um but anyway so it's it's automatically seeing the the change in the environment and even though i've got a new container that started up it's automatically updated itself to the points at the right place okay um and so that's certainly a way to uh showing off the the benefits here and now if i actually do a docker if i can spell it right and if i remove the cats app it's going to hear that and now it gives me a 404 because that's obviously not going to work and it removed itself from the service it no longer has the routing rule so it's responding to those events again that the container went away let's remove the config and go from there and just for kicks actually let's spin it back up and uh i'll hit the engine x service to you real quick all right and so we see cats.localhost up there um it's now responding and if i go to nginx.localhost i get the welcome to nginx page just the landing page cool so again traffic is sitting on port 80 and then as based on the routing rules figuring out where do i go now the the other containers you know i can launch other containers like databases or all that kind of stuff and if i don't put the labels on them then there's no routing config that's put in there and it's not going to try to connect to those those containers you can't you know that they basically stay internal services and can't be accessed from the outside so again you you have full control over the labels and there's a lot of other labels the the ones that we've got specified here are the the typical ones that you see you know what what routing rule do i need and what port do i send to but there there's a whole selection of lots of other things that lets you configure a lot of other aspects of how the routing works um and like timeouts and weights and all this kind of stuff there's a lot of really cool stuff that you can do with that so maybe with that um before actually maybe i'll mention this real quick too um i don't know if you guys have talked about swarm or not um i know that swarm doesn't get a lot of talk but i at least just wanted to mention it because uh for some people it might actually be a lot easier to to run a small little swarm cluster at home um rather than like a full kubernetes type thing if you're not familiar with swarm it's basically a container orchestration framework that's built into the docker engine and will let you run containers and you can theoretically scale it up to multiple nodes and all that kind of stuff but a lot of times people will even run a swarm cluster of one and the advantage that comes along with it is that you can simply declare your state and then the orchestration framework makes it a reality um so if i say i want one instance of this container running if that container dies for whatever reason well the orchestration framework will say cool let me spin it back up and and that's some of the advantage of using an orchestration framework rather than just running a a docker run where there's nothing making sure that it's up and running all the time um and so in this case the scaling out the swarm all i have to do is i change the the provider so instead of just providers.docker now i'm telling it to run in swarm mode so that it it watches different types of events and and different metadata so peter asks is that what docker's restart always does restart always has some interesting failure modes and um and and so yes it it can if it dies can restart it but it has no way to do like exponential back off or that kind of stuff if your your app can never start but then also one of the other advantages that comes with along with orchestration is if i've got version one of my app and i want to deploy version two of it it can do like rolling updates and that kind of stuff where you can't really replicate that with the restart always at least without manual process as well so restart always can make sure that your app is is always up and running but it does have some interesting kind of failure modes in it as well um and so jumping back here um the the only differences that we've got going on here if anybody wants to run traffic on swarm is right now i'm telling traffic needs to run on a manager node so that the docker socket has full access to the the cluster and can see the events regardless of where the containers are running in the cluster and one of the other things i'll just mention here too this is a pretty common pattern that and if you're running in clustered environments or you're running lots of different uh applications in a cluster a lot of times the proxy will be defined in one stack and you know deployed by itself unlike here where the proxy was deployed with the the other services so you may deploy the proxy and then say all right now i'm gonna deploy the app in a separate yaml document or you know all your different apps are in separate yaml documents in order for them to communicate with each other they need to be on the same network so a lot of times the the proxy stack as uh swarm calls it will define a network and then all of the other services will have to attach to that network so they can communicate with each other and an example looks like this which then i launch an app and uh when i when i launch it i specify that the default network is that proxy network um and so then then there's an actual network path between the proxy and the other containers um so that that's what this ends up looking like so this is a three node cluster here in which now traffic can hear events from the docker engine but then send it off to in this case an engine x i've got three replicas and they're spread across two other nodes and so regardless of the node um since they're all part of the same cluster they can they can communicate with each other and they're on the same network so in this case uh peter just asked so every node needs a reverse proxy no what ends up happening is the requests will come to traffic which is exposed on port 80 and and again i don't i don't want to make this a swarm workshop or anything but when in swarm if i expose port 80 it actually exposes port 80 on every node in the cluster and so even if a request comes to this worker node on port 80 there's iptables rules that will then send the request back to traffic over here which then yes may end up round tripping it back and so it's happening in kernel level redirects and everything and uh the docker engine and the swarm cluster everything keeps track of all those rules and everything so an external load balancer can simply say hey just throw this to port 80 on any node in the cluster and regardless of which node the request actually lands on traffic will then end up making sure it gets sent at the right place so again i don't want we could probably spend an entire other uh session maybe you guys will have to have us back at some point to talk about orchestration framework and networking all that kind of stuff but um yeah the orchestration frameworks that regardless of where the app is actually running the external systems don't have to know about it and the request will still get to where it needs to go sure there may be some optimizations to say hey i know traffic is only going to run on manager nodes and so i'm only going to send the request to manager node um all right so you follow up not sure if i understood if you have five containers on each node how does traffic route to specific containers on each node if it exists only exists on one so what's happening is traffic is again listening to the docker engine and it knows where all of the different services all the different containers are scheduled and the the networks that the clustered environment uses span across the nodes they're using vxlan or a variety of different networks and so it knows okay engine x1 has this ip address nginx 2 has this ip address engine x3 has this ip address and so really traffic is just saying hey i'm going to send it to 192 168 3.7 you know whatever it traffic doesn't really know nor care what node it's on it just needs to know the ip address and then the ipa um yeah all the ip routing rules will make sure it gets to the right place and uh so yeah the vxlan and other networking pieces make that a lot easier and so that again that's part of that what comes with the orchestration framework to keep up all those rules and what's living where um all right cool so glad that helped answer that and great questions too thanks for asking away um so with that actually i think that's a good stock a good stopping point any other questions or follow up here um i don't know how many people are using swarms i didn't want to go too much into it but at least just wanted to highlight here's another use case of traffic listening to a different set of events and it looks pretty similar in this case um but it's a again a different different set of events and it can respond to update config all that kind of stuff phil man they're blasting you for the echo i i know i'm really sorry i'm hoping i turned on aggressive echo suppression and then nobody could hear me when i tried talking so i can turn it back off that's all right all right so before we move on any other questions so far all right hearing none i'll stop sharing and i'll pass it back over to phil unless do we want to take a two or three minute break or are you good i guess you just took a break since you weren't talking how's everybody else feeling does anybody else need a couple minute break to get up walk around do something real quick we're we're mostly used to um sitting here for two hours so we're we're we're generally good i mean if you guys are looking ahead that you're ahead of schedule when you want to take a moment that's fine too there's good bladder control here [Music] all right hopefully we can get this through this without bad echo i've never had this problem before with echo things so i'm uh you know hoping it gets you know not terrible if it gets bad again just yell at me um so to tack onto the docker swarm component piece the easiest way to describe it to folks that aren't familiar with vxlan or anything would be uh think of it makes a whole bunch of nodes work like one node if you share a port it's shared on every node if you do an action generally it affects everything um it's not quite that simple but easy way to think about it at least from a networking standpoint um so personally we used to use swarm for a whole bunch of stuff we've moved on to kubernetes since then um so i'm going to talk a little bit about that piece of it um experience sorry i'm reading the comments i'm trying to fix my echo problem now um so in kubernetes one of the biggest differences um is that it looks very similar when you look at it um unlike in swarm the traffic reverse proxy piece can run on any node it doesn't necessarily have to be on a one of the the manager or controller nodes um and kind of the biggest reason i think that that's nice is it lets you be a little more flexible with whatever we might have to do um the it watches resources instead of labels um there's a particular they call an ingress object in kubernetes um because i should jump back a little bit i know you guys did an open shift talk um a little while back openshift is essentially kubernetes or at least the latest versions of openshift are kubernetes with some red hat special sauce kind of put on top of it i think they include their ingress controller and a couple other packages and things kind of all bundled together there's probably a better expert in here on openshift than i am but if so you may be familiar with some of these concepts if you guys have already done the openshift talk um so we we're going to create these ingress objects and ingress objects tell traffic hey when someone wants to talk to you know nginx then it needs to go to this particular service and it's that very declarative kind of this is how things should look in this case traffic usually gets referred to as an ingress controller um purely because one it controls ingress and then also in within the kubernetes world you have a lot of these objects and then you have some controller that acts on those objects so we'll get into this with a little bit of example and everything here shortly so just like michael showed with the docker and the docker swarm providers we have to turn on the the kubernetes um ingress provider um so i know michael was using command line flags he actually chatted about this personally i use config file things for a lot of stuff and i noticed somebody in the um [Music] the chat earlier mentioned that they were trying to start this up in podman and it looked like they were trying to pass on the tamil config file um so we we could do something similar here with us where you know we'll just create this little config file and i'm gonna do very similar to what michael did i'm going to turn on the dashboard and we're going to have it watch two different types of objects we're going to turn on two providers at the same time kubernetes provides its own kind of permissioning system on the equivalent of that socket file there's this api server that runs inside of a kubernetes cluster and everything that wants information about the cluster talks to this api service regardless if you're inside the cluster outside the cluster anything else just kind of this general api thing and part of its api includes a really nice and really flexible role-based access control system so the traffic in a kubernetes environment or openshift environment or any of the kind of derivatives off of kubernetes will run with a different service account and that service account will you give it permissions to only access the parts that you wanted to see so in our case we're going to say i wanted to be able to access ingresses because we need to know how to get to things you might want to be able to access services because sometimes we're going to attach some specific configuration um to uh to whatever you know we there's some annotations that we can put there for configurations all these different levels but maybe we don't want it to be able to access the secrets that are in our cluster um or maybe you wanted to access certain types of secrets um so there's a whole bunch of different reasons why you can do this but service accounts and the rbac system as peter pointed out that it was one of the red hat add-ons back to kubernetes back in the olden days i guess olden and kubernetes terms as what six months ago i know our back has been there much longer but it's just such a new thing um so we essentially we can make it do and limit access to things that we want and this is a really powerful pattern um to use in a lot of different applications um we use it quite a bit um in our environment and it's quite nice so this is what an ingress object looks like so in the docker environment or the docker example we were attaching labels to particular services a lot of people joke that kubernetes is really we're just going to write a whole bunch of yaml to do everything and they're not wrong um it's a lot more gamble to write than we would write in uh in a darker swarm or docker-composed style environment um but as you've probably already picked up it's everything is very fine green it's we have to define a lot because it's very granular and powerful with what we can do with it so in this particular example we're really just going to say i'm creating an ingress we're going to provide some metadata we're going to name it we're going to tell it what name space we want it to run in um we're also going to say we're going to annotate this and we're going to this is kind of a predefined thing where we're going to tell it i want to use thing rest class of traffic this is important because within a kubernetes cluster there are other popular ingress controllers there is an nginx based ingress controller if you go on the kubernetes documentation there's a whole pile of these things um so we personally want to marry our my team we use traffic um one because we came from the docker world where i don't know that there's any others um and two we were already familiar with the config just kind of ported over we just had to swap out that provider piece um so it's something we really liked and it's got a bunch of other just nice features that are really cool great community you know little plug for that so then we're going to create some roles um and we're going to say i want this to if the request comes in on who am i localhost we're going to give it some paths in this case we're just do the path we're going to say it's a prefix you can say i want an exact match or i want it to anything that starts with a slash um so i think this really plays in if you're doing microservices maybe you want them all running at one domain name or if they're internal to the cluster you don't need an ingress controller um i should probably clarify that statement a little bit if ingress is only for coming x for traffic external to the cluster ingressing into your cluster you don't need necessarily an ingress controller for traffic from one part of your cluster to another part um so if you have microservices that are called for maybe something outside of kubernetes then maybe you wanted to take a different path in um and say if i'm going to slash api slash version one then map to this other container over here and if we have time later i've got an example that we can go through and then we're just going to say this goes to the name the service name who am i and port and we're going to name http and that's defined elsewhere as well uh let's do a quick demo before we move on to the next piece so what i've done is i've created a kubernetes cluster um it's running locally so if we go into the services i've got some basics we can see the dashboard is listening um i've got a little health check thing saying ping that way if traffic were to die for whatever reason kubernetes will figure it out and restart it and then we're exporting metrics which we'll talk about later as well so you can see there's no who am i service in here now so over here i'm going to actually use a quieter keyboard um i use an old ibm model m so it's a little loud sometimes that i'm talking so i'm going to say i want to look in the who am i namespace and i want to get our ingress resources so right now it's going to tell me there's nothing there so just like michael did in the docker example we're going to start a watch in this case it's a particular thing that the kubernetes api is built in and we can just you can do this at an http level with curl um but essentially we're going to say just leave this open and tell me when anything changes with respect to ingresses over here i've got my who am i service i'm not going to go through this in detail because kubernetes as you might imagine could be a several day talk in itself and uh so then we can go through here and we're just gonna say i'm gonna run this traffic who am i service which is just an example container that they they've written um the folks at traffic but anyway and we're gonna say ports and this is where we name and say http is container port 80. and in this case we're going to run two of them and i think this is a little bit interesting so they're actually already running um if we go on here and i say who am i in pod and we can see that i've got two of these my services or pods up and running so i don't have this ingress created yet so we're gonna apply the ingress and as soon as i apply this in this other terminal window we'll see it pop up right away and we can see that it wants to the host is who am i local host and it's listing on port 80. if we go back down to the web browser we can see that it showed up on here twice um one of them is it's trying to do tls um i don't have a real certificate set up in our next section michael's going to run through kind of how that works um and then we'll go from there and then i'm not defining where the non-http one should listen so we've got these entry points so it's listening on my admin port my metrics port and my web port which is the non you know insecure http port 80. so from here we could say who am i dot localhost and then we'll get the output of this um and it just kind of gives me some information this is more interesting to look at actually so because there's two of them and web browser weirdness if we curl see that this is going to one container and then if we run it again we'll get the other container or the other pod so if we go back to pod we can see that these two identifiers match up with the names of the pods so it's load balancing between the two even though this is running entirely in my kubernetes cluster so let's see other interesting things to talk about in this dashboard real quick um oh in the services section we can see that i've got one of them it's you know it's load balancing across it we have two servers behind it and we can see the ip addresses here as well similar to what we saw in the docker swarm world earlier um and then we can set other flags and things and we can even see where it's used so we can see okay what's routing to this service um maybe you've got some really complex routing rules you can come in here and take a look at all of it um so that's that's kind of what an ingress does it's very similar and it's very declarative kind of like that docker score model where we can just say here's what i want my traffic to look like here's how it needs to be routed around the cluster we talked a little bit earlier too about other provider things that we can talk to it can also talk to console amazon's ecs marathon rancher 1.0 rancher 2 dot anything is just or it runs on top of kubernetes as well so it's going to use your normal ingress type objects um traffic well touch on this very briefly so we have this ingress object as you might imagine this is kind of the generic that's used by all of the kubernetes things that are out there that use ingress objects but different ingress controllers like traffic have kind of their own i want to say above and beyond but it's one that it doesn't quite match that lowest common denominator so they've created other objects that look like an ingress object where you can do more specific configurations and you can make things look like um i'm going to jump back to like a slide from earlier so when you write these in these rules and this rules language that michael sent us yeah this link in here when we have all these available rules where we can plug those in generically and that's where we can do really crazy things like regex and weird path modifications and matching and all kinds of other fun stuff so there is another type of ingress thing but this is kind of the the base definition of how everything fits together next we have a question the english definition doesn't specify which service endpoint to use how does it know which pod services in that name space to use so down here at the bottom we've we're matching this path and we're going to tell it the back end service and the service name is who am i and the port is http um if we one um so that is kind of it does bring up an interesting point though um so within kubernetes we noticed earlier when i was talking about the deployment there wasn't a reference to it there is another object in kubernetes called a service so peter you didn't miss anything i just kind of skipped over a part of it that's kind of behind the scenes um where the service is creating we're selecting apps that match who am i um and we're saying port 80 and we're kind of doing this we're mapping port 80 to another port 80 and this is kind of that internal load balancer thing where maybe you'd skip that ingress it's kind of out of the scope of this but it is something that needs to kind of be noticed if you're doing things like sticky sessions or persistent sessions um like i was talking about earlier where you know maybe your new container container a knows who you are but not container b you would apply those types of changes on the service itself not at the traffic layer so when you get into kubernetes um i know we all like to joke that you know there's really no problem in any of our jobs that can't be solved with like more layers of abstraction and in this case we're just adding yet another layer of abstraction to all of this so we have services can be like internal load balancers or if you're running in a cloud you can even create a service and say hey go create a load balancer for me um and it'll go and do that so and it can the service stuff in kubernetes so you mentioned in the group that it's the kubernetes vxlan type thing um yeah you mentioned that it's just one option to create the network in kubernetes there's networking again is probably a multi-day talk for kubernetes and it it just goes more layers of abstraction and plug-ins and extensibility and interfaces and all kinds of crazy stuff um so we definitely won't get into a whole lot of those details today but it is something to know that there's another layer of abstraction that's living in there um so this is kind of the boring part i think of traffic and that it routes traffic um it's in a boring in a good way um and i know one of the big pieces that everybody likes to talk about is tls management and it's nice integration with let's encrypt and other services so michael's done a whole lot more work with that than i have so i'm going to throw it back over to him for a demo on that lots of good questions too this has been awesome so far um so i did just want to bring this up real quick since it just came up again um this is the the page that has the that i linked to and referenced earlier that has a bunch of the different routing rules and all that kind of stuff um and so for example you can route based on headers in the request or um host or a host the host header if for whatever reason that's different it should never be different but um you know a method there's lots of different ways that you can set this up and uh as we kind of saw in the the example um and the dashboard that phil had up for a second that you can do ands and and that kind of stuff so you can make some pretty sophisticated rules as well um and one other thing i'll just mention too is uh you know phil was talking about services and yeah that's an abstraction layer and and and like docker for example that's you really have no control over that abstraction layer but with kubernetes there's a lot of other extensibility options and so for example you know in some environments you may take those service definitions or the service objects in maybe instead of doing all that routing internal to the cluster with um you know virtual routing or virtual networking you can actually take that and pull it out into aws lan for example and there's there's a lot of really neat networking things that you can do there but it does get pretty complicated and and finally one last thing i'll just mention too kind of plugging in the r back mechanisms the the ingress objects here letting them be separate ingress objects rather than labels on a container makes it much much easier to do like multi-tenant kubernetes where it's really really hard to do multi-tenant swarm clusters and that's because you could a variety of different things you could say hey whoever's running the cluster defines these ingress objects and you know they own the host names but also kubernetes has some really neat um capabilities called admissions web hook controllers which again we're not going to get too much into but it could say when you apply this ingress let's let's evaluate the policy and find out can you actually are you are you in this name space authorized to use who am i.localhost and so like for example at virginia tech we're doing exactly this with some multi-tenant kubernetes clusters in which we'll annotate a namespace and say any application in this namespace can use domains x y and z and and so if they try to define an ingress that uses domain a it'll say hey that's against the policy and we'll deny the ability for that ingress to be deployed and so kubernetes provides a lot more our back mechanisms but also policy enforcement where swarm doesn't um and so that again we can spend a whole extra talk in there but um there's a lot of really neat stuff and it's let us build um some pretty neat clusters and uh environments for for people to use all right so let's let's talk tls management um first off why jump in real quick and talk to peters who mentions that service networks in kubernetes are global um they are global um you can add some security to that with um network policies as well so you can do some really kind of crazy rule cases in there um where it uh you know let's solve the problem with yet another layer of abstraction and another rules thing in there and then more yellow so it's powerful but yeah there are some ways to control that a little bit so and i'd say in that space actually we're doing something exactly like that in which um so all of our name spaces we've got annotated with the who owns that namespace is it part of platform services or is it a attendant name space and so network policies um we've got policies in place that traffic can't go from one tenant name space to another tenant name space they can't cross name spaces um but they can go from like the platform services like our prometheus monitoring and metrics or even traffic itself that you know they they obviously have to go across name space um but so that there there are some ways to lock that down to you um and it also depends on what network cni driver you're using all that stuff to you so again that gets pretty complicated pretty quickly um and then there's another question here does each pod have their own individual ingress controller or is the ingress controller acting as a load balancer in between services um and so actually let's go back to the picture here um so it works pretty much exactly like this where the ingress controller at the end of the day a controller is really just a another container another pod that might have a little bit elevated permissions to watch for state changes in a cluster but there's no like there's no designation that says thou art a controller it's really just it's watching state changes and so traffic is just running as a container and it's it's uh querying the api server and and responding to the network changes so is there one of these or are there many of them it really just depends on the needs of the cluster for a lot of clusters if you're not running a lot of heavy workloads you may be able to get away with just a single traffic instance but you can run multiple replicas and they'll all watch for state change but it's definitely not a one-to-one mapping of traffic to back-end service there peter said service definitions are the the pod network balancer the ingress role is mainly to understand which service to route incoming requests to although as you can see you can add other features to it and that's exactly right um we typically deploy at least two ingress controllers per cluster um and yeah so there's lots of different uh deployment architectures that you can utilize as phil mentioned earlier there there are some groups that may use a combination of traffic and nginx or you know even different types of controllers personally i've never had a reason to do that but there you certainly can um typically we've been able to do everything with just traffic and then we scale up or down how many replicas of that depending on just how much traffic if you say traffic too many times it's hard to know which traffic you're talking but how much uh http how much network um how many requests we've got coming and going um and again something else that you can do with with kubernetes as well as you can have different kind of node pools and so you can have a a set of worker nodes that's just for ingress maybe has extra network um like in the cloud network optimize machines and run just the ingress on on those and and so yeah target traffic to run just on those nodes but then all the other nodes are in a separate node pool it's also one cluster but you know then you can make sure that your ingress have dedicated machines with higher network throughput or that kind of stuff there's a lot of really um different things you can do um say a big reason internal external exposure differentiation or high traffic pods may require specific isolated ingress so the rest of the cluster doesn't suffer the true okay yeah good points there all right let's talk to you less um so first off why https um and i know tls isn't just for http based stuff but we're going to talk http anyway so um the http protocol is a stateless protocol and that means every request that comes to a server the server is basically like who are you um and has no idea who you are there's no pre pre-assumptions that come along with hey this came from this ip address and the last time i talked to that iap address we were at this state so let's continue that state there's none of that and so to fix this web servers and http supports what are called cookies and cookies at the end they are just a header that is included in the request so that when when a server starts initiation with a user it says hey here's a cookie put in your cookie jar and the next time you come back to me bring bring the cookie back please and and so then the server says hey i see this this unique identifier in this cookie and so therefore i know it was issued as part of this request and let's look up all the state all the session that was associated with that user um and so that that at the end of the day is what cookies are and i i'm pretty sure all of you already know that as well but this last bullet point the cookies need to be protected session hijacking is real um it's so true um man i made a youtube video man it's probably 10 11 years ago at this point fire there was a new extension made for firefox in which it was called fire sheep in which you could basically sit there and it would put your wi-fi card in promiscuous mode and just listen to traffic and any port 80 traffic that it saw it would snarf it would steal the session cookie out of it and basically put it in a menu and if it was like google or facebook or twitter like some of the big names you can just click on the the menu icon and you it now set up your browser to have that cookie and you became that person and uh and so i made a little youtube video showing it off and everything and in many ways i think that extension is what really increased the awareness of oh crap we've got a problem here of everything's used in port 80 that was before yeah it was https everything and everybody was you know worried about the overhead and cpu for um encrypting all the traffic and all that kind of stuff so but that really forced the issue hey if you know joe schmoe can just download this extension and sit on you know the starbucks wi-fi which might or might not have been encrypted at the time and now they can become me oh my goodness this is this is a big deal here um so https solves that problem because now that part is part of the encrypted payload and uh can't be stolen just by sniffing traffic in on on the wi-fi so how do we do this um i'm sure many of you have gone through certificate provisioning and know how hard and ugly one it used to be but also for some of you it may still be so uh be careful with my words there but um you know you had to go to a certificate issuer and kind of prove your identity and there was this back and forth and forms to fill out and all this stuff is a very manual process and so let's encrypt started back in 2016 to figure out how can we do this for free but also scale it and automate it and what they did is they basically built the acme protocol and this protocol provides a way to say hey i want a certificate and before they they sign the the certificate they'll say well prove that you have ownership over the domain that you're requesting a certificate for so they give you a challenge and then when you complete the challenge they'll verify that you've met the challenge and then if everything's good cool they'll issue the signed certificate so an example looks something like this web server admin software says hey i want a certificate um please please sign this for me and it says okay cool here's a um a challenge put ed-98 at 8303 now obviously this has been shortened just for the graphic and the real versions would be much much longer but what they're saying is hey put this random identifier at this random location on your web server and so then the the server software would either put it at that location or update routing rules so that it would work and then it will say okay i've i've got that ready and let's encrypt will say cool let me fetch the file and make sure it's there so one this is validating that dns points to the server which again is proving that you have ownership over the domain and then we'll check that file and then make sure that it the contents match what the challenge expected it to be and this this is one form of verification there are other forms using dns where let's encrypt will say hey maybe you can't do the web server one because it's a offline server air gapped or security rules make it so we can't you know do an http request so to prove ownership if you've got ownership over dns well you've got ownership over the domain as well or at least the web server that we'll be running on so create a dns record that has this value at this record and so you can do challenges that way and there's a third method that uh i'll let phil mention uh in just a few minutes as well too but anyways it's this idea of hey i want a certificate cool here's a challenge i meet the challenge and then a certificate is is issued for and again this is all part of the acme protocol there's lots of vendors that implement this protocol now let's encrypt is just the biggest one and they're the one that basically built the protocol from the start okay so that's great how do we make use of this traffic has built-in support for let's encrypt and we'll automatically do everything that's needed so it automatically requests the search for desired host names i can say i want to search for hostname x and it will start the the communication with let's encrypt or any other acme provider as well it can validate the challenges and it knows how to do the http one and it can support many of the dns providers if you're using some of the biggest ones like cloudflare or root 53 or you know there's there's a large list if you use any of those it's got integrations to be able to automatically put in dns records for you as well assuming you give it credentials to do so um and then the other big advantage here is d traffic will handle the rotation of the certificates so i think let's encrypt certs right now if i remember right are 90 days but i know that they've talked about shortening them potentially even down to 30 days um so they're pretty tight and you know if you're doing that manually that's a lot of just rotation but traffic manages all that for you and it's completely behind the scenes and you don't have to worry about it think about it et cetera so what's how do we configure traffic to do this um again i'm i'm doing this with command line args phil mentioned earlier that you can do all this through config file as well and i think i've seen in chat an example of somebody that you know was accidentally putting it here but um of using automobile-based approach so there's lots of different ways to configure traffic so in this case i'm going to run swarm mode i'm setting the default network that it's going to use and what we see here is i'm setting up entry points which are the the the ports that traffic is going to listen on and and some of the rules around it so this first one i'm naming web and it's going to be on port 80 and what i'm doing is i'm setting up an automatic redirect so that all requests to are going to redirect to another entry point called web secure and the scheme for that is https okay so basically this is setting up automatic port 80 to 443 redirects and my downstream apps don't have to do that nor worry about it so for the web secure entry point i'm saying i'm going to do this on 443 it's going to be using tls and it's going to use a cert resolver called le resolver so let's encrypt resolver um we set up the the dashboard uh i'll mention this real quick this insecure skip verify it's not part of the the let's encrypt stuff but going back to what we were talking about earlier of the the leg between traffic and the back-end app if the back-end app is using a self-signed cert this is basically saying hey don't don't verify their certificate don't worry about it just let it go kind of thing so then that communication can be encrypted but it's not necessarily trusted um so that that's what that flag is then the last three here are actually setting up the let's encrypt resolver so a certificate resolver um i just name it le resolver dot acme i'm going to use the tls challenge which is the http based one that we were just looking at use it to true in order to do acme you have to give it an email so that it can send certificate expiration warnings or if there's ever any other details i've never once gotten a spam notice from them so it's it's pretty good there um you know what email address to use there and then storage is where is it going to store the the private keys and whatnot so i'm just going to store that in a file at slash acme.json and you'll see that i also just mount that onto the file system as well so if i have to restart traffic or whatever i don't have to reissue all my you know start with brand new private keys reissue certs all that stuff it persists longer than the life of the container so what i'm going to do here is uh we'll show this slide real quick and then we'll do a quick demo and i i use this for my home lab setup pretty much in which i've got you know my my home router i've got port forwarding rules going to just a machine that i have sitting here at home and in this case it's actually a swarm cluster it's just a swarm of one just that one machine and it's running traffic on it with let's encrypt and so i can put a dns name on it and and even a wild card on that name to point to the router here let's see did i close that i did um so in this case i'm actually using cloudflare i guess it logged me out so nevermind i won't log back in but um what we're gonna i'm gonna ask you guys in the in chat to to send a just a random sub domain name and we're going to uh use that name for the little cats app demo that we've been doing so whoever's first to put a subdomain name in chat we'll use it foster okay foster cats yeah i see where you're going there um so i've got to dns uh both the main name and the wild card pointing to my home ip address which then we'll send it to traffic and then um we'll go from there okay so let's actually do that real quick um so i'm on my my node here and we saw somebody wanted foster and so i've got this domain name micro87.training that i use for a lot of my workshops or whatnot and so i pointed nova lug and the wild card to my home um home ip address so please don't dost me while i'm doing this but um let's go ahead and so do a docker stack deploy and we'll call this nova log oops up i didn't remove one config piece there all right and so this is deploying the um that service and so we we see that it started up and if i open up so foster.nova log.37.training okay so right now it's still going through that process so i'm getting a certificate authority invalid because let's see if i open up the certificate it's in the security tab now view the certificate it's just using a traffic default search so by default it just uses a yep it's it's an unknown ca it's a self-signed cert because it hasn't finished going through the acme protocol okay and now if i refresh this okay now it's it's happy i've got a pages secure page is valid and i see that this certificate has been issued r3 is the let's encrypt uh issuer and it's trusted by my browser and and we're good to go so it just takes a a little bit to go through to get it um to go through that that process um and peter said he's still seeing itself signed from here i i've noticed sometimes the browser does that so maybe try an incognito window and maybe or you're doing it with curl well oh it's foster not found faster so um yeah so in any of the domain names that i'm not actually serving it's still going to use the uh the self-signed cert until i've got an app that it's actually trying to use that uh that endpoint there so um and yeah so with that i got a free tester and uh went from there and i'm going to jump in real quick too so in this case it was using the the tls challenge which um if you're doing this at home um so for me at home my isp i have cox they block port 80 at home um so what are the nice things with the tls challenge it's not supported by a lot of the standard let's encourage agents like i think certbot and some of those it handshakes a little bit differently so you can only they'll validate your cert and sign it with only port 443 open um which cox does allow so depending on your isp if you're trying to set up a home lab for something like this traffic in some respects is easier than some of the traditional stuff where port 80 is closed so just something to kind of keep in mind as you play with it yay for home isps so um i know actually that's a good point too i i have in my config that i'm using the tls challenge it might actually be that when let's encrypt is going through here it's using 443 i'm not actually i'll have to check which route it's actually doing there but anyways um so yeah this makes it really nice to be able to do home setup stuff so if i'm doing any sort of a you know demo or i want to show something off or just run an app for you know my own use or whatever i just add the labels to it spin up the container and not only is traffic going to start routing to it but it's automatically going to get a tls certificate and go from there now one of the things to note too if you go this route let's encrypt participates in the and i forget that the full name of it but um transparent certificate transparency reports or whatever so i could actually i don't know how quickly it shows up but all of the domain names that i request uh all the certs that i request are part of a public list and so yes technically it's at home and i'm probably not going to link to it or you know all that kind of stuff i'm not going to share it with the world but folks will be able to see i i just requested a certificate for foster.novalog.micro37.training so if you're trying to do this and want to keep things kind of quiet or kind of secret that kind of stuff let's encrypt may not be the right issuer that you want to use there so just a heads up there i do just want to mention since we talked kubernetes a little bit earlier certificate management and kubernetes you could certainly use traffic but a lot of times people don't use traffic in kubernetes because they also have other certificate needs and so what they'll use is a tool called cert manager and cert manager is another component that's deployed to kubernetes and it makes use of what uh kubernetes its extensibility uh so within kubernetes you can define what are called crds which are custom resource definitions and allows you to define other types of objects and so yeah the the native kubernetes has no idea what this object is and nothing's going to respond to it but what crds allow me to do is i can define a new type of object and then i can also run another another controller that's watching that type of object and responding to it so it allows you to extend the event driven system that comes along with kubernetes insert manager does exactly this and we'll see an example of it here in just a second what's nice about cert manager is it allows it it does this certificate provisioning process and it can work with many providers so it can do acme let's encrypt section all that kind of stuff it can also manage a self-signed or local ca so if if i wanted from traffic to all my apps to actually be encrypted i can issue certificates from cert manager to each of my backend apps that are issued by a ca being run in the kubernetes cluster and so then i could configure traffic to say hey trust the the internal ca and so then i can still have trust between the the application so there's some pretty neat stuff you can do there as well and then what happens is when kubernetes or sorry when certain manager issues the the certificates it stores the the keys and the cert and kubernetes secrets where then other other things can pick up like traffic so an example of this um i can define a cluster issuer kind of just like the the certificate resolver um you know similar concept with traffic i can say i'm gonna i'm gonna define an issuer here in which it's gonna use acme here's the server endpoint um here's where to store the private key for the account that it creates with acme and just some other details about http resolving once this cluster issuer exists then myself as a maybe an applications team i can say i'm going to deploy an application so i'm going to go back to phil's example earlier i'm going to create an ingress object but i want that ingress to be encrypted so i'm also going to create a certificate and that certificate i'm going to i'm going to name it i'm going to use the let's encrypt issuer and i want the common name and dns names to have myapp.example.com alright and when when you're done with it i'll store the the key and the certificate and a kubernetes secret called my absurd okay um and so what what's going to happen is i declare and i apply these manifest insert manager which would then be running in a cluster we'll see these objects get created and we'll say oh cool i see this certificate object let me start the acme protocol and once i'm done here then it stores the details and the secret and then what that allows me to do is i can go back to my ingress and i can specify um this tls section at the bottom and say here for this host here's the secret name to use and and traffic again since this is ingress this ingress object is a standardized object traffic is already consuming the rest of it will also consume the tls portion of it as well and and i know this this chart may or may not make sense or whatever but as the request comes in the traffic for you know myapp.example.com it sees it and says cool that means i need to do tls termination using the credentials that are in this secret and so it does the tls termination back and back and forth with the the client there and then we'll send the request onto my app so it's kind of hard to draw the full flow without it being a uh you know with without it being you know just a a sequence diagram but anyways cert manager makes that a lot easier and uh and so then traffic for in most environments rather than traffic being the one that's doing the let's encrypt mechanisms you use something like this and then traffic just picks up the certs and and use it uses it from there so um i don't have an example of that to try out but it's pretty straightforward here so and with that um i will hand it back to phil any other questions or whatnot okay i haven't seen anything else come and we're almost done don't worry i know it's almost neat you guys are saying they were getting close to time so i'll try and make this part uh relatively quick so i guess the one last thing in my mind that traffic we still haven't covered is uh traditional whether it's a reverse proxy or load balancer typically offers the ability to modify the traffic um kind of before it sends it onto that back end so one of the things that you might want to do is maybe you have an ip like wait list allow list that you want to do to limit access um and you're just trusting traffic to reliably do that maybe you want to add hd basic off maybe you need to modify the request add a header remove a header um whatever so one quick example that we can do is we can create this middleware in this case this matches something that we're using at one main where we have a an api that we've written where we can say open api dot it and we're going to do a git of slash api slash v1 courses slash department computer science in this case 301 but our application on the back end is expecting just slash department name slash course number that way our developers in this case don't have to worry about you know what other apis are there or um and this kind of microservice design pattern where we can have our group that works on the course api doesn't necessarily need to know that there's also a people api or a you know events api and a calendar api and all these other things that might exist all they really need to think about is i'm writing courses so what do i want mine to look like so then we write this kind of crazy middleware thing um with regex as you know everybody's most favorite thing to deal with so in this case we've written it pretty simple we've api slash v something we don't really care what it is um and then whatever the next word is we're just gonna in this case the type of this middleware is called a strip prefix regex where anything that matches this we're just going to rip off the request before we pass it on to the back end so this incoming request from the front end ends up looking like what we expect on the back end so traffic kind of modifies that while it's in flight your applications have to know about it this isn't something you would necessarily do want to do super widely especially for like things where relative paths are expected and stuff because it can make weird things but for apis these middlewares are really really kind of slick and you can do a lot of neat things with it so this is just one example of how we use it um and then there's some other crazy syntax for interest of time we'll skip over it but where you attach this middleware to an ingress object or you can attach multiples so maybe i want to take one of these and say this is only allowed from our within our campus network um but also i want to modify the path on its way in so you can chain these different things together and the reason this is written in regex is we can reuse this across multiple things so if this was the events api we could reuse the same type of thing across multiple implementations of it so there's a bunch of these built-in ones um they also have this new feature that's uh i think it was released in 2.4 um it's relatively new it's still kind of i think labeled beta and experimental but there's a way to write your own custom middleware things it's all in go um it requires integration with this cloud monitoring tool called pilot that traffic uses um there's actually some really cool stuff out there um if you have chance you might want to go to that website at some point and look at all the plugins um they have some really cool ones with swarm that will like you can essentially stop a service and when the first request comes in it will traffic will talk back to swarm and start it up and you can really kind of do some kind of really interesting things that definitely wouldn't normally be in the base piece of traffic as a reverse proxy that does service discovery but it is really useful for things that maybe you want to add some extra coolness to it that maybe doesn't belong in the root tree so that's something that's kind of fun that they're working on um other notable features in traffic i'm just going to run through real quick obviously as sticky and persistent sessions i mean you can do tracing where if you've got some really complicated call of duty service a call service b that calls service c and you don't know which one was slow it can kind of help you check that stuff out using some of these other popular upstream tools that that are out there is a number of them it can do metrics collection um i can show a quick example of that if there's interest but something we do internally um where we use prometheus and we can just look at for every particular backend what's our request rate look like what are what response codes are we sending back that way we can do some quick metrics and how long is it taking so we can kind of just do a quick overview of what every what's traffic handling for us um i listed it as a feature json logging um so you can machine parse it personally like having something that's machine readable is nice luckily the apache standard is fairly easily parsed and the nginx thing is fairly common as well but with json i don't have to worry about if they add a key and things like that so that's something we also turn on um so i'm happy to dive into some of these i know we're at times so i don't want to just jump right into it um but for that i guess we'll kind of kick it over to questions our contact information is there if you think of something later you want to yell at us that we're wrong whatever it might be i'm putting something on the internet um and also too our twitter accounts are there i think both of us are most of our tweet stuff is related to the stuff um though with mine you're going to find a lot of motor sports in virginia tech things because i went to school there um so still an athletics fan in a big way um but our contact info is there if you want to yell at us follow us whatever um and if you'd like to see demos of some of that other stuff we can kind of pull up our internal i'm happy to pull up the william mary like consoles and things and we can look at it in a more enterprise environment if people want to yeah and i can show off uh we've got a pretty neat uh qa environment that does some of what uh phil was just talking about with uh you know we've we've got lots of feature branch based deployments and uh if a specific deployment doesn't get access over us maybe a 30 minute period it automatically scales it down so that nobody can we're not paying for it but then the the first time somebody tries to access it we go to this launcher page and and spin it back up and and traffic's a pretty integral piece to that too so um there's a lot of really neat things that we can do um there um a question just came in do you utilize k3s in your cluster um so i don't use k3s in my we're not using our production clusters in in aws or you know for for virginia tech but um well i i can't pull it over but like i've got actually a raspberry pi cluster here um this one's just not plugged in right now i've got another one that is plugged in and especially for like arm or you know small iot kind of stuff like that i'm definitely using k3s because it's a much lighter weight um orchestration framework there it's basically kubernetes but it's just stripped down a lot that's why they they shorten it from k8s to k3s eight three is less than eight it's just stripped down yeah so um but yeah i i and i use traffic ingress uh on that as well too and i guess with that just for completeness my answer is the same as michael's we don't use it at women mary but at home i use it on raspberry pies and things like that too all right and with that since if there are any more questions you've got like 10 15 seconds to get them in otherwise i'm going to go ahead and stop the recording so we want to chat i'm looking well i saw that but that'll be after i turn off this okay

Channel: Traefik Labs

Views: 1,969

Keywords: docker, kubernetes, microservices, traefik

Id: 6cdC9XxdPns

Length: 112min 54sec (6774 seconds)

Published: Mon May 17 2021