diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html index 51371170..051f02d9 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_faq.html @@ -22,14 +22,14 @@ scripts without changing the whole pipeline.

git tag -l | xargs -n 1 git push --delete origin

10.8 I want to provide a different JDK version

  • by default we assume that you have jdk with id jdk8 configured
  • if you want a different one just override JDK_VERSION env var and point to the proper one
[Tip]Tip

The docker image comes in with Java installed at /usr/lib/jvm/java-8-openjdk-amd64. You can go to Global Tools and create a JDK with jdk8 id and JAVA_HOME pointing to /usr/lib/jvm/java-8-openjdk-amd64

To change the default one just follow these steps:

  - 

Figure 10.1. Click 'Manage Jenkins'

manage jenkins

  - 

Figure 10.2. Click 'Global Tool'

global tool

  - 

Figure 10.3. Click 'JDK Installations'

jdk installation

  - 

Figure 10.4. Fill out JDK Installation with path to your JDK

jdk

  + 

Figure 10.1. Click 'Manage Jenkins'

manage jenkins

  + 

Figure 10.2. Click 'Global Tool'

global tool

  + 

Figure 10.3. Click 'JDK Installations'

jdk installation

  + 

Figure 10.4. Fill out JDK Installation with path to your JDK

jdk

   

And that’s it!

10.9 Enable Groovy Token Macro Processing

With scripted that but if you needed to this manually then this is how to do it:

  - 

Figure 10.5. Click 'Manage Jenkins'

manage jenkins

  - 

Figure 10.6. Click 'Configure System'

configure system

  - 

Figure 10.7. Click 'Allow token macro processing'

groovy token

10.10 I want deployment to stage and prod be automatic

No problem, just set the property / env var to true

  • AUTO_DEPLOY_TO_STAGE to automatically deploy to stage
  • AUTO_DEPLOY_TO_PROD to automatically deploy to prod

10.11 I don’t want to test API compativility

No problem, just set the API_COMPATIBILITY_STEP_REQUIRED env variable + 

Figure 10.5. Click 'Manage Jenkins'

manage jenkins

  + 

Figure 10.6. Click 'Configure System'

configure system

  + 

Figure 10.7. Click 'Allow token macro processing'

groovy token

10.10 I want deployment to stage and prod be automatic

No problem, just set the property / env var to true

  • AUTO_DEPLOY_TO_STAGE to automatically deploy to stage
  • AUTO_DEPLOY_TO_PROD to automatically deploy to prod

10.11 I don’t want to test API compativility

No problem, just set the API_COMPATIBILITY_STEP_REQUIRED env variable to false and rerun the seed (you can pick it from the seed job’s properties too).

10.12 I can’t tag the repo!

When you get sth like this:

19:01:44 stderr: remote: Invalid username or password.
 19:01:44 fatal: Authentication failed for 'https://github.com/marcingrzejszczak/github-webhook/'
diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html
index 7fde2c06..f003a9bf 100644
--- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html
+++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__jenkins_pipeline_common.html
@@ -59,15 +59,15 @@ of Java installation and the others to another one.

< you’d have to go to Configure of the build step and modify the Git name / email. If you want to set it globally you’ll have to remove the section from the build step and follow these steps to set it globally.

You can set Git email / user globally like this:

  - 

Figure 7.1. Click 'Manage Jenkins'

manage jenkins

  - 

Figure 7.2. Click 'Configure System'

configure system

  - 

Figure 7.3. Fill out Git user information

git

  + 

Figure 7.1. Click 'Manage Jenkins'

manage jenkins

  + 

Figure 7.2. Click 'Configure System'

configure system

  + 

Figure 7.3. Fill out Git user information

git

   

Add Jenkins credentials for GitHub

The scripts will need to access the credential in order to tag the repo.

You have to set credentials with id: git.

Below you can find instructions on how to set a credential (e.g. for Cloud Foundry cf-test credential but remember to provide the one with id git).

  - 

Figure 7.4. Click 'Credentials, System'

credentials system

  - 

Figure 7.5. Click 'Global Credentials'

credentials global

  - 

Figure 7.6. Click 'Add credentials'

credentials add

  - 

Figure 7.7. Fill out the user / password and provide the git credential ID (in this example cf-test)

credentials example

  + 

Figure 7.4. Click 'Credentials, System'

credentials system

  + 

Figure 7.5. Click 'Global Credentials'

credentials global

  + 

Figure 7.6. Click 'Add credentials'

credentials add

  + 

Figure 7.7. Fill out the user / password and provide the git credential ID (in this example cf-test)

credentials example

   

7.3 Testing Jenkins scripts

./gradlew clean build

[Warning]Warning

The ran test only checks if your scripts compile.

7.4 How to work with Jenkins Job DSL plugin

Check out the tutorial. Provide the link to this repository in your Jenkins installation.

[Warning]Warning

Remember that views can be overridden that’s why the suggestion is to contain in one script all the logic needed to build a view for a single project (check out that spring_cloud_views.groovy is building all the spring-cloud views).

7.5 Docker Image

If you would like to run the pre-configured Jenkins image somewhere other than your local machine, we diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__project_opinions.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__project_opinions.html index dc68e2db..3af4ed6e 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__project_opinions.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__project_opinions.html @@ -1,4 +1,4 @@ 3. Project opinions

3. Project opinions

In this section we will go through the assumptions we’ve made in the project -structure and project properties.

3.1 CF project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Cloud Foundry
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
    • artifacts deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded

3.2 Kubernetes project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Kubernetes
  • The produced Java Docker image needs to allow passing of system properties via SYSTEM_PROPS env variable
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory and Docker repository

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
      • DOCKER_SERVER_ID - server id for Docker image pushing
      • DOCKER_USERNAME - username for Docker image pushing
      • DOCKER_PASSWORD - password for Docker image pushing
      • DOCKER_EMAIL - email for Artifactory / Nexus deployment
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • artifacts and Docker image deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_USERNAME env var - Username used to send the the Docker image
    • DOCKER_PASSWORD env var - Password used to send the the Docker image
    • DOCKER_EMAIL env var - Email used to send the the Docker image
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded
\ No newline at end of file +structure and project properties.

3.1 Cloud Foundry project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Cloud Foundry
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
    • artifacts deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded

3.2 Kubernetes project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Kubernetes
  • The produced Java Docker image needs to allow passing of system properties via SYSTEM_PROPS env variable
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory and Docker repository

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
      • DOCKER_SERVER_ID - server id for Docker image pushing
      • DOCKER_USERNAME - username for Docker image pushing
      • DOCKER_PASSWORD - password for Docker image pushing
      • DOCKER_EMAIL - email for Artifactory / Nexus deployment
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • artifacts and Docker image deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_USERNAME env var - Username used to send the the Docker image
    • DOCKER_PASSWORD env var - Password used to send the the Docker image
    • DOCKER_EMAIL env var - Email used to send the the Docker image
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded
\ No newline at end of file diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_cloud_foundry.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_cloud_foundry.html index 4a54a5b8..d5dd2400 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_cloud_foundry.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_cloud_foundry.html @@ -2,14 +2,14 @@ 12. The demo setup (Cloud Foundry)

12. The demo setup (Cloud Foundry)

The demo uses 2 applications. Github Webhook and Github analytics code. Below you can -see an image of how these application communicate with each other.

Figure 12.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

  +see an image of how these application communicate with each other.

Figure 12.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

   

For the demo scenario we have two applications. Github Analytics and Github Webhook. Let’s imagine a case where Github is emitting events via HTTP. Github Webhook has an API that could register to such hooks and receive those messages. Once this happens Github Webhook sends a message by RabbitMQ to a channel. Github Analytics is - listening to those messages and stores them in a MySQL database.

Figure 12.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

  + listening to those messages and stores them in a MySQL database.

Figure 12.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

   

Github Analytics has its KPIs (Key Performance Indicators) monitored. In the case -of that application the KPI is number of issues.

Figure 12.3. Grafana alerts Slack over Prometheus metrics

demo alerting

  +of that application the KPI is number of issues.

Figure 12.3. Grafana alerts Slack over Prometheus metrics

demo alerting

   

Let’s assume that if we go below the threshold of X issues then an alert should be sent to Slack.

12.1 Deploying production applications to PCF Dev

In the real world scenario we wouldn’t want to automatically provision services like RabbitMQ, MySQL or Eureka each time we deploy a new application to production. Typically diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_kubernetes.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_kubernetes.html index ef0f7feb..a28d5492 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_kubernetes.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi__the_demo_setup_kubernetes.html @@ -2,14 +2,14 @@ 13. The demo setup (Kubernetes)

13. The demo setup (Kubernetes)

The demo uses 2 applications. Github Webhook and Github analytics code. Below you can -see an image of how these application communicate with each other.

Figure 13.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

  +see an image of how these application communicate with each other.

Figure 13.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

   

For the demo scenario we have two applications. Github Analytics and Github Webhook. Let’s imagine a case where Github is emitting events via HTTP. Github Webhook has an API that could register to such hooks and receive those messages. Once this happens Github Webhook sends a message by RabbitMQ to a channel. Github Analytics is - listening to those messages and stores them in a MySQL database.

