Использование подмодуля git во время сборки Docker - PullRequest
0 голосов
/ 18 сентября 2018

Я создаю приложение, в котором есть несколько разных сервисов.Я использую docker и docker-compose для создания всех сервисов.Однако есть некоторый код, который мне нужно разделить между сервисами, в частности код ORM.Моя проблема в том, что когда я пытаюсь вызвать git submodule update --init, я получаю следующую ошибку:

Step 6/8 : RUN git submodule update --init
 ---> Running in 88e2dcfa5b36
fatal: Not a git repository: ../.git/modules/my-repo
ERROR: Service 'my-repo' failed to build: The command '/bin/sh -c git submodule update --init' returned a non-zero code: 128

Я не уверен, почему он ищет в ../ каталог .git.Я почти уверен, что правильно установил WORKDIR.Вот мое целое Dockerfile

FROM node
WORKDIR /usr/src/my-repo
COPY package*.json ./
RUN npm install
COPY . .
RUN git submodule update --init
RUN git submodule foreach npm install
CMD ["npm", "start"]

Также в качестве примечания: субмодуль является частным хранилищем, как бы я клонировал его с помощью SSH?Нужно ли настраивать докер с помощью моего ключа ssh или чего-то еще?Спасибо.

Редактировать: Также каждый из сервисов является подмодулем родительского проекта.Я думаю, что это может быть причиной того, что git ищет ../git/modules/my-repo, но я не совсем уверен, как обойти это.Моя структура каталогов выглядит так:

parent-repo
--service-1
----orm
--service-2
----orm

1 Ответ

0 голосов
/ 18 сентября 2018

Подводя итог:

  • У вас есть один каталог, который обрабатывает оркестровку
  • Внутри этого каталога у вас есть несколько проектов, которые содержат приложение узла
  • КаждыйПриложение узла имеет такую ​​же зависимость для orm lib

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

  • Сохранить каталог оркестрации
  • Удалить все подмодули из этого каталога
  • Теперь клонируйте каждый сервис внутри каталога оркестровки какнормальный мерзавец репо.Добавьте каждый каталог в файл .gitignore родительского проекта.
  • Создайте файл Docker в каждом подпроекте, чтобы создать контейнер только для этой службы.
  • В родительском каталоге создайте запись длякаждый проект в файле docker-compose

Теперь у вас есть такая структура

- orchestration/
  - .git/
  - .gitignore
  - docker-compose.yaml
  - service1/
    - .git/
    - Dockerfile
    - package.json
    - ...
  - service2/
    - .git/
    - Dockerfile
    - package.json
    - ...
  - service3/
    - .git/
    - Dockerfile
    - package.json
    - ...

Ваш docker-compose.yaml выглядит следующим образом:

version: '3'

services:
  service1:
    build: ./service1
  service2:
    build: ./service2
  service3:
    build: ./service3

Чтобы предоставить код orm для каждой службы:

  • Создайте (если он еще не существует) пакет npm для orm.
  • Когда вы создаете пакет самостоятельно, вы можете предоставить gitURL для зависимости.См. Официальные документы: https://docs.npmjs.com/files/package.json#git-urls-as-dependencies
  • Добавьте этот пакет в качестве зависимости npm для каждого проекта.

При вызове docker-compose up docker compose должен собрать каждый проект и запустить его,Если какой-либо службе требуется доступ к другой службе, URL-адрес этой службы - это просто имя, указанное в файле docker-compose.Например, service1 хочет получить доступ к service2, тогда URL-адрес http://serive1/path

Вам не нужно запускать все службы, вы можете запускать их как вам угодно, например, docker-compose up service1 service3.

Чтобы восстановитьвызов службы (например, при изменении кода): docker-compose restart service1

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...