This approach to running igweb works for the time being, but what if the server is rebooted? We need a means for the igweb program to be more resilient. It has to be able to start up again once the server comes back online, and nohup is not the suitable choice to accomplish this goal.
What we really need is a way to turn igweb into a system service. We can do exactly that with sysytemd, an init system, that is available with Ubuntu 16.04 LTS. With systemd, we can initialize, manage, and track system services. It can be used while the system starts up or while it is running.
In order to turn igweb into a service, we create a unit file called igweb.service and place it in the /etc/systemd/system directory. Here's the contents of the unit file:
[Unit]
Description=IGWEB
[Service]
USER=igweb
GROUP=igweb
Environment=IGWEB_APP_ROOT=/home/igweb/igweb
Environment=IGWEB_MODE=production
WorkingDirectory=/home/igweb/igweb
ExecStart=/home/igweb/igweb/igweb
Restart=always
[Install]
WantedBy=multi-user.target
Specifying the file extension of .service indicates that we are creating a service unit that describes how to manage an application on the server. This includes performing actions such as starting or stopping the service, and if the service should be started on system startup.
The unit file is organized into multiple sections, where the start of each section is denoted with a pair of square brackets [ and ] with the name of the section enclosed between the brackets.
The first section is the [Unit] section. This is used to define the metadata for the unit and how this unit relates to other units. Inside the [Unit] section we have specified a value for the Description, which is used to describe the name of the unit. For example, we run the following command:
$ systemctl status nginx
When we run it, the description we see for nginx is the description that was specified using the Description directive.
The [Service] section is used to specify the configuration of the service. The USER and GROUP directive specify what user and group the command should run as. We use the Environment directive to set the $IGWEB_APP_ROOT environment variable, and we use it again to set the $IGWEB_MODE environment variable.
The WorkingDirectory directive sets the working directory for the executed command. The ExecStart directive specifies the full path to the command that is to be executed; in this case, we have provided the full path to the igweb executable file.
The Restart directive is used to specify the circumstances that systemd will attempt to restart the service. By providing a value of always, we have specified that the service should always be running, and if for some reason it stops, it should be started up again.
The last section we've defined is the [Install] section. This section allows us to specify the behavior of a unit when it is enabled or disabled.
The WantedBy directive that is declared in this section tells systemd how a unit should be enabled, that is, at what system runlevel should the service run in when it is enabled. By setting the value for this directive to multi-user.target, we specify that this service has a system runlevel of 3 (multi-user mode).
Anytime we introduce a new systemd service script or make changes to an existing one, we must reload the systemd daemon. We can do so by issuing the following command:
$ systemctl daemon-reload
We can specify, that we want the igweb service to startup automatically on boot by issuing the following command:
$ systemctl enable igweb
If we don't want the igweb service to startup automatically on boot, we can issue the following command:
$ systemctl disable igweb
We can start the igweb service by issuing the following command:
$ systemctl start igweb
We can stop the igweb service by issuing the following command:
$ systemctl stop igweb
We have now completed the standalone deployment of igweb. It's amazing that we can run the igweb application without having to install Go on the target production system.
However, this approach is rather opaque to the DevOps crew that is tasked to keep IGWEB up and running. What I mean by opaque is that there's not much a DevOps engineer can ascertain by examining a static binary executable file and a bunch of static assets.
What we need is a more streamlined way to deploy IGWEB, a procedure that shows us all of the dependencies needed to launch an igweb instance from scratch. To achieve this goal, we need to dockerize IGWEB.