index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Docker Saigon</title>
    <link>http://docker-saigon.github.io/</link>
    <description>Recent content on Docker Saigon</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>Code released under the Apache 2.0 license.</copyright>
    <lastBuildDate>Wed, 28 Oct 2015 14:31:10 +0700</lastBuildDate>
    <atom:link href="http://docker-saigon.github.io/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title>about</title>
      <link>http://docker-saigon.github.io/about/</link>
      <pubDate>Wed, 28 Oct 2015 14:31:10 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/about/</guid>
      <description>

&lt;p&gt;Docker Saigon is the community of Docker users in Ho Chi Minh City, Vietnam.&lt;/p&gt;

&lt;h2 id=&#34;where-can-you-find-us:6083a88ee3411b0d17ce02d738f69d47&#34;&gt;Where can you find us?&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;http://meetup.com/docker-saigon&#34;&gt;Meetup&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://speakerdeck.com/dockersaigon&#34;&gt;SpeakerDeck&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://github.com/docker-saigon&#34;&gt;GitHub&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.youtube.com/channel/UC1t_GbTJudAAK9Wqkg6-uLw&#34;&gt;Youtube&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://www.facebook.com/DockerSaigon&#34;&gt;Facebook&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://twitter.com/docker_saigon&#34;&gt;Twitter&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://dockersaigon.herokuapp.com&#34;&gt;Slack (auto-invite app)&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://dockersaigon.reddit.com&#34;&gt;Reddit&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;docker:6083a88ee3411b0d17ce02d738f69d47&#34;&gt;Docker?&lt;/h2&gt;

&lt;p&gt;&lt;a href=&#34;http://docker.com&#34;&gt;Docker&lt;/a&gt; is an open-source project to easily create lightweight, portable, self-sufficient containers from any application. The same container that a developer builds and tests on a laptop can run at scale, in production, on VMs, bare metal, OpenStack clusters, public clouds and more.&lt;/p&gt;

&lt;p&gt;See our Docker Fundamentals live streaming at Lazada&amp;hellip; (link to video pending)&lt;/p&gt;

&lt;p&gt;Thanks for reading!&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>contact</title>
      <link>http://docker-saigon.github.io/contact/</link>
      <pubDate>Wed, 28 Oct 2015 22:17:33 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/contact/</guid>
      <description>&lt;p&gt;Want to get in touch with us? Fill out the form below to send us a message and we will try to get back to you as soon as possible!&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Docker For Windows Beta</title>
      <link>http://docker-saigon.github.io/post/Docker-Beta/</link>
      <pubDate>Mon, 18 Apr 2016 00:34:41 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/post/Docker-Beta/</guid>
      <description>

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: The research for this post was done on a Beta client and technical details are subject to change.&lt;/p&gt;

&lt;p&gt;As indicated in previous posts, we&amp;rsquo;ve been using Docker on Windows with Hyper-V for a while. Hearing that the new Docker client for Windows would be Alpine-based and focused on Hyper-V made us eager to see for ourselves.&lt;/p&gt;

&lt;h2 id=&#34;hyper-v-configuration:ebf9573d6838c40027746e9d7482622a&#34;&gt;Hyper-V configuration&lt;/h2&gt;

&lt;p&gt;The first issue to overcome when using Hyper-V on Windows is the lack of DNS/DHCP &amp;amp; NAT services. The new Docker client handles the Virtual Switch NAT configuration for us and adds a clever solution for DNS &amp;amp; DHCP.&lt;/p&gt;

&lt;p&gt;As part of the installation process a &lt;code&gt;DockerNAT&lt;/code&gt; Internal Virtual Switch is created and the Virtual Interface on the Windows host for this switch gets a static IP:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;New-VMSwitch -Name &amp;quot;DockerNAT&amp;quot; -SwitchType Internal
Get-NetAdapter &amp;quot;vEthernet (DockerNAT)&amp;quot; | New-NetIPAddress -AddressFamily IPv4 `
      -IPAddress &amp;quot;10.0.75.1&amp;quot; -PrefixLength 24
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;A NAT object is created to handle Network Address Translation for the &amp;ldquo;10.0.75.0/24&amp;rdquo; subnet:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;New-NetNat –Name $SwitchName `
	–InternalIPInterfaceAddressPrefix &amp;quot;10.0.75.0/24&amp;quot;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Tip&lt;/strong&gt;: If any of these steps failed, ensure a Switch with the name &amp;ldquo;DockerNAT&amp;rdquo; was created, the IP was assigned to the Virtual Interface and that &lt;code&gt;Get-NetNat&lt;/code&gt; lists a NAT with the correct subnet. Also ensure these hard-coded subnets do not overlap with already existing interfaces (We had to manually fix these things while testing the beta).&lt;/p&gt;

&lt;p&gt;Next, the &lt;code&gt;MobyLinuxVM&lt;/code&gt; Virtual Machine is created in Hyper-V. MobyLinuxVM uses an Alpine bootcd which has Hyper-V Integration Services, such as the &lt;code&gt;Key-Value Pair Exchange&lt;/code&gt; service (hv_kvp_daemon). The Hyper-V KVP Daemon allows communication between the Hyper-V Host and the Linux Guest (i.e to retrieve the Guest IP and send two-way messages as we&amp;rsquo;ll see later).&lt;/p&gt;

&lt;p&gt;Finally, Docker bundles a &lt;code&gt;com.docker.proxy.exe&lt;/code&gt; binary which proxies the ports from the MobyLinuxVM on your windows host. At the time of writing (Docker Beta 7), this includes the DNS (port 53 TPC/UDP), DHCP (port 67 UDP) and Docker daemon (port 2375 TCP).&lt;/p&gt;

&lt;p&gt;If you&amp;rsquo;ve been running alternative solutions for your Hyper-V set-up, you need to ensure the above ports are available as follows..&lt;/p&gt;

&lt;p&gt;See if any process is using port 53:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;netstat -aon | findstr :53 
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Once you have the process id (&lt;code&gt;&amp;lt;pid&amp;gt;&lt;/code&gt;) of the process holding the port, get the name:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;tasklist /SVC | findstr &amp;lt;pid&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The &lt;code&gt;com.docker.proxy.exe&lt;/code&gt; will proxy all DNS requests from the internal network of your Windows laptop to the DNS server used by your Windows host, effectively isolating the MobyLinuxVM from the network configuration changes as you move your laptop around.&lt;/p&gt;

&lt;p&gt;To ensure this process can work properly, docker automatically creates &lt;code&gt;DockerTcp&lt;/code&gt; &amp;amp; &lt;code&gt;DockerUdp&lt;/code&gt; firewall rules and removes them when you close the client.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;New-NetFirewallRule -Name &amp;quot;DockerTcp&amp;quot; -DisplayName &amp;quot;DockerTcp&amp;quot;  `
   -Program &amp;quot;C:\&amp;lt;path&amp;gt;\&amp;lt;to&amp;gt;\com.docker.proxy.exe&amp;quot; -Protocol TCP `
   -Profile Any -EdgeTraversalPolicy DeferToUser -Enabled True

New-NetFirewallRule -Name &amp;quot;DockerUdp&amp;quot; -DisplayName &amp;quot;DockerUdp&amp;quot;  `
   -Program &amp;quot;C:\&amp;lt;path&amp;gt;\&amp;lt;to&amp;gt;\com.docker.proxy.exe&amp;quot; -Protocol UDP `
   -Profile Any -EdgeTraversalPolicy DeferToUser -Enabled True
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Having the Docker daemon port opened locally, allows your docker client to talk to localhost, however - it seems that going forward a named pipe solution will be used instead, if the VM was created successfully you should see the named pipe connected to its COM port:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;Get-VMComPort -VMName MobyLinuxVM | fl | Out-String
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;See also the docker client code for handling &lt;a href=&#34;https://github.com/docker/docker/blob/v1.11.0/vendor/src/github.com/docker/go-connections/sockets/sockets_windows.go&#34;&gt;Windows Named Pipes&lt;/a&gt; going forward.&lt;/p&gt;

&lt;p&gt;If the MobyLinuxVM booted successfully, we may confirm the Hyper-V integration Services are running:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;Get-VMIntegrationService -VMName MobyLinuxVM -Name &amp;quot;Key-Value Pair Exchange&amp;quot;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;And that the &lt;code&gt;com.docker.proxy.exe&lt;/code&gt; DHCP service provided an IP to the VM - which we can query thanks to the Hyper-V Integration Services:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;$(Get-VM MobyLinuxVM).NetworkAdapters[0]
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;troubleshooting:ebf9573d6838c40027746e9d7482622a&#34;&gt;Troubleshooting&lt;/h2&gt;

&lt;p&gt;All settings are stored under &lt;code&gt;%APPDATA%\Docker\&lt;/code&gt; folder, this folder is replicated across machines in an Enterprise setting where Roaming is enabled.&lt;/p&gt;

&lt;p&gt;All logs are stored under &lt;code&gt;%LOCALAPPDATA%\Docker\&lt;/code&gt; folder.&lt;/p&gt;

&lt;p&gt;To monitor the latest logs use the following PowerShell command:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;gc $(gi $env:LocalAppData\Docker\* | sort LastAccessTime -Desc | select -First 1) -Wait
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;This will auto-refresh for every event written to the log.&lt;/p&gt;

&lt;h2 id=&#34;docker-toolbox-migration:ebf9573d6838c40027746e9d7482622a&#34;&gt;Docker ToolBox Migration&lt;/h2&gt;

&lt;p&gt;Switching on the Hyper-V role on Windows will disable VirtualBox (and you won&amp;rsquo;t be able to use the Docker ToolBox until you switch Hyper-V off &amp;amp; reboot). If a Docker Toolbox installation is detected, a migration path is offered (using &lt;code&gt;qemu-img&lt;/code&gt;). This will convert the &lt;code&gt;%USERPROFILE%\.docker\machine\machines\&amp;lt;machine-name&amp;gt;\disk.vmdk&lt;/code&gt; to vhdx:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;qemu-img.exe convert &amp;lt;path-to-vmdk&amp;gt; -O vhdx -o subformat=dynamic -p &amp;quot;C:\Users\Public\Documents\Hyper-V\Virtual hard disks\MobyLinuxVM.vhdx\&amp;quot;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;If you were already using Docker-Machine &amp;amp; Docker-Compose with Hyper-V, you can continue to do so side-by-side with the Docker for Windows client.&lt;/p&gt;

&lt;h2 id=&#34;mounting-volumes:ebf9573d6838c40027746e9d7482622a&#34;&gt;Mounting Volumes&lt;/h2&gt;

&lt;p&gt;One of the big improvements the new Docker for Windows promises is how Volume mounts will be handled.&lt;/p&gt;

&lt;p&gt;A handy dialog is provided to streamline everything for us.&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/beta7-shares.png&#34; alt=&#34;shares dialog&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;The current implementation will share the whole drive (and not individual folders). Enabling a Drive share will prompt for credentials.&lt;/p&gt;

&lt;p&gt;Credentials are stored with the &lt;code&gt;target&lt;/code&gt; &amp;ldquo;Docker Host Filesystem Access&amp;rdquo; under the Windows &amp;gt; Control Panel &amp;gt; Credential Manager &amp;gt; Windows Credentials Store by the configuration tool. This uses &lt;code&gt;System.Security.Cryptography&lt;/code&gt; to encrypt the credentials with currentuser scope.&lt;/p&gt;

&lt;p&gt;If the credential manager already contains credentials for the specified target, they will be overwritten.&lt;/p&gt;

&lt;p&gt;Next, the drive is shared on the Windows Host:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;net share C=C:\ /grant:&amp;lt;username&amp;gt;,FULL /CACHE:None
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;This Samba share now needs to be mounted into the MobyLinuxVM and this is automated through the Hyper-V &lt;a href=&#34;https://technet.microsoft.com/en-us/library/dn798287.aspx&#34;&gt;Key-Value Pair Exchange&lt;/a&gt; Integration Service. A detailed explanation is available &lt;a href=&#34;http://dlafferty.blogspot.com.ee/2013/09/hyper-v-kvp-data-exchange-for-cloudstack.html&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;The way this is supposed to work is as follows: our Windows host puts a &lt;code&gt;mount authentication token&lt;/code&gt; packaged in a &lt;code&gt;KvpExchangeDataItem&lt;/code&gt; on the VMBus:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;class Msvm_KvpExchangeDataItem : CIM_ManagedElement
{
  uint16 Source = 0;
  string Name = &amp;quot;cifsmount&amp;quot;;
  string Data = &amp;quot;authToken&amp;quot;;
};
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The Authentication token is a serialized string containing the mount points and mount options:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;/c;/C;username=&amp;lt;username&amp;gt;,password=&amp;lt;password&amp;gt;,noperm
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;On the Alpine guest the &lt;code&gt;hv_utils&lt;/code&gt; kernel driver module notifies the &lt;code&gt;hv_kvp_daemon&lt;/code&gt;. This daemon writes the kvp to the pool file (&lt;code&gt;/var/lib/hyperv/.kv_pool_*&lt;/code&gt;).&lt;/p&gt;

&lt;p&gt;At this stage a process on MobyLinuxVM needs to make the directory and mount the share from the host - but this was failing at the time of writing:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; #for both upper and lower case
mount -t cifs //10.0.75.1/C /C -o username=&amp;lt;username&amp;gt;,password=&amp;lt;password&amp;gt;,noperm
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;If the share worked fine, our docker client would be sending any volume mount commands through the socket opened by the &lt;code&gt;com.docker.proxy.exe&lt;/code&gt;, this proxy re-writes the path if needed: &lt;code&gt;C:\Users\test\&lt;/code&gt; becomes &lt;code&gt;/C/Users/test&lt;/code&gt;, allowing us to mount Windows folders into our Docker containers.&lt;/p&gt;

