[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Improvements to custom deployments



PR https://github.com/openshift/origin/pull/8787 added some
improvements that make running your own custom deployments even easier
than before.

Custom deployments previously allowed you to provide your own image to
handle the deployment logic, but it required you to duplicate a lot of
the code in the deployer in order for that to be effective. As of
#8787, it is easy to specify and override the default deployment logic
and inject your own custom steps.

First, customParams may now be specified for both Recreate and Rolling
deployments.  The customParams override the default behaviors for the
deployer pod - the image, command that is run, and environment
variables.  So you can specify hooks, surge, and max unavailable - but
also alter the execution behavior.

Second, the deployer process (openshift-deploy, which is the
entrypoint of the openshift/origin-deployer image) now accepts a new
argument "--until=".  The value of the argument can either be a state
- "start", "pre", and "mid" - or a percentage representing how far in
the deployment you want to go - "0%", "50%", "99%", "100%", or any
value in between.  When the deployer reaches that point, it will exit
cleanly, allowing you to run your own custom logic

Here's an example of customizing a rolling deployment with a pre hook
to add even more intermediate hooks:

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: custom
spec:
  replicas: 2
  selector:
    name: custom
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: myapp
          command:
          - /bin/echo
          - test pre hook executed
    customParams:
      command:
      - /bin/sh
      - -c
      - |
        set -e
        openshift-deploy --until=pre
        echo Hook is complete
        openshift-deploy --until=50%
        echo Halfway
        openshift-deploy
        echo Finished
  template:
    ...

This deployment will launch the normal deployer image (because we
didn't set image: under customParams) but instead of just calling
"openshift-deploy" (the default) it will run the provided bash script.

That script will instruct the deployer code to run until just after
the pre hook completes.  Since we call "set -e", if the pre hook fails
we'll exit with a non-zero code and the deployment will fail.  We'll
then print "Hook is complete", then restart the deployment process
until we are running at least 50% of the desired new pods (in this
case, 1).  We'll print "Halfway", then run openshift-deploy with no
arguments to run to completion.  If everything goes smoothly, we'll
print "Finished" and then exit successfully.

This is a very simple example, but it opens up *any* scripting you
want to apply.  Since the openshift-deployer image contains "oc", you
can use the oc command to run as the current service account (the
deployer service account) and execute other actions in your namespace.

Here's a script that triggers a complete restart of another component,
every time you deploy:

    set -e
    oc scale dc/cache --replicas=0
    oc scale dc/cache --replicas=5
    openshift-deploy

You can also use exec, for instance if you wanted to clear your memcache fields:

    set -e
    oc exec dc/cache -- /bin/memcachectl --clear-all
    openshift-deploy

You can also wait for a third party service to be up:

    set -e
    for i in `seq 1..100`; do
      sleep 1
      if [[ "$(oc get endpoints svc/cache --template='{{ len .subsets
}}')" != "0" ]]; then
        openshift-deploy
      fi
    done
    echo Timed out waiting for cache service to come up
    exit 1

When you include your own images, the possibilities get even wider.
If you have a common set of deployment scripting, add it as a layer on
top of "openshift/origin-deployer" and then set the "image" field of
customParams.  Or add it to your application image and set a custom
command to launch your scripts.

Please experiment with custom deployments and let us know if there are
improvements that would make them more flexible or easier to manage.
These changes are available in master now, and will be in the upcoming
1.3.0-alpha.1 release.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]