Here at Kublr we always emphasize how important it is to understand the foundations of Kubernetes (K8s) and its operations tools so you can more efficiently manage your applications and simplify your cloud-native development workflow.
Understanding these components on the front end is equally important as we begin our build processes, especially when building with an everything-as-code approach. Everything-as-code allows you to manage your applications and deploy containers using code and cloud-native technology.
From understanding CI/CD methodology to knowing which dilemmas you might encounter, there are important pieces of knowledge that make your life easier when starting your everything-as-code projects. Read on for an overview of important components of the everything-as-code approach.
The basic architecture of CI/CD process and tools
Continuous Integration (CI) and Continuous Delivery (CD) are methods at the core of DevOps. CI/CD tools can automate your integration, delivery and deployment of your applications. Here’s how they work.
In your build project, you begin with the Git Repository. This is responsible for tracking all changes that happen in a project file. A CI tool watches the Git Repository to notice if there are any changes. When it notices a change, the CI tool builds binary artifacts and stores them in binary artifact’s registries and repositories. In K8s, the most important registry is Docker Registry where Docker images are stored.
CI tools can also deploy freshly– built application binaries to development environments. However, it often makes more sense to use CD development tools if you want to propagate those builds to QA production automatically.
This brings us to the question: What’s the difference between CI and CD tools?
Mature processes usually call for CD tools over CI tools. CD tools allow you to implement more complex and interactive process flows for application propagation between environments. For example, a complex process might be establishing a step that requires manual approval from an administrator after QA or including manual QA testing in the staging environment. These are usually done through the CD delivery pipeline.
Using these tools to build everything-as-code ops stack
CI/CD processes and tools enable you to build a full-stack using an everything-as-code approach.
In an everything-as-code project, you can build a project that formally describes the environment, infrastructure and system components like Jenkins, Nexus, ArgoCD and more. You can build scripts embedded into a Docker file that generates a binary artifact that’s executable, wrapped into a container and pushed into the binary repository. Another set of artifacts necessary to deploy containerized applications in K8s usually includes K8s manifests templates (Eg. a helm package or customize package). In the end, you’ll have a formal description of the K8s deployment model for your project. You will also have a cluster spec that gives a full description of your system, application and DevOps practices that are alive, self-caring and self-documenting.
If you want to learn more about how to build an everything-as-code project, check out this tutorial.
Dilemmas you will encounter when building an everything-as-code project
There are build process dilemmas and difficulties you’ll encounter when building and executing an everything-as-code project. Here are some things you need to consider:
If you’ll use monorepo or multi-repo
Consider this especially if you have multiple components and microservices. Both monorepo and multi-repo have pros and cons.
How you’ll manage dependencies
First, consider how you define dependency. Then decide which dependencies you want to embed into your project. For example, you may want to consider if you’ll include helm package dependencies into your source base or if you’ll rely on remote repositories that contain those dependencies.
Hermetic repeatable builds and local development
This can often be a source of additional complexity for smaller projects but will significantly simplify management of larger and more complex projects. Consider early on if or when you will make builds hermetic and fully repeatable using build tools like Bazel.
How you’ll implement Don’t Repeat Yourself (DRY) principles
When developing build scripts, it’s a good practice to make sure that your scripts build on each other from layer to layer. This ensures that your build scripts will work on a local environment for developers, allowing them to fully build your application locally.
As an example, when building a Docker image, you should use the same build scripts that are used for local builds. Jenkins pipeline should use the same build scripts as the docker images and therefore, use the same build scripts people use for local scripts.
It’s worth taking the time to learn these processes.
It can seem like a lot of work on the front end to understand these processes and think through potential dilemmas you may encounter. But understanding these issues will give you a more comprehensive view of how your containers are orchestrated and how your applications are managed. This knowledge can prevent headaches and confusion throughout your building process when issues arise and changes need to be made.
If you are curious how you can use a K8s management platform to assist your everything-as-code projects, contact Kublr.