The deployment application is one of the most complex skills for developers of any level, and mastering this skill truly makes you a cool specialist.

Today, we will deploy a server together. This will be the frontend part of the video, which will be useful for frontend developers. It doesn't really matter what language you write in because the algorithm is the same everywhere. We will see how it all merges together, explore two ways to deploy our application, and of course, find out how much it costs, what server configuration is needed, and where to rent a cloud server.

In just this one video, you will gain a lot of skills and knowledge and learn to deploy your projects independently. My name is Artem, I am a senior Python developer, and on this channel, I help you enhance your hard skills and develop your career.

Let's get started!

I have a very simple project that we won't be creating today; it is already written. It consists of about 30-40 lines of code. We have a frontend application that essentially displays data from the backend. It has one endpoint, Items, and returns data from GitHub, Docker, and Angular in a random order along with images.

So, if we go to the Items endpoint, we will see this data in a completely different order. I have this running locally on two different terminals. One terminal is running the backend on port 8000, and the other is running the frontend on port 5173. Right now, these are two different servers working locally.

Let's look at the deployment problem. We have a frontend that works on one port and displays data. It communicates with the backend, which is on another port. The issue is that usually, all websites are on a single domain, where both the frontend and backend coexist. But right now, we have two separate, roughly speaking, websites that only work on our computer.

How do we connect them? When I was a beginner, I had no idea how to merge them together. Did I need to buy two websites? In reality, it's much simpler. There are two popular strategies to connect the frontend and backend.

The first one we will look at is reverse proxying, where we deploy the frontend on our main site and the backend on an API address. Essentially, it will just be a request to the same site through the API endpoint, like Items or whatever you have in your API.

The second method is using a subdomain, where we create another domain on our main domain, like api.mysite.ru, and the frontend communicates with it. This way, we separate the sites, and I actually prefer this method a bit more, but it is naturally a bit more complex.

Today, we will focus on reverse proxying. The video is quite long, so there will be a second part where we will register a domain, create a subdomain, learn to obtain SSL certificates for HTTPS instead of HTTP, and set everything up in Nginx so that it runs smoothly and users are satisfied.

You will also find five of my interview sessions on Boost. These include interviews for a stack developer, algorithmic leetcode interviews, tech lead interviews, and much more. So, subscribe; the link will be in the description. I would be happy to see you there.

Now, let's return to our project. Currently, it looks like this. We are not very interested in the code; our frontend communicates with the Items endpoint and displays all these items. The backend returns these items, and there is nothing complicated here.

It is very important that every project should have CORS configured. In the case of Python with FastAPI, this is done using middleware, where we specify the address of our frontend so that it can communicate with the backend.

On any other language or framework, you probably already have some utility, library, or just helper code to add CORS. Always remember to do this on the backend side.

What we will do is write two simple Dockerfiles to package everything into containers. Nowadays, almost all companies use Docker and containers for development because it is a convenient way to transport our images and projects.

We will create a file called Dockerfile, and you will see how to create universal Dockerfiles. It won't differ much for the frontend and backend. If we take Python, we will use a Python image and one of the latest versions, preferably a slim version, because we don't want to use a large image that takes up too much space.

At the end, we will have a command; for any other language, it will be a different command. For us, it is Python and pip. We have an entry file for launching, and what happens inside is not important what language it is.

It involves installing dependencies and copying all files into the image. First, we want to run the command to install dependencies, which is in the requirements.txt file. Here, we have only two dependencies, two libraries.

After that, we want to copy all files from our current directory into the Docker image. It is important to note that before installing dependencies, we need to move the requirements file into the Docker image first.

Notice that we don't first move all files and then install dependencies. We first move the requirements file because it changes infrequently, install them, and only then copy all the other files that change frequently, which are the Python code files.

Why is this done? Because Docker can cache layers. Each of these steps creates a separate layer, and if our requirements.txt hasn't changed, we won't have to wait 1, 2, or 10 minutes for dependencies to install. They will already be in the cache, and we can just copy the files from the directory into the image, and the deployment can happen in just 10-20 seconds.

Let's quickly go through this process. We have two folders side by side. Here, we will have the Node image. We are not interested in Python; we are writing in JavaScript and will also use one of the latest versions of Node Alpine, and we will name it Build.

Next, we will see why we need to do this. Our dependencies are not called requirements but package.json, and they are all stored there. By the way, you will find all the project code in my GitHub; it is a very valuable resource because it will include configuration files, Dockerfiles, Docker Compose, and everything you will likely need when deploying your own projects.

So, make sure to check it out and give it a star. We copied the dependency file, and now we need to install them. This is done with the command npm install. After that, we copy all remaining files and run npm build.

