GitOps as a way of working has dramatically increased in popularity over the past few years. It can be quite a different approach to application and cluster deployments for folks new to storing configuration as code.
Evolving out of DevOps workflows came GitOps: a set of principles to guide your deployment processes based on using Git as a single source of truth. With a Kubernetes controller monitoring your clusters, GitOps compares the system you’ve described in Git to what is actually deployed. A change to your cluster or to your Git repository will automatically trigger an action - notifying you of the change or even self-healing to match your ‘desired state’.
Starting by storing some Kubernetes manifests in your repository, you can build up to defining everything as code; infrastructure, multi-cloud cluster configurations, application and service deployments, whatever you run in Kubernetes you can store as code and keep it in sync with GitOps.
Red Hat OpenShift GitOps is built around the Argo CD project as the declarative GitOps engine that enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. With a gradual adoption of GitOps workflows users can see compounding benefits across their organisation; automating manual tasks, freeing up ops engineers, ‘shifting left’ the deployment process, integrating security policy management into familiar Git workflows and much more.
Version 1.7 of OpenShift GitOps has been released today, bringing with it some exciting new features.
New in version 1.7
Server Side Apply for patching resources:
Server Side Apply (SSA) originated in Kubernetes and has been GA since 1.22 as a flag on `kubectl apply`. Bringing support for SSA to Argo CD, you’re now able to define just the part of an object you’d like to amend and have Argo CD keep it in sync for you. Resources that you haven’t previously been able to manage declaratively can now be patched and monitored for any changes, all from your git-based configuration.
Application resources in any namespace:
Previously, applications could only be created in the same namespace as your Argo CD instance. This was restrictive for teams trying to run a multi-tenant cluster; not being able to install an application across multiple tenant namespaces significantly increased the maintenance burden on the team managing the control-plane namespace. With the latest release, you can now sync manifests to any of the namespaces that you have access to inside your cluster.
For a detailed rundown of everything included in this release, check out the v1.7 release notes.
Argo graduates from the CNCF
The Argo project is the parent project of Argo CD, and as of the 6th of December it is the 20th project to graduate from the Cloud Native Computing Foundation (CNCF). This is a prestigious milestone for the project and signifies a secure and stable project with strong adoption in the community.
“To graduate, Argo met the rigorous standards required of a mature and stable project, including a clear governance and committer process, healthy growth and adoption, and high standards for security and compliance.” - CNCF announcement of Argo’s graduation.
Red Hat is proud to be a core contributor to Argo CD and we are excited to continue to bring it to OpenShift with OpenShift GitOps.
For more information about the Argo project and its graduation, see our graduation announcement.
Where to next?
Version 1.7 of OpenShift GitOps is available now in Red Hat OpenShift - update your operator version, or download GitOps from OperatorHub to try it out. You can deploy and use OpenShift GitOps through the web console or using the CLI.
If you’re looking for more information about GitOps and OpenShift GitOps, the OpenShift documentation is a great place to start with the What is GitOps? topic.
More great resources to learn about GitOps:
If you’ve got any questions get in touch with our Support team, or you can find the GitOps team online in the #argo-cd channel of the CNCF Slack.