Transcription
Greetings to everyone on the channel I Dialogs. Today we will talk about a large and interesting area. This is the area of DevOps. And we will look at what tools like Cursor are capable of in tasks related to infrastructure deployment, application configuration, creating pipelines, building, and deployment. Today's video is for a wide audience. For DevOps engineers, it's an opportunity to see how various tools and practices significantly speed up their work or to get acquainted with some technologies if they haven't worked with them. For developers, this will be a useful practical video, because tasks related to delivering developed applications to some environments are very close to any developer. And for everyone else, in fact, it's an opportunity to be convinced that in this sphere too, the barrier is significantly lowered, the entry barrier, and that anyone who wishes can launch their own service, deploy their application somewhere. DevOps, if someone doesn't know, let's briefly go over it. In general, it's a philosophy, a set of tools, and practices that allow for a significant acceleration of the application delivery process, hypothesis testing. And in general, it's a huge variety of tools that have formed over the last, well, almost 10 years, that allow for effective solutions to various tasks. There are many tools, but there is a problem, as always. This whole area, infrastructure, servers, clouds, God forbid, the console, is what is often associated with this area. All of this is quite unfriendly, so to speak, to its users, and especially to users far removed from such tasks. Plus, there is a huge number of tools. They appear every day, and more and more appear. And each tool doesn't have some kind of standard. There are its own special technologies, languages, various formats, which are very difficult to learn, they differ from each other. In general, this creates a certain barrier, a serious one. And even the technologies listed here briefly. A small list, there, 1, 2, 3, 4, 5. We will not consider Kubernetes today. It is visible that each of these technologies has its own unique language. Either based on JSON markup, or based on YAML markup, plus various templates and so on, and so on. In general, using this was problematic until recently, but as they say, every cloud has a silver lining, right? With the advent of good tools like Cursor, and good models that know all these syntaxes, the entry barrier is significantly lowered. Today we will be convinced of this together with you. And we will be convinced with a practical example, not some kind of demonstration, but we have our landing page lmstar.ru, that is, a real industrial site. Here I opened it, it talks about our educational programs. This is a front-end application that is compiled into static files and published in the cloud, but it is done manually with the help of a script, written, but, in general, without any automatic tools and means. And what is the task? For now, while one person is developing this project, it is enough, but as soon as we want to involve someone else, it becomes problematic, how to see changes, how to develop something together. And a development environment is needed, of course. So, for this, we have specifically prepared startdev.ru for you, but we have nothing, no server, no infrastructure, no DevOps specialist. And the role of DevOps specialist today will be performed by Cursor, it will help me solve all these tasks. And as a disclaimer, I want to say that I have, of course, significant IT experience, but I have never been a system administrator or a DevOps specialist, I have never had any significant practical experience in tasks related to infrastructure, server configuration, let alone cloud servers. But, well, I have a certain, superficial, outlook, and I generally know what technologies are needed for what, at a level where anyone can, in principle, with ChatGPT or any other tool, based on their experience, choose a suitable technology stack. I will show and tell. I will try to go from absolute zero, just from the task to its completion, as quickly as possible, showing everything in practice. And we will do this, as always, with our classic approach with a roadmap, with small iterations. And in general, this task is probably characteristic of the role of a DevOps engineer, when developers, for example, a team hands over a project, asks to deploy it somewhere, create a new stand, and in general, to some extent, we will emulate real work. We will dive into the project, see how it is structured, containerize it, because it is not done yet. We will set up automatic building. Then we will create a server. Then we will configure this server. We will first perform manual deployment to this server, and then set up automatic deployment. And for this, we will use Docker, Terraform, Ansible, and GitHub Actions as a tool for continuous integration and continuous deployment. This is all called infrastructure as code. That is, in principle, all these unfriendly YAMLs, JSONs, templates, we will create them today. And let's start. We won't write anything ourselves. Cursor, I hope, will do everything for us. Let's start with the planning stage. I have prepared here, I wanted to say a small roadmap, but in fact, it's quite large. So, let's create an agent. We have nothing yet. The first stage is the planning stage, what is indicated in our prompt now. So, we say that it's a new stage, we describe what we will do, there is only a production environment, we will create a development environment, we will use some technologies. It is important that we will use an MVP approach, since all technologies can be used quite broadly and flexibly, and we do not need excessive complexity. Therefore, no redundancy, simplicity, conciseness, no redundancy, including in documentation. And we will develop the roadmap that I presented. The directory will be devops, there will be a doc file with the roadmap, we will look at it, and the roadmap will represent. So, in principle, I am not even creating any templates, I am saying directly in the prompt that this will be a visual table, where these iterations will be indicated. And for each iteration, of course, we will have a goal, what we will do, so that Cursor with Claude can help us write a small list of criteria, called definition of done, that is, what we will check as a result of completing the iteration. Well, and in general, if any documents, files, configurations were created, then, most importantly, for the future, decisions made. Some instructions, so that they are recorded. And below, in general, at a high level, an understanding for each iteration, immersion in the project, we will need to create a description infrastructure.md with a diagram of how it is now, and a diagram of how we want it to be later. Set up Docker, package it, create a Dockerfile, compose, then set up building, publishing, and so on for each section. In principle, there are some reference points here, the current domain, the domain we registered for the dev server. And in general, if we use Terraform, I have immediately prepared links to the official documentation. We will use Terraform, Time Weba, and some basic things that, if you know them, you can write yourself, if you don't know them, you can certainly research them. And what we will not do here, we will not choose this or that solution, we have already chosen them, but in general, let's say, behind the scenes, of course, I researched, consulted, what to choose for server management, what to choose for building and deployment, what is suitable in my specific case. And you can do this for your project and for your level of understanding. So, there are different options, of course. This option, as I said, is not the most trivial, but not the most difficult either. Let's go. Sonet model. So, let's see what we have created. A README file that describes the structure of the directories. A folder for accepted decisions, for recording accepted decisions, sprint results, and our roadmap. Let's look at it more closely. Automation, MVP approach, simple speed, minimum documentation, technology stack, basic Docker immersion, building, publishing, and then a detailed description. What needs to be done? So, we have a roadmap, and we need to dive into the project and do the basic thing – containerize it. I suggest combining the first two iterations, in principle, since the project is not very complex. Let's do that. Accordingly, plan. Open a new agent, open the roadmap, and we will perform all further iterations in planning mode and then implement according to the plan. Execute planning for iterations D0 D1. Switch to plan mode. This can be done by Shift Tab or simply by selecting it here instead of agent mode. In this mode, a document with a detailed plan for the implementation of the described operations will be prepared. If clarification is needed from the user for planning, then the necessary questions that affect the implementation will be asked. This is often very useful. This is a broad view of the task from the agent's perspective. Here's how the plan looks. Analysis of the state. What do we need? Description of the infrastructure, the current version. Using `npm build` static files are created, and there is a deployment script to Yandex Cloud S3 and access, of course, via a domain name. So, even at the planning stage, the agent has gathered the necessary context and a diagram of how it should be, right? That everything is built, deployed. Well, we will go through all this step by step. So, this first part needs to be documented. The second part, we need to create a Dockerfile, create environment variables, a docker-compose file for easy launching, and check all this. And, accordingly, we can save this plan. It might be useful for us in the future, which we will do, and we will execute it in agent mode. During planning, a small list was created, what the agent needs to do, and it follows this list and executes. Let's look at how this file describing the infrastructure looks for now. Project overview, landing page, technology stack. Everything is correct. We saw this even at the planning stage, how it works, how it runs locally, how it works on port 3000. For building, static files are generated, parameters that are used, and how everything is deployed. Production environment. Everything is clear. Some important dependencies, problems, and target architecture. Target architecture. Let's look more closely. So, we have a developer, who can, well, with a Dockerfile, check locally and uses GitHub branches Main and Develop. Upon push, corresponding triggers are launched, either a trigger for server configuration, or a trigger for building and publishing images, that is, the CI part, we will start with that, continuous integration, these are basic checks, linters, builds, tests, and in case of success, building a Docker image and publishing it to the Docker Hub container registry. And, accordingly, as a result, this image can be used anywhere, on any server. True, he called it a production server, but in fact, it's our development server, but it's not critical, actually, what it's called. Cursor cannot fill in some files due to security policies, but it certainly looks for workarounds and so on. `.dockerignore`, `.gitignore` files. For example, it cannot create `.env.example` either. Let's help it. Well, here's a complex moment. Iteration D1 is also completed, that is, all necessary configuration files have been created with a little help from me, so that it can be launched using Docker and Docker Compose tools. And then it reported, did a report, checked everything, recorded it, and accordingly, suggests further testing. So, in general, this is a fork. By and large, the most correct, competent, and reliable option, which I recommend to everyone, is to perform and test according to these instructions, according to the reports on the results of the iterations, and if something doesn't work, fix it, consult, and so on. But an alternative option, much faster, and which we will use in today's task, is to ask the agent. It has access to the console, a lot of tools, to do all this, check independently, look at the results, fix errors. And, well, yes, we will probably omit some details that are not essential for the essence of this video, but at the same time significantly speed up the process of going through this path. We won't need to manually copy, fix every snag, delay, error, typo, and this will be a significant acceleration, because in the creation of the server, in its configuration, there can be many, many pitfalls. Therefore, let's ask it in this case: perform all checks independently. That is, launch, build the image, launch it locally, check in the browser that everything works. So, Cursor has a browser that can be used very conveniently, without even leaving. And, in general, to some extent, you can even follow what it does, if you really want to. That is, we can open the terminal that it will use, and, accordingly, watch, analyze the process, that is, see errors if they arise, see how the agent fixes them, how it analyzes logs, how it analyzes the results of certain operations, and what decisions it makes, how to fix something. In principle, you can intervene in this process if necessary and somehow correct or guide it. So, the results of the zero and first iterations are completed. We helped Cursor a little with creating files for storing environment variables that are needed for launching with Docker Compose. It had some errors during debugging and image building. It first used the console utility incorrectly, and then it launched these commands from the wrong directory, but in general, it figured everything out successfully, overcame it, created all the necessary reports, plans, linked them to our roadmap, and we can proceed to the next iteration: automated builds, it happily created all the artifacts, reports about it. And most importantly, it independently checked the result of launching using Docker and Docker Compose utilities. That is, it opened a browser, took a screenshot, and even made a small change in the source code to check that it works locally. Hot reload, for development mode. And we see that in two iterations, we have filled 70% of the context out of 200,000 tokens for Bandisanet 4.5. And let's move on to the next iteration. We create a new agent and in the usual way say: "Perform planning for the next iteration." So, in principle, you can even say "next." We switch to plan mode and wait for the agent to gather the necessary context. By the way, it often reasons in English, as we see. The documents created by the previous agent are very useful, both from the perspective of the plan and from the perspective of the iteration results. That is, it can see what has been done, ask the necessary questions that affect the planning of implementation. In this case, since we need to configure the CI/CD part for building, it asks: "What branches will we build?" In principle, we can build both the main and develop branches. Why not? We only have the main branch for now. Is our access to the container registry configured? We need to check. I'm not sure, I don't know. What is the composition of checks? We already talked about MVP and minimal checks, but in general, no one prevents us from using all the necessary additional checks from all points of view of security, code quality, everything we want, once our pipeline is debugged in its minimal configuration. Should the built image be tested before publishing? No, successful build is enough, yes. We will check later. In principle, the most important thing for us now is that we can see that when changes are sent to the repository, a pipeline is launched that will perform small checks, run linters, package everything into Docker, and send it to a public registry so that these images can be used anywhere. While it is planning, it is visible here that in order to also effectively and quickly see how the build pipeline process is going, it fixes the use of console utilities in the plan. GitHub has a GitHub CLI tool that allows you to see if the build has started, how it went, view logs, what the problem is. So, in general, it helps the agent perform various operations using the console that allow debugging and fully completing the task. Let's see what it has planned. Sprint goal: automate building, that is, build a Docker image and publish it to the GitHub container registry. So, it gathers context, fixes the target state. And the task is, in fact, we need to create a configuration for GitHub Actions. As we see, this is another YAML file syntax, which needs to be understood. Minimal linters for branches. We tag. Yes, good. Update documentation. Good. Some reasoning about why we chose this stack. Well, and it already anticipates possible problems. Let's save this plan, as always, and proceed to implementation. We have completed iteration D2, created the necessary workflows, and Cursor marked all tasks as completed, although in fact it did not check everything independently. I sent it to check using the GitHub CLI tool. And it went to see what's happening. We, in turn, can see in the browser, in the repository, a CI/CD pipeline has appeared, which, as we see, failed the first time. So, apparently, some linters did not pass. And the option of using a console utility to fix such errors is very useful, so that, for example, in this case, if we were checking everything ourselves, we would have to copy the error from here, pass it to the agent, it would fix it, and everything would start anew. So, now we can only observe this. and watch how it fixes these errors and brings our basic pipeline to a state of successful completion and image building. We see that the build result, after two errors, is finally successful. The linter passed, the build passed, and the publication to the container registry. The images themselves can be seen in the list of tags. So, here is our package LM start published a minute ago, a Docker image. And we can see that it has two tags. The main branch, because we built from the main branch. This iteration can be considered complete. All statuses have been set and marked. What arose during the process? What is worth noting? The workflow files for GitHub Actions are located in the .github directory. Cursor also has problems editing them, so I helped it make changes to these files. And it also periodically has problems accessing console logs. Therefore, in this case, I also had to help it a little with this manual work, which I really wanted to avoid, because it couldn't work properly with the console, read it. But these are, in general, temporary difficulties. And as a rule, of course, this does not happen in most cases. This is some kind of general effect. What have we achieved at the current moment? We have gone through approximately half of the path. And let's briefly recap. In the first iterations, we delved into the project, created an infrastructure document that describes the current state, how the application is deployed locally and its target state. Then we created a Dockerfile, a docker-compose file, so that we can run our application in any environment, on a remote server, in the cloud, anywhere. We tested all this, resolved some problems, wrote a report about it, and finally achieved that our Docker image is built and published on the GitHub container registry platform, so that the image itself is available in the cloud to be downloaded and run on a remote server. Half of the path is completed, and we will cover the next half in part two of this video. I bid you farewell and suggest subscribing to our Telegram channel if you haven't already. We publish more useful and interesting information and materials there. And this topic of infrastructure, DevOps, and so on is, in essence, part of a larger program. which you can familiarize yourself with on the LSTART website. Push-driven development, which includes modules related to the full lifecycle of application creation, including system analysis, development, testing, working with legacy to some extent. We have touched upon this a little. basic and advanced topics related to DevOps, and of course, front-end development and even approaches to industrial application operation. And this is one of the three programs included in the comprehensive combo offer for 2026, available with a very good discount. That's all from me. Thank you all. Goodbye everyone.