Hi @Trevor Strong
The container image simply installs the standard Apache package in the container and adds the CSP add-on.
For any update on the Apache web server we should all keep an eye on https://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45 and consider patching/upgrading/re-building as necessary and according to the security policies and best practices of the organizations we work for.
Also, please upgrade to the lastest container version available that is 2021.1
The short answer is yes, you are correct.
The longer one :-)Stating the obvious, from a tool point of view, to be able to rollback operations means understanding the present state of an instance and of course have a record of all the previous states. In order to be able to do that one needs the concept of a "release state". As soon as you get into maintaining state you quickly escalate the complexity of a solution. See Terraform for example and ICM itself that supports the replication of its state via Consul.
There are tools like Helm, ArgoCd, etc. that help in that, however that is left to the user. Enhancing InterSystems IRIS is an option but that is not available now. At present we rely on a GitOps approach.
GitOps is a paradigm that incorporates best practices applied to the application development workflow all the way to the operating infrastructure of a system.
Embracing GitOps give us some benefits like:
However, GitOps itself is not the delivery & deployment panacea of this complex area. GitOps has issues too. There are shortcomings when auto-scaling and dynamic resources are implemented; there is no standard for managing secrets; observability is immature; rollbacks don't have a standard practice, etc.
The powerful CRUD operations that we can run with the CPF merge feature adds to the complexity. A solution needs to be implemented that may leverage one or more tools that organizations use in their automated provisioning pipeline, just like you would do when embracing the GitOps paradigm.
I think there are two ways to solve our rollback issue, at present.The first one would be a programmatic approach, maybe a diff operation on the git hash declarations of (last_op_def) vs (last_op_def - 1)If last_op_def contains a Create-resource I then need to rollback that with a Delete-resource or Modify-resource. And even in this simple case how do you determine that? Human intervention is probably needed.
The second option, simpler and safer, would be to simply re-run the container, the base state we know, and apply configuration settings #1 and #2 only.
There are probably other options involving verifying the CPF file. However, the present CPF file does not hold all of an instance settings.There are also other issues to these type of automations, like: what if you want to rollback after the creation of a database and data was written to it?
Log in or create a new account to continue