Automatic production deployment for a Node.js app on RHEL 7?

Question

I am looking for some way to have a maximally simple(no Jenkins or anything like that) automatic production deployment for a Node.js application on a RHEL 7 system. The caveat is:

At the organization where I work, we have a very restricted IT environment, that prohibits access to any ports other than 80 and 443 from anywhere, and only allows 22(ssh) from within some rooms in the office building. To upload files a tunnel is needed which is slow and is also not available in some places. And SSHing to the server to run commands is a huge pain for multiple reasons too. And no - I can't do anything about it.

In light of this the 'trigger' has to initiate from the server itself. The server should somehow decide to pull changes from a certain branch, ideally when a special commit message is seen, and then run some pre-configured scripts to deploy it. The tests at that point are already all done, the app has been at the staging and beta server and so the only things needed is to copy directory, update dependencies, compile frontend assets and restart the systemd service that runs the app (all that I already have in the script that Jenkins executes on staging server after running all the tests).

I would imagine the sever would need to poll, e.g. every minute for changes to the repo, and yes, that can be done with a cron job, but I am not sure how, and if there are some tools that make it easier, without creating a resource hog that Jenkins does (which is what we use on our staging and beta servers), then I would like to know about it (I wasn't able to find anything yet, maybe I am not using the right search terms).

Any advice?

Update-1: I am aware of Puppet and Chef, but if at all possible, would prefer avoiding proprietary solutions if possible for now because a - our project is not big enough yet for the decision makers to put real resources in it, and b - even if those have free versions available, they are most likely cumbersome and do a lot of things, whereas we want as simple a solution as possible, because that solution might be part of the package if we sell the project elsewhere (naturally we don't want to also "re-sell" Puppet or Chef). Some kind of Open Source solution, or simply a method of doing it using simple shell scripts would be best.

Update-2: As Tensibai mentioned - Chef is open source and fits our purposes, but it's a huge platform with a lot of features, which is precisely what we are trying not to use in production server (otherwise we'd just use Jenkins like we do in staging).

Answer 1

Ok, let's assume you'll pull the latest version of branch prod from a git repo, here's what it would take with chef on a basic illustrative purpose:

git "/opt/my_application" do
  source "https://<git_host>/<you_repo_url>/<repo.git>"
  revision "production"
  action :sync
  notifies :run,"execute[app_config]"
end

execute "app_config" do
  command "npm install"
  cwd "/opt/my_application"
  action :nothing
end

For more advanced use cases you can have a look at the poise application cookbooks, it includes a javascript plugin for node.js application.

chef is fully open source, either client or server side (out of the fancy UI) and on all OSes including windows.

Answer 2

All this time after I think I am finally able to answer this question. The solution is Ansible - just like @James Shewey mentioned. It's agentless and quite light python framework, that can be made to work through jump hosts and perform automated tasks through SSH. This means it requires no server setup or manual operations of any kind from our customer to deploy the application.

Without anything else it's a one-command deployment solution, which is almost as good as a fully automated one and it has the benefit of being readable and usable by people not familiar with code.

Puppet offers similar functionality, but it has an agent which means if packaged with the application, it does require manual server setup from the customer. Also Puppet is ruby and I try to stay clear of that thing as much as possible. I've learned the hard way just how bad ruby is for anything other than prototyping.