Rolling Container Updates with Custom Data in Jelastic PaaS

Together with continuously issued new software releases and vulnerabilities fixes, sooner rather than later everyone faces the necessity to upgrade the running container images or software stack run-times that serve our application. To simplify this operation and all the attendant maintenance procedures, Jelastic PaaS provides the built-in ability to roll up a new container image version (tag) and merge it with custom data from a running instance.

Typically, the container tag update implies replacement of the stack-related configuration files with the ones from the selected image tag. With Jelastic PaaS, you are able to designate which your custom data within the updated container should be saved. Additionally, some system and configuration files that are responsible for proper container operability, are backed up by default, namely:

• The whole content of the /var/lib/jelastic directory, as Jelastic utilizes it for storing various files and configs, required for internal operations;
• Data in default or custom volumes (optional, is defined with the appropriate option);
• All files and folders, specified in the dedicated file /etc/jelastic/redeploy.conf.
   

All of the data mentioned above will be packed into separate .tar.gz archives, which are automatically transferred out to the host physical server before redeploy and moved back to the container afterwards. Also, custom container configurations that you’ve set through the dedicated wizard within Jelastic GUI (i.e., environment variables, run configs, port settings, mounted volumes and linked instances), will be automatically re-applied as well.

Below we’ll consider in more details how the container redeployment procedure is handled at Jelastic PaaS and some additional possibilities that can be useful for saving your custom user data during rolling application or microservice updates.

How to Update Сontainer with New Image

Your running Docker containers can be updated with a newer image tag in the following convenient ways:

• Developers Dashboard – click the Redeploy containers button next to the appropriate node (or layer) to access the same-named dialog frame.
   
  Here, you can switch image version to the required tag, designate whether it’s required to keep data in volumes and, in case the chosen layer contains several containers, to set either they should be updated all at once or one-by-one with a predefined delay (to avoid the appropriate server downtime).
• Jelastic API – 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].
     
• Jelastic CLI – to update your container via command line, use the script ~/jelastic/environment/control/redeploycontainers – the details on the flow and all available parameters are described within the linked documentation.
   
• Cloud Scripting API action – 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}

  Where:

  • {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 identification number of the required node, whilst the rest of placeholders are the same as above.

Specifying Custom Data

Each container, hosted at Jelastic PaaS, is created with a special etc/jelastic/redeploy.conf file which is responsible for data storing during redeploy process. Through its editing, you can adjust and complement the list of files and directories that should be kept present and unchanged after your container image is updated.

For that, add an entry with a full path to a required item to the mentioned config (where each entry should be started with a new line) as it is shown below.

Herewith, each Jelastic certified container runtime stack is created with a default set of configuration files being already stated within the redeploy.conf file. Regardless of the used stack template, the redeploy.conf file contains the following obligatory elements:

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

The rest of stack-specific files, which are prescribed to be saved within instances of a particular node type, can be seen here.

Creating File Backup Copy Upon Image Redeployment

When rolling up a new software version, the good practice is to re-insure 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:

backup:{full_path_to_the_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.

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

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

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

Conclusion

Summing up described in this article, Jelastic PaaS provides seamless update for your container with a new version or security fix via either convenient UI, API or CLI. Herewith, during rolling out container image updates, you can preserve custom files and folders and, if necessary, backup user data and configurations.

Do not miss the opportunity to explore for free an easy way to deliver application updates with the help of container images redeploy functionality at our Jelastic PaaS platform.