Figure 13.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

  + listening to those messages and stores them in a MySQL database.

Figure 13.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

   

Github Analytics has its KPIs (Key Performance Indicators) monitored. In the case -of that application the KPI is number of issues.

Figure 13.3. Grafana alerts Slack over Prometheus metrics

demo alerting

  +of that application the KPI is number of issues.

Figure 13.3. Grafana alerts Slack over Prometheus metrics

demo alerting

   

Let’s assume that if we go below the threshold of X issues then an alert should be sent to Slack.

13.1 Deploying production applications to Minikube

In the real world scenario we wouldn’t want to automatically provision services like RabbitMQ, MySQL or Eureka each time we deploy a new application to production. Typically diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi_concourse-pipeline-k8s.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi_concourse-pipeline-k8s.html index 59210446..1aaf6fc7 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi_concourse-pipeline-k8s.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi_concourse-pipeline-k8s.html @@ -3,7 +3,7 @@ 5. Concourse Pipeline (Kubernetes)

5. Concourse Pipeline (Kubernetes)

[Important]Important

In this chapter we assume that you perform deployment of your application to Kubernetes PaaS

The Spring Cloud Pipelines repository contains opinionated Concourse pipeline definition. Those jobs will form an empty pipeline and a -sample, opinionated one that you can use in your company.

All in all there are the following projects taking part in the whole microservice setup for this demo.

  • Github Analytics - the app that has a REST endpoint and uses messaging. Our business application.
  • Github Webhook - project that emits messages that are used by Github Analytics. Our business application.
  • Eureka - simple Eureka Server. This is an infrastructure application.
  • Github Analytics Stub Runner Boot - Stub Runner Boot server to be used for tests with Github Analytics. Uses Eureka and Messaging. This is an infrastructure application.

5.1 Step by step

This is a guide for Concourse pipeline.

If you want to just run the demo as far as possible using PCF Dev and Docker Compose

5.1.1 Fork repos

There are 4 apps that are composing the pipeline

You need to fork only these. That’s because only then will your user be able to tag and push the tag to repo.

5.2 Concourse in K8S (Kubernetes)

The simplest way to deploy Concourse to K8S is to use Helm. +sample, opinionated one that you can use in your company.

All in all there are the following projects taking part in the whole microservice setup for this demo.

  • Github Analytics - the app that has a REST endpoint and uses messaging. Our business application.
  • Github Webhook - project that emits messages that are used by Github Analytics. Our business application.
  • Eureka - simple Eureka Server. This is an infrastructure application.
  • Github Analytics Stub Runner Boot - Stub Runner Boot server to be used for tests with Github Analytics. Uses Eureka and Messaging. This is an infrastructure application.

5.1 Step by step

This is a guide for Concourse pipeline.

If you want to just run the demo as far as possible using PCF Dev and Docker Compose

5.1.1 Fork repos

There are 4 apps that are composing the pipeline

You need to fork only these. That’s because only then will your user be able to tag and push the tag to repo.

5.2 Concourse in K8S (Kubernetes)

The simplest way to deploy Concourse to K8S is to use Helm. Once you have Helm installed and your kubectl is pointing to the cluster, just type this command to install the Concourse cluster in your K8S cluster.

$ helm install stable/concourse --name concourse

Once it’s done you’ll see the following output

1. Concourse can be accessed:
 
@@ -34,7 +34,7 @@ Congratulations. You have just deployed JFrog Artifactory Pro!
    Default credential for Artifactory:
    user: admin
    password: password

Next, we need to set up the repositories.

First, access the Artifactory URL and log in with -user, admin and password password.

Figure 5.1. Click on the Quick Setup

artifactory quick setup

Then, click on the Maven setup and click Create.

Figure 5.2. Create the Maven Repository

artifactory maven repo

5.2.2 Setup the fly CLI

If you go to Concourse website you should see sth like this:

  +user, admin and password password.

Figure 5.1. Click on the Quick Setup

artifactory quick setup

Then, click on the Maven setup and click Create.

Figure 5.2. Create the Maven Repository

artifactory maven repo

5.2.2 Setup the fly CLI

If you go to Concourse website you should see sth like this:

   

running concourse

   

You can click one of the icons (depending on your OS) to download fly, which is the Concourse CLI. Once you’ve downloaded that (and maybe added to your PATH) you can run:

fly --version

If fly is properly installed then it should print out the version.

5.2.3 Setup your credentials.yml

There is a sample credentials file called credentials-sample-k8s.yml prepared for k8s. You can use it as a base for your credentials.yml.

To allow the Concourse worker’s spawned container to connect to @@ -43,13 +43,13 @@ auth token.

To get the contents of CA for GCE just execute

echo "Visit http://127.0.0.1:8080 to use Concourse"
 $ kubectl port-forward --namespace default $POD_NAME 8080:8080
 Visit http://127.0.0.1:8080 to use Concourse

Log in (e.g. for Concourse running at 127.0.0.1 - if you don’t provide any value then localhost is assumed). If you execute this script (it assumes that either fly is on your PATH or it’s in the same folder as the script is):

$ fly -t k8s login -c http://localhost:8080 -u concourse -p concourse

Next run the command to create the pipeline.

$ ./set_pipeline.sh github-webhook k8s credentials-k8s.yml

5.2.5 Run the github-webhook pipeline

  - 

Figure 5.3. Click Login

concourse login

  - 

Figure 5.4. Pick main team

concourse team main

  - 

Figure 5.5. Log in with concourse user and concourse password

concourse user pass

  - 

Figure 5.6. Your screen should look more or less like this

concourse pipeline

  - 

Figure 5.7. Unpause the pipeline by clicking in the top lefr corner and then clicking the play button

start pipeline

  - 

Figure 5.8. Click 'generate-version'

generate version

  - 

Figure 5.9. Click + sign to start a new build

run pipeline

  - 

Figure 5.10. The job is pending

concourse pending

  - 

Figure 5.11. Job is pending in the main screen

job running

  - 

Figure 5.12. Job is running in the main screen

running pipeline

\ No newline at end of file + 

Figure 5.3. Click Login

concourse login

  + 

Figure 5.4. Pick main team

concourse team main

  + 

Figure 5.5. Log in with concourse user and concourse password

concourse user pass

  + 

Figure 5.6. Your screen should look more or less like this

concourse pipeline

  + 

Figure 5.7. Unpause the pipeline by clicking in the top lefr corner and then clicking the play button

start pipeline

  + 

Figure 5.8. Click 'generate-version'

generate version

  + 

Figure 5.9. Click + sign to start a new build

run pipeline

  + 

Figure 5.10. The job is pending

concourse pending

  + 

Figure 5.11. Job is pending in the main screen

job running

  + 

Figure 5.12. Job is running in the main screen

running pipeline

\ No newline at end of file diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-cf.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-cf.html index fb16dc2b..b33371eb 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-cf.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-cf.html @@ -32,35 +32,35 @@ has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and `github-analytics'.

  - 

Figure 8.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  - 

Figure 8.2. Click the 'Build with parameters'

seed run

  - 

Figure 8.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  - 

Figure 8.4. This is how the results of seed should look like

seed built

8.1.5 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do + 

Figure 8.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  + 

Figure 8.2. Click the 'Build with parameters'

seed run

  + 

Figure 8.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  + 

Figure 8.4. This is how the results of seed should look like

seed built

8.1.5 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do run it you have to provide some properties. By default we create a seed that has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and github-analytics.

  - 

Figure 8.5. Click the 'github-webhook' view

seed views

  - 

Figure 8.6. Run the pipeline

pipeline run

  + 

Figure 8.5. Click the 'github-webhook' view

seed views

  + 

Figure 8.6. Run the pipeline

pipeline run

   

[Important]Important

If your build fails on the deploy previous version to stage due to missing jar, that means that you’ve forgotten to clear the tags in your repo. Typically that’s due to the fact that you’ve removed the Artifactory volume with deployed JAR whereas a tag in the repo is still pointing there. Check out this section on how to remove the tag.

  - 

Figure 8.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

  + 

Figure 8.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

   

[Important]Important

Most likely you will run out of memory so when reaching the stage environment it’s good to kill all apps on test. Check out the FAQ section for more details!

  - 

Figure 8.8. The full pipeline should look like this

pipeline finished

  + 

Figure 8.8. The full pipeline should look like this

pipeline finished

   

8.2 Declarative pipeline & Blue Ocean

You can also use the declarative pipeline approach with the Blue Ocean UI. Here is a step by step guide to run a pipeline via this approach.

The Blue Ocean UI is available under the blue/ URL. E.g. for Docker Machine based setup http://192.168.99.100:8080/blue.

  - 

Figure 8.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  - 

Figure 8.10. Your first run will look like this. Click Run button

blue 2

  - 

Figure 8.11. Enter parameters required for the build and click run

blue 3

  - 

Figure 8.12. A list of pipelines will be shown. Click your first run.

blue 4

  - 

Figure 8.13. State if you want to go to production or not and click Proceed

blue 5

  - 

Figure 8.14. The build is in progress…​

blue 6

  - 

Figure 8.15. The pipeline is done!

blue 7

  + 

Figure 8.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  + 

Figure 8.10. Your first run will look like this. Click Run button

blue 2

  + 

Figure 8.11. Enter parameters required for the build and click run

blue 3

  + 

Figure 8.12. A list of pipelines will be shown. Click your first run.

blue 4

  + 

Figure 8.13. State if you want to go to production or not and click Proceed

blue 5

  + 

Figure 8.14. The build is in progress…​

blue 6

  + 

Figure 8.15. The pipeline is done!

blue 7

   

[Important]Important

There is no possibility of restarting pipeline from specific stage, after failure. Please check out this issue for more information

[Warning]Warning

Currently there is no way to introduce manual steps in a performant way. Jenkins is blocking an executor when manual step is required. That means that you’ll run out of executors diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-k8s.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-k8s.html index f2fa1c34..955b157e 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-k8s.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi_jenkins-pipeline-k8s.html @@ -24,35 +24,35 @@ has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and `github-analytics'.

  - 