What command do we use to run it? Actually, there is none because our frontend consists of JavaScript, HTML, and CSS files, which are just static files. We don't need to run anything.

In this case, to serve these static files from the container, we will run a command in this container to serve them. It will have a rather simple function. After the npm build command, a folder called dist will be created inside the Docker image. This is a classic name for the folder on the frontend where all the built bundles, so to speak, all static files are stored.

We need to copy them into the Nginx directory, which is /usr/share/nginx/html. This is actually quite universal code. You will likely encounter it in any frontend project to some extent when we copy our static files into Nginx.

We also need to copy a file called nginx.conf. Let's write it now. We will copy it into the classic directory where it always resides. You don't need to delve too deeply into the details of what these addresses are or where we are copying things because this is quite universal code, and you will find it all over the internet.

We don't have this file yet, so let's create it now. Before that, let's finish our Dockerfile. We will work on port 8000. You can choose any other port, but I just like 8000, so we will set it to work with that.

Our command will be CMD ["nginx", "-g", "daemon off;"]. This is a classic Dockerfile for the frontend that you can find all over the internet. It is a super basic, maximally compressed configuration just to serve the HTML file that we copied into this directory.

You don't need to get too caught up in the details of what is happening here or what is written. We are not hyper-optimizing our build; we just want to get this done.

So, let's continue with the overall build. The frontend is built, but how do we combine them? This question has been bothering me, and today I will tell you. It won't be very difficult.

If you are looking for a job or preparing for an interview and trying to understand what questions will be asked and how to answer them correctly, all of this is gathered in one place on the Solvit website. It is a whole platform for interview preparation where you can study all the questions in the question bank or only the top questions that are commonly asked in interviews.

You can think of it as a roadmap for beginners. If you are just trying to understand what steps you need to take to get to that coveted offer, and of course, the interview simulator allows you to choose the direction, language, grade, number of questions, and create a personal interview for yourself.

You can take it and see the analytics at the end, identifying your weak spots or, conversely, gaining confidence to know that you can answer everything and confidently go to interviews to find the best job.

You can track your progress in "My Progress," noting all weak and strong points, ensuring that you study a little every day to motivate yourself. Be sure to visit the Solvit website via the link in the description.

We will have a general configuration, but before that, let's create a Docker Compose file. For those who don't know, Docker Compose allows you to manage multiple containers at once, starting or stopping several at the same time.

We will use YAML format for our frontend and backend services. Initially, we will have two services: the first is the backend, and we will say, "Please build it" in the directory "backend." Don't forget the dot here.

We will have a similar service called "frontend." You can name it anything; it doesn't have to match the folder name. This is just a name you like. We will also run Nginx, or Engine, as it is called differently.

We will use a ready-made image from Docker Hub, not our local one. We don't have a stable image; we will use the same one we used for the frontend.

Next, we will work on some ports. The standard HTTP port is 80, and if we connect HTTPS, it is 443. But in this video, we won't connect it; we will do that in the next video on Boost.

Here, we will see how to connect and run our project so that it at least works. We will optimize it later and add HTTPS, which won't be too difficult.

It is very important that Nginx starts only after the frontend and backend have started, which is logical. We want to pass volumes so that it can see the files stored locally on the server, which will be on the server we rent.

We currently don't have a server yet, but we will create one. The Nginx configuration file will be our first file. We will say that it is located here locally, and you should place it in the container at this address.

Now, we have our Nginx configuration file, and we will fill it in. It is also important to remember to always connect containers in a single network. This is called networks, and you can name the network anything. I will name it "dev."

We will say that this container works in "dev," and this one also works in "dev." You can name it anything you like.

The Docker Compose file is ready. Now, we need the Nginx configuration file. You can find a standard default one on the internet. Let's do that now and modify it a bit.

You can simply Google "nginx.conf default file" or "default configuration," and you will find many different configurations. Here is one that suits us. Let's just copy it and paste it into our project.

I have removed almost all user comments. You can leave a note saying that our user will be called "root." We will have only one worker process, and we can leave the events section empty or even remove all location blocks.

We have left an empty configuration file; if we run it, it will work on port 80 and won't serve anything because we haven't defined any location blocks.

The simplest thing we want is for when someone visits our site, they get the frontend, which is running on port 3000. Remember, we are running the frontend here. This is the name we write here because it knows it lives in the same network.

We need to specify the magic word "proxy" so that all requests coming to the localhost address are forwarded to this container. Nginx will then translate the information back to the user in the browser.

Don't forget to specify HTTP here; there won't be any HTTPS since we are living inside one server. There is no need to connect any certificates here.

