5 thoughts on “Kubernetes continuous deployment pipeline”

  1. Hi Michael,

    I really like the looks of this plugin. One thing I am wondering about though, is we build everything via packer and provision with chef. How would this fit in to the plugin?

    Thanks,
    Tanner

    1. Tanner,

      I assume you deploy and provision the Kubernetes cluster with Chef and Packer. Is this accurate? The Jenkins deployment pipeline is only for deploying containers and does not provision the infrastructure of the Kubernetes Cluster.

      Michael

      1. Not to be a bug, but did my comment make it through? Last time it said pending, but it appears to have disappeared this time

        1. From Tanner:

          “Right now we are provisioning our cluster with Kops, soon to be terraform. I currently have a slightly automated pipeline setup using Jenkins: it tests the deployment with Chef using Test Kitchen for integration tests, builds the image using packer and then deploys it using a manually configured kubectl. All of this is done via Jenkinsfile and a Github Org folder.

          I want to move to a more ‘pick what you need’ approach, i.e your plugin for the application and environment bitesize files. However, unless I am mistaken, the build part won’t quite work since we don’t create any artifacts other than the image itself, since it is provisioned with chef.

          The thought behind my original question was that I would like to be able to use the build steps, except instead of building an artifact, build the image itself, and be able to deploy that. I’ve read through the code of the plugin a bit and get the feeling this isn’t possible at this time”

          1. Tanner,

            This would be accurate. Jenkins requires the build artifact to add on top of a base image to build the docker image. This allows us to keep the build of any given app separate from the base image. Thus standardizing the base image and simply dropping an artifact on top of it to build an app specific image. I didn’t catch if you are building an artifact for your application like a deb package or if you are simply unpacking something as apart of your docker image build process. If you can provide an artifact to Jenkins, it could then build for you. Currently deb package is required but we hope the community will rally around and add more artifact capabilities.

            In any case, we build an artifact for a few reasons:
            1) because we want our developers to be able to use that artifact elsewhere.
            2) it allows us to standardize everything but the actual application code which is also standardized to run in the proper location on our base images.

            For your testing you could simply have Jenkins call out to Test Kitchen. Or have Jenkins launch a slave with test kitchen on it that will respond back with a non-zero exit code for failures. The Jenkins plugin will do this automatically for you so long as you have test kitchen setup as a dependency.

            Our Deploy pipeline includes everything you need for deploying the containers to multiple environments and thus a manually configured kubectl command to execute this is not necessary.

            Hope this helps. If you are interested in adding functionality to the plugin we would it would be welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *