11 GitOps: Configuration as code

You may have noticed in this book so far that we’ve been writing a lot of YAML configuration files. It is possible to interact with most Kubernetes objects without writing configuration files using imperative kubectl commands such as kubectl run, and these are arguably easier to learn. So why did I use the declarative configuration-based approach throughout? One reason is that as you take an app to production, you can start treating the configuration like code, with version control and code reviews.

Another reason is it allows you to easily spin up multiple environments with the same configuration. Let’s say you want a staging and a production environment that are as similar as possible for better testing. With your workloads defined in configuration files, it’s possible to replicate the environments easily. Kubernetes has a namespaces feature that makes this possible without needing to worry about name collisions.

11.1 Production and staging environments using namespaces

11.1.1 Deploying to our new namespace

11.1.2 Syncing mutations from the cluster

11.2 Configuration as code the Kubernetes way

11.3 Rolling out safely

11.3.1 Deployment pipelines

11.3.2 Continuous deployment with Cloud Build

11.4 Secrets

11.4.1 String-based (password) secrets

11.4.2 Base64 encoded secrets

11.4.3 File-based secrets

11.4.4 Secrets and GitOps

Summary