开发人员是否应该能够在其开发环境中从lerna monorepo创建docker工件? [英] Should a developer be able to create a docker artifact from a lerna monorepo in their development environment?

查看:71
本文介绍了开发人员是否应该能够在其开发环境中从lerna monorepo创建docker工件?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近开始使用lerna来管理monorepo,并且在开发中效果很好.

I've recently started using lerna to manage a monorepo, and in development it works fine.

Lerna在我的各种程序包之间创建符号链接,因此'tsc --watch'或nodemon之类的工具可以很好地检测其他程序包中的更改.

Lerna creates symlinks between my various packages, and so tools like 'tsc --watch' or nodemon work fine for detecting changes in the other packages.

但是在这种环境下创建docker镜像时遇到了问题.

But I've run into a problem with creating docker images in this environment.

假设我们有一个具有以下结构的项目:

Let's say we have a project with this structure:

root
  packages
     common → artifact is a private npm package, this depends on utilities, something-specific
     utilities → artifact is a public npm package
     something-specific -> artifact is a public npm package
     frontend → artifact is a docker image, depends on common
     backend → artifact is a docker image, depends on common and utilities

在这种情况下,在开发中,一切都很好.我正在运行某种实时重新加载服务器,并且符号链接可以正常运行,从而使依赖项正常工作.

In this scenario, in development, everything is fine. I'm running some kind of live reload server and the symlinks work such that the dependencies are working.

现在让我们说我想从后端创建一个docker镜像.

Now let's say I want to create a docker image from backend.

我将介绍一些情况:

    我的Dockerfile中的
  1. I ADD package.json,然后运行npm install.

  1. I ADD package.json in my Dockerfile, and then run npm install.

不起作用,因为通用和实用程序包未发布.

Doesn't work, as the common and utilities packages are not published.

我在后端运行我的构建命令,在docker文件中添加/build和/node_modules.

I run my build command in backend, ADD /build and /node_modules in the docker file.

不起作用,因为我构建的后端具有require('common')require('utilities')命令,这些命令位于node_modules(符号链接)中,但是Docker只会忽略这些符号链接的文件夹.

Doesn't work, as my built backend has require('common') and require('utilities') commands, these are in node_modules (symlinked), but Docker will just ignore these symlinked folders.

解决方法::使用cp --dereference取消符号链接"节点模块有效.请参阅此 AskUbuntu问题.

Workaround: using cp --dereference to 'unsymlink' the node modules works. See this AskUbuntu question.

步骤1,但在构建docker映像之前,我先发布了npm软件包.

Step 1, but before I build my docker image, I publish the npm packages.

这行得通,但是对于正在检查代码库并对commonutilities进行修改的人来说,它行不通,因为他们没有发布npm软件包的特权.

This works ok, but for someone who is checking out the code base, and making a modification to common or utilities, it's not going to work, as they don't have privledges to publish the npm package.

我将backendbuild命令配置为不将commonutilities视为外部,而将common配置为不将something-specific视为外部.

I configure the build command of backend to not treat common or utilities as an external, and common to not treat something-specific as an external.

我认为首先要构建something-specific,然后是common,然后是utilities,然后是backend.

I think first build something-specific, and then common, and then utilities, and then backend.

这样,当进行构建时,并将此技术与webpack一起使用时,捆绑软件将包含something-specfic,common和utilities中的所有代码.

This way, when the build is occuring, and using this technique with webpack, the bundle will include all of the code from something-specfic, common and utilities.

但这很麻烦.

这似乎是我要解决的一个非常简单的问题.我的机器上当前正在运行的代码,我想拉出并放入docker容器中.

It seems like quite a simple problem I'm trying to solve here. The code that is currently working on my machine, I want to pull out and put into a docker container.

记住我们要在这里实现的关键是,使某人能够从他们的开发环境中检出代码库,修改任何软件包,然后构建docker映像.

Remember the key thing we want to achieve here, is for someone to be able to check out the code base, modify any of the packages, and then build a docker image, all from their development environment.

在这里我是否缺少明显的lerna技术,或者我可以用来思考解决此问题的devops参考框架?

Is there an obvious lerna technique that I'm missing here, or otherwise a devops frame of reference I can use to think about solving this problem?

推荐答案

我们遇到了一个类似的问题,这就是我们所做的事情:将Dockerfile放在monorepo的根目录(lerna.json所在的位置)中.

We got a similar issue and here is what we did: Put the Dockerfile in the root of the monorepo (where the lerna.json locates).

原因:您确实将整个存储库视为真实的单一来源,并且您希望对整个存储库的任何修改都反映在Docker映像中,因此为各个软件包使用单独的Dockerfile显得没有意义. /p>

Dockerfile

The reason: You really treat the whole repo as a single source of truth, and you want any modification to the whole repo to be reflected in the docker image, so it makes less sense to have separate Dockerfiles for individual packages.

FROM node:12.13.0

SHELL ["/bin/bash", "-c"]

RUN mkdir -p /app
WORKDIR /app

# Install app dependencies
COPY package.json /app/package.json
COPY yarn.lock /app/yarn.lock
COPY packages/frontend/package.json /app/packages/frontend/package.json
COPY packages/backend/package.json /app/packages/backend/package.json
COPY lerna.json /app/lerna.json
RUN ["/bin/bash", "-c", "yarn install"]

# Bundle app source
COPY . /app
RUN ["/bin/bash", "-c", "yarn bootstrap"]
RUN ["/bin/bash", "-c", "yarn build"]

EXPOSE 3000

CMD [ "yarn", "start" ]

package.json

{
  "private": true,
  "workspaces": [
    "packages/*"
  ],
  "scripts": {
    "bootstrap": "lerna clean --yes && lerna bootstrap",
    "build": "lerna run build --stream",
    "start": "cross-env NODE_ENV=production node dist/backend/main",
  },
  "devDependencies": {
    "lerna": "^3.19.0",
    "cross-env": "^6.0.3"
  },
}

这篇关于开发人员是否应该能够在其开发环境中从lerna monorepo创建docker工件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