-
Notifications
You must be signed in to change notification settings - Fork 2
Expand file tree
/
Copy pathindex.html
More file actions
89 lines (70 loc) · 6.74 KB
/
Copy pathindex.html
File metadata and controls
89 lines (70 loc) · 6.74 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
<!DOCTYPE html>
<html lang="en-us">
<head>
<meta charset="UTF-8">
<title>Dockins by Dockins</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="stylesheets/normalize.css" media="screen">
<link href='https://fonts.googleapis.com/css?family=Open+Sans:400,700' rel='stylesheet' type='text/css'>
<link rel="stylesheet" type="text/css" href="stylesheets/stylesheet.css" media="screen">
<link rel="stylesheet" type="text/css" href="stylesheets/github-light.css" media="screen">
</head>
<body>
<section class="page-header">
<img src="https://avatars3.githubusercontent.com/u/19631904?v=3&s=500">
<h1 class="project-name">Dockins</h1>
<h2 class="project-tagline">the best of Docker and Jenkins </h2>
<a href="https://github.com/Dockins" class="btn">View on GitHub</a>
</section>
<section class="main-content">
<h3>
<a id="goal" class="anchor" href="#goal" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Goal.</h3>
<p>This project is about getting the best of Docker and Jenkins to offer a simple, efficient CI/CD infrastructure. This project is highly opinionated, so you might disagree :P</p>
<h3>
<a id="embrace-docker" class="anchor" href="#embrace-docker" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Embrace Docker.</h3>
Docker and Jenkins at some time overlap in the way they can manage build processes and resources. Our goal here is to explore Docker impact on Jenkins
design to benefit Docker's features when they do a better job.
<ul>
<li>Jenkins uses it's own mechanisms to control build processes on remote "agents" (aka "slaves"). Docker API allows to control remote processes as well. We prefer the later. Actually, we have plan to fully remove need for Jenkins remoting</li>
<li>Docker offer isolated, customizable environment to run process(es). We want end-user to get total flexibility on this.</li>
<li>Docker can run containers as a composed set of services (aka docker-compose or kubernetes pods). We want to rely on this for end-user to compose a build/test environment for CI/CD, and not consider a container as a lightweight virtual machine.</li>
<li>Docker offer volumes and volume-drivers to manage data persistence and/or replication with low level control on actual infrastructure. We want to rely on this for build workspace, vs letting Jenkins guess the best node to run build on. </li>
</ul>
<h3>
<a id="docker-executor" class="anchor" href="#docker-executor" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Docker executor.</h3>
<p>docker-slaves-plugin is our first attempt to achieve some of those goals. It runs a set of ephemeral docker containers to host the build, based on configuration set by end user directly in job configuration.</p>
This project is released, not strictly speaking "<em>ready for production</em>" as there's some glitches we'd like to address and some extension
point to be defined. Anyway it is stable enough so hundred people already adopted it :P
<p>
Docker-slaves relies on docker composability to run a set of containers with shared resources (i.e. workspace and network). We use this to run
jenkins remote agent plumbing in a container end-user don't have to wory about, in addition to build container that can run arbitrary image, as
well as "<em>side containers</em>" to provide test resources (test database, selenium headless browser, ...)
<p>
This plugin has a high potential as it is fully compatible with all Jenkins plugins, do support Jenkins Pipeline, and could in near future
support docker-compose syntax as well as run on docker orchestrator (kubernetes or mesos for sample) in addition to plain docker/swarm.
<h3>
<a id="docker-pipeline" class="anchor" href="#docker-pipeline" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Docker Pipeline.</h3>
<p>docker-slaves-plugin do support pipeline, but still relies on executing arbitrary pipeline steps, and as such on jenkins remoting. We plan to offer an alternative pipeline-specific approach to only support shell commands, and run container detached. Doing this, we can just wait for the container to stop (listening on docker events to get notified) and don't need long-running-task plugin.</p>
Main idea of this plugin is to rely <em>only</em> on Docker, and drop Jenkins remoting. This make it fully incompatible with other Jenkins plugins,
so we will have to re-implement the relevant CI/CD features. Sounds crazy, but we think it's the best way to explore "<em>how Jenkins would look if Docker existed when it was created</em>".
<p>
It <em>might</em> be possible to be some way compatible with Jenkins plugins, by exposing some remoting stub to plugins, which would only support a subset
of Jenkins remoting API, typically re-implement FilePath remote file abstraction with plain docker commands (typically, <code>docker cp</code>).
This is just an assumption so far, doing this is a huge effort, probably simpler for us to define our own API and offer plugin adapters for the most requested ones.
<p>
This plugin is in early proof-of-concept stage.
<p>See <a href="https://gist.github.com/ndeloof/d701cbe1b11deb07dcef729776736361">draft design doc</a></p>
<h3>
<a id="declarative-pipeline" class="anchor" href="#declarative-pipeline" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Declarative Pipeline.</h3>
<p>A longer terms goal is to offer a declarative pipeline. As pipeline let end-user do arbitrary groovy scripting, it require sandboxing and increased complexity. This can make sense for some use-cases but we want to offer a KISS-level pipeline experience, inspired by travis-ci|circle-ci|drone.io. We can model pipeline stages as docker container(s) running some commands.</p>
<p>By design, such a DSL pipeline would offer limited extensibility. This would let us gain full control on the set of supported features,
and would make it possible to just translate into docker-pipeline Groovy DSL code to benefit Jenkins Pipeline existing infrastructure and
active development effort.</p>
<p>see <a href="https://gist.github.com/ndeloof/7e0bf5d31b71c87c4fcf4c67f8a3dc51">draft design doc</a></p>
<footer class="site-footer">
<span class="site-footer-owner"><a href="https://github.com/Dockins/www">Dockins</a> is maintained by <a href="https://github.com/Dockins">Dockins</a>.</span>
<span class="site-footer-credits">This page was generated by <a href="https://pages.github.com">GitHub Pages</a> using the <a href="https://github.com/jasonlong/cayman-theme">Cayman theme</a> by <a href="https://twitter.com/jasonlong">Jason Long</a>.</span>
</footer>
</section>
</body>
</html>