Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Avoid These Big Mistakes When Implementing Docker Containers

DZone's Guide to

Avoid These Big Mistakes When Implementing Docker Containers

For the Docker uninitiated, make sure that you take a look at this article for a quick guide on three things not to do with Docker containers.

· Cloud Zone ·
Free Resource

Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.

Switching from traditional VMs to containerized applications can bring major upgrades in efficiency and reliability. But if you handle your containers incorrectly, you’ll be throwing all those benefits out the window – and frustrating your users in the process!

containers-checklist-magalix

Here are three of the most common mistakes many organizations make when they implement Docker containers for the first time.

Storing Important Data in Containers and Registries

While containers are great at storing non-sensitive data for individual sessions, they’re not designed to store data that needs to persist across sessions, or any information that may pose a security risk. In fact, if you store any sensitive data within the container itself, you run the risk of losing that data when that container stops – and if you store secrets such as passwords using environment variables or container registries, you run a significant risk of being compromised, as Vine was in 2016.

Instead of storing your containerized data locally, it’s always a better idea to keep secrets, critical data – and in fact, all data other than container images and temporary files – in the cloud, and fetch it via SSH on an as-needed basis. That’s the only surefire way to keep private information secure, while also keeping your important data in safe.

Running Too Many Services, Especially in The Same Container

One common Docker newbie mistake is to treat a container as if it’s a conventional Linux environment, and practically set up an entire OS inside it. Even in less extreme cases, many novices make the mistake of hosting many (seemingly) necessary services inside the same container. But this is a major mistake, because every service increases your security vulnerability.

As Docker’s best practices document explains, it’s best to stick to the rule of “one process per container.” Even if it’s sometimes necessary to run two or more processes in the same container – for example, instances of cron and syslog – it’s better to let a baseline Linux image handle those services, for you.

Improperly Handling Docker's Build Cache

It won’t take long to notice problems with the Dockerfiles build cache, because your container images will suddenly start taking a very long time to build. If you’re using behaviors like ADD, VOLUMES or RUN in the wrong places, those may be invalidating your cache. It’s also important to keep in mind that Dockerfile execution happens sequentially, so changes can deprecate future caches.

To keep your cache reasonably sized without losing critical data, try grouping your RUN shell sequences together according to type, and handling cache order manually rather than automatically. Purging the cache is only a last-resort measure, but a bit of careful selective invalidation can help you regain control of troublesome cache volumes when necessary.

Steer clear of these three common mistakes, and you’ll be well on your way to providing fast, efficient, reliable containerized apps for your users. 

Like what you read? Get more insight from Mohamed on the Magalix blog: magalix.com/blog.

TrueSight Cloud Cost Control provides visibility and control over multi-cloud costs including AWS, Azure, Google Cloud, and others.

Topics:
docker containers ,container adoption ,container as a service ,cloud ,anti patterns ,mistakes

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}