Open theowenyoung opened 2 years ago
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:
apt
moduleYou 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
).
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.
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.
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.
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?