blocks|key|2492213|text|CloudBees+(+Jenkins背后的团队)在Jenkins+2中对Docker的支持投入了大量精力：https://jenkins.io/doc/pipeline/steps/docker-workflow/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2492214|在我看来还有点不成熟，但这是朝着好的方向迈出的一步。|2492215|我更喜欢gitlab-ci+(https://about.gitlab.com/gitlab-ci/)。它非常容易使用，而且非常稳定。不幸的是，对我来说，紧密的版本控制系统集成(如果你想使用GitLab+-CI，你必须把你的代码放到Gitlab中)是一个阻碍(必须把我的代码放在Github上)。|2492216|此外，您可以考虑一些SaaS产品，即：https://travis-ci.org/+https://buddybuild.com/|2492217|entityMap|0|LINK|mutability|MUTABLE|url|https://jenkins.io/doc/pipeline/steps/docker-workflow/|1|https://about.gitlab.com/gitlab-ci/|2|https://travis-ci.org/|3|https://buddybuild.com/^0|1I|1I|0|0|0|F|Z|1|0|J|M|2|16|N|3|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]|$A|1A|B|1B|1|1C]]|C|$]]|$1|J|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]|T|$5|M|N|O|C|$P|U]]|V|$5|M|N|O|C|$P|W]]]]

CloudBees (team behind Jenkins) puts a lot of effort in Docker support in Jenkins 2: <a href="https://jenkins.io/doc/pipeline/steps/docker-workflow/" rel="nofollow">https://jenkins.io/doc/pipeline/steps/docker-workflow/</a>

In my opinion is still a little bit immature, but it's step in good direction.

