Codelabs on Spinnaker

App Engine: Source to Prod

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial is deprecated and no longer supported, but left for reference. Halyard is no longer supported or maintained

Overview

This codelab provides an overview of Spinnaker’s integration with App Engine. You’ll build and run a simple App Engine deployment pipeline with the following steps:

Prerequisites

Be sure you have your Google Cloud Platform project’s ID. This value will be referenced as GCP-PROJECT-ID below.
Be sure you have gcloud installed, and that it is authenticated with your GCP project. In most cases, this should only require running gcloud auth login <your@email.com> and following the instructions in the prompt. If you don’t have gcloud installed locally, you can always run gcloud from inside Cloud Shell, which you can open from your GCP console.
Be sure you have the App Engine Admin and Compute Engine APIs enabled for your GCP project:

gcloud services enable appengine.googleapis.com
gcloud services enable compute.googleapis.com

If this is your first time deploying to App Engine in your project, execute the following command to create an App Engine application. You cannot change the region, so choose wisely: gcloud app create --region <e.g., us-central>.

Configuration & installation

We’re going to trigger our Spinnaker pipelines using Github webhooks. In order to do so, we will have to expose Spinnaker’s API gateway to external traffic. If you are going to use this installation beyond this codelab, you should follow the guides for securing Spinnaker.

Azure VM Scale Sets: Source to Prod

Mon, 01 Jan 0001 00:00:00 +0000

In this codelab, you will create a source-to-prod continuous delivery pipeline for a simple java based application targeting VM Scale Sets in Azure.

After completing this lab the following workflow will happen:

A developer pushes a commit to Github
Jenkins automatically builds a Debian package and pushes it to an Aptly repository
Spinnaker bakes the new package into an image
Spinnaker deploys to a test environment and disables the previous deployment
Spinnaker waits for a manual judgement of the test environment
Spinnaker deploys the image to the production environment and disables the previous deployment.

This codelab will walk through the following steps to implement this scenario:

Bake and Deploy Pipeline

Mon, 01 Jan 0001 00:00:00 +0000

VM only: This codelab requires you have a VM (for example, on AWS or GCP) on which to run it.

For Kubernetes, try Kubernetes Source-to-Prod ,

To walk you through some of the basics with Spinnaker, you’re going to set up a Spinnaker pipeline that bakes a virtual machine (VM) image containing redis, then deploys that image to a test cluster.

Note here that the us-east-1a availability zone is currently full, so it will need to be deselected in the corresponding ‘region’ checkbox list for each of these steps.

Continuous Delivery to Kubernetes on Oracle

Mon, 01 Jan 0001 00:00:00 +0000

In this codelab you will configure a Spinnaker pipeline to deploy an application from Kubernetes manifest files targeting Kubernetes on Oracle Cloud Infrastructure Container Engine (OKE).

Prerequisites

Before we begin, we need to do the following:

Configure Kubernetes

If you don’t already have a cluster for this purpose, you can follow this tutorial until a Kubernetes cluster on OKE is created.

Create a compute instance

Create a compute instance on Oracle Cloud Infrastructure (OCI) to host Spinnaker by following these instructions . Spinnaker supports Ubuntu 18.04 or higher.

DC/OS: Source to Prod

Mon, 01 Jan 0001 00:00:00 +0000

0. Setup

Prerequisites

Github repository with the source code to deploy
Enterprise DC/OS cluster (1.8 or greater)
- Marathon-lb is should be installed and running
- For the examples in this codelab we’ll say that it’s at https://dcos.example.com so you should replace that with the URL to your cluster
Jenkins instance
- This can be installed on your DC/OS cluster as a Mesosphere Universe package

Configure Spinnaker

clouddriver-local.yml

dcos:
  enabled: true
  clusters:
    - name: codelab-cluster
      dcosUrl: https://dcos.example.com
      insecureSkipTlsVerify: true
  accounts:
    - name: codelab-dcos-account
      dockerRegistries:
        - accountName: my-docker-registry
      clusters:  
        - name: codelab-cluster
          uid: ${DCOS_USER}
          password: ${DCOS_PASSWORD}
dockerRegistry:
  enabled: true
  accounts:
  - name: my-docker-registry
    address: https://index.docker.io
    repositories:
    - lwander/spin-kub-demo
    username: ${DOCKER_USER}
    password: ${DOCKER_PASSWORD}

Enable Docker

Configure a docker registry

Deploy Artifacts from Artifactory to CF

Mon, 01 Jan 0001 00:00:00 +0000