Figure 9.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  - 

Figure 9.2. Click the 'Build with parameters'

seed run

  - 

Figure 9.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  - 

Figure 9.4. This is how the results of seed should look like

seed built

9.1.4 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do + 

Figure 9.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  + 

Figure 9.2. Click the 'Build with parameters'

seed run

  + 

Figure 9.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  + 

Figure 9.4. This is how the results of seed should look like

seed built

9.1.4 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do run it you have to provide some properties. By default we create a seed that has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and github-analytics.

  - 

Figure 9.5. Click the 'github-webhook' view

seed views

  - 

Figure 9.6. Run the pipeline

pipeline run

  + 

Figure 9.5. Click the 'github-webhook' view

seed views

  + 

Figure 9.6. Run the pipeline

pipeline run

   

[Important]Important

If your build fails on the deploy previous version to stage due to missing jar, that means that you’ve forgotten to clear the tags in your repo. Typically that’s due to the fact that you’ve removed the Artifactory volume with deployed JAR whereas a tag in the repo is still pointing there. Check out this section on how to remove the tag.

  - 

Figure 9.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

  + 

Figure 9.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

   

[Important]Important

Most likely you will run out of memory so when reaching the stage environment it’s good to kill all apps on test. Check out the FAQ section for more details!

  - 

Figure 9.8. The full pipeline should look like this

pipeline finished

  + 

Figure 9.8. The full pipeline should look like this

pipeline finished

   

9.2 Declarative pipeline & Blue Ocean

You can also use the declarative pipeline approach with the Blue Ocean UI. Here is a step by step guide to run a pipeline via this approach.

The Blue Ocean UI is available under the blue/ URL. E.g. for Docker Machine based setup http://192.168.99.100:8080/blue.

  - 

Figure 9.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  - 

Figure 9.10. Your first run will look like this. Click Run button

blue 2

  - 

Figure 9.11. Enter parameters required for the build and click run

blue 3

  - 

Figure 9.12. A list of pipelines will be shown. Click your first run.

blue 4

  - 

Figure 9.13. State if you want to go to production or not and click Proceed

blue 5

  - 

Figure 9.14. The build is in progress…​

blue 6

  - 

Figure 9.15. The pipeline is done!

blue 7

  + 

Figure 9.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  + 

Figure 9.10. Your first run will look like this. Click Run button

blue 2

  + 

Figure 9.11. Enter parameters required for the build and click run

blue 3

  + 

Figure 9.12. A list of pipelines will be shown. Click your first run.

blue 4

  + 

Figure 9.13. State if you want to go to production or not and click Proceed

blue 5

  + 

Figure 9.14. The build is in progress…​

blue 6

  + 

Figure 9.15. The pipeline is done!

blue 7

   

[Important]Important

There is no possibility of restarting pipeline from specific stage, after failure. Please check out this issue for more information

[Warning]Warning

Currently there is no way to introduce manual steps in a performant way. Jenkins is blocking an executor when manual step is required. That means that you’ll run out of executors diff --git a/spring-cloud-pipelines/1.0.0.M7/multi/multi_spring-cloud-pipelines.html b/spring-cloud-pipelines/1.0.0.M7/multi/multi_spring-cloud-pipelines.html index 62fa9000..a9da3cfa 100644 --- a/spring-cloud-pipelines/1.0.0.M7/multi/multi_spring-cloud-pipelines.html +++ b/spring-cloud-pipelines/1.0.0.M7/multi/multi_spring-cloud-pipelines.html @@ -1,3 +1,3 @@ - Spring Cloud Pipelines

Spring Cloud Pipelines


Table of Contents

1. Introduction
1.1. Project setup
1.2. How to use it?
1.2.1. Centralized pipeline creation
1.2.2. Pipeline per repository
1.3. The flow
1.4. Environments
1.5. Tests
1.5.1. Testing against stubs
1.5.2. General view
1.6. CI Server worker prerequisites
1.7. Pipeline descriptor
2. Opinionated implementation
2.1. Build
2.2. Test
2.3. Stage
2.4. Prod
3. Project opinions
3.1. CF project opinions
3.2. Kubernetes project opinions
4. Concourse Pipeline (Cloud Foundry)
4.1. Step by step
4.1.1. Fork repos
4.1.2. Start Concourse and Artifactory
Deploy the infra JARs to Artifactory
4.1.3. Start PCF Dev
4.1.4. Setup the fly CLI
4.1.5. Setup your credentials.yml
4.1.6. Build the pipeline
4.1.7. Run the github-webhook pipeline
5. Concourse Pipeline (Kubernetes)
5.1. Step by step
5.1.1. Fork repos
5.2. Concourse in K8S (Kubernetes)
5.2.1. Deploying Artifactory to K8S
5.2.2. Setup the fly CLI
5.2.3. Setup your credentials.yml
5.2.4. Build the pipeline
5.2.5. Run the github-webhook pipeline
6. Concourse FAQ
6.1. Can I use the pipeline for some other repos?
6.2. Will this work for ANY project out of the box?
6.3. Can I modify this to reuse in my project?
6.4. I ran out of resources!! (PCF Dev)
6.5. The rollback step fails due to missing JAR ?!
6.6. Can I see the output of a job from the terminal?
6.7. I clicked the job and it’s constantly pending…​
6.8. The route is already in use (CF)
6.9. I’m unauthorized to deploy infrastructure jars
6.10. version resource is broken
7. Jenkins Pipeline (Common)
7.1. Project setup
7.2. Optional customization steps
7.2.1. Deploying infra jars to a different location
7.2.2. Setup settings.xml for Maven deployment
7.2.3. Setup Jenkins env vars
Seed properties
Global envs
7.2.4. Set Git email / user
Add Jenkins credentials for GitHub
7.3. Testing Jenkins scripts
7.4. How to work with Jenkins Job DSL plugin
7.5. Docker Image
8. Jenkins Pipeline (Cloud Foundry)
8.1. Step by step
8.1.1. Fork repos
8.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
8.1.3. Start PCF Dev
8.1.4. Run the seed job
8.1.5. Run the github-webhook pipeline
8.2. Declarative pipeline & Blue Ocean
8.3. Jenkins Cloud Foundry customization
8.3.1. All env vars
8.3.2. Jenkins Credentials
9. Jenkins Pipeline (Kubernetes)
9.1. Step by step
9.1.1. Fork repos
9.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
9.1.3. Run the seed job
9.1.4. Run the github-webhook pipeline
9.2. Declarative pipeline & Blue Ocean
9.3. Jenkins Kubernetes customization
9.3.1. All env vars
9.4. Preparing to connect to GCE
9.5. Connecting to a Kubo or GCE cluster
10. Jenkins FAQ
10.1. Pipeline version contains ${PIPELINE_VERSION}
10.2. Pipeline version is not passed to the build
10.3. The build times out with pipeline.sh info
10.4. Can I use the pipeline for some other repos?
10.5. Will this work for ANY project out of the box?
10.6. Can I modify this to reuse in my project?
10.7. The rollback step fails due to missing JAR ?!
10.8. I want to provide a different JDK version
10.9. Enable Groovy Token Macro Processing
10.10. I want deployment to stage and prod be automatic
10.11. I don’t want to test API compativility
10.12. I can’t tag the repo!
10.13. I’m unauthorized to deploy infrastructure jars
10.14. Signing Artifacts
10.15. Using SSH keys for git
10.16. Deploy to stage fails and doesn’t redeploy a service (Kubernetes)
10.17. I ran out of resources!! (Cloud Foundry)
10.18. Deploying to test / stage / prod fails - error finding space (Cloud Foundry)
10.19. The route is already in use (Cloud Foundry)
10.20. How to execute helper scripts against a real CF instance I’m logged into (Cloud Foundry)
11. Kubernetes setup
11.1. Kubernetes CLI Installation
11.1.1. Script Installation
11.1.2. Manual Installation
11.2. Kubernetes Cluster setup
11.2.1. Script Installation
11.2.2. Manual Installation
11.3. Run Minikube
11.4. Certificates and Workers
11.4.1. Minikube Certificates and Workers
11.4.2. Manual Certificates and Workers Setup
11.5. Generate Minikube namespaces
12. The demo setup (Cloud Foundry)
12.1. Deploying production applications to PCF Dev
12.2. Running Prometheus on CF
12.3. Running Grafana on CF
13. The demo setup (Kubernetes)
13.1. Deploying production applications to Minikube
13.2. Running Prometheus on Kubernetes
13.3. Running Grafana on Kubernetes
14. Building the project
14.1. Prerequisites
14.2. Bats submodules
14.3. Build and test
14.4. Generate docs
14.5. Making a release
15. Customizing the project
16. Releasing the project
16.1. Publishing A Docker Image
\ No newline at end of file + Spring Cloud Pipelines

