Deploying your application to StarlingX with FluxCD

This article was published for StarlingX you can view original here.

The article is part of a blog post series that guides you through the various ways of deploying a containerized application on top of the StarlingX platform. As a reminder, the methods are the following:

• Plain Kubernetes methods;

• Helm;

• FluxCD; and finally

• As a StarlingX Application, which benefits from tight integration with the StarlingX system.

In this article, I will continue demonstrating application deployment options, this time with focus on FluxCD, which is a continuous delivery tool that is used to keep Kubernetes clusters in sync with configuration sources.
In this example, I will be using StarlingX in a virtual All-In-One Simplex (AIO-SX) configuration. If you want to follow along, you can set up your environment by following the Starlingx automated install guide.

The Demo App

For consistency, I will use the same application as in the previous post. To learn more about the demo app, check out the demo app repository.

GiftOps and FluxCD

One of the greatest benefits of using FluxCD resources is the possibility to utilize GitOps methods for your deployments. GitOps is a set of practices, such as version control, collaboration, compliance and continuous delivery, and apply them to your infrastructure to achieve a certain level of automation. GitOps uses a Git repository as single source of truth for all of your configuration options, for both infrastructure and applications.

FluxCD allows you to use GitOps practices, through a set of tools, to enable a reliable and automated mechanism of deploying and managing infrastructure and applications, improving reproducibility and facilitating maintenance and scalability of your system.

To know more about FluxCD visit the project's official website.

Deploying the Demo App via FluxCD resources. 

The StarlingX platform provides access to FluxCD resources without direct access to its CLI, which allow you to easily deploy and manage your applications. For a list of all available Flux resources, refer to the official documentation.

There are many ways of deploying an application using Flux. In this demonstration, I will deploy the demo app by creating a Source Controller and a Helm Controller.

Source Controller

The Source Controller is a FluxCD component responsible for providing a common interface for artifact acquisition.

FluxCD offers 5 types of Source Controllers:

• GitRepository

• OCIRepository

• HelmRepository

• HelmChart

• Bucket

For this demonstration, I will create a GitRepository. Make sure to choose the best type of source controller for your specific use case.

To create my GitRepository that will contain the Helm Chart, I simply run the following code:

git clone https://github.com/brunomuniz-encora/poc-starlingx-messages.git
cd poc-starlingx-messages
helm package helm-chart/

The command above creates a GitRepository resource called poc-starlingx that contains the contents of https://github.com/bmuniz-daitan/poc-starlingx-messages.git

...
Successfully packaged chart and saved it to: .../poc-starlingx-messages/poc-starlingx-1.5.2.tgz

Helm Controller

The Helm Controller is an operator that allows the management of Helm Chart releases in a declarative way. The resource HelmRelease will define the desired state of a Helm release, and based on actions upon this resource (creation, deletion or mutation) the controller will perform Helm actions. In this scenario, before the HelmRelease is created, it will create a resource HelmChart. The HelmChart is a FluxCD resource responsible for holding the Helm charts with the specific set of values defined by you.

To deploy the demo app, I execute the following commands:

helm install poc-starlingx-messages-node poc-starlingx-1.5.2.tgz

As mentioned, the kubectl command above creates two resources, first, a HelmChart resource, which is loaded from the GitRepository.

NAME: poc-starlingx-messages
LAST DEPLOYED: <date> <time>
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
[sysadmin@controller-0 ~(keystone_admin)]$ 

After the HelmChart resource is successfully created, it moves on to create the HelmRelease for the deployment of the application with the values defined in the helmrelease.yaml file.

sysadmin@controller-0:~$ kubectl get all
NAME                                       READY   STATUS    RESTARTS   AGE
pod/poc-starlingx-85d766894b-dmw4v         1/1     Running   0          40s

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/poc-starlingx          NodePort    10.97.156.62    <none>        8100:31234/TCP   40s

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/poc-starlingx          1/1     1            1           40s

NAME                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/poc-starlingx-85d766894b         1         1         1       40s

With the success of the reconciliation, you can see that the application was deployed.

sysadmin@controller-0:~$ helm list
NAME                    NAMESPACE       REVISION        UPDATED         STATUS     CHART                            APP VERSION
poc-starlingx-messages  default         1               <date> <time>   deployed   poc-starlingx-1.5.2              1.5.2
[sysadmin@controller-0 ~(keystone_admin)]$

Modifying the HelmRelease

As I said before, actions upon the HelmRelease resource cause the controller to perform Helm actions on the deployment. So you can see these type of actions, let's modify a value on the HelmRelease file and see what happens.

First, I change the value of replicas from 1 to 5, this value can be found in spec.values.kube.replicas inside the helmrelease.yaml file:

cat <<EOF > central-overrides.yml
env:
  # Set application to act as a `central`
  - name: MODE
    value: central

kube:
  # Set the NodePort to be configured within the Kubernetes Service resource
  port: 32767
  # Set a different name for the Kubernetes resources (helper to allow multiple instances run in the same cluster)
  name: poc-starlingx-central

EOF

Then I run the kubectl apply command again, and wait for the command line to to show that the HelmRelease resource was configured.

helm install -f central-overrides.yml poc-starlingx-messages-central poc-starlingx-1.5.2.tgz

If you run kubectl get pods, you can see that 4 additional pods were created.

NAME: poc-starlingx-messages-central
LAST DEPLOYED: <date> <time>
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Additional resources

In the FluxCD official documentation, you can find further resources that Flux provides, which may be better suited for your specific use case, such as kustomization. This resource is responsible for defining a pipeline for fetching, decrypting, building, validating and applying kustomize overlays or plain Kubernetes manifests.

As a summary, FluxCD allows you to deploy your application in many different ways. It is up to you to evaluate the best resources and how to structure them so your application can make the most of what FluxCD has to offer.

Conclusion

You have just learned how to make use of the resources from FluxCD, made available on the StarlingX platform, to deploy your containerized application. For more information about FluxCD, please visit the official project website.

Next in this series, you will learn how to package and deploy your application as a StarlingX app and the benefits that this type of deployment offers.

About StarlingX

If you would like to learn more about the project and get involved check the website for more information or download the code and start to experiment with the platform. If you are already evaluating or using the software please fill out the user survey and help the community improve the project based on your feedback.