The document discusses creating developer-friendly containers using Chaperone and the chaperone-baseimage family. Chaperone is a process manager that provides services like logging, cron jobs, and orderly shutdown within containers. The chaperone-baseimage images use Chaperone to provide three personalities for containers: closed, attached-data, and development. This allows developers to have a consistent environment to develop applications without understanding container internals. The development model mounts the container's infrastructure to the developer's local directory for easy editing of code and data outside the container.
2. Hello
Background (the boring stuff)
Developer needs as we see it
Our solution (think of it as a case-study)
Q&A or whatever
3. We provide systems architecture and
engineering consulting to enterprise, small-
business development teams and start-ups.
Docker is transforming the way we think about
architecture and deployment.
This is how we’ve been helping clients
transition toward a robust container
environment…
6. Managing and Deploying Containers
Solid Advice and Emerging Best Practices
Technologies / Techniques / Case-Studies
Best Practices for Application Developers
“One Process Per Container”
Advice new adopters discover online…
7. Best Practices for Application Developers
“One Process Per Container”
Futile attempts to split complex existing applications
into separate container processes.
Redesign of existing systems using Micro-Services
architecture.
Attempts to do self-scripted container startup without
DevOps skill-set.
Attempts to create a mini-VM environment with
Supervisor, S6, runit, or even systemd.
and rarely…
8. “Your architecture is really outdated.
Nobody builds new systems like this
anymore, and considering some of your
code is 5 to 10 years old, we suggest
you rebuild everything from the ground-
up.”
So, this message hasn’t been getting
through very well…
9. “Containers can save you time and
money…
You can have greater application
consistency and stability for existing
development while paving the way for a
transition to better architectures.”
This works better…
11. Good Developers…
• Benefit from uninterrupted focus for their most
productive activities.
• Usually spend years mastering the language and
tools they use to achieve maximum productivity.
• Resist change because they know that goals will not
be met if they change toolsets without ample
consideration, or at the wrong time.
13. coders
Defining, managing, scheduling, deploying,
requirements changes, management changes,
technology changes, goal changes.
The most successful
strategies will
relieve pressure
rather than
add new skillsets
to the requirements.
14. Making things easier
means…
• A documented, well-managed non-root development
environment. Application code and related services
should never run as root.
• An environment where system services are properly
configured.
• Constraints to assure that application practices
which violate production requirements trigger errors.
15. How could we best assist
people at making the
transition?
We built a technology solution.
16. Goals
• Create a developer-friendly environment for people who spend
99% of their time coding applications.
• Assure developers can configure and develop their applications
without having to modify or understand container internals.
• “Scale down” necessary services like logging, cron, error
recovery, process management to assure all supporting services
present a properly-configured container environment.
• Create a consistent runtime model so that DevOps teams can
rely upon consistent requirements when developing, assembling,
testing and deploying applications using tools like compose, etc..
18. Chaperone
• Single PID 1 process that provides…
1. dependency-based startup, cron scheduling, script execution,
systemd notify protocol, orderly shutdown, zombie harvesting,
and…
2. syslog emulation, /dev/log capture and redirection
3. uid/gid mapping for attached storage
4. rich full-featured service, logging and environment configuration
• A general-purpose tool. Simple YAML configuration in a
single file, or can be as complex as desired.
• Open-source, well-documented.
19. chaperone-baseimage family
(at https://registry.hub.docker.com/repos/chapdev/)
• Collection of images which use Chaperone to establish
a robust development and deployment model.
• All images support three “personalities”:
• closed: applications and data reside inside the
container
• attached-data: applications and infrastructure reside
inside the container, data is external
• development: infrastructure is inside the container,
data and applications are external (usually in
developer’s home directory).
29. Development Model
Only infrastructure resides
in container.
docker run -i --rm chapdev/chaperone-lemp --task get-chaplocal | sh
Step 1:
Extract ‘chaplocal’ utility
from the desired container
30. Development Model
Only infrastructure resides
in container.
docker run -i --rm chapdev/chaperone-lemp --task get-chaplocal | sh
Step 1:
Extract ‘chaplocal’ utility
from the desired container
$ docker run -i --rm chapdev/chaperone-lemp --task get-chaplocal | sh
The 'chaplocal' script is ready to use. Here is the help you get if you type
./chaplocal
at the command line...
Usage: chaplocal [-d] local-apps-dir [image-name]
Runs the specified chaperone image and uses local-apps-dir for the apps
directory. Creates a script in local-apps-dir called run.sh so you can
run an interactive (default) or daemon instance.
Will run all container processes under the current user account with the
local drive mounted as a shared volume in the container.
If not specified, the the image 'chapdev/chaperone-lemp' will be used.
$
32. Development Model
Only infrastructure resides
in container.
Step 2:
Create and start a new
development directory
./chaplocal myappdir
./chaplocal myappdir
Extracting /apps default directory into /home/garyw/meetup/myappdir ...
You can customize the contents of /home/garyw/meetup/myappdir to tailor it for your application,
then use it as a template for your production image.
Executing run.sh within /home/garyw/meetup/myappdir ...
Port 8080 available at docker1:8080 ...
Port 8443 available at docker1:8443 ...
Jul 19 14:06:55 c8056b4d6b73 chaperone[1]: system wll be killed when '/bin/bash' exits
Now running inside container. Directory is: /home/garyw/meetup/myappdir
The default 'nginx' site is running at http://docker1:8080/
garyw@c8056b4d6b73:~/meetup/myappdir$
Processes run as… In directory… With data here…
—create-user user mounted: /home/garyw/apps mounted: /home/garyw/apps/var
33. Development Model
Only infrastructure resides
in container.
apps directory contents on
in developers’s home
directory
Processes run as… In directory… With data here…
—create-user user mounted: /home/garyw/apps mounted: /home/garyw/apps/var
garyw@c8056b4d6b73:~/meetup/myappdir$ ls -l
total 44
-rw-r--r-- 1 garyw garyw 328 Jul 19 14:06 bash.bashrc
drwxr-sr-x 2 garyw garyw 4096 Jul 19 13:24 bin
drwxr-sr-x 2 garyw garyw 4096 Jul 19 14:06 build
-rwxr-xr-x 1 garyw garyw 589 Jul 19 14:06 build.sh
drwxr-sr-x 2 garyw garyw 4096 Jul 19 13:24 chaperone.d
drwxr-sr-x 4 garyw garyw 4096 Jul 19 13:24 etc
-rw-r--r-- 1 garyw garyw 1016 Jun 10 03:53 README
-rwxr-xr-x 1 garyw garyw 1775 Jul 19 14:06 run.sh
drwxr-sr-x 2 garyw garyw 4096 Jul 19 13:24 startup.d
drwxr-sr-x 7 garyw garyw 4096 Jul 19 14:06 var
drwxr-sr-x 4 garyw garyw 4096 Jun 28 04:00 www
garyw@c8056b4d6b73:~/meetup/myappdir$ exit
34. Processes
run as…
In directory…
With data
here…
closed “runapps” /apps /apps/var
attached data
externally-specified
UID/GID
/apps
/apps/var
(attached)
developer
externally specified
UID/GID
/home/xxx/apps
(attached)
/home/xxx/apps/var
(attached)
Summary of container models
supported by chaperone-baseimage
and any derivatives
35. The result…
• Developers have a single, consistent development
model where…
• They control, configure, and add all services and
applications they need under their own user account
in their own development directory, and…
• Resulting images can be run using all three models:
closed, attached-data, and for additional
development.
40. Warning!
• In use in production, but just released this month as
open-source. Though well-tested and documented,
it is still a work in progress.
• Chaperone itself is platform neutral, but tools for
creating the development environment may need
minor tweaking for Kitematic or boot2docker
systems. Recommended environment is Linux host.
• Images have been tested under CentOS but there is
no CentOS base image yet (coming soon).
41. Q&A ++
me: http://garywiz.com
chaperone: https://github.com/garywiz/chaperone
documentation: http://garywiz.github.io/chaperone
chaperone-baseimage and friends:
https://github.com/garywiz/chaperone-docker
on Docker Hub:
https://registry.hub.docker.com/repos/chapdev/
Hinweis der Redaktion
End with: “How can we overcome this? First, let’s consider developers themselves…”
These are often at odds with the reality of organisations and businesses…
End with: HOW?
End with: “SO WE’LL QUICKLY SWITCH TO BEING TECHNICAL…”