Spring Cloud Pipelines


Table of Contents

1. Introduction
1.1. Project setup
1.2. How to use it?
1.2.1. Centralized pipeline creation
1.2.2. Pipeline per repository
1.3. The flow
1.4. Environments
1.5. Tests
1.5.1. Testing against stubs
1.5.2. General view
1.6. CI Server worker prerequisites
1.7. Pipeline descriptor
2. Opinionated implementation
2.1. Build
2.2. Test
2.3. Stage
2.4. Prod
3. Project opinions
3.1. Cloud Foundry project opinions
3.2. Kubernetes project opinions
4. Concourse Pipeline (Cloud Foundry)
4.1. Step by step
4.1.1. Fork repos
4.1.2. Start Concourse and Artifactory
Deploy the infra JARs to Artifactory
4.1.3. Start PCF Dev
4.1.4. Setup the fly CLI
4.1.5. Setup your credentials.yml
4.1.6. Build the pipeline
4.1.7. Run the github-webhook pipeline
5. Concourse Pipeline (Kubernetes)
5.1. Step by step
5.1.1. Fork repos
5.2. Concourse in K8S (Kubernetes)
5.2.1. Deploying Artifactory to K8S
5.2.2. Setup the fly CLI
5.2.3. Setup your credentials.yml
5.2.4. Build the pipeline
5.2.5. Run the github-webhook pipeline
6. Concourse FAQ
6.1. Can I use the pipeline for some other repos?
6.2. Will this work for ANY project out of the box?
6.3. Can I modify this to reuse in my project?
6.4. I ran out of resources!! (PCF Dev)
6.5. The rollback step fails due to missing JAR ?!
6.6. Can I see the output of a job from the terminal?
6.7. I clicked the job and it’s constantly pending…​
6.8. The route is already in use (CF)
6.9. I’m unauthorized to deploy infrastructure jars
6.10. version resource is broken
7. Jenkins Pipeline (Common)
7.1. Project setup
7.2. Optional customization steps
7.2.1. Deploying infra jars to a different location
7.2.2. Setup settings.xml for Maven deployment
7.2.3. Setup Jenkins env vars
Seed properties
Global envs
7.2.4. Set Git email / user
Add Jenkins credentials for GitHub
7.3. Testing Jenkins scripts
7.4. How to work with Jenkins Job DSL plugin
7.5. Docker Image
8. Jenkins Pipeline (Cloud Foundry)
8.1. Step by step
8.1.1. Fork repos
8.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
8.1.3. Start PCF Dev
8.1.4. Run the seed job
8.1.5. Run the github-webhook pipeline
8.2. Declarative pipeline & Blue Ocean
8.3. Jenkins Cloud Foundry customization
8.3.1. All env vars
8.3.2. Jenkins Credentials
9. Jenkins Pipeline (Kubernetes)
9.1. Step by step
9.1.1. Fork repos
9.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
9.1.3. Run the seed job
9.1.4. Run the github-webhook pipeline
9.2. Declarative pipeline & Blue Ocean
9.3. Jenkins Kubernetes customization
9.3.1. All env vars
9.4. Preparing to connect to GCE
9.5. Connecting to a Kubo or GCE cluster
10. Jenkins FAQ
10.1. Pipeline version contains ${PIPELINE_VERSION}
10.2. Pipeline version is not passed to the build
10.3. The build times out with pipeline.sh info
10.4. Can I use the pipeline for some other repos?
10.5. Will this work for ANY project out of the box?
10.6. Can I modify this to reuse in my project?
10.7. The rollback step fails due to missing JAR ?!
10.8. I want to provide a different JDK version
10.9. Enable Groovy Token Macro Processing
10.10. I want deployment to stage and prod be automatic
10.11. I don’t want to test API compativility
10.12. I can’t tag the repo!
10.13. I’m unauthorized to deploy infrastructure jars
10.14. Signing Artifacts
10.15. Using SSH keys for git
10.16. Deploy to stage fails and doesn’t redeploy a service (Kubernetes)
10.17. I ran out of resources!! (Cloud Foundry)
10.18. Deploying to test / stage / prod fails - error finding space (Cloud Foundry)
10.19. The route is already in use (Cloud Foundry)
10.20. How to execute helper scripts against a real CF instance I’m logged into (Cloud Foundry)
11. Kubernetes setup
11.1. Kubernetes CLI Installation
11.1.1. Script Installation
11.1.2. Manual Installation
11.2. Kubernetes Cluster setup
11.2.1. Script Installation
11.2.2. Manual Installation
11.3. Run Minikube
11.4. Certificates and Workers
11.4.1. Minikube Certificates and Workers
11.4.2. Manual Certificates and Workers Setup
11.5. Generate Minikube namespaces
12. The demo setup (Cloud Foundry)
12.1. Deploying production applications to PCF Dev
12.2. Running Prometheus on CF
12.3. Running Grafana on CF
13. The demo setup (Kubernetes)
13.1. Deploying production applications to Minikube
13.2. Running Prometheus on Kubernetes
13.3. Running Grafana on Kubernetes
14. Building the project
14.1. Prerequisites
14.2. Bats submodules
14.3. Build and test
14.4. Generate docs
14.5. Making a release
15. Customizing the project
16. Releasing the project
16.1. Publishing A Docker Image
\ No newline at end of file diff --git a/spring-cloud-pipelines/1.0.0.M7/single/spring-cloud-pipelines.html b/spring-cloud-pipelines/1.0.0.M7/single/spring-cloud-pipelines.html index 77fb292c..bb55f40c 100644 --- a/spring-cloud-pipelines/1.0.0.M7/single/spring-cloud-pipelines.html +++ b/spring-cloud-pipelines/1.0.0.M7/single/spring-cloud-pipelines.html @@ -1,6 +1,6 @@ - Spring Cloud Pipelines

Spring Cloud Pipelines


Table of Contents

1. Introduction
1.1. Project setup
1.2. How to use it?
1.2.1. Centralized pipeline creation
1.2.2. Pipeline per repository
1.3. The flow
1.4. Environments
1.5. Tests
1.5.1. Testing against stubs
1.5.2. General view
1.6. CI Server worker prerequisites
1.7. Pipeline descriptor
2. Opinionated implementation
2.1. Build
2.2. Test
2.3. Stage
2.4. Prod
3. Project opinions
3.1. CF project opinions
3.2. Kubernetes project opinions
4. Concourse Pipeline (Cloud Foundry)
4.1. Step by step
4.1.1. Fork repos
4.1.2. Start Concourse and Artifactory
Deploy the infra JARs to Artifactory
4.1.3. Start PCF Dev
4.1.4. Setup the fly CLI
4.1.5. Setup your credentials.yml
4.1.6. Build the pipeline
4.1.7. Run the github-webhook pipeline
5. Concourse Pipeline (Kubernetes)
5.1. Step by step
5.1.1. Fork repos
5.2. Concourse in K8S (Kubernetes)
5.2.1. Deploying Artifactory to K8S
5.2.2. Setup the fly CLI
5.2.3. Setup your credentials.yml
5.2.4. Build the pipeline
5.2.5. Run the github-webhook pipeline
6. Concourse FAQ
6.1. Can I use the pipeline for some other repos?
6.2. Will this work for ANY project out of the box?
6.3. Can I modify this to reuse in my project?
6.4. I ran out of resources!! (PCF Dev)
6.5. The rollback step fails due to missing JAR ?!
6.6. Can I see the output of a job from the terminal?
6.7. I clicked the job and it’s constantly pending…​
6.8. The route is already in use (CF)
6.9. I’m unauthorized to deploy infrastructure jars
6.10. version resource is broken
7. Jenkins Pipeline (Common)
7.1. Project setup
7.2. Optional customization steps
7.2.1. Deploying infra jars to a different location
7.2.2. Setup settings.xml for Maven deployment
7.2.3. Setup Jenkins env vars
Seed properties
Global envs
7.2.4. Set Git email / user
Add Jenkins credentials for GitHub
7.3. Testing Jenkins scripts
7.4. How to work with Jenkins Job DSL plugin
7.5. Docker Image
8. Jenkins Pipeline (Cloud Foundry)
8.1. Step by step
8.1.1. Fork repos
8.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
8.1.3. Start PCF Dev
8.1.4. Run the seed job
8.1.5. Run the github-webhook pipeline
8.2. Declarative pipeline & Blue Ocean
8.3. Jenkins Cloud Foundry customization
8.3.1. All env vars
8.3.2. Jenkins Credentials
9. Jenkins Pipeline (Kubernetes)
9.1. Step by step
9.1.1. Fork repos
9.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
9.1.3. Run the seed job
9.1.4. Run the github-webhook pipeline
9.2. Declarative pipeline & Blue Ocean
9.3. Jenkins Kubernetes customization
9.3.1. All env vars
9.4. Preparing to connect to GCE
9.5. Connecting to a Kubo or GCE cluster
10. Jenkins FAQ
10.1. Pipeline version contains ${PIPELINE_VERSION}
10.2. Pipeline version is not passed to the build
10.3. The build times out with pipeline.sh info
10.4. Can I use the pipeline for some other repos?
10.5. Will this work for ANY project out of the box?
10.6. Can I modify this to reuse in my project?
10.7. The rollback step fails due to missing JAR ?!
10.8. I want to provide a different JDK version
10.9. Enable Groovy Token Macro Processing
10.10. I want deployment to stage and prod be automatic
10.11. I don’t want to test API compativility
10.12. I can’t tag the repo!
10.13. I’m unauthorized to deploy infrastructure jars
10.14. Signing Artifacts
10.15. Using SSH keys for git
10.16. Deploy to stage fails and doesn’t redeploy a service (Kubernetes)
10.17. I ran out of resources!! (Cloud Foundry)
10.18. Deploying to test / stage / prod fails - error finding space (Cloud Foundry)
10.19. The route is already in use (Cloud Foundry)
10.20. How to execute helper scripts against a real CF instance I’m logged into (Cloud Foundry)
11. Kubernetes setup
11.1. Kubernetes CLI Installation
11.1.1. Script Installation
11.1.2. Manual Installation
11.2. Kubernetes Cluster setup
11.2.1. Script Installation
11.2.2. Manual Installation
11.3. Run Minikube
11.4. Certificates and Workers
11.4.1. Minikube Certificates and Workers
11.4.2. Manual Certificates and Workers Setup
11.5. Generate Minikube namespaces
12. The demo setup (Cloud Foundry)
12.1. Deploying production applications to PCF Dev
12.2. Running Prometheus on CF
12.3. Running Grafana on CF
13. The demo setup (Kubernetes)
13.1. Deploying production applications to Minikube
13.2. Running Prometheus on Kubernetes
13.3. Running Grafana on Kubernetes
14. Building the project
14.1. Prerequisites
14.2. Bats submodules
14.3. Build and test
14.4. Generate docs
14.5. Making a release
15. Customizing the project
16. Releasing the project
16.1. Publishing A Docker Image

