Blue-green deployment is a method of safely deploying applications by providing two versions of the application to run concurrently. In order to deploy a new version of the application, you need to switch the current version to the new version, and then close the old version. Blue-green deployment does not take your application out of service, allowing you to quickly roll back your application to the blue version if necessary.
This article briefly describes the process
http://martinfowler.com/bliki/BlueGreenDeployment.html
In a production environment, you may have used scripts to integrate this process into your existing system. Below, we provide an example that uses the DCOS CLI to provide a secure deployment. (DCOS CLI can be used with DCOS and open source marathon)
Prepare
Marathon-based applications have precise health monitoring
applications may expose an indicator endpoint to detect if the application has any unfinished operations. For example, detecting the number of transactions waiting for the database , etc.
jq command line json processor
If you are using open source mesos, you need to configure DCOS CLI
step
We will replace the BLUE version of the app with the GREEN version of the app.
1. Load a new version of the application in marathon and add a unique ID to the application name, such as Git 's commit id. In this example, we add a new version number to the application by adding GREEN to the name.
# launch green
dcos marathon app add green-myapp.json- 1
- 2
- 1
- 2
Note: If you use the API instead of the DCOS CLI, this command will be very long:
curl -H "Content-Type: application/json" -X POST -d @green-myapp.json <hosturl>/marathon/v2/apps- 1
- 1
2. GREEN application instances can be scaled to one or more. Initially (starting with 0 instances), set the minimum number of application instances based on the services provided.
# scale green
dcos marathon app update /green-myapp instances=1- 1
- 2
- 1
- 2
3. Wait until all tasks of the GREEN application provide health checks. This step requires jq .
# wait until healthy
dcos marathon app show /green-myapp | jq '.tasks[].healthCheckResults[] | select (.alive == false)'- 1
- 2
- 1
- 2
4. Use the above code snippet to check if all GREEN instances are still healthy. If your expected results are not achieved, you can terminate the deployment and roll back.
5. Add a new task instance from the GREEN application to the load balancing pool.
6. Obtain one or more task instances from the current version (BLUE version) of the application.
# pick tasks from blue
dcos marathon task list /blue-myapp- 1
- 2
- 1
- 2
7. Update the load balancing configuration and delete the task instance from the BLUE application pool.
8. Wait until the BLUE task instance has no pending operations. Application-provided indicator endpoints detect the number of pending operations.
9. Until all operations of the BLUE task are completed, use the API to close the BLUE application. In the code snippet below, hosturl is the hostname of your master node, prefixed with http://.
# kill and scale blue tasks
echo "{\"ids\":[\"<task_id>\"]}" | curl -H "Content-Type: application/json" -X POST -d @- <hosturl>/marathon/v2/tasks/delete?scale=true- 1
- 2
- 1
- 2
This marathon operation will remove the specified instances (those that have no pending operations) and prevent them from being restarted.
10. Repeat steps 2 through 9, specifying tasks without BLUE.
11. Remove the BLUE app from marathon.
# remove blue
dcos marathon app remove /blue-myapp- 1
- 2
- 1
- 2
Original: https://mesosphere.github.io/marathon/docs/blue-green-deploy.html
http://blog.csdn.net/zhuchuangang/article/details/51064974