WordPress is a popular platform for editing and publishing content for the web. This tutorial will walk you through how to build out a WordPress deployment using Kubernetes, ArgoCD, Crossplane, and Shipa. WordPress consists of two major components: the WordPress PHP server and a database to store user information, posts, and site data. We will define these two components and store them in a Git repository.
GitOps. The term appears everywhere, but what are its benefits? And is it as difficult as it sounds? Well, GitOps is a pretty easy paradigm to integrate with your current processes. However, my saying it is “easy” doesn’t help you decide whether you want to adopt it or not. So, let’s talk about it.
Infrastructure-as-apps builds on infrastructure-as-code to a logical endpoint by bringing in principles of GitOps management. The term is something I coined in 2021 to describe an existing movement to bring infrastructure into the same lifecycle control as applications under GitOps. Examples of Infra-as-apps tools include Argo CD, Crossplane, Cluster API, Cello, or even SchemaHero for databases and the list is always growing. Some of the benefits of infra-as-apps include Read on to understand why.
Within this blog post, we’ll be highlighting some best practices tied to Argo CD, that allow you to leverage GitOps easily within your deployment workflow.
Two of the most important questions that people ask themselves on day 2 after adopting GitOps are: In the previous article of the series, I focused on what NOT to do and explained why using Git branches for different environments is a bad idea. I also hinted that the “environment-per-folder” approach is a better idea. This article has proved hugely popular and several people wanted to see all the details about the suggested structure for environments when folders are used.
Imagine a workflow where you change and test all of your configurations in the “development” environment, committing those changes along the way, and then when you’re happy with the changes, you bundle them together in a single “pull request”, and the changes, after being reviewed by your peer(s), get pushed into production.
Today we are going to explore getting started using Argo CD. This post is going to assume you know a bit about containers, and that you already have an empty cluster in place (or know how to create one). If any of this is unfamiliar, head over to Understanding the Basics to get a bit of practice. Before we get started, let’s talk about GitOps.
As open-source software evolves and grows, it’s important that organizations, both large and small, can scale to keep up with their end user’s needs. At Codefresh, we are announcing a new release of our platform, Codefresh Software Delivery Platform, powered by Argo (CSDP) which delivers a scalable deployment management platform with Argo. Some of the major new features include the following support: These are some of the major new features in Codefresh’s new platform.
One of the major components of the Codefresh Software Delivery Platform is the Workflows capability that allows you to define any kind of software process for creating artifacts, running unit tests, running security scans, and all other actions that are typically used in Continuous Integration (CI). At first glance, Codefresh Workflows might look like the typical pipelines that you would find in any popular CI product but if you look under the hood you will realize looks can be deceiving.
There is a lot of the art of the possible between the GitOps Engine, Argo CD, and the Application-as-Code platform, Shipa. In a recent blog post, we outlined the power of a one-line developer experience. Though if you are unfamiliar with ArgoCD, here is a guide to get you started with Argo CD and leveraging Shipa for your first deployment.
