The Docker-based solutions are continuously developed, to deliver new product versions and fixes. So, it is highly recommended to regularly update your templates to their latest tags/releases.
This operation is called redeployment. Below, you will find some of the 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 Jelastic 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 (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, e.g. implicitly with no downtime
You can update your Docker-based container to a new tag (version) without affecting the application inside in just a few clicks via the dashboard UI or easily automated via API.
Important!: Downgrading (e.g. redeploying to the lower version) is not supported when working with the MySQL, MariaDB, or Percona databases. In case of extreme necessity, we recommend creating a backup and restoring a database after redeploying (or in a separate container altogether).
Update Container via Dashboard
The easiest way to redeploy a template tag is via dashboard. Follow the guide as shown below to perform this action:
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)
click the pencil icon next to the layer tag version in the topology wizard (when Changing Environment Topology of the existing environment)
2- As a result, the Redeploy containers frame will be opened. Select a new Tag for your container(s).
You can adjust some additional options like:
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
By finishing the configurations, click the Redeploy button and confirm within the pop-up.
3- Once the update is completed, you?ll see a notification in the top right corner of the dashboard.
Click Show Logs to open the information tab with of the updated container - Node ID, name:tag, and Duration.
Update Container via Jelastic API/CS/CLI
You can use Jelastic API, Cloud Scripting, and CLI (command-line interface) to automate the update process.
Important!: The detailed example on container redeploy via CLI is provided in the linked guide.
Container redeploy is performed with the environment.Control.RedeployContainers method, which is managed with the following parameters:
envName - name of the environment, where container(s) should be redeployed
session - user session (or token) identifier, used for authentication
nodeGroup - identifier of the environment layer to update (optional)
nodeId - identification number of the particular container to be redeployed (optional)
Imortant!: You need to state either nodeGroup or nodeId parameter to define the operation target. The method ignores nodeGroup if both are provided and fails if neither is specified.
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 - credentials to access an image from the private registry (optional)
skipReinstall - define if the image should be extracted upon the existing file system (true) or deployed to a new instance (false by default) (optional)
Below you will find the constructions to used for defining container update within your automation scripts:
1- Redeploying the whole layer of containers.
api: environment.control.RedeployContainersnodeGroup: {nodeGroup}tag: {myImage}:{newTag}Here:
{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
2- Updating a particular container.
api: environment.control.RedeployContainersnodeId: {nodeId}tag: {myImage}:{newTag}Here, substitute the {nodeId} value with the ID number of the required node (other placeholders are the same as for the example above).
Saving Custom Data during Container Redeploy
A special redeploy.conf file comes along with every Jelastic-managed container, where a list of critical container configs is stored. These settings are automatically preserved by the platform during the container redeploy. 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
The redeploy.conf for each node type includes different stack-specifics files.
The default list of preserved configurations can always be replaced 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.
Creating File Backup Copy Upon Image Redeployment
It is quite simple to create backups for configuration files during the container update. When replacing the specified config with its version from the new tag, a copy of the file from before the redeploy will be preserved.
Specify a path to the necessary file in redeploy.conf and add the ?backup:? prefix to the record to create a backup as shown below:
backup: {path_to_file}Important!: This operation is available for files only (not directories).
After redeploying, the config from the old container can be easily recognized by the appropriate ?backup? or ?time stamp? extensions. They can be used at any time to rollback upon incompatibility with the new configs or for analysis of the changes.
For example, all Jelastic-managed PHP application servers create a backup for the /etc/php.ini config by default.
After the update, you will see both, new and previous versions of the php.ini or any other backed up files:
{file_name} - file from the redeployment target image (from the new tag)
{file_name}.{time_stamp} - backup version of the file created just before the redeploy operation (a separate file for each redeployment to a different tag)
{file_name}.backup - the latest backup of the file (automatically replaces the previous same-named backup)
Replace the php.ini file with its backup (e.g. through the renaming or content copying) to switch to the previously used settings.