1

I am running 4-5 webservers for a website right now when updates come to the website I login to the FTP manager for each server an update manually which really gets tiresome if there is a bunch of updates in a week. Is there a better way to do this? I am sure there is but not really sure what I am looking for.

I thought of a share bulk storage but my servers don't share the same network so I am not sure if that will work maybe a pool storage. Thought of maybe a CDN but then again doesn't seem like that's the right answer either. I tried at one point doing a scheduled github pull every day but again if there are abunch of updates it'll have to be triggered on each server.

So here I am hat in hand seeking help.

I am running Ubuntu with Apache.

Thanks

2
  • There are lots of solution to automate a fleet of servers: Chef, Ansible, Salt, etc. It is not extra clear if you are more towards deployment (so a single source pushes content to all servers), or more like shared space where a file created by one server is visible to others, or a combination of those. Commented Jul 21, 2022 at 6:43
  • What I’m looking to do to keep it somewhat simple is one source pushes content to all the servers.
    – Jigsaw
    Commented Jul 21, 2022 at 10:55

1 Answer 1

2

There are lots of solutions.

One is to script your FTP to push it to all the servers - this should not be difficult, and indeed if you are logging in manually to each server you are doing it wrong - this kind of thing lends itself to scripting.

You may be better off ditching FTP altogether (its slow, insecure, and a horrible protocol), and replacing it with rsync [ over ssh ]. To do this you would set up ssh to be able to reach each box using a public private key - so no password required, then configure rsync to copy across any changes). This is probably the "correct" next step to take.

Another way might be to use Nextcloud (or Dropbox or Googledrive or what have you), push the data up to the the cloud, and configure each server to sync data from that source.

More complex - Yet another way might be to re-engineer your storage backend. There are a lot of ways of doing this, depending on your needs. A single common source mounted on all the systems is an easy way to do it [ eg using NFS ], but suffers a single point of failure and possibly speed issues depending on latency between servers. Using something like gluster is more complex but would get rid of the single point of failure.

There are, of-course other ways to do this, like puppet, chef, ansible as mentioned by @PatrickMevzek - but these are more geared to scaled out deployments and working towards deployment automation - very valuable tools which can be used for the job, but not exactly what you are asking for. Similar for Kubernetes and Docker containers.

6
  • Thank you for your response! I was told resync has speed issues…is this true or is this just one of those things people say that don’t have enough info and context on how things work. I really want to get away from FTP. The other options seem a bit “robust” for my prototype.
    – Jigsaw
    Commented Jul 22, 2022 at 1:16
  • 1
    That rsync has speed issues is absolutely false. It you have a few very large files which are updated regularly they can put a bit of load on the server and client to calculate diffs between the version and only send those (this can be mitigated), but for 99.9% of cases it is extremely efficient - way, way more-so then FTP. It is also a very well established tool that is heavily used by experts and as a basis of many backup tools and systems. (Generally the pattern is something like Frontend/script -> RSNAPSHOT -> RSYNC -> SSH - although its not that hard to get working).
    – davidgo
    Commented Jul 22, 2022 at 5:08
  • 1
    I just looked it up, RSYNC was originally released in 1996 with - and is still very, very widely used. That must tell you its pretty robust and good. As far as speed issues, I found the following thesis from the author - rsync.samba.org/~tridge/phd_thesis.pdf which goes way over my head, but should speak to your speed issues. (And, of-course, I use it on large data sets to back up multiple web servers and other stuff, so I have experience with it as well)
    – davidgo
    Commented Jul 22, 2022 at 5:14
  • Thanks! I'll be going with this since it seems to be the far easiest method to get working in a timely manor.
    – Jigsaw
    Commented Jul 22, 2022 at 21:16
  • "I was told resync has speed issues…" without context it is hard to tell, but it is certainly true, in some cases ,and certainly not true in others. So kind of not helping. rsync aim is to tranfer only the "differences" between two set of data. If you have very little changes, it is "fast" because almost nothing is exchanged. But these are all low level implementation details. You should first think of the design, specially the flows between servers and the origin (push vs pull) and then frequency and stuff like that. How you do it then, depends on all the above. Commented Jul 25, 2022 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.