In a previous article, I described how I migrated some websites from a bare metal server to a virtual machine running on the same server.
It’s actually three virtual machines. One is running the development, on the test and one the production environment. The three are basically identical in setup and installed software, but production has more resources assigned to it (2 processors instead of one, and more virtual disk space for data).
The next challenge was, how to automate the development process and avoid to having manually copy the files each time a update is performed.
There are several ways to do this, of course but they ideally all have something to do with using DevOps methodology.
I came up with this approach, which completely satisfies my requirements, and seems simple enough not to cause to much work to maintain.
The development environment exposes the web site files via a Samba share which can only be accessed from certain machines and edited by members of a specific development group.
The account that owns the files in the development environment has a certficate based, passwordless access to the test environment. The files are synced between development and test environment by using rsync as described here. This would require you to enter the password every time you want to publish, and to avoid this passwordless ssh access was enabled as described here.
To automate this process a shell script checks every 5s for a specific file in a specific directory and will publish only if it finds that file.
Once testing has been deemed successful, the same process has been configured on the test environment to publish to the production environment.
The script is a bit different, though. It first removes any files not needed in production and syncs the files to a staging environment. This means the files are on the server but are not live yet.
For the last step, a shell script on the production virtual machine checks all 5s for a file, and if it finds it stops the Webserver, removes any remaining files not needed in production, syncs the staging environment with the live environment, changes permission on all files and starts the web server again.
This is a very rudimentary DevOps environment established using basic tools available on every Linux box. Of course, you can establish much more advanced solutions, here is a list of some of them.
This minimal solution lacks real collaboration support and version control features. But in my case these would be overkill and mostly require too much time to maintain, so I stick with the basics for now.
It’s best to start simple and to grow later once you know your requirements better.