I prefer gitlab-ci (<a href="https://about.gitlab.com/gitlab-ci/" rel="nofollow">https://about.gitlab.com/gitlab-ci/</a>). It's extremely easy to use and rock solid stable. Unfortunately for me tight version control system integration (you have to put your code into GitLab if you would like to use Gitlab-CI) is a show stopper (have to keep my code on Github).

Also you may consider some SaaS products i.e:
<a href="https://travis-ci.org/" rel="nofollow">https://travis-ci.org/</a>
<a href="https://buddybuild.com/" rel="nofollow">https://buddybuild.com/</a>

blocks|key|2492287|text|使用带有自动缩放的gitlab和gitlab-ci，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2492288|这是开箱即用的支持，请参阅autoscale+runners+Gitlab-CI，它使用Docker+Machine和驱动程序根据需要自动部署资源，即使在数字海洋上也是如此。|offset|length|2492289|并在.gitlab-ci.yml中描述构建和测试：|2492290|2492291|定义了不同的阶段，(build，test1+....)|unordered-list-item|2492292|，每个阶段的所有构建/测试都必须完成，然后才能进入下一个阶段|2492293|和每个阶段都并行运行，当然这取决于可用的资源。|2492294|2492295|请参阅我的简单docker+pipeline+here。|2492296|备注1:当机密性有问题时，您可以|style|BOLD|2492297|2492298|a.在gitlab+|2492299|上创建私有存储库B.在您自己的服务器上托管gitlab*|2492300|2492301|备注2:当代码托管在其他地方(例如github)时，您可以在每次提交时将其推送到gitlab，以启动构建管道。|2492302|如果您需要专业人员来设置这样的项目，您可以与我联系，但这超出了本问题/答案的范围|2492303|entityMap|0|LINK|mutability|MUTABLE|url|https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/autoscale.md|1|https://docs.docker.com/machine/overview/|2|https://gitlab.com/dgoo2308/docker_env_test/pipelines/4391805^0|0|D|R|0|18|E|1|0|0|0|0|0|0|0|N|4|2|0|0|4|0|0|0|0|0|0|4|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@]|9|@$D|1K|E|1L|1|1M]|$D|1N|E|1O|1|1P]]|A|$]]|$1|F|3|G|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1S|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|1T|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|1U|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1W|8|@]|9|@$D|1X|E|1Y|1|1Z]]|A|$]]|$1|S|3|T|5|6|7|20|8|@$D|21|E|22|U|V]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|X|3|Y|5|K|7|24|8|@]|9|@]|A|$]]|$1|Z|3|10|5|K|7|25|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|27|8|@$D|28|E|29|U|V]]|9|@]|A|$]]|$1|14|3|15|5|6|7|2A|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]|1E|$5|19|1A|1B|A|$1C|1F]]|1G|$5|19|1A|1B|A|$1C|1H]]]]

Use gitlab and gitlab-ci with autoscale, 

this is supported out of the box, see <a href="https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/autoscale.md" rel="nofollow">autoscale runners Gitlab-CI</a> which uses <a href="https://docs.docker.com/machine/overview/" rel="nofollow">Docker Machine</a> with drivers to automatic deploy resources as needed, even on digital ocean.

And you describe your build and tests in the .gitlab-ci.yml:

<ul>
<li>defining the different stages, (build, test1 .... )</li>
<li>where all builds/tests per stage have to finish before moving to the next stage</li>
<li>and per stage all run parallel, depending on availleble resources of course.</li>
</ul>

see my simple docker pipeline <a href="https://gitlab.com/dgoo2308/docker_env_test/pipelines/4391805" rel="nofollow">here</a>.

REMARK 1: When confidentiality is an issue, you can 

<ul>
<li>a. create a private repository on gitlab</li>
<li>b. host gitlab on your own server*</li>
</ul>

REMARK 2: When code is hosted somewhere else (e.g. github), you can push it to gitlab on every commit to initiate the build pipeline.

If you would need a professional to setup such a project, you can contact me, but that would be outside the scope of this question/answer

blocks|key|30490|text|您可以随时编写一个bash或powershell脚本，Jenkins可以执行该脚本来执行此操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|30491|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You could always write a bash or powershell script that Jenkins could execute to do this.

blocks|key|2492357|text|首先，将集成测试移到Docker构建步骤之外。单元测试仍然可以在那里运行，但我更喜欢在容器外部单独运行这些测试，以最小化构建映像中的测试代码数量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2492358|对于多容器集成测试，他们需要在docker+run而不是docker+build之后运行它们。这允许您为每个容器提供dns连接的名称，并控制每次测试运行的顺序。您甚至可以将每个测试存储为docker-compose.yml并处理结果。|offset|length|style|CODE|2492359|将测试从映像构建中分离出来后，您可以将测试作为Jenkins管道中的一个步骤添加，从而使您能够并行运行各个部分，并在继续之前等待每个阶段的完成。|2492360|entityMap^0|0|F|A|S|C|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

Start by moving your integration test outside of your Docker build step. Unit tests could still run there, but I'd prefer to do those separately, outside of the container to minimize how much test code is inside the built image.

For the multi-container integration tests, they need to run them after a <code>docker run</code> rather than a <code>docker build</code>. That allows you to give each container a name for dns connectivity and control the order of when each test is run. You could even store each test as a docker-compose.yml and process the results.

With the tests separated from the image build, you can add the tests as a step in a Jenkins pipeline to give you the ability to run parts in parallel and wait on each stage for completion before continuing.

I have a set of stateful services that compose a distributed system. Each one has a Docker file that can build it and run its unit tests. I need to check how they interact with each other in a distributed manner. To run tests, I need to: 

<ul>
<li>Be able to run multiple Docker files at the same time on different nodes that would be considered a single test run.</li>
<li>Be able to set barriers in commands execution order of each Docker file. In other words, assuming all Docker files run simultaneously I need to be sure that all files have finished stage <code>X</code> before starting stage <code>Y</code>.</li>
<li>Be able to stop on failure of any node.</li>
</ul>

Is there a Jenkins plugin/extension for such operations, or is there any other system or approach that could solve such problem?

Is there Jenkins or other open-source CI for a distributed system?

版本控制系统

单元测试

集成测试

服务器

容器

Docker

SaaS

我有一组有状态的服务，它们组成一个分布式系统。每一个都有一个Docker文件，可以构建它并运行它的单元测试。我需要检查它们是如何以分布式方式彼此交互的。要运行测试，我需要：能够在不同的节点上同时运行多个Docker文件，这将被视为一次测试运行。能够在每个Docker文件的命令执行顺序中设置障碍。换句话说，假设所有Doc...

问是否有用于分布式系统的Jenkins或其他开源CI？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有用于分布式系统的Jenkins或其他开源CI？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有用于分布式系统的Jenkins或其他开源CI？
EN