Deploying Apps & Config Across Your Distributed Cloud

This is the third article in the “Journey to a Distributed Cloud” series focused on how clients can achieve a hybrid multi-cloud platform anywhere their apps need to run, yet still maintain “as a service” capabilities.

This is part 3. You can jump to part 1, part 2, or view all videos here.

Introduction

In the last article here, I focused on the foundational step of building a distributed cloud. At the end, we had a running distributed cloud where we had OpenShift clusters in a variety of locations around the world.

But let’s be honest: None of it is very useful if it doesn’t enable your team to accelerate…focusing on innovation to deliver a better experience for your customers. That’s where this article comes in. At the end of the day, our clients want the ability to build, deliver, and manage their applications consistently across a hybrid multi-cloud environment so that they can focus on innovating and delivering outstanding experiences to their clients.

Before we start, if you are a visual learner, you can watch this video, then read on!

Cloud Satellite Configuration — Concepts

When we have a distributed cloud, we have multiple Cloud Satellite locations connected to IBM Cloud through a secure Satellite Link, and the purpose is to provide fully managed services anywhere you need them to run.

With this distributed cloud, a dev team can use their existing pipeline and deliver apps to any of those locations.

But what if I want to push configuration changes or applications out across many clusters where each cluster lives behind a different set of firewalls/VPNs since they’re in different locations?

This is where Satellite Configuration (SatConfig) comes in. SatConfig lets you add a .yaml file as a “configuration”, then create a subscription so all clusters in a group will have that .yaml file applied to it. This means you could simply push out a namespace called “use-this-namespace”, a set of custom tools, or an operator that deploys a collection of microservices for an application.

And the clusters you can target? SatConfig has a broader reach. SatConfig’s purpose is to allow users to deploy and synchronize configuration and application components across a broad set of OpenShift clusters. I’ve summarized the various capabilities of Cloud Satellite and the scope difference here:

This means that while only “satellite enabled” cloud services are SRE-managed, Satellite Configurations allow users to deploy and synchronize configuration and application components across any OpenShift cluster, whether it was provisioned by IBM Cloud Satellite or not. In my experimentation, I’ve been able to run SatConfig on OCP clusters not provisioned by IBM Cloud (including OpenShift stand-alone clusters, ROSA, ARO, etc.) as I show in this graphic:

How Satellite Configuration Works

Here’s a summary of how SatConfig works:

• I attach the clusters I want to deploy and synch config
• I create configurations
• I create a subscription to start the deploy and synchronization across a group of clusters
• If the configuration changes in a cluster, the SatConfig subscription will return it to desired state

Let’s go through these in detail.

Attach Clusters

I attach my OpenShift cluster to my list of clusters for SatConfig. If I’ve provisioned through Cloud Satellite, I can choose to enable management through SatConfig with a single click during creation and it’s ready to rock. If I have an OpenShift cluster not provisioned through Cloud Satellite (Other OpenShift on IBM Cloud clusters, other OCP clusters in the world), I can attach separately.

To attach a cluster, I navigate to Satellite > Clusters, then click, “Attach Cluster”. I give it the name of the cluster and Cloud Satellite generates a script I’ll run to deploy the SatConfig agent. This agent is called razeedeploy.

Once run, the cluster shows as “Active” in the Cloud Satellite UI, and the following is running on the cluster itself:

Create Configuration

Next, I create a configuration. This is just a “holder” for the configuration versions, which are the .yaml files you want to deploy. While you may only have one version (create a namespace…simple), most of the time you will have a configuration that states what the thing is you want to do, and then multiple versions as you improve and iterate over time.

Tip: You can also create versions and create/edit subscriptions via CLI which means you can add this capability into your pipeline to deliver the updated version once all your automated tests pass. This will then fully automate your deployments from a central location.

ibmcloud sat config version create — name <version_name> — config <configuration_name_or_ID> — file-format <type> — read-config <file_path>

That said, if your configs require an image, you’ll need to push the images out ahead of time to local image repos accessible by the local Satellite clusters (remember, most of these clusters are behind a firewall and may have limited egress).

In my example, I’m creating a configuration called “custom-tooling-4”. It is a simple YAML that deploys 3 replicas of a container with some tools in it.

Deploy custom-tooling-4

Now I want to deploy my .yaml across a group of clusters. I select “Create Subscription”, and select a name of the subscription, the version to run, and the cluster group to run them on.

Once it’s running, the subscription will instantly deploy the .yaml file.

I can keep track of the subscription in the Satellite UI:

And I can view the results in one of the OCP clusters I’ve subscribed it to:

Update to custom-tooling-5

As the custom tooling gets used, issues and enhancements are brought up, and iteratively get implemented. Therefore, at some point I decide to update what is deployed across the clusters. To do that, I simply create a new version (version 5), edit the subscription, and watch the content instantly update across the clusters. In this graphic, the cluster is in the middle of updating from version 4 to version 5.

Further, the subscription protects me from configuration drift. If the deployed configuration ever changes, (in this case I scale up to four pods), the subscription detects the change and returns the environment to the desired state (in this case, it scaled back down to three pods). In this graphic, you can see I’ve got multiple subscriptions, across a variety of clusters.

Finally, if I no longer want that configuration deployed, I simply delete the subscription and the deployed content immediately is removed.

To me, Satellite Configuration reinforces the goal to code your apps in a portable way because it is quite handy to treat clusters as cattle, create/destroy full clusters with ease, and when the cluster is ready, add it to a cluster group and push all configuration/applications I want running on that new cluster automatically. Then when I’m done with the cluster, just blow it away.

Conclusion

This is just the beginning of what SatConfig can do for you. Yes, it’s a bit of a blunt instrument (deploy .yaml files, keep them synched), but creatively there are many, many scenarios that can be run to highly automate managing the applications and cluster configuration across your entire distributed cloud.

Stay tuned for my next article where I’ll get into Observability and how a single control plane should include common logging, monitoring, auditing not just for the clusters but for the applications as well.

How about you? How would you use Satellite Configuration to help manage your applications and clusters?