Documentation Authors: Marcin Grzejszczak

Spring, Spring Boot and Spring Cloud are tools that allow developers speed up the + Spring Cloud Pipelines

Spring Cloud Pipelines


Table of Contents

1. Introduction
1.1. Project setup
1.2. How to use it?
1.2.1. Centralized pipeline creation
1.2.2. Pipeline per repository
1.3. The flow
1.4. Environments
1.5. Tests
1.5.1. Testing against stubs
1.5.2. General view
1.6. CI Server worker prerequisites
1.7. Pipeline descriptor
2. Opinionated implementation
2.1. Build
2.2. Test
2.3. Stage
2.4. Prod
3. Project opinions
3.1. Cloud Foundry project opinions
3.2. Kubernetes project opinions
4. Concourse Pipeline (Cloud Foundry)
4.1. Step by step
4.1.1. Fork repos
4.1.2. Start Concourse and Artifactory
Deploy the infra JARs to Artifactory
4.1.3. Start PCF Dev
4.1.4. Setup the fly CLI
4.1.5. Setup your credentials.yml
4.1.6. Build the pipeline
4.1.7. Run the github-webhook pipeline
5. Concourse Pipeline (Kubernetes)
5.1. Step by step
5.1.1. Fork repos
5.2. Concourse in K8S (Kubernetes)
5.2.1. Deploying Artifactory to K8S
5.2.2. Setup the fly CLI
5.2.3. Setup your credentials.yml
5.2.4. Build the pipeline
5.2.5. Run the github-webhook pipeline
6. Concourse FAQ
6.1. Can I use the pipeline for some other repos?
6.2. Will this work for ANY project out of the box?
6.3. Can I modify this to reuse in my project?
6.4. I ran out of resources!! (PCF Dev)
6.5. The rollback step fails due to missing JAR ?!
6.6. Can I see the output of a job from the terminal?
6.7. I clicked the job and it’s constantly pending…​
6.8. The route is already in use (CF)
6.9. I’m unauthorized to deploy infrastructure jars
6.10. version resource is broken
7. Jenkins Pipeline (Common)
7.1. Project setup
7.2. Optional customization steps
7.2.1. Deploying infra jars to a different location
7.2.2. Setup settings.xml for Maven deployment
7.2.3. Setup Jenkins env vars
Seed properties
Global envs
7.2.4. Set Git email / user
Add Jenkins credentials for GitHub
7.3. Testing Jenkins scripts
7.4. How to work with Jenkins Job DSL plugin
7.5. Docker Image
8. Jenkins Pipeline (Cloud Foundry)
8.1. Step by step
8.1.1. Fork repos
8.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
8.1.3. Start PCF Dev
8.1.4. Run the seed job
8.1.5. Run the github-webhook pipeline
8.2. Declarative pipeline & Blue Ocean
8.3. Jenkins Cloud Foundry customization
8.3.1. All env vars
8.3.2. Jenkins Credentials
9. Jenkins Pipeline (Kubernetes)
9.1. Step by step
9.1.1. Fork repos
9.1.2. Start Jenkins and Artifactory
Deploy the infra JARs to Artifactory
9.1.3. Run the seed job
9.1.4. Run the github-webhook pipeline
9.2. Declarative pipeline & Blue Ocean
9.3. Jenkins Kubernetes customization
9.3.1. All env vars
9.4. Preparing to connect to GCE
9.5. Connecting to a Kubo or GCE cluster
10. Jenkins FAQ
10.1. Pipeline version contains ${PIPELINE_VERSION}
10.2. Pipeline version is not passed to the build
10.3. The build times out with pipeline.sh info
10.4. Can I use the pipeline for some other repos?
10.5. Will this work for ANY project out of the box?
10.6. Can I modify this to reuse in my project?
10.7. The rollback step fails due to missing JAR ?!
10.8. I want to provide a different JDK version
10.9. Enable Groovy Token Macro Processing
10.10. I want deployment to stage and prod be automatic
10.11. I don’t want to test API compativility
10.12. I can’t tag the repo!
10.13. I’m unauthorized to deploy infrastructure jars
10.14. Signing Artifacts
10.15. Using SSH keys for git
10.16. Deploy to stage fails and doesn’t redeploy a service (Kubernetes)
10.17. I ran out of resources!! (Cloud Foundry)
10.18. Deploying to test / stage / prod fails - error finding space (Cloud Foundry)
10.19. The route is already in use (Cloud Foundry)
10.20. How to execute helper scripts against a real CF instance I’m logged into (Cloud Foundry)
11. Kubernetes setup
11.1. Kubernetes CLI Installation
11.1.1. Script Installation
11.1.2. Manual Installation
11.2. Kubernetes Cluster setup
11.2.1. Script Installation
11.2.2. Manual Installation
11.3. Run Minikube
11.4. Certificates and Workers
11.4.1. Minikube Certificates and Workers
11.4.2. Manual Certificates and Workers Setup
11.5. Generate Minikube namespaces
12. The demo setup (Cloud Foundry)
12.1. Deploying production applications to PCF Dev
12.2. Running Prometheus on CF
12.3. Running Grafana on CF
13. The demo setup (Kubernetes)
13.1. Deploying production applications to Minikube
13.2. Running Prometheus on Kubernetes
13.3. Running Grafana on Kubernetes
14. Building the project
14.1. Prerequisites
14.2. Bats submodules
14.3. Build and test
14.4. Generate docs
14.5. Making a release
15. Customizing the project
16. Releasing the project
16.1. Publishing A Docker Image

Documentation Authors: Marcin Grzejszczak

Spring, Spring Boot and Spring Cloud are tools that allow developers speed up the time of creating new business features. It’s common knowledge however that the feature is only valuable if it’s in production. That’s why companies spend a lot of time and resources on building their own deployment pipelines.

This project tries to solve the following problems:

  • Creation of a common deployment pipeline
  • Propagation of good testing & deployment practices
  • Speed up the time required to deploy a feature to production

A common way of running, configuring and deploying applications lowers support costs @@ -180,7 +180,7 @@ For Cloud Foundry just call t for Kubernetes tools/k8s-helper.sh setup-prod-infra

