Deploying your application to StarlingX with FluxCD
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.
GitOps 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:
~$ cat <<EOF > gitrepository.yaml
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: poc-starlingx
spec:
interval: 2m
url: https://github.com/bmuniz-daitan/poc-starlingx-messages.git
ref:
branch: main
EOF
~$ kubectl apply -f gitrepository.yaml
The command above creates a GitRepository resource called poc-starlingx that contains the contents of https://github.com/bmuniz-daitan/poc-starlingx-messages.git
~$ kubectl get gitrepositories
NAME URL AGE READY
poc-starlingx https://github.com/bmuniz-daitan/poc-starlingx-messages.git 49s True
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:
~$ cat <<EOF > helmrelease.yaml
apiVersion: "helm.toolkit.fluxcd.io/v2beta1"
kind: HelmRelease
metadata:
name: poc-starlingx
spec:
releaseName: poc-starlingx
interval: 2m
chart:
spec:
chart: ./helm-chart # Relative path of the Helm chart inside the repository.
version: 1.5.2
sourceRef:
kind: GitRepository
name: poc-starlingx
values: # Override values for the Helm chart
env:
- name: MODE
value: node
- name: SERVER
value: 127.0.0.1:8100
- name: PORT
value: "8000"
image:
tag: latest
containerPort: 8000
kube:
port: 31234
replicas: 1
name: poc-starlingx
EOF
~$ kubectl apply -f helmrelease.yaml
As mentioned, the kubectl
command above creates two resources, first, a
HelmChart resource, which is loaded from the GitRepository.
~$ kubectl get helmcharts
NAME CHART VERSION SOURCE KIND SOURCE NAME AGE READY STATUS
default-poc-starlingx ./helm-chart 1.5.2 GitRepository poc-starlingx 2m41s True packaged 'poc-starlingx' chart with version '1.5.2'
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.
~$ kubectl get helmreleases
NAME AGE READY STATUS
poc-starlingx 3m20s True Release reconciliation succeeded
With the success of the reconciliation, you can see that the application was deployed.
~$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/poc-starlingx-5df9c9947f-7qdss 1/1 Running 0 4m15s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/poc-starlingx NodePort 10.101.7.175 <none> 8100:31234/TCP 4m15s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/poc-starlingx 1/1 1 1 4m15s
NAME DESIRED CURRENT READY AGE
replicaset.apps/poc-starlingx-5df9c9947f 1 1 1 4m15s
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:
kube:
port: 31234
replicas: 5
name: poc-starlingx
Then I run the kubectl apply
command again, and wait for the command line to
to show that the HelmRelease resource was configured.
~$ kubectl apply -f helmrelease.yaml
helmrelease.helm.toolkit.fluxcd.io/poc-starlingx configured
If you run kubectl get pods
, you can see that 4 additional pods were created.
~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
poc-starlingx-5df9c9947f-7qdss 1/1 Running 0 29m
poc-starlingx-5df9c9947f-97lqw 1/1 Running 0 17s
poc-starlingx-5df9c9947f-nzh6b 1/1 Running 0 17s
poc-starlingx-5df9c9947f-r2xj9 1/1 Running 0 17s
poc-starlingx-5df9c9947f-rhjjs 1/1 Running 0 17s
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.