MacOS Malware Outbreaks 2019 | The First 6 Months
July 1, 2019
New KB articles published for the week ending 22nd June,2019
July 2, 2019
After providing credentials and configuration to the plugin it will do the following during your Jenkins job:
- Download ephemeral credentials for your target GKE cluster
- Use kubectl to apply the Kubernetes resources in your workspace
- Wait for the number of replicas you have defined in your Deployment specification to reach the healthy state
Getting started with the Jenkins GKE plugin is easy. First, provide a single set of credentials to the plugin to discover the GKE clusters across your GCP projects. Then, after choosing a project and cluster, configure the path to the manifests in the Jenkins workspace from which you’d like to deploy. You can also optionally define a namespace to deploy your manifests to.
While many deployment mechanisms fire off a kubectl command and hope that Kubernetes realizes their changes successfully, this can lead to many false positives as deployments fail to reach the healthy state. You can configure the Jenkins GKE Plugin to wait for your deployment to enter the desired state by checking the “Verify Deployments” option. For each Deployment manifest that is applied to the cluster, the plugin polls the deployment to ensure that the number of healthy pods matches the requested minimum number of healthy replicas. In the future we hope to add more of this type of logic to verify other types of resources.
Getting started using the graphical interface like we do with the build step configuration above can speed up your initial exploration of the plugin, providing some guard rails and a more intuitive user experience. But in most cases you’ll want to define your application deployment processes in code so that changes can be reviewed, audited, and approved. Thankfully Jenkins provides the Pipeline syntax that lets you define your build, test and release process in a file alongside your source code. Below is an example pipeline that defines a simple rollout process that deploys to a staging cluster, waits for a manual approval from someone in the “sre-approvers” group and then finally deploys to production.
