We are excited to introduce a new GitOps-based usage model in Satellite Config.
IBM Cloud Satellite brings managed, cloud-native services to clients running workloads on-premises, at the edge and in third-party clouds and IaaS providers. One of the popular use cases for IBM Cloud Satellite is hosting managed OpenShift clusters on-premises and anywhere the client needs them. IBM Cloud Paks and many cloud-native workloads are already containerized. Offering a managed Kubernetes environment like Red Hat OpenShift on IBM Cloud in Satellite gives clients the flexibility to run workloads where it makes the most sense.
In order to manage these container workloads, users need automation to deliver cluster configurations and applications to OpenShift clusters in a uniform and easy-to-use manner. Satellite Config is a core component of IBM Cloud Satellite and provides this configuration management and deployment functionality for clusters.
What’s new?
Previously, Satellite Config only supported the direct upload of Kubernetes resource files to defined cluster groups. Automation was difficult, and user feedback indicated that the overall user experience defining clusters, upload resource files and defining versions was too complicated.
To address this, we are introducing a new GitOps-based usage model in Satellite Config. Policy, configuration and application resource definitions are stored in some form of Git Repository (we support GitHub and GitLab). Changes to the repository automatically trigger the deployment of changes to the impacted clusters. Using GitOps allows users to take Policy as Code and Configuration as Code approaches to deployments. This also enables version control, auditing and works well with rolling updates.
What is GitOps?
GitOps is a declarative way to implement continuous deployment for cloud-native applications. The key principles of GitOps are as follows:
- The Git repository is the single source of truth.
- Everything is observable. Environment changes are auditable through Git.
- There is a separation of concerns. Versioning is managed by Git and it changes trigger events that are processed by the deployment automation.
Use case
With Satellite Config, users can deploy their cluster configurations and applications across OpenShift clusters consistently and with a single pane of glass view.
There are three components to Satellite Config that are required to get this functional:
- Configuration: With Satellite configuration, users can upload or create Kubernetes resource YAML file versions to deploy to a group of clusters.
- Cluster groups: A cluster group specifies a set of clusters that are registered with the Satellite Config component and included in a Satellite configuration.
- Subscription: A Satellite subscription specifies which Kubernetes resource is deployed to one or more cluster groups.
Scenario A
There are three development environments: Dev, Stage and Production. Each has two OpenShift clusters deployed in three different Satellite Locations.
Each of the applications and cluster configurations are stored in a single Git Repository in different branches (as Dev, Stage and Prod, respectively).
Using Satellite Config GitOps model, you can use the following setup:
- A single Configuration with three Subscriptions.
- Each of these Subscriptions would define the relationship between the Git repo, branch of interest and cluster group defining the target clusters.
- Three Cluster Groups with two clusters each (Dev with two clusters, Stage with two clusters and Prod with two clusters).
With the above setup, any change to the Git Repository and to the respective branch will trigger deployment to the target clusters in the Cluster group. This allows automation, flexibility and easy operation and management of application deployment across multiple clusters with any resource change on Git.
This CD model helps maintain the application code and configuration in Git. The management of target clusters resides within Satellite Config, giving developers the seamless experience of managing code in Git and have automated process to deploy and test their applications on their OpenShift clusters.
Scenario B
There are three production environments for different regions where the user wants to deploy the application from one environment to another. For example, the first deployment happens in a US region. Then, when successful, the changes are promoted to be deployed in the EU region and then in the ASIA region.
Each of the application and cluster configurations are stored in a single Git Repository in different branches (as US, EU and ASIA, respectively). The user sets up automation to promote changes from one branch to another only after a set of integration tests succeeds on a given environment. Once the branch is updated, that will be then taken into account by Satellite Config and the next target environment gets deployed.
Using the Satellite Config GitOps model, you can use the following setup:
- A single Configuration with three Subscriptions.
- Each of these Subscriptions would define the relationship between the Git repo, the branch of interest and the cluster group defining the target clusters.
- Three Cluster Groups with three clusters each (US with three clusters, EU with three clusters and ASIA with three clusters).
The deployment of the app happens on the US Cluster group, and after the deployment, the user-defined integration test runs. Since the test ran successfully in this case, the Git branch for the US updates the branch for the EU. Since the EU branch is updated, Satellite Config will pull the new updates and deploy to the EU cluster group. Then, the integration test on clusters in the EU fails. This requires some manual fixes in the app configuration on Git. Therefore, no updates are made to the Git branch for ASIA.
With the above setup, any change to the Git Repository and the respective branch will trigger deployment to the target clusters in the Cluster group. This allows automation, flexibility, and easy operation and management of application deployment across multiple clusters with any resource change on Git.
Conclusion
With this new feature, you can now bring your Git repositories and use them as a source of truth for Satellite Config. Learn more about Satellite Config here.