Flux is a CNCF based open source stack of tools. Flux focuses on making it possible to keep Kubernetes clusters and cloud-native applications in sync with external resources and definitions hosted in environments such as GitHub.

 Implementing tools like FluxCD should enable you to achieve results such as:

• Code changes are atomic and transactional
• Have Git as your source of truth
• Use a code-centric approach as part of your DevOps lifecycle

The results above can bring obvious benefits, and many teams are adopting FluxCD as their tool of choice for GitOps. 

Despite the above, once implemented, it’s pretty common to see DevOps teams looking at addressing additional requirements such as:

• Leverage FluxCD to deliver applications across multiple clusters.
• Enforce policies across multiple clusters, environments, and projects in a scalable manner
• Integrate into the organization’s Active Directory/SSO
• Give developers an application platform to help them support their applications
• Create application-centric definitions to help developers leverage GitOps and speed up adoption

As your GitOps journey progresses, you will eventually need to address the points above to drive significant adoption.

The video below discusses an option you have on leveraging Shipa to drive your FluxCD adoption to an enterprise-level quickly, improve policy implementation and reporting, and improve developer experience:

Let’s quickly go over some of the details discussed in the video above:

GitHub Repository Structure

There are undoubtedly different ways you can structure your GitHub repository and have Flux leverage it.

As part of this video, we have structured it this way:

• An infrastructure repository
  • The focus is on the application infrastructure, where we store our policies, RBAC, clusters, and more.
  • We created it as a separate repo, so DevOps or Platform Engineering teams can manage this.
• An application repository
  • We have created two different folders in the same repo, one for each application, but this can be structured differently to allow distributed teams to have a separate repository structure.

You can find an example of the Git repository for the infrastructure part here.

Shipa Cloud Account

Creating a Shipa Cloud account is free, and you can get started here.

You can replicate the content of this video using your free account.

Shipa Provider and FluxCD

For this example, we decided to leverage Shipa’s Crossplane provider and connect FluxCD to it. The reason why we did is that:

• Users can further extend their automation and use Crossplane to provision clusters and infrastructure.
• With all three solutions combined, you have a robust GitOps platform. From storing your definitions as code in Git to an application platform where you can consolidate application, security, and operational information, you deliver a platform that allows you to scale.

You can find detailed information on how to install Crossplane and the Shipa provider here.

Policy as Code for GitOps

Through Shipa, you can quickly define and automatically enforce policies at the application level, using a scalable model.

You can plug Shipa’s policy as code into different pipelines and infrastructure as code (IaC) tools. One of the strong points of this approach is to plug a standard policy definition across other pipelines and tools, creating a repeatable, manageable, and scalable process, which you need to deliver as you scale.

You can define policies across RBAC, networking, registry, and more. You can monitor your policies using Shipa’s dashboard, add alerts for policy changes, and more.
You can find further information on defining policies using Crossplane, and other IaC providers, here.

Multi-Cluster Application Deployment

As you scale, one of the expected points you need to address is effectively managing policies and application deployments across multiple clusters with Flux.

Since we have Flux working with Shipa, scaling across multiple clusters is no longer a challenge. Flux will communicate with Shipa and tell Shipa which policies need to be created and which clusters and namespaces they need to be bound.

Shipa will then handle policy creation and enforcement for that namespace in the cluster. As your team deploy applications through the combined Flux and Shipa solution, one of the application definition fields is the framework these applications should be bound to. 

With that, when FluxCD sends the request to Shipa, based on the framework used for the application, Shipa will know where to deploy the application, the underlying cluster provider and version, and automatically create the required objects to deploy the application.

Post-Deployment Support

This is a point teams don’t pay much attention to when they are starting in their journey, but it becomes a key pain point as they scale the number of applications and users in the platform.

Often, we see teams reporting challenges such as:

• Developers have a hard time understanding and supporting their applications post-deployment. Since their applications become several objects in the cluster, understanding the object dependency, status, and details becomes complex, and the request for help comes back to the DevOps team.
• At this point, you have heard that kubectl is the new ssh, and without the proper user controls, it can be risky to have your developers with kubectl access.
• Git may be your “source of truth,” but using it as you scale to 100s of services and developers, finding who did what and when, the outcome, the log associated with that action, and more will become ridiculously time-consuming.
• If you are implementing a DevSecOps practice, giving centralized information across policies enforced, application changes, deployments, users, and more is another challenge to add to the list.

Those are points Shipa Cloud will help you solve. With centralized information consumed by developers, SREs, DevOps, and DevSecOps, you now have an operational application model that can scale.

SSO Integration

It might sound obvious, but one point you will need to address is integrating your platform into your company’s Active Directory.

By connecting FluxCD with Shipa, the authentication will be handled by Shipa, which will then validate your user’s permissions and allow them to perform whichever actions they are allowed to perform.

Shipa offers SSO and can connect through SAML, for example, to your Azure Active Directory.

Extending the Approach

One of the final points the video talks about is integrating applications with your incident management systems. By giving application owners this capability to do it easily, you plug Shipa into your existing stack, which will drive faster adoption inside your organization.

You can also create further hooks and leverage additional external platforms to consume data created by Shipa. One example is, every time there is a change to a policy, new policies are created, users are added, and more, Shipa can send a call to external apps to alert you of these and further actions.
You can find detailed information about webhooks on Shipa here.

Conclusion

I hope this was helpful to understand how you can deliver critical wins for users across development, DevOps, DevSecOps, and SRE.

By delivering on the premises above, you also enable a better experience across the teams above and drastically increase the chance of users adopting your platform and initiatives while providing a scalable platform.