5

I am currently migrating our monorepo to yarn workspaces. It contains multiple packages and services. Services depends on packages in their respective package.json. I would like to deploy my services to Google App Engine without having to publish the packages to a private npm registry.

I managed to deploy a single service by using a custom runtime and by moving the app.yaml and the Dockerfile to the root of the monorepo in order to have access to the packages and the service in the build context. The issue is that I have multiple services and I cannot have all the dockerfiles at the root of the monorepo, as they have to be named Dockerfile and that I cannot change the build context.

I see 2 naive solutions:

The first would be to move the app.yaml and Dockerfile of the corresponding service to the root of the monorepo before deploying. But this looks quite dirty and would make the CI code very complicated.

The second would be to have a single Dockerfile and service1.yaml, service2.yaml etc. at the root of the monorepo and to pass variables to the Dockerfile. The problem is that I don't see any way in App Engine documentation to pass variables to the Dockerfile of a custom runtime.

My dream solution would be to be able to keep each Dockerfile and app.yaml in the directory of their respective services and to be able to set the build context through the gcloud CLI (like we can do in docker-compose). Example:

project
├── package.json
├── packages
│   ├── package1
│   │   ├── package.json
│   │   └── src
│   ├── package2
│   │   ├── package.json
│   │   └── src
│   └── package3
│       ├── package.json
│       └── src
├── services
│   ├── service1
│   │   ├── app.yaml
│   │   ├── Dockerfile
│   │   ├── package.json
│   │   └── src
│   └── service2
│       ├── app.yaml
│       ├── Dockerfile
│       ├── package.json
│       └── src
└── yarn.lock

and run something like: gcloud app deploy services/service1/app.yaml --build-context=.

But I don't see any way of doing this in the documentation.

Do you know how I can get closer to my "dream solution"?

RobC
  • 22,977
  • 20
  • 73
  • 80
Gabriel Colson
  • 53
  • 4
  • 1
    What about building the Docker images beforehand (even with docker-compose) and pushing them to `gcr.io` (Google Container Registry) so these can be used on deploy time with the `--image-url` [option](https://cloud.google.com/sdk/gcloud/reference/app/deploy#--image-url)? – bhito Jun 17 '20 at 08:55
  • @bhito I didn't think of doing it this way but that could work. Thanks! – Gabriel Colson Jun 22 '20 at 08:22
  • Glad that I could be of help, I will add it as an answer to give it more visibility to the community :) – bhito Jun 22 '20 at 09:35

1 Answers1

3

Adding possible option suggested in comments to give more visibility.

One possibility would be keeping the docker-compose workflow that you were using and integrate it with your App Engine deploys.

As you were already building your docker images with docker-compose in order to specify the build context, you can push the result of the build operations to Google's Container Registry so the images can be later used to deploy App Engine by using the --image-url flag.

bhito
  • 2,083
  • 7
  • 13