1. 1. Creating Developer- Friendly Containers (with some help from chaperone) garyw@blueseastech.com http://garywiz.com slideshare: http://goo.gl/7UmU5B
2. 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. 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
4. 4. Our Perspective
5. 5. Micro-service Applications Legacy Applications Primordial Applications Enterprise Architectures Docker Adoption Focus
6. 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. 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. 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. 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. 10. Docker is not designed for developers. Problem
11. 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.
12. 12. coders Defining, managing, scheduling, deploying, requirements changes, management changes, technology changes, goal changes.
13. 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. 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. 15. How could we best assist people at making the transition? We built a technology solution.
16. 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. 17. Existing process management solutions are not designed with containers in mind. Problem
18. 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. 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. 20. Infrastr ucture Apps and C onfigur ation Persist ent Da ta Application components
21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Development Model Only infrastructure resides in container. Step 2: Create and start a new development directory ./chaplocal myappdir
32. 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. 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. 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. 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. 36. Resources
37. 37. The Sample Application docker run -i -t --rm -p 80:8080 -p 443:8443chapdev/chaperone-lemp /bin/bash
38. 38. Dockerfile Quick Start http://garywiz.github.io/chaperone/guide/chap-docker-simple.html
39. 39. Image Family https://github.com/garywiz/chaperone-docker
40. 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. 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/