Continuous Deployment to Kubernetes using GitHub triggered Spinnaker pipelines
Last updated
Last updated
Let's learn how to configure Spinnaker v1.19.1 to trigger pipelines based on GitHub commits and inject changed GitHub files as artifacts into the Spinnaker pipeline for Kubernetes Continuous Deployment.
Valid GitHub repository account: This account should have permission to publish commits to prepare a GitHub repository and add some source code to it. It must contain the source code for the artifact.
Spinnaker instance in use
Under the GitHub repository, navigate to Settings -> Webhooks -> Add Webhook.
Update the following values to the form
Payload URL: The Payload URL should be $ENDPOINT/webhooks/git/github
We need Spinnaker’s API running on a publicly reachable endpoint. This is required to allow GitHub’s webhooks to reach Spinnaker. If you’re not sure about what your Spinnaker API endpoint is, check the value of services.gate.baseUrl in ~/.hal/$DEPLOYMENT/staging/spinnaker.yml. The value of $DEPLOYMENT is typically default.
Look at the following Example:
Content-type: The value should be ‘application/json’
Secret: The value is up to you, but must be provided to any GitHub webhooks triggers that you configure within Spinnaker. It’s used to ensure that only GitHub can trigger your pipelines, not an imposter.
Spinnaker can be configured to monitor changes to a GitHub repository. These instructions will walk you through configuring a GitHub artifact account. So that Spinnaker can download files from GitHub.
Credentials Downloading begins by generating a GitHub access token. The token requires the repo scope. Here Create a GitHub access token by clicking the link.
Generate an Access token for your GitHub account, and save the downloaded credentials in 'github token file' TOKEN_FILE=/home/opsmxuser/dvrs/github/github_token_file
Editing Artifact Settings in Spinnaker Config: Enable GitHub artifact support and add an artifact account:
TOKEN_FILE=/home/opsmxuser/dvrs/github/github_token_file ARTIFACT_ACCOUNT_NAME=dvr-github-artifact-act $ hal config features edit –artifacts true $ hal config artifact github enable $ hal config artifact github account add $ARTIFACT_ACCOUNT_NAME –token-file $TOKEN_FILE $ hal deploy apply
Configure Spinnaker pipeline to be triggered by a GitHub commit:
Configure the Spinnaker pipeline to be triggered by GitHub changes and to make deployments on Kubernetes
In Pipeline configuration, click the Configuration stage and Click on Add Artifact under the Expected Artifacts section.
Select an artifact account that was added earlier (3.2) from the Account drop-down list and enter the File Path field.
Select ‘Use Default Artifact’ and specify the artifact account that was added earlier (3.2) from the Account drop-down list and the ‘Content URL’. Here the ‘Content URL’ is used.
Add another Artifact Account for Docker-Registry as an account, as well as the Docker image name that we want to trigger on changes.
Update Automated Triggers details
Click Automated Triggers
In the Type field, select Git.
In the Repo Type field, select Github.
In the Organization or User field, enter the organization value of your Git repository.
In the Project field, enter the Github repository name.
Specify the appropriate branch details for the Branch.
Provide the Secret value that was entered during GitHub Webhook configuration in Section #2.
Select the Display name for Artifact Constraints which was generated in the Expected Artifacts section.
2. Configure Deploy Manifest in Spinnaker pipeline for deployments on Kubernetes
Select the Deploy (Manifest) stage by statistically specifying the manifests.
Make a change into the repository (https://github.com/opsmxorg/samplerepo.git) for specified Filepath(example: manifest.yaml) and ensure Spinnaker’s pipeline is auto-triggered. This can also be verified under Manage Webhook -> Recent Deliveries by checking the Response for 200, which means the Github event (commit) has been processed successfully.
Ensure the Deploy(manifest) stage is executed successfully as shown below:
And see the subsequent result in the Kubernetes cluster as below:
