Container Redeploy

Table of Contents

The majority of Docker-based solutions (including CirrusGrid-managed stacks) are continuously developed, delivering new product versions and fixes. Thus, it is recommended to regularly update your templates to their latest tags, i.e. releases.

Such an operation is called redeploy and has the following specifics when managed on the platform:

  • the custom user data and sensitive system files are preserved during the update:
    • content of the volumes (default and custom ones)
    • files listed in /etc/jelastic/redeploy.conf (specific configs of the CirrusGrid stacks), which are required to ensure container operability
    • AutoFS and NFS related configurations (/etc/autofs.jelastic, /etc/auto.master, /etc/exports)
    • firewall configurations (/etc/sysconfig/iptables-custom, /etc/sysconfig/iptables4-jelastic, /etc/sysconfig/iptables6-jelastic, /etc/iptables/rules.v4)
    • SSH access data (/root/.ssh/authorized_keys, /root/.ssh/authorized_keys2, /root/.ssh/id_rsa)
  • all the previously specified custom configurations (like run commands, links, variables, etc.) won’t be affected
  • if operating with multiple (horizontally scaled) instances, the update can be performed on containers one by one, i.e. implicitly with no downtime

In such a way, you are able to update your Docker-based container to a new tag (version) without affecting the application inside. With CirrusGrid PaaS, container redeployment can be performed in just a few clicks via the dashboard UI.

Note: When working with the MySQL, MariaDB, or Percona databases, downgrading (i.e. redeploying to the lower version) is not supported. In case the operation is necessary, we recommend creating a backup and restoring a database after redeploy (or in a separate container altogether).

To learn about saving or backing up custom data during redeploy, refer to the appropriate section below.

Update Container via Dashboard #

The most straightforward and user-friendly way to redeploy a template tag is to use the CirrusGrid dashboard. The instruction below will walk you through the required steps:

1. The dedicated redeployment dialog frame can be accessed in two different ways:

  • select the Redeploy Container(s) button next to the required node or layer (for updating all the comprised containers at once)redeploy containers via ui

  • click the pencil icon next to the layer tag version in the topology wizard (when Changing Environment Topology of the existing environment)redeploy containers topology wizard

2. As a result, the Redeploy containers frame will be opened, where you can select a new Tag for your container(s).redeploy containers dialog

Also, you can adjust some additional options:

  • Keep volumes data – if enabled, data in the volumes will be protected from erasing and will remain available after redeploy
  • for horizontally scaled containers, you can choose between two deployment options:
    • Simultaneous deployment – redeploys all nodes at once, which is comparatively quicker but cause a brief downtime of your application
    • Sequential deployment with delay – redeploys instances one-by-one with a specified delay between operations. This option ensures that there is always a running node to process incoming requests (i.e. no downtime)

After all the configurations are set, click the Redeploy button and confirm within the pop-up.

3. Once the update is completed, you’ll see the corresponding notification in the top right corner of the dashboard.successful redeploy notification

Click the Show Logs button to open the appropriate tab with information on the updated container – Node ID, name:tag, and Duration.redeploy action log

Now, you know how to redeploy a container via the CirrusGrid dashboard.

Saving Custom Data during Container Redeploy #

Each CirrusGrid-managed container is provided with a special redeploy.conf file, where a list of critical container configs is stored. These settings are automatically preserved by the platform during the container redeploy. Herewith, some of the common files are provided on all of the stacks:

  • /etc/jelastic/redeploy.conf – the current redeployment config itself (to store the list of required for saving files and directories during each further container redeploy)

  • ${home}/.bash_profile – contains the default SSH shell settings (e.g. shell introduction message, the required configuration files to be fetched, etc.)

  • /etc/sysconfig/iptables – keeps the default firewall rules

  • /etc/sysconfig/iptables-custom – contains custom firewall rules

  • /var/lib/jelastic/keys – stores uploaded SSH private keys, which are necessary to access container via SSH and for interaction with other containers

  • Also, the redeploy.conf for each particular node type will include some additional

    stack-specifics files.

    If needed, the default list of preserved configurations can be supplemented with your custom files and folders. Open the redeploy.conf file and add an entry with a full path to the required item (each entry should be stated in a separate line).

redeploy conf file

Don’t forget to Save the changes.

Creating File Backup Copy Upon Image Redeployment #

CirrusGrid PaaS provides a convenient and simple way of creating backups for configuration files during the container update. Namely, besides replacing the specified config with its version from the new tag, a copy of the file from before the redeploy will be preserved.

To create a backup, you need to specify a path to the necessary file in redeploy.conf and add the “backup:” prefix to the record:

backup: {path_to_file}

Note: This operation is available for files only (not directories).

After redeploy, the config from the old container can be easily recognized by the appropriate “.backup” extension. It can be used for an instant rollback upon incompatibility with the new configs or for analysis of the changes.

For example, all CirrusGrid-managed PHP application servers create a backup for the /etc/php.ini config.

file backup via redeploy conf

After container update, you’ll see new and previous versions of the php.ini files.

backup file successfully created

Note: A new {file_name}.backup file automatically replaces the previous backup (i.e. the existing same-named file) during redeploy.

This way, you can easily switch to the previously used settings by substituting the php.ini file with its backup (e.g. through files renaming or content copying). Now, you know how to manage templates versions (Docker tags) of the containers inside CirrusGrid PaaS.

Powered by BetterDocs