In this codelab, you will deploy an artifact to Cloud Foundry via a Spinnaker pipeline. The pipeline is triggered by an artifact published to a JFrog Artifactory Maven repository or by an app manifest stored in a GitHub repository.

Prerequisites

This codelab assumes you have the following:

Artifact support enabled .
An Artifactory repository configured to accept a Maven artifact—the JAR for your application
A GitHub repository containing a manifest with which to deploy your application

1. Add Artifactory Search to Spinnaker

a. Enable the Artifactory repository:

Deploy GCS Pub/Sub Artifacts to Google App Engine

Mon, 01 Jan 0001 00:00:00 +0000

The goal of this codelab is to trigger a Spinnaker pipeline with a Pub/Sub message from GCS upon upload of a tarball.

In this codelab, you will deploy artifacts to Google App Engine (GAE) via a Spinnaker pipeline. The pipeline is configured to trigger on Pub/Sub messages from a GCS bucket serving as an artifact repository. The Pub/Sub messages contain context that allows Spinnaker to parse and deploy the stored artifacts.

Deploy GCS Pub/Sub Artifacts to Cloud Foundry

Mon, 01 Jan 0001 00:00:00 +0000

In this codelab, you will deploy an artifact to Cloud Foundry via a Spinnaker pipeline that is triggered by JAR uploads to a Google Cloud Storage (GCS) bucket.

Prerequisites

This codelab assumes you have the following:

A billing-enabled Google Cloud Platform (GCP) project.
The gcloud CLI tool (installed locally on your computer).
Artifact support enabled .

1. Create a GCS Bucket for Artifact Storage

a. Log in with gcloud:

$ gcloud auth login

b. Run the gsutil mb command to create a bucket within your GCP project, giving your project’s ID (PROJECT_ID below) and the name of the bucket to create (BUCKET):

GCE Source To Prod

Mon, 01 Jan 0001 00:00:00 +0000

In this codelab, you create a cohesive workflow which takes source code and builds, tests and promotes it to production. You can also watch a video of this codelab in this Youtube playlist .

This will be accomplished via 3 pipelines:

Bake & Deploy to Test
Validate Test
Promote to Prod

You will be using a custom-built image that includes sample application source code, a Jenkins instance, a Debian repository (aptly) and a Spinnaker instance.

An Introduction to Spinnaker: Hello Deployment

Mon, 01 Jan 0001 00:00:00 +0000

This guide will run through the workflow of setting up an example application deployment with Spinnaker. It assumes you already have Spinnaker up and running on AWS or GCE. A guide for installation can be found here .

Below is a diagram of the workflow we will set up.

Set up Jenkins

Jenkins is a powerful continuous integration server that allows us to do several important things:

Poll our Github repository for changes so Spinnaker knows when to run a pipeline.
Compile and build our example application into a .deb package so Spinnaker can bake it on an image. Spinnaker expects all applications to be deployed as deb packages.

Installing Jenkins

If you already have a Jenkins server, you can skip this step.

Kubernetes Source to Prod

Mon, 01 Jan 0001 00:00:00 +0000

Overview

In this codelab you will configure:

A GitHub repo containing both your code to be deployed, and the Kubernetes manifests that will run your code.
A set of Spinnaker pipelines to deploy changes to your code, manifests, and application configuration from source to production.

0: Prerequisites

Before we begin, we need to do the following:

Configure GitHub

You need some source code and manifests to deploy stored in GitHub. We have a repository you can fork to follow along easily.

Oracle Cloud Infrastructure Source to Prod

Mon, 01 Jan 0001 00:00:00 +0000

In this codelab, you will create a cohesive workflow which takes source code and builds, tests, and promotes it to production.

Building the binary from the source code is done outside of Spinnaker, typically in a CI system such as Jenkins, Travis, etc. Spinnaker is integrated with three CI systems. Workflows can be triggered by jobs in these CI systems. The easiest binary form for Spinnaker to produce machine image is debian or rpm packages.

Safe Deployments

Mon, 01 Jan 0001 00:00:00 +0000

Overview

In this codelab, you will improve a deployment process by adding safeguards to your deployments.

This codelab is a continuation of the Kubernetes: code to prod codelab. It assumes you have an application set up and ready to deploy.

Setup

Please follow the steps in the Kubernetes Source to Prod guide to create a deployed Spinnaker cluster.

Making manual operations safer

Using the Rollback action

The rollback action automates the process of restoring to the previous good known server group. This feature enhances a traditionally manual operation by ensuring that the restored cluster is taking traffic before disabling the current server group.