Here we’re

  • tagging the Git repo with prod/${version} tag
  • downloading the application artifact (either JAR for Cloud Foundry or Docker image for Kubernetes)
  • we’re doing Blue Green deployment:
  • for Cloud Foundry

    • we’re renaming the current instance of the app e.g. fooService to fooService-venerable
    • we’re deploying the new instance of the app under the fooService name
    • now two instances of the same application are running on production
  • for Kubernetes

    • we’re deploying a service with the name of the app e.g. fooService
    • we’re doing a deployment with the name of the app with version suffix (with the name escaped to fulfill the DNS name requirements) e.g. fooService-1-0-0-M1-123-456-VERSION
    • all deployments of the same application have the same label name equal to app name e.g. fooService
    • the service is routing the traffic basing on the name label selector
    • now two instances of the same application are running on production
  • in the Complete switch over which is a manual step

    • we’re deleting the old instance
    • remember to run this step only after you have confirmed that both instances are working fine!
    • now two instances of the same application are running on production
  • in the Rollback to blue which is a manual step

    • we’re routing all the traffic to the old instance
    • in CF we do that by ensuring that blue is running and stopping green
    • in K8S we do that by scaling the number of instances of green to 0
    • this step will set the state of your system to such where most likely some manual intervention should take place (to restart some applications, redeploy them, etc.)

3. Project opinions

In this section we will go through the assumptions we’ve made in the project -structure and project properties.

3.1 CF project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Cloud Foundry
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
    • artifacts deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded

3.2 Kubernetes project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Kubernetes
  • The produced Java Docker image needs to allow passing of system properties via SYSTEM_PROPS env variable
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory and Docker repository

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
      • DOCKER_SERVER_ID - server id for Docker image pushing
      • DOCKER_USERNAME - username for Docker image pushing
      • DOCKER_PASSWORD - password for Docker image pushing
      • DOCKER_EMAIL - email for Artifactory / Nexus deployment
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • artifacts and Docker image deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_USERNAME env var - Username used to send the the Docker image
    • DOCKER_PASSWORD env var - Password used to send the the Docker image
    • DOCKER_EMAIL env var - Email used to send the the Docker image
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded

4. Concourse Pipeline (Cloud Foundry)

[Important]Important

In this chapter we assume that you perform deployment of your application +structure and project properties.

3.1 Cloud Foundry project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Cloud Foundry
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
    • artifacts deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded

3.2 Kubernetes project opinions

We’ve taken the following opinionated decisions for a Cloud Foundry based project:

  • application built using Maven or Gradle wrappers
  • application deployment to Kubernetes
  • The produced Java Docker image needs to allow passing of system properties via SYSTEM_PROPS env variable
  • For Maven (example project):

    • usage of Maven Wrapper
    • settings.xml is parametrized to pass the credentials to push code to Artifactory and Docker repository

      • M2_SETTINGS_REPO_ID - server id for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_USERNAME - username for Artifactory / Nexus deployment
      • M2_SETTINGS_REPO_PASSWORD - password for Artifactory / Nexus deployment
      • DOCKER_SERVER_ID - server id for Docker image pushing
      • DOCKER_USERNAME - username for Docker image pushing
      • DOCKER_PASSWORD - password for Docker image pushing
      • DOCKER_EMAIL - email for Artifactory / Nexus deployment
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • artifacts and Docker image deployment by ./mvnw clean deploy
    • stubrunner.ids property to retrieve list of collaborators for which stubs should be downloaded
    • repo.with.binaries property - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • distribution.management.release.id property - (Injected by the pipeline) ID of the distribution management. Corresponds to server id in settings.xml
    • distribution.management.release.url property - (Injected by the pipeline) Will contain the URL to the repo containing binaries (e.g. Artifactory)
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apicompatibility Maven profile
    • latest.production.version property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke Maven profile
    • running end to end tests on a deployed app via the e2e Maven profile
  • For Gradle (example project check the gradle/pipeline.gradle file):

    • usage of Gradlew Wrapper
    • deploy task for artifacts deployment
    • REPO_WITH_BINARIES env var - (Injected by the pipeline) will contain the URL to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_USERNAME env var - Username used to send the binary to the repo containing binaries (e.g. Artifactory)
    • M2_SETTINGS_REPO_PASSWORD env var - Password used to send the binary to the repo containing binaries (e.g. Artifactory)
    • DOCKER_REGISTRY_URL env var - (Overridable - defaults to DockerHub) URL of the Docker registry
    • DOCKER_USERNAME env var - Username used to send the the Docker image
    • DOCKER_PASSWORD env var - Password used to send the the Docker image
    • DOCKER_EMAIL env var - Email used to send the the Docker image
    • DOCKER_REGISTRY_ORGANIZATION - env var containing the organization where your Docker repo lays
    • deployment.yml contains the Kubernetes deployment descriptor
    • service.yml contains the Kubernetes service descriptor
    • running API compatibility tests via the apiCompatibility task
    • latestProductionVersion property - (Injected by the pipeline) will contain the latest production version for the repo (retrieved from Git tags)
    • running smoke tests on a deployed app via the smoke task
    • running end to end tests on a deployed app via the e2e task
    • groupId task to retrieve group id
    • artifactId task to retrieve artifact id
    • currentVersion task to retrieve the current version
    • stubIds task to retrieve list of collaborators for which stubs should be downloaded

4. Concourse Pipeline (Cloud Foundry)

[Important]Important

In this chapter we assume that you perform deployment of your application to Cloud Foundry PaaS

The Spring Cloud Pipelines repository contains opinionated Concourse pipeline definition. Those jobs will form an empty pipeline and a sample, opinionated one that you can use in your company.

All in all there are the following projects taking part in the whole microservice setup for this demo.

  • Github Analytics - the app that has a REST endpoint and uses messaging. Our business application.
  • Github Webhook - project that emits messages that are used by Github Analytics. Our business application.
  • Eureka - simple Eureka Server. This is an infrastructure application.
  • Github Analytics Stub Runner Boot - Stub Runner Boot server to be used for tests with Github Analytics. Uses Eureka and Messaging. This is an infrastructure application.

5. Concourse Pipeline (Kubernetes)

[Important]Important

In this chapter we assume that you perform deployment of your application to Kubernetes PaaS

The Spring Cloud Pipelines repository contains opinionated Concourse pipeline definition. Those jobs will form an empty pipeline and a -sample, opinionated one that you can use in your company.

All in all there are the following projects taking part in the whole microservice setup for this demo.

  • Github Analytics - the app that has a REST endpoint and uses messaging. Our business application.
  • Github Webhook - project that emits messages that are used by Github Analytics. Our business application.
  • Eureka - simple Eureka Server. This is an infrastructure application.
  • Github Analytics Stub Runner Boot - Stub Runner Boot server to be used for tests with Github Analytics. Uses Eureka and Messaging. This is an infrastructure application.

5.1 Step by step

This is a guide for Concourse pipeline.

If you want to just run the demo as far as possible using PCF Dev and Docker Compose

5.1.1 Fork repos

There are 4 apps that are composing the pipeline

You need to fork only these. That’s because only then will your user be able to tag and push the tag to repo.

5.2 Concourse in K8S (Kubernetes)

The simplest way to deploy Concourse to K8S is to use Helm. +sample, opinionated one that you can use in your company.

All in all there are the following projects taking part in the whole microservice setup for this demo.

  • Github Analytics - the app that has a REST endpoint and uses messaging. Our business application.
  • Github Webhook - project that emits messages that are used by Github Analytics. Our business application.
  • Eureka - simple Eureka Server. This is an infrastructure application.
  • Github Analytics Stub Runner Boot - Stub Runner Boot server to be used for tests with Github Analytics. Uses Eureka and Messaging. This is an infrastructure application.

5.1 Step by step

This is a guide for Concourse pipeline.

If you want to just run the demo as far as possible using PCF Dev and Docker Compose

5.1.1 Fork repos

There are 4 apps that are composing the pipeline

You need to fork only these. That’s because only then will your user be able to tag and push the tag to repo.

5.2 Concourse in K8S (Kubernetes)

The simplest way to deploy Concourse to K8S is to use Helm. Once you have Helm installed and your kubectl is pointing to the cluster, just type this command to install the Concourse cluster in your K8S cluster.

$ helm install stable/concourse --name concourse

Once it’s done you’ll see the following output

1. Concourse can be accessed:
 
@@ -256,7 +256,7 @@ Congratulations. You have just deployed JFrog Artifactory Pro!
    Default credential for Artifactory:
    user: admin
    password: password

Next, we need to set up the repositories.

First, access the Artifactory URL and log in with -user, admin and password password.

Figure 5.1. Click on the Quick Setup

artifactory quick setup

Then, click on the Maven setup and click Create.

Figure 5.2. Create the Maven Repository

artifactory maven repo

5.2.2 Setup the fly CLI

If you go to Concourse website you should see sth like this:

  +user, admin and password password.

Figure 5.1. Click on the Quick Setup

artifactory quick setup

Then, click on the Maven setup and click Create.

Figure 5.2. Create the Maven Repository

artifactory maven repo

5.2.2 Setup the fly CLI

If you go to Concourse website you should see sth like this:

   

running concourse

   

You can click one of the icons (depending on your OS) to download fly, which is the Concourse CLI. Once you’ve downloaded that (and maybe added to your PATH) you can run:

fly --version

If fly is properly installed then it should print out the version.

5.2.3 Setup your credentials.yml

There is a sample credentials file called credentials-sample-k8s.yml prepared for k8s. You can use it as a base for your credentials.yml.

