github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v1/content/en/docs/tutorials/developer-journey.md (about) 1 --- 2 title: "Developer Journey with Buildpacks" 3 linkTitle: "Developer Journey" 4 weight: 100 5 --- 6 7 # Skaffold Developer Journey with Buildpacks Tutorial 8 9 ## Introduction 10 11 ### What is this project? 12 13 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. 14 15 For a guided Cloud Shell tutorial on how a developer's journey might look in adopting Skaffold, follow: 16 17 [](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) 18 19 ### What you'll learn 20 21 * How to develop on minikube locally and move to an enterprise managed kubernetes cluster with ease 22 * How to easily switch buildpack versions to comply with security demands 23 24 ___ 25 26 **Time to complete**: <walkthrough-tutorial-duration duration=15></walkthrough-tutorial-duration> 27 Click the **Start** button to move to the next step. 28 29 ## Prepare the Environment 30 31 ### Create a Project 32 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: 33 ```bash 34 gcloud config set project skaffold-tutorial 35 ``` 36 37 ### Run the Setup Script 38 Run the start script to prepare the environment. The script will: 39 * Enable the GCE and GKE APIs, which is needed in order to spin up a GKE cluster 40 * Create a network and subnet for the GKE cluster to use 41 * Deploy a one node GKE cluster to optimize for cost 42 * Install the latest version of skaffold. Although Skaffold is already installed on cloud shell, we'll install the latest version for good measure. 43 ```bash 44 chmod +x start.sh && ./start.sh 45 ``` 46 **Note:** answer **y** when prompted to enable the GKE and GCE APIs 47 48 ### Start a Minikube cluster 49 50 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/). 51 52 Run: 53 ```bash 54 minikube start 55 ``` 56 57 ## Run the App to Minikube Using Skaffold 58 59 ### Deploy the App 60 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. 61 ```bash 62 skaffold dev 63 ``` 64 65 **Important:** note the software versions under the **DETECTING** phase of the buildpack output. These will be important later. 66 67 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: 68 ```bash 69 minikube tunnel 70 ``` 71 72 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: 73 ```bash 74 kubectl get service 75 ``` 76 77 Ensure the app is responding by running: 78 ```bash 79 curl http://EXTERNAL_IP:8080 80 ``` 81 82 ### Change the App and Trigger a Redeploy 83 84 Edit the part of the application responsible for returning the "Hello World!" message you saw previously: 85 ```bash 86 vim src/main/java/hello/HelloController.java 87 ``` 88 Change the return line to **return "Hello, Skaffold!"**. 89 90 Switch back to the **Terminal A** and see that its rebuilding and redeploying the app. 91 92 Switch back to the **Terminal C** and run the following command to watch until only one pod is running: 93 ```bash 94 watch kubectl get pods 95 ``` 96 97 Once there is only one pod running, meaning the latest pod is deployed, see that your app changes are live: 98 ```bash 99 curl http://EXTERNAL_IP:8080 100 ``` 101 102 ### Updating Buildpacks 103 104 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. 105 106 Edit the **skaffold.yaml** file: 107 ```bash 108 vim skaffold.yaml 109 ``` 110 Update the builder line to **gcr.io/buildpacks/builder:v1**, which will use the latest builder that has more up-to-date buildpacks. 111 112 Switch back to the **Terminal A** and see that its rebuilding and redeploying the app. 113 114 **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. 115 116 Switch back to **Terminal C** and run the following command to watch until only one pod is running: 117 ```bash 118 watch kubectl get pods 119 ``` 120 121 Once there is only one pod running, meaning the latest pod is deployed, see that your app changes are live: 122 ```bash 123 curl http://EXTERNAL_IP:8080 124 ``` 125 126 ## Deploy the App to Enterprise GKE Cluster Using Skaffold 127 128 ### Switch kubectl Context to the Enterprise GKE Cluster 129 130 Switch your local kubectl context to the enterprise GKE cluster and get the latest credentials: 131 ```bash 132 gcloud container clusters get-credentials $(gcloud config get-value project)-cluster --region us-central1-a 133 ``` 134 135 See that kubectl is now configured to use the remote kubernetes cluster instead of minikube (denoted by the asterisk) 136 ```bash 137 kubectl config get-contexts 138 ``` 139 140 ### Deploy the App 141 142 Attempt to deploy the app by running: 143 ```bash 144 skaffold dev --default-repo=gcr.io/$(gcloud config get-value project) 145 ``` 146 147 Switch back to **Terminal C** and run the following command to watch until only one pod is running: 148 ```bash 149 watch kubectl get pods 150 ``` 151 152 Run the following command. Once an external IP is assigned to the service, record it as **EXTERNAL_IP**: 153 ```bash 154 watch kubectl get service 155 ``` 156 157 See that your app changes are now live on an Internet-accessible IP: 158 ```bash 159 curl http://EXTERNAL_IP:8080 160 ``` 161 162 ## Congratulations! 163 164 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. 165 166 I hope this tutorial was informative. Good luck on your journey with Skaffold!