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

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 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.

In such a way, with Jelastic you get a powerful tool for the Docker template tags’ management, being allowed to switch between them when needed with no manual adjustments or data transferring required.