To allow the Concourse worker’s spawned container to connect to @@ -265,16 +265,16 @@ auth token.

To get the contents of CA for GCE just execute

echo "Visit http://127.0.0.1:8080 to use Concourse"
 $ kubectl port-forward --namespace default $POD_NAME 8080:8080
 Visit http://127.0.0.1:8080 to use Concourse

Log in (e.g. for Concourse running at 127.0.0.1 - if you don’t provide any value then localhost is assumed). If you execute this script (it assumes that either fly is on your PATH or it’s in the same folder as the script is):

$ fly -t k8s login -c http://localhost:8080 -u concourse -p concourse

Next run the command to create the pipeline.

$ ./set_pipeline.sh github-webhook k8s credentials-k8s.yml

5.2.5 Run the github-webhook pipeline

  - 

Figure 5.3. Click Login

concourse login

  - 

Figure 5.4. Pick main team

concourse team main

  - 

Figure 5.5. Log in with concourse user and concourse password

concourse user pass

  - 

Figure 5.6. Your screen should look more or less like this

concourse pipeline

  - 

Figure 5.7. Unpause the pipeline by clicking in the top lefr corner and then clicking the play button

start pipeline

  - 

Figure 5.8. Click 'generate-version'

generate version

  - 

Figure 5.9. Click + sign to start a new build

run pipeline

  - 

Figure 5.10. The job is pending

concourse pending

  - 

Figure 5.11. Job is pending in the main screen

job running

  - 

Figure 5.12. Job is running in the main screen

running pipeline

6. Concourse FAQ

6.1 Can I use the pipeline for some other repos?

Sure! Just change the app-url in credentials.yml!

6.2 Will this work for ANY project out of the box?

Not really. This is an opinionated pipeline that’s why we took some + 

Figure 5.3. Click Login

concourse login

  + 

Figure 5.4. Pick main team

concourse team main

  + 

Figure 5.5. Log in with concourse user and concourse password

concourse user pass

  + 

Figure 5.6. Your screen should look more or less like this

concourse pipeline

  + 

Figure 5.7. Unpause the pipeline by clicking in the top lefr corner and then clicking the play button

start pipeline

  + 

Figure 5.8. Click 'generate-version'

generate version

  + 

Figure 5.9. Click + sign to start a new build

run pipeline

  + 

Figure 5.10. The job is pending

concourse pending

  + 

Figure 5.11. Job is pending in the main screen

job running

  + 

Figure 5.12. Job is running in the main screen

running pipeline

6. Concourse FAQ

6.1 Can I use the pipeline for some other repos?

Sure! Just change the app-url in credentials.yml!

6.2 Will this work for ANY project out of the box?

Not really. This is an opinionated pipeline that’s why we took some opinionated decisions. Check out the documentation to see what those decisions are.

6.3 Can I modify this to reuse in my project?

Sure! It’s open-source! The important thing is that the core part of the logic is written in Bash scripts. That way, in the majority of cases, you could change only the bash scripts without changing the @@ -367,15 +367,15 @@ of Java installation and the others to another one.

< you’d have to go to Configure of the build step and modify the Git name / email. If you want to set it globally you’ll have to remove the section from the build step and follow these steps to set it globally.

You can set Git email / user globally like this:

  - 

Figure 7.1. Click 'Manage Jenkins'

manage jenkins

  - 

Figure 7.2. Click 'Configure System'

configure system

  - 

Figure 7.3. Fill out Git user information

git

  + 

Figure 7.1. Click 'Manage Jenkins'

manage jenkins

  + 

Figure 7.2. Click 'Configure System'

configure system

  + 

Figure 7.3. Fill out Git user information

git

   

Add Jenkins credentials for GitHub

The scripts will need to access the credential in order to tag the repo.

You have to set credentials with id: git.

Below you can find instructions on how to set a credential (e.g. for Cloud Foundry cf-test credential but remember to provide the one with id git).

  - 

Figure 7.4. Click 'Credentials, System'

credentials system

  - 

Figure 7.5. Click 'Global Credentials'

credentials global

  - 

Figure 7.6. Click 'Add credentials'

credentials add

  - 

Figure 7.7. Fill out the user / password and provide the git credential ID (in this example cf-test)

credentials example

  + 

Figure 7.4. Click 'Credentials, System'

credentials system

  + 

Figure 7.5. Click 'Global Credentials'

credentials global

  + 

Figure 7.6. Click 'Add credentials'

credentials add

  + 

Figure 7.7. Fill out the user / password and provide the git credential ID (in this example cf-test)

credentials example

   

7.3 Testing Jenkins scripts

./gradlew clean build

[Warning]Warning

The ran test only checks if your scripts compile.

7.4 How to work with Jenkins Job DSL plugin

Check out the tutorial. Provide the link to this repository in your Jenkins installation.

[Warning]Warning

Remember that views can be overridden that’s why the suggestion is to contain in one script all the logic needed to build a view for a single project (check out that spring_cloud_views.groovy is building all the spring-cloud views).

7.5 Docker Image

If you would like to run the pre-configured Jenkins image somewhere other than your local machine, we @@ -413,35 +413,35 @@ has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and `github-analytics'.

  - 

Figure 8.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  - 

Figure 8.2. Click the 'Build with parameters'

seed run

  - 

Figure 8.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  - 

Figure 8.4. This is how the results of seed should look like

seed built

8.1.5 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do + 

Figure 8.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  + 

Figure 8.2. Click the 'Build with parameters'

seed run

  + 

Figure 8.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  + 

Figure 8.4. This is how the results of seed should look like

seed built

8.1.5 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do run it you have to provide some properties. By default we create a seed that has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and github-analytics.

  - 

Figure 8.5. Click the 'github-webhook' view

seed views

  - 

Figure 8.6. Run the pipeline

pipeline run

  + 

Figure 8.5. Click the 'github-webhook' view

seed views

  + 

Figure 8.6. Run the pipeline

pipeline run

   

[Important]Important

If your build fails on the deploy previous version to stage due to missing jar, that means that you’ve forgotten to clear the tags in your repo. Typically that’s due to the fact that you’ve removed the Artifactory volume with deployed JAR whereas a tag in the repo is still pointing there. Check out this section on how to remove the tag.

  - 

Figure 8.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

  + 

Figure 8.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

   

[Important]Important

Most likely you will run out of memory so when reaching the stage environment it’s good to kill all apps on test. Check out the FAQ section for more details!

  - 

Figure 8.8. The full pipeline should look like this

pipeline finished

  + 

Figure 8.8. The full pipeline should look like this

pipeline finished

   

8.2 Declarative pipeline & Blue Ocean

You can also use the declarative pipeline approach with the Blue Ocean UI. Here is a step by step guide to run a pipeline via this approach.

The Blue Ocean UI is available under the blue/ URL. E.g. for Docker Machine based setup http://192.168.99.100:8080/blue.

  - 

Figure 8.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  - 

Figure 8.10. Your first run will look like this. Click Run button

blue 2

  - 

Figure 8.11. Enter parameters required for the build and click run

blue 3

  - 

Figure 8.12. A list of pipelines will be shown. Click your first run.

blue 4

  - 

Figure 8.13. State if you want to go to production or not and click Proceed

blue 5

  - 

Figure 8.14. The build is in progress…​

blue 6

  - 

Figure 8.15. The pipeline is done!

blue 7

  + 

Figure 8.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  + 

Figure 8.10. Your first run will look like this. Click Run button

blue 2

  + 

Figure 8.11. Enter parameters required for the build and click run

blue 3

  + 

Figure 8.12. A list of pipelines will be shown. Click your first run.

blue 4

  + 

Figure 8.13. State if you want to go to production or not and click Proceed

blue 5

  + 

Figure 8.14. The build is in progress…​

blue 6

  + 

Figure 8.15. The pipeline is done!

blue 7

   

[Important]Important

There is no possibility of restarting pipeline from specific stage, after failure. Please check out this issue for more information

[Warning]Warning

Currently there is no way to introduce manual steps in a performant way. Jenkins is blocking an executor when manual step is required. That means that you’ll run out of executors @@ -473,35 +473,35 @@ has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and `github-analytics'.

  - 

Figure 9.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  - 

Figure 9.2. Click the 'Build with parameters'

seed run

  - 

Figure 9.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  - 

Figure 9.4. This is how the results of seed should look like

seed built

9.1.4 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do + 

Figure 9.1. Click the 'jenkins-pipeline-seed-cf' job for Cloud Foundry and jenkins-pipeline-seed-k8s for Kubernetes

seed click

  + 

Figure 9.2. Click the 'Build with parameters'

seed run

  + 

Figure 9.3. The REPOS parameter should already contain your forked repos (you’ll have more properties than the ones in the screenshot)

seed

  + 

Figure 9.4. This is how the results of seed should look like

seed built

9.1.4 Run the github-webhook pipeline

We already create the seed job for you but you’ll have to run it. When you do run it you have to provide some properties. By default we create a seed that has all the properties options, but you can delete most of it. If you set the properties as global env variables you have to remove them from the seed.

