0

I'm currently looking at GKE and some of the tutorials on google cloud. I was following this one here https://cloud.google.com/solutions/integrating-microservices-with-pubsub#building_images_for_the_app (source code https://github.com/GoogleCloudPlatform/gke-photoalbum-example)

This example has 3 deployments and one service. The example tutorial has you deploy everything via the command line which is fine and all works. I then started to look into how you could automate deployments via cloud build and discovered this:

https://cloud.google.com/build/docs/deploying-builds/deploy-gke#automating_deployments

These docs say you can create a build configuration for your a trigger (such as pushing to a particular repo) and it will trigger the build. The sample yaml they show for this is as follows:

# deploy container image to GKE
- name: "gcr.io/cloud-builders/gke-deploy"
  args:
  - run
  - --filename=kubernetes-resource-file
  - --image=gcr.io/project-id/image:tag
  - --location=${_CLOUDSDK_COMPUTE_ZONE}
  - --cluster=${_CLOUDSDK_CONTAINER_CLUSTER}

I understand how the location and cluster parameters can be passed in and these docs also say the following about the resource file (filename parameter) and image parameter:

kubernetes-resource-file is the file path of your Kubernetes configuration file or the directory path containing your Kubernetes resource files.

image is the desired name of the container image, usually the application name.

Relating this back to the demo application repo where all the services are in one repo, I believe I could supply a folder path to the filename parameter such as the config folder from the repo https://github.com/GoogleCloudPlatform/gke-photoalbum-example/tree/master/config

But the trouble here is that those resource files themselves have an image property in them so I don't know how this would relate to the image property of the cloud build trigger yaml. I also don't know how you could then have multiple "image" properties in the trigger yaml where each deployment would have it's own container image.

I'm new to GKE and Kubernetes in general, so I'm wondering if I'm misinterpreting what the kubernetes-resource-file should be in this instance.

But is it possible to automate deploying of multiple deployments/services in this fashion when they're all bundled into one repo? Or have Google just over simplified things for this tutorial - the reality being that most services would be in their own repo so as to be built/tested/deployed separately?

Either way, how would the image property relate to the fact that an image is already defined in the deployment yaml? e.g:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: photoalbum-app
  name: photoalbum-app
spec:
  replicas: 3
  selector:
    matchLabels:
      name: photoalbum-app
  template:
    metadata:
      labels:
        name: photoalbum-app
    spec:
      containers:
      - name: photoalbum-app
        image: gcr.io/[PROJECT_ID]/photoalbum-app@[DIGEST]
        tty: true
        ports:
        - containerPort: 8080
        env:
        - name: PROJECT_ID
          value: "[PROJECT_ID]"

 
TommyBs
  • 9,354
  • 4
  • 34
  • 65

1 Answers1

1

The command that you use is perfect for testing the deployment of one image. But when you work with Kubernetes (K8S), and the managed version of GCP (GKE), you usually never do this.

You use YAML file to describe your deployments, services and all other K8S object that you want. When you deploy, you can perform something like this

kubectl apply -f <file.yaml>

If you have several file, you can use wildcard is you want

kubectl apply -f config/*.yaml

If you prefer to use only one file, you can separate the object with ---

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:...
...
guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • Sorry I’m a bit confused about how this would work with the continuous deployment from cloud build? Do I just omit the image parameter for the cloud build deployment yaml and rely on the config folder? – TommyBs Mar 10 '21 at 08:31
  • No, you need to update the YAML file and then apply them. Or to rebuild them. – guillaume blaquiere Mar 10 '21 at 08:35
  • Sorry, I'm still not sure I follow. I want to trigger cloud build on commit to a repo and build all 3 deployments and service as in the tutorial. Are you saying this wouldn't be the way to go or it isn't possible with cloud build specifically on commit? I noticed the following comment on the gke-deploy page "gke-deploy can only reference one image in your build configuration file. If your Kubernetes resource files contain multiple image references, only the images beginning with gcr/project-id/image will be updated to reference the specified tag." Would I just use an inline build script? – TommyBs Mar 10 '21 at 09:11
  • I believe I've found this repo https://github.com/GoogleCloudPlatform/software-delivery-workshop/blob/master/labs/gke-progression/builder/cloudbuild-prod.yaml relating to this codelab https://codelabs.developers.google.com/codelabs/cloud-builder-gke-continuous-deploy/index.html#0 which I believe is what I need to investigate – TommyBs Mar 10 '21 at 10:02
  • Agree, the line 65 of the github repo show you how to replace the latest image name in the yaml file. And the following line applied the change. – guillaume blaquiere Mar 10 '21 at 19:17