You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+123-47
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ This tutorial launches a Kubernetes cluster on [Google Container Engine](https:/
8
8
9
9
If you are running this tutorial at home, you will need a Google Cloud Platform account. If you don't have one, sign up for the [free trial](https://cloud.google.com/free).
10
10
11
-
To complete this tutorial, you will need to following tools installed:
11
+
To complete this tutorial, you will need the following tools installed:
If you get an error, make sure you enable the Container Engine API [here](https://console.cloud.google.com/apis/api/container.googleapis.com/overview).
32
35
33
-
2. Run the hello world [deployment](./hello-node/deployment.yaml):
36
+
*Tip:* To enable kubectl autocomplete run `source <(kubectl completion bash)`
34
37
35
-
`kubectl apply -f ./hello-node/deployment.yaml`
38
+
2. Run the hello world [deployment](./01-hello-node/deployment.yaml):
36
39
37
-
Expose the container with a [service](./hello-node/service.yaml):
You can see the all pods with the following command:
54
64
55
65
`kubectl get pods`
56
66
57
-
## Step 3: Hello world is boring, let's update the app
67
+
## Step 3: Hello World is boring, let's update the app
68
+
69
+
The new app allows you to upload a picture, flips it around, and displays it.
70
+
71
+
You can see the source code [here](./imageflipper-app/index.js).
72
+
73
+
Lets package the new app into a container so we can run it on Kubernetes.
74
+
75
+
The specification to build our container image can be found in the [Dockerfile](./imageflipper-app/Dockerfile).
76
+
77
+
There are 2 options to build our container, locally or with the [Google Container Builder](https://cloud.google.com/container-builder). Chose one of the two.
78
+
79
+
### Option 1 - Locally
80
+
81
+
To make the build a bit easier we use a [Makefile][./imageflipper-app/Makefile]. It will build the container image, tag it with the current version (obtained with `git describe --always`) and optionally push it to the [Google Container Registry](https://gcr.io).
58
82
59
-
The new app will take a picture, flip it around, and return it.
83
+
To build the container run:
60
84
61
-
You can see the source code [here](./rolling-update/index.js).
85
+
`cd imageflipper-app && make container && cd ..`
62
86
63
-
The Dockerfile for this container can be found here.
87
+
To push the container image to the Container registry run:
64
88
65
-
Build the Docker Container using [Google Container Builder](https://cloud.google.com/container-builder):
This will automatically build and push this Docker image to [Google Container Registry](https://gcr.io).
93
+
[Google Container Builder](https://cloud.google.com/container-builder) will build your containers for you remotely on GCP. To submit a build run the following command:
70
94
71
-
Now, we are going to update the deployment created in the first step. You can see the new YAML file [here](/rolling-update/deployment.yaml).
Now, we are going to update the deployment created in [Step 1](#step-1:-create-cluster-and-deploy-hello-world). You can see the new YAML file [here](/02-rolling-update/deployment.yaml.template).
100
+
101
+
Make a copy of the template file [deployment.yaml.template](./02-rolling-update/deployment.yaml.template) and save it in the same folder as `deployment.yaml`. Replace the <PROJECT_ID> and <VERSION> placeholders with your Project ID and the current git version(`git describe --always`).
102
+
You can use the following command to do all this in one step:
This will replace all the old containers with the new ones. Kubernetes will perform a rolling update; it will delete one old container at a time and replace it with a new one.
82
111
83
112
You can watch the containers being updated with this command:
84
113
85
-
`watch kubectl get pods`
114
+
`watch -n1 kubectl get pods`
86
115
87
116
Once it is done, press `ctrl + c` to quit.
88
117
89
-
If you visit the website now, you can see the updated website!
118
+
If you refresh the page pointing to the external ip of your service now, you'll see the updated website!
90
119
91
-
## Step 4: Backend Service
120
+
## Step 4: Splitting the app into Microservices
92
121
93
-
The web frontend is created, but let's split the monolith into microservices. The backend service will do the image manipulation and will expose a REST API that the frontend service will communicate with.
122
+
The imageflipper app is created and running, but what if you want to innovate on the image flipping independent of the frontend? We need to separate these two parts. Lets create a backend service that does the image manipulation and will expose a REST API that the frontend app can communicate with.
94
123
95
-
You can see the source code for the service [here](./second-service/index.js).
124
+
You can see the source code for the backend service [here](./imageflipper-service/index.js).
96
125
97
-
Build the Docker Container using [Google Container Builder](https://cloud.google.com/container-builder):
126
+
You again have the 2 options from [Step 3](#step-3:-hello-world-is-boring,-let's-update-the-app) to build your container.
`cd imageflipper-service && make push-gcr && cd ..`
100
129
101
-
The service.yaml file for the backend service is very similar to the frontend service, but it does not specify `type: LoadBalancer`. This will prevent Kubernetes from spinning up a Cloud Load Balancer, and instead the service will only be accessable from inside the cluster.
130
+
Run the backend [deployment](./imageflipper-service/deployment.yaml):
102
131
103
-
Run the backend [deployment](./second-service/deployment.yaml):
The service.yaml file for the backend service is very similar to the frontend service, but it does not specify `type: LoadBalancer`. This will make the service a cluster local service instead that is only accessible from inside the cluster.
108
137
109
-
Expose the container with a [service](./second-service/service.yaml):
138
+
Make the backend pods discoverable and addressable with a [service](./imageflipper-service/service.yaml):
## Step 5: Update Frontend Service to use the Backend with a Blue-Green deployment
114
143
115
-
Now the backend service is running, you need to update the frontend to use the new backend.
144
+
Now that the backend service is running, we need to update the frontend to use the new backend.
116
145
117
-
The new code is [here](./blue-green/index.js).
146
+
Make the changes in [imageflipper-app/index.js](./imageflipper-app/index.js) and update the `/api/photo` endpoint to use the new backend. Don't cheat, but if you need "inspiration" you can find the solution [here](./imageflipper-app/index.js.v2).
118
147
119
-
Instead of doing a rolling update like we did before, we are going to use a Blue-Green strategy.
148
+
To create a new git version we need to commit our changes. Run the following command to commit the changes and tag the new version.
120
149
121
-
This means we will spin up a new deployment of the frontend, wait until all containers are created, then configure the service to send traffic to the new deployment, and finally spin down the old deployment. This allows us to make sure that users don't get different versions of the app, smoke test the new deployment at scale, and a few other benefits. You can read more about [Blue-Green Deployments vs Rolling Updates here](http://stackoverflow.com/questions/23746038/canary-release-strategy-vs-blue-green).
Now we can build our new frontend container image:
159
+
160
+
`cd imageflipper-app && make push-gcr && cd ..`
161
+
162
+
Instead of doing a rolling update like we did before, we are going to use a Blue-Green strategy this time.
163
+
164
+
This means we will spin up a new deployment of the frontend, wait until all containers are created, then configure the service to send traffic to the new deployment, and finally spin down the old deployment. This allows us to make sure that users don't get different versions of the app, smoke test the new deployment at scale, and a few other benefits. You can read more about [Blue-Green Deployments vs Rolling Updates here](http://stackoverflow.com/questions/23746038/canary-release-strategy-vs-blue-green).
126
165
127
166
Spin up the the new deployment with the following command:
You can see all the containers running with this command:
172
+
Check if the new version is running with the following command:
134
173
135
174
`kubectl get pods`
136
175
137
-
Now, we need to edit the service to point to this new deployment. The new service definition is [here](./blue-green/service.yaml). Notice the only thing we changed is the selector.
176
+
To test the service we need to make the new version accessible through a Kubernetes service.
138
177
139
-
`kubectl apply -f ./blue-green/service.yaml`
178
+
Create the `hello-node-test` service with the following command:
140
179
141
-
At this point, you can visit the website and the new code will be live. Once you are happy with the results, you can turn down the green deployment.
180
+
`kubectl apply -f ./03-blue-green/service.yaml`
181
+
182
+
Wait for the external ip to be assigned:
183
+
184
+
`watch -n1 kubectl get svc`
185
+
186
+
Once the external ip is assigned for the `hello-node-test` service direct your browser in a new tab to it. Verify if everything works. Once you're happy, we can switch over the existing (production) `hello-node` service to the new frontend.
187
+
188
+
To do this, we use the `kubectl edit` command:
189
+
190
+
`kubectl edit svc hello-node`
191
+
192
+
Look for the selector and change it to `hello-node-green`:
193
+
194
+
Before:
195
+
196
+
```
197
+
...
198
+
selector:
199
+
name: hello-node-green
200
+
...
201
+
```
202
+
203
+
After:
204
+
205
+
```
206
+
...
207
+
selector:
208
+
name: hello-node-blue
209
+
...
210
+
```
211
+
212
+
213
+
At this point, you can go back to the original browser tab were you had the first version open and verify the new code will be live. Once you are happy with the results, you can turn down the green deployment.
0 commit comments