P5vc / fetch-apply

Transparent Server Configuration and Management
MIT License
17 stars 3 forks source link

How to upgrade software? #8

Open theowenyoung opened 2 years ago

theowenyoung commented 2 years ago

thanks for your great tool, I like it very much and I even submitted it to HN news!

For example, If I want upgrade shadowsocks, What should I do?

another question is that how to change config and restart the service? Cause doc said that apply will run every 24h, but what happened if I have no change?

P5vc commented 1 year ago

Thank you so much for your kind words! I really appreciate you trying out Fetch Apply and sharing it with others!

To answer your first question:

To upgrade software, you have a lot of different options. Here are a few common options I can think of off the top of my head:

  1. Create an apt module

You could create a module for your package manager, and have the apply file look something like:

apt-get update
apt-get upgrade -y
apt-get autoremove -y

This would automatically keep your system up-to-date with the latest versions of installed software.

For those looking for more fine-grained (and less potentially-disastrous) control, the apply file can be easily modified to only install security updates (or you could use unattended-upgrades and create a module for that) or to only install specific versions of software (the information for which could be placed within a configuration file, the variables file, or even right within the apply file, like so: apt install nftables:amd64=1.0.2-1ubuntu3).

  1. Overwrite an existing configuration file with new version information

A lot of people working in server environments already use other systems to handle software version control. One common example is docker. You could store your docker configuration (such as a docker compose file) within a docker module, so that whenever you update the configuration within your operations repository to bump your software to a new version, that gets reflected on your servers.

  1. Include the desired binaries in your operations repository

Another method would be to simply include the software binaries within your operations repository, and then install it within apply via a command similar to dpkg -i softwarev17.deb. This would probably only be the best solution if you needed to distribute custom software not available via external means.

To answer your second question:

You have a few options when it comes to restarting a service after a configuration change. The first option would be to just have the service automatically restarted once every Fetch Apply interval regardless of whether or not the configuration has been changed. Understanding that this is likely not a desired behavior in production environments, you could add logic to your apply file to automatically check for changes, and only restart the service when a change to the configuration is detected. For a good example of this, see the apply file in the docker module linked above. Finally, and perhaps the best choice for your use case, is that you can set modules to only run when they've been changed. You can do this by setting the fa_var_EXECUTE_ON_CHANGE and fa_var_EXECUTE_IF_MODIFIED values equal to true within the Fetch Apply configuration file. For more information about this final option, I highly recommend reading the last paragraph of the modules section in the Fetch Apply documentation.

P.S. I just want to quickly apologize for the extremely delayed replies to your comments. I've had a busy few months between moving all of our code over to Gitea, rewriting a lot of Priveasy's backend, and life stuff. I'll be sure to answer more quickly to any follow up questions you may have, and will leave this issue open for a bit before closing it, to give you a chance to respond.