Autonomous configuration-based release orchestration with autonomous runtime container management configuration
A method and apparatus for autonomous container management configuration changes to container clusters during runtime and autonomous configuration-based release orchestration. A release manager manages a staggered feature release that includes staggers, stagger order, and container clusters included in each stagger. A logging service manages logs generated by the container clusters and/or app containers. An update service determines container management configuration changes based on analysis of data provided by the logging service. A shared engine attempts to implement instructions provided by the release manager and the update service at different times. The release manager receives an indication of success or failure of the attempted deployment of the feature release to the current stagger. The release manager, responsive to the indication of success or failure, determines to perform one of a plurality of actions, including attempting to deploy the feature release to the next stagger, and rolling back.
1. A method for both autonomous container management configuration changes to container clusters during runtime and autonomous configuration-based release orchestration that supports staggered feature releases across a plurality of container clusters, wherein an application in application (app) containers in the plurality of container clusters include features that each have a state that may be changed, the method comprising:
by a release manager outside of the container clusters, managing a staggered feature release that includes a plurality of staggers, an order for the staggers, and which subset of one or more of the plurality of container clusters is in each stagger;
by a logging service, managing logs generated by the plurality of container clusters and/or the app containers within the plurality of container clusters;
by an update service, outside of the container clusters and coupled to the logging service, determining container management configuration changes based on analysis of data, the data provided at least in part by the logging service;
by a shared engine, outside of the container clusters and coupled to the release manager and the update service, attempting to implement instructions provided by the release manager and the update service at different times, wherein instructions provided by the release manager pertain to one of the plurality of staggers selected by the release manager as a current stagger;
by the release manager, receiving an indication of success or failure of the attempted deployment of the feature release to the current stagger; and
by the release manager, responsive to at least the indication of success or failure of the attempted deployment of the feature release, determining to perform one of a plurality of actions, wherein the plurality of actions includes i) attempting to deploy the feature release to a next one of the plurality of staggers according to the order, and ii) rolling back.
2. The method of claim 1 , wherein the logs include one or more of volume of traffic being received by the app containers currently running in each of the container clusters, CPU load of electronic devices running the app containers, and storage requirements of the app containers, and wherein the data includes current status information indicative of one or more of current volume of traffic being received by each of the container clusters and current health status of the app containers currently running in each of the container clusters.
3. The method of claim 2 , wherein the data also includes one or more of configuration data and historical data.
4. The method of claim 1 , wherein the analysis of the data includes predictions of one or more events occurring in respect of one or more container clusters and/or one or more app containers within the one or more container clusters, wherein the one or more events include one or more of changes in traffic volume, changes in resource usage, and changes in resource availability.
5. The method of claim 1 , wherein the container management configuration changes pertain to runtime configuration of the container clusters and include one or more of a number of the app containers within one of the container clusters, and an allocation of resources between the app containers within one of the container clusters.
6. The method of claim 1 , wherein:
the determining the container management configuration changes comprises identifying a set of one or more of the plurality of container clusters to receive one or more of the container management configuration changes; and
the attempting to implement instructions provided by the update service comprises:
causing a runtime config update to be sent to a second engine within each of the set of the container clusters to receive one or more of the container management configuration changes, wherein each of the plurality of container clusters includes an instance of the second engine.
7. The method of claim 1 , wherein:
the attempting to implement instructions provided by the release manager comprises:
causing an app config update to be sent to a second engine within each of the container clusters in the current stagger, wherein the app config update includes an indication of the application to allow the second engine, in each container cluster of the subset of container clusters in the currently selected stagger, to determine which containers within that container cluster are one of the app containers, and wherein the app config update also includes indications of which of the features are to be changed to which state; and
receiving an indication of success or failure of the attempted deployment of the feature release to each of the container clusters in the current stagger.
8. An article of manufacture comprising:
a non-transitory machine-readable storage medium that provides instructions that, if executed by a set of one or more processors, are configurable to cause the set of processors to perform operations for both autonomous container management configuration changes to container clusters during runtime and autonomous configuration-based release orchestration that supports staggered feature releases across a plurality of container clusters, wherein an application in application (app) containers in the plurality of container clusters include features that each have a state that may be changed, the operations comprising,
by a release manager outside of the container clusters, managing a staggered feature release that includes a plurality of staggers, an order for the staggers, and which subset of one or more of the plurality of container clusters is in each stagger;
by a logging service, managing logs generated by the plurality of container clusters and/or the app containers within the plurality of container clusters;
by an update service, outside of the container clusters and coupled to the logging service, determining container management configuration changes based on analysis of data, the data provided at least in part by the logging service;
by a shared engine, outside of the container clusters and coupled to the release manager and the update service, attempting to implement instructions provided by the release manager and the update service at different times, wherein instructions provided by the release manager pertain to one of the plurality of staggers selected by the release manager as a current stagger;
by the release manager, receiving an indication of success or failure of the attempted deployment of the feature release to the current stagger; and
by the release manager, responsive to at least the indication of success or failure of the attempted deployment of the feature release, determining to perform one of a plurality of actions, wherein the plurality of actions includes i) attempting to deploy the feature release to a next one of the plurality of staggers according to the order, and ii) rolling back.
9. The article of manufacture of claim 8 , wherein the logs include one or more of volume of traffic being received by the app containers currently running in each of the container clusters, CPU load of electronic devices running the app containers, and storage requirements of the app containers, and wherein the data includes current status information indicative of one or more of current volume of traffic being received by each of the container clusters and current health status of the app containers currently running in each of the container clusters.
10. The article of manufacture of claim 9 , wherein the data also includes one or more of configuration data and historical data.
11. The article of manufacture of claim 8 , wherein the analysis of the data includes predictions of one or more events occurring in respect of one or more container clusters and/or one or more app containers within the one or more container clusters, wherein the one or more events include one or more of changes in traffic volume, changes in resource usage, and changes in resource availability.
12. The article of manufacture of claim 8 , wherein the container management configuration changes pertain to runtime configuration of the container clusters and include one or more of a number of the app containers within one of the container clusters, and an allocation of resources between the app containers within one of the container clusters.
13. The article of manufacture of claim 8 , wherein:
the determining the container management configuration changes comprises identifying a set of one or more of the plurality of container clusters to receive one or more of the container management configuration changes; and
the attempting to implement instructions provided by the update service comprises:
causing a runtime config update to be sent to a second engine within each of the set of the container clusters to receive one or more of the container management configuration changes, wherein each of the plurality of container clusters includes an instance of the second engine.
14. The article of manufacture of claim 8 , wherein:
the attempting to implement instructions provided by the release manager comprises:
causing an app config update to be sent to a second engine within each of the container clusters in the current stagger, wherein the app config update includes an indication of the application to allow the second engine, in each container cluster of the subset of container clusters in the currently selected stagger, to determine which containers within that container cluster are one of the app containers, and wherein the app config update also includes indications of which of the features are to be changed to which state; and
receiving an indication of success or failure of the attempted deployment of the feature release to each of the container clusters in the current stagger.
15. An apparatus comprising:
a set of one or more processors; and
a non-transitory machine-readable storage medium that provides instructions that, if executed by the set of one or more processors, are configurable to cause the apparatus to perform operations for both autonomous container management configuration changes to container clusters during runtime and autonomous configuration-based release orchestration that supports staggered feature releases across a plurality of container clusters, wherein an application in application (app) containers in the plurality of container clusters include features that each have a state that may be changed, the operations comprising,
by a release manager outside of the container clusters, managing a staggered feature release that includes a plurality of staggers, an order for the staggers, and which subset of one or more of the plurality of container clusters is in each stagger;
by a logging service, managing logs generated by the plurality of container clusters and/or the app containers within the plurality of container clusters;
by an update service, outside of the container clusters and coupled to the logging service, determining container management configuration changes based on analysis of data, the data provided at least in part by the logging service;
by a shared engine, outside of the container clusters and coupled to the release manager and the update service, attempting to implement instructions provided by the release manager and the update service at different times, wherein instructions provided by the release manager pertain to one of the plurality of staggers selected by the release manager as a current stagger;
by the release manager, receiving an indication of success or failure of the attempted deployment of the feature release to the current stagger; and
by the release manager, responsive to at least the indication of success or failure of the attempted deployment of the feature release, determining to perform one of a plurality of actions, wherein the plurality of actions includes i) attempting to deploy the feature release to a next one of the plurality of staggers according to the order, and ii) rolling back.
16. The apparatus of claim 15 , wherein the logs include one or more of volume of traffic being received by the app containers currently running in each of the container clusters, CPU load of electronic devices running the app containers, and storage requirements of the app containers, and wherein the data includes current status information indicative of one or more of current volume of traffic being received by each of the container clusters and current health status of the app containers currently running in each of the container clusters.
17. The apparatus of claim 16 , wherein the data also includes one or more of configuration data and historical data.
18. The apparatus of claim 15 , wherein the analysis of the data includes predictions of one or more events occurring in respect of one or more container clusters and/or one or more app containers within the one or more container clusters, wherein the one or more events include one or more of changes in traffic volume, changes in resource usage, and changes in resource availability.
19. The apparatus of claim 15 , wherein the container management configuration changes pertain to runtime configuration of the container clusters and include one or more of a number of the app containers within one of the container clusters, and an allocation of resources between the app containers within one of the container clusters.
20. The apparatus of claim 15 , wherein:
the determining the container management configuration changes comprises identifying a set of one or more of the plurality of container clusters to receive one or more of the container management configuration changes;
the attempting to implement instructions provided by the update service comprises:
causing a runtime config update to be sent to a second engine within each of the set of the container clusters to receive one or more of the container management configuration changes, wherein each of the plurality of container clusters includes an instance of the second engine; and
the attempting to implement instructions provided by the release manager comprises:
causing an app config update to be sent to the second engine within each of the container clusters in the current stagger, wherein the app config update includes an indication of the application to allow the second engine, in each container cluster of the subset of container clusters in the currently selected stagger, to determine which containers within that container cluster are one of the app containers, and wherein the app config update also includes indications of which of the features are to be changed to which state; and
receiving an indication of success or failure of the attempted deployment of the feature release to each of the container clusters in the current stagger.