Author | Lin Jun (Wan Nian) source | Erda Erda public number
Start with a short story
You are a senior development engineer.
One day, you confidently write code for autobrew coffee and debug it locally. After the code is merged into the main trunk branch, you are ready to publish the service to the test environment and enter the roll-out process.
You opened the project collaboration expertly, created a release work order for the operation and maintenance students, specified the code branches to be released in detail, and emphasized that this time, a special environment variable switch AUTO_MAKE_COFFIE_ENABLED=true should be added.
After a period of time, the work order processing is completed, the test students began to test.
Suddenly, the bad news comes: there are several bugs in your project collaboration.
Why, you wonder, is there so many bugs in the test environment when code that works perfectly locally?
You begin to suspect that there is a problem with the logic somewhere in the code. After careful investigation, but still can not locate the problem.
Finally, you realize that the operations student copied the environment variable with a missing letter: AUTO_MAKE_COFFIE_ENABLE=true, ENABLED with a missing D.
Is this situation familiar? It’s not your pot, but it’s slowing you down to be a programmer 10 times over.
So how can you avoid it?
You must be thinking: if only there were no manual copying. You need a place to save your configuration, but you don’t have the permission and don’t want to log in to the o&M platform and paste it yourself.
You have an Epiphany: If you agree on a configuration file with the o&M student, submit the deployment configuration into the code, and the o&M student reads the application environment configuration from the file, the problem is solved.
What is the IaC
In the above story, the specified configuration file is part of the application infrastructure (I in IaC).
What are we to make of infrastructure? For a more complex application, only the code will not be able to run, because it has many environment dependencies that need to be accurately described, such as the command line tools specified by make, Git, etc., and the middleware dependencies, etc.
Therefore, when implementing continuous delivery, the product team must consider the maintenance of infrastructure as part of supporting the operation of the product. At the same time, the rapid progress and evolution of technology also makes the configuration of infrastructure have to change frequently. In this process of rapid change, infrastructure is required to be flexible as well as secure and reliable.
IaC Infrastructure refers to the IaaS layer of Infrastructure, including physical servers, virtual machines, and related resource definitions. As Code means that these configurations should be managed on VCS.
The nice thing about As Code is that you can take advantage of the natural benefits of version management, making it easy to do rollbacks and so on.
When you maintain Code in Git, it’s called GitOps. Interested students can search for GitOps articles to learn.
So, what should Code look like in As Code? This format is determined by the specific automation platform. As for the type of Code, it can be both declarative and directive. For example, common Ansible is generally directive, while Terraform is declarative. Of course, declarative definitions are preferred because they are end-state oriented and are more developer-friendly without implementation details.
How is app-centric IaC different in the cloud native era?
Fast forward to the cloud native era.
With the general trend of cloud on services, the concept of infrastructure is no longer limited to the IaaS layer. In the cloud native era, developers are increasingly focusing on applications. Namely: application-centric.
The widespread adoption and acceptance of concepts such as continuous integration, continuous deployment, and DevOps requires greater ownership of deployment and operations by product teams.
First of all, in today’s DevOps era, it’s not enough for a developer to just write good code, it’s just good Dev. The real life cycle of software delivery begins with Ops, and the operation and maintenance students are no longer responsible for application deployment and operation and maintenance, which are the business of developers.
The advent of Docker has made image delivery the de facto delivery standard for most applications. So, there needs to be a file in your application that defines how to make an image of your code, and this file is usually a Dockerfile.
At the same time, the popularity of the PaaS platform means that developers don’t even need to care about Dockerfiles. Because the PaaS platform automatically probes and selects the right build from your application directory structure and feature files, this process of compiling code and building images is called BuildPack. Of course, before compiling, you may need to do some code quality checks, compliance checks, etc. These processes need to be declared in a process description file. On different PaaS platforms, there are different declarations.
How to make IaC better in Erda DOP
Erda is an application-centric enterprise one-stop digital PaaS platform.
DOP, or DevOps Platform, is an application-centric, one-stop DevOps Platform.
An Erda application supports code quality scanning, code security scanning, unit test execution, image security scanning, continuous deployment, interface automation testing, and more after the image is created. These processes are used to manage the entire application life cycle.
On this platform, you can define the CI/CD flow of your application using pipelines.yaml. Obviously, the pipeline.yaml is part of the application infrastructure.
At the same time, you need to use a declarative Erda.yaml to describe your application microservices architecture, including dependencies between microservices, dependencies on middleware, and so on.
From the beginning of the platform design, we abstracted it so that it could be deployed to any platform, including K8s, DC/OS, etc., shielding developers from implementation details.
Therefore, these two files are essential when the application is deployed on the Erda PaaS platform.
It is worth mentioning that in the earliest days of the platform, we only had an erda.yaml file that put the microservices architecture and build process together. In practice, we gradually realized that this approach was not scalable enough and it was difficult to customize the process. In addition, the imperative and declarative forms are coupled in the same file, and the user’s mental switching costs are higher.
In addition, we support defining API description files in the.erda directory to manage the full API lifecycle.
Once the Infrastructure is submitted as Code, the Erda platform can integrate and deliver the entire application automatically based on the configuration.
In the case of Erda itself, continuous integration, automatic release, etc., are bootstrapped on the Erda platform. The screenshot of erda.yaml is as follows:
The screenshot of pipeline.yaml for CI is as follows:
When your app is a standard, IaC makes it easy to deliver the app to customers. All you have to do is push the repository complete to the new application repository and then pipeline it. After execution, a complete application is delivered to the new customer environment. The developer then customizes the new application, submitting the changes to code for version control as the application’s infrastructure changes.
conclusion
You build it, you run it.
So infrastructure-as-Code (IaC) is at the heart of the cloud native developer experience.
With IaC, you, as a developer, finally have more control over the full life cycle of your app.
Welcome to open source
As an open source one-stop cloud native PaaS platform, Erda has platform-level capabilities such as DevOps, micro-service observation governance, multi-cloud management and fast data governance. Click the link below to participate in open source, discuss and communicate with many developers, and build the open source community. Welcome to follow, contribute code and Star!
- Erda Github address:https://github.com/erda-project/erda
- Erda Cloud official website:https://www.erda.cloud/