0:02 hey guys Chris Shia and in this video we
0:05 are covering traffic the free and open
0:07 source reverse proxy that allows you to
0:09 easily set up and manage routing and
0:12 https for all of your applications and
0:13 get rid of this annoying certificate
0:16 warning in your browser it is absolutely
0:18 amazing I know if you're following this
0:20 channel you might know it already since
0:23 I often covered it in previous videos
0:25 however since the latest version of
0:26 traffic changed a couple of things here
0:28 and there and my last tutorial is
0:30 already a bit old I wanted to make this
0:33 new video to recap all of the important
0:35 installation and configuration steps in
0:37 traffic to easily get started today
0:40 we'll focus on the docker integration as
0:42 well as setting up trusted T
0:44 certificates from let's encrypt so no
0:46 kubernetes in this part but don't worry
0:48 I'm also working on a second part of
0:49 this video covering the kubernetes
0:52 deployments as well so this video is for
0:54 everyone using traffic and DOA no matter
0:56 if you're just a beginner or you're
0:57 already familiar with it but you just
0:58 need a little update about the new
1:00 version configs so keep watching and
1:03 let's check it out together before we
1:05 start I've got something else that might
1:07 be interesting if you're a developer
1:09 using Docker to automate workflows or if
1:12 you're handling data collection tasks
1:13 then you should definitely check out our
1:16 today's sponsor bright data with bright
1:18 data you can seamlessly integrate
1:20 Advanced tools for web scraping proxy
1:22 management and Cloud connectivity right
1:25 into your darker containers right data
1:27 offers a robust Global proxy Network
1:29 that lets you bypass gear restrictions
1:31 and captur seamlessly all from within
1:33 your darker containers just imagine you
1:35 need access to gear restricted content
1:37 for testing or web scraping these
1:39 proxies are super useful for that task
1:41 and they let you operate like a local in
1:43 any region worldwide and just because
1:46 we're talking about security and hdps in
1:48 this video of course they've got https
1:50 enabled making your data collection
1:53 fully encrypted and secure as well with
1:54 just a few lines of code the bright
1:57 data's web scraping API can scale data
1:58 collection tasks across multiple
2:01 containers make it ideal for handling
2:03 large data sets in no time but it's not
2:05 just about collecting data what happens
2:08 next right data also integrates smoothly
2:10 with any major cloud service like AWS
2:12 Google and snowflake so what are you
2:14 waiting for supercharge your data
2:16 workflows today try out bright data for
2:18 free and simly integrate powerful web
2:21 scraping tools Global proxies and secure
2:23 data collection right into your Docker
2:24 setups of course you will find a link to
2:26 their website in the description box
2:28 down below and now let's get back to
2:30 topic and start setting up traffic
2:32 okay so I know some of you might be
2:34 already familiar with traffic so I'll
2:37 try to keep it short in simple terms
2:38 traffic is a free and open source
2:40 reverse proxy that allows you to Route
2:43 Network requests to services and apis in
2:46 an easy way it is often used to have a
2:47 better control and protection of
2:50 unencrypted web applications and protect
2:53 them all with https or TLS to make sure
2:54 the network requests are always
2:56 encrypted and the connection is always
2:59 trusted it can also act as a load
3:01 balancer to to automatically distribute
3:03 the incoming requests to multiple Target
3:05 services or noes that's why it is often
3:07 used as a kubernetes Ingress controller
3:09 but in this video as I said we'll focus
3:11 on Docker only but just that you know
3:13 traffic is a pretty versatile
3:15 application that can work in several
3:17 other scenarios as well and that's why I
3:19 absolutely love it and I'm using this on
3:21 all of my Docker servers and kubernetes
3:24 clusters to protect my web applications
3:26 and manage TLS certificates in an easy
3:28 and simple way now to get started with
3:29 it you first definitely should check out
3:32 the official documentation pages I know
3:33 since I've started to use it in many of
3:35 my videos I've always heard people
3:37 saying that traffic is kind of complex
3:39 and it doesn't work for them and so on
3:41 and yeah to some extent I have to agree
3:43 it definitely need some time to
3:45 understand how to use it and configure
3:47 it correctly but in my opinion that's
3:48 mainly not because traffic itself would
3:51 be complicated that's just the nature of
3:53 networking web security and protocols
3:55 there are so many different technology
3:57 Stacks that all need to play together
3:59 here but don't worry we will go through
4:01 all of the stuff together step by step I
4:03 also want to point you to my public
4:05 repository boiler plates on GitHub so
4:07 this is a place where I'm collecting all
4:10 sorts of templates for Docker ketes
4:12 terraform anible yeah all the amazing
4:14 Technologies I'm covering in my videos
4:16 and of course here you will find also
4:18 some great examples for traffic as well
4:19 so definitely check it out that will
4:21 help you to get started and configure
4:23 traffic to work with your
4:26 applications now first let's have a look
4:28 at how to install and set up traffic on
4:30 one of my virtual Docker servers so if
4:32 we go to the official documentation
4:34 Pages there's a great quick start guide
4:36 you will find some instructions on how
4:38 to install and setup traffic with the
4:41 darker provider so I'm just going to
4:43 copy this template here and modify it a
4:45 bit and for this quick demonstration I'm
4:47 opening a new connection to my server
4:49 demo 1 and create a new project
4:53 directory traffic demo 1 CD into that so
4:55 this is what we can use as a quick
4:57 demonstration here now let's go into
5:00 this directory on my remote server using
5:02 vs code so here we can create a new
5:05 Docker compost file where we can paste
5:07 all the content from the documentation
5:09 quick start guide uh by the way I hope
5:11 you have some general understanding and
5:13 practice in docka if you don't well I've
5:15 made some nice tutorials on my patreon
5:17 page that give you a great introduction
5:18 of course I'll link you this in the
5:21 description box down below and yeah so
5:23 here uh let me just modify a few things
5:25 of this file a bit so first of all I'm
5:27 going to change the name reverse proxy
5:30 to just set it to traffic I'm going to
5:31 remove some of the comments here we
5:34 don't need that and also add a container
5:36 name I think this is uh much better to
5:37 differentiate the projects from each
5:40 other and I'm also going to add a
5:43 specific pin version TCH here so you can
5:45 see this is currently using the version
5:47 3.1 which is at the time of recording
5:48 this video probably the latest version
5:51 but I'm going to check it on the docker
5:53 Hub so here we can see if we search for
5:56 traffic you can find the docker image
5:59 and all the version tags so here we have
6:01 a release candidate for version of 3.2
6:03 but I'm going to use what is equivalent
6:04 to the latest version tag this is
6:06 usually the latest stable version this
6:07 is the
6:09 3.1.5 and I'm also going to add the
6:11 restart policy and set it to unless
6:13 stopped so this makes sure whenever
6:15 you're making updates on your Linux
6:16 server and you need to restart the
6:19 server the traffic reverse proxy is
6:21 automatically restarted as well and
6:22 always up and running unless you
6:24 manually stop this stalker compost
6:26 project now one thing that is very
6:28 important at this point that you have to
6:30 take care of when you managing a bunch
6:32 of different Docker containers in
6:35 separate Docker compost files so usually
6:37 if you start this Docker compost project
6:39 it will automatically create a separate
6:42 Docker Network just for this project and
6:44 connect all the services listed in the
6:46 docker compost file to this project so
6:48 when you are adding a bunch of other
6:50 services that you need traffic to get
6:52 access to you can just list them here
6:53 and you don't need to care about
6:56 networks but most of the time when
6:58 you're managing multiple applications on
6:59 the same Docker server but you're
7:01 managing them in different Docker
7:03 compost projects they are usually
7:06 creating always isolated networks and it
7:08 is important that the traffic container
7:10 can reach out to all of the other
7:12 containers that you want to make
7:14 accessible through traffic so that's why
7:16 I usually create a separate Docker
7:18 Network just for adding the proxy
7:20 services so you can easily check with
7:22 the docker Network LS command what uh
7:24 current Docker networks you have Creed
7:26 on your machine don't choose the default
7:28 Bridge Network for this because um there
7:30 is no DNS resolving possible in that
7:32 Network so I would definitely create a
7:34 new Docker Network that you're just
7:36 going to call I don't know proxy I most
7:38 of the time use the name front end for
7:40 this so here we can check the docker
7:43 network has been created and when we go
7:45 back to the docker compost file we add a
7:47 new section here that is called networks
7:50 and add the name of our custom Network
7:52 in here now we need to make sure that we
7:55 set the external flag to true because
7:57 otherwise doer compost will try to
7:59 create this network but because we have
8:01 manually created it and managed it on
8:03 the docker machine we just need to
8:06 import this externally managed Network
8:08 to this composed project and of course
8:11 we also need to attach the container to
8:14 this network as well now this is a
8:16 simple and very minimalistic setup that
8:19 would in theory work but I just want to
8:21 make a few more customizations to it
8:23 because uh first of all as you can see
8:26 here in the command Flex there are some
8:28 Flex that configure certain settings of
8:30 the traffic reverse Pro
8:32 and I don't like to do it this way so
8:33 I'm just going to remove it here and
8:36 creating a new directory in the project
8:38 directory that I'm just going to call
8:40 config where I create a static config
8:43 file for traffic called traffic. yaml
8:45 and if we go back to the docker compost
8:47 project of course we need to mount this
8:48 static configuration file in the
8:50 container so I'm going to refer to the
8:54 current project directory config and I'm
8:57 just going to mount this single file
9:00 into the ETC traffic location so this is
9:02 where traffic will look up its static
9:05 configuration file and set it to read
9:06 only so the container cannot make
9:09 changes to its config file now before we
9:11 edit this config file I think we should
9:12 also quickly talk about the different
9:15 types of configurations in traffic as I
9:17 think this is a quite important concept
9:19 to understand so traffic has two
9:21 different types of configurations first
9:23 the dynamic routing configuration which
9:25 contains the router the service the
9:27 middleware and certificate definitions
9:30 we'll talk about this later and the
9:32 Startup configuration also referred to
9:34 as the static configuration which
9:36 contains the main settings of the
9:38 traffic application to define the entry
9:40 points the providers and some other
9:42 general settings like logging and so on
9:44 this static configuration file can be
9:46 set in three different ways which are
9:48 mutually exclusive so that means you can
9:51 only use one at the same time you can
9:54 use a ml or toml formatted config file
9:55 just like what we're doing in this
9:57 tutorial but you could also think about
10:00 using CLI arguments or environment
10:02 variables I personally prefer using a
10:04 static config file in yaml because I
10:06 think that's just the easiest way since
10:08 most applications we are using half yaml
10:10 based config file so everyone is
10:13 familiar with the language in syx and we
10:14 can easily Mount that config file into
10:17 the containers fight system of traffic
10:19 edit it in vs code and yeah that's
10:22 really practical but just that you know
10:24 in the end it is basically up to you
10:25 what you prefer using if you're
10:27 searching in the traffic documentation
10:29 for any settings of the static configur
10:31 uration you usually find examples for
10:32 all these three different types of
10:35 configurations and also no matter which
10:36 method you're using the config settings
10:39 are always the same so it doesn't really
10:41 make any difference what method you
10:43 prefer using all right so let's go back
10:46 to vs code and let's add some general
10:48 settings in this traffic configuration
10:49 file so here in the global section you
10:52 can Define some things like check new
10:55 versions set this to FSE so I like to
10:57 update my traffic and container images
11:00 myself I don't need any notification and
11:03 I'm also going to disable any
11:05 Telemetry and what is also pretty useful
11:07 especially if you're beginning to learn
11:09 how to use the traffic reverse proxy you
11:12 might want to set the lock level to
11:14 debug because otherwise you will only
11:16 see the errors so by default it is set
11:19 to the lock level error but sometimes um
11:21 if you experiment with a bunch of
11:22 different flags and settings in traffic
11:24 and it might not work directly you just
11:26 want to know if it's actually processed
11:28 and what is the reason behind this error
11:30 and then it usually helps a lot to
11:32 enable the debug locks of course you
11:33 will also see a lot of noise in the
11:35 locks but sometimes it's really helping
11:38 for troubleshooting also I'm going to
11:40 add the dashboard to the API and set it
11:42 to true so this is the administrative
11:45 dashboard and traffic also has an API
11:47 that you can access and now we also have
11:50 to add the entry points by default it
11:52 always enables this web entry point here
11:54 for TCP traffic which is the standard
11:57 port for HTTP but you can of course also
11:59 add any other entry points for example a
12:02 web secure entry point with the address
12:04 for for free so that's the standard port
12:07 for https traffic or you can also add
12:10 any other TCP or UDP port and protocol
12:12 just look up the documentation page for
12:15 entry points as a reference and also
12:17 don't forget if you added some entry
12:20 points to this config file that you of
12:21 course also need to make them accessible
12:24 in the docker container so here I'm also
12:26 going to add the port 4 for free for the
12:29 web secure entry point the port 88 is by
12:32 the way the port for the insecure
12:34 dashboard and API in traffic so because
12:37 we have enabled it here we don't need to
12:39 manually create this entry point because
12:40 it's automatically managed by traffic
12:42 when you enable the dashboard and
12:44 insecure settings of the API don't do
12:46 this in production this is just for
12:48 testing all right so that's basically
12:50 everything that we need uh we have
12:51 created the static config file the
12:54 docker compost file let's go back to the
12:56 terminal and let's start the traffic
12:57 reverse proxy by executing a Docker
12:59 compose up so this will pull down the
13:01 latest version and start up the
13:03 container so I'm currently starting it
13:05 in the foreground so that we can see the
13:08 lock files as I've explained if you
13:10 enabled the debug logging so then you
13:12 will get a lot of noise in here but it
13:14 also would tell you a lot about how the
13:16 system functions and if it's processing
13:18 the specific rules and settings you have
13:20 configured once we have that you can
13:23 also try and get access to the dashboard
13:25 so just enter HTTP your server name or
13:27 IP address where traffic is running on
13:29 the port 8080 and then you get access
13:30 access to the traffic dashboard by the
13:33 way by default it usually doesn't have
13:35 the dark mode enabled so definitely
13:37 click on that button here so that it
13:39 just looks a bit nicer and here in the
13:40 dashboard you can see all the
13:43 information about what rules Services
13:46 entry points routers you have configured
13:47 don't worry we will go through all of
13:49 the settings later here what is also
13:51 pretty nice in the latest version of
13:53 traffic there is a new button in here is
13:55 called plugins which takes you to the
13:58 traffic Labs plugin catalog so here you
14:01 can also connect different other plugins
14:04 to this reverse proxy some of them are
14:06 really very exciting so I definitely
14:07 will take some time looking at those and
14:10 making separate videos for example about
14:12 mod security where you can add stronger
14:14 uh protection and malicious pattern
14:16 detection to your reverse proxy it's
14:18 pretty cool and basically make this a
14:20 web security Gateway but yeah for this
14:22 video we don't have to mess around with
14:24 that okay guys so that's how you install
14:27 traffic in Docker and set up the static
14:29 configuration file with the entry point
14:31 and some other general settings now
14:32 let's have a look at how to route the
14:35 incoming Network requests to the Target
14:37 application services and to explain how
14:39 you can do this very easily in your
14:42 network we also have to look at your DNS
14:43 because let's assume you're running two
14:46 or more applications on the same server
14:49 to differentiate those incoming requests
14:51 you usually would have to expose them on
14:53 different port numbers because only one
14:55 servers can listen at one port at the
14:58 same time so without any reverse proxy
15:00 you would have to to connect to the IP
15:02 address or DNS name of your server where
15:04 the container is running and use the
15:06 port number to connect to the desired
15:08 Target application but of course that's
15:10 not really what we want when we're using
15:12 a reverse proxy because we don't want to
15:14 connect to our applications directly and
15:16 Define the different port numbers
15:18 instead we want to use traffic to
15:20 receive all the incoming requests for
15:22 the applications on the two entry points
15:24 and the standard ports and then traffic
15:26 should take care of forwarding those
15:28 requests to the actual Target application
15:29 application
15:31 and the best way to differentiate those
15:34 incoming requests is to use a new host
15:36 name for each of your applications you
15:38 want to access just to give you an
15:40 example how that would look like in my
15:42 home network so for example if I want to
15:45 access app one the fqdn the fully
15:46 qualified domain name what I need to
15:48 enter in the address bar of my browser
15:51 would be ab1 do server demo one. home.
15:53 creative. and of course the same would
15:56 also work for the application too on my
15:58 local DNS server which is an authorative
16:01 DNS for the home docreative dode domain
16:04 I'm having two DNS entries here one for
16:06 the server itself and a so-called
16:09 wildcard DNS record which resolves any
16:11 name in front of the server's name to
16:13 its IP address as well so that means
16:15 when the client makes a request to the
16:18 fqdn of application one the DNS server
16:20 will resolve the IP address of the
16:22 server where traffic is running traffic
16:23 because it's listening on the main entry
16:26 point will receive this incoming request
16:29 and by configuring a specific host rule
16:31 in traffic for the fqdns of your
16:33 application it knows where to send this
16:36 request to then you don't need to expose
16:37 the application itself on a different
16:39 port number anymore you can just use the
16:42 fqdn to access your applications on the
16:44 standard ports 0 or for for free for
16:47 hdps and every request is automatically
16:49 routed and protected by the traffic
16:51 reverse proxy just a quick side note at
16:53 this point here if you don't know how to
16:55 manage and set up a DNS server for your
16:57 home lab and you generally want to know
16:59 how to set up DNS record and an
17:00 authorative DNS server I've made a
17:03 tutorial about this entire topic so I
17:05 link you this in the description box
17:06 down below but generally speaking you
17:08 could also think about just using your
17:10 home router for this yeah most home
17:13 routers allow you to set static DNS
17:15 records for any domain or DNS record
17:17 that you want or you can use a network
17:19 security firewall if you got something
17:21 like this and so it's depending on your
17:23 setup and environment how the DNS names
17:25 are managed now to configure those
17:27 specific rules for the application
17:29 containers in traffic that I've talked
17:31 about we will need to use the dynamic
17:33 configuration of traffic now remember
17:35 this is the second configuration type
17:37 which is a bit different from the static
17:39 configuration because here you have to
17:42 use the supported providers in traffic
17:44 providers are infrastructure components
17:46 and have again different ways of
17:48 configur them I don't want to go into
17:49 too much detail here at this point and
17:51 if you're interested in learning these
17:53 providers here in this table you can see
17:56 what provider is configured in which way
17:58 but for this tutorial we only need to
18:00 know the docker provider and this is
18:03 configured using labels that you attach
18:06 to the Target applications containers
18:07 but first of all we need to enable the
18:10 docker provider which makes traffic
18:12 monitor all the events of the docker
18:15 demon therefore it needs to have access
18:17 to the docker socket so if we go back to
18:18 the docker compost file you can see that
18:20 we've mounted the docker socket as a
18:22 volume into the container's fight system
18:25 if there is a new container staring up
18:26 with some Docker labels and that's where
18:29 it gets its configuration from so to
18:32 enable this we just need to uh put those
18:35 entries here in the steady configuration
18:37 of traffic so we need to go back to the
18:40 traffic. EML configuration and add this
18:42 section in here now one thing that's
18:45 also pretty important by default traffic
18:47 monitors or the docker events and it
18:50 tries to expose each container that it
18:54 can see on the docker socket and this is
18:56 usually enabled by default and honestly
18:58 I don't like this setting because I like
19:00 to control myself which containers I
19:03 want to expose and make available on the
19:04 traffic reverse proxy and which ones I
19:06 might not want to expose and so
19:08 therefore I usually recommend to add
19:11 this setting to the docker provider and
19:14 set the exposed by default flag to false
19:16 now that we have configured the docker
19:18 provider we can now start adding the
19:20 docker labels to our example application
19:22 to make it accessible now in traffic
19:24 there are three different functions you
19:27 should know that Define how the requests
19:29 are routed to the Target applications
19:31 first the routers which configure how
19:34 the incoming requests are handled so
19:35 here you can Define the rules the
19:38 encryption settings and so forth then
19:40 the services which are used to configure
19:42 how to reach the target application
19:44 usually this is configured by default in
19:46 the docker provider so this is done
19:49 automatically for us and the middlewares
19:51 which are used to change specific parts
19:53 of the requests like changing adders
19:55 paths adding basic authentication and so
19:57 on in this video I'm not covering
19:59 middleware as I think it should be
20:01 covered on a separate video and it is
20:02 very much depending on your use case and
20:05 the target application so for routing
20:07 simple web applications we don't need to
20:09 mess around with services or middleware
20:12 so we'll only focus on routers for now
20:14 now as a reference again look at the
20:16 official documentation page of routers
20:18 so here you will find all of the
20:21 settings you can configure in the rules
20:23 which are a set of matches for the
20:25 incoming requests you can specify
20:28 depending on which rules traffic should
20:30 forward the traffic to the actual
20:31 container application so here for
20:33 example you could use a header matching
20:35 so if it matches a specific header in
20:38 the htdp request you can use regular
20:41 Expressions you can use host regular
20:42 Expressions you can also use path
20:45 mattres so for example only specific
20:47 paths should be forwarded to specific
20:50 containers I think the most simplest way
20:52 to achieve what we want is to use a host
20:55 matcher so this will basically match the
20:57 fqdn of our container application and to
20:59 demonstrate how that would look like
21:01 let's go to one example project that
21:03 I've deployed so here for example this
21:06 is a simple enginex Darko container that
21:08 is an example like any other container
21:09 that you might want to deploy on your
21:11 network again as I said uh in the
21:14 installation part of this tutorial if
21:16 you want to access those containers with
21:18 traffic you need to put it to the same
21:21 Docker Network so here we also need to
21:24 define the front and edor where we have
21:26 put the traffic reverse proxy to make it
21:29 externally managed and then attach this
21:33 container to the frontend network so
21:35 that traffic can see and connect to it
21:39 and now we can add the rules settings to
21:41 the label section of the darker
21:43 container so here first of all because
21:46 we have set the exposed by default flag
21:49 to Falls traffic will not try to Monitor
21:52 and expose this container by default
21:55 this you can do with the traffic. enable
21:58 flag and set it to true now we need to add
21:59 add
22:01 the router and then we need to define a
22:03 name for our router you can give it any
22:06 name that you want for example engine x-
22:08 htdp that's usually the name that I
22:12 prefer and then we can add a rule to
22:14 this setting and here if we go back to
22:16 the documentation we can use a host rule
22:19 or host regular expression whatever
22:21 method we want to use let's give it a
22:24 name just enginex I think this is fine
22:29 enginex do server demo 1. home. c.de so
22:31 this my local DNS server because I've
22:32 added a wild card DNS record will
22:34 automatically resolve to the IP address
22:37 of where traffic is running now we also
22:40 need to attach this to an entry point
22:42 because in the traffic dashboard you can
22:44 see we have defined multiple entry
22:46 points and I don't know by default I
22:47 think it will attach it to the web entry
22:49 point but I think it is better to
22:52 specify to which entry point it should
22:54 attach the router to so let's just add
22:56 the next configuration setting for the
22:59 same router and now we can set it to
23:03 entry points set it to web so one thing
23:05 is also important to understand if you
23:08 change any configuration to the labels
23:10 of any the container that you want to
23:13 expose via traffic you don't have to
23:15 restart the traffic reverse Pro you just
23:16 have to redeploy The Container if you
23:18 changed the labels again as I said
23:20 traffic will monitor the docker socket
23:23 and automatically apply those new rules
23:26 however because we edited something in a
23:29 static configuration file this requires
23:31 a restart so that to enable the docker
23:33 provider first we need to stop the
23:36 traffic container in the terminal and
23:37 let's just restart it let's let's put it
23:39 to the background here so I think this
23:43 is fine and now that the traffic proxy
23:45 has enabled the provider for Docker we
23:47 can simply take this container down and
23:50 restart it with the new labels that we
23:52 have attached to it and let's go back to
23:54 the terminal here I just want to show
23:57 you the locks here so here you can see
23:58 in the debug locks that's why why I said
24:00 is is really important for beginners to
24:02 learn how it's working you can see some
24:05 debu loocks configuration received for
24:08 enginex demo one here you can see the
24:10 router engine x- HTTP that we have
24:13 defined with the entrypoint web the rule
24:14 set that we have configured it
24:16 automatically created a service object
24:18 for us so that's why I said we only need
24:20 to take care about the routers here but
24:21 if you want to customize the service
24:24 settings you could also add another
24:26 label referring to this service name
24:29 here and change any of the those
24:31 specific settings if you want now let's
24:33 try to open this engine X web server so
24:34 here I'm just going to use the fully
24:37 qualified domain name in the browser as
24:39 you can see this is uh notifying us that
24:41 we're using an un encryption connection
24:43 so we're using the web entry point with
24:46 the HTTP protocol it's not using https
24:49 therefore it's saying not secure but as
24:51 you can see we get access to the engine
24:54 X service without having to expose the
24:56 engine X server using a port number or
24:58 anything all right guys so that's it
24:59 about the first part of the video that's
25:01 how you configure traffic throughout
25:03 incoming requests to the Target
25:05 applications now let's come to the
25:08 interesting part let's talk about TLS
25:09 because as you might have noticed we
25:12 only used the unencrypted HTTP protocol
25:14 for now but of course one of the main
25:16 benefits using a reverse proxy like
25:18 traffic is that you can add https
25:20 encryption to your applications and
25:23 issue trusted TLS certificates to
25:25 explain how that's working we need to go
25:27 back to the presentation don't worry I'm
25:29 not going into too much detail on how
25:32 TLS and hdtp works by the way I've done
25:34 a video Once on self sign certificates
25:36 in the past where I explained a lot
25:38 about the certificate verification
25:39 importing the certificate chain in your
25:40 browser and so forth if you're
25:42 interested of course I'll link you that
25:44 in the description as well but for this
25:46 video I want to focus on certificates
25:48 from lets en Crypt which is a nonprofit
25:51 CA a certificate Authority that allows
25:53 you to issue trusted te certificates
25:56 completely for free the cool thing about
25:57 this is that if you're using those
25:59 certificates for your applications you
26:01 will never see a certificate warning in
26:03 the browser again because the ca of
26:06 let's encrypt is imported into every
26:09 devices browser or operating system as a
26:12 trusted CA by default so any application
26:14 or service that is using valid let
26:15 encrypt certificates will be
26:17 automatically trusted by any device in
26:19 the world to issue those trusted TLS
26:21 certificates from lets encrypt you have
26:24 to have a public domain which you also
26:26 Ed in your DNS server to resolve the IP
26:28 address of traffic that's by the way Al
26:30 the reason why I'm using a subdomain of
26:33 my C creative. de domain for my home lab
26:35 because then I can easily have trusted
26:37 and valid certificates for any services
26:39 in my entire network now to issue TLS
26:41 certificates from let's encrypt in
26:43 traffic you also have to connect it with
26:45 a DNS provider like Cloud flare that
26:48 supports the akma protocol which stands
26:50 for automatic certificate management
26:52 environment I know technically there are
26:54 also other ways possible traffic has
26:56 Integrations for many other DNS
26:57 providers available that automatically
27:00 handle the DNS Challenge and the
27:02 verification of course you could also do
27:04 it manually and so on but I think using
27:06 Cloud flare as a DNS provider is just
27:08 the best way to do it because Cloud
27:10 flare is free it is super reliable and
27:12 it also has some other very exciting
27:15 features like apis web security and
27:17 other cool stuff so yeah Cloud flare is
27:18 absolutely amazing a big recommendation
27:21 from my side however if you prefer using
27:23 a different DNS provider then feel free
27:25 to check out the documentation of
27:27 traffic if your DNS provider is listed
27:30 here if it's not well you might consider
27:32 switching over to one of these supported
27:34 providers like Cloud flare don't worry
27:36 you don't have to transfer your entire
27:38 domain to Cloud flare you just have to
27:40 switch the name servers on your DNS
27:42 regist so where you have registered your
27:44 public domain and just insert the name
27:47 servers of cloudflare just check the
27:49 documentation of your DNS register how
27:51 to do that I'm pretty sure they have
27:53 something about it and also Cloud flare
27:55 has some great documentation about this
27:57 topic so I think I don't need to go into
27:59 too much detail here uh by the way for
28:01 most common top level domains you can
28:03 even use cloudflare itself as a domain
28:05 register so they have added this service
28:08 for about a year or two unfortunately
28:11 you can't use it for the German de top
28:14 level domains but for any or net domains
28:17 I'm always using cloudflare so once you
28:19 changed the name servers and imported
28:21 your registered domain into cloudflare
28:23 or maybe you have registered it directly
28:25 in Cloud flare then you should see it in
28:27 the administrative dashboard and you can
28:30 start making changes state now to issue
28:33 trusted CLS certificates that are valid
28:36 for your domain you have to prove that
28:38 you have the ownership of the domain and
28:40 the way this is working is by using a
28:43 so-called DNS challenge so let's encrypt
28:46 will challenge the DNS provider to
28:49 create a specific txt entry in the DNS
28:52 settings and that way you prove that you
28:54 have the ownership of the domain because
28:56 only the owner of a domain should be
28:58 able to make changes to the n settings
29:01 right and using the akma protocol this
29:03 is done fully automatically in traffic
29:06 the way it works is you need to give the
29:09 traffic reverse proxy access to the
29:11 domain Zone that you want to issue the
29:13 TLs certificates for and that is by
29:16 creating an API token and adding it into
29:18 the traffic reverse proxy to create an
29:21 API token in Cloud flare you need to go
29:23 to your profile click on my profile and
29:26 go to the API tokens section here you
29:29 can create and manage user API tokens
29:32 and you can also download the API Keys
29:34 now I personally would prefer to create
29:37 a token because with a token you can
29:40 very specifically Define permissions for
29:43 the user otherwise with an API key that
29:46 is global you give anyone access in to
29:48 your entire Cloud flare account and
29:50 maybe that's not what you want so I
29:51 definitely would create a separate API
29:55 token for each traffic reverse proxy
29:57 that you that you have created you can
29:59 use an API token toen template so you
30:00 don't have to mess around with the
30:02 permission flags and so on so just
30:04 choose the edit Zone use template
30:06 because as I said the traffic reverse
30:08 proxy needs to create a simple txt
30:11 record on your DNS zone so it only needs
30:13 this permission here so here you can see
30:15 all the domains that you have registered
30:17 and just select the domain that you're
30:19 using on your local DNS server for
30:22 resolving the internal IP address no you
30:24 can also give it an expiry date but yeah
30:26 I don't like this because then you have
30:28 to always change the API token on your
30:30 traffic reverse box that's a bit
30:33 annoying and let's create this token now
30:35 this token will only show up once so
30:38 make sure to store it in a safe location
30:40 then attach it to the traffic reverse
30:41 proxy the way how you can do this is by
30:45 using environment variables so here in
30:47 the main project directory I will create
30:50 a EnV file and then you need to use a
30:53 specific variable so in the traffic
30:56 documentation when you go to https and
30:58 TLS and go to Let's en crypto
31:00 here you can see the specific
31:02 environment variables that the resolvers
31:05 need depending on what DNS Challenge and
31:07 which provider you're using so here you
31:09 can find all the DNS providers uh again
31:11 we are using Cloud flare here we have to
31:16 use the CF DNS API token so let's copy
31:18 this value in here let's add this to the
31:21 environment variable and if we go back
31:23 to the dock compost file of course we
31:26 need to add this environment and then
31:28 the traffic container should have this
31:32 uh secure token now to issue trusted TLS
31:34 certificates we also need something else
31:37 if we go back to the documentation in
31:39 the overview section there is an object
31:42 that we need which is called certificate
31:44 resolvers so by creating certificate
31:48 resolvers traffic knows how to issue and
31:50 retrieving certificates from an akma
31:52 server and of course we need to create a
31:55 certificate resolver for cloud flare so
31:57 I'm going to copy a template that I have created
31:58 created
32:01 that I want to add to the traffic. yaml
32:03 file so here I usually add it somewhere
32:05 here in this section here in the
32:08 certificate resolvers section you can
32:11 add different types of resolvers so here
32:12 I just create one that is called
32:15 cloudflare um you have to set your email
32:18 address in here and create a storage
32:21 location so I usually store them in a
32:24 VAR directory that is called traffic SS
32:26 so this of course also has to be a
32:28 persistent volume because otherwise
32:29 every time you restart the traffic
32:31 reverse proxy it needs to regenerate and
32:33 reissue those certificates and that is
32:36 not what we want also what is very
32:38 important here if you're using a DNS
32:39 Challenge and add the provider Cloud
32:42 flare you need to have those IP
32:44 addresses in the resolver section
32:46 because otherwise the traffic reverse
32:49 proxy will try to resolve the names
32:52 using your local DNS server and that
32:54 might not work correctly so therefore
32:57 you have to add those IP addresses here
32:59 as well again if you want to have those
33:01 templates check out my B plates
33:03 repository on GitHub so there I usually
33:05 manage all those templates you can copy
33:07 and paste to your configurations one
33:09 thing that we just need for this is we
33:10 need to go back to the docker compost
33:13 file and create a persistent volume for
33:16 this uh so here maybe let's add a data
33:18 directory that we use for these
33:20 certificates also going to create a
33:23 Sears folder in here and mount this into
33:26 the location that I've specified in the
33:29 certificate resolvers over
33:32 traffic Sears and make this read right
33:34 of course because traffic needs you
33:36 issue and generate and retrieve the
33:38 certificate and Stor in this location
33:41 and that's what we need to issue
33:44 certificates so traffic handles the TLs
33:47 certificate um request and generation
33:49 process fully automatic uh you just need
33:52 to tell it to do so and that you can
33:55 usually do again in the applications
33:57 labels so if we go back to our ngex the
34:00 one doer container we can create a
34:02 separate router for the web secure entry
34:04 point because for https we need to use
34:06 the different entry point of course
34:07 we're not using the port 80 we're using
34:10 the port 4 for free so again we have to
34:14 create a new HTTP router and call this
34:16 engine X https just give it a different
34:19 name and here we first want to enable
34:22 TLS so this is the uh encryption
34:26 protocol then we need to add a sech
34:29 resolver and say set this to name Cloud
34:32 flare so this should be the name that
34:34 you have created here in the static
34:36 configuration file if you have a
34:38 different name here you need to use a
34:39 different name here for the SE resolver as
34:40 as
34:44 well and then we also need to define the
34:46 web secure entry point for this router in
34:47 in
34:50 here and of course we also need a host
34:54 rule so that traffic knows based on
34:56 which rule it should forward the traffic
34:58 yeah so I think that's fine now we have
35:00 two entry points here one for the
35:04 insecure HTTP protocol and one for the
35:07 https protocol so I think I missed that
35:11 one here TLS dot all right so let's take
35:13 the container down and take it up again
35:15 and because we have made changes to the
35:17 static configuration file of traffic of
35:19 of course we need also need to restart
35:21 the traffic container so now you should
35:24 see that it starts issuing the
35:26 certificate for the engine X reverse
35:28 proxy it starts to solve the NS
35:30 Challenge and that might take a few
35:32 seconds depending on how fast the let
35:34 encrypt and Cloud Flash servers are and
35:37 once it has creaded everything you
35:39 should be able to access the engine X
35:43 server through the https protocol as
35:46 well so let's start using htps and as
35:48 you can see that's the icon for the
35:51 connection is secured in Chrome so here
35:54 we can see we have now a valid TLS
35:58 certificate that is issued by this
36:00 certificate Authority so this is ECA
36:03 from let's encrypt and our certificate
36:06 is valid for this domain so once that
36:08 works you can access your engine X
36:12 server using HTTP or https because both
36:15 entry points are enabled now I
36:17 personally I would always try to
36:21 redirect the unencrypted htps protocol
36:24 to the https Target using using a
36:26 permanent redirection route and there is
36:28 also a very simple way how you can do
36:30 this in traffic so if we go to the
36:32 routing and load balancing section entry
36:34 points here there is an https
36:37 redirection rule that you can attach to
36:40 the web entry point here so basically
36:42 you can just copy this part here which
36:45 will add a permanent redirection so just
36:48 add this configuration setting in here
36:51 and restart the traffic reverse proxy so
36:53 now if we try to access our engine X
36:55 server using the UN unsecure https
36:57 protocol it will automatically red
37:00 direct the connection to the secured
37:03 https address and that's how you can
37:05 automatically add protection to all your
37:08 unencrypted web services by the way once
37:10 you have that permanent redirection you
37:12 could also think about removing this
37:14 entry point here from the configuration
37:16 because then you only need the https
37:19 entry point to be available all right so
37:21 yeah that's how you can easily install
37:23 and configure traffic to add https to
37:25 all of your services and applications in
37:27 Docker I think this is really really
37:29 amazing and that's also the reason why
37:31 I'm using it in so many of my other
37:33 videos by the way if you're looking for
37:35 adding more protection and a secure
37:37 authentication to all the applications
37:39 running in traffic then definitely check
37:40 out my video about the free and open
37:43 source IDP authentic of course I will
37:44 leave you a link in the description box
37:46 down below and as always don't forget to
37:48 check out my content on patreon and yeah
37:50 maybe consider supporting all the free
37:53 tutorials I'm making like all these
37:55 amazing people down here thank you so
37:57 much for watching guys have a nice rest
37:59 of your day and I'm going to catch you
38:03 in the next video take care bye-bye [Music]