It is also very important to put a slash at the end. Be sure to copy the code from my GitHub to avoid mistakes.

Now, how do we handle the backend? It is actually very simple. We just add another slash here, and we have the backend service running on port 8000. It can be any other port; it doesn't matter what port we deploy on.

We also need to remember to put a slash here. Our configuration is ready. Of course, it won't be localhost; we will rent a server and add a real IP address here.

To rent a cloud server, we will use a platform called Selectel. It is a provider of servers, object storage, databases, and much more. It is a very cool platform.

Let's create our first project here. I have already created one; you can create your own, enter it, and create a new server. Here, you choose a random name, like "Saint Petersburg."

We will select the operating system; let's go with the latest Ubuntu 24. If you don't trust it much, you can choose 22, but there shouldn't be any problems with it; it is a stable version.

Next, we will need the minimum configuration: 1 CPU and 1 GB of RAM. Based on experience, the CPU and RAM will be most consumed when you are building Docker images. Applications don't consume as much when you are building images on your server.

This is definitely enough for us. We can increase the SSD a bit if we need a database. We need a public key to work with it.

Let's add an SSH key. We need to run a specific command in the terminal to create it. You can just press Enter; I already have this file, so I will create a new one called "selectel_youtube."

This will create a public key with an address. We can just type "cat" to display this key in the terminal. We will paste it here and add it, and now we can connect to the server without using a password.

Yes, we won't need a password; we will connect to our server automatically. Everything is great, and the price is only 35 rubles per day to deploy our project so that real users can work with the frontend and backend.

In principle, this is not much. We create the server, and in just 20-30 seconds, we will have our dedicated IP address and can connect to it.

Our server has been created quickly. We can copy its IP address and connect to it. If you have any issues with SSH, just go to the console, enter the password, and connect via password.

It is certainly more convenient to create an SSH key once. I will go to the SSH folder because I have a custom key with an unusual name, so the server will complain.

Let's connect: `ssh root@<IP address> -i <path to your SSH key>`. Enter, and we will be let into the server. Here is the welcome message from Ubuntu, and there is absolutely nothing here. There is no Git, no Docker, nothing at all.

The next step is to push all this data to GitHub. We quickly create a new repository, make it public to avoid any issues with SSH keys. If you have a private project, make it private, create SSH keys, and all that.

We currently don't have a README file, but let's create one for appearance's sake as if we have some documentation. I will copy everything here and paste it.

Let's open a new terminal, paste everything, and with just one command, our repository will be filled with data. Yes, we forgot to add all the other data. That's great!

Let's create a `.gitignore` file and write here the folders `venv` and `node_modules`, the heaviest folders with dependencies that we obviously don't need. We have only 20 files that we need.

Let's write here `git commit -m "Initial commit"` and push it to GitHub. Why do we need a repository? It is a convenient transport medium between our local computer and the server. We will pull code from GitHub to the server.

In real development, GitLab is always used because it is more stable. So, what do we do? We go to our server. Here we are, `root@<server>`.

Let's check if Git is installed. Git is not here, so we are told to run `sudo apt update`. This will update all packages, and now we can install Git with `sudo apt install git`.

We press "Yes," and Git will be installed so we can work with the repository. We will run `git clone <repository URL>`, and it will create a folder called "test_deploy_site."

We will go into it and see all our files. Now we need to install Docker. Let's Google "docker install ubuntu" and find two commands.

We will copy the first one and run it, and then we will copy the second command and wait for all dependencies to install. Everything installs quickly, and Docker Compose will also be installed pretty fast.

So, Docker and Git are installed; everything is great. Next, we just build our images with the command `docker-compose up --build`. This command builds the images and starts the containers in one convenient command.

We press Enter and watch what happens. We pull the Nginx image from Docker Hub, where all repositories are stored. We pull the Python image, we pull the Node image, and we wait for all dependencies to install.

In fact, the CI/CD process is quite complex. There are many nuances regarding where these Docker containers are built, where they are stored, how they are launched, and how they are deployed to avoid any downtime.

If you are interested in a video on CI/CD, please like and subscribe to the channel, and it won't take long to come out.

I made a small mistake; the command on the frontend is incorrectly named. Let's go to the frontend folder. The command should be `npm run build`.

Let's see how we make changes. For example, we fixed something, and we will push it to the repository. We will run `git pull` to pull all changes, and once again, `docker-compose up --build`.

Notice how simple and fast it is. In just a second, everything is built because we specified in the Dockerfile to install dependencies first in the backend.

Here, we first install them and only then copy all the other files. Right now, we are witnessing how we change a file, and we don't have to reinstall all dependencies.

This is super important. Let's check again, refresh the page, and we see an error. CORS error.