&lt;p&gt;However, there are still limitations due to the SMB protocol (lack of support for inotify and symlinks), which will cause problems with live reloads.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Troubleshooting&lt;/strong&gt;: We can verify that the auth token exists on the VMBus with the following PowerShell script:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;$VmMgmt = Get-WmiObject -Namespace root\virtualization\v2 -Class ` 
    Msvm_VirtualSystemManagementService
$vm = Get-WmiObject -Namespace root\virtualization\v2 -Class ` 
    Msvm_ComputerSystem -Filter {ElementName=&#39;MobyLinuxVM&#39;}

($vm.GetRelated(&amp;quot;Msvm_KvpExchangeComponent&amp;quot;)[0] ` 
    ).GetRelated(&amp;quot;Msvm_KvpExchangeComponentSettingData&amp;quot;).HostExchangeItems | % { ` 
        $GuestExchangeItemXml = ([XML]$_).SelectSingleNode(` 
            &amp;quot;/INSTANCE/PROPERTY[@NAME=&#39;Name&#39;]/VALUE[child::text() = &#39;cifsmount&#39;]&amp;quot;) 

        if ($GuestExchangeItemXml -ne $null) 
        { 
           $GuestExchangeItemXml.SelectSingleNode(` 
            &amp;quot;/INSTANCE/PROPERTY[@NAME=&#39;Data&#39;]/VALUE/child::text()&amp;quot;).Value 
        }    
    } 

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;So far, I have not been able to find which process is monitoring the &lt;code&gt;/var/lib/hyperv/.kv_pool_0&lt;/code&gt; files on the Alpine guest.&lt;/p&gt;

&lt;h2 id=&#34;private-registries:ebf9573d6838c40027746e9d7482622a&#34;&gt;Private Registries&lt;/h2&gt;

&lt;p&gt;At the moment, the beta for Windows does not support &lt;code&gt;DOCKER_OPTS&lt;/code&gt; or TLS certs &lt;strong&gt;yet&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;We can get root access to the MobyLinuxVM as follows:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; #get a privileged container with access to Docker daemon
docker run --privileged -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /usr/bin/docker:/usr/bin/docker alpine sh

 #run a container with full root access to MobyLinuxVM and no seccomp profile (so you can mount stuff)
docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh

 #switch to host FS
chroot /host
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Poking around in the VM reveals the following:&lt;/p&gt;

&lt;p&gt;The VM (Alpine-based) uses &lt;a href=&#34;http://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System&#34;&gt;OpenRC as its init system&lt;/a&gt;.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;rc-status
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Shows the status of all services, but some of the init scripts do not implement status and show up as &amp;ldquo;crashed&amp;rdquo; while it seems their process is still running (&lt;code&gt;ps -a&lt;/code&gt;).&lt;/p&gt;

&lt;p&gt;The Docker init script relies on a &lt;code&gt;/usr/bin/mobyconfig&lt;/code&gt; script. This &lt;code&gt;mobyconfig&lt;/code&gt; script requires the kernel to boot with a &lt;code&gt;com.docker.database&lt;/code&gt; label specifying the location of the config file or it bails. If the label is present - &lt;code&gt;/Database&lt;/code&gt; is mounted using the &lt;a href=&#34;https://en.wikipedia.org/wiki/9P_%28protocol%29&#34;&gt;Plan 9 Filesystem Protocol&lt;/a&gt;, which was the original filesystem for Docker for Mac.&lt;/p&gt;

&lt;p&gt;The &lt;code&gt;mobyconfig&lt;/code&gt; script is able to retrieve network and &lt;code&gt;insecure-registry&lt;/code&gt; configuration for the Docker deamon or pick up a config file from &lt;code&gt;/etc/docker/daemon.json&lt;/code&gt;. This looks like a very promising solution, once it is fully implemented.&lt;/p&gt;

&lt;p&gt;As the whole disk is a Temporary filesystem with only the &lt;code&gt;/var/&lt;/code&gt; mountpoint (to &lt;code&gt;/dev/sda2&lt;/code&gt;) persisted, changes made to any of the scripts are not persisted across reboots. It is possible to temporarily change the Docker options and &lt;code&gt;/etc/init.d/docker restart&lt;/code&gt; the daemon.&lt;/p&gt;

&lt;h2 id=&#34;conclusion:ebf9573d6838c40027746e9d7482622a&#34;&gt;Conclusion&lt;/h2&gt;

&lt;p&gt;Many improvements are coming with the Docker client for Windows, we are looking forward at testing the Docker client for Mac next.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Docker Caveats</title>
      <link>http://docker-saigon.github.io/post/Docker-Caveats/</link>
      <pubDate>Mon, 11 Apr 2016 20:17:12 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/post/Docker-Caveats/</guid>
      <description>

&lt;p&gt;We can&amp;rsquo;t deny Linux Containers are a very powerful concept combining clever Linux kernel features and Docker&amp;rsquo;s open source tools make containers easily accessible to developers of any background.&lt;/p&gt;

&lt;p&gt;At container summit 2016, &lt;a href=&#34;https://twitter.com/bcantrill&#34;&gt;Bryan Cantrill&lt;/a&gt; eloquently compared the industry disruption this causes, and the issues mass industry adoption entails, to the issues which may show up after &lt;a href=&#34;http://containersummit.io/events/nyc-2016/videos/the-evolving-container-ecosystem&#34;&gt;you&amp;rsquo;ve taught peasants to read&lt;/a&gt; &lt;em&gt;(about 28 minutes into the linked video of the panel discussion).&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Issues such as: improper usage of the technology and unpleasant surprises due to a poor understanding of the underlying features enabling the technology.&lt;/p&gt;

&lt;p&gt;Yesterday, a brilliant Downfall parody made by &lt;a href=&#34;https://twitter.com/nukemberg&#34;&gt;Avishai Ish-Shalom&lt;/a&gt; highlights some of the surprises &amp;amp; frustrations which may cause shock to those that are unprepared:&lt;/p&gt;

&lt;blockquote class=&#34;twitter-tweet&#34;&gt;&lt;p lang=&#34;en&#34; dir=&#34;ltr&#34;&gt;This is hilarious! Hitler uses Docker &lt;a href=&#34;https://t.co/cmXB2Clj8D&#34;&gt;https://t.co/cmXB2Clj8D&lt;/a&gt; &lt;br&gt;&lt;br&gt;via &lt;a href=&#34;https://twitter.com/nukemberg&#34;&gt;@nukemberg&lt;/a&gt; ht &lt;a href=&#34;https://twitter.com/m1keil&#34;&gt;@m1keil&lt;/a&gt;  &lt;a href=&#34;https://twitter.com/hashtag/linux?src=hash&#34;&gt;#linux&lt;/a&gt; &lt;a href=&#34;https://twitter.com/hashtag/cloudcomputing?src=hash&#34;&gt;#cloudcomputing&lt;/a&gt; &lt;a href=&#34;https://twitter.com/hashtag/devops?src=hash&#34;&gt;#devops&lt;/a&gt; &lt;a href=&#34;https://twitter.com/hashtag/sysadmin?src=hash&#34;&gt;#sysadmin&lt;/a&gt;&lt;/p&gt;&amp;mdash; nixCraft (@nixcraft) &lt;a href=&#34;https://twitter.com/nixcraft/status/719146833558183936&#34;&gt;April 10, 2016&lt;/a&gt;&lt;/blockquote&gt;
&lt;script async src=&#34;//platform.twitter.com/widgets.js&#34; charset=&#34;utf-8&#34;&gt;&lt;/script&gt;

&lt;p&gt;In this blog post, we&amp;rsquo;d like to take a look at each of these statements and deconstruct them for a better understanding of what makes this short so clever, while at the same time - it serves as a great caveat for anyone hoping to get the best out of running Docker in production.&lt;/p&gt;

&lt;h2 id=&#34;isolation:4c461b6a7a614440939d8002a0e574c8&#34;&gt;Isolation&lt;/h2&gt;

&lt;p&gt;The video starts with what looks like a very popular CI/CD setup using Docker&amp;rsquo;s public image registry, the Docker Hub and its multi-container management tool, Docker-Compose. Although it should be noted that Docker-Compose is still primarily aimed at Development and Testing environments and is probably not suited for larger production deployments, as clearly outlined in the &lt;a href=&#34;https://docs.docker.com/compose/production/&#34;&gt;Docker docs&lt;/a&gt; at the time of this blog post.&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat01.png&#34; alt=&#34;Untrusted Images&#34; /&gt;
    
    
&lt;/figure&gt;



&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat02.png&#34; alt=&#34;Kernel Panic in a Shared Kernel&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;&lt;strong&gt;This highlights a first issue of sharing the kernel: reduced reliability and redundancy.&lt;/strong&gt;&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat03.png&#34; alt=&#34;Isolation my ass!&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;We believe, the take-away here should be:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Containers should not be used without ensuring that reliability and redundancy of every resource is incorporated into the overall design of your infrastructure.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;You may gain back reliability by using shared storage, service orchestration, monitoring and a framework with built-in self-healing features such as &lt;a href=&#34;http://container-solutions.com/rescheduling-containers-on-node-failures-with-docker-swarm-1-1/&#34;&gt;the container rescheduling on node failure&amp;rdquo;  features added to Swarm&lt;/a&gt;; Or the ingrained concept of &amp;ldquo;The Reconciliation Loop&amp;rdquo; in &lt;a href=&#34;http://kubernetes.io/docs/user-guide/replicasets/&#34;&gt;Kubernetes ReplicaSets&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Although a snarky comment on the above is also included in the video:&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat09.png&#34; alt=&#34;Keep it Simple, Stupid&#34; /&gt;
    
    
    &lt;figcaption&gt;
        &lt;p&gt;
        
        &lt;a href=&#34;https://twitter.com/hashtag/GIFEE&#34;&gt; 
            #GIFEE
        &lt;/a&gt; 
        &lt;/p&gt; 
    &lt;/figcaption&gt;
    
&lt;/figure&gt;


&lt;p&gt;Later on, another concern related to the implementation of isolation provided by container runtimes is also highlighted:&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat08.png&#34; alt=&#34;Resource Isolation in a Shared Kernel&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;Disillusionment comes from treating Docker like magic.&lt;/p&gt;

&lt;p&gt;Covered in detail by &lt;a href=&#34;https://www.youtube.com/watch?v=sK5i-N34im8&#34;&gt;Jérôme Petazzoni in his DockerCon EU 2015 presentation&lt;/a&gt;, control groups are integral to what makes up a linux container and fundamental to the resource usage control per process group. A fix for the above complaint is added to Docker 1.11, details can be found in the below Twitter conversation between the video creator and Docker maintainer &lt;a href=&#34;https://github.com/jfrazelle&#34;&gt;@jfrazelle&lt;/a&gt;:&lt;/p&gt;

&lt;blockquote class=&#34;twitter-tweet&#34;&gt;&lt;p lang=&#34;en&#34; dir=&#34;ltr&#34;&gt;&lt;a href=&#34;https://twitter.com/frazelledazzell&#34;&gt;@frazelledazzell&lt;/a&gt; &lt;a href=&#34;https://twitter.com/francesc&#34;&gt;@francesc&lt;/a&gt; &lt;a href=&#34;https://twitter.com/nixcraft&#34;&gt;@nixcraft&lt;/a&gt; &lt;a href=&#34;https://twitter.com/m1keil&#34;&gt;@m1keil&lt;/a&gt;  nproc cgroup support will only be in 1.11.0&lt;a href=&#34;https://t.co/lCKjdNmx5Y&#34;&gt;https://t.co/lCKjdNmx5Y&lt;/a&gt;&lt;/p&gt;&amp;mdash; Avishai Ish-Shalom (@nukemberg) &lt;a href=&#34;https://twitter.com/nukemberg/status/719326696084606978&#34;&gt;April 11, 2016&lt;/a&gt;&lt;/blockquote&gt;
&lt;script async src=&#34;//platform.twitter.com/widgets.js&#34; charset=&#34;utf-8&#34;&gt;&lt;/script&gt;

&lt;p&gt;Care is also required surrounding entropy depletion in cloud environments, which is certainly very relevant in shared-kernel scenarios and we may refer to &lt;a href=&#34;https://github.com/gesellix/haveged&#34;&gt;HAVEGED&lt;/a&gt; as a work-around for this.&lt;/p&gt;

&lt;h2 id=&#34;image-security:4c461b6a7a614440939d8002a0e574c8&#34;&gt;Image Security&lt;/h2&gt;

&lt;p&gt;The 2nd issue highlighted above was the mis-placed trust in container images pulled from public registries.&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat04.png&#34; alt=&#34;Untrusted Images&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;The very apt &amp;ldquo;&lt;a href=&#34;http://sobersecurity.blogspot.com.ee/2016/03/containers-are-like-sandwiches.html&#34;&gt;Sandwich Analogy&lt;/a&gt;&amp;rdquo; does a great job explaining why using non-official public images from the Docker Hub should be a concern.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Let&amp;rsquo;s think about Containers in the context of Sandwiches. You can pick up a sandwich. You can look at it, you can tell basically what&amp;rsquo;s going on inside. Are there tomatoes? Lettuce? Ham? Turkey? It&amp;rsquo;s not that hard. There can be things hiding, but for the most part you can get the big details. This is just like a container. Fedora? Red Hat? Ubuntu? It has httpd, great. What about a shell? systemd? Cool. There can be scary bits hidden in there too. Someone decided to replace /bin/sh with a python script? That&amp;rsquo;s just like hiding the olives under the lettuce. What sort of monster would do such a thing!&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The security of image contents was big in the news all of 2014 &amp;amp; 2015. Docker has been working diligently to add the required building blocks to fill the gaps. &lt;a href=&#34;https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/#content-addressable-storage&#34;&gt;Content Addressable image layers&lt;/a&gt; to verify image content against signed manifests, Registry repositories with proper pull validation no longer requiring Image IDs to be treated as secrets, &lt;a href=&#34;https://blog.docker.com/2015/11/dockercon-eu-2015-docker-universal-control-plane/&#34;&gt;Nautilus deep inspections&lt;/a&gt; on the hub ensuring exposed vulnerabilities are patched in the &lt;strong&gt;official&lt;/strong&gt; public Images, &lt;a href=&#34;https://blog.docker.com/2016/02/docker-engine-1-10-security/&#34;&gt;User Namespaces, Seccomp and AppArmor profiles&lt;/a&gt; as well as &lt;a href=&#34;https://blog.docker.com/2015/12/docker-webinar-qa-intro-to-docker-security/&#34;&gt;other Security additions&lt;/a&gt; to the Docker Engine, &amp;hellip;.&lt;/p&gt;

&lt;p&gt;Refer also to the &lt;a href=&#34;https://docs.docker.com/engine/security/&#34;&gt;Docker docs&lt;/a&gt; and &lt;a href=&#34;https://www.docker.com/docker-security&#34;&gt;the Docker Security Portal&lt;/a&gt;.&lt;/p&gt;

&lt;h2 id=&#34;docker-defaults:4c461b6a7a614440939d8002a0e574c8&#34;&gt;Docker Defaults&lt;/h2&gt;

&lt;p&gt;As highlighted in our &lt;a href=&#34;http://docker-saigon.github.io/post/Docker-Internals/&#34;&gt;Docker Internals&lt;/a&gt; blog post, if your Linux Kernel &amp;gt; 2.6.x - you need to disable the &lt;code&gt;userland-proxy&lt;/code&gt; on the Docker daemon in favor of Hairpin NAT!&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat13.png&#34; alt=&#34;docker-proxy&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;In general, careful study of the docker defaults is required to ensure the optimal configuration for your environment and use-case. Things such as selecting the appropriate Copy-on-Write Filesystem are all covered in the Docker docs.&lt;/p&gt;

&lt;h2 id=&#34;containers-vs-vms:4c461b6a7a614440939d8002a0e574c8&#34;&gt;Containers vs VMs&lt;/h2&gt;

&lt;p&gt;Containers provide significant advantages over Virtual Machines for the use of &amp;ldquo;Application Packaging&amp;rdquo; due to the fact that they take a short time to build, are moved around easily and can start and stop very quickly compared to VMs.&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat05.png&#34; alt=&#34;Inception&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;Unfortunately, in Windows &amp;amp; OSX - virtualisation is required to run the Linux kernel and work with Linux containers. If this is not fully understood, this may cause frustration.&lt;/p&gt;

&lt;p&gt;Docker is also improving this with the newest Docker client (which is in private beta at the time of writing). The approach used by the newer Docker clients integrates more deeply with the host operating system which greatly streamlines the developer experience on non-Linux operating systems.&lt;/p&gt;

&lt;h2 id=&#34;distribution-deployment:4c461b6a7a614440939d8002a0e574c8&#34;&gt;Distribution &amp;amp; Deployment&lt;/h2&gt;

&lt;p&gt;The Docker tools not only popularized Container technology, they also included critical shipping functionality making Containers an increasingly popular way to package and deploy code. Container images solve many real-world problems with existing packaging and deployment tools.&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat06.png&#34; alt=&#34;Bloated Images&#34; /&gt;
    
    
&lt;/figure&gt;



&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat07.png&#34; alt=&#34;Use Package Managers&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;However, as containers were being adopted by the masses without differentiating them from the way Virtual Machines tend to be used, images were often shipped with full Linux distributions and countless unnecessary binaries packaged within. This does not only bloat the images, causing slow deployment times, but also increases the attack surface for the application running in production.&lt;/p&gt;

&lt;p&gt;Luckily the community has been adopting slim &lt;code&gt;Application containers&lt;/code&gt;, using minimal Linux distributions such as Alpine - which is now being &lt;a href=&#34;https://news.ycombinator.com/item?id=11000378&#34;&gt;used for all the Official docker images&lt;/a&gt; and statically compiled binaries that only rely on the kernel they are built for.&lt;/p&gt;


&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat14.png&#34; alt=&#34;Scalable Apps&#34; /&gt;
    
    
&lt;/figure&gt;


&lt;p&gt;Scalability in your App is still up to you and will require you to explore the scenarios enabled by Containers.&lt;/p&gt;

&lt;p&gt;The concept of Container &lt;a href=&#34;http://kubernetes.io/docs/user-guide/pods/&#34;&gt;Pods&lt;/a&gt; encourage the decomposition of applications into even smaller modular, focused, cooperating containers. The isolation provided by containers are sufficient to allow the design of reusable components which lead to more reliable, more scalable and faster to build services than applications built from monolithic containers. We believe these concepts require a change in mindset of what it means to build applications for the cloud. Read more about: &lt;a href=&#34;http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html&#34;&gt;Patterns for Composite Containers&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;But even for existing legacy applications, which may be less &amp;ldquo;CloudNative&amp;rdquo;, containers enable powerfull deployment patterns such as &lt;a href=&#34;https://www.joyent.com/blog/dbaas-simplicity-no-lock-in&#34;&gt;The autopilot pattern&lt;/a&gt; pioneered by Joyent.&lt;/p&gt;

&lt;h2 id=&#34;microsoft:4c461b6a7a614440939d8002a0e574c8&#34;&gt;Microsoft&lt;/h2&gt;

&lt;p&gt;
&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat10.png&#34; alt=&#34;Microsoft Containers&#34; /&gt;
    
    
&lt;/figure&gt;
&lt;/p&gt;

&lt;p&gt;Microsoft committed early on to supporting the Docker API for Windows containers with Windows Server 2016. After contributing to ensure the Docker client tools worked well on Windows, implementing Filesystem and Container fundamentals in the Windows Kernel and even open sourcing the Dot Net Core CLR.&lt;/p&gt;

&lt;p&gt;
&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat11.png&#34; alt=&#34;Microsoft Containers&#34; /&gt;
    
    
&lt;/figure&gt;
&lt;/p&gt;

&lt;p&gt;Microsoft seems to have gone full-out by extending Project Astoria (an Android emulator) into an impressive Windows SubSystem for Linux (WSL) announced just last week and surprising everyone.&lt;/p&gt;

&lt;p&gt;
&lt;figure &gt;
    
        &lt;img src=&#34;http://docker-saigon.github.io/img/caveat/caveat12.png&#34; alt=&#34;Bash on Windows&#34; /&gt;
    
    
&lt;/figure&gt;
&lt;/p&gt;

&lt;p&gt;The current Linux Kernel API features integrated with Windows however, are targeted at the most common Linux system calls and just enough to &lt;a href=&#34;http://arstechnica.com/information-technology/2016/04/why-microsoft-needed-to-make-windows-run-linux-software/&#34;&gt;make Windows a more attractive platform for software development&lt;/a&gt; (at the moment).&lt;/p&gt;

&lt;p&gt;Integrating these recent events into a wonderfully joyful way, our hats are off to the creator of this video!&lt;/p&gt;

&lt;p&gt;&lt;a href=&#34;https://news.ycombinator.com/item?id=11477020&#34;&gt;Discuss on Hacker-News&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Reference: &lt;a href=&#34;http://blog.takipi.com/ignore-the-hype-5-docker-misconceptions-java-developers-should-consider/&#34;&gt;Ignore the Hype&lt;/a&gt;&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>TLS secured Private Registries</title>
      <link>http://docker-saigon.github.io/post/Private-Registry-Setup/</link>
      <pubDate>Tue, 22 Mar 2016 14:52:43 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/post/Private-Registry-Setup/</guid>
      <description>

&lt;p&gt;An intermezzo after creating a small swarm cluster in &lt;a href=&#34;http://docker-saigon.github.io/post/Swarm-Week-2016-Part1/&#34;&gt;our previous post&lt;/a&gt; and before deploying &amp;amp; scaling the sample voting app on this cluster.&lt;/p&gt;

&lt;p&gt;In this post we will use &lt;code&gt;Docker-Machine&lt;/code&gt; to provision a &lt;code&gt;Boot2Docker&lt;/code&gt; host for a  local Docker &lt;code&gt;Registry&lt;/code&gt; and explain how to configure other Machines (i.e. &lt;code&gt;Boot2Docker&lt;/code&gt; &amp;amp; &lt;code&gt;CoreOS&lt;/code&gt; machines) to push and pull from this Registry using TLS.&lt;/p&gt;

&lt;p&gt;This setup is great for giving demonstrations where internet access is not guaranteed. We will not be configuring basic authentication or more advanced features such as web hooks, but provide links for how to do this.&lt;/p&gt;

&lt;p&gt;We will, again, be using Windows 10, Hyper-V and PowerShell for this setup (as there aren&amp;rsquo;t many guides out there using this setup), but it should be trivial to repeat these steps on OSX.&lt;/p&gt;

&lt;h2 id=&#34;1-create-configure-the-machine-to-host-the-registry:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;1. Create &amp;amp; Configure the Machine to host the Registry&lt;/h2&gt;

&lt;p&gt;Use Docker-Machine to create a TLS secured Docker Engine. For the full details on our environment configuration, refer to our previous post on &lt;a href=&#34;http://docker-saigon.github.io/post/Swarm-Week-2016-Part1/&#34;&gt;How to create a Swarm cluster.&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;As seen in that post, using Hyper-V and an elevated Powershell session with the &lt;code&gt;dm&lt;/code&gt; alias (&lt;code&gt;New-Alias dm Docker-Machine&lt;/code&gt;), we may run the following command to create our &lt;code&gt;registry0&lt;/code&gt; machine:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm create `
 --driver hyperv `
 --hyperv-virtual-switch &amp;quot;VMWare NAT&amp;quot; `
 --hyperv-memory &amp;quot;512&amp;quot; registry0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: As a result of the above command, &lt;code&gt;Docker-Machine&lt;/code&gt; will have created a PKI for us. The Certificate Authority private key as well as self-signed CA certificate are stored under &lt;code&gt;~/.docker/machine/certs/&lt;/code&gt;, we will use this information when generating the TLS assets for our registry.&lt;/p&gt;

&lt;p&gt;Configure a static IP (192.168.233.3) for the newly created machine.&lt;/p&gt;

&lt;p&gt;Using PowerShell with a single command from the Host:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;echo &amp;quot;kill ``more /var/run/udhcpc.eth0.pid```n`
ifconfig eth0 192.168.233.3 netmask 255.255.255.0 broadcast 192.168.233.255 up`n`
route add default gw 192.168.233.2&amp;quot; | `
dm ssh registry0 &amp;quot;sudo tee /var/lib/boot2docker/bootsync.sh&amp;quot; &amp;gt; $null
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;(see Swarm post referred to earlier for a detailed explanation of these commands)&lt;/p&gt;

&lt;p&gt;Now, bounce the machine:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm restart registry0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;After changing the IP, we have to re-generate the certificates used by our &lt;code&gt;registry0&lt;/code&gt; machine:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm regenerate-certs registry0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Add DNS entries for &lt;code&gt;registry0&lt;/code&gt; (in our setup, this is handled through the &lt;code&gt;/etc/hosts&lt;/code&gt; file on the VM Host):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;&amp;quot;192.168.233.3 registry0`n192.168.233.3 registry0.localdomain&amp;quot; | ac $env:Windir\System32\Drivers\etc\hosts
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: Requires an elevated PowerShell session.&lt;/p&gt;

&lt;h2 id=&#34;2-prepare-the-tls-assets-for-the-registry:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;2. Prepare the TLS assets for the Registry&lt;/h2&gt;

&lt;p&gt;For convenience, we will use the PKI created by &lt;code&gt;Docker-Machine&lt;/code&gt; to generate a signed certificate.&lt;/p&gt;

&lt;p&gt;First, generate the private key to be used by the registry server:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;openssl genrsa -out registry-key.pem 2048
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Next, we need to create a signing request. We will use a config file &lt;code&gt;registry-openssl.cnf&lt;/code&gt; with the following contents:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = registry0.localdomain
DNS.2 = registry0
IP.1 = 192.168.233.3
IP.2 = 192.168.150.104
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: Make sure to replace/add any hostnames and IPs the registry will be reachable on by other Docker Engines into the above snippet.&lt;/p&gt;

&lt;p&gt;Use the private key and the configuration file to create a certificate signing request (using git-bash):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;openssl req -new -key registry-key.pem -out registry.csr -subj &amp;quot;/CN=registry0.localdomain&amp;quot; -config registry-openssl.cnf
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Use the CA created by &lt;code&gt;Docker-Machine&lt;/code&gt; to sign the certificate for the registry:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cp ~/.docker/machine/certs/ca*-pem .
openssl x509 -req -in registry.csr -CA &amp;quot;ca.pem&amp;quot; -CAkey &amp;quot;ca-key.pem&amp;quot; -CAcreateserial -out &amp;quot;registry.pem&amp;quot; -days 365 -extensions v3_req -extfile registry-openssl.cnf
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Copy the registry private key, signed certificate as well as certificate authority to the registry server:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;scp -i ~/.docker/machine/machines/registry0/id_rsa registry.pem registry-key.pem ca.pem docker@registry0:.
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;3-create-the-registry-container:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;3. Create the Registry Container&lt;/h2&gt;

&lt;p&gt;We now have all ingredients to run a basic registry server on the &lt;code&gt;registry0&lt;/code&gt; Machine. We will use a minimal Registry configuration, refer to the &lt;a href=&#34;https://docs.docker.com/registry/configuration/&#34;&gt;official Docker docs&lt;/a&gt; for more configuration options.&lt;/p&gt;

&lt;p&gt;SSH to our Machine with &lt;code&gt;dm ssh registry0&lt;/code&gt; or alternatively with the following command:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ssh -i ~/.docker/machine/machines/registry0/id_rsa docker@registry0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Prepare the folder structure and data for the registry server&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo -i
mkdir /var/lib/boot2docker/registry-certs/
mkdir /var/lib/boot2docker/registry-data/
mv ~docker/registry-*.pem /var/lib/boot2docker/registry-certs/
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Start the Registry container (this will pull the image automatically from the Docker Hub):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -d -p 443:5000 --restart=always --name registry \
  -v /var/lib/boot2docker/registry-certs:/certs \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.pem \
  -e REGISTRY_HTTP_TLS_KEY=/certs/registry-key.pem \
  -v /var/lib/boot2docker/registry-data:/var/lib/registry \
  registry:2
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: may need to chain the &lt;code&gt;registry.pem&lt;/code&gt; certificate with the &lt;code&gt;ca.pem&lt;/code&gt; certificate for this to work (to be confirmed)&lt;/p&gt;

&lt;p&gt;From any other machine, confirm the registry works with the following command (assuming &lt;code&gt;ca.pem&lt;/code&gt; lives in &lt;code&gt;PWD&lt;/code&gt;)&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;curl --cacert ca.pem https://registry0/v2/
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: To give an example of the more advanced configuration options, refer to &lt;a href=&#34;https://docs.docker.com/registry/configuration/#notifications&#34;&gt;the configuration of webhooks&lt;/a&gt;:&lt;/p&gt;

&lt;p&gt;&lt;code&gt;REGISTRY_NOTIFICATIONS_ENDPOINTS_{name,url,headers, ...}&lt;/code&gt; ENV variables which allow us to call out systems such as &lt;a href=&#34;https://github.com/ehazlett/conduit&#34;&gt;Conduit&lt;/a&gt; and automatically deploy images a build server may push to this registry.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;http://docker-saigon.github.io/img/notifications.png&#34; alt=&#34;registry notifications&#34; /&gt;&lt;/p&gt;

&lt;p&gt;A more complicated setup may be managed through &lt;code&gt;Docker-Compose&lt;/code&gt;.&lt;/p&gt;

&lt;h2 id=&#34;4-ensuring-your-docker-engine-can-push-pull-from-this-registry:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;4. Ensuring your Docker Engine can push/pull from this registry.&lt;/h2&gt;

&lt;p&gt;Servers who do not trust the CA which signed the Registry certificate will not be able to push/pull from our Registry. The steps below show how to make a server trust our CA.&lt;/p&gt;

&lt;h3 id=&#34;for-boot2docker-machines:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;For Boot2Docker machines:&lt;/h3&gt;

&lt;p&gt;Add the Certificate Authority to a &lt;code&gt;Boot2Docker&lt;/code&gt; machine (See: &lt;a href=&#34;https://github.com/boot2docker/boot2docker/blob/v1.10.3/README.md#installing-secure-registry-certificates&#34;&gt;B2d - Installing Secure Registry Certificates&lt;/a&gt;):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm scp ca.pem &amp;lt;machine&amp;gt;:~
dm ssh &amp;lt;machine&amp;gt; sudo mkdir -p /var/lib/boot2docker/certs/
dm ssh &amp;lt;machine&amp;gt; sudo mv ~/ca.pem /var/lib/boot2docker/certs/
dm restart &amp;lt;machine&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Once the machine has rebooted, you will be able to push/pull from the local registry.&lt;/p&gt;

&lt;h3 id=&#34;for-coreos-machines:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;For CoreOS machines:&lt;/h3&gt;

&lt;p&gt;Similar to Boot2Docker, add the Certificate Authority and update the certificates:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;scp ca.pem core@&amp;lt;machine&amp;gt;:~
ssh core@&amp;lt;machine&amp;gt; sudo mv ca.pem /etc/ssl/certs
ssh core@&amp;lt;machine&amp;gt; sudo update-ca-certificates
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&#34;for-ubuntu-debian-rhel-centos:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;For Ubuntu, Debian, RHEL, CentOS, &amp;hellip;&lt;/h3&gt;

&lt;p&gt;Refer to the &lt;a href=&#34;https://docs.docker.com/docker-trusted-registry/configure/config-security/#install-registry-certificates-on-client-docker-daemons&#34;&gt;official documentation&lt;/a&gt; from the DTR (the setup is the same for our TLS secured private registry).&lt;/p&gt;

&lt;h2 id=&#34;5-usage-tips-for-your-private-registry:21a6fde08c8e60098cde90e87b1d737a&#34;&gt;5. Usage tips for your private Registry&lt;/h2&gt;

&lt;p&gt;To pull a Docker Image from the Hub and make it available on your local registry, enter the following commands (example with the official alpine-based nginx image):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker pull nginx:mainline-alpine
docker tag nginx:mainline-alpine registry0.localdomain/nginx:mainline-alpine
docker push registry0.localdomain/nginx:mainline-alpine
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;From then on, all local machines may easily serve static content with the following command:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -d --name web -v --restart=always /path/to/html:/etc/nginx/html:ro registry0.localdomain/nginx:mainline-alpine
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Tip&lt;/strong&gt;: this nginx server can be deployed on our registry server to serve static binaries / yaml files for bootstrapping scripts for our cluster as well as the images stored in its repositories.&lt;/p&gt;

&lt;p&gt;There are a few Registry web UI which allow you to list repositories, images and tags for a v2 Registry, but several lack basic features.&lt;/p&gt;

&lt;p&gt;Alternatively, the contents may be listed with the following &lt;code&gt;curl&lt;/code&gt; &amp;amp; &lt;code&gt;jq&lt;/code&gt; commands as well:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;#list repositories
curl -s https://registry0.localdomain/v2/_catalog | jq -r .repositories[]
#list tags of an image
curl -s https://registry0.localdomain/v2/nginx/tags/list | jq -r .tags[]
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;For more actions, refer to the &lt;a href=&#34;https://github.com/docker/distribution/blob/v2.3.1/docs/spec/api.md#deleting-an-image&#34;&gt;Registry v2 API&lt;/a&gt;&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Swarm week 2016 - Part 1: Cluster Setup</title>
      <link>http://docker-saigon.github.io/post/Swarm-Week-2016-Part1/</link>
      <pubDate>Fri, 11 Mar 2016 10:29:20 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/post/Swarm-Week-2016-Part1/</guid>
      <description>

&lt;p&gt;In this post we will be creating a local &lt;code&gt;Swarm&lt;/code&gt; cluster running in VMs on &lt;code&gt;Boot2Docker&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;We will be using &lt;code&gt;Consul&lt;/code&gt; as a kvstore for:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;node discovery &amp;amp; overlay networking,&lt;/li&gt;
&lt;li&gt;swarm leader election, and&lt;/li&gt;
&lt;li&gt;as a config store for other cluster components (i.e Interlock config).&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Swarm makes use of the &lt;a href=&#34;https://github.com/docker/libkv&#34;&gt;libkv&lt;/a&gt; library to support not only consul but multiple store backends: (&lt;code&gt;etcd&lt;/code&gt;,&lt;code&gt;zookeeper&lt;/code&gt;,..).&lt;/p&gt;

&lt;p&gt;All Docker Engines will be created through &lt;code&gt;Docker-Machine&lt;/code&gt; with TLS enabled. Additionally, we will see &lt;strong&gt;how to configure Boot2Docker with a static IP&lt;/strong&gt; and install the &lt;a href=&#34;https://github.com/gondor/docker-volume-netshare&#34;&gt;netshare&lt;/a&gt; &lt;code&gt;Volume Driver&lt;/code&gt; to &lt;strong&gt;mount VM host folders across all cluster nodes for persistence&lt;/strong&gt; - allowing any statefull containers to be re-scheduled on different nodes without loss of data.&lt;/p&gt;

&lt;p&gt;In a future post, we will look at deploying and scaling the &lt;a href=&#34;https://github.com/docker/swarm-microservice-demo-v1&#34;&gt;sample voting app&lt;/a&gt; on top of this cluster with &lt;code&gt;Docker-Compose&lt;/code&gt;, using the latest &lt;code&gt;Interlock&lt;/code&gt; images with TLS authentication for communication with Swarm.&lt;/p&gt;

&lt;p&gt;In the sample set-up in this first part, we will be using a &lt;strong&gt;single-node&lt;/strong&gt; Consul cluster and a &lt;strong&gt;single-node&lt;/strong&gt; Swarm-manager cluster. For High Availability we would need to deploy several Consul nodes and Swarm-Manager replicas behind a load balancer, which may be explored in a future post.&lt;/p&gt;

&lt;p&gt;Finally, automation of all the manual steps using &lt;a href=&#34;nathanleclaire.com/blog/2015/11/10/using-ansible-with-docker-machine-to-bootstrap-host-nodes/&#34;&gt;Ansible containers&lt;/a&gt; would be the perfect conclusion of this series.&lt;/p&gt;

&lt;p&gt;We will be using Windows 10, Hyper-V and PowerShell for this setup, but it should be possible to repeat a similar setup on OSX (replacing CIFS by NFS in the netshare, for example).&lt;/p&gt;

&lt;h2 id=&#34;windows-10-environment-setup:e3eed6f67421eff48e81c37460ec6ac3&#34;&gt;Windows 10 Environment Setup&lt;/h2&gt;

&lt;p&gt;The quickest way to get everything ready on Windows would be by installing &lt;a href=&#34;https://github.com/git-for-windows&#34;&gt;git-for-windows&lt;/a&gt; and the &lt;a href=&#34;https://www.docker.com/products/docker-toolbox&#34;&gt;Docker Toolbox&lt;/a&gt; (VirtualBox).&lt;/p&gt;

&lt;p&gt;However, &lt;strong&gt;if you are required to use the Hyper-V role&amp;hellip;&lt;/strong&gt; - the Docker Toolbox can/should not be used.&lt;/p&gt;

&lt;p&gt;The following steps will guide you how to use &lt;code&gt;docker&lt;/code&gt;, &lt;code&gt;docker-machine&lt;/code&gt; and &lt;code&gt;docker-compose&lt;/code&gt; with Hyper-V on Windows 10 (64 bit):&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;Hyper-V &amp;amp; NAT Setup&lt;/p&gt;

&lt;p&gt;Before &lt;a href=&#34;http://www.thomasmaurer.ch/2015/11/hyper-v-virtual-switch-using-nat-configuration/&#34;&gt;NAT support was added to Hyper-V (Q3 2015)&lt;/a&gt; in Windows 10, it was recommended to &lt;a href=&#34;http://thomasvochten.com/archive/2014/01/hyper-v-nat/&#34;&gt;use VMWare&amp;rsquo;s NAT &amp;amp; DHCP services with Hyper-V&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;It is also possible to use Internet Connection Sharing (ICS) with your Virtual Network, but I strongly advise against it. ICS requires manual re-configuration when switching between Ethernet and WiFi adapters, which is not suitable.&lt;/p&gt;

&lt;p&gt;At the time of writing, I still prefer to use the VMWare networking services with Hyper-V as it still provides the most features. You could even extract the &lt;code&gt;vmnetconfig.exe&lt;/code&gt; UI tool from the VMWare Workstation installation source to easily manage your virtual networks (after only installing VMWare Player components):
 &lt;img src=&#34;http://docker-saigon.github.io/img/hyper-v-vmnetconf.png&#34; alt=&#34;vmnetconf&#34; /&gt;&lt;/p&gt;

&lt;p&gt;The VM networking services provided by the VMWare tools also include a DNS server which forwards any DNS requests from VMs to the host machine. This means that you only need to maintain the &lt;code&gt;etc/hosts&lt;/code&gt; file centrally on the Hyper-V host for easy, IP-less, inter-VM communication.&lt;/p&gt;

&lt;p&gt;Before we move on, note down the name of your Virtual Switch configured with VMWare NAT, mine is &lt;code&gt;VMWare Nat&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;However, if you decide to use the new NAT switches introduced for Hyper-V on Windows 10, you will still need to find a solution for &lt;a href=&#34;https://4sysops.com/archives/native-nat-in-windows-10-hyper-v-using-a-nat-virtual-switch/#dhcp-server-for-windows&#34;&gt;DHCP&lt;/a&gt; as well as &lt;a href=&#34;http://unbound.net/index.html&#34;&gt;DNS&lt;/a&gt;.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Git, ssh, scp, openssl, &amp;hellip;&lt;/p&gt;

&lt;p&gt;Installing &lt;a href=&#34;https://github.com/git-for-windows&#34;&gt;git-for-windows&lt;/a&gt; is mandatory for a decent console experience on Windows. The git-for-windows bundle also removes the need for putty, plink &amp;amp; pageant when working with Linux machines.&lt;/p&gt;

&lt;p&gt;Even though the Windows 10 console has greatly improved (transparency, multi-line selections, full-screen mode, &lt;code&gt;CTRL+C/V&lt;/code&gt; support, &amp;hellip;), I still recommend the usage of &lt;a href=&#34;https://conemu.github.io/&#34;&gt;ConEmu&lt;/a&gt; as it has more features (quickly splitting console panels, switching between consoles, configurable short-cuts, &amp;hellip;).&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Docker setup&lt;/p&gt;

&lt;p&gt;In a bash console, execute the following commands:&lt;/p&gt;

&lt;p&gt;Download the &lt;code&gt;docker&lt;/code&gt; Windows 64 bit binary:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; curl -Lo /usr/bin/docker.exe https://get.docker.com/builds/Windows/x86_64/docker-1.10.3.exe
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Download &lt;code&gt;docker-machine&lt;/code&gt; Windows 64 bit binary (includes hyperv driver)&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; curl -Lo /usr/bin/docker-machine.exe https://github.com/docker/machine/releases/download/v0.6.0/docker-machine-Windows-x86_64.exe
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Download &lt;code&gt;docker-compose&lt;/code&gt; Windows 64 bit binary&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; curl -Lo /usr/bin/docker-compose.exe https://github.com/docker/compose/releases/download/1.6.2/docker-compose-Windows-x86_64.exe
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;PowerShell set-up&lt;/p&gt;

&lt;p&gt;To control Hyper-V, PowerShell needs to have Administrative privileges. in ConEmu pressing &lt;code&gt;WINDOWS+SHIFT+W&lt;/code&gt; allows you to quickly create such a session:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;http://docker-saigon.github.io/img/powershell-admin.png&#34; alt=&#34;PowerShell Admin&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Make sure your &lt;code&gt;$PATH&lt;/code&gt; environment variable includes the &lt;code&gt;/usr/bin/&lt;/code&gt; directory where we downloaded all the binaries earlier:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; $env:Path.Contains(&amp;quot;$env:LOCALAPPDATA\Programs\Git\usr\bin&amp;quot;)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Should return &lt;code&gt;True&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Confirm the Docker tools are working:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; docker --version; docker-machine --version; docker-compose --version
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Should return something similar to the following:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; Docker version 1.10.3, build 20f81dd
 docker-machine.exe version 0.6.0, build e27fb87
 docker-compose version 1.6.2, build e80fc83
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;During this guide, we will use aliases as follows:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; New-Alias &amp;quot;dm&amp;quot; &amp;quot;docker-machine&amp;quot;
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Shared Folder Set-up&lt;/p&gt;

&lt;p&gt;For this demo we assume a &lt;code&gt;demo&lt;/code&gt; user with password &lt;code&gt;demo&lt;/code&gt; is created on the Hyper-V host and a folder share read/writeable to this user exists under the name &lt;code&gt;demo&lt;/code&gt;.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&#34;set-up-the-key-value-store:e3eed6f67421eff48e81c37460ec6ac3&#34;&gt;Set up the Key Value Store&lt;/h2&gt;

&lt;p&gt;We will run Consul using a Docker machine. After provisioning the machine, we will configure a static IP, launch the Consul container and confirm Consul is working.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;Provision the &lt;code&gt;consul0&lt;/code&gt; machine&lt;/p&gt;

&lt;p&gt;Generic command:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker-machine create consul0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;In PowerShell using Hyper-V and setting custom memory:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm create `
 --driver hyperv `
 --hyperv-virtual-switch &amp;quot;VMWare NAT&amp;quot; `
 --hyperv-memory &amp;quot;512&amp;quot; consul0
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Set a Static IP (&lt;a href=&#34;https://github.com/docker/machine/issues/1709&#34;&gt;ref&lt;/a&gt;) and reboot the machine.&lt;/p&gt;

&lt;p&gt;In this sample setup, VMs use the &lt;code&gt;192.168.233.0/24&lt;/code&gt; subnet with the NAT gateway on &lt;code&gt;192.168.233.2&lt;/code&gt; and a DHCP range of &lt;code&gt;128-254&lt;/code&gt;. We will assign &lt;code&gt;192.168.233.10&lt;/code&gt; as the static IP for our Consul node. Keep in mind you may need to update these values to match your configuration.&lt;/p&gt;

&lt;p&gt;By default, DHCP is enabled on the Boot2Docker interfaces, but we may disable it by killing the process managing a particular interface:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;kill `more /var/run/udhcpc.eth0.pid`
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Do not run the following commands on the Boot2Docker VM just yet, we will add them to the boot process at a later stage.&lt;/p&gt;

&lt;p&gt;To set a static IP and ensure a default route to the gateway, we would use the following 2 commands:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ifconfig eth0 192.168.233.10 netmask 255.255.255.0 broadcast 192.168.233.255 up
route add default gw 192.168.233.2
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;If we weren&amp;rsquo;t using PowerShell, We may add the above commands to the boot script as follows (quote the heredoc label to avoid backticks from being evaluated):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cat &amp;lt;&amp;lt;&amp;quot;EOF&amp;quot; | sudo tee /var/lib/boot2docker/bootsync.sh
kill `more /var/run/udhcpc.eth0.pid`
ifconfig eth0 192.168.233.10 netmask 255.255.255.0 broadcast 192.168.233.255 up
route add default gw 192.168.233.2
EOF
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Or, using PowerShell with a single command from the Host:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;echo &amp;quot;kill ``more /var/run/udhcpc.eth0.pid```n`
ifconfig eth0 192.168.233.10 netmask 255.255.255.0 broadcast 192.168.233.255 up`n`
route add default gw 192.168.233.2&amp;quot; | `
dm ssh consul0 &amp;quot;sudo tee /var/lib/boot2docker/bootsync.sh&amp;quot; &amp;gt; $null
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Bounce the box&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm restart consul0
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Regenerate the certificates&lt;/p&gt;

&lt;p&gt;Docker-Machine generated certificates are only valid for the old IP, changing the IP requires us to regenerate the certificates:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm regenerate-certs consul0
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Start Consul&lt;/p&gt;

&lt;p&gt;Docker-Machine helps you manage your environment configuration to target the right Boot2Docker VM:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker-machine env consul0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Activating this environment in PowerShell (using &lt;code&gt;iex&lt;/code&gt; as an alias for &lt;code&gt;Invoke-Expression&lt;/code&gt;), looks as follows:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm env consul0 | iex
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm all is working:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker info
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Launch a single node Consul container, exposing its DNS and the Consul API:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -d -p 192.168.233.10:8500:8500 -p 192.168.233.10:53:8600/udp --name consul -h consul --restart always gliderlabs/consul-server -bootstrap
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Follow the boot process of your Consul node:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker logs -f consul
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Press &lt;code&gt;CTRL+C&lt;/code&gt; and add an entry for the static consul IP to your hosts file (if your virtual network forwards DNS queries to your host, this will allow all your nodes to point to the &lt;code&gt;consul0&lt;/code&gt; node by its hostname).&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;&amp;quot;consul0&amp;quot; | `
% { &amp;quot;$($(Get-VM $_).NetworkAdapters[0].IpAddresses[0]) $_&amp;quot; } | `
ac $env:Windir\System32\Drivers\etc\hosts
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm Consul works:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;iwr http://consul0:8500/v1/catalog/nodes | ConvertFrom-Json
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&#34;set-up-the-swarm-manager:e3eed6f67421eff48e81c37460ec6ac3&#34;&gt;Set up the Swarm Manager&lt;/h2&gt;

&lt;p&gt;We will now create a single Swarm Manager (no replication) and use the following &lt;code&gt;Docker-Machine&lt;/code&gt; &lt;a href=&#34;https://docs.docker.com/machine/reference/create/&#34;&gt;flags&lt;/a&gt; to configure our box:&lt;/p&gt;

&lt;p&gt;Swarm flags:&lt;/p&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Flag&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--swarm&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Provision swarm agent, &lt;a href=&#34;https://docs.docker.com/swarm/reference/join/&#34;&gt;see docs&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--swarm-master&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Provision swarm manager, &lt;a href=&#34;https://docs.docker.com/swarm/reference/manage/&#34;&gt;see docs&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--swarm-discovery&lt;/code&gt; &amp;nbsp;&lt;/td&gt;
&lt;td&gt;Discovery method, &lt;a href=&#34;https://docs.docker.com/swarm/reference/manage/#discovery-discovery-backend&#34;&gt;see docs&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;We also specify Engine &lt;a href=&#34;https://docs.docker.com/engine/reference/commandline/daemon&#34;&gt;configuration options&lt;/a&gt; to enable &lt;strong&gt;Node Discovery&lt;/strong&gt; in the created Docker engine, this is required to support overlay networking:&lt;/p&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Option&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--cluster-store&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;kvstore URL&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--cluster-advertise&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;URL for cluster nodes to reach this node, &lt;a href=&#34;https://docs.docker.com/engine/reference/commandline/daemon/#nodes-discovery&#34;&gt;see docs&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--cluster-store-opt&lt;/code&gt; &amp;nbsp;&lt;/td&gt;
&lt;td&gt;additional cluster options&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;Below is an overview of default sockets used by Docker components:&lt;/p&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Port&lt;/th&gt;
&lt;th&gt;Protocol&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;2375 &amp;nbsp;&lt;/td&gt;
&lt;td&gt;insecure docker API&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;2376&lt;/td&gt;
&lt;td&gt;TLS secure docker API&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;3375&lt;/td&gt;
&lt;td&gt;insecure swarm API&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;3376&lt;/td&gt;
&lt;td&gt;TLS secure swarm API&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;Combining the above information, this is how we may create our Swarm Manager with Docker-Machine using Powershell:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm create `
 --driver hyperv `
 --hyperv-virtual-switch &amp;quot;VMWare NAT&amp;quot; `
 --swarm --swarm-master `
 --swarm-discovery &amp;quot;consul://consul0:8500/cluster1&amp;quot; `
 --engine-opt &amp;quot;cluster-store consul://consul0:8500&amp;quot; `
 --engine-opt &amp;quot;cluster-advertise eth0:2376&amp;quot; `
 --engine-opt &amp;quot;cluster-store-opt kv.path=cluster1/docker/overlay&amp;quot; master0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Once our box has been provisioned, we can confirm the engine options were applied by looking at the &lt;code&gt;/var/lib/boot2docker/profile&lt;/code&gt;:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm ssh master0 cat /var/lib/boot2docker/profile
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;You may have noticed that we specified custom paths for the config store, we can confirm the actual keys stored in consul with the following command:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;iwr http://consul0:8500/v1/kv/?recurse | ConvertFrom-Json | ft Key
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;join-nodes-to-the-swarm-cluster:e3eed6f67421eff48e81c37460ec6ac3&#34;&gt;Join Nodes to the Swarm cluster&lt;/h2&gt;

&lt;p&gt;To create the Swarm Nodes, we follow the exact same steps as before, however we do not specify the &lt;code&gt;--swarm-master&lt;/code&gt; flag.&lt;/p&gt;

&lt;p&gt;Additionally, we may attach &lt;a href=&#34;https://docs.docker.com/userguide/labels-custom-metadata/#daemon-labels&#34;&gt;labels&lt;/a&gt; to our nodes depending on the roles we assign to them within our infrastructure:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm create `
 --driver hyperv `
 --hyperv-virtual-switch &amp;quot;VMWare NAT&amp;quot;`
 --swarm `
 --swarm-discovery=&amp;quot;consul://consul0:8500/cluster1&amp;quot; `
 --engine-opt=&amp;quot;cluster-store=consul://consul0:8500&amp;quot; `
 --engine-opt=&amp;quot;cluster-advertise=eth0:2376&amp;quot; `
 --engine-opt=&amp;quot;cluster-store-opt=kv.path=cluster1/docker/overlay&amp;quot; `
 --engine-label=&amp;quot;com.docker-saigon.group=frontend&amp;quot; `
 --engine-label &amp;quot;com.docker-saigon.environment=dev&amp;quot; node0
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Don&amp;rsquo;t forget to change the &lt;code&gt;--engine-label&lt;/code&gt; flags when provisioning multiple nodes with different roles&lt;/p&gt;

&lt;p&gt;Confirm the nodes have joined the Swarm&lt;/p&gt;

&lt;p&gt;Look at the consul data:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;iwr http://consul0:8500/v1/kv/?recurse | ConvertFrom-Json | ft Key
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Activate the connection to the Swarm cluster:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm env --swarm master0 | iex
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; The usage of the &lt;code&gt;--swarm&lt;/code&gt; flag!&lt;/p&gt;

&lt;p&gt;Once the nodes become available, install the &lt;a href=&#34;https://github.com/gondor/docker-volume-netshare&#34;&gt;netshare&lt;/a&gt; &lt;code&gt;Volume Driver&lt;/code&gt; with the following steps:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;ssh into the node (repeat for every node):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm ssh node0
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Download the netshare archive:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;curl -Lo docker-volume-netshare_0.11.tar.gz https://dl.bintray.com//content/pacesys/docker/docker-volume-netshare_0.11_linux_amd64.tar.gz?direct
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Extract the archive to the persistant disk of Boot2Docker:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo tar -xf docker-volume-netshare_0.11.tar.gz -C /var/lib/boot2docker/ --strip=1 docker-volume-netshare_0.11_linux_amd64/docker-volume-netshare \
&amp;amp;&amp;amp; rm -f docker-volume-netshare_0.11.tar.gz
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Create a .netrc file with credentials for the &lt;code&gt;demo&lt;/code&gt; share we created in the Windows Environment setup&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo sh -c &#39;cat &amp;gt; /var/lib/boot2docker/.netrc &amp;lt;&amp;lt;EOF
machine 192.168.233.1
       username  demo
       password  demo
       domain    192.168.233.1
EOF&#39;
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Enable the netshare volume driver to start at boot:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;echo &#39;/var/lib/boot2docker/docker-volume-netshare cifs --netrc /var/lib/boot2docker &amp;gt;/var/lib/boot2docker/log/netshare 2&amp;gt;&amp;amp;1 &amp;lt;/dev/null &amp;amp;&#39; | sudo tee -a /var/lib/boot2docker/bootsync.sh  &amp;gt; /dev/null
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Bounce the nodes&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Confirm the netshare Volume Driver is running&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm ssh node0 ps xawu | grep netshare
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&#34;demo-on-created-swarm-cluster:e3eed6f67421eff48e81c37460ec6ac3&#34;&gt;Demo on created swarm cluster&lt;/h2&gt;

&lt;p&gt;To conclude this post, we will quickly demonstrate working cross node communication and container discovery as well as the ability to mount shared storage from the host.&lt;/p&gt;

&lt;p&gt;First, ensure we are talking with the Swarm manager:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm env --swarm master0 | iex
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;List existing networks:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker network ls
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: A default bridge, host and null network exist for every node in the cluster.&lt;/p&gt;

&lt;p&gt;Create a new network through swarm:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker network create --subnet=10.0.10.0/24 nw
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: It is good practice to provide the subnet when creating networks&lt;/p&gt;

&lt;p&gt;Review the created network:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker network ls
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: The network was created as an overlay network across the cluster, this is the default when creating networks with swarm.&lt;/p&gt;

&lt;p&gt;Instruct all nodes to pull the latest alpine image:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker pull alpine
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;If using ConEmu, press &lt;code&gt;CTRL+SHIFT+O&lt;/code&gt; to horizontally split the console&lt;/p&gt;

&lt;p&gt;Ensure the newly created console is pointing to the swarm master&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;New-Alias dm docker-machine
dm env --swarm master0 | iex
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Monitor the netshare logs on &lt;code&gt;node0&lt;/code&gt; in the top frame:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;dm ssh node0 tail -f /var/lib/boot2docker/log/netshare
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Define a volume for all nodes in the cluster:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker volume create -d cifs --name /192.168.233.1/demo
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Run a first container in the cluster:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -dit --name container1 --net nw -v 192.168.233.1/demo:/demo alpine sh
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: You should notice the volume being mounted on node0&lt;/p&gt;

&lt;p&gt;Run a second container in the cluster:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -dit --name container2 --net nw -v 192.168.233.1/demo:/demo alpine sh
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm Swarm is using the &lt;code&gt;spread&lt;/code&gt; scheduling strategy by default and ran each container on a separate node:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker ps
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm container1 can ping container2 (even though they are running on different nodes and using hostnames instead of IPs):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it container1 ping container2
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm container1 can create files in the mounted volume:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it container1 touch /demo/fromcontainer1
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm any files created by container1 are accessible to container2:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it container2 ls -l /demo/
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;tips-tricks:e3eed6f67421eff48e81c37460ec6ac3&#34;&gt;Tips &amp;amp; Tricks&lt;/h2&gt;

&lt;p&gt;Get a list of every running VM:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;Get-VM | ? { $_.State -eq &amp;quot;Running&amp;quot; }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Get a list of every Running VM with IpAddress:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;Get-VM | ? { $_.State -eq &amp;quot;Running&amp;quot; } | select Name, Uptime, @{l=&amp;quot;IpAddress&amp;quot;;e={$_.NetworkAdapters[0].IpAddresses[0]}}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Open console to a specific VM&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;$vm = Get-VM consul0
vmconnect $env:COMPUTERNAME $vm.Name -G $vm.Id
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;To print every cluster node with its ip (this could be piped to the &lt;code&gt;Add-Content&lt;/code&gt; cmdlet for the &lt;code&gt;/etc/hosts&lt;/code&gt;):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;&amp;quot;master0&amp;quot;,&amp;quot;node0&amp;quot;,&amp;quot;node1&amp;quot; | % { &amp;quot;$($(Get-VM $_).NetworkAdapters[0].IpAddresses[0]) $_ &amp;quot; }
&lt;/code&gt;&lt;/pre&gt;
</description>
    </item>
    
    <item>
      <title>Linux Container Internals</title>
      <link>http://docker-saigon.github.io/post/Docker-Internals/</link>
      <pubDate>Mon, 29 Feb 2016 13:59:25 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/post/Docker-Internals/</guid>
      <description>

&lt;p&gt;This post was the basis for a joint event with the &lt;a href=&#34;http://www.grokkingengineering.org/&#34;&gt;grokking engineering&lt;/a&gt; community in Saigon.&lt;/p&gt;

&lt;p&gt;The event was centered around DevOps, for our talk Docker Saigon needed to interest an engineering audience with how things tick on the inside of Docker. Audience experience with Docker and Linux operating systems was expected.&lt;/p&gt;

&lt;p&gt;Anyone interested to learn more about Docker, Full free hands-on-labs training events are scheduled for &lt;sup&gt;23&lt;/sup&gt;&amp;frasl;&lt;sub&gt;24&lt;/sub&gt; March. For more details go to &lt;a href=&#34;http://www.meetup.com/Docker-Saigon/&#34;&gt;meetup.com/Docker-Saigon&lt;/a&gt;&lt;/p&gt;

&lt;h2 id=&#34;outline:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Outline&lt;/h2&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;a href=&#34;#overview-of-linux-containers:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Overview of Linux containers&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;What is a Linux container, some history about Linux containers. How do they relate to Package Managers, Configuration Management, &amp;hellip;?&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;a href=&#34;#how:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;How do they work?&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Namespaces, cgroups, Images, Layers &amp;amp; copy-on-write&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;a href=&#34;#overview-of-container-runtimes:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Overview of Container Runtimes&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Past, Current and Future&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;a href=&#34;#docker-api:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Docker API&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;With a focus on Events &amp;amp; Hooks&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;a href=&#34;#container-format-explosion:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Container Format explosion&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Evolution towards a common standard?&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&#34;overview-of-linux-containers:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Overview of Linux containers&lt;/h2&gt;

&lt;p&gt;The target of this section is to give a very short overview of containers from a Linux system perspective, it is not meant as an introduction to users unfamiliar with Docker nor people unfamiliar with Linux systems.&lt;/p&gt;

&lt;p&gt;Developers in Saigon looking to find out more on how they can get started with Docker, are referred to the excellent &lt;a href=&#34;https://docs.docker.com/toolbox/overview/&#34;&gt;Installation Guide (OSX/Windows)&lt;/a&gt; and &lt;a href=&#34;https://docs.docker.com/engine/userguide/&#34;&gt;User Guides&lt;/a&gt; available on the Docker website.&lt;/p&gt;

&lt;p&gt;Anyone wondering if/why Docker matters, is invited to contact the &lt;a href=&#34;http://docker-saigon.github.io/about/&#34;&gt;Docker Saigon&lt;/a&gt; user group (preferably through our &lt;a href=&#34;http://dockersaigon.herokuapp.com/&#34;&gt;Slack auto-invite app&lt;/a&gt;) for discussion.&lt;/p&gt;

&lt;h3 id=&#34;what-is-a-container:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;What is a container?&lt;/h3&gt;

&lt;p&gt;In 4 bullet points:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Containers share the host kernel&lt;/li&gt;
&lt;li&gt;Containers use the kernel ability to group processes for resource control&lt;/li&gt;
&lt;li&gt;Containers ensure isolation through namespaces&lt;/li&gt;
&lt;li&gt;Containers feel like lightweight VMs (lower footprint, faster), but are &lt;strong&gt;not Virtual Machines!&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Components of a container &lt;strong&gt;ecosystem&lt;/strong&gt; include:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Runtime&lt;/li&gt;
&lt;li&gt;Image distribution&lt;/li&gt;
&lt;li&gt;Tooling&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Now&amp;hellip; if you look in the Linux &lt;code&gt;kernel&lt;/code&gt;, there is no such thing as a container&amp;hellip; so what gives?&lt;/p&gt;

&lt;h3 id=&#34;history-of-container-technology:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;History of Container Technology&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;Chroot circa 1982&lt;/li&gt;
&lt;li&gt;FreeBSD Jails circa 2000&lt;/li&gt;
&lt;li&gt;Solaris Zones circa 2004&lt;/li&gt;
&lt;li&gt;Meiosys - MetaClusters with Checkpoint/Restore 2004-05&lt;/li&gt;
&lt;li&gt;Linux OpenVZ circa 2005 (not in mainstream Linux)&lt;/li&gt;
&lt;li&gt;AIX WPARs circa 2007&lt;/li&gt;
&lt;li&gt;LXC circa 2008&lt;/li&gt;
&lt;li&gt;Systemd-nspawn circa 2010-2013&lt;/li&gt;
&lt;li&gt;Docker circa 2013

&lt;ul&gt;
&lt;li&gt;built on &lt;strong&gt;LXC&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;moved to &lt;strong&gt;libcontainer&lt;/strong&gt; (March 2014)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;appC&lt;/strong&gt; (CoreOS) announced (December 2014)&lt;/li&gt;
&lt;li&gt;Open Containers standard for &lt;strong&gt;convergence&lt;/strong&gt; with Docker Announced (June 2015)&lt;/li&gt;
&lt;li&gt;moved to &lt;strong&gt;runC&lt;/strong&gt; (OCF compliant) (July 2015)&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&amp;hellip; many more container formats coming?&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href=&#34;http://www.slideshare.net/jkshah/postgresql-and-linux-containers&#34;&gt;Reference slide deck&lt;/a&gt;&lt;/p&gt;

&lt;h3 id=&#34;how-do-containers-compare-to-package-managers:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;How do containers compare to Package Managers?&lt;/h3&gt;

&lt;p&gt;Why are containers different from package management?&lt;/p&gt;

&lt;p&gt;Packaging into an image is similar to an RPM, but apart from the Linux distributions - software is rarely packaged correctly.&lt;/p&gt;

&lt;p&gt;The big innovation of Docker is that it is a slightly easier to use Package Manager. &lt;strong&gt;Package managers failed us due to shared libraries version differences causing dependency issues&lt;/strong&gt;, packaging shared libraries in an image goes around that.&lt;/p&gt;

&lt;p&gt;What is missing?&lt;/p&gt;

&lt;p&gt;Package managers provide an easy way to find out what is inside the packages. If you are wondering how to handle this with Container Images&amp;hellip;&lt;/p&gt;

&lt;p&gt;See the &lt;a href=&#34;https://github.com/docker/community/blob/master/DockerCon/DockerCon%20EU%202015.md&#34;&gt;Dockercon EU talks&lt;/a&gt; where a system of meta data tags was suggested for image inspection. See &lt;a href=&#34;https://youtu.be/j4SZ1qoR8Hs&#34;&gt;Shipping Manifests, Bill of Lading and Docker Metadata and Containers - Video&lt;/a&gt;&lt;/p&gt;

&lt;h3 id=&#34;how-do-containers-compare-to-configuration-management:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;How do containers compare to Configuration Management?&lt;/h3&gt;

&lt;p&gt;Configuration Management utilities provide the ability to store Infrastructure as code. Popular CM tools include:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://puppetlabs.com/&#34;&gt;Puppet&lt;/a&gt; (Ruby)&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.chef.io/&#34;&gt;Chef&lt;/a&gt; (Ruby)&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.ansible.com/&#34;&gt;Ansible&lt;/a&gt; (Python)&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://saltstack.com/&#34;&gt;SALT&lt;/a&gt; (Python)&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/hashicorp/terraform&#34;&gt;Terraform&lt;/a&gt; (Golang)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Several of the above tools are often still procedurally provisioning the environment as opposed to distributing a package which is self-contained and runs in exactly the same way on the same architectures in every environment (environments may differ in Linux distribution [Ubuntu/redhat/..], scale [local laptop / server cluster/ &amp;hellip;], &amp;hellip;).&lt;/p&gt;

&lt;p&gt;However, it is still &lt;strong&gt;advisable to leverage such a provisioning tool to bootstrap the Docker infrastructure&lt;/strong&gt;, letting the Container Runtime layer take care of the application layer once it is ready.&lt;/p&gt;

&lt;p&gt;In Summary, I believe the following key points drive the adoption of Docker containers:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Docker provides a self-contained image that is exactly that same image running on your laptop vs in the cloud while i.e. Puppet/Chef are procedural scripts that need to rerun to converge your cluster machines. This enables approaches also know as Immutable Infrastructure or Phoenix Deploys.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Docker is really fast, to stand up a container takes very few seconds! There is very little overhead (cpu, memory, io, image footprint, ..) enabling high density (such as running a full stack of containers on your laptop, if you use Puppet/Chef, you&amp;rsquo;d need to create several VM&amp;rsquo;s with a much heavier footprint).&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;The community adopted Docker quickly due to the ease of how to build an image, the &lt;strong&gt;Dockefile DSL&lt;/strong&gt; is very simple and very powerful (you can use pure bash to build the image or you can use load python scripts or anything similar you are familiar with for machine configuration.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;why-docker:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Why Docker?&lt;/h3&gt;

&lt;p&gt;Docker is currently the only ecosystem providing the full package:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Image management&lt;/li&gt;
&lt;li&gt;Resource Isolation&lt;/li&gt;
&lt;li&gt;File System Isolation&lt;/li&gt;
&lt;li&gt;Network Isolation&lt;/li&gt;
&lt;li&gt;Change Management&lt;/li&gt;
&lt;li&gt;Sharing&lt;/li&gt;
&lt;li&gt;Process Management&lt;/li&gt;
&lt;li&gt;Service Discovery (DNS since 1.10)&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;how:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;How?&lt;/h2&gt;

&lt;p&gt;The target of this section is to have a very detailed look into each component in the Linux stack which make Linux Containers possible.&lt;/p&gt;

&lt;p&gt;A higher level overview is available (and was used as a reference) in the &lt;a href=&#34;See also: [Understanding the Docker architecture](https://docs.docker.com/engine/understanding-docker/&#34;&gt;Official Docker documentation&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;UPDATE: See Also &lt;a href=&#34;http://containersummit.io/events/nyc-2016/videos/building-containers-in-pure-bash-and-c&#34;&gt;jfrazelle&amp;rsquo;s talk&lt;/a&gt; @ container summit February 2016&lt;/p&gt;

&lt;h3 id=&#34;kernel-namespaces:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Kernel Namespaces&lt;/h3&gt;

&lt;p&gt;Allow you to create isolation of:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Process trees (PID Namespace)&lt;/li&gt;
&lt;li&gt;Mounts (MNT namespace) &lt;code&gt;wc -l /proc/mounts&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Network (Net namespace) &lt;code&gt;ip addr&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Users / UIDs (User Namespace)&lt;/li&gt;
&lt;li&gt;Hostnames (UTS Namespace) &lt;code&gt;hostname&lt;/code&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Inter Process Communication (IPC Namespace) &lt;code&gt;ipcs&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;Notable example using IPC = PostgreSQL&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;cgroups:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Cgroups&lt;/h3&gt;

&lt;p&gt;Kernel control groups (cgroups) allow you to do accounting on resources used by processes, a little bit of access control on device nodes and other things such as freezing groups of processes.&lt;/p&gt;

&lt;p&gt;Ref DockerCon EU: &lt;a href=&#34;https://www.youtube.com/watch?v=sK5i-N34im8&#34;&gt;jpetazzoni: What are containers made from&lt;/a&gt;, we attempt to provide here a summarized overview of this excellent presentation.&lt;/p&gt;

&lt;p&gt;cgroups consist of one hierarchy (tree) per resource (cpu, memory, &amp;hellip;) . for example:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cpu                      memory
├── batch                ├── 109
│   ├── hadoop           ├── 88 &amp;lt;
│   │   ├── 88 &amp;lt;         ├── 25
│   │   └── 109          ├── 26
└── realtime             └── databases
    ├── nginx                ├── 1008
    │   ├── 25               └── 524
    │   └── 26          
    ├── postgres 
    │   ├── 524  
    └── redis    
        └── 1008 
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;We can create sub groups for each hierarchy, in the example above custom &lt;code&gt;batch&lt;/code&gt; and &lt;code&gt;realtime&lt;/code&gt; sub groups for the &lt;code&gt;cpu&lt;/code&gt; resource were created. Each process will be in 1 node for each resource (&lt;code&gt;pid&lt;/code&gt; 88 is in a node for the memory resource as well as the cpu resource, &amp;hellip;)&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Note: cgroups are system wide&lt;/strong&gt;
The feature is enabled / disabled at boot time and can not be controlled on a per process level&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;A closer look at each resource tree:&lt;/p&gt;

&lt;h4 id=&#34;memory-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Memory cgroup:&lt;/h4&gt;

&lt;p&gt;The Memory resource provides 3 types of functionality: Accounting, Limits &amp;amp; Notifications&lt;/p&gt;

&lt;h5 id=&#34;accounting:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Accounting&lt;/h5&gt;

&lt;p&gt;granularity = memory page size (4kb depending on the architecture)&lt;/p&gt;

&lt;p&gt;2 type of memory pages:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;file pages&lt;/strong&gt;: loaded from disk (important because we know the data is still on disk and can be removed from memory, no need to swap when memory needs to be reclaimed)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;anonymous pages&lt;/strong&gt;: memory that does not correspond to anything on disk, for this type we have to swap out if we want to reclaim this memory&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Some pages can be shared, for example: multiple processes reading from the same files.&lt;/p&gt;

&lt;p&gt;Create 2 pools for all pages:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Active&lt;/li&gt;
&lt;li&gt;Inactive pages - keep often accessed pages into active set.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Each page is accounted to a group, shared pages are only accounted to 1 group and re-allocated to another group if that group goes away.&lt;/p&gt;

&lt;h5 id=&#34;limits:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Limits&lt;/h5&gt;

&lt;p&gt;Each group optionally has 2 type of limits:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Hard limits&lt;/strong&gt;: If the group goes above its hard limit, the group gets killed with an &lt;code&gt;out of memory&lt;/code&gt; error. (which is why it is a good practice to put a single process in a container)&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;strong&gt;Soft limits&lt;/strong&gt;: not enforced&amp;hellip; except when the system starts to run out of memory. The more a process goes over its soft limit, the higher the chance pages get reclaimed for its group&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;There are 3 kinds of memories on which limits can be applied:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;physical memory&lt;/li&gt;
&lt;li&gt;kernel memory: to avoid processes abusing the kernel to allocate memory&lt;/li&gt;
&lt;li&gt;total memory&lt;/li&gt;
&lt;/ul&gt;

&lt;h5 id=&#34;note:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Note&lt;/h5&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;oom-notifier&lt;/p&gt;

&lt;p&gt;Provides a mechanism to give control to a user program to handle a group going over its limits by freezing the processes in the group and notifying user space. At this point the program handling the notification could kill the container, raise the limits or migrate the container.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Overhead:&lt;/p&gt;

&lt;p&gt;Each time the kernel gives or takes a page to or from a process, counters are updated.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;hugetbl-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;HugeTBL cgroup&lt;/h3&gt;

&lt;p&gt;Accounting for usage of huge pages by process group, ignoring for now..&lt;/p&gt;

&lt;h3 id=&#34;cpu-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;CPU cgroup&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;keeps track of user/system CPU time&lt;/li&gt;
&lt;li&gt;keeps track of usage per CPU&lt;/li&gt;

&lt;li&gt;&lt;p&gt;allows to set weights - not limits&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why no limits?&lt;/strong&gt; On an idle host a container with low shares will still be able to use 100% of the CPU&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;cpuset-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;CPUSet cgroup&lt;/h3&gt;

&lt;p&gt;Bind group to specific CPU&lt;/p&gt;

&lt;p&gt;Useful for:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Real Time applications&lt;/li&gt;
&lt;li&gt;NUMA systems with localized memory per CPU&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;blkio-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;BlkIO cgroup&lt;/h3&gt;

&lt;p&gt;Measure &amp;amp; Limit amount of blckIO by group, unless your processes do direct IO - setting limits may give surprising results.&lt;/p&gt;

&lt;h3 id=&#34;net-cls-and-net-prio-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;net_cls and net_prio cgroup&lt;/h3&gt;

&lt;p&gt;Kernel will only tag the traffic and you are responsible for doing traffic control (&lt;code&gt;tc&lt;/code&gt;)&lt;/p&gt;

&lt;h3 id=&#34;devices-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Devices cgroup&lt;/h3&gt;

&lt;p&gt;Controls which group can &lt;strong&gt;read/write access&lt;/strong&gt; devices. Can be used to prevent groups to read/write directly to disk drives, very important for containers&lt;/p&gt;

&lt;p&gt;Typically with containers access to &lt;code&gt;/dev/{tty,zero,random,null}&lt;/code&gt; are allowed and everything else is denied.&lt;/p&gt;

&lt;p&gt;Why &lt;code&gt;/dev/random&lt;/code&gt;? Because if you are generating encryption keys inside a container, you will quickly deplete the entropy unless you read it from the host..&lt;/p&gt;

&lt;p&gt;Other interesting devices for containers:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;code&gt;/dev/net/tun&lt;/code&gt; if you want to do anything with vpn&amp;rsquo;s inside a container without polluting the host&lt;/li&gt;
&lt;li&gt;&lt;code&gt;/dev/fuse&lt;/code&gt; custom filesystems in a container&lt;/li&gt;
&lt;li&gt;&lt;code&gt;/dev/kvm&lt;/code&gt; to allow virtual machines to run inside a container&lt;/li&gt;
&lt;li&gt;&lt;code&gt;/dev/dri&lt;/code&gt; &amp;amp; &lt;code&gt;/dev/video&lt;/code&gt; for GPU access in containers - (see &lt;a href=&#34;https://github.com/NVIDIA/nvidia-docker&#34;&gt;NVIDIA/nvidia-docker&lt;/a&gt;).&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;freezer-cgroup:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Freezer cgroup&lt;/h3&gt;

&lt;p&gt;Freeze a whole group without sending &lt;code&gt;SIGSTOP/SIGCONT&lt;/code&gt; to the group (without interfering in the process).&lt;/p&gt;

&lt;p&gt;Useful for:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;cluster batch scheduling&lt;/li&gt;
&lt;li&gt;process migration - think CRIU&lt;/li&gt;
&lt;li&gt;debugging without affecting prtrace&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;how-to-manage-cgroups-with-systemd:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;How to manage cgroups with Systemd?&lt;/h3&gt;

&lt;p&gt;By setting the &lt;code&gt;ControlGroupAttribute&lt;/code&gt; in the unit file:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;.include /usr/lib/systemd/system/httpd.service

[Service]
ControlGroupAttribute=memory.swappiness 70
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Or &lt;strong&gt;temporarily&lt;/strong&gt; on a running process through:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;systemctl set-property &amp;lt;group&amp;gt; CPUShares=512
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;To show all properties of an existing group:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;systemctl show &amp;lt;group&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The above commands go behind the Docker daemon and may result in unexpected behaviour (i.e.: settings are reverted on container restarts)&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Note: Docker 1.10 introduced the &lt;code&gt;docker update&lt;/code&gt; command to change cgroup limits on the fly for certain attributes:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;Usage: docker update [OPTIONS] CONTAINER [CONTAINER...]

Updates container resource limits

  --blkio-weight=0           Block IO (relative weight), between 10 and 1000
  --cpu-shares=0             CPU shares (relative weight)
  --cpu-period=0             Limit the CPU CFS (Completely Fair Scheduler) period
  --cpu-quota=0              Limit the CPU CFS (Completely Fair Scheduler) quota
  --cpuset-cpus=&amp;quot;&amp;quot;           CPUs in which to allow execution (0-3, 0,1)
  --cpuset-mems=&amp;quot;&amp;quot;           Memory nodes (MEMs) in which to allow execution (0-3, 0,1)
  -m, --memory=&amp;quot;&amp;quot;            Memory limit
  --memory-reservation=&amp;quot;&amp;quot;    Memory soft limit
  --memory-swap=&amp;quot;&amp;quot;           Total memory (memory + swap), &#39;-1&#39; to disable swap
  --kernel-memory=&amp;quot;&amp;quot;         Kernel memory limit: container must be stopped
&lt;/code&gt;&lt;/pre&gt;
&lt;/blockquote&gt;

&lt;h3 id=&#34;how-does-the-kernel-expose-cgroups:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;How does the kernel expose cgroups?&lt;/h3&gt;

&lt;p&gt;Groups are created through a pseudo file system, this is how &lt;code&gt;systemctl&lt;/code&gt; applies your configuration changes:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;mkdir /sys/fs/cgroup/memory/somegroup/subcgroup
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;To move a process, just echo the process id to the special &lt;code&gt;tasks&lt;/code&gt; file in the path of the group:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;echo $PID &amp;gt; /sys/fs/cgroup/.../tasks
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&#34;iptables-networking:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;IPTables (networking)&lt;/h3&gt;

&lt;p&gt;Isolation on the networking level is achieved through the creation of virtual switches in the linux kernel.  Linux Bridge is a kernel module, first introduced in 2.2 kernel (circa 2000). And it is administered using the &lt;code&gt;brctl&lt;/code&gt; command on Linux.&lt;/p&gt;

&lt;p&gt;Linux bridges are heavily used for the setup of Linux virtualization &amp;amp; Software Defined Networking (SDN).&lt;/p&gt;

&lt;p&gt;Network shaping and bandwidth control for Linux containers can be achieved through the use of existing technology such as &lt;a href=&#34;http://www.lartc.org/manpages/tc.txt&#34;&gt;&lt;code&gt;tc&lt;/code&gt;&lt;/a&gt;, I will not attempt to cover this here.&lt;/p&gt;

&lt;p&gt;Below is a quick demo on how Docker uses the Linux Bridge together with IPTables functionality to create isolated Container networks and expose container ports.&lt;/p&gt;

&lt;h4 id=&#34;container-networking-and-port-forwarding:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Container networking and port forwarding&lt;/h4&gt;

&lt;p&gt;We will be using an Alpine image with DNS tools such as &lt;code&gt;dig&lt;/code&gt; and an exposed port:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker build -t so0k/envtest - &amp;lt;&amp;lt; EOF
FROM alpine:latest
MAINTAINER Vincent De Smet &amp;lt;vincent.drl@gmail.com&amp;gt;

RUN apk --update add bind-tools &amp;amp;&amp;amp; rm -rf /var/cache/apk/*
EXPOSE 80
EOF
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Create a test network&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker network create test
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Run 2 containers to demonstrate the resulting Linux configuration:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run --net test -dit --name host1 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker run --net test -dit --name host2 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker ps
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Overview of Linux bridges &amp;amp; IPtable rules:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;brctl show
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;sudo iptables -nvL
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Notice a port has been opened for each port exposed within the container image:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ss -an | grep LISTEN
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;With the default Docker configuration, a userland docker-proxy process is used:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ps -Af | grep proxy
&lt;/code&gt;&lt;/pre&gt;

&lt;blockquote&gt;
&lt;p&gt;be careful if you need to open &lt;a href=&#34;https://github.com/docker/docker/issues/11185&#34;&gt;a lot of ports&amp;hellip;&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;pre&gt;&lt;code&gt;docker run --net test -dit --name prangetest -p 76-85:76-85 so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Memory usage by these proxies:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ps -o pid,%cpu,%mem,sz,vsz,cmd -A --sort -%mem | grep proxy
&lt;/code&gt;&lt;/pre&gt;

&lt;blockquote&gt;
&lt;p&gt;You can &lt;a href=&#34;https://docs.docker.com/engine/userguide/networking/default_network/binding/#bind-container-ports-to-the-host&#34;&gt;disable the userland docker-proxies&lt;/a&gt; forcing Docker to usee the Linux kernel &lt;a href=&#34;http://lwn.net/Articles/347344/&#34;&gt;&amp;lsquo;hairpin&amp;rsquo;&lt;/a&gt; forwarding mode (kernel &amp;gt;=3.6) with alternative &lt;code&gt;iptable&lt;/code&gt; rules. This will improve network performance and memory usage.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;  if you do not use the docker-proxy - your other containers may not be able to connect without hairpin NAT setup&amp;hellip;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Next, demonstrate some simple &lt;strong&gt;&amp;ldquo;Service Discovery&amp;rdquo;&lt;/strong&gt; provided within Docker networks:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it host1 ping host2
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it host2 netstat -an
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it host1 dig host3 +noall +answer +stats
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Notice how the container has been re-configured by Docker for name resolution:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec host2 cat /etc/resolv.conf
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The dns process was injected into the container:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it host2 netstat -an
&lt;/code&gt;&lt;/pre&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;a href=&#34;https://docs.docker.com/engine/userguide/networking/configure-dns/&#34;&gt;more info on configuration of the embedded DNS&lt;/a&gt;. notice we can create container aliases and still create private links between containers where required.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Let&amp;rsquo;s demonstrate the isolation between separate container networks:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker network create test2
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker run --net test2 -dit --name host3 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker run --net test2 -dit --name host4 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Notice another Linux bridge was created for this network:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;brctl show
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;sudo iptables -nvL
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Confirm containers on the first network can not reach containers on the second network. (to really confirm this use the actual container IPs instead of hostnames)&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it host1 ping host4
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Name Resolution was introduced with Docker 1.10 in Q1 2016. The Docker DNS server is not exposed to containers connected to the default Docker bridge for backwards compatibility. (Running containers without the &lt;code&gt;--net&lt;/code&gt; parameter puts them on the default bridge):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -dit --name def-host1 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker run -dit --name def-host2 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;No name resolution:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it def-host1 cat /etc/resolv.conf
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it def-host1 hostname
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it def-host1 cat /etc/hosts
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;If these containers need to find each other, use links, just like it used to be before Docker 1.10&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;docker run -dit --name def-host3 --link def-host1 -P so0k/envtest sh
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;docker exec -it def-host3 cat /etc/hosts
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;If you want to expose additional ports to the public, here is an example for the containers connected to the Default bridge:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; #forward packets from port 8001 on your host to port 8000 on the container
 iptables -t nat -A DOCKER -p tcp --dport 8001 -j DNAT --to-destination ${CONTAINER_IP}:8000
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Let&amp;rsquo;s revise the cgroup setup of all the containers created above as seen earlier:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo systemd-cgls
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&#34;security:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Security&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;AppArmor &amp;amp; &lt;a href=&#34;https://github.com/jfrazelle/bane&#34;&gt;jfrazelle/bane&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://blog.scalock.com/new-docker-security-features-and-what-they-mean-seccomp-profiles&#34;&gt;Seccomp&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;http://linux.die.net/man/7/capabilities&#34;&gt;Capabilities&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Currently no examples provided in this document&amp;hellip; This is subject for further study.&lt;/p&gt;

&lt;h3 id=&#34;types-of-containers:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Types of Containers&lt;/h3&gt;

&lt;p&gt;Given the above constructs, containers may be divided into 3 types as follows:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;System Containers&lt;/strong&gt; share rootfs, PID, network, IPC and UTS with host system but live inside a cgroup.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;strong&gt;Application Containers&lt;/strong&gt; live inside a cgroup and use namespaces (PID, network, IPC, chroot) for isolation from host system&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;strong&gt;Pods&lt;/strong&gt; use namespaces for isolation from host system but create sub groups which share PID, network, IPC and UTS except the rootfs.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;, current Pod implementations on top of &lt;strong&gt;Docker are sub optimal&lt;/strong&gt; as a work around is needed to allow the sub groups to share namespaces (this is implemented through a sleep container which is essentially pid 1). Ideally something like systemd is used as the PID 1 to share the namespaces between the sub groups and chroot to separate the rootfs.&lt;/p&gt;

&lt;p&gt;Reference &lt;a href=&#34;https://www.youtube.com/watch?v=et7BCV_kAUY&#34;&gt;Brandon Philips: Where We Are and Where We Are Going&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h3 id=&#34;images-layers:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Images &amp;amp; Layers&lt;/h3&gt;

&lt;p&gt;Images you create yourself or images created by others are stored in &lt;a href=&#34;https://docs.docker.com/engine/understanding-docker/#inside-docker&#34;&gt;Docker Registries&lt;/a&gt;. These are public or private stores from which you upload or download images. Docker registries are the &lt;strong&gt;distribution&lt;/strong&gt; component of Docker.&lt;/p&gt;

&lt;p&gt;There are 3 choices for use of a Registry:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;A Public Cloud-hosted registry. The &lt;a href=&#34;https://hub.docker.com&#34;&gt;Docker Hub&lt;/a&gt; is the default registry used by the docker client and source of Officially maintained Docker images, however alternatives exists such as &lt;a href=&#34;https://quay.io&#34;&gt;Quay.io&lt;/a&gt;. Limited Private repositories may be created or purchased to enable a quick Docker adoption.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;An On-premise registry, through the commercially offered &lt;a href=&#34;https://docs.docker.com/docker-trusted-registry/overview/&#34;&gt;Trusted Docker Registry&lt;/a&gt;, providing advanced configuration options, Logging, usage and system health metrics and much more&amp;hellip;&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;A Self-hosted registry based on the official Open Source &lt;a href=&#34;https://github.com/docker/distribution&#34;&gt;Docker Registry&lt;/a&gt;. This is a fully functional Registry which you can fully setup by yourself and is the basis on which the Docker Trusted Registry is built, but it does not provide advanced monitoring &amp;amp; access control as well as requires manual maintenance.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Each Docker image references a list of read-only layers that represent filesystem differences. Layers are stacked on top of each other to form a base for a container’s rootfs.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;http://docker-saigon.github.io/img/image-layers.jpg&#34; alt=&#34;&#34; /&gt;&lt;/p&gt;

&lt;p&gt;When the container starts, the Docker engine prepares the rootfs &amp;amp; uses &lt;code&gt;chroot&lt;/code&gt; for the container filesystem isolation - similar to LXC. One big innovation of the Docker engine was the concept of leveraging Copy-On-Write file systems to significantly speed up the preparation of the rootfs.&lt;/p&gt;

&lt;h3 id=&#34;copy-on-write:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Copy-On-Write&lt;/h3&gt;

&lt;p&gt;Before Docker, LXC would create a full copy of FileSystem when creating a container. This would be slow and take up a lot of space&lt;/p&gt;

&lt;p&gt;When &lt;strong&gt;Docker&lt;/strong&gt; creates a &lt;strong&gt;container&lt;/strong&gt;, it &lt;strong&gt;adds a new, thin, writable layer&lt;/strong&gt; on top of the underlying stack of image layers. This layer is often called the “container layer”.&lt;/p&gt;

&lt;p&gt;All changes made to the running container - such as writing new files, modifying existing files, and deleting files - are written to this thin writable container layer.&lt;/p&gt;

&lt;p&gt;by not copying the full rootfs, Docker reduces the amount of space consumed by containers and also reduces the time required to start a container. Below is a diagram showing multiple containers and its &amp;ldquo;container layer&amp;rdquo;, sharing&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;http://docker-saigon.github.io/img/sharing-layers.jpg&#34; alt=&#34;&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Union File Systems provide the following features for storage:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Layering&lt;/li&gt;
&lt;li&gt;Copy-On-Write&lt;/li&gt;
&lt;li&gt;Caching&lt;/li&gt;
&lt;li&gt;Diffing&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;By introducing storage plugins in Docker, many options are available for the Copy-On-Write functionality, for example:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;OverlayFS (CoreOS)&lt;/li&gt;
&lt;li&gt;AUFS (Ubuntu)&lt;/li&gt;
&lt;li&gt;device mapper (RHEL)&lt;/li&gt;
&lt;li&gt;btrfs (next-gen RHEL)&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://news.ycombinator.com/item?id=11125063&#34;&gt;ZFS&lt;/a&gt; (next-gen Ubuntu releases)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;A quick overview on when to choose which, is provided here, full details are on the excellent &lt;a href=&#34;https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/&#34;&gt;Docker Docs&lt;/a&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;AUFS: PaaS-type work&lt;/strong&gt;:&lt;/li&gt;
&lt;/ul&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Pro&lt;/th&gt;
&lt;th&gt;Con&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;stable&lt;/td&gt;
&lt;td&gt;high write activity&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;production ready&lt;/td&gt;
&lt;td&gt;not in mainline kernel&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;good memory use&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;smooth Docker experience&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;Aufs3 default &amp;amp; recommended for Ubuntu currently&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;devicemapper (direct-lvm): Paas-type work&lt;/strong&gt;:&lt;/li&gt;
&lt;/ul&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Pro&lt;/th&gt;
&lt;th&gt;Con&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;stable&lt;/td&gt;
&lt;td&gt;??&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;production ready&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;in mainline kernel&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;smooth Docker experience&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;The most stable configuration for production environments on RHEL, but requires daemon flags to overwrite the defauts.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;devicemapper (loop): Lab testing - this is default in Docker on RHEL, not recommended for production&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Pro&lt;/th&gt;
&lt;th&gt;Con&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;stable&lt;/td&gt;
&lt;td&gt;production&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;in mainline kernel&lt;/td&gt;
&lt;td&gt;performance&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;smooth Docker experience&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;Using a loopback mounted sparse file, additional codepaths and overhead
does not suit I/O heavy workloads.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;OverlayFS: Lab testing&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Pro&lt;/th&gt;
&lt;th&gt;Con&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;stable&lt;/td&gt;
&lt;td&gt;container churn&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;in mainline kernel&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;good memory use&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;Hailed as the future, default on CoreOS, but less mature and thus potentially less stable&amp;hellip;&lt;/p&gt;

&lt;p&gt;but&amp;hellip; ionodes problems if there is high rate of containers creation/removal
so, not good for build pools..&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Btrfs: Build Pools&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Pro&lt;/th&gt;
&lt;th&gt;Con&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;in mainline kernel&lt;/td&gt;
&lt;td&gt;high write activity&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;container churn&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;h2 id=&#34;overview-of-container-runtimes:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Overview of Container Runtimes&lt;/h2&gt;

&lt;p&gt;The target of this section is to play with other container runtimes (some of the past, some alternatives to Docker and some upcoming implementations)&lt;/p&gt;

&lt;h3 id=&#34;lxc:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;LXC&lt;/h3&gt;

&lt;p&gt;Originally used by Docker as backend until libcontainer replaced it.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Installing:&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt;install bridge-utils libvirt lxc lxc-templates
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
&lt;li&gt;Available commands&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt;lxc-attach       lxc-config    lxc-freeze    lxc-start     lxc-usernsexec
lxc-autostart    lxc-console   lxc-info      lxc-stop      lxc-wait
lxc-cgroup       lxc-create    lxc-ls        lxc-top
lxc-checkconfig  lxc-destroy   lxc-monitor   lxc-unfreeze
lxc-clone        lxc-execute   lxc-snapshot  lxc-unshare
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
&lt;li&gt;Quick Guide to use an LXC based container of busybox&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt;wget https://www.busybox.net/downloads/binaries/busybox-x86_64 -o busybox
chmod a+x busybox
PATH=$(pwd):$PATH lxc-create -t busybox -n mycontainer
lxc-start -d -n mycontainer
lxc-console -n mycontainer # (use CTRL-A Q to exit console mode)
lxc-stop -n mycontainer
lxc-destroy -n mycontainer
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Interesting Read: &lt;a href=&#34;https://www.hastexo.com/blogs/florian/2016/02/21/containers-just-because-everyone-else/&#34;&gt;Linux Containers without Docker using OverlayFS &amp;amp; Ansible&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;the LXC project has been working on a more user-friendly Daemon similar to the Docker daemon called &lt;a href=&#34;https://linuxcontainers.org/lxd/introduction/&#34;&gt;LXD&lt;/a&gt; since November 2014.&lt;/p&gt;

&lt;h3 id=&#34;systemd-nspawn:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Systemd-nspawn&lt;/h3&gt;

&lt;p&gt;Originally created to debug the Systemd init system, future versions to be more integrated in the core of the OS (the most low-level and minimal approach to make containers native to the OS).&lt;/p&gt;

&lt;p&gt;CoreOS Toolbox uses systemd-nspawn and CoreOS rkt builds on top of it.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Installing:&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Included with all recent Linux distribution releases..&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Commands available&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt;systemd-analyze       systemd-delta         systemd-nspawn
systemd-ask-password  systemd-detect-virt   systemd-run
systemd-cat           systemd-cgls          systemd-loginctl
systemd-sysv-convert  systemd-cgtop         systemd-machine-id-setup
systemd-coredumpctl   systemd-notify        systemd-tty-ask-password-agent
systemd-inhibit       systemd-stdio-bridge  systemd-tmpfiles
systemdctl            machinectl            hostnamectl         journalctl
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
&lt;li&gt;Quick Guide to a container deployment using systemd-nspawn&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt; # Create an Image (fedora)
 sudo yum -y --releasever=7 --nogpg --installroot=/mycontainers/centos7 \
  --disablerepo=&#39;*&#39; --enablerepo=fedora \
  install systemd passwd yum fedora-release vim-minimal

 # Change the root password in the image (through a shell in the rootfs)
 sudo systemd-nspawn -D /mycontainers/centos7
 passwd
 exit

 # Start the container as if booting into the container image
 sudo systemd-nspawn -bD /mycontainers/centos7 -M mycontainer --bind /from/host:/in/container

 # Get list of containers registered with machine
 machinectl list
 machinectl status mycontainer

 # log into the container
 machinectl login mycontainer

 # or enter the running namespace
 nsenter -m -u -i -n -p -t $PID
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;a href=&#34;https://chimeracoder.github.io/docker-without-docker/#18&#34;&gt;see also - Docker without Docker&lt;/a&gt;
&lt;a href=&#34;https://github.com/Fewbytes/rubber-docker&#34;&gt;see also - Rubber Docker Workshop&lt;/a&gt; - &lt;a href=&#34;https://docs.google.com/presentation/d/10vFQfEUvpf7qYyksNqiy-bAxcy-bvF0OnUElCOtTTRc/edit#slide=id.g1012f66722_0_8&#34;&gt;Prep Slides&lt;/a&gt;&lt;/p&gt;

&lt;h3 id=&#34;runc:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;runC&lt;/h3&gt;

&lt;p&gt;Spun out via &lt;code&gt;libcontainer&lt;/code&gt; from Docker Engine and made OCI compliant, currently core of Docker Engine&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Installing runC&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt;apt-get update &amp;amp;&amp;amp; apt-get install libseccomp2
curl -Lo /usr/local/bin/runc https://github.com/opencontainers/runc/releases/download/v0.0.8/runc-amd64
chmod +x /usr/local/bin/runc
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
&lt;li&gt;Building &amp;amp; Installing&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;On Digital Ocean Ubuntu 14.04 with Docker 1.10 image:&lt;/p&gt;

&lt;p&gt;Build dependencies:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;apt-add-repository -y ppa:evarlast/golang1.4
apt-get update
apt-get install make gcc g++ libc6-dev libseccomp-dev golang
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Procedure&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cd ~ 
git clone https://github.com/opencontainers/runc
cd runc
GOPATH=&amp;quot;$(pwd)&amp;quot; PATH=&amp;quot;$PATH:$GOPATH/bin&amp;quot; make
make install
cd ~
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
&lt;li&gt;Commands available&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt;   checkpoint   pause        
   delete       restore      
   events       resume       
   exec         spec         
   kill         start        
   list         help
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Quick guide to container deployment using &lt;code&gt;runc&lt;/code&gt; &amp;amp; Docker shipping.&lt;/p&gt;

&lt;p&gt;Keep in mind that the Docker Engine does all of the below behind the scenes for us and appreciate the level of comfort it provides.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code&gt; # Download an OCF compliant image (using docker for example)
 docker pull busybox

 # Create busybox/rootfs
 mkdir -p busybox/rootfs

 # Flatten the image layers &amp;amp; copy to rootfs
 tmpcontainer=$(docker create busybox)
 docker export $tmpcontainer | tar -C busybox/rootfs -xf -
 docker rm $tmpcontainer

 # Generate container spec file
 cd busybox/
 runc spec

 # start the container
 runc start test

 # confirm we are now in busybox container
 /bin/busybox
 ps -a 
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Alternatively download image layers from a registry using tianon&amp;rsquo;s script &lt;a href=&#34;https://github.com/docker/docker/blob/v1.10.3/contrib/download-frozen-image-v2.sh&#34;&gt;download-forzen-image-v2.sh&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Or with &lt;code&gt;debootstrap&lt;/code&gt; &amp;hellip;&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cd ~
apt-get install debootstrap
mkdir -p debian_wheezy/rootfs
debootstrap --arch=amd64 wheezy debian_wheezy/rootfs
cd debian_wheezy
runc spec
runc start debian
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;You can use post-start hooks (in &lt;code&gt;config.json&lt;/code&gt;) to call additional binaries/scripts to do things such as set up the virtual bridge and veth pair and iptable rules for your container.&lt;/p&gt;

&lt;h2 id=&#34;docker-api:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Docker API&lt;/h2&gt;

&lt;p&gt;The target of this section is to give an overview of how we might hook in to the various Docker components to leverage some of its notification systems. This is purely to quench the thirst of engineers looking to understand platforms built on top of Docker.&lt;/p&gt;

&lt;p&gt;Many existing platforms already provide orchestration layers and it is advisable to research existing solutions before implementing your own using these events.&lt;/p&gt;

&lt;h3 id=&#34;docker-engine:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Docker Engine&lt;/h3&gt;

&lt;p&gt;&lt;a href=&#34;https://docs.docker.com/engine/reference/api/docker_remote_api/&#34;&gt;Events&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;http://docker-saigon.github.io/img/event_state.png&#34; alt=&#34;&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Use Cases:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;a href=&#34;https://github.com/jwilder/docker-gen&#34;&gt;jwilder/docker-gen&lt;/a&gt; - simple implementation&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;docker-gen is a small utility that uses these APIs and exposes container meta-data to templates. Templates are rendered and an optional notification command can be run to restart the service.&lt;/p&gt;

&lt;p&gt;Using docker-gen, we can generate Nginx config files automatically and reload nginx when they change. The same approach can also be used for docker log management.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Uses: &lt;a href=&#34;https://github.com/fsouza/go-dockerclient&#34;&gt;fsouza/go-dockerclient&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Code: &lt;a href=&#34;https://github.com/jwilder/docker-gen/blob/0.7.0/generator.go#L211-L278&#34;&gt;How this registers Docker client &amp;amp; Passes events to listeners&lt;/a&gt; (Golang)&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;&lt;a href=&#34;https://github.com/ehazlett/interlock&#34;&gt;ehazlett/interlock&lt;/a&gt; - complicated implementation with extensions&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Dynamic, event-driven extension system using Swarm. Extensions include HAProxy and Nginx for dynamic load balancing.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Uses: &lt;a href=&#34;https://github.com/samalba/dockerclient&#34;&gt;samalba/dockerclient&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Code: &lt;a href=&#34;https://github.com/ehazlett/interlock/blob/master/server/server.go#L174-L205&#34;&gt;How this triggers extension reloads using a TTL Cache&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Monitoring with &lt;code&gt;docker stats&lt;/code&gt; and the API behind it? &lt;a href=&#34;https://github.com/google/cadvisor/tree/master/container&#34;&gt;cAdvisor?&lt;/a&gt;
 more about monitoring: &lt;a href=&#34;https://www.youtube.com/watch?v=sxE1vDtkYps&amp;amp;feature=youtu.be&#34;&gt;https://www.youtube.com/watch?v=sxE1vDtkYps&amp;amp;feature=youtu.be&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;docker-registry:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Docker Registry&lt;/h3&gt;

&lt;p&gt;Notifications through webhooks:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;http://docker-saigon.github.io/img/notifications.png&#34; alt=&#34;&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Use Case: &lt;a href=&#34;https://github.com/ehazlett/conduit&#34;&gt;conduit&lt;/a&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Conduit exposes an endpoint that receives webhooks (i.e. from Docker Hub). Upon receiving the hook, Conduit will pull the new image, deploy a new container from the updated image and then remove the original container.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h3 id=&#34;docker-compose:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Docker Compose&lt;/h3&gt;

&lt;p&gt;Via stdout&lt;/p&gt;

&lt;p&gt;See: &lt;a href=&#34;https://docs.docker.com/compose/reference/events/&#34;&gt;Docker Compose events docs&lt;/a&gt; &amp;amp; &lt;a href=&#34;https://github.com/docker/compose/pull/2392&#34;&gt;PR&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Sample gist (from PR):&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; #!/bin/bash
 set -e

 function handle_event() {
     local entry=&amp;quot;$1&amp;quot;
     local action=$(echo $entry | jq -r &#39;.action&#39;)
     local service=$(echo $entry | jq -r &#39;.service&#39;)
     local hook=&amp;quot;./hooks/$service/$action&amp;quot;
     if [ -x &amp;quot;$hook&amp;quot; ]; then
         &amp;quot;$hook&amp;quot; &amp;quot;$entry&amp;quot;
     fi
 }

 docker-compose events --json | (
     while read line; do
         handle_event &amp;quot;$line&amp;quot;
     done
 )
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;container-format-explosion:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Container Format explosion&lt;/h2&gt;

&lt;p&gt;As Docker made containers easy, an ecosystem emerged with an incredible amount of contributions towards the Docker standard.&lt;/p&gt;

&lt;p&gt;However, different opinions exist concerning the exact requirements &amp;amp; responsibilities of each layer within a Container infrastructure with many big players looking to take a piece of the pie - divergence was to be expected.&lt;/p&gt;

&lt;p&gt;The target of this section is to have a look at future and upcoming infrastructures. Out of these, Docker is currently (end 2015) the most mature and the easiest for beginning users to get started with.&lt;/p&gt;

&lt;h3 id=&#34;containerd-alpha-by-docker:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Containerd (Alpha) - By Docker&lt;/h3&gt;

&lt;p&gt;See &lt;a href=&#34;https://containerd.tools/&#34;&gt;containerd.tools&lt;/a&gt; - Spinning out the Docker Daemon into a more advanced and OCI compliant Daemon to control runC.&lt;/p&gt;

&lt;p&gt;Uses &lt;a href=&#34;http://www.grpc.io/&#34;&gt;GRPC&lt;/a&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;A high performance, open source, general RPC framework that puts mobile and HTTP/2 first.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;!-- 
See also?: https://github.com/gengo/grpc-gateway &amp; twitter conv: https://twitter.com/kelseyhightower/status/704914665969733633
The etcd v3 API leverages gRPC for efficient watches and to reduce memory and CPU usage. 

https://twitter.com/hashtag/grpc?src=hash
https://www.eventbrite.com/e/grpc-community-meetup-tickets-22059237774
https://coreos.com/blog/gRPC-protobufs-swagger.html

Nice to see protobuf add initial support for Javascript — works in browsers and in node.js. https://github.com/google/protobuf/releases/tag/v3.0.0-beta-2 …

It should also be noted that you can store full JSON/YAML/XML blobs in etcd and consul. Use a single key named app.conf and call it a day.

Now that rkt has reached 1.0 we need to have a talk about container runtimes vs application management platforms.


--&gt;

&lt;p&gt;Containerd is the plumbing component that will manage containers in a future version of Docker Engine.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;curl -Lo /usr/local/bin/containerd https://github.com/docker/containerd/releases/download/0.0.5/containerd
curl -Lo /usr/local/bin/ctr https://github.com/docker/containerd/releases/download/0.0.5/ctr
curl -Lo /usr/local/bin/containerd-shim https://github.com/docker/containerd/releases/download/0.0.5/containerd-shim
chmod +x /usr/local/bin/{containerd,ctr,containerd-shim}

nohup containerd &amp;gt;/dev/null 2&amp;gt;&amp;amp;1 &amp;amp;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Create redis image using Docker to pull from hub&lt;/p&gt;

&lt;pre&gt;&lt;code&gt; mkdir -p redis/rootfs
 docker pull redis
 tmpredis=$(docker create redis)
 docker export $tmpredis | tar -C redis/rootfs -xf -
 docker rm $tmpredis 
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Prepare the OCI bundle:&lt;/p&gt;

&lt;p&gt;generate &lt;code&gt;config.json&lt;/code&gt;&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;runc spec
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;edit &lt;code&gt;config.json&lt;/code&gt;:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;terminal: false&lt;/li&gt;
&lt;li&gt;populate uid &amp;amp; guid&lt;/li&gt;
&lt;li&gt;set &lt;code&gt;args&lt;/code&gt;: &amp;ldquo;redis-server&amp;rdquo;, &amp;ldquo;&amp;ndash;bind&amp;rdquo;, &amp;ldquo;0.0.0.0&amp;rdquo;&lt;/li&gt;
&lt;li&gt;set correct &lt;code&gt;cwd&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;edit &lt;code&gt;runtime.json&lt;/code&gt;:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;remove &lt;code&gt;network&lt;/code&gt; namespace for now to allow easy connections from localhost for testing&amp;hellip;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;see &lt;a href=&#34;https://github.com/docker/containerd/blob/0.0.5/docs/bundle.md&#34;&gt;&lt;code&gt;config.json&lt;/code&gt; &amp;amp; &lt;code&gt;runtime.json&lt;/code&gt;&lt;/a&gt; from &lt;code&gt;containerd&lt;/code&gt; repository&lt;/p&gt;

&lt;p&gt;Or generate bundles from Docker container definittions with &lt;a href=&#34;https://github.com/jfrazelle/riddler&#34;&gt;jfrazelle/riddler&lt;/a&gt;&lt;/p&gt;

&lt;h3 id=&#34;oci-opencontainers-initiative:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;OCI (OpenContainers Initiative)&lt;/h3&gt;

&lt;p&gt;OCI currently only covers the Runtime&lt;/p&gt;

&lt;p&gt;Doesn&amp;rsquo;t cover how an image is defined, may cover Identity confirmation&lt;/p&gt;

&lt;p&gt;Docker provided tech draft and implementation of OCI in runC (moving libcontainer to runC in the process).&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;OCI? (simple tarballs of the layers+metadata being pushed)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href=&#34;https://www.opencontainers.org/faq#n9&#34;&gt;OCI and link with AppC?&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The individuals behind the appc effort are joining the technical leadership of the OCI, and our intention is to work towards both a common format that is compatible with existing container formats as well as to work on a future spec that combines the best elements of all the existing container efforts.&lt;/p&gt;

&lt;p&gt;See also &lt;a href=&#34;https://coreos.com/blog/making-sense-of-standards/&#34;&gt;CoreOS announcement&lt;/a&gt; &amp;amp; &lt;a href=&#34;https://blog.docker.com/2015/12/progress-report-open-container-initiative/&#34;&gt;Docker announcement&lt;/a&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Creating and maintaining formal specifications (&amp;ldquo;OCI Specifications&amp;rdquo;) for container image formats and runtime, which will allow a compliant container to be portable across all major, compliant operating systems and platforms without artificial technical barriers.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The idea behind OCI was to take the widely deployed runtime and image format implementation from docker and build an open standard in the spirit of appc.&lt;/p&gt;

&lt;h3 id=&#34;appc-by-coreos:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;AppC - By CoreOS&lt;/h3&gt;

&lt;p&gt;&lt;a href=&#34;https://www.youtube.com/watch?v=M6B9BMYciIw&#34;&gt;Ref (June 2015)&lt;/a&gt;
&lt;a href=&#34;https://www.youtube.com/watch?v=et7BCV_kAUY&#34;&gt;Ref (Nov 2015)&lt;/a&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Image format (ACI) and Identity, initially based on Docker image format&lt;/li&gt;
&lt;li&gt;Container Signing&lt;/li&gt;
&lt;li&gt;Discovery mechanism allowing to easily store images and find where the images are (no default registry, no special registry)&lt;/li&gt;
&lt;li&gt;Runtime environment: defined behavior on running the images.&lt;/li&gt;
&lt;li&gt;Tooling: No fancy tooling required. For example, building is easy with command line tools &lt;code&gt;tar&lt;/code&gt;, &lt;code&gt;gzip&lt;/code&gt; and &lt;code&gt;gpg&lt;/code&gt; to sign them&lt;/li&gt;
&lt;/ul&gt;

&lt;h4 id=&#34;image-format:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Image Format&lt;/h4&gt;

&lt;p&gt;ACI (ref AMI) needs to contain all files and metadata needed to execute a given app.&lt;/p&gt;

&lt;p&gt;Notable difference with Docker: ACIs need to specify the mount points&amp;hellip;&lt;/p&gt;

&lt;p&gt;Docker doesn&amp;rsquo;t require you to specify the volumes, it gives flexibility but you can&amp;rsquo;t read the image manifest and know all the required mountpoints.
AppC can force volumes to be defined at run time and fail if they have been omitted.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;rootfs: Same as in Docker image format. Could be an existing system, tarred up. Could be generated with &lt;code&gt;docker build&lt;/code&gt;. Could be build with native system tools Debian/Redhat tools to build full systems in a chroot.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;image manifest: all defined fields defined on the AppC repo. Key points are the concept of labels could be used to define the kernel requirements (Containers share the kernel) and explicit requirement on mountpoint definitions.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Images should be content addressable and share layers.&lt;/p&gt;

&lt;h4 id=&#34;discovery-mechanism:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Discovery Mechanism&lt;/h4&gt;

&lt;p&gt;Translates an ACI name into a download-able image. All ACIs must have a detached signature and do a verification process.&lt;/p&gt;

&lt;p&gt;Could be by convention using a template on the runtime.&lt;/p&gt;

&lt;p&gt;Could be by probing a metadata endpoint to retrieve the discovery mechanism (if you want to use a different protocol, for example bittorrent to distribute your images)&lt;/p&gt;

&lt;h4 id=&#34;runtime-environment:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Runtime Environment&lt;/h4&gt;

&lt;p&gt;AppC defines how ACIs are executed on a host. Fundamental concept is to allow multiple images to be running inside a container and define recovery policy for each image instance within the container.&lt;/p&gt;

&lt;p&gt;Defines:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;FileSystem layout: uses the concept of Pod = ability to compose a collection of containers into a single execution unit.&lt;/li&gt;
&lt;li&gt;Volumes: There is a specific requirement to specify all mountPoints and it is the executer task to do that&lt;/li&gt;
&lt;li&gt;Networking (CNI): network plugins&lt;/li&gt;
&lt;li&gt;Resource Isolators: all cgroups should be defined when executing a container&lt;/li&gt;
&lt;li&gt;Logging: Runtime is responsible for having logs for all the Pods and the containers running in them&lt;/li&gt;
&lt;/ul&gt;

&lt;h4 id=&#34;tooling:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Tooling&lt;/h4&gt;

&lt;p&gt;Providing &lt;code&gt;actool&lt;/code&gt; which allows you to &lt;code&gt;actool build&lt;/code&gt;, &lt;code&gt;actool cat-manifest&lt;/code&gt;, &lt;code&gt;actool validate&lt;/code&gt; &amp;hellip;&lt;/p&gt;

&lt;p&gt;You can build with &lt;code&gt;actool&lt;/code&gt; or the commandline tool listed above&lt;/p&gt;

&lt;p&gt;Runtime may be able to convert Docker images on the fly, or you could use tools such as &lt;code&gt;docker2aci&lt;/code&gt; to convert Docker images, &lt;code&gt;deb2aci&lt;/code&gt; to convert packages &amp;hellip; for you.&lt;/p&gt;

&lt;p&gt;Image content verification, initial naive implementation is to use detached gpg signatures (basically you define what publicly signed hash you expect when downloading things over the internet), which is not ideal.&lt;/p&gt;

&lt;p&gt;Upcoming standard for image verification is The Update Framework (TUF), which is adopted by Docker through Notary. TUF is similar to yum index / apt repo. Essentially a JSON file providing metadata of all images in a registry together with cryptographic metadata for verification once downloaded.&lt;/p&gt;

&lt;h3 id=&#34;existing-implementations-of-appc:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;Existing Implementations of AppC&lt;/h3&gt;

&lt;h4 id=&#34;rkt:cb6baf67dddd3a71c07abfd705dc7d4b&#34;&gt;rkt&lt;/h4&gt;

&lt;p&gt;works in 3 stages:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;stage0: get the image, unpack, verify, ..&lt;/li&gt;
&lt;li&gt;stage1: runs the image (with nspawn) - currently launch systemd init system, processes run directly in process tree under assigned cgroup (not via a daemon).&lt;/li&gt;
&lt;li&gt;stage2: applying the isolators&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href=&#34;https://youtu.be/et7BCV_kAUY?t=1237&#34;&gt;Comparison vs rkt &amp;amp; Docker:&lt;/a&gt;&lt;/p&gt;

&lt;!-- 
## Other Material

 - [Docker Internals](https://docs.google.com/presentation/d/1juVgXiLTM-ZmAmYBOshNwhBABkUqwIxVodHZwq-0eGg)

--&gt;
</description>
    </item>
    
    <item>
      <title>Welcome</title>
      <link>http://docker-saigon.github.io/post/welcome/</link>
      <pubDate>Thu, 08 Oct 2015 12:36:02 +0700</pubDate>
      
      <guid>http://docker-saigon.github.io/post/welcome/</guid>
      <description>&lt;p&gt;This is the first post in Docker Saigon Blog. Let&amp;rsquo;s hope everything works as expected.&lt;/p&gt;

&lt;p&gt;An interesting article will be coming soon!&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>