Author | Lin Jun (Wan Nian) source | Erda Erda public number
Let’s start with a short story
You are a senior development engineer.
One day, you confidently write the code for auto-brewed coffee and debug it locally. After the code is merged into the main branch, you are ready to publish the service to the test environment and enter the test promotion process.
You skillfully turn on project collaboration, create a new release work order for the operations team, specify the branch of code that needs to be released, and specifically emphasize the need for a new environment variable switch AUTO_MAKE_COFFIE_ENABLED=true this time.
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, are there so many bugs in the test environment when the code runs perfectly locally?
You begin to suspect that there is something wrong with the logic somewhere in your code. But after careful investigation still can not locate the problem.
Finally, you realize that it is the Operations student who copied the environment variable with one missing letter: AUTO_MAKE_Coffie_enable =true and ENABLED with one missing D.
Does this sound familiar? It’s not your fault, but it slows you down as a tenfold programmer.
So how do you avoid it?
You must be thinking: If only there were no manual copying operations. There needs to be a place to save your configuration, but you don’t have permissions and don’t want to log in to the Ops platform and paste the configuration yourself.
You have an Epiphany: if you agree to a configuration file with the operation and maintenance students, the deployment configuration is also submitted to the code, and the operation and maintenance students read the application environment configuration from the file, the problem will be solved.
What is the IaC
In the above story, this particular contracted configuration file is part of the application infrastructure (I in IAC).
What do we make of infrastructure? A slightly more complex application, only the code is unable to run, because it has a lot of environment dependencies need to be accurately described, such as the need to run the environment have make, git and other specified command-line tools, which middleware depends on, etc.
Therefore, when implementing continuous delivery, product teams must consider the maintenance of the infrastructure as part of supporting product operations. 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, but also safe and reliable.
IAC Infrastructure refers to the Infrastructure of the IaaS layer in a broad sense, including physical servers, virtual machines, and related resource definitions. As Code means that the configuration should be managed on the VCS.
The nice thing about AS Code is that you get the natural benefits of versioning, and it’s easy to do rollbacks and things like that.
When you maintain Code in Git, it’s called Gitops. Interested students can search GITOPS related articles to learn.
So, what should Code look like in AS Code? This format depends on the specific automation platform. As for the type of Code, you can use either directive or declarative. For example, the common Ansible is generally directive, while the Terraform is declarative. Of course, a declarative definition is preferred because it is an end-state oriented definition and is friendlier to the developer by shielding the implementation details.
How is application-centric IAC different in the cloud native era?
Fast forward to the cloud native era.
In the general trend of the 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 apps. That is: application as the center.
The widespread adoption and acceptance of the concepts of Continuous Integration, Continuous Deployment, and DevOps requires greater ownership of deployment and operations by product teams.
First of all, in today’s DevOps concept, it’s not enough for a developer to just write good code, it’s just to do a good Dev. The real life cycle of software delivery starts with OPS. Operations students are no longer responsible for the deployment and operation of the application, which is the developer’s responsibility.
With the advent of Docker, mirroring delivery has become the de facto delivery standard for most applications. Therefore, an application needs to have a file that defines how to mirror your code. This file is usually called a Dockerfile.
At the same time, the popularity of PaaS platforms means developers don’t even need to care about Dockerfile. Because the PaaS platform automatically detects and selects the appropriate build from your application’s directory structure and characteristics files, this process of compiling and mirroring the code is called BuildPack. Of course, you may need to do some code quality checks, compliance checks, etc., before compiling. These processes need to be documented in a process description document. On different PaaS platforms, there are different ways to declare.
How to make IAC better in Erda DOP
ERDA is an application-centric, enterprise-level, 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, and, once the image is made, image security scanning, continuous deployment, interface automation testing, and more. The full life cycle of the application is managed through these processes.
On this platform, you can use PIPELIN.YAML to define the entire CI/CD flow of your application. 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 the dependencies between the microservices, the dependencies on the middleware, and so on.
At 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 the implementation details.
Therefore, these two files are essential when an application is deployed on the Erda PaaS platform.
It’s worth noting that in the early days of the platform, we only had a single erda.yaml file that wrote the microservice architecture and the build process together. In practice, we gradually realize that this approach is not scalable enough and difficult to carry out process customization. Moreover, both the imperative and declarative forms are coupled in the same file, and the user’s mental switching costs are higher.
In addition, we also support defining API description files in the.erda directory to manage the full API lifecycle.
Once the Infrastructure is committed as Code, the Erda platform can continue to integrate and deliver based on the configuration, and finally automatically deploy the application completely.
In Erda itself, for example, continuous integration, automatic release, etc., are bootleded on the Erda platform.
The screenshot of the Erda. Yaml section is as follows:
The screenshot of the Pipeline.YAML section for CI is as follows:
When your app is a standard, it’s very easy to deliver it to customers with IAC. All you have to do is push the repository completely into the new application repository and then execute the pipeline. After execution, a complete application is delivered to the new customer environment. The developer then customizes the new application and commits the changes to the code for version control when the application infrastructure changes.
conclusion
You build it, you run it.
So let’s say that infrastructure as code (IAC) is at the heart of the developer experience in the cloud native era.
With IAC, you, as a developer, have a better grasp of the full life cycle of your application.
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 an open source community. Everyone is welcome to follow, contribute code and STAR!
- Erda Github address:https://github.com/erda-project/erda
- Erda Cloud Website:https://www.erda.cloud/