BeagleBoard/GSoC/Bonescript remote deployer
Bonescript zero-configuration and user-friendly remote deployer utility, to help manage remote boards scripts
Student: Francesco Guardiani
This project is currently just a proposal.
My pull request for example cross-compiling project: https://github.com/jadonk/gsoc-application/pull/77
School: Politecnico di Milano
Primary language Italian
Typical work hours 5PM-10PM CET
The languages I know:
- C++ (Moderate)
- Java (Good)
- Bits of JavaEE (in particular with JAX-WS)
- Android (Moderate)
- Python (Beginner)
About Bonescript Remote Deployer
I would have the pleasure to implement the idea described in this issue.
The main objective of this task is to create a user-friendly zero configuration remote deployer, simple to use as:
bonescript-remote-deploy -h [host] -p [ssh_port]
This command is intended to use with BeagleBone/BeagleBoard directly connected to network via one of its network interfaces (WiFi or Ethernet). This command will do this following steps:
- Instantiate SSH connection or with standard parameters (username root and no password) or with provided username and password (
--user [username] --pass [password]) or with a provided key (
- Upload project files in current directory to pre-defined directory in BeagleBone/BeagleBoard
- Configure a new systemd unit to run the bonescript project.
- Execute the systemd unit and print a hopeful “It Works” in client side
Creating a systemd unit will be useful to remotely manage the deployed instance of script via SSH tunnel. For this purpose, I will create a wrapper command for systemd remote interface:
bonescript-remote-manage [start|stop|kill|force-restart|enable|disable|log] -h [host] -p [ssh_port]
At the first run
bonescript-remote-deploy generates a configuration file, called
.env_bs_remote_deploy. This configuration file enables user to configure all the parameters for remote deploy like:
- Multi machine configuration
- Alias, host, port, username and password for every BeagleBone/BeagleBoard configured
- Script to run on BeagleBone/BeagleBoard before/after successful deploy
A script called
bonescript-remote-config will help the user to configure the
The usage of the configuration file can help the user to deploy on a batch of BeagleBone/BeagleBoard the same script, and with the
bonescript-remote-manage the user can watch status of script at the same time on all machines deployed. After the first usage (or after the manual creation of the configuration file via a command like
bonescript-remote-config generate-config -h [host] -p [port]) the user can use the deployer command without having to specify every time the host and port.
Also I will expose an API to do all those things inside scripts created by users
As seen before, the project is divided into three scripts ready to use for the final user:
All this scripts rely on one configuration file for project:
bonescript-remote-deploy allows the user to run the algorithm that uploads the project to remote machine/machines. This algorithm will rely on SSH tunnels to connect with remote machines. This choice allows the use of bonescript remote deployer without configure remote BeagleBone/BeagleBoard, reaching the most important objective of this project: the give to the final user a friendly and plug & play interface. The sample procedure of what this command will do is described here:
.env_bs_remote_deploy file exists, the command automatically calls
bonescript-remote-config generate-config with parameters provided by parameters
-h [host] and
Before copying project files to server, the command will generate a systemd unit that will be installed on remote machine and will save that in local project folder. If it already exists, no file will be created so user can modify the systemd unit automatically generated.
After generation procedure the command calls the algorithm that deploys script on remote machine. This will be a simple copy-paste procedure that copy entire project folder from user machine to BeagleBone/BeagleBoard. The functionality of file transfer will be achieved by SCP protocol.
The final step of
bonescript-remote-deploy is to copy the systemd unit to pre-defined folder and start the service.
bonescript-remote-manage is the command that enables user to manage his script deployed on remote BeagleBone/BeagleBoard. The reasons of choice to rely on systemd for remote software management are:
- Having a robust and affordable framework to manage locally and remotely the script
- Granting zero configurations : as for SSH, user doesn’t need to configure a “remote software manager”, because distros primarly used on BeagleBone/BeagleBoard (like Angstrom Distribution) already has systemd locally installed
With systemd remote control (or with SSH connection) the user can connect to one or all boards configured at the same time and start, stop, enable for start at boot and so on. Also systemd provides script logging and this functionality, combined with remote connection, can take advantage of enable the user to watch the status of his script as simple as
bonescript-remote-config will help user to manage the configuration file. It will expose functions as add machine, remove machine and generate the configuration file (like
.env_bs_remote_deploy configuration file will be a JSON file containing an array that contains boards informations . Other configuration parameters can be added later.
All this command will be implemented in Node.JS, using libraries with open-source license compatible with BoneScript project
1 May – 31 May: Join the Beagleboard community and design all technical aspects of the project with the help of mentor
1 June – 26 June: Create a first working prototype of bonescript-remote-deploy with file upload, generation of systemd and start of script (without configuration file)
26 June – 24 July: Create bonescript-remote-manage and test it
24 July – 10 August: Configure the previously defined commands to support configuration file and create bonescript-remote-config
10 August – 21 August: Complete the project test with multi boards deployment test and fix bugs
Experience and approach
I already work with these technologies, in particular I worked a lot with Node.JS (like described before). Moreover I have good knowledge of systemd (every project I coded uses the systemd as deamon manager) and SSH. My obsession is coding a project working in all its aspects and features, for this reason I test every module/functionality of my project before committing to repository. I love bringing into a project new features with the main objective of simplify the final user experience.
The main benefit for the community is the usage of a simple remote deployer that enables users to update entire networks of boards with one simple command. Also the remote management feature enables users to update the code when they don’t have physical access to the board. Some example are shown here:
- Update script of a sensor reader inside a sensor network
- Manage status of remote script and, in case of crash, remote reupload a working version of the script