Container Redeploy

Once you have your Docker template deployed and properly configured, you receive a fully functional and stable application. However, the majority of Dockerized applications and services are continuously developed, delivering new product versions (implemented within tags) from time to time. Thus, most likely, eventually you’ll need to update your already running template to its latest version.

With Jelastic, such redeploy operation could be performed just in a few clicks, whilst providing the following benefits:
  • data, stored within the mounted to a container volumes, can remain available afterwards through being packed into separate .tar.gz archives, which are automatically transferred out/in the container to the host physical server during this operation
  • all the previously specified custom configurations (like run commands, links, variables, etc) and files in /var/lib/jelastic directory (required by Jelastic to ensure container operability) won’t be affected
  • if operating with multiple template instances (i.e. in case it was scaled horizontally), the update can be performed implicitly and causing no downtime through redeploying the containers one by one
  • containers are automatically backed up during the redeploy, allowing, to painlessly restore node’s previous version in case of any issues; herewith:
    • you are not charged for the redeployment backups created by Jelastic
    • failure during the sequential redeployment interrupts the process so that it won’t be initiated on the remaining containers
    • if faced some problems with container(s) after successful redeploy, contact your service hosting provider support team to restore the previously used version (usually, only the latest redeploy operation can be reverted)

container update logo

Also, depending on a used software stack, some of container configuration files will be automatically saved and re-applied to your updated instance(s) afterward. Such files are listed within a dedicated redeploy.conf configuration file, where you can also set paths to your customized configs and/or user data which you’d like to keep (or backup) during container update(s) in a similar way.

And now let’s consider how to actually perform the container update with another tag version either directly through the developers dashboard using GUI or remotely, with the help of Jelastic API and CLI.

Update Container via Dashboard

The most clear and user-friendly way to update the template tag is to use Jelastic 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) container redeploy button button next to the required node or layer (for updating all the comprised containers at once):

    container redeploy button dashboard
  • or, you can click on the Change environment topology button for your environment and then hit the pencil icon next to the tag version in the central part of the opened frame:

    container redeploy in topology wizard
2. As a result, you’ll be shown the Redeploy containers frame, where you need to select the desired Tag from the automatically fetched list, which will be used while updating the chosen container(s).

container redeploy dialog frame
Also, you can specify some additional options:
  • Keep volumes data - shown if at least one volume is mounted to the selected node(s); when turned ON, your data will be protected from erasing and will remain available after redeploy
  • in case of redeploying multiple containers at once (i.e. the chosen server was scaled out and thus includes multiple same-type containers), you can switch between two deployment options:
    • Simultaneous deployment - runs redeploy on all containers at once, which cause a brief downtime of your app (however, in this case the procedure itself will take less time)
    • Sequential deployment with delay - makes all layer instances being redeployed sequentially, i.e. one by one with a specified delay; in this case, running nodes will continue serving the incoming requests while a particular one is undergoing the update, ensuring your service availability during the procedure

After all the configurations are determined, just hit the Redeploy button and confirm within the pop up.

3. Once the update is completed, you’ll see the corresponding pop-up message appeared in the top right corner of the dashboard:

container redeploy dashboard notification
Clicking the Show Logs button will lead you to the redeploy log tab, which contains the information on Node ID of the updated container(s), name:tag of the redeployed image and Duration of this process.

container redeploy action logs
4. Also, the current image tag version for every container can be seen within the Tags column next to the appropriate Node ID record at the dashboard.

container tag version in dashboard
Now, you know of all the Docker tag version management possibilities available via Jelastic dashboard.

Update Container using Jelastic API and Cloud Scripting

The update process can be automated using Jelastic API and Cloud Scripting.

Execute the environment.control.RedeployContainers method with the appropriate parameters:
  • envName - name of the environment with container(s) to be redeployed
  • session - user session identifier from authentication response
  • nodeGroup - label of an environment layer to update all containers in it at once [optional]
  • nodeId - identification number of an exact container to be redeployed singly [optional]

    Note: You have to obligatory specify one of the latter two parameters to designate which container(s) should be updated - or you’ll get an error otherwise.

    Herewith, if adding both of them, only the nodeId value will be considered during the method execution.
  • tag - image version to be deployed
  • useExistingVolumes - set it to true to keep data in the mounted volumes present within the updated container(s) [optional]
  • login and password - two separate parameters with credentials to access images within private registries [optional]
  • skipReinstall - if set to true, the newly deployed image will be extracted upon the already existing file system and merged with it (whilst the default redeployment flow implies recreating a container from scratch and deploying new image tag to a bare instance) [optional]

