From c430abe147f732b63043d9fd4744e59fbd36c649 Mon Sep 17 00:00:00 2001 From: Brent Baude Date: Feb 25 2016 16:59:52 +0000 Subject: characteristics: Add characterics section The characteristics section provides a way to highlight hurdles when containerizing applications. These characteristics are used to educate developers of these problems and provide academic solutions to them. --- diff --git a/creating/creating_index.adoc b/creating/creating_index.adoc index 3745b49..6671c19 100644 --- a/creating/creating_index.adoc +++ b/creating/creating_index.adoc @@ -26,6 +26,21 @@ recommendations. === Choosing base image + +==== Updating Software supplied by Base Image + +Avoid updating software supplied by base image unless necessary. Base images themselves are meant to be updated +on a regular basis by the supplier and provide software that has been tested for a particular environment. + +Also, updating base-image software in layered images can introduce unexpected problems or bring in unwanted +dependencies and in certain cases significantly expand the image size. + +In other words, avoid using instructions similar to this one: + +``` +RUN yum -y update +``` + ==== RHEL base images ==== Building your own @@ -91,20 +106,6 @@ RUN yum -y install ---- -==== Updating Software supplied by Base Image - -Avoid updating software supplied by base image unless necessary. Base images themselves are meant to be updated -on a regular basis by the supplier and provide software that has been tested for a particular environment. - -Also, updating base-image software in layered images can introduce unexpected problems or bring in unwanted -dependencies and in certain cases significantly expand the image size. - -In other words, avoid using instructions similar to this one: - -``` -RUN yum -y update -``` - // TBD: different recommendations for Fedora and CentOS/RHEL base images? ==== Squashing layers diff --git a/images/simple_db.png b/images/simple_db.png new file mode 100644 index 0000000..6f5718c Binary files /dev/null and b/images/simple_db.png differ diff --git a/images/simple_db_containerized.png b/images/simple_db_containerized.png new file mode 100644 index 0000000..c6d046f Binary files /dev/null and b/images/simple_db_containerized.png differ diff --git a/planning/planning_application_classes.adoc b/planning/planning_application_classes.adoc new file mode 100644 index 0000000..28a5002 --- /dev/null +++ b/planning/planning_application_classes.adoc @@ -0,0 +1,74 @@ +=== Application Classes + +We have defined applications into four general categories: + +. System Services +. Client Tools +. Service Components +. Micro-service Applications + + +==== 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 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. \ No newline at end of file diff --git a/planning/planning_index.adoc b/planning/planning_index.adoc index 489633a..29a14e9 100644 --- a/planning/planning_index.adoc +++ b/planning/planning_index.adoc @@ -9,94 +9,24 @@ should be considered prior to authoring a Dockerfile. You will want to plan out how to start the application, to network considerations, to making sure your image is architected in a way that can run in multiple environments like Atomic Host or OpenShift. -The following sections discuss our advice and best practices on planning to containerize your applications. +The very act of containerizing any application presents a few hurdles that are perhaps considered +defacto in a traditional Linux environment. The following sections highlight these hurdles and +offer solutions which would be typical in a containerized environment. -=== Application Classes +//Simple database +include::planning_scenarios_simple_db.adoc[] -We have defined applications into four general categories: -. System Services -. Client Tools -. Service Components -. Micro-service Applications +=== Security and user requirements - -==== 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 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. - - -==== Security and user requirements - -==== Host and image synchronization +=== Host and image synchronization Some applications that run in containers require the host and container to more or less be synchronized on certain attributes so their behaviors are also similar. One such common attribute can be time. The following sections discuss best practices to keeping those attributes similar or the same. -===== Time +==== Time Consider a case where multiple containers (and the host) are running applications and logging to something like a log server. The log timestamps and information would almost be entirely useless if each container reported a different @@ -112,7 +42,7 @@ In your Dockerfile, this can be accomplished by adding the following to your RUN -v /etc/localtime:/etc/localtime ``` -===== Machine ID +==== Machine ID The _/etc/machine_id_ file is often used as an identifier for things like applications and logging. Depending on your application, it might be beneficial to also bind mount the machine id of the host into the container. For example. diff --git a/planning/planning_scenarios_simple_db.adoc b/planning/planning_scenarios_simple_db.adoc new file mode 100644 index 0000000..d94881a --- /dev/null +++ b/planning/planning_scenarios_simple_db.adoc @@ -0,0 +1,45 @@ +=== Persistent Storage: Simple Database Server + +Introduce the basic environment and began to foreshadow the perceieved complications + +==== Traditional database server + +One of the simpler environments in the IT world is a database that serves one or more +client nodes. A corporate directory is an example most of us can identify with. Consider +the figure below. + +.Simple database topology +image::images/simple_db.png[] + +In this scenario, we have a single server running a Linux distribution. The server functions +largely as a database server (perhaps postgres) for other clients that can connect to it on +the network. The database is capable of connecting to the clients on the network using the +standard TCP/IP network stack and typically a combination of TCP socket and port. In the case +of posgres, the default port is 5432. + +More importantly, many database implementations store the database files on reliable, Enterprise +storage such as SANs or robust RAID arrays. This is done to obviously protect the database +from data loss. By default, containers have immutable storage; and therefore, if the container +is deleted, your data will be lost. As a developer, you will need to understand and design +your containerization in a way that will allow for data to persist regardless of the state +of the container. + + +==== Containerized Environment + +In the case of a database server, retaining your data can be critical. The default storage for +containers themselves is not persistent but it can be with a little planning. The most common +way to allow for data persistence is using one of the xref:planning_storage[several methods] +already available to docker or your chosen deployment platform. The following figure is a simplified +containerized topography of the same database from above. + +.Containerized database +image::images/simple_db_containerized.png[] + +Note how the container host, like the traditional Linux deployment, has enterprise storage +associated with it. Through the use of a link:https://docs.docker.com/engine/userguide/containers/dockervolumes/[docker volumes], +we can assign storage to containers and those volumes will persist irregardless of the +state of the container. + +For more information about planning for persistent storage, check out the +xref:planning_storage[Storage Options] section. diff --git a/planning/simple_db.odg b/planning/simple_db.odg new file mode 100644 index 0000000..0aeb15f Binary files /dev/null and b/planning/simple_db.odg differ