A variety of tools are available to help us meet the challenges, but I chose Kubernetes as it's well tested, reliable, and open source. The way you run your servers, manage their configurations, and orchestrate them can hugely impact the success of the project. If everything goes well, the Docker image can be deployed to the Production environment using the same infrastructure as other environments.
#Building microservice systems with docker and kubernetes code
Consistency saves time and makes it easier to test deployment code in other environments rather than Production. Keep all the deployment steps similar, except for some configurations (that are read from the repository). We run End-to-End tests on the application in the Dev environment, after which it is deployed to the QA environment where our testers can test the integration with other external systems manually. The scripts are kept under VCS and in most cases Bamboo just checks out the project and runs the specified shell/python scripts.
I prefer to write scripts instead of configuring the Bamboo through its UI. It also promotes containers from Dev to QA and then to Production with no changes. It runs different types of tests, code metrics, produces artifacts, creates and publishes a Docker image tagged with the name of the application and build number. The build server takes advantage of changes applied so far and provides our CI/CD pipeline. Build Server-Setting Up Our CI/CD Pipeline To facilitate the identification of images, they are tagged with application name (or repository name) as well as the build number. The application expects to find the configurations/properties in a specific location outside of its packaged artifact.Īfter running initial tests (e.g., unit tests), a Docker image is generated that includes our application artifacts (no configuration is packaged with the image). This helps us generate an immutable artifact and then promote it to different environments (likely with different configurations) without any change to the artifact itself. In a typical modern environment, the application prints the logs to the console and we configure the standard output of the server to redirect the logs to our favorite logging infrastructure like Elasticsearch.Ĭonfiguration and credentials related to our environments (Dev, QA, etc.) should be maintained in a separate repository they should not be packaged within the application artifact. Application-One Immutable Artifact for Different Environments This helps us automate things and roll back changes when required.Ĭode and application configurations should be placed into two separate repositories. This could be code, application property files, SQL changes that you've applied as part of a deployment, environment variables, or basically anything that’s important to build and run the application properly. Key Components Version Control System-The Single Source of TruthĪny data required for packaging, deploying, and running the application should be tracked by the VCS. They are cattle not pets!Īs part of implementing a microservice architecture for a client, I built an on-premise CI/CD pipeline with Kubernetes and here is a summary of my thoughts. In a modern CI/CD pipeline, you don't fall in love with your server as a new one can be built and up and running in minutes, reflecting every working change in the project.
0 kommentar(er)
