tag:blogger.com,1999:blog-216284382024-03-18T22:03:16.858+01:00new Blog( perso );Yet another Java blog, comme on ditNicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.comBlogger478125tag:blogger.com,1999:blog-21628438.post-2812065501769970412018-06-20T19:05:00.001+02:002018-06-20T20:36:29.320+02:00multi-release jar with Maven<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
Java 9 is here, and comes with some "surprises". So does Java 10, 11 ...<br />
<br />
A recurrent problem I have as a library developer is I'd like to use some recent APIs but still need to support users on a not-so-recent JRE. Java 9 makes this even harder with the introduction of java modules, and a very common issue is getting such a warning at runtime :<br />
<br />
<pre class="brush: bash">WARNING: Illegal reflective access by com.foo.Bar to field org.Zot.qix
</pre>
<br />
<br />
The issue here is that Java 9 doesn't just deprecate a method, it makes reflection model obsolete and warn you because this will be strictly unsupported in a future release. This has impacts on many popular frameworks : Spring, Hibernate, Guava ... (and Jenkins for sure). This is such a backward incompatible change we will need to live with, as more will come with future versions of Java platform.<br />
<br />
There's a workaround for such issues, relying on a fresh new API introduced by Java 9 (<a href="https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/VarHandle.html">VarHandles</a> for this specific reflection problem) but does this mean your favourite framework will only support Java 9+ for new releases ?<br />
<br />
So for sample, this code was used by Jenkins for a while :<br />
<br />
<pre class="brush: java">public class ProcessUtil {
public static long getPid(Process p) {
try {
Field f = p.getClass().getDeclaredField("pid");
f.setAccessible(true);
return (long)f.get(p);
} catch (ReflectiveOperationException e) {
return -1;
}
}
}
</pre>
</div>
<br />
(ab)use of reflection to access Process pid attribute can be replaced in Java 9 with a fresh new API.<br />
<br />
<pre class="brush: java">public class ProcessUtil {
public static long getPid(Process p) {
try {
return p.getPid();
} catch (UnsupportedOperationException e) {
return -1;
}
}
}
</pre>
<br />
If we want Jenkins to run on Java 9 we need to replace ProcessUtil legacy implementation with this new code. But on the other side we still want Jenkins to run on Java 8.<br />
<br />
Here comes <a href="http://openjdk.java.net/jeps/238">JEP 238</a> "Multi Release Jar". The idea is to bundle in a Jar implementations of the exact same class targeting distinct Java releases. Anything before Java 9 will pick the plain old class file, but Java 9 will also look into META-INF/versions/9, Java 10 to look into META-INF/versions/10, and so on. So web can write the ProcessUtil class <i>twice</i> for Java 8 and Java 9, and get both included in the Jar, and used according to the platform which actually run the code.<br />
<br />
Looks good, but now comes the funny part : how to write and bundle a class file <i>twice</i> in a Jar ?<br />
<br />
Jetbrains' IDE Intellij Idea I'm using doesn't support setting distinct java level per source-folder, neither does Maven (see <a href="https://issues.apache.org/jira/projects/MCOMPILER/issues/MCOMPILER-323">MCOMPILER-323</a>), so I can't adopt a maven project structure like this one :<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEMA4VrJr1avwGjShG2B3cMzWRNE7B7lRs-bMXvn_R-fH1KK8s7b_jhTIslyQpfqAFt-Jvjjq1InI3JsD-uV5n9Y4uGJAPyONCEFItleOyyWV96czNM8VeE6NW4W4YosdyPFC-/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-20+a%25CC%2580+18.39.18.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="108" data-original-width="277" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEMA4VrJr1avwGjShG2B3cMzWRNE7B7lRs-bMXvn_R-fH1KK8s7b_jhTIslyQpfqAFt-Jvjjq1InI3JsD-uV5n9Y4uGJAPyONCEFItleOyyWV96czNM8VeE6NW4W4YosdyPFC-/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-20+a%25CC%2580+18.39.18.png" /></a></div>
<br />
So I had to convert the library into a multi-module maven project, one of the sub-module being specific to re-implementing some classes for Java 9 :<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiotJkhLNHMQX4bhlXvKAczg1DERo8Hypn5UO5mIZsEg8H4WTXoTJvtwWLnpgfI-wGw_959mTbpemTc_xBT54o5_YLeOU_qcMP1lNE4XuWBlkLQPfgZPjunqJ4CVDYHM5gkj5QA/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-20+a%25CC%2580+18.44.19.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="217" data-original-width="265" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiotJkhLNHMQX4bhlXvKAczg1DERo8Hypn5UO5mIZsEg8H4WTXoTJvtwWLnpgfI-wGw_959mTbpemTc_xBT54o5_YLeOU_qcMP1lNE4XuWBlkLQPfgZPjunqJ4CVDYHM5gkj5QA/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-20+a%25CC%2580+18.44.19.png" /></a></div>
<br />
And here comes a maven chicken-egg issue. The class we want to re-implement with Java 9 APIs do rely on some classes defined by the main library as type references. So core has to be built first by maven, then java9. But we still want to distribute a single Jar, with a single POM deployed to public repositories.<br />
<br />
My current setup for this scenario is to let Maven think I'm building a multi-module Jar, then hack the build lifecycle to get Java 9 classes bundled into the "core" Jar. For this purpose, I had to rely on some ant-task in my pom.xml :<br />
<br />
<pre class="brush: xml">
⟨build⟩
⟨plugins⟩
⟨plugin⟩
⟨artifactid⟩maven-antrun-plugin⟨/artifactid⟩
⟨executions⟩
⟨execution⟩
⟨id⟩bundle_java9⟨/id⟩
⟨goals⟩
⟨goal⟩run⟨/goal⟩
⟨/goals⟩
⟨phase⟩prepare-package⟨/phase⟩
⟨configuration⟩
⟨tasks⟩
⟨mkdir dir="${project.build.outputDirectory}/META-INF/versions/9"/⟩
⟨javac classpath="${project.build.outputDirectory}" destdir="${project.build.outputDirectory}/META-INF/versions/9" includeantruntime="false" source="9" srcdir="../java9/src/main/java" target="9"/⟩
⟨/tasks⟩
⟨/configuration⟩
⟨/execution⟩
⟨/executions⟩
⟨/plugin⟩
⟨plugin⟩
⟨artifactid⟩maven-jar-plugin⟨/artifactid⟩
⟨configuration⟩
⟨archive⟩
⟨manifestentries⟩
⟨multi-release⟩true⟨/multi-release⟩
⟨/manifestentries⟩
⟨/archive⟩
⟨/configuration⟩
⟨/plugin⟩
⟨/plugins⟩
⟨/build⟩
</pre>
<br />
<br />
This hack do run java 9 compilation on sibling "java9" source directory from within the core maven module. As a result I can deploy artifacts from this single module without polluting my pom.xml with unnecessary sub-modules dependencies.<br />
<br />
java9 module is configured as a java 9 jar module so my IDE will detect it accordingly, and depends on core module, so I can access all types to re-implement the class I want to replace.<br />
<br />
Yes, this is a hack, but as it took me some time to get this running I thought it could be useful to others. You can see this in action on a tiny-library I created to offer a java 9 compliant way to access private fields by reflexion, on all versions of Java : <a href="https://github.com/ndeloof/fields">https://github.com/ndeloof/fields</a><br />
<br />
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com26tag:blogger.com,1999:blog-21628438.post-58659713003280589332018-06-18T11:20:00.002+02:002018-06-23T09:11:39.790+02:00gVisor in depth<div dir="ltr" style="text-align: left;" trbidi="on">
<div>
<div style="text-align: justify;">
In my previous blog post I described <a href="https://github.com/google/gvisor">gVisor</a> as '<i>some stuff I hardly can really understand</i>'. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Technology is not only about code, understanding where it comes from, why and how it has been done, do helps to understand the design decision and actual goals.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div style="background: #ffe; border: solid 1px black; padding: 10px;">
<div style="text-align: justify;">
<b>tl;dr:</b> gVisor has been open-sourced recently but it has been running <a href="https://cloud.google.com/appengine/">Google App Engine</a> and <a href="https://cloud.google.com/functions/docs/">Google Cloud Functions</a> for years. It is a security sandbox for application, acting as a "Virtual kernel", but not relying on an hypervisor (unlike <a href="https://katacontainers.io/">KataContainers</a>). Now being open-source we can expect gVisor to support more application runtimes and being portable enough so it can replace Docker's <span style="font-family: "courier new" , "courier" , monospace;">runc</span> at some point for those interested in this additional isolation level.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Being in San Francisco for DockerCon'18 I went to visit Google office to meet Googler <a href="https://www.linkedin.com/in/ludovicchampenois">Ludovic Champenois</a>, and Google Developer Advocate <a href="https://www.linkedin.com/in/davidgageot/">David Gageot,</a> who kindly explained me gVisor history and design. In the meantime some of the informations required to fully understand gVisor became <a href="https://twitter.com/teich/status/1006611801331544065">public</a>, so I now can blog on this topic. By the way, Ludo made <a href="https://github.com/ludoch/ludoch.github.io/blob/master/Breizhcamp%202018.pdf">a presentation on this topic at BreizhCamp</a>, even gVisor name has not been used this was all about it.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
<h4 style="text-align: justify;">
History</h4>
</div>
<div>
<div style="text-align: justify;">
gVisor introduce itself as "<b><span style="color: #3d85c6;">sandboxing for linux applications</span></b>". To fully understand this, we should ask "<i>Where does it come from</i>" ?</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
I assume you already heard about Google App Engine. GAE was launched 10 years ago, and allowed to run Python application (then later Java) on google infrastructure for the cost of actually consumed resources. No virtual machine to allocate. Nothing to pay when application is not in use. If they did this in 2018, they probably would have named something like "<i>Google Serverless Engine</i>". </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Compared to other cloud hosting platform like Amazon, Google don't rely on virtual machines to isolate applications running on his infrastructure. They made this crazy bet they can provide enough security layers to directly run arbitrary user payload on a shared operating system.</div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
A public cloud platform like Google Cloud is a privileged target for any hacker. in addition, GAE applications do run on the exact same Borg infrastructure as each and every Google services. So the need for security in depth, and Google did invest a lot in security. For sample, the hardware they use in DataCenters do include a <a href="https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html">dedicated security chip</a> to prevent hardware/firmware backdoors. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
When GAE for java was introduced in 2009, it came with some restrictions. This wasn't the exact same JVM you used to run, but some curated version of it, with some API missing. Cause for those restrictions is for google engineers to analyse each and every low level feature of the JRE that would require some dangerous privileges on their infrastructure. Typically, <span style="font-family: "courier new" , "courier" , monospace;">java.lang.Thread</span> was a problem. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Java 7 support for GAE has been announced in 2013, <b>2 years</b> after Java 7 was launched. Not because Google didn't wanted to support Java, nor because they're lazy, but because this one came with new internal feature <span style="font-family: "courier new" , "courier" , monospace;">invokedynamic</span>. This one introduced a significant new attack surface and required a huge investment to implement adequate security barriers and protections. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Then came Java 8, with lambdas and many other internal changes. And plans for Java 9 with modules was a promise for yet more complicated and brain-burner challenges to support Java on GAE. So they looked for another solution, and here started internal project that became gVisor.</div>
<div style="text-align: justify;">
<br /></div>
<h4 style="text-align: justify;">
Status</h4>
</div>
<div>
<div style="text-align: justify;">
gVisor code you can find on <a href="https://github.com/google/gvisor">Google's github repository</a> is the actual code running Google App Engine and Google Cloud Function (minus some Google specific pieces which are kept private and wouldn't make any sense outside Google infrastructure). </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
When Kubernetes was launched, it was introduced as a simplified (re)implementation of Google's Borg architecture, designed for lower payloads (<span style="font-size: x-small;">Borg is running *all* Google infra as a huge cluster of hundreds thousands nodes</span>). gVisor isn't such a "<i>let's do something similar in oss</i>" project, but a proven solution, at least for payloads supported by Google Cloud platform. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div style="text-align: left;">
<div style="background: #ffe; border: solid 1px black; padding: 10px; text-align: justify;">
<i>To better understand it's design and usage, we will need to get into details. Sorry if you get lost in following paragraph, if you don't care you can directly scroll down to the kitten. </i></div>
</div>
<div style="text-align: left;">
<div style="text-align: justify;">
<h4 style="text-align: justify;">
<i><br /></i></h4>
<h4 style="text-align: justify;">
<i>
W</i>hat's a kernel by the way ?</h4>
</div>
</div>
<div>
<div style="text-align: justify;">
"Linux containers", like the ones you use to run with Docker (actually runc, default low level container runtime), but also LXC, Rkt or just systemd (<span style="font-size: x-small;">yes, systemd is a plain container runtime, just require a way longer command line to setup :P</span>), all are based on Linux kernel features to filter system calls, applying visibility and usage restrictions on shared system resources (cpu, memory, i/o). They all delegate to kernel responsibility to do this right, which as you can guess is far from being trivial and is the result of a decade of development by kernel experts.<br />
<br />
Linux defines a "user-space" (ring 3) and 'kernel-space" (ring 0) as CPU execution levels. "rings" are protection levels implemented by hardware: on can get into a higher ring (during boot), but not the opposite, and each ring only can access a subset of hardware operations.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Priv_rings.svg/300px-Priv_rings.svg.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="216" data-original-width="300" src="https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Priv_rings.svg/300px-Priv_rings.svg.png" /></a></div>
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
An application runs in user-space. Doing so there's many hardware related operation it can't use: for sample, allocating memory, which require interactions with hardware and is only available in kernel-space. To get some memory, application has to invoke a <b><span style="color: #3d85c6;">system call</span></b>, a predefined procedure implemented by kernel. When application execute <span style="font-family: "courier new" , "courier" , monospace;">malloc</span>, it actually delegates to kernel the related memory operation. Buy remember : there's <b>no way</b> to move from user-space to kernel-space, so this <b>not</b> just a function call.<br />
<br /></div>
</div>
<div>
<div style="text-align: justify;">
System calls implementation depends on architecture. on intel architectures it relies on interruption, which is a signal the hardware uses to handle asynchronous tasks and external events, like timers, a key pressed on keyboard or incoming network packet. Software also can trigger some interruptions, and passing parameters to kernel relies on values set in CPU's registries.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikfC9RHBlCepdeEqGI3j-qBWwC9YNk_y8DLLOrqbkj_g2VbLfQvJIKGjbhC1fgCMN1hyphenhyphenEKx6Ezw0G12-h_72e7xWypXiFN9iuM2MA6rKey1ZO9ywd6X_btM3Svc2gHvsz1WVuT/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-18+a%25CC%2580+10.16.44.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="270" data-original-width="760" height="113" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikfC9RHBlCepdeEqGI3j-qBWwC9YNk_y8DLLOrqbkj_g2VbLfQvJIKGjbhC1fgCMN1hyphenhyphenEKx6Ezw0G12-h_72e7xWypXiFN9iuM2MA6rKey1ZO9ywd6X_btM3Svc2gHvsz1WVuT/s320/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-18+a%25CC%2580+10.16.44.png" width="320" /></a></div>
<br />
<br />
When an interruption happens, the execution of the current program on the CPU is suspended, and a <i>trap</i> assigned to the interruption is executed in kernel-space. When the trap completes, the initial program is restored and follow up it's execution. As interruption only allows to pass few parameters, typically a system call number and some arguments, there's no risk for application to inject illegal code in kernel-space (as long as there's no bug in kernel implementation, typically a buffer overflow weakness).</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Kernel trap handling the system call interruption will proceed to memory allocation. Doing so it can apply some for restrictions (so your application can't allocate more that xxx Mb as defined by control-group) and implement memory allocation on actual hardware.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
What's wrong with that ? <b>Nothing</b> from a general point of view, this is a very efficient design, and system call mechanism acts as a very efficient filter ... as long as everything in kernel is done right. In real world software comes both with bugs and unexpected security design issues (not even considering hardware ones), so does the kernel. And as Linux kernel protections use by Linux Containers take place <i>within kernel space</i>, anything wrong here can be abused to break security barriers.<br />
<div style="text-align: left;">
<div style="text-align: justify;">
<h4 style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdG5WaSUmZXCUlwPiWhoD3lCOdY9g08Wv97E6tmZ_QX-kx9REpRcJd8FWGFZ49vdnTqxQce0vKzsn4Ood6r6GJiGMtrgLV-29JcpB0zb1_mfFNUd4OU-yYPh-UXlT21S2ClqzC/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+12.28.54.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="295" data-original-width="782" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdG5WaSUmZXCUlwPiWhoD3lCOdY9g08Wv97E6tmZ_QX-kx9REpRcJd8FWGFZ49vdnTqxQce0vKzsn4Ood6r6GJiGMtrgLV-29JcpB0zb1_mfFNUd4OU-yYPh-UXlT21S2ClqzC/s320/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+12.28.54.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
</h4>
</div>
</div>
I you check <a href="https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33">number of CVE per year for linux kernel </a>you will understand being a security engineer is a full time job. Not that linux kernel is badly designed, just that a complex software used by billions devices and responsible to manage shared resources with full isolation on a large set of architectures is ... dawn a complex beast ! </div>
</div>
<div>
<div style="text-align: justify;">
<span style="color: #3d85c6;"><br /></span>
<span style="background: #39f; border: solid 1px black; padding: 10px;"><b>Congrats to Linux kernel maintainer by the way, they do an awesome job !</b></span><br />
<span style="color: #3d85c6;"><br /></span>
Google do have it's own army of kernel security engineers, maintaining a custom kernel : both on purpose for hardware optimisation and to enforce security by removing/replacing/strenghtening everything that may impact their infrastructure, also contributing to mainstream Linux kernel when it makes sense.<br />
<br />
But that's still risky : if someone discover an exploit on linux kernel, he might not be smart enough to keep this private or could even try to hack Google. </div>
</div>
<div>
<div style="text-align: justify;">
<h4 style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div>
<br /></div>
</h4>
<h4 style="text-align: justify;">
Additional isolation : better to be safe than sorry.</h4>
</div>
</div>
<div>
<div style="text-align: justify;">
A possible workaround to this risk is to add one additional layer of isolation / abstraction : hypervisor isolation. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
To provide more abstraction, a Virtual Machine do rely on hardware capability (typically: intel VT-X) to offer yet another level of interruption based isolation. Let's see how <span style="font-family: "courier new" , "courier" , monospace;">malloc</span> will operate when application runs inside a VM :</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
- application calls libC's <span style="font-family: "courier new" , "courier" , monospace;">malloc</span> which actually invoke system call number 12 by triggering an interruption.</div>
</div>
<div>
<div style="text-align: justify;">
- interruption is trapped in kernel-space as configured on hardware during operating system early stage boot.</div>
</div>
<div>
<div style="text-align: justify;">
- kernel access hardware to actually allocate some physical memory if legitimate. On bare metal the process would end here, but we are running in a VT-X enabled virtual machine</div>
</div>
<div>
<div style="text-align: justify;">
- as guest kernel is virtualized, it actually run on hosts as a user-space program. VT-X make it possible to have two parallel ring levels. So attempt to access hardware do trigger VMEXIT and let hypervisor to execute trapping instructions to act accordingly. in KVM architecture this means switching into hosts' user-mode as soon as possible (!) and use user-mode QEmu for hardware emulation.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtdI3RAGYfUIXNHZTeXafsYAQXn7C48evsRQYOWaely-0zxxAqIR2CfPy4t2AquHs3dNkC8d4ywNYD7ZTKzaKldBZam9pBFLQPxfoXpW42Pc_-nRhL9MALwtV6owryqfeJ-xpa/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+09.59.04.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="541" data-original-width="815" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtdI3RAGYfUIXNHZTeXafsYAQXn7C48evsRQYOWaely-0zxxAqIR2CfPy4t2AquHs3dNkC8d4ywNYD7ZTKzaKldBZam9pBFLQPxfoXpW42Pc_-nRhL9MALwtV6owryqfeJ-xpa/s320/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+09.59.04.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<br />
Hypervisor is configured to trap this interruption, and translating the low level hardware access into some actual physical memory allocation, based on emulated hardware and Virtual Machine configuration. So when VM's kernel things it's allocating memory block xyz on physical memory, it's actually asking hypervisor to allocate on an emulated memory model, and hypervisor can detect an illegal memory range usage. security++</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
This second level of isolation would prevent a bug in virtual machine kernel to expose actual physical resources. It also ensure the resources management logic implemented by guest kernel is strictly limited to a set of higher-level allocated resources. Hacking both the kernel then the hypervisor is possible in theory, but extremely hard in practice.<br />
<br />
<a href="https://katacontainers.io/">KataContainers</a> is an exact implementation of this idea : a docker image when ran by <span style="font-family: "courier new" , "courier" , monospace;">runV</span> (KataContainers' alternative to Docker's <span style="font-family: "courier new" , "courier" , monospace;">runC</span>) do use a KVM hypervisor to run a just-enough virtual machine so the container can start. And thanks to OpenContainerInitiative and docker's modular design you can switch from one to the other.</div>
</div>
<div>
<div style="text-align: justify;">
<br />
<h4 style="text-align: justify;">
</h4>
<h4 style="text-align: justify;">
Google's wish list for application isolation</h4>
</div>
</div>
<div>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.petmd.com/sites/default/files/small-kitten-walking-towards_127900829_0.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="355" data-original-width="474" height="239" src="https://www.petmd.com/sites/default/files/small-kitten-walking-towards_127900829_0.jpg" width="320" /></a></div>
<br />
Google decided to explore another approach. a Virtual Machine comes with some footprint. With a dedicated kernel and hardware emulation, a significant amount of cpu/memory is consumed by translation, and attempts by guest kernel to optimise resource usage are non-sense without a full platform vision and duplicate host's kernel effort. When you run Billions containers, any useless byte has a cost.<br />
<br />
<br />
On the other side, kernel-based isolation is far from being enough. They are part of a global solution, but Google needs more. Goole wanted to :<br />
<br />
<ul>
<li>limit the kernel's attack surface : minimize lines of code involves, so potential bugs</li>
<li>limit the kernel's risk for bugs : rely on a structured language. They selected Go (some advocate Rust would have been a better choice...)</li>
<li>limit the impact of kernel being hacked</li>
</ul>
<br />
<h4 style="text-align: justify;">
</h4>
<h4 style="text-align: justify;">
Virtual Kernel to the rescue.</h4>
Google designed a "User-Space Thin Virtual Kernel" (this is how I call this, not sure about their own name for this concept). </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
gVisor kernel is a tiny simple thing. It only implement a subset of Linux system calls (~250 over 400), and do this without any attempt to do some clever optimisations. This thin kernel is more or less a kernel firewall, and acts as a barrier to kernel exploits, for sample to prevent a buffer overflow.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="background: #39f; border: solid 1px black; padding: 10px; text-align: justify;">
<b>buffer overflow</b> is a security exploit relying on kernel to not detect some system call parameter do imply a larger amount of data to be written in some well known kernel-memory location. As a result the sibling kernel memory get overridden, and can allow hackers to execute some code in kernel mode. gVisor kernel is pretty simple in implementation, which drastically reduce the risk for such an attack to find. Linux Kernel in comparison is about thousands line of C code, with a significant attack surface whenever best experts review it's code on a regular basis.<br />
<br />
Sounds crazy ? Look at this for a disruptive proof of abusing a credit card payment terminal being hacked by buffer overflow.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/wWTzkD9M0sU/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/wWTzkD9M0sU?feature=player_embedded" width="320"></iframe></div>
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
gVisor kernel do trap application system calls and (re)implement them as a kernel proxy on host's, without any hardware emulation / hypervisor. Being implemented in Go, it doesn't suffer the permissive C model which force developer to check for buffers size, allocated pointers, reference removal, etc. This for sur comes with some cost (typically: a garbage collector), I bet Google isn't using the standard Go compiler/runtime for internal use.</div>
</div>
<div>
<div style="text-align: justify;">
gVisor do only implement legitimate system calls for payload supported on Google App Engine. Java 8 support for Google App Engine in 2017 means that all system calls a JRE 8 require have been implemented by gVisor. It probably could run many other runtimes, but Google prefer to double check before any public announcement and commitment with customers.<br />
<br />
But the most disruptive architecture decision with gVisor is for it to run this Thin Virtual Kernel in user-space. <i>Some</i> magic has to happen so that user program system call get actually trapped by Virtual Kernel running in user-space.<br />
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVNUzVczaTrrbKz7ZlVLlTzpeyEl8qpstGV6ne_pLeNDdwJavy-VV3wAfHMqbgtZKSeqhBa5qpwZCAlmFAjsfQPZ1JJKSiS-cO4pVq7heR2ZBbXRSyRex9LOiCLsLhWRlhZHiW/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+09.35.23.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="282" data-original-width="763" height="118" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVNUzVczaTrrbKz7ZlVLlTzpeyEl8qpstGV6ne_pLeNDdwJavy-VV3wAfHMqbgtZKSeqhBa5qpwZCAlmFAjsfQPZ1JJKSiS-cO4pVq7heR2ZBbXRSyRex9LOiCLsLhWRlhZHiW/s320/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+09.35.23.png" width="320" /></a></div>
<h4>
</h4>
<h4>
How to trap a system call in user-space ?</h4>
</div>
</div>
<div>
<div style="text-align: justify;">
gVisor comes with a plugable <i>platforms</i>, offering two options : ptrace and kvm.<br />
<br />
ptrace is documented as "reference" implementation on gVisor docs. One should read "portable", as sole guaranteed way to run gVisor on arbitrary Linux systems. <a href="http://man7.org/linux/man-pages/man2/ptrace.2.html">ptrace</a> is Linux system call debugger, it's designed to trap system calls in kernel-space and execute a user-space fonction in reaction.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPWRfUDuHWO_WTrk9NrvgM0qpNWLrw1IVpeSWJsTHmE_9VQFMgfjrcKpXMhRcQnMo8uTqXuZ0Ndn4y31qo_I_Gs7FPmw555Fyd_OIaLTDysv4-q2s5I7OObO7aUO63S4L8ouZ9/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+09.43.13.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="272" data-original-width="761" height="114" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPWRfUDuHWO_WTrk9NrvgM0qpNWLrw1IVpeSWJsTHmE_9VQFMgfjrcKpXMhRcQnMo8uTqXuZ0Ndn4y31qo_I_Gs7FPmw555Fyd_OIaLTDysv4-q2s5I7OObO7aUO63S4L8ouZ9/s320/Capture+d%25E2%2580%2599e%25CC%2581cran+2018-06-19+a%25CC%2580+09.43.13.png" width="320" /></a></div>
<br />
Sounds good but devils is in the details: the actual design has some communication glitches which make it pretty inefficient when accessing large amounts of memory. Not an issue for a debugger, but a huge one for a container runtime. <a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a> was designed with this exact same idea, ans is mostly abandoned for bad performances.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
The other option is kvm, so ... an hypervisor. This is claimed to be experimental, my guess is that google <a href="https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html">custom flavour of kvm</a> and Linux kernel has been optimised for this usage. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<h4>
Who the hell will use gVisor ?</h4>
</div>
</div>
<div>
<div style="text-align: justify;">
Anyone running Google App Engine or Google Cloud Functions for sure, but by design of the platform they don't know, and they don't have to care.<br />
<br /></div>
</div>
<div>
<div style="text-align: justify;">
For others, without a portable, production ready <i>platform,</i> gVisor so far is "<i>only</i>" an interesting project, which tell us more about how Google do host random code on a shared infrastructure. If one want to run containers with kvm isolation, it's pretty unclear to me if gVisor is a better option vs KataContainer, as this one is public for a longer time with a larger community. On the other side, gVisor project already received request features and pull-requests to add more system-calls. Maybe this can help Google expand its Cloud platform to new application runtimes ?</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
The other option is for another platform to be implemented. Typically, Google new operating system <a href="https://fuchsia.miraheze.org/wiki/Main_Page">Fuchsia</a>, designed to run both on mobiles, IoT devices and clusters might be designed with this use-case in mind, offering an efficient syscall-to-userspace mechanism (or maybe using more ring levels ?).</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Last but not least, gVisor project demonstrates creativity in an alternative approach. Someone might come with some fresh new idea using this new piece of software in combination with another feature, and build something unexpected... this happened already as Linux kernel had all those namespace and cgroup things, and some technology enthusiasts came with this emergent concept of "<i>_containers_</i>", creating a whole ecosystem and changing the way we build and deliver software today. </div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div style="height: 0px; text-align: left;">
<div style="text-align: justify;">
x</div>
</div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com39tag:blogger.com,1999:blog-21628438.post-14098321734937389132018-05-04T11:45:00.002+02:002018-05-04T11:48:54.995+02:00gVisor, WTF ?<div dir="ltr" style="text-align: left;" trbidi="on">
Google vient d'annoncer un nouveau runtime pour les containers OCI (les images Docker quoi) : <a href="https://github.com/google/gvisor">gVisor</a>.<br />
<br />
Décryptage. (je pique les illustrations de la page gVisor parce que j'ai la flemme de les refaire)<br />
<br />
Linux n'a pas de concept natif de "container", contrairement à BSD avec ses <i>Jails</i> ou à Solaris avec ses <i>Zones</i>. Ce qu'on appelle un "<i>container</i>" n'est donc que l'émergence d'en empilement de divers mécanismes de sécurisation et d'isolation. En un sens c'est pratique parce qu'on peut <i>tuner</i> tout ça et désactiver deux ou trois trucs quand on en a besoin, mais quid de la sécurité du machin en termes de "sandbox" qui permet d'exécuter du code arbitraire sans risquer d'exposer la machine ?<br />
<br />
Le runtime à la Docker (containerd) met en place l'arsenal mis à disposition par les noyeau Linux : isolation de visibilité des ressources (namespaces), restrictions (cgroup) et filtres sur les appels noyeau (capabilities, seccomp, apparmor, SELinux). En gros, on sait imposer que telle application a droit d'accéder à tels fichiers, uniquement en lecture, et avec un débit I/O de xx maximum, ce qui permet aux autres application d'avoir aussi des ressources I/O et de placer leur propres données sur le même disque sans risque.<br />
<br />
Configuré correctement - la conf par défaut étant déjà pensée pour permettre tout ce qui est raisonnable à une application standard, et bloquer tout ce qui clairement n'est pas justifié - on est en principe à l'abris de tout débordement de la part d'une application malveillante / malcodée / lesdeuxmoncapitaine.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://github.com/google/gvisor/raw/master/g3doc/Rule-Based-Execution.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="172" data-original-width="353" height="155" src="https://github.com/google/gvisor/raw/master/g3doc/Rule-Based-Execution.png" width="320" /></a></div>
<br />
Notons au passage que le support du user-namespace dans Docker est encore minimal (et désactivé par défaut). C'est lui qui permet d'être "root" dans le container mais en fait non, utilisateur non-privilégié sur le système hôte. Idéalement chaque container devrait tourner avec un user ID distinct, comme on fait tourner les divers services d'un système Unix avec des uid/gid différents pour bien isoler qui a droit de faire quoi. Fin de la parenthèse<br />
<br />
Bon ça c'est en théorie, parce qu'évidemment tout ça repose sur la solidité de ces mécanismes, et donc sur l'absence de bug dans le noyau. On a pu voir passer quelques articles détracteurs, à charge contre Docker, qui mettent en lumière un problème de partage de ressources au niveau du noyau lorsqu'un container a un comportement particulier, et qu'il finit par pénaliser les autres. On ne parle pas d'escalade de permission ou de fuite d'information, mais c'est déjà un soucis. Dans les articles que j'ai lu le problème était résolut en faisant une mise à jour du noyau (!). Bref, tout repose sur les épaules du noyau et de ses mécanismes de partage équitable et de protection des resources. Et même avec toute la bonne volonté du monde on se doute qu'il y a toujours un risque.<br />
<br />
D'où l'idée de ne pas partager le noyau entre containers, et d'avoir un noyau <i>par</i> container. C'est le principe de KataContainers, la fusion des projets ClearContainer (intel) et runV (hyper). Dans les deux cas, on utilise un hyperviseur KVM et un noyau minimal dédié à chaque container. Ce n'est pas magique, ici aussi la machine hôte doit assurer un partage équitable et sécurisé des ressources entre les différentes machines virtuelles + container. Mais en ajoutant cette indirection on limite le risque qu'un bug donné dans le noyau expose significativement la machine hôte.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://github.com/google/gvisor/raw/master/g3doc/Machine-Virtualization.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="335" data-original-width="387" height="277" src="https://github.com/google/gvisor/raw/master/g3doc/Machine-Virtualization.png" width="320" /></a></div>
<br />
La partie "virtual hardware" est là où le bâs blesse : Si vraiment on émule le CPU, les disques, la mémoire ... on va se retrouver avec les performances d'un MO5 (c'est d'ailleurs comme ça qu'on fait un émulateur MO5 sur PC, mais c'est une toute autre histoire).<br />
<br />
Vous vous doutez bien vu l'utilisation massive de VMs dans le Cloud que ça ne fonctionne pas comme ça : le "hardware" exposé à la machine virtuelle est une version pré-machée, super facile à utiliser, et qui fait passe plat avec les drivers du système hôte. Le noyau de la VM hébergée dispose lui aussi du driver qui va bien pour utiliser ce "hardware" tellement simple que le code fait quelques lignes (bon, quelques centaines, ça reste du code C :P).<br />
On gagne en simplicité - donc on limite les risques de bugs => faille de sécurité - et en performances.<br />
<br />
Cette technique de "<i>para-virtualisation</i>" (virt-io) permet de conserver une certaine isolation sans renoncer à la performance. Elle est parfois implémentée niveau hardware, en particulier par le CPU - sans quoi les machines virtuelles râmeraient dur dur, mais aussi sur certaines architectures par le contrôleur mémoire ou encore l'interface réseau...<br />
<br />
Bref, les VMs ça marche (non, sans blague ?) et ça permet d'avoir ceinture + bretelle, ce qui est la tenue préférée de l'expert sécurité (sous son gilet pare-balle).<br />
<br />
Ok donc qu'est-ce que gVisor vient faire là dedans ?<br />
<br />
gVisor veut lui aussi séparer le noyau utilisé par un container du noyau hôte. Pour cela il utilise une technique qui n'est pas nouvelle : <a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a> avait déjà exploré la même approche, et le fait que le site soit sur sourceforge vous donne une idée de son ancienneté.<br />
<br />
L'idée est de démarrer un process classique en <i>user-space</i> (pas <i>root</i> quoi) qui va servir de noyau à un sous-système hébergé, mais sans couche de virtualisation comme le propose un hyperviseur. Les appels systèmes que l'application fait au noyau hébergé sont alors implémentés sur la base des resources légitimes allouées au process.<br />
<br />
Soucis principal : comment faire pour qu'un process standard intercepte les appels systèmes (qui par définition sont ... au coeur du systèmes donc dans le noyau). L'approche utilisée par UML et gVisor est de détourner ptrace, outil de debug Posix, qui permet en gros d'avoir un point d'arrêt sur tout appel système et de répondre à la place du noyau. Un bon gros hack quoi. Ca marche, mais c'est pas gratuit en termes de performances. Sans surprise d'ailleurs, c'est conçu pour du debug !<br />
<br />
gVisor par ailleurs utilise un noyau développé en Go par Google. Alors je veux bien croire qu'ils sont très, très bon et que gVisor ne sort pas d'un chapeau, mais celle là je l'avais pas vue venir. Quand je parlais de re-coder Jenkins en Rust c'était pour la blague, coder un noyau OS en Go c'est, heu ... <i>disruptif</i> ?<br />
<br />
Mais bon, admettons. Après tout ce "noyau" n'est là que pour filtrer ce qu'on veut bien exposer au container et produire une implémentation simple puisqu'il se base non pas sur du hardware mais sur un système Linux avec tout ce qu'il faut.<br />
<br />
Malgré tout je reste perplexe : Certes ce pseudo-noyau permet d'expose quelque chose de plus propre au conteneurs que le fait un runtime Docker :<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://pbs.twimg.com/media/DcPCJIeUwAA_-g6.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="650" data-original-width="800" height="260" src="https://pbs.twimg.com/media/DcPCJIeUwAA_-g6.png" width="320" /></a></div>
D'un côté de "vrai" mounts (bien camouflés quoi), de l'autre des montages qui montrent bien le runtime sous-jacent.<br />
<br />
Certes ce noyau écrit exprès pour ça peut mettre en oeuvre des choses qui n'auraient aucun sens dans le noyau Linux <i>upstream</i>. Certes Google a une expérience sur le sujet qui lui permet d'être crédible. Il n'en reste pas moins que ça me semble étrange de <a href="https://github.com/google/netstack">développer une pile réseau</a> dans ce Go-noyau là où Linux propose des pile réseau virtuelles (veth) depuis des lustres, et qui <i>a priori</i> donne satisfaction à tout le monde. Il y a donc une volonté de prendre le contrôle sur certains détails très fins de ces aspects, qui ne sont pas (encore) documentés<br />
<br />
<div style="text-align: left;">
<span style="background-color: white; font-family: , , "segoe ui" , "helvetica" , "arial" , sans-serif , "apple color emoji" , "segoe ui emoji" , "segoe ui symbol"; font-size: 16px;"><span style="color: #999999;">We plan to release a full paper with technical details and will include it here when available.</span></span></div>
<div style="text-align: left;">
<br /></div>
Ce qui m'amène au point principal, plutôt que de débattre des choix techniques : quel est le cas d'utilisation qui justifie tout ça ? Clairement ce n'est pas prévu pour un usage <i>mainstream</i> par Mme Sysadmin-Michu. Et ça, je l'ai pas trouvé dans la doc.<br />
<br />
<b><span style="color: #0b5394;">Mon hypothèse, indéniablement fausse, mais je la propose quand même :</span></b><br />
<br />
Un noyau linux complet, même utilisant virt-io, est bien trop complexe et "intelligent" pour un contexte aussi trivial qu'une mono-application dans son conteneur, ce qui augmente les risques de bugs. L'idée de Google est donc d'avoir un noyau <strike>débile</strike> épuré qui n'expose que le strict nécessaire, avec une logique interne ultra-simple pour limiter les failles, puis de passer la main à un "adulte" pour ce qui est de la gestion plus délicate du vrai hardware.<br />
<br />
<div style="border: solid 1px #000; padding: 10px;">
<u>NB:</u> Ma compréhension du noyau est très insuffisante pour dire si cette vision des choses est réaliste / pertinente, donc prenez là pour ce qu'elle est.</div>
<br />
Ce qui m'embête c'est que ce cahier des charges c'est ... celui de <a href="https://linuxfr.org/users/pied/journaux/seccomp-une-sandbox-integree-au-noyau-linux">seccomp</a> :-/ Ce serait donc une approche alternative pour ne <i>pas</i> se baser sur seccomp qui<br />
<br />
<ol style="text-align: left;">
<li>tourne en espace noyau</li>
<li>ne permet de filtrer que partiellement les paramètres des appels (valeurs directes). Limitation que n'a pas <a href="https://lwn.net/Articles/698226/">Landlock</a> qui lui succédera peut-être ?</li>
</ol>
<br />
<br />
<br />
Je ne pense pas qu'on ai du gVisor en production tout de suite (!). Il n'en reste pas moins que l'approche pose des questions, et que je n'arrive pas à trouver des réponse satisfaisantes. Autant dire que je ne vous ai sans doute pas donné la réponse que vous attendiez peut être dans cet article. Poussez-moi des commentaires si vous avez lu des infos intéressantes dessus ou un avis sur la question.<br />
<br />
Autre point noir : gVisor n'a pas de logo, et ça c'est nul quand on cherche une illustration pour un billet de blog. Du coup tant pis pour vous, je vous met un David Gageot à la place.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://pbs.twimg.com/profile_images/920247739279167490/kUfQSN-e_400x400.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="400" data-original-width="400" height="320" src="https://pbs.twimg.com/profile_images/920247739279167490/kUfQSN-e_400x400.jpg" width="320" /></a></div>
<br />
<br />
<br />
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com11tag:blogger.com,1999:blog-21628438.post-5301692159329542322018-02-09T11:43:00.001+01:002018-02-09T11:43:10.656+01:00Breizh to the CampSi vous lisez ce blog vous me connaissez sans doute déjà un peu :<br />Je bricole des trucs chez CloudBees, j'anime une chaîne Youtube sur Docker, et j'organise une conférence à Rennes : le BreizhCamp<br /><br />
<br /><br />
<br /><br />
Il est rare que je puisse réunir ces trois composantes dans le même billet, et voici donc l'exception qui confirme une règle :<br /><br />
une vidéo Youtube pleine de hacks à pour faire la promo du BreizhCamp 2018<br /><br />
<br /><br />
<iframe allowfullscreen="" frameborder="0" height="270" src="https://www.youtube.com/embed/y1-Gh0bMsUo" width="480"></iframe><br /><br />
<br /><br />
Profitez en, partagez là, aidez-nous à faire du bruit !<br /><br />
Bientôt un second lot de places pour vous inscrire au BreizhCamp 2018 va être débloqué ...<br /><br />
<br /><br />
<br /><br />
<br />Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com25tag:blogger.com,1999:blog-21628438.post-2689486855645911332018-01-19T10:41:00.002+01:002018-01-19T12:27:02.878+01:00to DinD or not do DinD ?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
A colleague of mines pointed me to <a href="https://applatix.com/case-docker-docker-kubernetes-part/">this interesting article</a> about using Docker-in-Docker ("DinD") as a valid solution for Continuous Integration use-case. </div>
<div style="text-align: justify;">
<br /></div>
<h4 style="text-align: justify;">
Don't bind-mount docker.sock !</h4>
<div style="text-align: justify;">
This article is pretty interesting as it explains very well the issue by exposing underlying docker socket to a container. tldr; you just give up with security and isolation. Remember this single excerpt:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="background-color: #fefefe; color: #6d7f8b; font-family: "heebo" , sans-serif; font-size: 16px;">" they can create Docker containers that are privileged or bind mount host paths, potentially creating havoc on the host </span><span style="background-color: #fefefe; color: #6d7f8b; font-family: "heebo" , sans-serif; font-size: 16px; text-align: right;">"</span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This article starts with a reference to <a href="https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/">Jérôme's blog post</a> explaining <b>why</b> one should <b>not</b> use DinD for CI, so this is interesting to understand the reasoning to adopt a solution the original author explicitly disclaimed for this usage.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let's now have a look at the follow-up article on DinD : <a href="https://applatix.com/case-docker-docker-kubernetes-part-2/">A case for Docker-in-Docker on Kubernetes (Part 2)</a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Here again, the issue exposing underlying docker infrastructure is well described. Please read-it, I'm exhausted trying to explain why '<span style="font-family: "courier new" , "courier" , monospace;">-v /var/run/docker.sock:/var/run/docker.sock</span>' is an option you never should type.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Then the DinD solution applied to kubernetes is demonstrated, and a point I want you to notice is this one in pod's yaml definition :</div>
<div style="text-align: justify;">
<br /></div>
<pre style="background-color: #fefefe; color: #6d7f8b; font-family: monospace, monospace; font-size: 16px;">securityContext:
privileged: true
</pre>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGH4cD9Fu3F7C4jHsLFH6ntpA3L3TFkpkW5dZOnLpx7ZX2bW53FdKgRGRlHuQ0ft93UmdVuFQCxZStdabXUtGjAoPuKvAOtC_0ozUqG4ZYULI_ss_p1bsEEcI6rS0vmN3AqRoi/s1600/29b28b350e1dc5dfdb22061799cd80aa--le-cri-edvard-munch.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="690" data-original-width="540" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGH4cD9Fu3F7C4jHsLFH6ntpA3L3TFkpkW5dZOnLpx7ZX2bW53FdKgRGRlHuQ0ft93UmdVuFQCxZStdabXUtGjAoPuKvAOtC_0ozUqG4ZYULI_ss_p1bsEEcI6rS0vmN3AqRoi/s320/29b28b350e1dc5dfdb22061799cd80aa--le-cri-edvard-munch.jpg" width="250" /></a></div>
<h4 style="text-align: justify;">
Privileged ?</h4>
<div style="text-align: justify;">
What does this option implies ? It sounds like few people actually understand the impact. The option name should anyway ring a bell.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Let's have a look at the <a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">reference documentation</a>:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="background-color: #fefefe; color: #6d7f8b; font-family: "heebo" , sans-serif; font-size: 16px;">" </span><span style="color: #6d7f8b; font-family: "heebo" , sans-serif;">The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller</span><span style="background-color: #fefefe; color: #6d7f8b; font-family: "heebo" , sans-serif; font-size: 16px; text-align: right;">"</span></div>
<div style="text-align: justify;">
<span style="background-color: #fefefe; color: #6d7f8b; font-family: "heebo" , sans-serif; font-size: 16px;"><br /></span></div>
<div style="text-align: justify;">
Such a container can then access every hardware resource exposed at lowest level within the host's <span style="font-family: "courier new" , "courier" , monospace;">/dev</span> pseudo-filesystem, which includes all your disks, which is the most obvious security issue. Are you comfortable your build can also access <span style="font-family: "courier new" , "courier" , monospace;">/dev/mem</span> (physical memory) ? </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Allowing all capabilities also means your container can use all system calls from <span style="background-color: #f5f8fa; color: #0c5176; font-family: "menlo" , "monaco" , "consolas" , "courier new" , monospace; font-size: 12.6px; white-space: nowrap;">cap_sys_admin</span> capability, which as a short overview of <a href="http://man7.org/linux/man-pages/man7/capabilities.7.html">Linux capabilities</a> means ... there's no restriction what this process can do on system. Typically, with <span style="background-color: #f5f8fa; color: #0c5176; font-family: "menlo" , "monaco" , "consolas" , "courier new" , monospace; font-size: 12.6px; white-space: nowrap;">cap_sys_admin</span> you can use <span style="font-family: "courier new" , "courier" , monospace;">mknod</span> to create <span style="font-family: "courier new" , "courier" , monospace;">/dev/*</span> if you didn't already had access to it from container...<br />
<br />
--privileged is sort of a sudo++. Just like if you could use this :<br />
<br />
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Inconsolata; color: #ffffff; background-color: #000000}
span.s1 {font-variant-ligatures: no-common-ligatures; color: #c33720}
span.s2 {font-variant-ligatures: no-common-ligatures}
span.s3 {font-variant-ligatures: no-common-ligatures; color: #34bbc8}
</style>
<br />
<div class="p1">
<span class="s1">➜<span class="Apple-converted-space"> </span></span><span class="s2"> </span><span class="s3">~</span><span class="s2"> echo hello</span></div>
<div class="p1">
<span class="s2">Permission denied</span></div>
<div class="p1">
<span class="s2"><span class="s1">➜<span class="Apple-converted-space"> </span></span><span class="s2"> </span><span class="s3">~</span><span class="s2"> sudo echo hello</span></span></div>
<div class="p1">
<span class="s2"><span class="s2">Permission denied</span></span></div>
<div class="p1">
<span class="s1">➜<span class="Apple-converted-space"> </span></span><span class="s2"> </span><span class="s3">~</span><span class="s2"> echo --privileged hello</span></div>
<div class="p1">
<span class="s2"><span class="s2"></span></span></div>
<div class="p1">
<span class="s2">hello</span></div>
<div>
<span class="s2"><br /></span></div>
So, a DinD container runs as root, without restriction on system calls it can run, and access to all devices. Sounds like a good place to run arbitrary processes and build pull-requests, isn't it ?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Maybe you consider docker resources isolation as "<i>we want to prevent development team to shoot into it's own foot</i>" and just ensure no build process will start an infinite fork loop or break the CI service with a memory leak. Only public cloud services need to prevent hackers to break the isolation and steal secrets, right ? If so, please take few minutes to talk with your Ops team :P</div>
<div style="text-align: justify;">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbbVLAxJLZNGPq3TfKoWYrYMULBrDnTTPX4yPG27Fij89HZJQ1ZOp7Lxci6ixWSMs_DeKz8X_st_kDv2_KGPzGYTAC7KV1xSBmDjx3MxErX6pOUYyQJ9nl2z14c5tFkN6tRVOH/s1600/Maxi-Posters-Les-Simpson---Le-Cri-71474_28548x1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="400" data-original-width="280" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbbVLAxJLZNGPq3TfKoWYrYMULBrDnTTPX4yPG27Fij89HZJQ1ZOp7Lxci6ixWSMs_DeKz8X_st_kDv2_KGPzGYTAC7KV1xSBmDjx3MxErX6pOUYyQJ9nl2z14c5tFkN6tRVOH/s320/Maxi-Posters-Les-Simpson---Le-Cri-71474_28548x1.jpg" width="224" /></a></div>
<br /></div>
<h4 style="text-align: justify;">
So, is DinD such a bad idea ?</h4>
<div style="text-align: justify;">
Actually, one <b>can</b> use privileged container <b>and</b> enforce security, using a fine-grained AppArmor profile to ensure only adequate resources. You also can use docker's <span style="font-family: "courier new" , "courier" , monospace;">--device</span> to restrict the devices your DinD container actually can use, and <span style="font-family: "courier new" , "courier" , monospace;">--cap-drop</span> to restrict allowed system calls to the strict minimum. This is actually how <a href="http://training.play-with-docker.com/">play-with-docker</a> is built, but as you can guess this wasn't created within a day, and require advanced understanding of those security mechanisms. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<h4>
Is there any alternative ?</h4>
</div>
<div style="text-align: justify;">
My guess is that Applatix solution is driven by lack for a simple and viable alternative. Exposing underlying docker infrastructure is just a no-go, as you then loose kubernetes management control on your side containers. Your nodes would quickly be running thousands orphaned containers. From this point of view, using DinD allows to maintain all your containers under cluster management.</div>
<div style="text-align: justify;">
<br />
<h4>
How do others solve this issue ?</h4>
CircleCI for sample do allow access to a docker infrastructure to build your own image. The <a href="https://circleci.com/docs/2.0/building-docker-images/">documentation</a> explains a dedicated, remote, docker machine will be allocated for your build. So they just create VMs (or something comparable) to allow your build to access a dedicated docker daemon with some strong isolation. This is far from being transparent for end-user, but at least don't give up with a secured solution.<br />
<br />
My recommendation is to have your build include the required logic for such a dedicated docker box to be setup. In terms of a <span style="font-family: "courier new" , "courier" , monospace;">Jenkinsfile</span> pipeline, you could mimic CircleCI with a shared library to offer a <span style="background-color: whitesmoke; color: #333333; font-family: monospace; font-size: 15px; white-space: pre;">setup_remote_docker()</span> high-level function to jobs within your company. This library would allocated a short lived VM on your infrastructure to host docker commands, and inject DOCKER_HOST environment variable accordingly.<br />
<br />
<h4>
What's next ?</h4>
</div>
<div style="text-align: justify;">
Another solution I've been investigating is to create a docker API proxy, which do expose the underlying docker infrastructure <b>but</b> filter all API calls to reject anything you're not supposed to do :</div>
<div style="text-align: justify;">
<ul>
<li>only proxy supported API calls (whitelist)</li>
<li>parse API payload and rebuild payload sent to underlying infrastructure. This ensure only supported options will be passed to docker daemon.</li>
<li>reject security related options like : bind mounts, privileged, cap-add, etc</li>
<li>block access to containers/volumes/networks you didn't created</li>
<li>filter API responses to only let you see legitimate resources (for sample, <span style="font-family: "courier new" , "courier" , monospace;">docker ps</span> will only give you access to your own containers)</li>
</ul>
<div>
This proxy also transparently adds constraints to API commands: it enforces all containers you create do inherit from the same cgroup hierarchy. So if your build is constrained to 2Gb memory, you can't get more running side containers. It also adds labels, which could be used for infrastructure monitoring to track resources ownership.</div>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
so, generally speaking, this proxy adds a "namespace" feature on top of Docker API.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This is just a prototype so far, and sorry : it's not open-source...</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhR-QhY8sVMh9kctrK9zISD7Oxs091FcrZAvtujNqGoobxZhNBlNwbFo7h6SHTtKQjB0lbavyO-rE7uYCJK44LH_5ZjWvgZ2dpc1jl0A2lJ6CAc-EB9yBuDnEY7kJ8zhGK77CjU/s1600/Edvard-Munch-Le-Cri-parodie-lapin-cretin.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="582" data-original-width="450" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhR-QhY8sVMh9kctrK9zISD7Oxs091FcrZAvtujNqGoobxZhNBlNwbFo7h6SHTtKQjB0lbavyO-rE7uYCJK44LH_5ZjWvgZ2dpc1jl0A2lJ6CAc-EB9yBuDnEY7kJ8zhGK77CjU/s320/Edvard-Munch-Le-Cri-parodie-lapin-cretin.jpg" width="247" /></a></div>
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com277tag:blogger.com,1999:blog-21628438.post-29558301644395174402017-10-09T15:35:00.001+02:002017-10-09T15:35:27.867+02:00Jenkins Docker plugin 0.17 released<div dir="ltr" style="text-align: left;" trbidi="on">
As new maintainer for this plugin, I just released 0.17. You should see it in Jenkins update center within few hours.<br />
<br />
Plugin used to have version 0.xx as the internal API might change at any time, but has been adopted by <a href="https://wiki.jenkins.io/display/JENKINS/Docker+Plugin">thousands people</a>, so I think it's time to get a 1.0. That being said, for my first release I preferred to not break everything at once, and only made few fixes and improvements. I plan to have some more 0.x fix versions if required, but next one should be 1.0.<br />
<br />
What's new ?<br />
First, I migrated to docker-commons for credentials management (docker API and registry). If you use docker-pipeline this is something you're familiar with. As a side effect you might need to reconfigure your jobs and/or agent templates.<br />
<br />
I also introduced an experimental "attached" agent launcher.<br />
Jenkins require a communication channel for the master to control the agent. Any transport protocol is fine, so depending your infrastructure you might rely on SSH or JNLP. But Docker offers an alternative : you probably are used to run docker CLI in interactive, "attached" mode<br />
<br />
<div class="p1">
<span class="s1">➜<span class="Apple-converted-space"> </span></span><span class="s2"> </span><span class="s3">~</span><span class="s2"> docker run -it ubuntu bash</span></div>
<div class="p1">
<span class="s2">root@89ac63c6802e:/# echo "hello from ubuntu"</span></div>
<div class="p1">
<span class="s2">hello from ubuntu</span></div>
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Inconsolata; color: #ffffff; background-color: #000000}
span.s1 {font-variant-ligatures: no-common-ligatures; color: #c33720}
span.s2 {font-variant-ligatures: no-common-ligatures}
span.s3 {font-variant-ligatures: no-common-ligatures; color: #34bbc8}
</style>
<br />
<div class="p1">
<span class="s2">root@89ac63c6802e:/# exit</span></div>
<br />
Here Docker CLI uses the plain Docker API an upgrade HTTP protocol to establish a long running terminal session with the container. Jenkins can rely on this stdin/stdout transport to setup required Jenkins remoting channel.<br />
<br />
This feature relies on docker-java support for attached mode, my experiments so far demonstrated it works well, but only tests at scale will prove it really works as expected. So please give it a try and let me know :P<br />
<br />
What's next in docker-plugin ?<br />
<br />
Major point I want to address is lack of support for docker swarm mode. This one would offer Jenkins a scalable build infrastructure. But this will also require some tweaks, as Docker service API is way less powerful than the plain container API. It can't for sample inject some content in a container, or exec inside a container to run some additional commands. So probably this will introduce some constraints, but need to experiment more to know the actual options we have here.<br />
<br />
<br />
<br />
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com33tag:blogger.com,1999:blog-21628438.post-72085924983840219902017-08-02T11:54:00.000+02:002017-08-02T19:06:21.825+02:00J'ai aimé Valérian<div dir="ltr" style="text-align: left;" trbidi="on">
C'est l'été, et ce blog va donc - une fois n'est pas coutume - me permettre d'exprimer une petite critique cinéma.<br />
<br />
générique.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.deloriand.com/wp-content/uploads/2014/08/Fossoyeur_de_film.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.deloriand.com/wp-content/uploads/2014/08/Fossoyeur_de_film.jpg" data-original-height="283" data-original-width="800" height="225" width="640" /></a></div>
<br />
<br />
<br />
<br />
Je suis donc allé voir Valérian, l'occasion de partager un moment avec mes deux grands, de leur parler de cette BD qui a bercé mon enfance et que j'ai adoré et relu de nombreuses fois (merci à la BDThèque de Brest).<br />
<br />
---<br />
<br />
Avant d'entrer dans la salle obscure, j'ai lu des <a href="http://www.lefigaro.fr/cinema/2017/07/11/03002-20170711ARTFIG00212--valerian-de-luc-besson-entre-bonnes-trouvailles-et-gachis-epique-selon-la-critique-us.php">critiques plutôt négatives</a> sur le film, et j'avoue ne pas m'y reconnaitre après séance.<br />
<br />
Comprenez bien que ce n'est <u>pas</u> une transcription de la BD à l'écran, ce qui aurait été très différent. D'une part la BD a elle même beaucoup évolué dans son style entre le premier album et le dernier opus, ensuite le rythme et le type de narration n'ont pas grand chose à voir dans ces deux formats. Le film est un vrai film, avec la dynamique liée au format "image grand format", avec un scénario taillé pour un format de 2h, mariant action, sentiments, humour, etc.<br />
<br />
Je vois deux pièges possibles dans ce genre d'adaptation<br />
<br />
1. le pur <b>fan-service </b>: le film que seuls les amoureux de l'oeuvre originale peuvent comprendre.<br />
<i>Le ire du genre</i> : <a href="http://www.allocine.fr/video/player_gen_cmedia=19379667&cfilm=61768.html">Final Fantasy Advent Children</a>. Si t'as pas joué au jeu vidéo tu pige juste rien<br />
<br />
2. le <b>foutage de gueule hollywoodien</b> : le film qui raconte un truc avec plein de références empruntés à l'oeuvre originale mais qui la dénature pour tenter de tenir un scénario. <br />
<i>Typiquement</i>: <a href="https://fr.wikipedia.org/wiki/Mission_impossible_(film)">Mission Impossible</a> (qui fait de Jim Phelps un traitre ... sans commentaire)<br />
<br />
<br />
Valérian évite ces deux écueils, en proposant un vrai film qui reprend les éléments de l'univers de la BD, quelques personnages clés, mais surtout la diversité biologique qui caractérise cette fiction, jusque dans le détail d'une humanité à l'origine de la station Alpha "des milles planètes" et pourtant en plein déclin, et qui craint de s'en faire exclure.<br />
<br />
Niveau casting, j'étais sceptique du choix de Dane DeHaan, un peu trop "ado" a mon avis pour ce role, mais au final ça passe bien. Quand a Cara Delevingne elle incarne une parfaite Laureline : sexie mais pas bimbo, fière, déterminée, vaillante... et la doublure voix Française lui donne un charme fou.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://media.rtl.fr/cache/8StNrrT_GjhyQSlm28bitQ/880v587-0/online/image/2017/0710/7789280398_laureline-est-une-heroine-cool-et-independante-dans-valerian-et-la-cite-des-mille-planetes.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://media.rtl.fr/cache/8StNrrT_GjhyQSlm28bitQ/880v587-0/online/image/2017/0710/7789280398_laureline-est-une-heroine-cool-et-independante-dans-valerian-et-la-cite-des-mille-planetes.jpg" data-original-height="533" data-original-width="800" height="266" width="400" /></a></div>
<br />
<br />
Niveau image, on navigue dans un environnement graphique élégant, riche et régulièrement renouvelé, qui reproduit très fidèlement l'imaginaire de la BD en terme de "diversité biologique". On a aussi droit à une bonne dose d'images 3D, surtout dans les scènes d'action aux travelings improbables, sans pour autant se perdre dans des plans séquence épileptiques à la <i>Tranformers</i>.<br />
<br />
J'avoue être un peu partagé sur la présence de Rhianna au casting, dont le rôle est au final un peu artificiel : même s'il permet d'apporter un moment <i>différent</i> dans le rythme du film qui n'est pas du tout inutile, la sortie du personnage est un peu rapidement balayée par la suite des événements. Ce serait peut être le seul reproche que j'aurais à faire.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://android7update.com/wp-content/plugins/RSSPoster_PRO/cache/b18d4_405" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="270" data-original-width="405" height="266" src="https://android7update.com/wp-content/plugins/RSSPoster_PRO/cache/b18d4_405" width="400" /></a></div>
<br />
<br />
J'ai pu lire des reproches sur les similitudes avec Blade Runner, Star Wars ou Avatar. Ce serait peut être oubliée que la BD a commencé en 1967 et que c'est plutôt elle qui a inspiré (directement ou indirectement) les réalisateurs de ces films - <a href="http://www.numerama.com/pop-culture/278841-star-wars-le-cinquieme-element-comment-valerian-a-influence-les-films-de-science-fiction.html">lire cet article</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.numerama.com/content/uploads/2017/07/star_wars_and_valerian_english.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.numerama.com/content/uploads/2017/07/star_wars_and_valerian_english.jpg" data-original-height="526" data-original-width="750" height="280" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Alors oui, lorsque les trois protagonistes sortent d'un container à ordure <i>forcément</i> on peut voir un parallèle avec la même scène de Star Wars... mais bon, je préfère y voir un clin d'oeil plus qu'un manque d'originalité, car le film n'en manque pas sur d'autres aspects. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
Idem pour le look des Pearl, habitants de <span style="background-color: white; color: #222222; font-family: sans-serif; font-size: 14px;">Mül, qui rappellent forcément Avatar. Mais bon, nos canons de beauté étant assez limités il est difficile d'éviter ce stéréotype dans un film grand public : grands, minces, des traits doux et lisses, une relation harmonieuse avec la nature ... ce que l'humanité aimerait être quoi. Alors oui, ils auraient pu avoir de petites ailes dans le dos. </span><br />
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: sans-serif; font-size: 14px;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfDtqpOjehw3S4luEkWBW8SNa01KBTvires4uU-ZlZfS-esgqYNdrDvcoOpE8PDlO9jFb0V2pfh-3RQlsjha0gi02ckhNOnOq6H0BEfrTIbvxoWZJVC0wGqTKnznCh44bF78QZ9A/s1600/Les+habitants+de+la+plan%25C3%25A8te+Mul+dans+Val%25C3%25A9rian.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="481" data-original-width="1086" height="281" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfDtqpOjehw3S4luEkWBW8SNa01KBTvires4uU-ZlZfS-esgqYNdrDvcoOpE8PDlO9jFb0V2pfh-3RQlsjha0gi02ckhNOnOq6H0BEfrTIbvxoWZJVC0wGqTKnznCh44bF78QZ9A/s640/Les+habitants+de+la+plan%25C3%25A8te+Mul+dans+Val%25C3%25A9rian.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: sans-serif; font-size: 14px;"><br /></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: sans-serif; font-size: 14px;"><br /></span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="background-color: white; color: #222222; font-family: sans-serif; font-size: 14px;">BREF je trouve ce film très réussi, adapté aussi bien aux fans de la BD qui y retrouveront ce qu'ils ont aimé dans les aventures en planches du duo cosmique, aussi bien que des non-initiés qui découvrent un univers richer et inspirant, au long d'une histoire bien sympathique. </span></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Donc, merci Mr Besson pour ce bon moment, aussi bien pour moi qui ai retrouvé le plaisir de la BD que pour mes gamins qui en ont pris plein les yeux ! </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://i.ytimg.com/vi/8CtGQbrD2-M/maxresdefault.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="450" data-original-width="800" height="360" src="https://i.ytimg.com/vi/8CtGQbrD2-M/maxresdefault.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com6tag:blogger.com,1999:blog-21628438.post-22084863726854235042017-07-07T10:47:00.002+02:002017-07-07T17:15:34.521+02:00Writing a Docker Authorization Plugin<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
Docker daemon is extensible by plugins, allowing network, volumes, authorization and (in last version) logs and metrics management to be plugged in and controlled from external services.<br />
<br />
As I'm investigating Docker infrastructure security in the contexte of a CI/CD service, I've been looking for ways to lock down docker daemon so it only allows a subset of the Docker API. Typically, I want to disable bind mounts to ensure one can't just make crazy things like :<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">docker run -v /:/target alpine rm -rf /target/*</span><br />
<br />
(don't try this at home)<br />
<br />
<br />
There's various solutions to prevent bad things to happen, including <a href="https://success.docker.com/KBase/Introduction_to_User_Namespaces_in_Docker_Engine">enabling the user namespace</a>, but a second protection barrier still makes sense #DefenseInDepth.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5e3FcMj1OlFJlxMHvyMUVjDajEPSE8pQzpUEmUe2sAXw3yeeafEx8-6Mduww_G8ZvkV44IMQ_d4fthrSEnrtmU72fpjxqC16Z5z1WGoJNlfiPCHzS18qqmNTS-51ZBi8_D4PO/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2017-07-07+a%25CC%2580+08.27.51.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="285" data-original-width="612" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5e3FcMj1OlFJlxMHvyMUVjDajEPSE8pQzpUEmUe2sAXw3yeeafEx8-6Mduww_G8ZvkV44IMQ_d4fthrSEnrtmU72fpjxqC16Z5z1WGoJNlfiPCHzS18qqmNTS-51ZBi8_D4PO/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2017-07-07+a%25CC%2580+08.27.51.png" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
So I've been investigating <a href="https://docs.docker.com/engine/extend/plugins_authorization/">authorization plugin</a> for docker daemon.<br />
<br />
<h4 style="text-align: left;">
Step 1 : <span style="color: #0b5394; font-size: x-large;">A</span>rchitecture</h4>
Authorization plugin are invoked by deamon for any API call, either from docker socket or http clients. User identity is based on TLS key, so one could create such a plugin with user profiles, so some super-admin with adequate TLS key could do anything, and all others would have restricted access to the API. You can chain authorization plugins, so depending your needs you can keep them simple, or just plug existing ones.<br />
<br />
Authorization plugin only implements 2 http endpoints, one to authorize the incoming API request, and the second to authorize the resulting output. This design allows to filter some API calls <i>or</i> to block some data to be exposed by the daemon. It's sometime simpler to let the daemon run some read-only API calls (like <span style="font-family: "courier new" , "courier" , monospace;">inspect</span>) then check the result to ensure no sensible data is exposed.<br />
<br />
To write such a plugin, you'll need to understand which <a href="https://docs.docker.com/engine/api/v1.30">API</a> are actually used by a docker CLI command. Typically, <span style="font-family: "courier new" , "courier" , monospace;">docker run -it </span> actually uses a bunch of them to pull image, create and start container, attach stdin/out. A simple way is to just look a docker daemon logs when debug is enabled. <br />
<br />
Also note authorization plugin can't make changes to the incoming request, so you can't for sample remove some parameters or add some additional ones, like forcing a label to a container to track which user created it. I'd like to do this so I can prevent a later <span style="font-family: "courier new" , "courier" , monospace;">docker exec</span> command to enter a container someone else created. To do this from this plugin I'll need to become stateful and store some container :: owner map.<br />
<h4>
Step 2 : <span style="color: #0b5394; font-size: x-large;">C</span>ode</h4>
I've implemented my plugin in Go, using <a href="https://github.com/docker/go-plugins-helpers">go-plugin-helper</a> skeleton. There's not much done by this lib, but I'm lazy :P<br />
<br />
I spent some time fighting with <span style="font-family: "courier new" , "courier" , monospace;">GOPATH</span> and (lack of) dependency management in Go language. Typically, go-plugin-helped do depend on go-connections, and I've been hurt by <a href="https://github.com/docker/go-connections/commit/62665b16fb0590a1157f2ba0eb006ea3d7775a46">this change</a> as go-connection has some tags but go-plugin-helper doesn't, so <a href="https://github.com/golang/dep">dep</a> I'm using to manage dependencies just pulled incompatible code. I like go development but dependency hells is really a terrible issue for this ecosystem.<br />
<br />
Plugin's code is available <a href="https://github.com/ndeloof/authobot">on github</a>. There's nothing magic here, just a whitelist for API calls I authorize and a specific parameter check for '<span style="font-family: "courier new" , "courier" , monospace;">docker run</span>' to ensure no bind mount is user, nor Privileged containers creation.<br />
<br />
I could also have used <a href="https://github.com/twistlock/authz">twistlock authz plugin</a> with a custom profile, but<br />
<br />
<ol style="text-align: left;">
<li>I'm not sure this plugin is more than just a proof of concept (twistlock offers a proprietary more advanced security service, so <a href="https://github.com/twistlock/authz/issues/42#issuecomment-313228495">don't expect</a> this project to do more than just basic filtering)</li>
<li>One learn more by getting hands dirty. Or maybe this is some sort of NIH syndrom :P </li>
</ol>
<br />
<h4>
Step 3 : <span style="color: #0b5394; font-size: x-large;">T</span>est</h4>
You can ask my colleagues : I'm not used to write unit tests (and that's probably bad) but here I did at least for a simple one :P. But unit tests only cover local code execution, let's try to deploy this plugin on a real docker daemon and validate it actually does the job.<br />
<br />
To avoid breaking my local docker installation (sic) I created a virtualbox test environment using docker-machine (yes, despite docker4desktop supersede it for developer experience, this project still is useful). So we now have a sandbox, let's play<br />
<br />
<h4>
Step 4 : <span style="color: #0b5394; font-size: x-large;">D</span>eploy</h4>
Authorization plugin deployment is not a smooth process. I would expect I can run something like:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">docker build -t myplugin . && docker plugin install myplugin</span><br />
<br />
but ... that's not the case (yet - maybe this will be improved in a future release).<br />
<br />
You first have to build your plugin and provide a root filesystem for it to run containerized. So the simpler solution is to build a docker image and export it's filesystem<br />
<br />
<pre class="brush: bash">docker build -t authobot .
(...)
mkdir rootfs
ID=$(docker run -d authobot)
docker export $ID | tar -x -C rootfs
docker kill $ID
docker rm $ID</pre>
</div>
One also have to create a JSON descriptor for the plugin. There's various options in this file, but for this simple plugin descriptor is trivial:<br />
<br />
<pre class="brush: javascript">{
"Description": "Authorization plugin for Docker",
"Documentation": "https://github.com/ndeloof/authobot/blob/master/README.md",
"Entrypoint": [
"/bin/authobot"
],
"Interface": {
"Socket": "authobot.sock",
"Types": [
"docker.authz/1.0"
]
}
}
</pre>
<br />
<br />
We can now register this plugin on docker daemon and enable it<br />
<br />
<pre class="brush: bash">docker plugin create authobot .
docker plugin enable authobot</pre>
<br />
Here, the funny thing is that the plugin is enabled, but not in use. #plugin channel on Docker slack was a great assistance for me to understand the issue. Thanks a lot to <a href="https://twitter.com/cpuguy83">Brian Goff</a> for taking time to assist a noob :P<br />
<br />
Authorization plugins have to be explicitly set as docker daemon options, and can't be enabled/disabled from the API. It makes sense as one could then use the API to disable authorization :-\ but makes the code/deploy/test cycle bit more slow and annoying.<br />
<br />
So let's now <i>actually</i> enable the plugin :
<br />
<pre class="brush: bash">sudo vi /var/lib/boot2docker/profile</pre>
(adjust to your docker installation if you don't use a boot2docker VM)<br />
<br />
Add <span style="font-family: "courier new" , "courier" , monospace;">--authorization-plugin=authobot</span> to docker daemon arguments<br />
<br />
restart daemon :
<br />
<pre class="brush: bash">sudo /etc/init.d/docker restart</pre>
<br />
<h4>
Step 5 : <span style="color: #0b5394; font-size: x-large;">D</span>one!</h4>
My docker daemon now accepts the few API I've whitelisted, but nothing much<br />
<br />
<pre class="brush:bash">$ docker run -it ubuntu echo 'hello world!'
hello world!
$ docker ps
Error response from daemon: plugin authobot:latest failed with error: AuthZPlugin.AuthZReq: /v1.30/containers/json is not authorized
</pre>
<div>
<br />
<br />
<h4>
Step 6 : <span style="color: #0b5394; font-size: x-large;">W</span>hat's next?</h4>
Code is currently very minimalist, there's many thing I could improve.<br />
Generally speaking, it only partially cover my need : I will need to track the owner of each container to prevent one try to access other's containers.<br />
<br />
Also, as an authorization plugin doesn't allow to change the API call payload, there's few things that will be harder to implement, like per user resource quota, and few other protections I'd like to implement. This plugin anyway will at least prevent the most obvious security issues.</div>
<br />
<br />
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com18tag:blogger.com,1999:blog-21628438.post-82556064809714052002017-06-28T09:14:00.000+02:002017-06-28T09:14:00.838+02:00Filmer un meetup ...<div dir="ltr" style="text-align: left;" trbidi="on">
J'écris ce billet en réponse à l'article "<a href="https://methylbro.fr/aventure/filmer-le-web/">filmer le web</a>" de Thomas Gasc, vu que son blog ne permet pas de laisser de commentaires :P<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://methylbro.fr/lego-green-lantern.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="482" data-original-width="448" height="320" src="https://methylbro.fr/lego-green-lantern.jpg" width="297" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
Le BreizhJUG a été créé en 2008 et de nombreuses tentatives ont été menées pour assurer la captation, pour aboutir au setup actuel du BreizhCamp qui offre un super résultat mais au prix d'un investissement conséquent et d'un coût non négligeable.</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
Je ne vais donc pas vous faire une liste de matos, je comprend bien que l'idée ici c'est de faire avec les moyens du bord, et pas de cherche un sponsor pour l'acquisition d'un micro Sennheiser de concert à 1k€.</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
Il y a par contre quelques points que je note, et que je voudrais partager parce que je suis régulièrement moi-même dans un trois rôles : organisateur, speaker, ou "filmer".</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
<span style="color: orange; font-size: x-large;"><b>1. P</b></span><b>rivilégier le son</b>. L'image du speaker n'a pas grand importance, si le son n'est pas bon, personne ne supportera votre vidéo plus de 2 minutes. Thomas a d'ailleurs fait un autre article sur comment filmer avec un bête smartphone, j'en vois aussi utiliser de GoPro. Bref, n'investissez pas dans un super caméscope si vous n'avez pas déjà un bon micro. L'entrée de gamme est malheureusement décevant, il faut donc accepter d'y mettre des sous. J'ai de bons résultats avec un micro canon, placé en face du speaker. C'est pas trop intrusif (vs un serre tête) et ça donne un bon signal de base. L'autre option c'est le Lavalier "micro cravate", mais là attention pour avoir un bon micro il faut accepter d'y mettre des sous, et accessoirement ça suppose une transmission sans fil si vous ne voulez pas que le speaker se prenne les pieds dans un cable et arrache tout.</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
Ensuite, il faut un enregistreur. Les Zoom sont très bien, mais sinon une carte son USB et un enregistrement directement sur PC peut faire le taf. C'est juste plus encombrant. NB: les caméscopes grand public n'ont souvent pas d'entrée micro, et même avec les circuits audio intégrés sont souvent source de souffle, donc à éviter.</div>
<br />
J'ai déjà vu un meetup ne capter que les slides et le son, et ne pas filmer le speaker. Ben au final la vidéo est tout aussi utile, même si elle manque inévitablement de vie.<br />
<br />
<span style="color: orange; font-size: x-large; text-align: justify;"><b>2. N</b></span><b style="text-align: justify;">e pas être intrusif</b><span style="text-align: justify;">. Exemple type : l'éclairage. Oui, pour filmer, il faut de la lumière. Et oui, pour que les slides soient lisibles, il en faut le moins possible. </span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">En tant qu'orga, je privilégie les gens qui sont venu physiquement au meetup, donc si la lumière les dérange je demanderai de la couper, tant pis pour la captation (de toute façon, voir 1.)</span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">En tant que speaker, un spot dans la tronche ce n'est pas non plus très agréable. Un speaker chevronné sera un peu plus habitué, mais un novice peut être déstabilisé.</span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">Le meilleur setup c'est de pouvoir décaler le speaker par rapport à l'écran, et de l'éclairer de côté avec deux projos plutôt directionnels et équipés de coupe-flux (les 4 plaques autour d'un projecteur de cinéma). Ca évite de tout lui balancer dans la tronche, ça fait une lumière plus jolie (la lumière de face écrase les ombres du visage) et les brise flux permettent d'épargner l'écran. </span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">Pour le BreizhCamp on a sorti les projecteurs de théâtre de 500W mais bien sur c'est €€€ et pas très portable, à la place sans investir beaucoup on peut bricoler un truc avec des petits projos LED.</span><br />
<br />
Même règle de ne pas venir déranger le meetup pour ce qui est de la captation son (cf 1.) ou de la captation des slides, d'ailleurs ...<br />
<br />
<span style="color: orange; font-size: x-large; text-align: justify;"><b>3. C</b></span><b style="text-align: justify;">apter les slides</b><span style="text-align: justify;">. Un speaker • euse qui parle avec les mains c'est sympa, mais un live coding sans voir le code c'est pas terrible. Filmer "large" pour capturer aussi l'écran de projection pose plein de problèmes, d'une part de luminosité, d'autre part de "piqué" (en général, c'est difficilement lisible).</span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">La solution de facilité c'est le petit soft de capture qu'on installe sur le PC speaker. On va par contre à l'encontre de la règle 1., mais bon si le speaker est prévenu à l'avance ça peut être jouable.</span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">Sinon, pour capter le signal HDMi on trouve aujourd'hui du matos adapté pour pas top cher. En gros, une carte blackmagic dans un boitier extension PCI sur USB-C, et on a un système de captation portable.</span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;">Attention à bien respecter le point 2: parfois le speaker a un setup exotique (un PC Windows 10 4k par exemple) et la captation merde. Dans ce cas, à meetup -2 minutes il faut accepter de laisser tomber la captation pour que le public puisse profiter du meetup, tant pis c'est la vie voilà.</span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;"><br /></span>
<span style="color: orange; font-size: x-large; text-align: justify;"><b>4. C</b></span><b style="text-align: justify;">ollaborer</b><span style="text-align: justify;">. J'avais dit qu'on ne parlerais pas matos et pourtant j'ai pas arrêté. Du coup se pose une question simple : les</span><span style="text-align: justify;"> organisateurs de meetup - qui ont la plupart du temps des sponsors - peuvent-ils contribuer à l'achat de matériel ? Un éclairage soigné du speaker est nécessaire pour la captation mais peut être aussi utile de manière plus générale pour baisser la lumière générale et avoir des slides bien nets tout en gardant un speaker bien visible même du fond de la salle. </span><br />
<br />
<span style="text-align: justify;">De ce que je comprend (j'ai pas eu l'occasion d'en discuter de visu) Thomas débarque dans un meetup et se propose de filmer. Cool. Par contre les contraintes techniques apparaissent du coup au dernier / mauvais moment. En discutant plus en amont avec les orgas pour aménager un peu le meetup il est possible de mieux gérer tout ça et d'éviter ces mauvaises surprises. </span><br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;"><br /></span>
<span style="color: orange; font-size: x-large; text-align: justify;"><b>B</b></span><b style="text-align: justify;">ref</b><span style="text-align: justify;"> </span><span style="text-align: justify;"> si vous voulez filmer un meetup, déjà essayez ! Ce qui précède ce ne sont que des conseils après plusieurs années de merdages répétés et de mauvais choix. Ne soyez pas forcément trop ambitieux, mais gardez les règles ci-dessus en tête. Je vous propose d'ailleurs cette progression :</span><br />
<span style="text-align: justify;"><br /></span>
<br />
<ol style="text-align: left;">
<li>Commencer par un bon enregistrement son. Accompagné du lien slideshare ça peut déjà être sympa. Style podcast. Si vous êtes courageux vous pouvez alors faire un montage slides + son. Ajoutez un écran d'intro avec la photo du speaker ça lui fera plaisir :P</li>
<li>Essayer de capturer la sortie vidéo ou de trouver un soft acceptable par vos speakers. J'ai pas de recommandation, perso j'ai horreur de ça (j'ai eu un gros plantage une fois, merci).</li>
<li>Filmez le speaker et faite un joli montage picture-in-picture comme les pros. </li>
</ol>
<div>
Vous le voyez, dans cette recette, filmer le speaker c'est le dernier point, la cerise sur le gateau. Essayez donc de déjà faire un gateau sympa avant de vous embarquer dans des trucs compliqués et intrusifs.</div>
<div>
<br /></div>
<div>
Notez bien que je parle de captation de meetup ici, pas d'interview, vidéo d'ambiance, etc. Ca c'est un tout autre sujet :D</div>
<br />
<span style="text-align: justify;"><br /></span>
<span style="text-align: justify;"><br /></span></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com3tag:blogger.com,1999:blog-21628438.post-3946405970054585142017-06-19T16:08:00.001+02:002017-06-19T16:08:24.888+02:00Jenkins Community Day à Paris<div dir="ltr" style="text-align: left;" trbidi="on">
Le 11 Juillet, JFrog organise le <span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;">Jenkins Community Day à Paris, une excellente opportunité pour rencontrer ceux qui font Jenkins et découvrir toutes les nouveautés et tendances dans le monde du Continuous Delivery.</span><br />
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;"><br /></span>
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/Y_WbRj0AgZg/0.jpg" src="https://www.youtube.com/embed/Y_WbRj0AgZg?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;">J'y serais présent en tant que speaker pour vous présenter l'évolution du couple Jenkins + Docker ces dernières années, et les pistes pour l'avenir - le tout en mode "Back to the Future", parce qu'on peut parler de choses sérieuse sans s'y prendre sois-même aux. </span><span style="background-color: white; color: #222222; font-family: arial, sans-serif;"><span style="font-size: xx-small;">(si vous connaissez une tournure correcte pour cette phrase sans répéter "sérieux" je suis preneur)</span></span><br />
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;"><br /></span>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi1p74jYymTrAHGrY-40xkMz9g5lItaODYJoIgluuwHsote8J3y1doVB8RB9ZlvhyeI7ahXyloUPHlWcEqBaThto6hUE39fPx6M1T6vwpbQuad4XOdnKvXr-tyruhcG9p_E68l/s1600/Nicolas+de+Loof.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="628" data-original-width="1200" height="167" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi1p74jYymTrAHGrY-40xkMz9g5lItaODYJoIgluuwHsote8J3y1doVB8RB9ZlvhyeI7ahXyloUPHlWcEqBaThto6hUE39fPx6M1T6vwpbQuad4XOdnKvXr-tyruhcG9p_E68l/s320/Nicolas+de+Loof.png" width="320" /></a></div>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;"><br /></span>
<span style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 14.6667px;">Si vous voulez m'y rejoindre, <a href="https://www.eventbrite.com/e/billets-jenkins-community-day-paris-2017-33850605071?discount=SpeakerFriends">passez par ici</a> pour obtenir une réduction sur votre inscription.</span></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com2tag:blogger.com,1999:blog-21628438.post-25722192513645871632017-06-19T08:00:00.000+02:002017-06-19T08:00:07.683+02:00Docker et la Sécurité<div dir="ltr" style="text-align: left;" trbidi="on">
Chose promise, chose due<br />
<br />
Voici donc la première vidéo qui marque le retour de "Quoi d'neuf Docker". J'y parle de Docker et de la Sécurité, un thème qui amène de nombreuses questions et pas mal de fantasmes. Je compte d'ailleurs faire une vidéo "follow-up" pour répondre à vos réactions/questions/corrections, donc n'hésitez pas à pousser un commentaire (sur YouTube).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/vcYhvzJZqBg/0.jpg" src="https://www.youtube.com/embed/vcYhvzJZqBg?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com3tag:blogger.com,1999:blog-21628438.post-81290937871074555852017-06-09T09:59:00.000+02:002017-06-09T09:59:28.321+02:00Quoi d'neuf Docker Reloaded<div dir="ltr" style="text-align: left;" trbidi="on">
Je vous annonçais dans un billet de décembre (décidément, ce blog n'est plus très prolifique...) mettre un terme à ma chaine Youtube "Quoi d'neuf Docker". Cet article avait fait suite à plusieurs mois à tenter de me motiver pour sortir une vidéo sur Docker Swarm, qui aurait fait suite à son lancement à la DockerCon'16. Enregistrée deux fois, la vidéo manquait du peps que je veux insuffler dans mes vidéos, le texte était bancal, les tentatives de montage laborieuse (si tu as de la merde en entrée...)<br />
<br />
BREF, j'ai baissé les bras, à contre coeur, mais constatant mon incapacité à avancer<br />
<br />
Depuis, j'ai reçu de nombreux messages d'encouragement ou de remerciement, qui paradoxalement me laissent un gout amer : <b>j'ai merdé</b>.<br />
<br />
Vous m'avez fait confiance, vous m'avez encouragé, vous m'avez soutenu, y compris financièrement, et plouf je baisse les bras, c'est pas très classe.<br />
<br />
Par ailleurs, merde j'aimais bien faire ces vidéos. D'une part j'ai appris plein de choses en les préparant - il y a une <b>énorme</b> différence entre faire un truc et savoir l'expliquer - mais aussi je me suis bien amusé sur les montages, tentatives d'effets spéciaux plus ou moins réussis, et ça c'est un truc qui me botte. D'autant qu'il y a une marge de progression gigantesque dans ce domaine.<br />
<br />
En en discutant avec mes copains du BreizhCamp, j'ai réussi à embarquer sans avoir besoin d'insister Yoann et Sylvain pour me prêter main forte. Essentiellement pour me botter le cul, mais aussi pour relire les textes (qui du coup sont plus préparés) et me pousser des idées.<br />
<br />
Je suis donc heureux de vous annoncer le retour de Quoi d'neuf Docker<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCtsM83BVw0O-NtofN4ghuB6vXH1Mi4Acpf_B6Pg2TnPI0SsWcjG32uqryJ8jsGJ8dE2m7mfxYDank7PMtTbIVjCnIWSR-GpMkxXOMXD483uU3L9lBY-LS3JlUdvYTGNZeXfIo/s1600/images.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="756" data-original-width="504" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCtsM83BVw0O-NtofN4ghuB6vXH1Mi4Acpf_B6Pg2TnPI0SsWcjG32uqryJ8jsGJ8dE2m7mfxYDank7PMtTbIVjCnIWSR-GpMkxXOMXD483uU3L9lBY-LS3JlUdvYTGNZeXfIo/s320/images.jpg" width="213" /></a></div>
<br />
Et comme vous l'aurez compris, le côté "vidéo" m'éclate bien, donc j'ai embauché l'équipe pour un trailer.<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/zJwqulREcmM/0.jpg" src="https://www.youtube.com/embed/zJwqulREcmM?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
La prochaine vidéo avec du vrai contenu sortira si tout va bien avant fin juin (le texte est prêt, y'a plus qu'à). Le sujet c'est ... et bien vous verrez bien, mais histoire de faire les choses comme il faut pour me faire pardoner d'un an sans publication, j'ai abordé le sujet qui m'était le plus réclamé :P</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
A+</div>
<div class="separator" style="clear: both; text-align: justify;">
<br /></div>
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com1tag:blogger.com,1999:blog-21628438.post-44058329709612715022017-02-06T12:46:00.003+01:002017-02-06T12:46:46.607+01:0010 ways for a speaker to upset conference organizers<div dir="ltr" style="text-align: left;" trbidi="on">
Cet article est une réaction à <a href="https://www.troyhunt.com/10-ways-for-a-conference-to-upset-their-speakers/?utm_content=buffer2976c&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer">cet autre article</a>.<br />
<br />
Dans l'article en question, l'auteur - que je ne connais pas, de toute évidence une star dans son domaine vu son propos, moi désolé jamais entendu parler - énonce 10 points qui l'horripilent lorsqu'il intervient dans une conférence.<br />
Etant à la fois speaker et organisateur, je vous propose ma vision des choses...<br />
<h3 style="text-align: left;">
Forcing a slide template on people</h3>
<div>
Je dois l'avouer, c'est souvent très chiant. Le support dans les outils de présentation de <i>templates</i> est d'ailleurs assez mauvais, et lorsqu'on en change toute la mise en page est à refaire. Cependant, en tant que speaker, lorsqu'on ne m'impose pas un template - je précise qu'on ne me l'a jamais "imposé", juste très fortement recommandé, ce qui n'est pas la même chose, j'aurais pu faire ma conférence sans, et ne pas pour autant être blâmé - j'ai pour habitude d'essayer a minima d'intégrer le logo de la conférence dans les slides. Ca s'appelle respecter son hôte.</div>
<h3 style="text-align: left;">
Asking for slides in advance</h3>
<div>
Ca ne m'est jamais arrivé, j'ai parfois vu cette option dans un Call for Papers, mais généralement on me demande plutôt une vidéo d'une de mes intervention pour estimer mes qualités de speaker. J'admet que si ça m'arrivait je serais emmerdé. Il est assez courant que j'ajuste mes slides au denier moment, souvent en fonction des sessions qui ont précédées ou qui sont au programme et recouvrent mon sujet "<i>pour en savoir plus, allez voir XX salle YY à 16h</i>".</div>
<h3 style="text-align: left;">
Asking for slides after the talk</h3>
<div>
Sérieux, peut-on reprocher à une conférence de vouloir regrouper les slides sur leur site web ? Bien sur, l'essentiel de la conférence n'est pas dans les slides, mais il y a TOUJOURS des gens pour vous les demander. Franchement ce n'est pas pour ce que ça coute, sans parler des très nombreux speakers qui les mettent en ligne d'eux-même</div>
<h3 style="text-align: left;">
Screens that are only 4:3</h3>
<div>
Alors là mon gars, je sais pas dans quel monde tu vies, mais quand on est organisateur, on est bien obligé de faire avec ce qu'on trouve dans les rares lieux qui correspondent à l'événement qu'on prévoit. Et oui, parfois on a de vieux projecteur 4:3 qui poussent à peine en 1024x768. Mais pour quelqu'un qui nous explique que son talk ne se résume pas à ses slides, je trouve que la critique tombe bien mal.</div>
<h3 style="text-align: left;">
Badly prepared rooms</h3>
<div>
J'admet qu'un micro qui part en vrille au bout de 10 minutes, ou pire : un micro pupitre qui t'interdit tout mouvement, c'est pénible. Seul point sur lequel je suis d'accord. Ceci dit, un bon micro serre tête sans fil ça coute un bras, aussi voir le point précédent.</div>
<h3 style="text-align: left;">
Conference laptops are (usually) painful</h3>
<div>
Je n'ai jamais fait cette expérience, et je n'aurais pas l'idée de l'imposer à un speaker. Mais de toute évidence ça arrive. Si c'est le cas j'admet que c'est un soucis au niveau de l'organisation, à savoir que permettre au speaker de vérifier sa connectique avant son intervention est un minimum. Maintenant, encore faut-il que le speaker en question soit présent à l'avance et joignable :P</div>
<h3 style="text-align: left;">
Not covering T&E is a massive no-no</h3>
<div>
Ben tiens. Viens vendre ta camelote, je te payerais le billet d'avion avec plaisir ! Y'en a qui n'ont peur de rien. Evidemment il existe des speakers qui se font rémunérer, mais là on parle d'autre chose, non?</div>
<div>
Dire ça, c'est clairement ne pas comprendre le modèle économique d'une conférence, qui doit jongler entre ce qu'elle arrive à soutirer des sponsors, et le prix du billet qu'elle veut afficher. Alors oui, on peut faire des conférences de riche avec des billets à 1500€ et payer l'avion à tous les speakers, ou bien ne proposer une assistance financière qu'au cas par cas et conserver un billet abordable.</div>
<h3 style="text-align: left;">
Bad hotels are bad</h3>
<div>
Désolé, la suite présidentielle n'était pas libre. Et nous ne payons pas non plus le service de callgirls. </div>
<h3 style="text-align: left;">
Not allowing me to arrange my own flights</h3>
<div>
Bon là, clairement on est dans la catégorie Lady Gaga, je ne sais même plus quoi dire. Le mec on lui paye l'hotel, l'avion, et il est pas content parce que c'est compliqué d'indiquer ses contraintes.</div>
<h3 style="text-align: left;">
Not treating conferences as a mutually-beneficial relationship</h3>
<div>
Vu le discours, il est clair que le "beneficial" dans un des deux sens il est évident. En tant qu'organisateur, je laisserais le plaisir à d'autres de gouter à l'autre direction de la <i>relationship</i>.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
Voilà, bref, ce discours de speaker-star m'exaspère. Ce mec mériterait un bon entartrage (tarte évidemment financée par l'organisateur)</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com10tag:blogger.com,1999:blog-21628438.post-67519401347623331502016-12-13T19:04:00.003+01:002016-12-13T19:04:59.329+01:00Quoi d'neuf Docker ? ... ben rien justement<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Il y a quasiment un an jour pour jour je me lançais dans l'aventure Quoi d'neuf Docker, avec le soutien inespéré de nombreux internautes pour mener au bout une campagne de Crowdfunding, suivie d'une série de vidéos pour lesquelles j'ai pu tester différents styles et en même temps en apprendre beaucoup sur Docker.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Force est de constater que, depuis la dernière vidéo diffusée en Juillet, la chaîne montre un encéphalogramme plat. Il est donc temps pour moi de déclarer sa mort clinique.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Pour faire court, depuis Juillet j'ai changé de poste, et j'ai nettement moins de temps libre avec en plus de régulières réunions en soirée (merci les 9 heures de décalage horaire avec la côte Est). J'ai aussi de nouvelles contraintes familiales à considérer, et par dessus cela ces derniers temps des soucis qui me bouffent le peu qui me restait de "temps libre".</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Disons les choses clairement, même si l'envie de filmer une nouvelle vidéo revient régulièrement, si ce n'est pas la préparation du contenu qui pose problème, si même mon public est encore assez sympa pour m'encourager, je sais que de longues heures de montage m'attendent, et que cela va s'éterniser.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
J'ai ainsi un tiers de vidéo "docker-swarm" qui dort sur mon disque dur depuis deux semaines, et qui va rester dans cet état inachevé car je me rend bien compte que je ne trouverais pas le temps ni l'énergie pour en venir à bout.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Plutôt que de bâcler, je préfère renoncer, et laisser les nombreux Docker Captains qui en ont encore l'énergie vous abreuver des informations que vous attendez d'eux. Je me doute que quelques un seront déçus, mais rassurez vous d'ici quelques jours ce sera oublié.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Merci à tous ceux qui m'ont soutenu et encouragés pendant cette expérience très riche d'enseignements. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUQ7Um6hgHJ19IeytKUvJxJatcRv0IZD9wcxYQNm_k_wreZWRlyWs4xBqCoTAikb8LQwpYE7wdsLA1FnQruh3czg-0kKxOhe71WAxbXXm8NrIdC0HOSG8J5IvHe2AwOBRHjmEu/s1600/that%2527s+all+folks.png" imageanchor="1"><img border="0" height="272" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUQ7Um6hgHJ19IeytKUvJxJatcRv0IZD9wcxYQNm_k_wreZWRlyWs4xBqCoTAikb8LQwpYE7wdsLA1FnQruh3czg-0kKxOhe71WAxbXXm8NrIdC0HOSG8J5IvHe2AwOBRHjmEu/s640/that%2527s+all+folks.png" width="640" /></a></div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com5tag:blogger.com,1999:blog-21628438.post-75005719866158834142016-10-30T16:59:00.001+01:002016-10-30T17:07:21.096+01:00J'ay pris le temps d'e-lire<div dir="ltr" style="text-align: left;" trbidi="on">
Je viens de finir le deuxième tome de "<i>Prenez le temps d'e-penser</i>", le bouquin de <a href="https://fr.wikipedia.org/wiki/Bruce_Benamran">Bruce Benamran</a>, célèbre pour sa chaine Youtube de vulgarisation scientifique dont le succès ne faiblit pas.<br />
<br />
J'ai eu le plaisir de rencontrer brièvement Bruce (je me permet donc de l'appeler par son prénom) lors d'une séance de dédicace du tome 1. Le bonhomme est souriant et disponible, aussi j'espère qu'il appréciera mon honnêteté dans ce billet - en supposant qu'il le lise, c'est un autre histoire, le Bruce étant très demandé je n'arrive pas bien à me représenter à quoi doit ressembler son agenda.<br />
<br />
Pour commencer, un petit mot : Bruce est pour moi un modèle, ses capacités pédagogiques naturelles me laissent sans voix, le seul auteur qui m'ai laissé cette impression est <a href="http://www.dunod.com/sciences-techniques/sciences-fondamentales/physique-et-astrophysique/master-et-doctorat-capes-agreg/le-cours-de-physique">Richard Feynman</a> c'est dire. C'est en suivant ça chaîne que j'ai décidé de lancer la mienne, frustré par le format trop linéaire des conférences que je présente par-ci par là. Voilà.<br />
<br />
<br />
Je vous livre donc mon avis de lecteur.<br />
<br />
<h3 style="text-align: left;">
D'abord sur le <a href="http://www.marabout.com/prenez-le-temps-de-penser-tome-1-9782501104920">Tome 1</a>.</h3>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.marabout.com/sites/default/files/styles/couv_livre_detail/public/images/livres/9782501104920-001-X.jpeg?itok=aWlEKfNN" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.marabout.com/sites/default/files/styles/couv_livre_detail/public/images/livres/9782501104920-001-X.jpeg?itok=aWlEKfNN" height="320" width="221" /></a></div>
<br />
<br />
Bon commençons par dire que c'est un excellent bouquin à mettre entre toutes les mains. Sympathique, sur le ton de la conversation pleine de pointes d'humour, de références geek et autres détours qui rendent le texte très agréable, j'ai dévoré ce livre en 2 jours. Je m'attendais à ce qu'il reprenne des sujets et anecdotes déjà présentés en vidéo, aussi ce n'est pas un point qui m'a déplu, le contraire m'aurait en fait déçu, le livre étant ainsi la pleine continuité de la chaîne Youtube.<br />
<br />
Je suis par contre un peu resté sur ma faim sur deux aspects : l'explication de la relativité du temps et de l'espace et un sujet foutrement compliqué, qui brutalise notre sens commun, et qu'il est bien délicat d'expliquer sans un tableau blanc et quelques schémas. Bruce à fait le choix de se concentrer sur du pur texte, ce qui rend ce chapitre étrangement difficile par rapport à la fluidité d'explication et aux analogies ingénieuses auxquelles il nous avait habitué. Bon clairement, je vois mal comment présenter le sujet autrement, je ne dis pas qu'on puisse faire tellement mieux ... mais de mémoire il me semble que j'avais plus <i>tilté</i> à la lecture de (l'excellent) <a href="http://www.laffont.fr/site/l_univers_elegant_&100&9782221090657.html">Univers Elegant</a>. Ou alors j'ai peut être juste eu le temps de digérer le truc ? Comme Bruce s'est en plus amusé à nous faire une révision des présidents de la 5ème république, je me demande s'il n'a pas fait exprès de nous mettre un chapitre destiné à être lu deux fois (ou plus) histoire qu'on soit bien imprégnés.<br />
<br />
Second aspect, qui m'a fait retirer un dixième de point dans mon classement des livres indispensables que j'achèterais en triple pour les offrir à mes gamins, le chapitre sur la mécanique qui se présente comme une suite de concepts, annoncés comme un mal nécessaire. C'est très inhabituel de la part de Bruce qui met un point d'honneur à rendre tout sujet à la fois clair, amusant et immédiatement compréhensible.<br />
<br />
Pour avoir été moi même auteur (<a href="https://www.amazon.fr/Apache-Maven-Nicolas-loof/dp/274402337X">Apache Maven</a> - 1500 exemplaires vendu, j'aurais peut être du choisir un sujet un peu plus <i>large</i>) je sais aussi qu'il faut parfois savoir jongler avec les délais de l'éditeur et que - malheureusement - certains chapitres en souffrent. Tout le monde n'est pas un George R.R. Martin... Bon ceci dit ce n'est qu'une spéculation appuyée sur du vent, peut être que Bruce voulait faire ça comme ça et puis c'est tout, lui seul le sait et il fait ce qu'il veut de toute manière, et le succès des ventes du livre semble montrer que ça n'a gêné personne...<br />
<br />
Donc en résumé, une oeuvre qui est <b>un morceau de choix</b> pour tout lecteur intéressé un temps soit peu à la science, et à laquelle j'ai trouvé quelques critiques juste par ce que je suis un éternel insatisfait.<br />
<br />
<br />
<h3 style="text-align: left;">
Passons au <a href="http://www.marabout.com/prenez-le-temps-de-penser-tome-2-9782501117166">Tome 2</a></h3>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.marabout.com/sites/default/files/styles/couv_livre_detail/public/images/livres/9782501117166-001-X.jpeg?itok=uNiNerO6" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.marabout.com/sites/default/files/styles/couv_livre_detail/public/images/livres/9782501117166-001-X.jpeg?itok=uNiNerO6" height="320" width="212" /></a></div>
<br />
Dans ce tome, on attaque (entre autre) des sujets qui annoncent une sacré migraine : mécanique quantique, big bang, cosmologie, trou noirs et théorie de cordes...<br />
<br />
Et là, je retrouve le Bruce que j'apprécie : AUCUN chapitre n'a relevé pour moi un quelconque point négatif. Malgré le sujet pourtant ardu et profondément <i>imbitable</i> pour le sens commun, Bruce arrive à nous préparer avec soin et à présenter chaque sujet, toujours avec ce fabuleux mélange d'humour, d'histoire des sciences, et d'analogies - et quand on parle de mécanique quantique, faut avoir une sacré imagination pour en trouver.<br />
<br />
Je me dis que pour ce tome 2, Bruce était plus rodé, confiant, peut être moins pris avec la fin de la tournée de l'eXoConférence ? Avec la <a href="https://www.youtube.com/channel/UCNAaM25o2k2Guv7Lrf-xuDw">chaine en anglais</a> j'en doute, mais bon. En tout cas, c'est un vrai régal. Et oui, sur ce coup là je n'ai rien à redire, pas le moindre petit truc à relever. Mince alors. Je vais le relire pour être sur...<br />
<br />
Ah si : <b>énorme</b> déception d'apprendre qu'il n'y aura pas de tome 3. Sur sa chaîne Bruce ne se contente pas de présenter les <i>sciences dures (i.e physique fondamentale) </i>mais aussi beaucoup d'autres sujets, traités avec le même soin et toujours des références approfondies, concernant la biologie, le <a href="https://www.youtube.com/watch?v=7GiQuG2S26Q">fonctionnement étonnant du cerveau</a>, abordant parfois des problèmes qui <a href="https://www.youtube.com/watch?v=6G5SiVJnJM4">touchent à la sociologie</a>, ou bien des <a href="https://www.youtube.com/watch?v=HQIGBqYGNGQ">aspects méconnus de mécanique</a>, enfin bref ça part dans tous les sens pour le plus grand plaisir des abonnés. Les deux bouquins abordent aussi ces sujets, mais dans une moindre mesure. Il y aurait donc matière pour un tome 3, 4, ... Mais bon, l'auteur fait ses choix, c'est le principe d'un auteur, c'est lui qui décide.<br />
<br />
Donc bref, j'ai adoré ce bouquin et je suis extrêmement déçu d'avoir raté la dédicace à Rennes cette semaine - j'étais en vacances dans le Finistère, avec la crève en prime :'( - qui m'aurait donné l'occasion de féliciter Bruce de vive voix pour ce deuxième acte de son oeuvre. Vous l'avez deviné, je suis un fan, j'ai même tenté d'emprunter son style dans <a href="https://www.youtube.com/watch?v=KMttioiBQc0">une de mes vidéos</a> (après m'être tenté à imiter <a href="https://www.youtube.com/watch?v=zO4-1D9LdDw">Karim</a>, <a href="https://www.youtube.com/watch?v=2tP9PgvmBSY">Fred</a> ou <a href="https://www.youtube.com/watch?v=1ZgDo1Lx7yQ">François</a>) ... <i>comme quoi c'est pas si simple</i><br />
<br />
<br />
Je profite de ce billet pour faire savoir à ceux qui ont raté l'info (?) que Bruce a mis à jour son site vitrine <a href="http://e-penser.com/">e-penser.com</a> qui propose maintenant des annonces et du contenu exclusif.<br />
<br />
Donc bref, pour noël ou n'importe quel autre prétexte, n'hésitez pas à sortir 19,90€ (x2) pour faire des heureux.<br />
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com3tag:blogger.com,1999:blog-21628438.post-51957568556611859012016-09-13T22:51:00.000+02:002016-09-15T07:22:57.204+02:00Docker-Slaves 1.0 released<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
This week is <a href="http://jenkinsworld.com/">JenkinsWorld</a>, and I won't be there ... but this doesn't mean I won't be part of it.<br />
<br />
<b><span style="font-size: large;">I'm pleased to announce <a href="https://wiki.jenkins-ci.org/display/JENKINS/Docker+Slaves+Plugin">Docker-slaves-plugin</a> has reached 1.0.</span></b><br />
<br />
Docker-slaves was created on year ago, as <a href="https://twitter.com/yoanndubreuil">Yoann</a> and I joined forces during DockerHackDay, with complementary ideas in mind to re-invent Jenkins in a Docker world. We are proud we were able to develop a working prototype within 24 hours and won 3rd prize on this challenge !<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://avatars3.githubusercontent.com/u/19631904?v=3&s=500" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://avatars3.githubusercontent.com/u/19631904?v=3&s=500" width="320" /></a></div>
<br />
<br />
What makes Docker slaves such a revolution ?<br />
<br />
Docker-related Jenkins plugins so far use a single docker container to provide a Jenkins agent (aka "slave"), which will host a build. Such a container is running a Jenkins remote agent and as such has to include a JRE, and allow connection from master or connect to master by itself. In both cases, this introduces significant constraints on the Docker image one can use. We want this to disappear.<br />
<h3 style="text-align: left;">
With Docker-slaves, you can use <i><span style="color: #0b5394;">ANY</span></i> docker image to run your build.</h3>
<br />
To communicate with remote agent, Jenkins establish a communication channel with slave. On ssh slave, this communication uses the ssh connection as a tunnel. Other slave launcher uses various tunneling techniques or explicit port allocation to create this channel. But docker also has an interactive mode to run a container, which let us establish a stable (encrypted) connection with a remote container. Running `docker run -it` is very comparable to running a ssh client to connect to a remote host. So we use this capability to create the remoting channel directly on top of docker's interactive mode.<br />
<h3>
SSHD in docker container is evil. Docker-slaves don't need one, and does not require your master to expose JNLP on the Internet </h3>
<div>
<br /></div>
<div>
Docker is not just about container, it's also about container<u><b>s</b></u>. docker-compose is a popular tool and demonstrate need to combine containers together to build useful stuff. We think a build environment has the same requirement. You need maven to build your project, but you also need a redis database and a web browser so you can run Selenium functional tests. Just create 3 containers, and link them together ! This is exactly what Docker-slaves does, so you can define your build environment as a set of containers. </div>
<div>
<h3>
Docker-slaves let you compose your build environment </h3>
<div>
<br />
... and you can even define those containers using a <span style="font-family: "courier new" , "courier" , monospace;">Dockerfile</span> you store in SCM ! If you love infrastructure as code, you'll be happy to get both your source code, continuous deployment pipeline script, and build environment stored all in your project SCM with plain Dockerfiles. Docker-slaves will build the required image on demand and run the build inside this container.<br />
<h3>
Docker-slaves bring Continous-Delivery-as-Code to next level</h3>
<br /></div>
</div>
<div>
Docker slave also adds a transparent "remoting" container so Jenkins plumbing is well setup and <i><b>all</b></i> Jenkins plugins work without any change. This includes <a href="https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin">Pipeline plugin</a>. This plugin used to require a classic jenkins slave as <span style="font-family: "courier new" , "courier" , monospace;">node()</span> to run build step, and this node to host a docker daemon if you want to run anything docker related. With docker slaves, just write your <span style="font-family: "courier new" , "courier" , monospace;">Jenkinsfile</span> without need for a single classic Jenkins executor.</div>
<div>
<br /></div>
<pre>dockerNode("maven:3.3.3-jdk-8") {
sh "mvn -version"
}</pre>
<div>
<h3>
<span style="font-size: small; font-weight: normal;">How does this compare to docker-pipeline's <span style="font-family: "courier new" , "courier" , monospace;">docker.inside</span> ? There's no need for a host jenkins Node here, nor a local Docker daemon installed on your jenkins slaves. You can rely on docker swarm to scale your build capacity.</span></h3>
<h3>
Docker-slaves do embrace Pipeline</h3>
</div>
<br />
Last but not least, Jenkins docker-related plugins use to start with a fresh, new slave, which require to run a full SCM checkout and populate project dependencies. Docker-slaves uses a volume as build workspace, so this one is persistent between builds. There is huge room for improvement here, with assistance for docker's volume-drivers, typically to provide snapshot capability so you can browse workspace for a specific build (to diagnose a build failure) or replicate workspace on cluster.<br />
<div>
<h3>
Docker-slaves workspace is persistent</h3>
</div>
<div>
<br /></div>
If you have opportunity to give it a try, please send me feedback <a href="https://twiter.com/ndeloof">@ndeloof</a><br />
<div>
<br /></div>
<br />
<b>UPDATE</b>:<br />
For some odd reason <span style="font-size: x-small;">(who said "conspiracy" ?)</span> docker-slaves 1.0 was not published in <a href="https://updates.jenkins-ci.org/download/plugins/docker-slaves/">update center</a> (yet). Will need to investigate with Jenkins infra team, but with Jenkins World they are all higly busy this week.<br />
<br />
<br /></div>
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
<a href="https://twitter.com/ndeloof">@ndeloof</a> w00t ! Best plugin ever !</div>
— Damien Duportal (@DamienDuportal) <a href="https://twitter.com/DamienDuportal/status/775940029994577920">September 14, 2016</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com9tag:blogger.com,1999:blog-21628438.post-2502459473774608732016-06-20T19:30:00.000+02:002016-06-20T19:30:10.154+02:00DockerCon : quand docker-swarm laisse la place à docker swarm<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="background: #ffe; border: solid 1px #000; padding: 10px;">
<div style="text-align: justify;">
<b>tl:dr; </b></div>
<div style="text-align: justify;">
docker 1.12 = docker 1.11 + swarmKit + <i>server-side </i>docker-compose </div>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Dans ma <a href="https://www.youtube.com/c/quoideneufdocker">dernière vidéo</a> je vous parlais du changement d'architecture de Docker 1.11 et du fait que le démon docker ne fait "<i>plus grand chose</i>" - à part l'authentification et la gestion des images, quelques bricoles quoi.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Il faut croire que, comme la nature, l'équipe Docker a horreur du vide, puisqu'elle s'est empressée de remplacer ce déficit de fonctionnalités dans la version 1.12 (Release Candidate 2) annoncée ce matin en keynote de la DockerCon - et oui, j'étais au courant avant, nananèreu</div>
<h4 style="text-align: justify;">
Dcoker-swarm est mort, vive docker swarm</h4>
<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://pbs.twimg.com/media/ClX-AgYUYAAsdBI.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://pbs.twimg.com/media/ClX-AgYUYAAsdBI.jpg" width="320" /></a></div>
<br />
Vous aviez sans doute vu passer l'annonce de swarmKit, un projet issu de l'architecture de docker-swarm mais plus générale (on parle ici de "tâches", pas forcément de conteneurs docker). En fait ce projet est reparti de la page blanche, en reprenant ce qui a bien marché dans docker-swarm et en choisissant d'autres pistes pour ce qui marchait moins bien.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Typiquement, oubliez votre etcd / consul et le zookeeper qui va bien pour gérer un cluster swarm. Jusqu'ici, swarm avait besoin d'un service externe "clé/valeur" pour stocker la configuration du cluster. En plus de compliquer le setup pour assurer de la haute disponibilité, cela introduisait pas mal de délais dans le traitement asynchrone de la transmission de ces infos. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
SwarmKit utilise <a href="https://raft.github.io/">Raft</a>, protocole d'élection d'un noeud maître, et son implémentation par etcd. Plus besoin de service externe, un cluster swarm se suffit à lui même out-of-the-box pour distribuer ses métadonnées et élire son noeud "leader". </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Mais l'annonce de SwarmKit n'était que la partie visible de l'Iceberg, qui d'ailleurs à trompé pas mal de monde, car comme toujours les évolutions de Docker sont visibles sur le projet open-source pour qui sait lire entre les lignes des Pull-Requests.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker 1.12 annonce donc l'intégration native de swarmKit, pour former un cluster swarm sans quoi que ce soit d'autre que le démon Docker. Cette nouvelle feature n'est pas active par défaut (la compatibilité restant la première priorité). Il vous faudra explicitement passer en "<i>mode swarm</i>": <span style="font-family: "courier new" , "courier" , monospace;">docker swarm init</span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker 1.12 introduit aussi le concept de <i><b>services</b></i>, et permet de déployer N instances d'un conteneur sur le cluster (voir, sur tous les noeuds du cluster - parfait pour l'exploitation), de gérer leur re-schedule automatique en cas de défaillance, le load-balancing de ces N instances, les mises à jour en rolling-upgrade, etc. Bref, ce que vous faisiez jusqu'ici avec docker-swarm ou avec votre orchestrateur docker préféré (sic), vous pourrez le faire en natif avec le docker engine de base, dans le cadre d'un <i><b>cluster swarm</b></i> - le nom reste, je reconnais que ça peut être source de confusion, mais bon en même temps au final c'est le même concept.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Le load balancing c'est une nouveauté importante qu'il va falloir que je teste plus en profondeur. S'il est toujours possible d'utiliser le DNS avec la liste des IP associées à un service, ce qui suppose que votre code client gère ça correctement (sic), la nouvelle approche consiste à faire du load balancing en se basant sur <a href="http://www.linuxvirtualserver.org/software/ipvs.html">IPVS</a> (i.e passer par le noyau Linux). Les interactions exactes entre un <i>service</i> déployé de cette façon, les conteneurs qui lui permettent de tourner, et les réseaux / ports associés sont encore assez flous pour ce qui me concerne, cela nécessitera quelques tests plus appuyés.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
De son côté, le projet docker-swarm, s'il va vivre encore un moment (support client oblige) va rapidement être dépassé par ce support natif dans docker-engine.</div>
<div style="text-align: justify;">
<br /></div>
<h4 style="text-align: justify;">
Compose se fait tailler un short</h4>
<div style="text-align: justify;">
Seconde annonce majeure : l'ajout du concept de "service“ à l'API docker, avec des réplicas et un load balancing natif sur le cluster swarm.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<div>
Ca parait abstrait comme ça ? En pratique, vous allez déployer non plus un conteneur (même si vous pouvez encore) mais un "service" utilisant une image : </div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">docker service create --name foo --network bar ma_super_appli:1</span></div>
<div>
<br /></div>
<div>
Sur TOUS les noeuds de votre cluster swarm, et sur l'overlay network <span style="font-family: "courier new" , "courier" , monospace;">bar</span> indiqué, vous pourrez discuter avec ce conteneur. Et si vous augmentez le nombre d'instances :</div>
<div>
<span style="font-family: "courier new" , "courier" , monospace;">docker service update foo --replicas 5</span></div>
<div>
.. docker se chargera de faire du round-robin sur ces conteneurs pour distribuer la charge. Evidemment il y a toutes les possibilités de contraintes / affinités / labels de swarm pour jongler finement lorsque c'est nécessaire. </div>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Pour faire simple, jusqu'ici vous utilisiez docker-compose pour lancer une grappe de conteneurs. Rassurez-vous, vous allez sans doute continuer à faire ça en développement, et le format <span style="font-family: "courier new" , "courier" , monospace;">docker-compose.yml</span> n'est pas remis en question. Par contre, sur un cluster swarm docker-compose est exposé à une limite :</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker-compose utilise l'API docker pour faire de l'orchestration, mais un déploiement compose n'est pas atomique. Comprenez que si vos deux premiers conteneurs trouvent leur place sur un noeud, et que le troisième ne rentre pas faut de resources disponibles, et bien votre déploiement échoue, point barre. En gros, docker-compose est un orchestrateur côté client, en mode <i>optimistic transaction</i>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker 1.12 introduit le concept de "<i><b>bundle</b></i>", dont le format est encore très récent et sujet à évolutions (<span style="font-size: x-small;">i.e ne vous attardez pas dessus pour le moment</span>), qui définit un groupe de containers et comment les lier ensembles.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://pbs.twimg.com/media/ClWBufAUgAEvnFr.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://pbs.twimg.com/media/ClWBufAUgAEvnFr.jpg" width="320" /></a></div>
<br />
<br />
Oui, c'est tout pareil que docker-compose. D'ailleurs, <span style="font-family: "courier new" , "courier" , monospace;">docker-compose bundle</span> vous permettra de générer une spécification de bundle à partir de votre fichier <span style="font-family: "courier new" , "courier" , monospace;">docker-compose.yml</span>, il ne s'agit donc pas de remplacer compose, mais plutôt de le booster en lui fournissant une API à la hauteur de ses ambitions. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Ce bundle (un fichier JSON à ce stade, mais ça peut encore bouger), vous le passerez à votre démon docker via la commande docker deploy. La différence avec compose, c'est que le déploiement se fait alors "<i>côté serveur</i>", avec la sélection des noeuds en connaissance de cause.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Contrairement à docker-swarm, docker-compose va par contre subsister puisque son mode de fonctionnement continue à être pertinent en mode "<i>classic</i>" (non-swarm) - typiquement sur le poste de développement - et assurer la liaison avec le format de bundle.</div>
<div style="text-align: justify;">
<h4>
BREF</h4>
</div>
<div style="text-align: justify;">
docker-swarm vient de se prendre un balle, et docker-compose s'est fait couper les jambes par l'annonce de Docker 1.12. Ce qui est intéressant ici, c'est de voir que ces deux outils, conçus sur la base de l'API docker, avec ses contraintes et limites, voient au final leur fonctionnalité coeur intégrée dans docker-engine. Et vont donc pouvoir renaître en inventant de nouveaux usages et patterns, lesquels seront peut être un jour intégrés à leur tour... </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Ce cycle peut paraître surprenant quand on investi sur un outillage qui peut devenir obsolète au détour des annonces d''une keynote, mais il montre la dynamique raisonnée de l'écosystème Docker : si une fonctionnalité démontrer son intérêt, elle finit par être prise en charge nativement dans l'engine, vidant l'outil de sa raison d'être première, mais au final montrant que l'approche était bonne, et ouvrant la voie pour le cycle suivant.</div>
<div style="text-align: justify;">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://pbs.twimg.com/media/ClaRCBlVYAA4mXz.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="228" src="https://pbs.twimg.com/media/ClaRCBlVYAA4mXz.jpg" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A ce stade 1.12 n'est qu'une Release Candidate, et l'effet d'annonce pour la DockerCon a limité la période de test par la communauté (très occupée à s'accaparer SwarmKit). La version 1.12, bien qu'activement testée par de nombreux partenaires, va mettre donc encore quelque semaines à murir, sous les assauts d'une communauté qui ne va pas se priver de la secouer dans tous les sens pour vérifier que</div>
<div style="text-align: justify;">
<ol>
<li>ça continue de marcher comme avant </li>
<li>le nouvelles fonctionnalités tournent dans la vraie vie comme indiqué dans la doc</li>
</ol>
</div>
<div style="text-align: justify;">
Dans tous les cas, Docker 1.12 va changer pas mal de choses dans votre façon de déployer Docker, en intégrant les concepts de clustering et de déploiements composites au coeur de docker-engine.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com0tag:blogger.com,1999:blog-21628438.post-78510082937026491102016-05-31T11:17:00.003+02:002016-06-01T13:14:25.932+02:00Docker Cleanup<div dir="ltr" style="text-align: left;" trbidi="on">
Most Docker newcomers are disappointed when, at some time, after various experiments with Docker, they hit a <span style="color: red; font-family: "courier new" , "courier" , monospace;"><b>no space left on device</b></span> issue. Docker indeed do store all containers, images and volumes in <span style="font-family: "courier new" , "courier" , monospace;">/var/lib/docker</span>, which can quickly grow to gigabytes.<br />
<br />
One can find tons of blog post about how to cleanup this folder. Here I'd like to give my own tips, and to explain them in detail, so you don't run random command found by Googling the Internet.<br />
<br />
/var/lib/docker is used to store :<br />
<br />
<br />
<ul style="text-align: left;">
<li>docker images</li>
<li>docker container descriptors</li>
<li>docker networks descriptors</li>
<li>docker volumes</li>
<li>containers' layers (depends on the storage driver you used. Typically AUFS)</li>
</ul>
<div>
<br /></div>
<h4 style="text-align: left;">
Terminated containers</h4>
<div>
I use docker a lot to experiment unix commands, so use to run <span style="font-family: "courier new" , "courier" , monospace;">docker run --it ubuntu bash</span>. When you run a container without the <span style="font-family: "courier new" , "courier" , monospace;">--rm</span> option, container still exists on disk after the command complete. So doing this will create tons of containers, and layers for things I modified on container's filesystem. For this reason I created an alias <span style="font-family: "courier new" , "courier" , monospace;">docker-run</span> to ensure I don't forget this option. But this option can't be used with <span style="font-family: "courier new" , "courier" , monospace;">-d</span> (run in background) so I can't use it when I want to run some backend service for testing purpose. </div>
<div>
<br /></div>
<div>
As the end of the day, I have tons of stopped containers that I don't use anymore, and will just consume disk in /var/lib/docker. So I use this command to run some cleanup :</div>
<div>
<br /></div>
<div>
<pre class="brush: bash">docker rm -v $(docker ps --filter status=exited -q)
</pre>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="p1">
this command do list all exited containers (thanks to status filter), and only dump their ID (<span style="font-family: "courier new" , "courier" , monospace;">-q</span>). This ID list is used by the remove command to cleanup containers, including volumes they where using.<br />
<h4 style="text-align: left;">
Unused volumes</h4>
Volumes ? Yes, when you run a container which has been built with a VOLUME command in it's Dockerfile, docker do implicitly create a volume on disk, and may copy data from container image in this volume. This can result in significant disk consumption. Removing a container with <span style="font-family: "courier new" , "courier" , monospace;">-v</span> option do force docker to remove such volumes. This doesn't apply to bind mount volumes, only to volumes created by docker daemon.<br />
<div>
<br /></div>
If you already removed your containers without using -v, volumes remain orphaned in /var/lib/docker. You can remove them as well using :<br />
<br />
<pre class="brush: bash">docker volume rm $(docker volume ls -q -f 'dangling=true')
</pre>
</div>
</div>
<div>
<br /></div>
<div>
the "dangling" filter do select volumes that aren't referenced by any container.<br />
<br />
Note: one can find many scripts to do comparable cleanup by directly making changes to /var/lib/docker. Those script where written before <span style="font-family: "courier new" , "courier" , monospace;">docker volume</span> command was introduced in 1.9. Don't use them. Directly hacking your docker daemon storage isn't a good idea when you have a clean API for this purpose.<br />
<h4 style="text-align: left;">
Unused images</h4>
</div>
<div>
You can also use a comparable dangling filter with images, this one will detect image layers that are not referenced by a tag, which in many cases is the result of running docker builds.<br />
<br />
<pre class="brush: bash">docker rmi $(sudo docker images -f "dangling=true" -q)
</pre>
<br />
<br />
what about obsolete / unused images ?<br />
You can find some script to detect images which aren't used by a container on your system. For production environment this can make sense, but for my workstation this would remove mostly all docker images, as most container I run don't keep running all day long.<br />
<br />
Docker doesn't track image use by containers, <a href="https://github.com/docker/docker/issues/4237">this issue</a> is tracking attempt to change this, so writing a garbage collector would be simpler. So far I'm using https://github.com/ndeloof/docker-gc to collect image usage based on docker events. Not perfect, but does the job.<br />
<br />
<br />
Hope this helps.</div>
<div>
<br /></div>
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com2tag:blogger.com,1999:blog-21628438.post-70190859767816628142016-04-27T21:23:00.002+02:002016-04-27T21:23:48.029+02:00I'm now a Docker Captain<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: center;">
I'm now a Docker Captain</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.docker.com/sites/default/files/docker_captian_image.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://www.docker.com/sites/default/files/docker_captian_image.png" /></a></div>
Captains is a Docker program to organize their best advocates around the world, give them first class informations and contacts in Docker community, help them to experiment and spread the world with great Docker related content.<br />
<br />
Thanks to Docker captain program, we got access to Docker4Desktop before it was publicly announced, we get online webinars with engineering, and we now have a cool logo !<br />
<br />
I'm pleased to have been selected as a Captain, even my Youtube Channel <a href="https://youtube.com/c/Quoideneufdocker">Quoi d'Neuf Docker</a> is limited to French audience (maybe I should launch an english spoken one ?).<br />
<br />
Java has Java Champions program, I never have been invited to join, despite my awesome <a href="https://github.com/ndeloof/apache-maven-book">Apache Maven book</a> and talks at major conferences, seems it's easier to become a Docker star :P<br />
<br />
<br />
<br />
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com0tag:blogger.com,1999:blog-21628438.post-25034413757436702242016-04-25T07:31:00.000+02:002016-04-25T10:15:39.165+02:00cfp.io<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
I'm very excited to announce the launch of a long term project of mines: <a href="http://www.cfp.io/">cfp.io</a></div>
<div style="text-align: justify;">
<br />
<br /></div>
<div style="border: solid 1px #000; color: #3d85c6; margin: 10px; padding: 10px; text-align: justify;">
TLDR; Are you event organizer ? Need a free call-for-papers?
<a href="mailto:info@cfp.io?subject=[cfp.io]">Contact us</a>, we will host it for you.</div>
<h3 style="text-align: justify;">
History</h3>
<div style="text-align: justify;">
As a conference organizer, I've been handling call-for-papers for a while, and have actually worked on developing 3 of them (sic). </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br />
<ul>
<li>We started in <b>2012</b> with a simple google form to collect speakers proposals. This was a poor experience, but did the job. Anyway as developers we decided we need a dedicated tool to offer a better service.</li>
<li>In <b>2013</b> we created our own CFP, and worked on it during the pre-event period so it match our needs. Main issue took place in 2014 when we tried to restart it from the initial collect phase, as the later changes had unexpected impacts (soc)</li>
<li>In <b>2015</b>, <a href="http://www.devoxx.fr/">DevoxxFrance</a> offered to share his custom CFP application codebase. We forked it, and adapted to our needs. The codebase is written in Scala, and just for this reason I hardly was able to found volunteers to help us on this topic. Also, this application do cover lot's of Devoxx specific things, hidden in codebase. We ended with few speakers not being registered, as Devoxx do only offer a pass to the first two speakers, and we have labs with up to four of them :'(</li>
<li>In <b>2016</b>, we forked <a href="https://devfest.gdgnantes.com/">DevFest Nantes</a> Call for Papers application. This one was written in Java/Spring/Angular, had a nice look and feel, so was a great candidate. We noticed many glitches in backend, so decided to fix them ... and after few months had it mostly fully rewritten. Anyway, this was a smooth migration, and 4 volunteers where able to make it a great app.</li>
</ul>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Our CFP worked like a charm, and was then forked by NCfrats.io for their own need.</div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
So, is this the definitive CFP we need ?</h3>
<div style="text-align: justify;">
<b>No:</b> main issue here is to maintain forks of each others. As a sample, we discovered a security issue with our CFP, fixed it, but as this happened two weeks before the event, we didn't took time to let DevFest guys know about it (sorry guys). Also, people at NCrafts could introduce interesting features, and even git make it easy to backport such code, this could quickly become a hard task to keep everything in sync.</div>
<div style="text-align: justify;">
<br />
We believe a better approach is to colocate our Call-for-papers. a CFP is a low traffic application, limited data volume, and limited complexity. It's very easy to make our codebase multi-tenant, and we plan to offer free hosting for call for papers on our server. Each tenant will get access as https://{{my_awesome_event}}.cfp.io and will be able to manage his own stuff, without need to bother with infrastructure.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqcOMlOmP-UBIfkCfZULlOFXuhKdR5HcbV-TaIWGdrNBLJRURwBZd70283qtgx-JF-WKYBUOO5r-LPXCVP3X7ry9V5j_4jqSf7-w6qmWWHyYv9k9Kh1sxIfPmJQsSQh3Awy_tA/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2016-04-25+a%25CC%2580+07.28.55.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="403" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqcOMlOmP-UBIfkCfZULlOFXuhKdR5HcbV-TaIWGdrNBLJRURwBZd70283qtgx-JF-WKYBUOO5r-LPXCVP3X7ry9V5j_4jqSf7-w6qmWWHyYv9k9Kh1sxIfPmJQsSQh3Awy_tA/s640/Capture+d%25E2%2580%2599e%25CC%2581cran+2016-04-25+a%25CC%2580+07.28.55.png" width="640" /></a></div>
<br />
As code is open-source (AGPL) we will welcome contribution to offer additional features. If you have designed an integration with third party web service, then please contribute this new feature. Other platform users will then get notified about this new feature and can chose to use it as well. We expect this to be the best way for cfp.io to become <i>the place to be</i> for event organizers, covering all aspects of event management.<br />
<h3 style="text-align: justify;">
Emerging features</h3>
A side effect of co-hosting call for papers is to build sort of a <i>speaker social network</i> :<br />
<br />
<b>As a speaker</b>, I have to copy/paste my bio and favorite talk abstract on various events' call-for-papers. With cfp.io, I can just reuse my bio, and select a talk I already proposed at eventA so I can apply to eventB. I also can discover events I didn't heard about, just because their CFP is hosted by the platform.<br />
<b>As an event organizer</b>, I can check a speaker already talked at other events, and maybe this specific talk was recorded and available online. This will be a great assistance for program committee to select speakers.<br />
<h3 style="text-align: justify;">
Business model</h3>
Do we plan to create a company here ? No. we are a non-profit organization, and this is all just for fun ! We are just geeks, trying to make something cool and useful. Our "<i>business plan</i>" is for each hosted conference to get a free pass. Some of them will be use for our own pleasure to join great events, some of them might be sold to pay for the server, or to help us pay for travel.<br />
<br />
If you are event organizer, feel free to contact us to get your CFP setup on our infra - we plan to make this automated as well on a self-service basis, but this isn't implemented yet.</div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com3tag:blogger.com,1999:blog-21628438.post-69235569569114387322016-04-24T10:16:00.000+02:002016-04-24T10:33:15.216+02:00Docker Slaves Jenkins plugin has been released !<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
At Docker Hack Day 2015, Yoann an I created <a href="https://github.com/ndeloof/docker-slaves-plugin">Docker Slaves Plugin</a>, an alternative way to rely on Docker for Jenkins to get build nodes. This initial implementation was the summary of a summer hacking Jenkins APIs and internal design, it was very helpful for us to suggest required changes in jenkins-core and offer a more flexible approach.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
How does Docker-slaves differ from other Jenkins' Docker plugins ?</div>
<h4 style="text-align: justify;">
No prerequisite on Docker images</h4>
<div style="text-align: justify;">
Jenkins uses a Java agent on build machine to manage build operations from master remotely. As a side effect, plugins like docker, amazon-ecs or kubernetes -plugins do require the Docker image configured to host builds to have a JVM, expected permissions, and sometime even a ssh daemon running.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We think this is a non-sense. You should not have to bake Jenkins specific images. Especially, if you don't code in Java but use Jenkins for CI, growing your Docker images by 200Mb of JDK is terrible.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We already explored this goal with <a href="https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Custom+Build+Environment+Plugin">Docker Custom Build Environment Plugin</a> but this one also has some contraints : relying on bind mount, it require your Jenkins "classic" build node to have a local docker daemon installed. It also suffers some technical limitations :'(</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="color: #3d85c6;">Docker Slaves Plugin let you use any arbitrary image</span>.</div>
<div style="text-align: justify;">
<h4>
More than just one Docker image</h4>
</div>
<div style="text-align: justify;">
Docker, amazon-ecs and kubernetes -plugins all rely on running a single docker image for the build. They some way admit a common misunderstanding aobut containers, considering them as <i>ligthweight virtual machines</i>. As a result, you can find some docker images to include tons of build tools and also start a selenium environment, like <a href="https://hub.docker.com/r/cloudbees/java-build-tools/">cloudbees/java-build-tools</a>. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Why try to get all this shit in a single docker image ? Couldn't we combine a set of more specialized docker images into a group ("<i>pod</i>") of containers configured to work together ?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We used this exact approach. Every build will executre with at least 2 containers :</div>
<div style="text-align: justify;">
<ol>
<li>a plumbing '<i>jenkins-slave</i>' container to run required Jenkins slave agent</li>
<li><u>your</u> build container</li>
<li>some optional additional containers, for sample <a href="https://hub.docker.com/r/selenium/standalone-firefox/">selenium/standalone-firefox</a> to run browser-based tests, or a test database, or ... whatever resource your build require.</li>
</ol>
<div>
All those containers are set to share build workspace and network, so they can work all together without extra configuration.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://github.com/ndeloof/docker-slaves-plugin/raw/master/docs/docker.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="160" src="https://github.com/ndeloof/docker-slaves-plugin/raw/master/docs/docker.png" width="320" /></a></div>
<br /></div>
<div>
<br /></div>
<div>
<span style="color: #3d85c6;">Docker Slaves Plugin let you define build environment and resources as a set of containers.</span></div>
</div>
<h4 style="text-align: justify;">
Build specific Docker executor</h4>
<div style="text-align: justify;">
Jenkins use to maintain a pool of slaves, which can be automatically provisioned by a Cloud provider. When a job is executed, such a slave get the task assigned, creates a log for the build, and start executing. After completion, the slave goes back to available pool. Docker-plugin and few other do hack this lifecycle so the slave can't be reused, and enforce a fresh new provisioned node.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This has an odd effect : when the docker infrastructure has issue to run your container, and so the slave doesn't come online, Jenkins will try to run another slave. Again and again. You won't get notified about failure as your build didn't even started. So, wafter few hours when you connect to Jenkins, you'll see hundred disconnected slaves and your build pending...</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
We wanted to reverse the Slave :: Build relation. We also wanted the slave environment to be defined by the job, or maybe even by content of the job's repository at build time - typically, from a Dockerfile stored in SCM. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
When docker-slaves is used by a job, a slave is created to host the build but it's actual startup is delayed until the job has been assigned, and a build log created. We use this to pipe the container launch log in the build log, so you can immediately diagnose an issue with docker images or Dockerfile you used for the build.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="color: #3d85c6;">Docker Slaves Plugin creates a one-shot executor, as a main element of your build.</span></div>
<h4 style="text-align: justify;">
Jenkins Remoting</h4>
<div style="text-align: justify;">
Jenkins communicates with the slave agent using a specific "remoting" library, comparable to Java RMI. It relies on this one so the master can access remote filesystem and start commands on slave.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
But we use Docker, and docker client typically can be considered a way to run and control remote commands, relying on docker daemon as the remote agent. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker Slaves bypass Jenkins Remoting when master has to run a command on slave. It relies on plain <span style="font-family: "courier new" , "courier" , monospace;">docker run</span> for this purpose. We still need Remoting as it is also used for plugins to send Java code closures to be executed on slave. This is the reason we have a jenkins-slave container attached to all builds, which you can ignore, but is required for all Jenkins plugins to work without a single change. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="color: #3d85c6;">Docker Slaves Plugin reduce Jenkins Remoting usage</span>.</div>
<h4 style="text-align: justify;">
Pipeline Support</h4>
<div style="text-align: justify;">
Last but not least, Docker Slaves to fully embrace Jenkins Pipeline. Being main component for Jenkins 2.0, we could not just let Pipeline integration for further implementation effort.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker Slaves do introduce <span style="font-family: "courier new" , "courier" , monospace;">dockerNode</span> Pipeline DSL, as an alternative to <span style="font-family: "courier new" , "courier" , monospace;">node</span> used to assign a classic Jenkins slave. dockerNode takes as parameter the set of container images to be ran, then act as a node and you can use all your Jenkins Pipeline construct to script your CI/CD workflow.</div>
<div style="text-align: justify;">
<br /></div>
<pre class="brush:java">dockerNode(image: "maven:3.3.3-jdk-8", sideContainers: ["selenium/standalone-firefox"]) {
git "https://github.com/wakaleo/game-of-life"
sh 'mvn clean test'
}
</pre>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="color: #3d85c6;">Docker Slaves Plugin embrace Pipeline</span>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<h4 style="text-align: justify;">
What's next ?</h4>
</div>
<div style="text-align: justify;">
There's still some point we need to address, and probably some bugs as well, but Plugin is working fine already. If you give it a try, please send us feedback on your usage scenario.<br />
<br />
Something we want to address as well is <i><b>volumes</b></i> management. We re-attach the jenkins-slave container on later builds so we can retrieve a non-empty workspace. But we'd like to fully manage this as a volume and manage it's lifecycle. Especially, we'd like to experiment use of docker volume plugins to improve user experience. For sample, use of <a href="https://clusterhq.com/flocker/introduction/">Flocker</a> would allow us to snapshot workspace on build completion. This could be useful to offer post-build browsing of the workspace (for diagnostic on failure for sample) or to ensure a build starts from the last stable workspace state, which will offer pre-populated SCM checkout and dependencies, without the risk to get a corrupter environment from a build failure.<br />
<br />
We also would like to investigate adapting this approach on container orchestrator like Kubernetes. Not sure they offer the adequate flexibility, maybe only a subset of the plugin could be enabled on such an environment, but makes sense to give it a try.<br />
<br />
As a resume, still some long hacking nights in perspective :)<br />
<br />
In the meantime, please give it a try, and let us know if it would be helpful for your Jenkins usage.<br />
<br />
<br />
<br /></div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com2tag:blogger.com,1999:blog-21628438.post-76377775788761212772016-03-04T12:22:00.000+01:002016-03-04T12:22:15.746+01:00Google Summer of Code<div dir="ltr" style="text-align: left;" trbidi="on">
Ca faisait un bail, pas vrai ?<br />
<br />
J'écris ce billet pour faire savoir que je participe cette année au Google Summer of Code en tant que mentor.<br />
<br />
GSoC est un programme de Google qui consiste à mettre des étudiants entre les mains de mentors sur des projets open-source reconnus. Après un premier mois d'immersion, ils doivent bosser deux mois pendant l'été sur le projet, et leur contribution est évaluée par leur mentor et Google pour valider leur participation. Google rémunère alors les étudiants qui ont rempli leur contrat.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.honeynet.org/sites/default/files/banner-gsoc2016_2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://www.honeynet.org/sites/default/files/banner-gsoc2016_2.png" /></a></div>
<br />
<br />
Ce n'est donc pas un stage, encore moins avec une belle convention de stage comme on les aime en France. Par contre c'est passionnant et une excellente carte de visite. Donc ça peut être difficile à faire passer auprès de votre direction des études, mais ça vaut le coup de tenter de les dépoussiérer un peu !<br />
<br />
Je propose un sujet dans le cadre de Jenkins : "<b>Jenkins et Docker sont dans un bateau ...</b>"<br />
<br />
L'idée est de tordre un peu Jenkins pour remplacer son mode synchrone, basé sur un mécanisme semblable à RMI, pour contrôler des process sur une machine de build distante.<br />
<br />
A la place, nous voulons utiliser le support natif de Docker pour contrôler des process distant et de manière asynchrone - et sans se prendre un CVE sur la sérialization Java (sic).<br />
<br />
Et bien sur, le tout de manière backward compatible (ben oui, c'est Jenkins) ce qui promet quelques heures de réflexion intense.<br />
<br />
<br />
<br />
Bref, si vous êtes intéressé, commencez déjà par aller voir <a href="https://summerofcode.withgoogle.com/">https://summerofcode.withgoogle.com/</a> pour comprendre le process du GSoC, ensuite on en discute sur la mailing list jenkins-dev !</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com0tag:blogger.com,1999:blog-21628438.post-57493092283198898272016-01-26T18:17:00.001+01:002016-01-26T18:17:42.046+01:00Quoi d'neuf sur Quoi d'neuf Docker ?<div dir="ltr" style="text-align: left;" trbidi="on">
Salut à tous,<br />
<br />
dans mon dernier post - sur ce blog qui n'est plus très actif, je dois l'admettre ... - je vous parlais de la <a href="https://www.youtube.com/c/Quoideneufdocker">chaîne Youtube</a> que j'ai montée pour partager mon enthousiasme sur Docker.<br />
<br />
Depuis ce dernier billet, d'une part le crowdfunding Ulule s'est terminé avec succès (107%!), et j'ai comme convenu commencé à mettre en oeuvre les contreparties, dont la merveilleuse <i>chanson du merci</i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/LzYFVoxnyAI/0.jpg" src="https://www.youtube.com/embed/LzYFVoxnyAI?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
J'ai aussi publiée trois épisodes, avec des niveaux successifs - du plutôt accessible "<a href="https://www.youtube.com/watch?v=zO4-1D9LdDw">Docker 101</a>" au significativement plus touffu "<a href="https://www.youtube.com/watch?v=yHbGOdGROMs">Le grand plongeon</a>". Certains m'ont fait remarquer cette différence importante de niveau. Je compte mixer des vidéos plutôt techniques (pas trop rassurez vous, car ça me demande pas mal de préparation) avec des sujets plus légers.<br />
<br />
En parlant de légèreté, une <i><a href="https://github.com/docker/docker/issues/19396">issue</a></i> un chouille provocatrice que j'ai créée à provoqué un déferlement de créativité de la part des Francophiles et tout poils, et j'ai voulu leur rendre hommage avec une nouvelle vidéo - pas du tout technique celle-là : <a href="https://www.youtube.com/watch?v=1ZgDo1Lx7yQ">ET Si ... Docker était resté Français</a>.<br />
<br />
Vous l'aurez compris, cette chaîne est un soigneux mélange de genres, et est surtout pour moi l'occasion, comme je l'avais annoncé sur le projet Ulule, de mettre en pratique des idées et des technique de tournage/montage vidéo. Je m'essaye à copier tant bien que mal le style de plusieurs Youtubeur que j'affectionne, pas forcément toujours avec le résultat escompté mais qui ne tente rien...<br />
<br />
Bref, <a href="https://www.youtube.com/c/Quoideneufdocker">Quoi d'neuf Docker</a> est lancé, et bien lancé (j'ai une TODO-list assez conséquente) et j'ai beaucoup d'idées de mise en scène à expérimenter :D Votre aide sur le crowdfunding m'a ouvert de nouvelles portes avec un magnifique Canon 70D et un objectif très lumineux, de quoi occuper quelques heures d'apprentissage.<br />
<br />
Par ailleurs, la chaîne compte déjà plus de 700 abonnés - oui, 700, même sur un sujet aussi ciblé - et je commence à rêver du Youtube Space Paris, réservé aux chaînes ayant plus de ... 1000 abonnés.<br />
<br />
Je n'ai donc pas à vous dire ce qu'il vous reste à faire...<br />
<br />
Et comme certains d'entre vous n'ont pas vu le Ulule à temps et veulent tout de même contribuer à la chaîne (sic), j'ai mis en place un <a href="https://www.tipeee.com/quoi-d-neuf-docker">Tipee</a>, en gros un crowdfunding sans limite de temps. Je n'attend pas particulièrement à ce que cela m'apporte grand chose, mais qui sait, cela pourra participer à financer du matériel plus spécifique, et/ou des frais de déplacement - <i>DockerCon Seattle, je pense à toi</i><br />
<i><br /></i>
Merci à tous pour votre soutien, vos encouragements, et rendez-vous très très bientôt (enfin, si le tournage de ce soir se passe bien ...)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG-rsugwBfRndOGzRCqYAa4fs8_CzWq-WpAo8hcPWqI_iYCTj_EDKQ8RROvWzzTopwgDrmIZsjUZtZEc1lgIc4kAqAFnNh-4mBv4dpHWWtjWOuaFVvYn-MruMpUzlurEAWidKA/s1600/99b1bce4-6106-11e1-b7ad-a711bc3d9b8e-493x328.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG-rsugwBfRndOGzRCqYAa4fs8_CzWq-WpAo8hcPWqI_iYCTj_EDKQ8RROvWzzTopwgDrmIZsjUZtZEc1lgIc4kAqAFnNh-4mBv4dpHWWtjWOuaFVvYn-MruMpUzlurEAWidKA/s320/99b1bce4-6106-11e1-b7ad-a711bc3d9b8e-493x328.jpg" width="320" /></a></div>
<br />
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com0tag:blogger.com,1999:blog-21628438.post-53001666688812367992015-12-12T11:05:00.002+01:002015-12-14T11:54:38.167+01:00Un chaîne Youtube consacrée à Docker<div dir="ltr" style="text-align: left;" trbidi="on">
Comme le prouvent les vidéos que nous publions chaque année pour faire la promotion du <a href="http://www.breizhcamp.org/">BreizhCamp</a>, je prend un grand plaisir à manipuler la vidéo comme média de communication.<br />
<br />
Je suis impressionné par le succès des chaînes Youtube des pointures du Net Français : JoueurDuGrenier, e-Penser, Axolot, Salut les Geeks ou Antoine Daniel apportent tous à leur manière une expression libre sur le web avec un talent certain.<br />
<br />
Je n'ai pas la prétention de me comparer à ces références, mais le format employé m'attire sans conteste. Aussi, je lance une chaîne Youtube, sur un sujet de niche : Docker ...<br />
<br />
"de niche" parce que pas du tout grand public. Oublions donc tout de suite les millions de vues, promesse de toucher un chèque signé "<i>Youtube</i>". L'idée est ici de présenter Docker et son écosystème, comme je le fais en conférence, mais en exploitant le média vidéo, c'est à dire pas sous forme de conférence filmée, linéaire, mais en exploitant les possibilités données par le montage et la mise en scène.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-Pul5WZbSQYTq5CvSYIbVzRgAlaOEVKXnuLat-7No_TUPY0sce0cXw9aUrUBU4pCxkd08Cxt5JivHo7YwxakoQeUScCg6H9C-28Dvs4AAkD3wldyCchGrq-Md4wlq8YTwfPdt/s1600/Capture+d%25E2%2580%2599e%25CC%2581cran+2015-12-11+a%25CC%2580+17.43.55.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="420" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-Pul5WZbSQYTq5CvSYIbVzRgAlaOEVKXnuLat-7No_TUPY0sce0cXw9aUrUBU4pCxkd08Cxt5JivHo7YwxakoQeUScCg6H9C-28Dvs4AAkD3wldyCchGrq-Md4wlq8YTwfPdt/s640/Capture+d%25E2%2580%2599e%25CC%2581cran+2015-12-11+a%25CC%2580+17.43.55.png" width="640" /></a></div>
<br />
<br />
La chaîne est encore naissante et a donc pour le moment une <a href="https://www.youtube.com/channel/UCOAhkxpryr_BKybt9wIw-NQ">URL à chier</a>, il faudra attendre 500 abonnés pour régler ça, mais pour ça il faut déjà proposer du contenu.<br />
<br />
Ce contenu est déjà en préparation, mais je veux profiter de cette occasion pour aller plus loin que ce que j'ai produit jusqu'ici, en particulier en raison des limitations de la caméra que j'ai à ma disposition via le BreizhCamp. J'aimerais passer au tournage sur boitier Reflex, profiter de l'expérience en photo de plusieurs collègues pour choisir les bons objectifs et trouver des astuces de cadrage, etc.<br />
<br />
Bref, il va falloir investir, et pour cela je fais appel aux bonnes volontés, via un financement participatif sur Ulule : <a href="http://fr.ulule.com/neuf-docker/">http://fr.ulule.com/neuf-docker/</a><br />
<br />
Je prépare un premier épisode pilote en tant que "<i>proof of concept</i>" et pour montrer ce que j'ai en tête, en espérant que cela déliera les portefeuilles. J'ai placé le premier niveau de contribution à 5€ en espérant que cela motivera ceux qui ne sont pas des connaissances directes, comme on dit "<i>les petits ruisseaux font les grandes rizières</i>"<br />
<br />
Bref, à vot' bon coeur.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://twitter.com/quoidneufdocker"><img border="0" height="56" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMyBTovxWwN4eOSwLOHMI8_XLUad6Di-kbVcoLyvgXU3dIbdF_wzOl8P5kC-RtxorlRWYBkmCJxwly2WtmvWVMRgtypwD_PiBBmYi0u3vHuFBWphzMF8Ql1OqOZHOpaxXrifbj/s320/twitter.png" width="320" /></a></div>
<br />
<b>UPDATE</b><br />
Je viens de publier un épisode pilote, pas vraiment technique, mais qui donne une idée de ce que j'ai en tête. j'espère qu'il vous amusera.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/L2nBaOj4qRg/0.jpg" src="https://www.youtube.com/embed/L2nBaOj4qRg?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<br /></div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com1tag:blogger.com,1999:blog-21628438.post-14705750422556515382015-12-04T15:19:00.001+01:002015-12-04T15:19:41.570+01:00Docker Garbage Collector<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
When you play a bit with Docker, you end up after some time with a very classic <i><span style="font-family: "courier new" , "courier" , monospace;">filesystem full</span></i> issue.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The first time you hit this issue, you learn the <span style="font-family: "courier new" , "courier" , monospace;">docker rm</span> command and start using <span style="font-family: "courier new" , "courier" , monospace;">--rm</span> option to launch containers. The issue here is container aren't destroyed when stopped/killed. Most of us do even have some cleanup alias/script to run something like</div>
<br />
<div class="p1">
<pre class="brush:bash">docker rm $(docker ps --filter status=exited -q)</pre>
</div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div style="text-align: justify;">
You also can hit such an abusive disk usage issue as you get lot's of obsolete image stored on your disk after you tested various things pulled from DockerHub. Same cause usually has the same effect, so you add to your script some :</div>
<br />
<div class="p1">
<pre class="brush:bash">docker rmi $(docker images | grep “^<none>” | awk ‘{print $3}’)</none></pre>
</div>
<br />
<br />
<span style="font-size: xx-small;">(based on <a href="https://gist.github.com/ngpestelos/4fc2e31e19f86b9cf10b">https://gist.github.com/ngpestelos/4fc2e31e19f86b9cf10b</a>)</span><br />
<br />
<div style="text-align: justify;">
So, what's next ?</div>
<div style="text-align: justify;">
First issue with such a script is you have to run it by yourself when something goes wrong.</div>
<div style="text-align: justify;">
Second issue is such a script do remove untagged images, but not tagged ones you won't use anymore. Some other script could remove all unused images, but will then in many cases force you to re-pull few images you use on a daily basis, but weren't running at the time you ran the cleanup.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
To avoid such an issue, I've created a small tool : <a href="http://github.com/ndeloof/docker-gc">docker-gc</a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This tool do listen docker daemon for <span style="font-family: "courier new" , "courier" , monospace;">destroy</span> events, so it knows when a container is removed, and can capture the image it used. This information is used, when the gc process list the unused images, to determine which one where used recently and should be kept - as I assume you will reuse the same image on a regular basis - and which one weren't used for a long time and should be removed.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
I'm sure there's many ways to improve the actual GC algorithm efficiency.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
For convenience, tool is distributed as a docker image (what else ?) as <a href="https://hub.docker.com/r/ndeloof/docker-gc">ndeloof/docker-gc</a>, just need to bind mount docker unix socket so it can interact with DockerHost daemon.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
</div>
<div class="p1">
<pre class="brush:bash">docker run -d -v /var/run/docker.sock:/var/run/docker.sock ndeloof/docker-gc</pre>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br />
As a cool project needs a cool logo, I created one using a Jellyfish as a mascot to cleanup docker's ocean. </div>
<div style="text-align: justify;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://github.com/ndeloof/docker-gc/raw/master/docker-GC.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://github.com/ndeloof/docker-gc/raw/master/docker-GC.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: justify;">
Please note <a href="https://www.docker.com/brand-guidelines">docker legal terms</a> totally prohibit such a logo usage, so don't do such crazy logo hijack if you don't want Solomon's advocates to knock at your door. I'll welcome <a href="https://twitter.com/bloglaurel">Laurel</a>'s pull-request to suggest another one :P</div>
</div>
Nicolas De Loofhttp://www.blogger.com/profile/01689687514370945173noreply@blogger.com0