Experience with Revel Framework application deployment

About Revel

Revel is a highly productive Go language web framework, and the prototype is made up of Java play! Framework evolved. In fact, in addition to Revel, the Go Language web framework has a lot of, here is no longer enumerated. As far as the Revel framework itself is concerned, it has and provides some very good features, such as Code thermal compilation (hot-code Reload) that supports Run-time, and provides many components including: routing, parametric parsing, validation, Session/flash, templates, caching, scheduling tasks, testing, Internationalization and other functions.

Although the current version of Revel is still a v0.12.0 version (2015-03-25–daffodil release), the framework has been applied to a production environment and has a good concurrency performance. As a result, Revel has also become the preferred framework for our most recent project.

Deployment of Revel applications

After introducing the Revel framework, get to the point and share some of the ways in which revel applications are deployed to the production environment.

Because of the static nature of go, all programs need to be compiled before they can be run. This also means that compiling a good application directly becomes an executable file that, at run time, does not depend on any runtime. Therefore, the deployment of Revel applications is also broadly divided into two ways:

Compiling a publication locally

Running on server-side compilation
Each has its own advantages, the deployment of a slightly different way, you can choose according to the actual needs.

Compile the publication on the client

In this way, the client compiles the code directly to the executable program, and then deploys the Revel application upload to the server. The Revel framework itself provides a command to compile the applications and related Web resource files that ultimately need to be published directly on the client side for deployment.

For example, use the command Revel build to output a compiled application to the current deploy directory:

Revel build Import/path/to/app./deploy

The next thing to do is to publish the deploy directory to the server, you can use the SCP command, or you can use rsync.

In addition, Revel also provides a more convenient command:

Revel Package Import/path/to/app

After running, Revel will compile your application and package it directly into app.tar.gz, and upload it to the server to extract and deploy it.

The benefit of using local compilation is that the server does not need to install and configure the Go environment, nor does it need to install the Revel framework, where the server runs a compiled application without deploying the source code to the server.

To compile the publication on the client side, you need to be aware of the problem of cross compilation. If the client's operating system and CPU architecture are inconsistent with the server, you need to provide the target machine's environment variable settings when compiling the publication.

For example, the client machine is the WINDOWS,CPU is 32 bits, while the server-side machine is a Linux system, the CPU is 64 bits, you need to compile packaging when the following environment variables are provided:

Goos=linux GOARCH=AMD64 Revel Package Import/path/to/app

Running on server-side compilation

With this deployment, you avoid the inconvenience of cross compilation, but you need to install the GO environment and Revel Framework on the server side. By using Git, the client-submitted code can get all the changes directly on the server via Git pull and then compile and run directly on the server side.

Because git itself is an incremental get code churn, it can save a lot of time compared to the client-compiled upload application.

And the combination of upstart

Once the deployment is operational, the application itself is also monitored in the production environment. There are a number of related tools such as Supervisor or forever. But these two tools do not start automatically when the server restarts unexpectedly, and cannot continue to guard our process. So you have to figure out how to automatically start supervisor or forever after the machine restarts.

Upstart, by contrast, is a good choice. Upstart is an event-based daemon that replaces/sbin/init, which can start/close tasks and service processes when the system starts/shutdown, and monitor these tasks and service processes during the system run phase. It's a necessary tool for home travel ...

Use upstart to create a configuration file for our application and save it to/etc/init/my-revel.conf. The contents of the configuration file are as follows:

Description "My Revel Website"

Start on (Local-filesystems and net-device-up Iface!=lo)

Kill Signal TERM
Kill Timeout 60

Respawn #自动重启
Respawn Limit 5 #尝试10次, interval 5 seconds

Setgid Deployuser
Setuid Deployuser

Script
/var/www/current/run.sh
End Script

The start on parameter in the configuration specifies that upstart will run our program after the machine is started and the network connection is normal. The respawn parameter indicates that the process is automatically restarted and is tried 10 times in 5 seconds. The script section in the configuration file points to the run.sh in the Revel application.

Finally, start the daemon by command:

sudo start my-revel

In this way, the Revel has become a background process running, and will automatically restart after the machine unexpectedly reboot, after the program abnormal exit, will also be automatically started. You can kill the process directly with the KILL command, and discover that the new Revel process will be created and run immediately.