Manage multiple sites with Docker Compose and Traefik

hey everyone Andrew here I wanted to show you how I manage multiple sites when I use Docker everything in this video will be done in my local environment but you should also be able to follow the same steps for production servers as well alright I have this application here and it has a separate backend and front end the front end is powered by JavaScript in the back end by PHP if I open up the docker compose file for it each of those sections is served as a separate service so the app is the front-end portion of it and it's served on the 8081 Port where the API is the backend portion served on the 8082 port this is currently up and running in Docker and if I go to the browser we can see localhost 8081 is displaying the JavaScript application and localhost 8082 is displaying the PHP application which will be the backend API now in this application both of these are expected to work in tandem together but besides just being annoying having to tack on the port numbers in the URL there's a problem and that is that browsers treat URLs with different ports as completely separate domains which can come with their own set of problems especially if you use cookies or anything like that for Authentication ideally I'd like them all to be on the same domain and that's where traffic comes in traffic is a HTTP reverse proxy and load balancer application built and go that's readily used in containerized environments so it's perfect for our use case let's get started and I'll crack open my Docker compose file again and at the bottom here we're going to add in a new service we'll call it traffic and it will use an image traffic and the latest tag which at the time of this recording is version 2.9 next we need to pass in two arguments with the command attribute API dot insecure is true which allows us to use it without providing SSL certificates and providers dot docker which specifies what container platform we're using it has two ports that we can expose one at 80 which we will map to 80. that's where the actual web traffic from our browser is going and then there's another at 8080 which we will also map to 8080 locally and that's a handy little dashboard view that I'll show you later on finally we need to mount our Docker socket to it using a volume VAR run Docker dot sock to the same directory and location Varun docker.soc now the other services that will be using this should depend on this new container so we'll add that to their respective lists so scrolling up API now depends on my SQL but it should also depend on traffic and so should the app service so now as both of these spin up traffic will be the first one to be provisioned so now we can go ahead and utilize these changes let's go ahead and open up the terminal and we're going to restart our containers Docker compose down and Docker compose up D all right everything is started and we can run Docker compose PS to make sure that everything is running and it is and now let's go back to the browser real quick and we can see that everything is still running as expected in its ports but what happens if we just go to localhost and we get a 404 page not found that's good because that means that the traffic container is running and getting traffic to it but we don't have anything called host rules set up for this yet and those are the domains that are used in routing traffic from the browser to one of the services listed in our Docker compose file if we head over to the 8080 port we can see this cool little dashboard view for us that traffic provides if we check out the HTTP tab we can see our two Services here under API full stack app and app full stack app but we can't actually visit these in this state because the hostname is not exactly a fully qualified domain name we can fix this though let's go back to our Docker compose file and under each of the two containers running our app Services we need to create a labels section in it we just need a single label and that's a string that starts with traffic dot HTTP dot routers and then a DOT followed by the service name of the container we're currently in for us that is app so app and then dot rule equals posts and then in parentheses we provide the hostname for it that we want to use let's just use app.localhost since anything that ends in localhost is automatically routed to the localhost 80 Port this will make it easier for us I don't need to add this to my Etsy host file all right and now we need another one for the API so we'll just copy this section here and then in the API service we'll change this from app.localhost to api.app.localhost and we need to change the app service to API okay let's save this and restart our containers Docker compose down and Docker compose up D okay now let's open up our browser and if we refresh the traffic dashboard here we can see that our hosts for our services have been updated to use api.app.localhost and app.localhost and if we use those in the browser we can see that we're getting routed exactly where we expected so app.localhost is in our JavaScript application [Music] while api.app.localhost navigates us to the PHP application so no more juggling between ports everything goes through Port 80 and is routed to the particular service based on the domain that we use just as another example let's say that we don't want to use a subdomain for the API and instead want it to be on part of the domain like app.localhost slash API well we can just make a simple change to the api's traffic label we'll wrap what we have here in parentheses first and then we'll swap out the host here to mirror the app so just app.localhost and then we can tack on and path prefix and then provide it with a somewhat obvious path prefix so like slash API so that means that any traffic that goes to app.localhost slash API and any other route afterwards will be routed to this service here whereas the main app.localhost will still be routed to this app here as well as any other paths after it that are not API and let's see this in action I'll just restart my containers one more time all right I'm going back to the browser we can see api.app.localhost does not resolve anymore app.localhost still does and if we go to slash API it says 404 not found but it's being routed through the PHP application there's just no route available for slash API but if I went ahead and added that in just for this example's sake we can go to the backend application routes API and create a route get slash because it's already prefixed with API and return a hello world so now saving this and going back to the browser we can see we're getting back hello world now from the PHP application at slash API and of course heading back to the traffic dashboard we can see the changes reflected here all right I think that's it for this video traffic's pretty powerful and it's a great addition to your orchestration tool belt whether you use it locally or in production we barely scratched the surface of the features it provides though here's a documentation site for it and it's just chock full of different configurations and additions that you can add to your particular instance anyway I just wanted to Showcase a basic example of how I use it specifically to Route traffic to a few separate Services especially when I'm working locally as always if you have any questions about this or any other web development topics please feel free to reach out to me in the comments or on my Twitter linked below thanks for watching

Channel: Andrew Schmelyun

Views: 23,681

Keywords: docker, traefik, docker compose, docker-compose, docker tutorial, docker tutorials, traefik tutorial, traefik tutorials, traefik with docker, traefik with docker compose, traefik with docker-compose, traefik php tutorial, traefik javascript tutorial

Id: mZbLvGQqEvY

Length: 8min 35sec (515 seconds)

Published: Fri Oct 07 2022