Anyways, to run the demo just provide in the REPOS var the comma separated list of URLs of the 2 aforementioned forks of github-webhook and github-analytics.

  - 

Figure 9.5. Click the 'github-webhook' view

seed views

  - 

Figure 9.6. Run the pipeline

pipeline run

  + 

Figure 9.5. Click the 'github-webhook' view

seed views

  + 

Figure 9.6. Run the pipeline

pipeline run

   

[Important]Important

If your build fails on the deploy previous version to stage due to missing jar, that means that you’ve forgotten to clear the tags in your repo. Typically that’s due to the fact that you’ve removed the Artifactory volume with deployed JAR whereas a tag in the repo is still pointing there. Check out this section on how to remove the tag.

  - 

Figure 9.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

  + 

Figure 9.7. Click the manual step to go to stage (remember about killing the apps on test env). To do this click the ARROW next to the job name

pipeline manual

   

[Important]Important

Most likely you will run out of memory so when reaching the stage environment it’s good to kill all apps on test. Check out the FAQ section for more details!

  - 

Figure 9.8. The full pipeline should look like this

pipeline finished

  + 

Figure 9.8. The full pipeline should look like this

pipeline finished

   

9.2 Declarative pipeline & Blue Ocean

You can also use the declarative pipeline approach with the Blue Ocean UI. Here is a step by step guide to run a pipeline via this approach.

The Blue Ocean UI is available under the blue/ URL. E.g. for Docker Machine based setup http://192.168.99.100:8080/blue.

  - 

Figure 9.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  - 

Figure 9.10. Your first run will look like this. Click Run button

blue 2

  - 

Figure 9.11. Enter parameters required for the build and click run

blue 3

  - 

Figure 9.12. A list of pipelines will be shown. Click your first run.

blue 4

  - 

Figure 9.13. State if you want to go to production or not and click Proceed

blue 5

  - 

Figure 9.14. The build is in progress…​

blue 6

  - 

Figure 9.15. The pipeline is done!

blue 7

  + 

Figure 9.9. Open Blue Ocean UI and click on github-webhook-declarative-pipeline

blue 1

  + 

Figure 9.10. Your first run will look like this. Click Run button

blue 2

  + 

Figure 9.11. Enter parameters required for the build and click run

blue 3

  + 

Figure 9.12. A list of pipelines will be shown. Click your first run.

blue 4

  + 

Figure 9.13. State if you want to go to production or not and click Proceed

blue 5

  + 

Figure 9.14. The build is in progress…​

blue 6

  + 

Figure 9.15. The pipeline is done!

blue 7

   

[Important]Important

There is no possibility of restarting pipeline from specific stage, after failure. Please check out this issue for more information

[Warning]Warning

Currently there is no way to introduce manual steps in a performant way. Jenkins is blocking an executor when manual step is required. That means that you’ll run out of executors @@ -545,14 +545,14 @@ scripts without changing the whole pipeline.

git tag -l | xargs -n 1 git push --delete origin

10.8 I want to provide a different JDK version

  • by default we assume that you have jdk with id jdk8 configured
  • if you want a different one just override JDK_VERSION env var and point to the proper one
[Tip]Tip

The docker image comes in with Java installed at /usr/lib/jvm/java-8-openjdk-amd64. You can go to Global Tools and create a JDK with jdk8 id and JAVA_HOME pointing to /usr/lib/jvm/java-8-openjdk-amd64

To change the default one just follow these steps:

  - 

Figure 10.1. Click 'Manage Jenkins'

manage jenkins

  - 

Figure 10.2. Click 'Global Tool'

global tool

  - 

Figure 10.3. Click 'JDK Installations'

jdk installation

  - 

Figure 10.4. Fill out JDK Installation with path to your JDK

jdk

  + 

Figure 10.1. Click 'Manage Jenkins'

manage jenkins

  + 

Figure 10.2. Click 'Global Tool'

global tool

  + 

Figure 10.3. Click 'JDK Installations'

jdk installation

  + 

Figure 10.4. Fill out JDK Installation with path to your JDK

jdk

   

And that’s it!

10.9 Enable Groovy Token Macro Processing

With scripted that but if you needed to this manually then this is how to do it:

  - 

Figure 10.5. Click 'Manage Jenkins'

manage jenkins

  - 

Figure 10.6. Click 'Configure System'

configure system

  - 

Figure 10.7. Click 'Allow token macro processing'

groovy token

10.10 I want deployment to stage and prod be automatic

No problem, just set the property / env var to true

  • AUTO_DEPLOY_TO_STAGE to automatically deploy to stage
  • AUTO_DEPLOY_TO_PROD to automatically deploy to prod

10.11 I don’t want to test API compativility

No problem, just set the API_COMPATIBILITY_STEP_REQUIRED env variable + 

Figure 10.5. Click 'Manage Jenkins'

manage jenkins

  + 

Figure 10.6. Click 'Configure System'

configure system

  + 

Figure 10.7. Click 'Allow token macro processing'

groovy token

10.10 I want deployment to stage and prod be automatic

No problem, just set the property / env var to true

  • AUTO_DEPLOY_TO_STAGE to automatically deploy to stage
  • AUTO_DEPLOY_TO_PROD to automatically deploy to prod

10.11 I don’t want to test API compativility

No problem, just set the API_COMPATIBILITY_STEP_REQUIRED env variable to false and rerun the seed (you can pick it from the seed job’s properties too).

10.12 I can’t tag the repo!

When you get sth like this:

19:01:44 stderr: remote: Invalid username or password.
 19:01:44 fatal: Authentication failed for 'https://github.com/marcingrzejszczak/github-webhook/'
@@ -627,14 +627,14 @@ $ kubectl config set-context default-system --cluster=default-cluster --user=def
 $ kubectl config use-context default-system

11.5 Generate Minikube namespaces

With the running Minikube cluster we need to generate namespaces. Just execute the ./tools/k8s-helper.sh setup-namespaces to do this.

12. The demo setup (Cloud Foundry)

The demo uses 2 applications. Github Webhook and Github analytics code. Below you can -see an image of how these application communicate with each other.

Figure 12.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

  +see an image of how these application communicate with each other.

Figure 12.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

   

For the demo scenario we have two applications. Github Analytics and Github Webhook. Let’s imagine a case where Github is emitting events via HTTP. Github Webhook has an API that could register to such hooks and receive those messages. Once this happens Github Webhook sends a message by RabbitMQ to a channel. Github Analytics is - listening to those messages and stores them in a MySQL database.

Figure 12.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

  + listening to those messages and stores them in a MySQL database.

Figure 12.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

   

Github Analytics has its KPIs (Key Performance Indicators) monitored. In the case -of that application the KPI is number of issues.

Figure 12.3. Grafana alerts Slack over Prometheus metrics

demo alerting

  +of that application the KPI is number of issues.

Figure 12.3. Grafana alerts Slack over Prometheus metrics

demo alerting

   

Let’s assume that if we go below the threshold of X issues then an alert should be sent to Slack.

12.1 Deploying production applications to PCF Dev

In the real world scenario we wouldn’t want to automatically provision services like RabbitMQ, MySQL or Eureka each time we deploy a new application to production. Typically @@ -683,14 +683,14 @@ scrape_configs: - targets: ['github-analytics-sc-pipelines.cfapps.io']

A deployed version for the Spring Cloud Pipelines demo is available here

12.3 Running Grafana on CF

You can check out Toshiaki Maki’s code on how to automate Prometheus installation on CF.

Download tarball from https://grafana.com/grafana/download?platform=linux Next set http_port = 8080 in conf/default.ini. Then call

cf push sc-pipelines-grafana -b binary_buildpack -c './bin/grafana-server web' -m 64m

The demo is using Grafana Dashboard with ID 2471.

A deployed version for the Spring Cloud Pipelines demo is available here

13. The demo setup (Kubernetes)

The demo uses 2 applications. Github Webhook and Github analytics code. Below you can -see an image of how these application communicate with each other.

Figure 13.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

  +see an image of how these application communicate with each other.

Figure 13.1. Github Webhook listens to HTTP calls and sends a message to Github Analytics

demo

   

For the demo scenario we have two applications. Github Analytics and Github Webhook. Let’s imagine a case where Github is emitting events via HTTP. Github Webhook has an API that could register to such hooks and receive those messages. Once this happens Github Webhook sends a message by RabbitMQ to a channel. Github Analytics is - listening to those messages and stores them in a MySQL database.

Figure 13.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

  + listening to those messages and stores them in a MySQL database.

Figure 13.2. Github Analytics exposes metrics that are polled by Prometheus

demo metrics

   

Github Analytics has its KPIs (Key Performance Indicators) monitored. In the case -of that application the KPI is number of issues.

Figure 13.3. Grafana alerts Slack over Prometheus metrics

demo alerting

  +of that application the KPI is number of issues.

Figure 13.3. Grafana alerts Slack over Prometheus metrics

demo alerting

   

Let’s assume that if we go below the threshold of X issues then an alert should be sent to Slack.

13.1 Deploying production applications to Minikube

In the real world scenario we wouldn’t want to automatically provision services like RabbitMQ, MySQL or Eureka each time we deploy a new application to production. Typically