container redeploy api methods

Use the following constructions to designate container update within your automation scripts.

For example, for redeploying the whole group of container nodes, the required strings are:

api: environment.control.RedeployContainers
nodeGroup: {nodeGroup}
tag: {myImage}:{newTag}
  • {nodeGroup} - environment layer (or node group) where all containers should be updated
  • {myImage} - name of the image to be deployed
  • {newTag} - the required version of the image above

And to update a particular container apart from the rest ones, add such commands to your script:

api: environment.control.RedeployContainers
nodeId: {nodeId}
tag: {myImage}:{newTag}

where {nodeId} value should be substituted with the identificator number of the required node, whilst the rest of placeholders are the same as above.

Redeploy Container via Jelastic CLI

Another possible way to update container template tag is to use Jelastic CLI, which provides the ability to accomplish all the required operations remotely.

Tip: In order to find out how the Jelastic CLI can be installed and used in the most beneficial way for your environments’ and nodes’ remote management, refer to the linked instruction.

Once you’ve installed CLI at your workstation, you are able to take the control over your Jelastic account via terminal. In our case, i.e. with an aim to perform the container(s) redeployment, the following actions are required:

1. Look for the available for template tag versions by executing command from below:
~/jelastic/environment/control/getcontainertags --image {templateName} [--registry {registry}] [--userName {login}] [--password {password}]
where {templateName} corresponds to the name of the required template, while {registry}, {login} and {password} are optional parameters, required in case of a private repository usage.

get container tags cli
2. Now, when you know the list of existing image tags, you can choose the one you need and initiate the container update - just run the redeploycontainers method with same parameters as described for API:
~/jelastic/environment/control/redeploycontainers --envName {envName} [--nodeGroup {nodeGroup}] [--nodeId {nodeId}] --tag {tag} [--useExistingVolumes {useExistingVolumes}] [--login {login}] [--password {password}]

redeploy containers method cli
Wait for a couple of minutes for the method to response with success (i.e. "result": 0).

Saving Custom Data during Container Update

Each newly created container at Jelastic PaaS contains a special redeploy.conf config with a predefined list of container configuration files to be saved and re-applied after its update to another image version. Regardless of a used stack, the following items are automatically preserved at any node:
  • /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 for further container access via SSH and/or interaction with other related containers

Also, the redeploy.conf for each particular node type will include some additional stack-specifics files to be saved, namely:

Apache PHPbackup:/etc/php.ini
Apache Ruby/var/lib/jelastic/env
NGINX(load balancer)/etc/dhcp/dhcpd.conf
NGINX PHPbackup:/etc/php-fpm.conf
NGINX Ruby/var/lib/jelastic/env

This default list of preserved configurations can be supplemented with your custom files and folders upon the necessity - just add an entry with a full path to a required item to the mentioned redeploy.conf file (where each entry should be started with a new line).

redeploy conf file

Don’t forget to Save the changes.

Creating File Backup Copy Upon Image Redeployment

When rolling up a new software version, the good practice is to reinsure yourself by creating a backup copy of the current container configurations. Further on, it can come in handy for merging the required customizations with the updated configs or, in case of experiencing some incompatibility issues that affect your service operability, for an instant rollback to the previously used settings.

To automatically preserve such file(s) each time your container is undergoing update, add a string of the following format to the redeploy.conf file:


As a result, the system will store a duplicate of the stated file (regardless of whether the newly chosen image tag implies any changes within its content or this item presence in a container at all) with appending the “.backup” string to its original name. This way, further you’ll be able to readily recognize which config contains your customizations and which one is a new one, created upon container update.

Note: This option is applicable to files only and not to directories.

As an example, below we show the default backup settings for all PHP application server stacks, with /etc/php.ini copy being automatically saved:

backup files in redeploy conf
In this way, after container update, you’ll see the new php.ini file and its previously used version saved as php.ini.backup.

restoring from backup after redeploy
Note: Each new {file_name}.backup file, created during container redeploy, automatically replaces the same-named one (if such already exists).

In such a way, you can easily switch to the previously used settings by substituting the php.ini file with its backup (through renaming the file itself or simple copying of its content).

That’s it! With Jelastic PaaS you get a powerful tool for the container tags management, being allowed to switch between them when needed with no manual adjustments or data transferring required.