1. Creating Developer- Friendly Containers (with some help from
chaperone) [email protected] http://garywiz.com slideshare:
http://goo.gl/7UmU5B
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 weve 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 hasnt 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
10. Docker is not designed for developers. Problem
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..
17. Existing process management solutions are not designed with
containers in mind. Problem
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 developers home
directory).
20. Infrastr ucture Apps and C onfigur ation Persist ent Da ta
Application components
21. Infrastr ucture Apps and C onfigur ation Persist ent Da ta
Closed Model Entire application exists within the same container.
Ideal: when container data is truly ephemeral. for model
deployments or demonstrations.
22. Closed Model Entire application exists within the same
container. docker run -i -t --rm -p 80:8080 -p
443:8443chapdev/chaperone-lemp /bin/bash
23. Closed Model Entire application exists within the same
container. docker run -i -t --rm -p 80:8080 -p
443:8443chapdev/chaperone-lemp /bin/bash Jul 19 13:42:26
baccbaa91e5a chaperone[1]: system wll be killed when '/bin/bash'
exits runapps@baccbaa91e5a:/$ cps USER PID PPID PGID VSZ RSS STAT
COMMAND root 1 0 1 69448 16532 Ss [chaperone] /bin/bash runapps 55
1 55 426920 51240 Sl /usr/sbin/mysqld
--defaults-file=/apps/etc/mysql/my runapps 75 1 75 228956 5104 Ss
php-fpm: master process (/apps/etc/php-fpm.conf) runapps 76 75 75
228956 4524 S _ php-fpm: pool www runapps 77 75 75 228956 4516 S _
php-fpm: pool www runapps 83 1 83 82116 1368 Ss nginx: master
process /usr/sbin/nginx -c /apps/var/e runapps 84 83 83 82436 1660
S _ nginx: worker process runapps 85 83 83 82436 1660 S _ nginx:
worker process runapps 86 83 83 82436 1660 S _ nginx: worker
process runapps 87 83 83 82436 1660 S _ nginx: worker process
runapps 88 1 88 21284 1988 S /bin/bash runapps 91 88 91 21088 1544
S+ _ /bin/bash /apps/bin/cps runapps 92 91 91 18680 1280 R+ _ ps
--forest -weo runapps@baccbaa91e5a:/$ Processes run as In directory
With data here runapps /apps /apps/var
24. Infrastru cture Apps and Co nfigurati on Persiste nt Data
Attached-Data Model Data exists on attached storage. Ideal for most
production deployments.
25. Attached-Data Model Data exists on attached storage. mkdir
lemp-var docker run -i -t --rm -v /home/garyw/lemp-var:/apps/var-p
80:8080 -p 443:8443chapdev/chaperone-lemp --create garyw/1021:1021
/bin/bash
26. Attached-Data Model Data exists on attached storage.
myuid=`id -u` mygid=`id -g` mkdir lemp-var docker run -i -t --rm -v
`pwd`/lemp-var:/apps/var-p 80:8080 -p
443:8443chapdev/chaperone-lemp --create $USER/$myuid:$mygid
/bin/bash
27. Attached-Data Model Data exists on attached storage. Jul 19
13:50:21 e75923c8b6b0 chaperone[1]: system wll be killed when
'/bin/bash' exits garyw@e75923c8b6b0:/$ cps cps USER PID PPID PGID
VSZ RSS STAT COMMAND root 1 0 1 69464 16544 Ss [chaperone]
/bin/bash garyw 77 1 77 426920 51148 Sl /usr/sbin/mysqld
--defaults-file=/apps/etc/mysql/my.cnf - garyw 97 1 97 228956 5104
Ss php-fpm: master process (/apps/etc/php-fpm.conf) garyw 98 97 97
228956 4524 S _ php-fpm: pool www garyw 99 97 97 228956 4516 S _
php-fpm: pool www garyw 105 1 105 82116 1376 Ss nginx: master
process /usr/sbin/nginx -c /apps/var/etc/ng garyw 106 105 105 82436
1672 S _ nginx: worker process garyw 107 105 105 82436 1672 S _
nginx: worker process garyw 108 105 105 82436 1672 S _ nginx:
worker process garyw 109 105 105 82436 1672 S _ nginx: worker
process garyw 110 1 110 21280 1988 S /bin/bash garyw 113 110 113
21088 1544 S+ _ /bin/bash /apps/bin/cps garyw 114 113 113 18680
1284 R+ _ ps --forest -weo user,pid,ppid,pgid,vsz,
garyw@e75923c8b6b0:/$ Processes run as In directory With data here
create-user user /apps mounted: /apps/var myuid=`id -u` mygid=`id
-g` mkdir lemp-var docker run -i -t --rm -v
`pwd`/lemp-var:/apps/var-p 80:8080 -p
443:8443chapdev/chaperone-lemp --create $USER/$myuid:$mygid
/bin/bash
28. Infrastr ucture Apps and Co nfigurati on Persiste nt Data
Development Model Only infrastructure resides in container. Ideal
for: development rapid prototyping experimentation and
exploring
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. $
31. Development Model Only infrastructure resides in container.
Step 2: Create and start a new development directory ./chaplocal
myappdir
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 developerss 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.
36. Resources
37. The Sample Application docker run -i -t --rm -p 80:8080 -p
443:8443chapdev/chaperone-lemp /bin/bash
39. Image Family
https://github.com/garywiz/chaperone-docker
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/