integration/examples/dev-journey-buildpacks/tutorial.md
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.
For a guided Cloud Shell tutorial on how a developer's journey might look in adopting Skaffold, follow:
Time to complete: <walkthrough-tutorial-duration duration=15></walkthrough-tutorial-duration> Click the Start button to move to the next step.
Create a project called skaffold-tutorial with a valid billing account in the Google Cloud Manage Resources Console. In the shell run:
gcloud config set project skaffold-tutorial
Run the start script to prepare the environment. The script will:
chmod +x start.sh && ./start.sh
Note: answer y when prompted to enable the GKE and GCE APIs
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.
Run:
minikube start
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.
skaffold dev
Important: note the software versions under the DETECTING phase of the buildpack output. These will be important later.
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:
minikube tunnel
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:
kubectl get service
Ensure the app is responding by running:
curl http://EXTERNAL_IP:8080
Edit the part of the application responsible for returning the "Hello World!" message you saw previously:
vim src/main/java/hello/HelloController.java
Change the return line to return "Hello, Skaffold!".
Switch back to the Terminal A and see that its rebuilding and redeploying the app.
Switch back to the Terminal C and run the following command to watch until only one pod is running:
watch kubectl get pods
Once there is only one pod running, meaning the latest pod is deployed, see that your app changes are live:
curl http://EXTERNAL_IP:8080
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 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.
Edit the skaffold.yaml file:
vim skaffold.yaml
Update the builder line to gcr.io/buildpacks/builder:v1, which will use the latest builder that has more up-to-date buildpacks.
Switch back to the Terminal A and see that its rebuilding and redeploying the app.
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.
Switch back to Terminal C and run the following command to watch until only one pod is running:
watch kubectl get pods
Once there is only one pod running, meaning the latest pod is deployed, see that your app changes are live:
curl http://EXTERNAL_IP:8080
Switch your local kubectl context to the enterprise GKE cluster and get the latest credentials:
gcloud container clusters get-credentials $(gcloud config get-value project)-cluster --region us-central1-a
See that kubectl is now configured to use the remote kubernetes cluster instead of minikube (denoted by the asterisk)
kubectl config get-contexts
Attempt to deploy the app by running:
skaffold dev --default-repo=gcr.io/$(gcloud config get-value project)
Switch back to Terminal C and run the following command to watch until only one pod is running:
watch kubectl get pods
Run the following command. Once an external IP is assigned to the service, record it as EXTERNAL_IP:
watch kubectl get service
See that your app changes are now live on an Internet-accessible IP:
curl http://EXTERNAL_IP:8080
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.
I hope this tutorial was informative. Good luck on your journey with Skaffold!