One aspect of instance pools that will come up eventually is the question of updating the individual worker nodes in such a pool to keep up with OS or application updates. The OCI Console lends itself as the tool of choice for building the initial Instance Configuration and then the Instance Pool and Autoscaling Configuration. However, the Console currently doesn't offer any way to update the instances managed by the pool.
There are several aspects to consider for such updates:
The obvious conclusion is that we will need to apply whatever updates there are to the source image used to instantiate new instances when they join the pool. The solution for existing pool members would be to trigger their replacement with new instances.
The way Instance Pools work, they don't allow you to update the Instance Configuration with new parameters or a new source image. However, you can create a new Instance Configuration and then update the existing Instance Pool with this new configuration. This will cause any new instances to spawn off the updated Instance Configuration.
Of course, there are multiple ways to create the initial image and then the Instance Configuration. For example:
oci compute-management instance-configuration create --instance-details file:///instance.details.json --compartment-id <your compartment-id> --display-name "mgoldbuildconfig"An example for the file instance.details.json can be found in this blog.
Whatever you do, the end result will always include an image which will be used as the source for the worker nodes in your Instance Pool. Once you're done with the pool configuration, it will look something like this in the Console:
In this example, it is configured to run two instances. Checking the pool shows that both of them use the initial Instance Configuration:
How you update this image will depend on how you created it. For example:
Whatever you do, you will need to create a new Instance Configuration that will point to the updated image.
Once you created a new Instance Configuration (based on the new or updated image), the next step is to update the existing Instance Pool, replacing the previous version of the Instance Configuration with the new one. All we need for this is the OCIDs of the existing Instance Pool and the new Instance Configuration. We can then update the pool with the command
oci compute-management instance-pool update --instance-pool-id <instancepool-ocid> --instance-configuration-id <newinstanceconfiguration-ocid>
The resulting pool configuration will look like this in the Console:
This will have no immediate effect on the running instances in the pool, so any active production workloads will continue unaffected. However, any new instance that is spawned because of a scaling operation will now use the updated Instance Configuration and thus the updated image. The result will be that any new instances will run on the updated image, while all the "old" instances will continue to work on the older version:
The final step, therefore, is to replace the old instances with new ones.
The simplest method to replace these old instances is to terminate them - either from the console or via the CLI. Make sure to terminate their boot volumes along with the instances. The Instance Pool will notice this and spawn replacements as needed:
Note that terminating the instances might interrupt the workload running on that instance. However, this is also the case in a scale-down operation triggered by the pool, so it is usually safe to assume that the workload is transactional in nature and will recover from an unexpected instance termination.
Of course, if something is wrong with the new Instance Configuration, reverting back to the old configuration is as simple as repeating the above command, using the OCID of the previous, known good Instance Configuration.
As we've seen, it is not too difficult to update the instances in an Instance Pool, even while the pool is in production. To summarize, the steps are: