The Do’s, Don’ts of Docker Containers
Operating on the assumption that whatever it was, it was needed yesterday, enterprise micro-services in general and Docker application containers in particular are making serious headway among developers. The folks charged with developing and distributed enterprise applications have reached the point where they are identifying the drawbacks as well as the advantages of application containers.
Given the right approach, a proponent of the technology argues, the advantages outweigh the hassles. The initial problem argues Rafael Benevides, a senior software developer at Red Hat (NYSE: RHT), is that many new users continue to treat containers like virtual machines.
In a blog post under the title, "Containers For Grownups," Benevides emphasized a key attribute of containers: they are disposable. Indeed, their inherent low overhead in terms of computing and storage resources is what makes micro-services so attractive as enterprise IT infrastructure is weighed down by torrents of data.
"Containers are ephemeral," stressed Benevides, adding, "This characteristic per se forces users to change their mindset on how they should handle and manage containers."
One reason why containers solve many IT problems is that they also are "immutable." That means all necessary components from operating system to configurations to application should behave in production the way the same image behaved in testing.
One downside of feathery containers is their low memory footprint, frequently smaller that what developers are accustomed to. Typically, memory allocation in containers is in the range of tens of MBs. The flip side is that container can be spun up quickly, often in seconds.
Those attributes prompted Benevides to come up with a list of "things to avoid in Docker containers." His post touched off a useful discussion among developers. Topping his list was a warning not to store data in containers. "An application version 1.0 running in container should be easily replaced by the version 1.1 without any impact or loss of data," Benevides wrote. "Make sure your applications are designed to write to shared data stores."
Other tips included avoiding large images and single layer images and resist creating images from "running containers."
The Red Hat engineer also warned against running multiple processes in a single container.
A commenter agreed: "All new applications should be designed with good separation of code, configuration and data." He added, Existing applications [might] not have good separation of code, configuration and data. With these apps, you can still make your life better by adopting Docker and [Google's container cluster manager] Kubernetes, but you may not be able to separate everything into separate containers."
Meanwhile, the security of application containers remains an ongoing concern. Isolation of containers, trusted container registries and encryption approaches all have been proposed to ensure the security of container content. Benevides also noted that credentials like user names and passwords should not be "hardcoded" into a container image.
Finally, Benevides cautioned against relying on IP addresses when application containers or micro-services need to communicate with another container. Instead, he recommended using "any names and/or environment variables to pass the proper information from one container to another."
