Création d'un service

Choisir un nom de service

A service name must be unique in its application code namespace.

A best practice is to allocate unique service names in the corporate namespace, even if it is not mandatory.

Create the service

The following actions only modify files in <OSVCETC>. No operating system configuration file is modified, so they are safe to experiment with.

From scratch, non interactive

Create a service with minimal configuration. No resources are described.

sudo svcmgr -s <svcname> create

From scratch, interactive

sudo svcmgr -s <svcname> create -i

From an existing local configuration file

Experienced users may find it easier to start from a copy of the conf file of an existing similar service. The following information describes the steps needed to create a service manually.

sudo svcmgr -s <svcname> create --config <path to config file>

From a collector's service

sudo svcmgr -s <svcname> pull

Service configuration files

Service configuration files are in <OSVCETC>. They are created automatically by the above svcmgr commands. Each service must have these three files present to be fully functional. Services using the internet shared collector must be named using the domainname as a suffix to avoid naming conflicts:

<OSVCETC>/<svcname> -> /usr/bin/svcmgr
<OSVCETC>/<svcname>.conf
<OSVCETC>/<svcname>.d -> /<svcname>/etc/init.d

or:

<OSVCETC>/<svcname> -> /usr/bin/svcmgr
<OSVCETC>/<svcname>.conf
<OSVCETC>/<svcname>.d -> <svcname>.dir
<OSVCETC>/<svcname>.dir

Rôle des fichiers de configuration

<OSVCETC>/<svcname> -> /usr/bin/svcmgr

This symbolic link is meant to be used as a shortcut to pass commands to a specific service. Like /etc/opensvc/unxdevweb01.mydomain.com start for example

<OSVCETC>/<svcname>.conf

This is the configuration file proper, including service description and resource definitions. Fully commented section templates are available on each node at <OSVCDOC> and online here.

<OSVCETC>/<svcname>.d -> <svcname>.dir

Ce lien symbolique pointe le répertoire qui contient les lanceurs applicatifs. Le service n'est pas utilisable tant que ce lien n'existe pas. Le répertoire pointé devrait, quand c'est possible, être contenu par un système de fichier dédié au service. Les lanceurs sont au format SysV : [SK][0-9]*appname. S pour les lanceurs, K pour les stopeurs, le nombre pour l'ordonnancement. Les lanceurs et les stopeurs peuvent être des liens symboliques vers le même script. Les lanceurs se voient passer le paramètre 'start' et les stopeurs 'stop'.

<OSVCETC>/<svcname>.dir

This optional directory can be used to store locally the startup scripts. As such, it can be linked from <OSVCETC>/<svcname>.d. OpenSVC synchronize this directory to nodes and drpnodes as part of the sync#i0 internal sync resource. If you placed your startup script on a shared volume, this .dir is not needed but you will still have to create a sync resource to send them to the drpnodes.

Customize the service conf file

At that point you should describe your service's ip addresses, filesystems, disk groups, file synchronizations, app launchers, ... The <OSVCDOC> templates present you with all possible configurations available. The svcmgr create -s newsvc -i command prompts you about all possible configurations, explains the role of each keyword, proposes candidate values and defaults, and validate input sanity. This same command in non-interactive mode can be used to provision service. In this mode, the resources are passed as json-serialized keyword-value dictionaries.

Interactive

sudo svcmgr -s <svcname> edit config

The configuration file syntax is checked upon editor exit. The new configuration is installed if the syntax is found correct, or save in a temporary location if not. In this later case, two options are possible:

  • Discard the erroneous configuration:

    sudo svcmgr -s <svcname> edit config --discard
    
  • Re-edit the erroneous configuration:

    sudo svcmgr -s <svcname> edit config --recover
    

Non-interactive resource addition

sudo svcmgr -s <svcname> update --resource '{"rtype": "fs", "foo": "bar"}'

The resource identifier (rid) must not be specified. The resource type must be specified (rtype). A free rid will be allocated.

Non-interactive resource modification

sudo svcmgr -s <svcname> update --resource '{"rid": "fs#1", "foo": "bar"}'

The resource identifier must be specified.

Non-interactive resource deletion

sudo svcmgr -s <svcname> delete --rid fs#1

Test

You should now be able to run succesfully:

sudo svcmgr -s <svcname> print config
sudo svcmgr -s <svcname> print status
sudo svcmgr -s <svcname> start
sudo svcmgr -s <svcname> stop

Service deletion

sudo svcmgr -s <svcname> delete

Best practice

Attribuer un compte générique et une adresse internet

Nous recommandons d'allouer à chaque service une adresse internet privée pour permettre la bascule des services entre noeuds.

We recommend to allocate service-dedicated generic accounts (one is ok most of the time) for better control on privileges. All service files should be owned by these accounts. The application launchers are executed by the agent using impersonnification as the launcher file owner. The generic account home directory should be a link redirecting to a subdirectory of one of the service-dedicated filesystems (the one hosting data is a good candidate).

Créer un squelette d'arborescence pour le service

Donner à chaque service des systèmes de fichiers dédiés. Idéalement un pour les données, un pour les outils (mysql, apache, ...) et un pour les lanceurs et éventuellement l'instance de système d'exploitation du container. Nous recommandons l'organisation suivante :

/gieprdweb01

Lanceurs applicatifs dans etc/init.d/

/gieprdweb01/tools

Installation privée des outils. Les outils doivent écouter sur l'adresse privée du service pour éviter les conflicts entre instances du même outil mais de services différents tournant sur le même noeud.

/gieprdweb01/data

Données de l'application

If the applications are not containerized, prefer per-service private tools installations to distribution packages installations. This choice provides better system/service insulation, more reliable relocation and safer operating system upgrades. This also makes the service installation harder.