So, there is all that stuff outside there, huhn? Containers, Continuous Integration, Git Deployment, Pipes etc. And they are awesome, in fact.
But sometimes we have a legacy project in hand, some old stuff or huge infrastructure monoliths that are simply really risky to refactoring.
Start a deployment strategy on those kind of projects can become a real nightmare. I commonly see people configuring environments from scratch, then using FTP clients as FileZilla, or terminal commands like rsync and scp repeatedly to keep the project up to date.
Thinking in structures like that i wrote a tiny really simple deployer using shell script and rsync. Of course, the main feature here is sync files between your local project and the server. You can add multiple hosts, and can achieve certain level of automation, but this is not comparable (of course) with any of the real deployment technologies that we have today. In fact, the name "Deployer" here is more
illustrative and generated by what it tries to remedy than by what it really does.
No more bla bla bla, lets configure it:
You will need:
A *Unix local system with rsync and git installed.
A *Unix server with Rsync and SSH connection enabled.
Most of this requirements are just a default configuration for any *Unix system. Now, follow this steps:
Clone or download the project on github:
https://github.com/felippe-regazio/sh-simple-deployerCopy the
deploy.shfile and thedeployfolder to your project root.Open the file
deploy/_hosts.sh, you will see 2 arrays with some fake information. Each array is a valid deployer host, it tells rsync which connection and path to use when syncing. You can add how many as you want in order to deploy to multiple targets for example. Delete the "another" array, and let only the "default". Configure it like that:
declare -a default=(
root@127.0.0.0
/path/to/project/root/on/server
https://yourprojecturl.com
)
On the 1st line, the one with root@127.0.0.0, you add your ssh connection following the pattern user@host. If you need to pass a different port, use it like that user@host:port.
On the 2nd line you must add the absolute path to your project ON THE SERVER. To discover your project absolute path, access your server using ssh, navigate to your project root folder, and type pwd. Dont use filezilla or GUI clients as reference to find out the root path.
On the 3th line you must add the project IP or URL. The deployer wont use it, but maybe you will need it to extend functionalities, or to remind you about where this project lives.
Now open the
deploy/directories.txtfile, and add the paths or files that you want to upload, they must be relative to your project root and separated by a blank line. The default directory to sync is ".", or: the entire root folder.Now open the
deploy/ignore.txtand add the paths or files in the same way you did with the directories.txt. This paths, rules or files will be ignored by rsync.Now open the
deploy/remind.txtand add some message. This message will be showed every time you run the script. This step is optional.
Now you are ready to go. Give the deploy.sh file permission to be executed. Open a terminal on your project root and run:
./deploy.sh
You could run it using sh deploy.sh, but as pointed out by @tonypelliccio in the comments:
From a systems perspective you don't need to launch a new shell by using
sh. Instead ./scriptname.sh whilst in the same directory will work too. And if you have to be root sudo su - will work just as well.
When you run it for the first time, rsync will sync your local project with the server one. Now, when you modify something on your project, just run de deployer and it will sync only the modified files, based on your configuration. A log will be saved on ./deploy/logs.
You can add new entries on _hosts.sh and call them as a parameter. For example, if we had configured the "another" array on _hosts.sh, we could use it like that:
./deploy.sh another
At the end, its just the good and old rsync. But this script brings automation and standardization to the deployment process on old systems.
See the README.md on github to know more about, or feel free to message me. And again: this is not an ideal modern solution, its a script to solve a problem that you may have with legacy infra structures, old projects, poor hosts, etc. Dont know your situation, but may this could be useful for you, and thats the point. Thank you for your interest, thats all folks.
Top comments (7)
2 hours of learning Ansible & I had the same kind of thing working on a legacy app.
This even worked on a shared host with no root access.
Might make more sense to spend effort on a tool that can scale with you.
Ansible needs python at remote site. Sure many distros already have python in default installation. But if python is not available (legacy, old, no-auth?) or you prefer shell scripting, than sh-simple-deployer and cdist are good candidates.
I prefer Ansible but it's not a 2 h tool. Only if I want to print Hello World. Ansible manual is vast and I need a lot of the modules and other concepts (roles, yaml, Jinja, etc) to really say "Wow, this is better/faster than scripting". Maybe a week. :-)
Good point about the python dependency! If you don't have that, it won't work.
But I wasn't exaggerating about the 2 hours to get a useful versioned deploy from Git working. I used the Deploy Helper module as a starting point:
docs.ansible.com/ansible/latest/mo...
I didn't knew Ansible. Seems really simple and powerful, indeed. I'll try to use it, for sure.
Always good to see someone else using this. I actually have something similar that I did a week or so ago that I also wrote about. I clone the repo and then used rsync to my site directory. Great for older hosting models
From a systems perspective you don't wan to launch a new shell by using sh. Instead ./scriptname.sh whilst in the same directory will work too. And if you have to be root sudo su - will work just as well.
Nice point, Tony. You're right. I updated the post with your information.