From e0c99c9910f367003ccff7e60a8b67d6281356c1 Mon Sep 17 00:00:00 2001 From: Aaron Weitekamp Date: Dec 15 2015 19:41:06 +0000 Subject: Merge pull request #36 from aweiteka/plan add planning section --- diff --git a/Makefile b/Makefile index 07c9460..93ec019 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,7 @@ SHELL := /bin/bash -LABS=overview/overview.adoc \ +LABS=index.asciidoc \ + overview/overview.adoc \ + plan/index.adoc \ create/general_guidelines.adoc \ create/references.adoc diff --git a/containers.dict b/containers.dict index 06271ca..8797d41 100644 --- a/containers.dict +++ b/containers.dict @@ -1,12 +1,17 @@ personal_ws-1.1 en 37 adoc +Amazon asciidoc +AWS +bindmount catalogize CentOS centosplus chown chmod +CLI CMD +deployable devel dockerfile Dockerfile @@ -18,8 +23,10 @@ entrypoint ENTRYPOINT ENV gettext +git GitHub HTTPS +init io IP iproute @@ -27,6 +34,10 @@ LABELs leveloffset lifecycle metadata +microservice +Microservice +microservices +Microservices middleware Middleware mongodb @@ -39,18 +50,24 @@ nss og openshift OpenShift +OpenStack +optimizations py redhat REPO RHEL rhel rpmkeys +runtime rwx scl setopt setuptools +sosreport spc +SPCs sti +strace sudo systemd tbd @@ -59,7 +76,9 @@ TCP toc toclevels tsflags +uptime uri usr utils +workflows zdover diff --git a/index.asciidoc b/index.asciidoc index 3bed8a3..50cbcf1 100644 --- a/index.asciidoc +++ b/index.asciidoc @@ -10,7 +10,7 @@ include::overview/overview.adoc[] // Plan -//include::plan/ +include::plan/index.adoc[] // Create include::create/general_guidelines.adoc[] diff --git a/overview/overview.adoc b/overview/overview.adoc index d816699..e0364e9 100644 --- a/overview/overview.adoc +++ b/overview/overview.adoc @@ -7,26 +7,11 @@ Container technology is a popular packaging method for developers and system administrators to build, ship and run distributed applications. Production use of image-based container technology requires a disciplined approach to development. This document provides guidance and recommendations for creating and managing image to control application lifecycle. -Application Planning +In link:#planning[*Application Planning*] we discuss how to deconstruct applications into microservices, common types of images and how planning must consider the target deployment platforms. -- [ ] Deconstructing Applications -- [ ] Types of Images -- [ ] Deployment Platforms +link:#general_guidelines[*Creating Images*] discusses the details about how to work with Dockerfiles, best practices, tips and tricks, and tools available to developers. -Creating Images +The *Build* section discusses the importance of automation in building, testing and maintaining images. We discuss ideal workflows, how to plan a test environment, types of testing and image certification. -- [ ] Source Repositories -- [ ] Dockerfile Best Practices -- [ ] Tools - -Build a Pipeline - -- [ ] Workflow Overview -- [ ] Build environment -- [ ] Automation Triggers -- [ ] Planning a Test Environment -- [ ] Types of Testing -- [ ] Certification - -Delivery +Finally, *Delivery* covers how to get images and updates to the end-users, whether that's inside an enterprise or public infrastructure. A key consideration is access control. diff --git a/plan/index.adoc b/plan/index.adoc new file mode 100644 index 0000000..9470968 --- /dev/null +++ b/plan/index.adoc @@ -0,0 +1,53 @@ +// vim: set syntax=asciidoc: +[[planning]] += Application Planning +:data-uri: +:icons: +:homepage https://github.com/projectatomic/container-best-practices: + +Careful planning is important when working with container technology. + +== Application Classes + +There are many different kinds of applications that may be candidates for porting to container technology. + +=== System Services + +System services are a special kind of application. These are drivers or system agents that extend the functionality of the host system. They are typically single-container images. They are typically run using automation during a start-up script like cloud-init or a configuration management system. System service containers require special runtime configuration to enable the appropriate level of privilege to modify the host system. They are commonly referred as Super Privileged Containers (SPCs). They utilize the benefits of container packaging but not separation. + +=== Client Tools + +Client Tools applications are another special kind of application. These are used by end-users who do not wish to install a client using traditional packaging such as RPM. Container technology enables an end-user to add a client to their workstation without modifying the operating system. + +There are an endless number of potential clients for this class of applications. A few examples include remote clients such as OpenStack or Amazon Web Services (AWS) client tools. An extension of the model is vagrant-like development environment where a tool set for a given project is packaged. For example, Red Hat's link:https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/getting-started-with-containers/#using_the_atomic_tools_container_image[rhel-tools image] is a toolkit for interacting with an immutable Atomic host system. It includes git, strace and sosreport, for example. + +Two important architectural decisions should be considered for client container images. + +. How does the end-user interact with the container? Will they use them like traditional command line interface (CLI) tools? Or will they enter the container environment as a shell, perform some commands, then exit. The entrypoint command chosen for the container will determine the default behavior. +. Will end-users will need access to files on the host system? If so, will the default behavior bindmount the current working directory or a user-specified directory? + +=== Service Components + +Service components are applications that an application developer integrates with. Databases are common examples. A database is typically a component of a larger application. + +The challenge of porting service components to container technology is optimizing integration. Will the application developer be able to configure the service to their needs? Will the application developer have sufficient documentation to install, configure and secure the service being integrated? + +=== Microservice Applications + +The microservice architecture is particularly well-suited to container technology. Martin Fowler describes microservice applications as "suites of independently deployable services."footnote:[Martin Fowler, http://martinfowler.com/articles/microservices.html] Well-designed microservice applications have a clean separation of code, configuration and data. + +Planning is especially critical for microservice applications because they are especially challenging to port to container technology. The planning phase must include experts who understand the application's architecture and service topology, performance characteristics, configuration and dependencies such as networking and storage. While many applications can be ported to container technology without modification there are sometimes optimizations that should be made regarding configuration, storage, installation or service architecture. + +== Deconstructing Microservice Applications + +The process of deconstructing applications varies widely depending on the complexity and architecture of the application. Consider the following steps as a guide to a generalized process. + +. Identify the components that will be broken down into microservices. These typically map to a container images. +. Identify how the services will communicate. How are REST or message bus interfaces authenticated? +. Identify how data will be accessed by the services. Which services need read/write access to the storage? +. Create a service topology drawing to represent the components, lines of communication and storage. This will guide the development work, configuration discussions, debugging and potentially become part of the end-user documentation. +. Identify how the services will be configured, which services need to share configuration and how these services might be deployed in a highly available configuration. + +== Deployment Platform Considerations + +Preparing applications for production distribution and deployment must carefully consider the supported deployment platforms. Production services require high uptime, injection of private or sensitive data, storage integration and configuration control. The deployment platform determines methods for load balancing, scheduling and upgrading. A platform that does not provide these services requires additional work when developing the container packaging.