Как я могу развернуть сервис GAE с локальной зависимостью npm?

Question

Я новичок в Google Cloud и, похоже, не могу понять, как развернуть службу Google App Engine, которая имеет локальную зависимость. У меня есть такая структура проекта (мой стек - TypeScript, nest JS, React):

-frontend
    app.yaml
    package.json
-backend
    app.yaml
    package.json
-common
    package.json
dispatch.yaml

Пакет frontend развертывает код stati c для службы default, и Пакет backend развертывается в сервисе api. Пакет common содержит некоторый код, которым я хочу поделиться между передней и задней частью. Они включают его в свои package.json файлы, например так:

dependencies: {
    common: "file:../common"
}

Эта структура отлично работает локально. Проблема в том, что при развертывании бэкэнда происходит сбой npm install, поскольку он не может найти пакет common. Это имеет смысл, так как я понимаю, что он будет загружать только содержимое backend в этот сервис. Но как правильно достичь этого?

Полагаю, я мог бы просто развернуть одну службу, которая содержит весь код, и получить мой package.json делегат верхнего уровня npm start для package.json бэкэнда , Но это работает только потому, что мой интерфейс полностью настроен c, поэтому у меня есть только один пакет, для вызова которого требуется npm start. Кажется, что должен быть лучший способ справиться с этим, потому что этот подход сломался бы, если бы у меня было два отдельных бэкэнда, каждый из которых нуждался в своих npm start.

Я предполагаю, что думаю о некоторых это в корне неверно, но мне нужна помощь, чтобы выяснить, что это такое.

Answer 1

Дело в том, что вы определяете 2 службы App Engine, frontend и backend, которые будут упакованы независимо и установлены в разных экземплярах, они никогда не будут сосуществовать в одном экземпляре. Таким образом, оба должны будут включать общий пакет.

Когда вы запускаете gcloud app deploy, папка, содержащая файл app.yaml для этой службы, считается папкой root, а файлы и папки в дереве выигрываются. не будет развернуто, как вы упомянули.

Я понимаю, что с точки зрения разработки имеет смысл иметь общий пакет, общий для обеих служб, поскольку он позволяет избежать дублирования кода. Одним из способов управления этим является использование Cloud Build для создания конвейера сборки, который будет обрабатывать включение этого общего кода в обе службы и развертывать их по отдельности. Например, что-то вроде этого:

steps:
- name: ubuntu
  id: 'copy-file'
  args:
  - '-c'
  - |
        cp ./common/package.json frontend/ && cp ./common/package.json backend/
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy']
  dir: 'frontend/'
  timeout: '1600s'
  waitFor: ['copy-file']
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy']
  dir: 'backend/'
  timeout: '1600s'
  waitFor: ['copy-file']

На первом шаге будет скопирован общий пакет в оба каталога (вам нужно обновить общий путь зависимости в вашем package.json, так как он теперь будет в тот же каталог). Следующие 2 шага будут выполняться параллельно (оба ждут первого шага до конца sh) и развернут каждый сервис отдельно (обратите внимание на параметр dir ).

Затем вы можете развернуть свои службы, выполнив следующую команду в каталоге root:

gcloud builds submit

Обратите внимание, что при этом всегда будут развернуты обе службы.

Если вы предпочитаете иметь возможность развертывать один сервис, а не другой, вы можете определить 2 файла облачных сборок, например:

cloudbuild-frontend.yaml :

steps:
- name: ubuntu
  args:
  - '-c'
  - |
        cp ./common/package.json frontend/
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy']
  dir: 'frontend/'
  timeout: '1600s'

cloudbuild-backend.yaml :

steps:
- name: ubuntu
  args:
  - '-c'
  - |
        cp ./common/package.json backend/
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy']
  dir: 'backend/'
  timeout: '1600s'

В результате вы получите дерево, подобное этому:

-frontend
    app.yaml
    package.json
-backend
    app.yaml
    package.json
-common
    package.json
cloudbuild-frontend.yaml
cloudbuild-backend.yaml
dispatch.yaml

После этого вы сможете развернуть одну службу или другой, запустив либо gcloud builds submit --config=cloudbuild-frontend.yaml или gcloud builds submit --config=cloudbuild-backend.yaml

Answer 2

У меня была похожая ситуация с Firebase, где у меня был код, которым я хотел поделиться между передней и задней частью, без необходимости сохранять изменения в двух местах.

Поскольку вы используете Typescript, вы можете просто использовать tsc, компилятор Typescript, чтобы вывести ваш общий файл в ваши как переднюю, так и внутреннюю папки, сконфигурировав выходные данные в вашем tsconfig.json файл. https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

Для фронта вы должны вывести его в виде .js файла и просто загрузить его как <script src='myCommonFile.js>. В конце вы бы require или import это.

Тогда задача состоит в том, чтобы написать код таким образом, чтобы его можно было использовать как в среде браузера, так и в среде узлов. Цитируя код из этого поста SO :

(function(exports){

    // Your code goes here. For example: 
   exports.test = function(){
        return 'hello world'
    };

})(typeof exports === 'undefined'? this.mymodule = {} : exports);

Таким образом, если exports не определено, вы должны быть в браузере, и в этом случае mymodule объявляется в window (т. Е. this). Или, если определено exports, это в контексте node, и в этом случае вы можете просто var mymodule = require('mymodule'). И в любой среде вы можете использовать его как mymodule.test(). Острота!

Answer 3

Я не знаком с GAE, но мое решение для совместного использования такого кода заключается в упаковке общего кода в виде пакета NPM и его импорте в серверные и клиентские приложения

Если вы выберете чтобы ваши общие пакеты не публиковались c, вы все равно можете установить их непосредственно из репозитория git. Имейте в виду, что это может усложнить ваше развертывание, поскольку вам придется настроить ключи S SH, чтобы разрешить клонирование вашего частного репозитория.