Skip to content
Securely manage Docker, Swarm, Kubernetes and Podman clusters in the cloud, on-premise, and in the data center.
Secure app deployment and device management for your Industrial IoT, IoT and Edge devices.
Let Portainer's Managed Platform Services accelerate your containerization journey.
Manage all your Docker, Swarm, Kubernetes and Podman clusters from a single secure interface.
Portainer empowers Platform Engineering teams to deliver efficient, user-centric services.
Empower your business by adopting containerization the easy way with Portainer.
Deploy to and manage your fleet of remote devices centrally and securely.
Onboard, manage and deploy workloads across hundreds of devices securely with Portainer.
Deployment scenarios
Partner Solutions
blog-banner
DimkoDecember 15, 20211 min read

GitOps in a nutshell

TicketOps, DevOps, GitOps, SecOps - what are they? Have we come to the point when these acronyms do not make any sense?

At least, a few of them do make sense. We are going to look at GitOps today - a very fresh way of deploying our software.

Essentially, that's how you reliably and repeatably take a piece of software into a particular environment while collaborating with other people working along. But how that look in practice?

In practice, you have a recipe to make GitOps happen:

  1. Git repo to store your manifest about the application to be deployed
  2. An environment where you want the application
  3. A tool in the environment that is able to go to Git repo and take the manifest from there to an environment

 

 


If you take Kubernetes, you would have to store a Kubernetes YAML manifest in the Git repo, and have a tool that would repeatedly pull that manifest to check whether it has something to deploy onto the Kubernetes.

If you take Docker Swarm, you would have to store a docker-compose.yaml in the Git repo and have a tool that would pull from the repo and apply that compose file onto Swarm.

This is exactly as simple as keeping the desired state of the application deployment in the Git repo. As we update that deployment state in the Git repo, it updates in a particular environment.

That gives us the ability to collaborate with our peers on that manifest using Git workflows - pull requests to change the version of the image in the cluster or add an extra LoadBalancer. It's the way for software engineers to collaborate on their deployments using the good old instruments they know - Git, PRs, comments, history, rollbacks, and so on. With this approach, there is no need to go deep on deploying the software to an environment, since the GitOps tool will do that for you. Not everyone needs that, but almost everyone needs a way to deploy their build artifacts in a safe, repeatable, and reliable way.

We've been working tirelessly to give everyone that ability to deliver software in a reasonably simple manner. I think we nailed it with our latest 2.9+ releases. In the next part of this series, we'll go over Portainer's take on GitOps.

GET 5 NODES OF PORTAINER BUSINESS FREE

Dimko

Dimko

COMMENTS

Related articles