Page Comparison

...

This article is not relevant for single server environments.

When is the install.sh executed?

The install.sh is run to install the projects on each application instance to complete either the deployment of a new release or the provisioning of a new instance. Since  Since the configuration of the necessary steps is to be done by the project, the install.sh must be part of the source code.

To install by install.sh include the following steps:

1. Configure the application with the appropriate endpoints of the environment

2. Installation of CRONs

3. Execute necessary PHP commands

The steps can be adapted as desired to the requirements of individual projects.

Background information

• The install.sh is run as www-data user.

   All

   All file operations are therefore executed in the context of the web server in order to avoid access problems.

• If certain commands stop the deployment, if they can not be successfully executed, this can be achieved with appending " || exit $?" to the command.

   If

   If this is not specified, the deployment or the provisioning continues even in the event of an unsuccessful command, making it much harder to debug.
  

• The execution of the install.sh always takes place in the root directory of the repository

Example

An example install.sh might look like this:

 #! /bin/bash
 # inject entpoints to local.xml
 sed "s#%DATABASE_USER%#${DATABASE_USER}#g;
      s#%DATABASE_NAME%#${DATABASE_NAME}#g;
      s#%DATABASE_PASSWORD%#${DATABASE_PASSWORD}#g;
      s#%DATABASE_HOST%#${DATABASE_HOST}#g;
      s#%REDIS_HOST%#${REDIS_HOST}#g;
      s#%REDIS_PORT%#${REDIS_PORT}#g;
      s#%ENV%#${ENV}#g;
      " local.xml.dist > local.xml || exit $?

 # install CRON if role "backend" is installed
 if [[ "${ROLE}" == "backend" ]]
 then
     # cron example
     echo "* * * * * cd /var/www/ && php cron.php > /dev/null 2>&1" >> project-crontab

     # cron example with custom logging
     echo "* * * * * date >> /var/log/application/cron.log && cd /var/www/ && php cron.php >> /var/log/application/cron.log 2>&1" >> project-crontab

     # cron example to register dynamic application log files stored in a dedicated log folder
     echo "* * * * * /usr/local/bin/check-log-registration /var/www/${ROLE}/logs/" >> project-crontab

     # cron example to run a command on only one instance per role
     echo "* * * * * /usr/local/bin/run-once-per-role.sh 'web' /var/www/web/public/bin/artisan cron:start" >> project-crontab

     crontab project-crontab || exit $?
     rm project-crontab
 fi

# register custom application log file
register-log -k "/var/www/${ROLE}/log_dir/custom_application.log"

See (Archived) Scripts Snippets for an explanation of the used scripts register-log, check-log-registration and run-once-per-role.sh.

Explanation of "Configuring the application with the appropriate endpoints of the environment"

By means of " sed ", placeholders are replaced with the values from the appropriate environment variable according to the schema% VARIABLE%. The  The result is written into the configuration file used. In  In the example, a template configuration file "local.xml.dist" is used to provide the placeholders. The  The environment variables for each project can be taken by executing "sudo get-application-env" on the respective application instance.

Explanation of "Installing CRONs"

The example shows the possibility to install a CRON. This  This installation is installed in the example only for the "backend" role. With  With this methodology, they allow all commands to be applied to different roles.

Explanation of "Running Required PHP Commands"

For shopware, for example, you may want the attributes to be regenerated. The  The following command should be added:

php -d bin / console sw: generate: attributes ||  exit $? 

...