github.com/GoogleContainerTools/skaffold@v1.39.18/examples/dev-journey-buildpacks/tutorial.md (about) 1 # Skaffold Developer Journey with Buildpacks Tutorial 2 3 ## Introduction 4 5 ### What is this project? 6 7 Skaffold allows developers to easily transition from local development on minikube to remote development on an enterprise Kubernetes cluster managed by IT. During the transition from local to remote deployment, a security team might ask a developer to patch a library with a specific vulnerability in it. This is where Skaffold's support for buildpacks comes in handy. In this tutorial, you'll start out deploying an application locally, swap out buildpacks in the **skaffold.yaml** file to use the latest libraries, and then deploy the application to a remote Kubernetes cluster. 8 9 For a guided Cloud Shell tutorial on how a developer's journey might look in adopting Skaffold, follow: 10 11 [](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https://github.com/GoogleContainerTools/skaffold&cloudshell_workspace=examples/dev-journey-buildpacks&cloudshell_tutorial=tutorial.md) 12 13 ### What you'll learn 14 15 * How to develop on minikube locally and move to an enterprise managed kubernetes cluster with ease 16 * How to easily switch buildpack versions to comply with security demands 17 18 ___ 19 20 **Time to complete**: <walkthrough-tutorial-duration duration=15></walkthrough-tutorial-duration> 21 Click the **Start** button to move to the next step. 22 23 ## Prepare the Environment 24 25 ### Create a Project 26 Create a project called **skaffold-tutorial** with a valid billing account in the Google Cloud [Manage Resources Console](https://console.cloud.google.com/cloud-resource-manager). In the shell run: 27 ```bash 28 gcloud config set project skaffold-tutorial 29 ``` 30 31 ### Run the Setup Script 32 Run the start script to prepare the environment. The script will: 33 * Enable the GCE and GKE APIs, which is needed in order to spin up a GKE cluster 34 * Create a network and subnet for the GKE cluster to use 35 * Deploy a one node GKE cluster to optimize for cost 36 * Install the latest version of skaffold. Although Skaffold is already installed on cloud shell, we'll install the latest version for good measure. 37 ```bash 38 chmod +x start.sh && ./start.sh 39 ``` 40 **Note:** answer **y** when prompted to enable the GKE and GCE APIs 41 42 ### Start a Minikube cluster 43 44 We'll use minikube for local kubernetes development. Minikube is a tool that optimizes kubernetes for local deployments, which makes it perfect for development and testing. Cloud Shell already has minikube installed, but you can install it yourself by running **gcloud components install minikube** or following [these instructions](https://minikube.sigs.k8s.io/docs/start/). 45 46 Run: 47 ```bash 48 minikube start 49 ``` 50 51 ## Run the App to Minikube Using Skaffold 52 53 ### Deploy the App 54 Start skaffold in development mode which will constantly monitor the current directory for changes and kick off a new build and deploy whenever changes are detected. 55 ```bash 56 skaffold dev 57 ``` 58 59 **Important:** note the software versions under the **DETECTING** phase of the buildpack output. These will be important later. 60 61 We will be working in three terminals during this tutorial. The current terminal you're in will be referred to as **Terminal A**. Open a second terminal, which we will call **Terminal B**. In order to connect to the application to make sure its working, you need to start the minikube load balancer by running: 62 ```bash 63 minikube tunnel 64 ``` 65 66 Open a third terminal, which we will refer to as **Terminal C**. Find out the load balancer IP by recording the external IP as **EXTERNAL_IP** after running: 67 ```bash 68 kubectl get service 69 ``` 70 71 Ensure the app is responding by running: 72 ```bash 73 curl http://EXTERNAL_IP:8080 74 ``` 75 76 ### Change the App and Trigger a Redeploy 77 78 Edit the part of the application responsible for returning the "Hello World!" message you saw previously: 79 ```bash 80 vim src/main/java/hello/HelloController.java 81 ``` 82 Change the return line to **return "Hello, Skaffold!"**. 83 84 Switch back to the **Terminal A** and see that its rebuilding and redeploying the app. 85 86 Switch back to the **Terminal C** and run the following command to watch until only one pod is running: 87 ```bash 88 watch kubectl get pods 89 ``` 90 91 Once there is only one pod running, meaning the latest pod is deployed, see that your app changes are live: 92 ```bash 93 curl http://EXTERNAL_IP:8080 94 ``` 95 96 ### Updating Buildpacks 97 98 Perhaps the best benefit of buildpacks is that it reduces how much work developers need to do to patch their applications if the security team highlights a library vulnerability. [Google Cloud buildpacks](https://cloud.google.com/blog/products/containers-kubernetes/google-cloud-now-supports-buildpacks) use a managed base Ubuntu 18.04 image that is regularly scanned for security vulnerabilities; any detected vulnerabilities are automatically patched. These patches are included in the latest revision of the builder. A builder contains one or more buildpacks supporting several languages. Our **skaffold.yaml** points to an older builder release, which uses older buildpack versions that may pull in vulnerable libraries. We will be updating the builder release to use the most up-to-date buildpacks. 99 100 Edit the **skaffold.yaml** file: 101 ```bash 102 vim skaffold.yaml 103 ``` 104 Update the builder line to **gcr.io/buildpacks/builder:v1**, which will use the latest builder that has more up-to-date buildpacks. 105 106 Switch back to the **Terminal A** and see that its rebuilding and redeploying the app. 107 108 **IMPORTANT:** compare the software versions under the **DETECTING** phase of the buildpack output to the ones you saw before. The builder is now using newer buildpack versions. 109 110 Switch back to **Terminal C** and run the following command to watch until only one pod is running: 111 ```bash 112 watch kubectl get pods 113 ``` 114 115 Once there is only one pod running, meaning the latest pod is deployed, see that your app changes are live: 116 ```bash 117 curl http://EXTERNAL_IP:8080 118 ``` 119 120 ## Deploy the App to Enterprise GKE Cluster Using Skaffold 121 122 ### Switch kubectl Context to the Enterprise GKE Cluster 123 124 Switch your local kubectl context to the enterprise GKE cluster and get the latest credentials: 125 ```bash 126 gcloud container clusters get-credentials $(gcloud config get-value project)-cluster --region us-central1-a 127 ``` 128 129 See that kubectl is now configured to use the remote kubernetes cluster instead of minikube (denoted by the asterisk) 130 ```bash 131 kubectl config get-contexts 132 ``` 133 134 ### Deploy the App 135 136 Attempt to deploy the app by running: 137 ```bash 138 skaffold dev --default-repo=gcr.io/$(gcloud config get-value project) 139 ``` 140 141 Switch back to **Terminal C** and run the following command to watch until only one pod is running: 142 ```bash 143 watch kubectl get pods 144 ``` 145 146 Run the following command. Once an external IP is assigned to the service, record it as **EXTERNAL_IP**: 147 ```bash 148 watch kubectl get service 149 ``` 150 151 See that your app changes are now live on an Internet-accessible IP: 152 ```bash 153 curl http://EXTERNAL_IP:8080 154 ``` 155 156 ## Congratulations! 157 158 That's the end of the tutorial. You now know how to seamlessly transition between local kubernetes development and remote development on a kubernetes cluster managed by your enterprise IT team. Along the way you learned how to quickly patch your application libraries to comply with security standards. 159 160 I hope this tutorial was informative. Good luck on your journey with Skaffold!