Model Call Girl in Tilak Nagar Delhi reach out to us at 🔝9953056974🔝
Â
from Docker to Moby and back. what changed ?
1. http://strikr.in/ CC BY NC-SA 4.0
Docker to Moby Project and back
saifi@acm.org
What changed ?
2. http://strikr.in/ CC BY NC-SA 4.0
Why this talk ?
â—Ź Docker architecture
â—Ź Understand the Container landscape
â—Ź Eco-system dynamics
â—Ź Cloud vendor losing leverage
â—Ź Moby in the game
â—Ź Game of Open Standard thrones
â—Ź Tactical Solutions approach
– Power user is the System builder
â—Ź
3. http://strikr.in/ CC BY NC-SA 4.0
Goal of this talk
â—Ź What should you do to succeed with containers
in a post-Docker world ?
4. http://strikr.in/ CC BY NC-SA 4.0
Application
container Services
Operating System
OS Services
container Runtime
container Engine
11. http://strikr.in/ CC BY NC-SA 4.0
â—Ź Properties of cloud native systems
– Container Packaged
– Dynamically managed
– Micro-services oriented
12. http://strikr.in/ CC BY NC-SA 4.0
â—Ź Goals to Achieve
– Standardized interfaces between
subsystems.
– A standard systems architecture describing
the relationship between parts
– At least one standard reference
implementation of each sub-system.
– Extensible architecture that end users can
extend, replace or change behavior in
every layer of the stack for their purposes.
13. http://strikr.in/ CC BY NC-SA 4.0
â—Ź Container packaged
– Running applications and processes in
software containers as an isolated unit of
application deployment, and as a mechanism
to achieve high levels of resource isolation.
– Benefit
â—Ź Improves overall developer experience
â—Ź code and component reuse
â—Ź simplify operations for cloud native app
14. http://strikr.in/ CC BY NC-SA 4.0
â—Ź Dynamically managed
– actively scheduled and actively managed by
a central orchestrating process.
– Benefits
â—Ź Improve machine efficiency and resource
utilization
â—Ź Reduce the cost associated with
maintenance and operations
15. http://strikr.in/ CC BY NC-SA 4.0
â—Ź Micro-services oriented
– Loosely coupled with dependencies explicitly
described (ie. service end-points)
– Benefits
â—Ź Increase the overall agility and
maintainability of applications.
16. http://strikr.in/ CC BY NC-SA 4.0
Virtualization vs Containerization
â—Ź VM world
– Hypervisor
â—Ź Container world
– Container engine
17. http://strikr.in/ CC BY NC-SA 4.0
Solutions Approach
â—Ź Immutable
infrastructure is the
goal
â—Ź Containers First
â—Ź Data volume
containers
â—Ź Resilient Micro-
services
â—Ź Fine-tuned runtime to
support it
â—Ź Scripted automated
â—Ź Pipelines
â—Ź DevOps
– coInt
– coDep
– coMon
– coSec
– coCmp
Gold standard: It's your runtime with your artifact that you deploy to any 'cloud' vendor.
19. http://strikr.in/ CC BY NC-SA 4.0
containerD
â—Ź Core container runtime
â—Ź The daemon that controls runC
20. http://strikr.in/ CC BY NC-SA 4.0
ContainerD
â—Ź Architecture
– designed to be embedded into a larger
system, rather than being used directly by
developers or end-users.
â—Ź daemon
– exposes gRPC API over a local UNIX socket.
21. http://strikr.in/ CC BY NC-SA 4.0
containerD
â—Ź API design
– low-level one designed for higher layers to
wrap and extend.
â—Ź CLI
– a barebone CLI (ctr) designed for
development and debugging purpose.
â—Ź interface with runC
– uses runC to run containers according to the
OCI specification.
22. http://strikr.in/ CC BY NC-SA 4.0
the promise of containerD 1.0
â—Ź Container execution and supervision
â—Ź Image distribution
â—Ź Network Interfaces Management
â—Ź Local storage
â—Ź Native plumbing level API
â—Ź Full OCI support, including the extended OCI
image specification
Windows – Linux parity
26. http://strikr.in/ CC BY NC-SA 4.0
runC
â—Ź universal runtime for OS Containers
â—Ź CLI tool for spawning and running containers
according to the OCI specification.
27. http://strikr.in/ CC BY NC-SA 4.0
runC
â—Ź a CLI tool for spawning and running containers
according to the OCI specification.
â—Ź runC
– Depends on runtime-spec repo
– Supports Linux platform only
– Must be built with Go 1.6+
– Executes build tags for features
– Linux kernel 4.3+
– Uses 'vndr' for dependency management
28. http://strikr.in/ CC BY NC-SA 4.0
RunC for container lifecycle
cd /mycontainer
runc create mycontainerid
# view the container is created and in the "created" state
runc list
# start the process inside the container
runc start mycontainerid
# after 5 seconds view that the container has exited and is now in the
stopped state
runc list
# now delete the container
runc delete mycontainerid
29. http://strikr.in/ CC BY NC-SA 4.0
Rootless containers
â—Ź runc has the ability to run containers without
root privileges. This is referred to as rootless
â—Ź some parameters need to be passed to runc in
order to run rootless containers.
â—Ź
30. http://strikr.in/ CC BY NC-SA 4.0
Rootless containers
â—Ź mkdir ~/mycontainer
â—Ź cd ~/mycontainer
â—Ź mkdir rootfs
â—Ź docker export $(docker create busybox) | tar -C
rootfs -xvf -
● runc spec –rootless
â—Ź runc --root /tmp/runc run mycontainerid
31. http://strikr.in/ CC BY NC-SA 4.0
moby
â—Ź Move away from monolithic docker
â—Ź an open framework to assemble specialized
container systems.
â—Ź
35. http://strikr.in/ CC BY NC-SA 4.0
Moby as it stands today
â—Ź https://github.com/moby/moby/issues/32871
â—Ź Move the monolith
https://github.com/moby/moby/pull/33022
â—Ź Discussions at
https://forums.mobyproject.org/t/topic-find-a-good-an
â—Ź
36. http://strikr.in/ CC BY NC-SA 4.0
Moby code org .. issues
â—Ź we have the code of the legacy "docker engine"
(a monolith to be split out in multiple
components) at the root and it's very confusing.
â—Ź api
– cannot be moved yet, because it's used
externally
â—Ź client
– cannot be moved yet, because it's used
externally
37. http://strikr.in/ CC BY NC-SA 4.0
Moby code org
â—Ź Moby
– moby tool
â—Ź Monolith
– the code where "docker engine" lives, to be
split out and eventually will disappear
â—Ź Pkg
– cannot be moved yet, because it's used
externally
â—Ź Vendor
– vendoring
48. http://strikr.in/ CC BY NC-SA 4.0
#15629
â—Ź Docker with devicemapper driver and dm.thinpooldev lead to
data loss
â—Ź https://github.com/moby/moby/issues/15629
â—Ź Steps to reproduce
– Create lvm thin pool using lvcreate or lvconvert
– Pass lvm thin pool for exclusive use by docker
– Run docker daemon with devicemapper driver and
dm.thinpooldev
– Import volume to the docker or create new container
– Try to extend or make any operation on lvm thin pool using
lvm tools like lvextend thin data
â—Ź Issue: Only one entity can create thin devices in pool. Either
lvm or docker.
49. http://strikr.in/ CC BY NC-SA 4.0
Solution
â—Ź configure direct-lvm mode for production
â—Ź https://docs.docker.com/v1.10/engine/userguide/stor
â—Ź Steps
58. http://strikr.in/ CC BY NC-SA 4.0
Notary
â—Ź Based on The Update Framework (TUF)
â—Ź publishers can sign their content offline using
keys kept highly secure
â—Ź Software update systems are
– Application updaters
– Library package managers
– System package managers
â—Ź TUF is a spec and library for secure software
update systems
61. http://strikr.in/ CC BY NC-SA 4.0
SwarmKit
â—Ź Swarmkit modelled after containerD
– SwarmD
– SwarmCtl
â—Ź Protobuf3 with grpc over HTTP/2.0
â—Ź Swarmkit masters and Raft leaders are mutual
exclusion
â—Ź Master promotion /demotion can be done on
any node manually