CODEWITHSUNDEEP
kubernetesgoogle-kubernetes-enginegoogle-cloud-buildcloudbuild.yaml
TommyBs
TommyBs

Reputation: 9648

GKE automating deploy of multiple deployments/services with different images

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]"

Upvotes: 0

Views: 1007

Answers (1)

guillaume blaquiere
guillaume blaquiere

Reputation: 75970

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:...
...

Upvotes: 1

Related Questions