Original link: https://www.kawabangga.com/posts/5154
Now the company more or less uses some open source software, and I also deploy and maintain a lot of open source software in my work. This article will talk about some experience in maintaining these software. What I mainly want to talk about are those services that need to be deployed, such as Jenkins and Prometheus. Command-line tools, and libraries and such, are outside the scope of this discussion (but some lessons apply as well).
Technology Selection
If there are many solutions that can solve the problem, which one should you choose?
When selecting an open source software technology, the factors that can be referred to are:
word of mouth, acceptance. If there are more users of the software, then the probability of existing problems being exposed is greater, and there are more information on the Internet. There are fewer pits to step on.
time that has existed. As above, tried and tested software is relatively reliable.
APIs and openness. This point is easy to overlook. If there is API support, it will be much easier to integrate with other systems within the company. You can also do more customized functions. What format is used for storage? If it is an open standard, for example, VictoriaMetrics has a very convenient import and export for Prometheus, and then the migration will be much easier. Even if this software is not used in the future, it can be easily switched to other solutions.
Support for decision making is part knowledge and part information. The information comes primarily from the project documentation. The project’s issue page and community discussions are also worth referring to.
It is recommended to read the project documentation carefully, and you can get a lot of insights. I often struggle with not knowing if this tool provides some kind of solution to a problem when I am solving it. If you encounter a problem when going through the document, you can at least remember a certain keyword.
Reading documents seems to be quite time-consuming, but it actually saves time. It can at least deepen your knowledge of the software. (I found that what I spend the most time is doing things that are not suitable for it with a tool…)
Build from 0 to 1
New deployment of an open source software mainly needs to solve two problems.
The first question is how to deploy it to your own company’s infrastructure. Common deployment methods are:
- Install Docker directly on the machine, and start it with a single Docker command;
- Write ansible playbook deployment
- Use k8s (generally, there will be customization within the company)
Choosing the right deployment method for the right software is very important. Don’t underestimate the way of one-line command Docker deployment, which is very suitable for some software, such as Jenkins, its Java dependencies are difficult to deal with, and there are many system dependencies, but it is essentially a very independent single application, and the content of dependencies Stored in a single folder, this is ideal for deploying with Docker, where upgrades and reboots are one-liners. Although it is a manual operation, this method is almost the most efficient.
WordPress is a special example. This software has some magical functions, such as clicking in the background, it can update its own code, upgrade plug-in code, and even upgrade itself. So I put the entire WordPress operating environment in a Git to track code changes.
The second problem is to solve dependencies. Software generally has dependencies on other services, the most common being storage. This part can also be considered when selecting models. Generally, the less dependencies the better. For example, Jenkins, this thing is amazing, basically only depends on a $HOME_DIR
, give it a folder, and nothing else is needed, especially friendly to upgrades and backups. Other dependencies such as how to access the gateway, how to log in the user, how to maintain the back-end storage, and so on.
custom function
The official version cannot meet everyone’s needs, and we often need to customize the software.
It should be emphasized that it is best to use some plug-in formats supported by the software, such as Jenkins, CoreDNS, K8s, etc., all support plug-ins. There are also some like Prometheus, which can do customized functions by writing external services .
The next best thing to do is to directly fork and modify the code of the software, so that it will be separated from the main body, and it will be difficult to follow up the official upgrade later. (However, if you can directly submit PR to the official, it is a good way)
upgrade
This is actually a very important issue, which is to follow up the official update.
Why is it important? I have seen a lot of stories about installing a software version and never updating it again, because it runs well and no one wants to touch it (most software is like this, you can find it through its version When was it introduced to the company, lol). Or because the fork modified the code, the upgrade did not work. Then starting from this version, you may have to solve the existing problems by yourself. Maybe the official has released a fix or optimization, but because there is no upgrade, there is no way to enjoy it. Not even you know about the update.
Therefore, it is recommended to subscribe to the official release records, and generally there will be an RSS subscription method.
To read the changelog for each release.
It is best not to perform cross-version upgrades, because some incompatible modifications may cause problems (still refer to the official upgrade guidelines).
You can also subscribe to the news updates of some core developers to see what problems everyone is concerned about and what problems to solve.
support
Finally, in the process of using the software, you will definitely encounter various problems. If there is no current solution, but many people have the same problem, try to solve it yourself. (Give back to the community!)
Reporting problems is also a kind of support to some extent. But to make the problem clear, submit a case that can emerge.
If you don’t have the energy, then donating some money is also a great support.
The post Experiences Deploying and Maintaining Open Source Software first appeared on Kawabangar! .
related articles:
This article is transferred from: https://www.kawabangga.com/posts/5154
This site is only for collection, and the copyright belongs to the original author.